Software Risk Analysis in Medical Devices

April 10, 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 MitigationMitigation Level
NoneNone
Software, in the same component as the one being assessedMinor
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
DesignHigh

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 – you can try it out for free for 30 days. Alternatively, schedule a call with the SoftComply team!

Follow us on LinkedIn for more on Risk Management:

Table of Contents

Ready to get started?

Contact us to book a demo and learn how SoftComply can cover all your needs

Confluence Validation
Picture of Marion Lepmets

Marion Lepmets

CEO
August 25, 2025

Medical device companies face a constant challenge: how do you validate cloud software tools that update daily? If you’re using Confluence Cloud for your quality management system, you need validation documentation that keeps pace with Atlassian’s frequent updates. I’ll walk you through exactly how to automate this process using the...

Risk Reporting
Picture of Marion Lepmets

Marion Lepmets

CEO
August 19, 2025

Risk reporting isn’t just another checkbox on your compliance list. It’s the backbone of effective risk management that keeps your team informed, your management happy, and your auditors satisfied. When you’re managing risks in Jira, you need clear, current reports that don’t require endless manual updates or screenshot juggling. Watch...

P1 P2 hazard analysis approach
Picture of Marion Lepmets

Marion Lepmets

CEO
August 13, 2025

Do you want to make your medical device risk management more precise? While many companies stick with single probability values in their hazard analysis, ISO 14971 suggests breaking down probability into P1 and P2 components. I’ll show you exactly how to set this up in Jira using nested risk models....