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.

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.

Risk Assessment

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.

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.

Risk Result

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.

Risk Review

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