Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

⚠️ Software Risk Analysis in Medical Devices

Marion Lepmets _SoftComply_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
April 11, 2024

In the Medical Device industry software components, whether standalone or as part of a physical device, must follow the same rules as any other component, i.e. ISO 14971 “Medical devices – Application of risk management to medical devices”.

BUT

.. but there are significant deviations required by IEC 62304 and the GDA guidance document “Content of Premarket Submissions for Device Software Functions”

In particular:

It is often difficult to adequately estimate the probability of software failures that could contribute to a hazardous situation. Applying unrealistically low probability estimates to software failures could result in unrealistic risk evaluation and subsequently lead to inappropriate risk control measures. As a result, in some instances it may be prudent to focus on the identification of potential software functionality and failures that could result in hazardous situations instead of estimating probability. In such cases, considering a worse case probability is appropriate, the probability for the software failure occurring should be set to 1.

This is not a small demand. It compromises the typical approach to risk management, where controls and mitigations are used to reduce the probability of the hazardous situation occurring. No matter what you do, P=100% before and after mitigation. Even if you use a split probability P1 and P2, P = P1 x P2 = P2, and P2 is not usually modified, as it ties in with clinical effects.

In your risk model, the risk level will remain in the same range:

How is it possible then to set the acceptability of each individual risk item? How can a company determine if it has done enough?

There are two general approaches that have been accepted by the FDA and Notified Bodies, and they are described below.

Line-by-Line Justification

With this approach, the Product Development team must explain why the selected controls are sufficient for each risk and reduce the risk As-Low-As-Possible. This is a time-consuming task, where users are tempted to copy and paste the same justification over and over, defying the purpose of this assessment.

It is a safe approach though, as the Severity of the risk is the only parameter used to make the acceptability assessment.

The Third Parameter

The Development Team can also define an additional parameter, let’s call it a “mitigation level”, and assign a value based on the effectiveness of the controls the team thinks that they have.

It may look like a Probability, it may work the same as Probability, but it’s not Probability.

Please note that these levels, their names and descriptions are arbitrary.

… and more

If deemed necessary, the team can also define the mitigation level as a function of other factors, for example the type of mitigation:

Type of Mitigation

 Mitigation Level

 None  None
Software, in the same component as the one being assessed  Minor
Information (e.g. training, manual)  Minor
Software, in a different software system as the one being assessed (e.g. a watchdog)  Moderate
Protection (e.g. alarms)  Moderate
Design High

Please note that these levels, their names and descriptions are arbitrary.

Conclusion

Despite losing a valuable parameter such as Probability, there are several solutions that a development team can adopt to assess the risk level and acceptability for software components or products.

Just do not use the word “Probability”.


For more information about Medical Device Risk Management app in Atlassian Jira, check out the most advanced Risk Management app in Jira Cloud – you can try it out for free for 30 days. 

Alternatively, schedule a call with the SoftComply team!

Risk Manager Plus.png
SoftComply Risk Manager Plus on Jira Cloud

1 comment

Comment

Log in or Sign up to comment
Aaron Morris
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 11, 2024

Thank you! This is thought-provoking. The strategy you describe might solve some other challenges with using probability, too.

For example, there is the challenge that hazard probability is a moving target that naturally increases as product adoption and usage increase.  Using mitigation level might resolve that challenge as well.

Matteo Gubellini _SoftComply_
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 19, 2024

Hi Aaron,

Regarding the increased "exposure" of population to risks due to product adoption, I saw companies use different probability scales depending on the forecast number of users, e.g. "Improbable" was 10^-6 for "normal" usage, but 10^-7 for "high" usage. But here we were talking about 100k's of users.

Like Aaron Morris likes this
TAGS
AUG Leaders

Atlassian Community Events