Medical device recalls nearly doubled from fiscal years 2003 to 2012, according to the FDA.¹ 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.

Lisa Weeks

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.² 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.³ 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.

Risk Planning

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:

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.
 

Risk Assessment

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:

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.

Best (and Worst) Practices for Assessing Risk

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. 
 

Sources: