Although rapidly advancing medical technologies revolutionize healthcare, they can also cause setbacks as medical device software complexity increases.
Medical device software design failures account for most of the recent FDA medical device recalls, which have nearly doubled in the past decade.
Design safe and sound medical software by implementing a medical device software development risk management process that complies with FDA Quality System Regulation 21 CFR, ISO 13485, ISO 14971 and IEC 63204.
It is imperative to conduct software risk management in the development phase to consider overall medical-device risk throughout the entire process. For example, if the user inserts a disposable with an expired date code, the software would detect the out-of-date condition and alert the operator for an appropriate intervention. It’s appropriate to evaluate many use cases to identify all hazards. Without taking the whole medical device into account during software development, this control measure wouldn’t exist – leading to a potentially hazardous situation.
Although resorting to labeling might seem like the easiest and most cost effective risk control measure, labeling is the least desirable RCM because it leaves the potential for use errors and its effectiveness is difficult to measure.
Medical Software Risk Management Rundown
The Association for the Advancement of Medical Instrumentation (AAMI) says the medical software risk management plan
describes how software is used in the medical device, describes how the software will be developed, identifies any development aspects unique to risk management and identifies risk acceptance criteria if different from risk acceptance criteria of other components.
The medical device software development risk management process involves:
- Communication: Document and communicate risk at every stage.
- Assessment: Risk identification, analysis and evaluation
- Control: Risk reduction and acceptance
- Result: Software output
- Review: Event analysis, residual risk evaluation
Now, we’ll take a closer look at each stage in the process.
Every software item undergoing risk management contains a risk management file.
Document the sequence of events that could result in a hazardous situation in that file, as well as all of the risk control measures and the method used to verify those measures.
Communication needs to occur at every stage of the medical device software development risk management process.
Apply the medical device software development risk management process to all software that could potentially cause a hazardous situation.
AAMI describes risk as the combination of the probability and severity of harm, with harm being physical damage to people, property or the environment. A hazard is the potential source of the harm, such as heat, electrical energy and the transfer of substance.
That brings us to hazardous situations, where people, property or the environment are exposed to hazards.
Potential causes of a hazardous situation include:
- Incorrect or incomplete specification of functionality
- Software defects in the identified software item functionality
- Failure or unexpected results from software of unknown pedigree (SOUP)
- Hardware failures or other software defects that could result in unpredictable software operation
- Reasonable foreseeable misuse
Note: When SOUP is a potential cause of medical device software failure, at a minimum, review the software vendor’s anomaly list for known anomalies resulting in a hazardous sequence of events.
If a hazardous situation could arise from a software system failure, assume 100% probability of failure.
Examine actual clinical hazards as the first risk assessment step by establishing intended use and involving the people who will use the product. From there, get into lower-level software analysis.
AAMI offers the following risk assessment considerations:
- Device behavior complexity
- The user’s reliance on the device
- Device configurability and user’s understanding of current configuration
- Transfer of information
- User interfaces
Once you’ve determined the possibility of a hazardous situation, begin risk reduction through control measures.
Risk Control Measures
Risk control measures are methods used to reduce the occurrence and/or severity of potential harm.
Define and document the risk control measures for each potential cause of a hazardous situation in the software item’s risk management file.
Implement software risk control measures for hardware failures, use errors, software common causes and software specific causes, as well as hardware and labeling RCMs for software causes.
AAMI lists the preferred RCM order as:
- Inherent safe design: Fail-safe philosophy unique to intended use, change software architecture, simplify user interface, and use defensive design and programming
- Protective measures: Separate of software function, fault tolerance and memory protection
- Detection and notification: Applied at system boundaries and interfaces, checks on input and output, limits transfer of energy or substance to patients
- Labeling and training: Warnings on the device, user education
If implementing a risk control measure as part of a software-item function:
- Include it in the software requirements
- Assign a safety class to the software item based on the severity of the hazardous situation
- Develop the software item in accordance with your software development process
Verify each risk control measure implementation and document the verification.
If implementing a risk control measure as a software item, evaluate the measure, and identify and document any new potentially hazardous events in the risk management file.
After implementing all risk control measures, observe the software output and evaluate the results.
Analyze software changes to determine whether other potential hazardous situations are introduced or if they interfere with existing risk control measures, and if additional software risk control measures are required.
Document all remaining software anomalies in the risk management file before proceeding to the review phase.
Evaluate the residual risk you observed in the software output.
Ensure that the residual risk doesn’t contribute to unacceptable risk.
The manufacturer determines acceptable risk, which may be based on number of failures, failures per patient, failures per hour of use and more.
You may need to consult objective clinical experts to make this determination.
In the risk management file, document the traceability of software-related hazardous situations:
- From the hazardous situation to the software item
- From the item to the specific software cause
- From the software cause to the risk control measure
- From the risk control measure to the risk control measure verification
You’re not done yet
In the medical product production and post-production phases, plan software maintenance, integrate risk management into software-problem investigations, involve multidisciplinary teams and consider SOUP in software maintenance.
If possible, plan for sustaining engineering as early in the medical device software development process as possible.
Don’t Risk Harm, Recall and Reputation
Reduce risk and prevent medical device recall due to medical software failure. Patient lives, and your reputation, depend on it.
Implement a quality compliant medical software risk management plan, or work with a medical device development partner with experienced software developers, who can:
- Identify ways software can fail
- Analyze risks associated with software failure
- Identify and apply risk control measures, and
- Analyze post-release problems and implement change
A proper medical software risk management plan saves lives and keeps customers.
What other steps do you take to mitigate medical device software risk? Please share in the comments below.
For information about KMC’s medical device development services, download our capabilities sheet.