Your 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 already discussed the general process for software 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.
