Software is playing an expanding role in modern medical devices, raising the question of how developers, regulators, medical professionals, and patients can be confident in the devices' reliability, safety, and security. Software- related errors in medical equipment have caused people's deaths in the past, so the issue is not simply theoretical. Device manufacturers need to provide safety assurance for complex software that is being developed in a competitive environment where price and time-to-market are critical factors. Further, security issues that previously were not a major concern now need to be anticipated and handled.
I recently spoke with Dr. Benjamin Brosgol, senior member of the technical staff at Adacore, about these issues. This includes how some recent Food and Drug Administration (FDA) regulations are dealing with such issues, and how programming language and support tool technology can help.
Wong: How does the medical device industry differ from other safety-critical industries, such as avionics, transportation and nuclear control?
Brosgol: Obviously there's a basic similarity in that a software failure can directly lead to human fatality, but there are also some differences between medical and other domains:
- If a plane crashes or a nuclear reactor releases deadly radioactive gases, that's instant news all over the world. On the other hand, one person dying from an insulin overdose caused by faulty infusion pump software does not get the same attention. That's not to understate its significance, or the importance of having confidence that medical devices "first do no harm". But historically the requirements for certification in the medical industry have not been as strict as in domains such as commercial avionics.
- If software problems delay a new aircraft's flight certification, then airlines can use older planes. This is perhaps an inconvenience for passengers, or an additional cost for the airline or the manufacturer, but the delay is not a safety hazard. On the other hand, if there is a delay in certifying a new life-saving medical device, then people can die while waiting for the device to be approved. That tends to put the onus on the FDA to show that a device is unsafe, versus on the manufacturer to show that it is safe.
- There are only a few companies in the business of constructing airplanes or nuclear reactors, whereas there are several thousand medical device companies. The large number of vendors of medical devices affects the dynamics of regulation/approval.
- In most safety-critical domains, equipment is operated only by trained / certified personnel. Medical devices often need to be operated by end users (patients) who have no formal training. That places a higher demand on the design of the user interface and the need for hardware- or software-enforced checks on inputs or outputs.
- Many safety-critical industries see software lifecycles that extend over a decade or more, with the hardware platform remaining stable. In contrast, a medical device manufacturer tends to react more quickly to hardware improvements that will offer a competitive advantage in terms of performance or functionality. That in turn induces a need for more frequent software changes or upgrades, which can introduce various risks (regression errors, configuration / version problems, etc.).
Wong: Give some examples of medical device software safety issues that have been responsible for patients' deaths.
Brosgol: Some of the earliest and most dramatic incidents involved the Therac-25 radiation therapy machine in the mid 1980s, when a software design error caused several patients to be killed from radiation dosages orders of magnitude higher than what had been intended. The immediate cause was a so-called "race condition" where rapidly-entered human input took the machine into an unplanned state. But more fundamentally, a detailed accident analysis cited shortcomings in the development and verification process, including inadequate software engineering practices.
Unfortunately, that was not the only case where defective medical device control software has proved fatal. Here's an excerpt from Total Product Life Cycle: Infusion Pump - Premarket Notification [510(k)] Submissions (Draft Guidance, April 2010):
FDA has seen an increase in the number and severity of infusion pump recalls. Analyses of MDRs [Medical Device Reportings] have revealed device problems that appear to be a result of faulty design. Between January 1, 2005 and December 31, 2009, FDA received over 56,000 MDRs associated with the use of infusion pumps. Of these reports, approximately 1% were reported as deaths, 34% were reported as serious injuries, and 62% were reported as malfunctions.
This translates into a rate of more than 100 deaths and 3500 serious injuries per year, from equipment that is supposed to be helping people. The Draft Guidance goes on to state:
The most frequently reported infusion pump device problems are: software error messages, human factors (which include, but are not limited to, use error), broken components, battery failure, alarm failure, over infusion and under infusion. In some reports, the manufacturer was unable to determine or identify the problem and reported the problem as "unknown." Subsequent root cause analyses revealed that many of these design problems were foreseeable and, therefore, preventable.
The FDA has evaluated a broad spectrum of infusion pumps across manufacturers and has concluded there are numerous, systemic problems with device design, manufacturing, and adverse event reporting. FDA has structured this guidance document to address these device problems prior to clearance of the premarket notification and in the postmarket context.