⚠️ How to Manage Risks of Off-the-shelf Software

[#1]

Your medical device software is likely to contain a number of components, items, packages, libraries, etc. not developed directly by your company. It may include open-source or purchased software. Unless you have a very close relationship with the developer and access to the source code, these components are black boxes for you.

According to IEC 62304, the definition of SOUP (software of unknown provenance) is “SOFTWARE ITEM that is already developed and generally available and that has not been developed for the purpose of being incorporated into the MEDICAL DEVICE (also known as “off-the-shelf software”) or SOFTWARE ITEM previously developed for which adequate records of the development PROCESSES are not available”.

Any component that is not developed according to IEC 62304 can be considered SOUP, which is the vast majority of OTS software.

Now, you need to include these components into your Risk Management File.

What is the best approach?

We have discussed the general process for medical device risk analysis in a previous post, and the same applies for SOUP components. In addition, IEC 62304 requires a company to at a minimum “evaluate published SOUP anomaly lists” (you can consider anomaly = bug).

Note: if the developer has not provided a list of known bugs, it may mean that the maturity of the company behind it is not great.

Top-Down Approach

For this approach remember, that you will not do a Hazard Analysis for a SOUP component only. You will need to understand that SOUP failures are accounted for as causes of a higher level software system failure.

Advantages:

• It requires little knowledge of the SOUP items;
• It naturally fits into the existing risk analysis documents.

Disadvantages:

• It is easy to miss some SOUP failure modes if they do not fit into the existing cause-event analyses.

Bottom-Up Approach – FMEA

For complex systems, large number of SOUP items or high risk devices, it is advisable to use a bottom-up approach to analyse SOUP.

This means having each SOUP item as a component entry in a risk analysis, like other software items and components. In certain cases, a separate SOUP FMEA may be a good idea.

Advantages:

• Exhaustive approach;
• Easy fit for known bugs/anomalies.

Disadvantages:

• More burdensome than a top-down approach, leading potentially to duplications.

🍜 Conclusion

SOUP items are integral part of any modern software product, but they must be assessed adequately as unpredicted failures may lead to dire consequences.

You can also apply the Benefit-Risk assessment to determine whether it is worth developing a component in-house rather than purchasing it.

[Brian L Pate]

I like what you have written @Marion Lepmets _SoftComply_ ! SOUP components often get forgotten during the risk management activities and specifically the software hazards analysis activity. However, SOUP components as you stated can fail (or behave in an expected way) just like our custom written software components. Regulators (and end-users!) will expect the developers to have considered those failure modes and misbehaviors during development and to have appropriately mitigated them.  I also encourage early top down fault tree analyses to help with the selection of "the most appropriate" SOUP as some SOUP may have more error detection / handling capabilities than others.

Glad to see more tools to help developers and manufacturers manage the analysis information so as to be more effective and likely efficient.  Onward to better software risk management!

[Matteo Gubellini _SoftComply_]

@Brian L Pate  absolutely right, I found FTAs incredibly useful in the decision making process. It gives you a solid, risk based rationale to justify it.