Medical device recalls nearly doubled from fiscal years 2003 to 2012, according to the FDA.1 While some attribute the spike to increased reporting on the part of device manufacturers, others blame design failure—in particular, software design failure, which was identified as the most common recall cause.
It’s rare these days to find a medical device that does not rely heavily on software to operate. In many cases, it’s the software component within a device that differentiates one company’s product from another’s. But as medical software grows more sophisticated in terms of both design and functionality, FDA reviewers are forced to increase their level of expertise, as well as the amount of time they spend reviewing many 510(k) submissions. This can impede time to market. Increased software complexity also makes it harder for manufacturers to pinpoint the technical risks that could lead to failure or recall—or worse.
In November of 2000, at the National Cancer Institute in Panama, radiation therapy planning software in a Cobalt-60 radiotherapy machine miscalculated the proper dosage of radiation, jolting 28 patients with massive overdoses of gamma rays. Forty months after the incident, it was reported that 21 of the 28 patients had died.2 More recently, in May of 2015, CareFusion issued a Class I recall of its Alaris Pump caused by a software error that caused the pump to delay an infusion. Days later, CareFusion recalled a line of ventilators, citing a software flaw that could cause suffocation.3 While there were no fatalities associated with the CareFusion malfunctions, the company has sustained considerable brand and reputation damage.
Unique Challenges of Identifying Defective Software
Clearly, a software malfunction can be just as deadly as any other device component failure. However, it’s harder to identify and quantify the potential effects of defective software. The more complex the component, the more defects it may have, and software programs are the most complex things humans make. Also, many of the standard components used in devices, valves, for example, have established track records with mountains of performance data for engineers to consider. Software, with few exceptions, is proprietary and often device-specific, so performance data is sparse or non-existent.
“Medical device software engineers essentially have to reinvent the wheel with each new piece of code,” says Matt Lowe, MasterControl executive vice president, global sales and marketing, who has experience launching more than a dozen medical devices. “They don’t have the luxury of performing a complaint analysis on a predicate device. The data just isn’t there.”
So, how can manufacturers reap the benefits of software while avoiding the clearance delays, increased safety risks and other setbacks that are often side effects of rapidly advancing technology? As with most things these days, it comes down to risk.
Foundational Standards for Medical Devices
Risk management is not a new concept for device makers. The FDA’s Quality System Regulation requires risk management in their design, manufacturing, and support processes, and ISO 14971, the international risk management standard for medical devices, has been around since 2000. The main standard pertaining to software in medical devices, IEC 62304, also supports a risk-based approach to software development. There are at least a half-dozen additional standards that address the importance of applying risk management principles when designing life- or safety-critical systems and devices.
Yet here we are—several years and standards later—still struggling to understand risk management and the vital role it plays in promoting software safety.
Perhaps part of the problem is that many device makers assume successful risk management means eliminating risk altogether, or they see it as an isolated regulatory activity, separate from the design process. In reality, risk management is ongoing. Continuous improvement, not risk elimination, is its real goal. “It’s impossible to anticipate every potential hazard of your device or its components. This is especially true in the case of software, which is inherently vulnerable,” said Walt Murray, director of MasterControl’s quality and compliance consulting services, who has more than two decades of risk management expertise. “When assessing software-related risks, you don’t ask, ‘What risks can occur if the software fails?’ You ask, ‘What risks can occur when the software fails?’”
Understanding Risk-Related Terminology
Loosely defined, risk management is a systematic process that can be used to identify hazards; to estimate and evaluate the risk associated with those hazards; and to implement and monitor the effectiveness of risk mitigation measures. Done effectively, it helps a manufacturer produce a safer product that performs as expected and experiences fewer failures in the field. If that sounds remarkably like design control, that’s because it is. Risk management as a requirement of design control shares its purpose: to produce safer devices that meet user needs. They should be performed simultaneously.
Whether you are applying risk management principles to the software in a device, to the mechanical or electrical components in a device, or to the medical device as a whole, the process is virtually the same. It comprises four phases: risk planning, risk assessment, risk control, and risk review/monitoring.
The planning stage is critical. Poor or insufficient planning is a common reason for medical software failure—and one that is easy to avoid. According to the Association for the Advancement of Medical Instrumentation (AAMI), a medical software risk management plan must:
- Describe how the software will be used in the device, i.e., its intended use.
- Describe how the software will be developed.
- Identify any development aspects unique to risk management.
- Identify the risk acceptance criteria, if different from the risk acceptance criteria of other components.
Once intended use has been established, per IEC 62304, manufacturers must classify their system in one of three safety classes. Class A is for systems that pose no threat of injury or damage to health. Class B is for software systems that may cause non-serious injury. Class C is reserved for systems that have the potential to cause death or serious injury. The standard, stipulates that “Class shall be set with the knowledge of physicians and the intended use” of the device.
Risk planning also includes the creation of a risk management file for every software item undergoing risk management. The risk management file should include all records and documents generated during the risk management process, including all risk control measures and the methods used to verify those measures.
The purpose of risk assessment is to determine the product’s potential to cause harm, with harm being defined as physical damage to people, property or the environment. Every medical device has the potential to present a hazard. The hazard can lead to a hazardous situation. The hazardous situation can cause harm. Hazards can occur during normal use (intended use), but more so if the device is misused. Hazards and hazardous situations feed into your product development process to improve user needs and design inputs. Hazards that cannot be eliminated by design are called residual risks. They must be assessed and accepted or mitigated by the product developer.
In terms of software, potential causes of hazardous situations include:
- Incorrect or incomplete specification of functionality.
- Software defects in the identified software item functionality.
- Failure our unexpected results for software of unknown pedigree, or SOUP, which by definition is deemed a risk.
- Hardware failures of other software defects that could result in unpredictable software operation.
- Reasonably foreseeable misuse.4
Risk assessment is made up of three interconnected processes: risk identification, risk analysis, and risk evaluation. The terms risk analysis and risk assessment are often used interchangeably, but they are not synonymous.
- Risk identification focuses on uncovering and describing as many of the potential risks associated with the application of your software as possible.
- Risk analysis focuses on estimating the level of risk associated with each independent risk uncovered during risk identification. Failure modes and effects analysis (FMEA) and fault tree analysis are popular risk analysis tools. Risk management software is also available to help you assess and track risk (see Figure 1).
- Risk evaluation focuses on comparing your risk analysis results with your organization’s predetermined risk threshold.
Best (and Worst) Practices for Assessing Risk
- Best: Assemble a cross-functional team, not one comprised solely of development engineers, to brainstorm possible hazard or misuse scenarios. Different perspectives will increase your chances of uncovering more risks. The team should form early; remain active throughout design and manufacture; and understand the foundation standards listed above.
- Best: Consider the risks posed by the medical device as a whole before the software and hardware risks. Hardware risk analysis should then run alongside software risk analysis.
- Best: Integrate risk management into the design process from the get-go. It is easier and cheaper to address risks during design than it is during production or worse, once the product is in use. Of course, you’ll want to revisit your risk assessment any time a change is made, such as in a bug fix.(see Figure 2)
- Worst: Skipping risk analysis or performing it casually. Every identified risk requires its own risk analysis.
- Worst: Addressing (mitigating) risk during the assessment phase; that’s risk control.
Once you’ve assessed your risk, it’s time to brainstorm mitigation methods you can implement to reduce it to an acceptable level. ISO 14971 provides three design options to consider in order of priority: change the design to eliminate risk; incorporate protective measures in the device or manufacturing process; or provide information in an operator’s manual that explains what steps to take when conditions that could lead to a risk occur.
You must verify each risk control measure you implement, and document the verification in the risk management file. Verification activities should be appropriate to the classification and risk of the device, and may include testing, simulations and code and document inspections. The software must also be validated in accordance with regulatory expectations, often with reference to the broader medical device. Your goal is to produce documentation that is suitable for inclusion with (or referenced from) the device master file.
Before you proceed to the next phase, it’s important to review the software output to see if your risk control measures generated any potentially hazardous situations that might interfere with existing mitigation measures or require additional measures.
Review and Monitor Risk
Once you have documented all outstanding software anomalies in the risk management file, review the file to determine whether or not it complies with your risk management plan and all applicable regulatory standards. Make sure you have included appropriate methods for collecting production and post-production information (such as incident reports, customer complaints) throughout the product lifecycle. Make sure this information is included in your risk management file. If it isn’t, you will need to update it and start the risk analysis process over again. Remember, risk management never ends! It is—and should be—an inherent component of your software design process.
Lisa Weeks, a marketing communications specialist at MasterControl, writes extensively about technology, the life sciences, and other regulated environments. Before her tenure at MasterControl, she worked with McNeil Pharmaceuticals, SAP AG, SCA Mölnlycke Health Care, Crozer-Keystone Health Systems, and NovaCare Rehabilitation/Select Med. Connect with her on LinkedInor GxP Lifeline.
- US FDA Center for Devices and Radiological Health, Medical Device Recall Report FY 2003 to FY2012, www.fda.gov/downloads/AboutFDA/CentersOffices/OfficeofMedicalProductsandTobacco/CDRH/CDRHTransparency/UCM388442.pdf (accessed October 8, 2015).
- Ravages of Miscalculations, http://www.baselinemag.com/c/a/Projects-Processes/We-Did-Nothing-Wrong/2 (accessed October 7, 2015).
- CareFusion Runs into More ‘Deadly’ Trouble with Infusion Pump, http://www.fiercemedicaldevices.com/story/carefusion-runs-more-deadly-trouble-infusion-pump/2014-05-21 (accessed October 16, 2015).
- Risk Management in Medical Device Software Device Software Development, http://www.kmcsystems.com/blog/bid/106735/Don-t-Risk-Life-and-Limb-Medical-Device-Software-Development-Risk-Management (accessed October 9, 2015).