What is Software of Unknown Provenance (SOUP)?

In the world of medical devices, software plays a critical role. However, not all software used in these devices is developed from scratch. Often, off-the-shelf software, or software of unknown provenance (SOUP), is integrated into the device. But what exactly is SOUP?

Update: We also released a new license checker that you can use for the SOUPs in your software, completely free to use. Simply upload your package.json or requirements.txt to get all the licenses for SOUPs in your software. It saved our clients a ton of time so we decided to make it public. Check it out here after reading the article.

Software of Unknown Provenance aka SOUP

Software of Unknown Provenance, or SOUP, is a term used across industries to describe software whose safety, performance, and potential risks are not fully known because it was not developed by the device manufacturer themselves. This includes off-the-shelf (OTS) software that has not been developed with a known software development process or methodology and could include anything from an operating system, a database management system, or even a software library. We will give some more specific examples of these below.

The use of SOUP in medical devices is particularly important due to the potential risks it can pose to the safety and performance of the device. If the provenance of the software is unknown, it can be difficult to assess the reliability, safety, and potential risks associated with its use. This is especially crucial in medical devices where software failures can lead to serious harm or even death.

The IEC 62304 standard provides a framework for the lifecycle processes of medical device software, including the use of SOUP. According to section 8.1.2 of this standard, you are required to identify SOUP by name, version, and manufacturer of each SOUP item. We found the best way of accomplishing this is through a global SOUP list.

Additionally, section 7.1.2 and 7.1.3 requires manufacturers to analyze each SOUP item for potential risks to patient, operator, or third parties. This includes identifying known software anomalies that could contribute to a hazardous situation. A good place to check for this are GitHub issues or other issue boards for the software.

While the use of SOUP can provide certain benefits such as cost and time savings, it is crucial that manufacturers thoroughly document and assess the potential risks associated with its use in accordance with the IEC 62304 standard. 

You might be asking yourself “how in the world am I going to document all of this for my product?” Well, not all software components need to be classified as SOUPs. Let’s talk about  which are SOUPs and why

Determining SOUP and Handling Challenges

Determining whether a software component is a SOUP can be challenging, especially when dealing with complex systems or legacy code. How do we classify such components?

The first step in classifying a software component as SOUP is to identify whether the software component was developed following a known software development process or methodology related to medical technology. Did the manufacturer follow IEC 62304 and was it built under ISO 13485? If it was not, or if this information is not available, the software component can be considered SOUP.

In practical terms, classifying a software component as SOUP involves a thorough evaluation of the software component, its intended use in the medical device, and the potential risks it presents. This process requires a deep understanding of both the software component and the medical device in which it will be used. Here are some general considerations for different types of software components:

• Node/Python/Java/Rust dependencies: If these come from third party libraries and, if they included in your medical device software, they are SOUPs
• Hosed services like authentication or notifications: This depends on the function. If they are contained within your application, they are SOUPs. Often these can reside outside of what we consider the “software medical device” and in this case these services are not SOUP.
• Operating systems or frameworks: There is some debate on this. Since operating systems and frameworks are often considered the environment that the software operates in as opposed to part of the software medical device itself, you could justify these as being not included as a SOUP.
• Development tools: Any tools used in development like IDEs and compilers are not considered SOUP as they aren’t used for a medical function but in building the software.

‍

Let’s look at some examples of SOUP items and non-SOUP items. For this example, let’s consider our medical device being software that analyzes a photo of your skin to monitor skin rashes caused by psoriasis to help you stay up to date on your treatments. The software was built in house by an engineering team but contains some third party software components. In the table below we have provided some examples of those components and whether they are SOUP or not. 

‍

‍

Remember, the use of SOUP does not absolve you from ensuring the safety and effectiveness of the medical device. You are still responsible for the performance of the device, including any software components classified as SOUP. Therefore, a rigorous risk management process is essential when dealing with SOUP. 

Managing IEC 62304 Documentation Requirements for SOUP

To effectively manage the IEC 62304 documentation requirements for SOUP, you can adopt a few practical strategies. These include maintaining a SOUP inventory, conducting regular risk assessments, and establishing a robust change management process. 

Below described in more detail is how to go about those processes:

• Identify SOUP: The first step is to identify all SOUP used in your medical device software by name, manufacturer, and version of the software you are using. You should also identify where in your software architecture the SOUP resides. The first place you should go for SOUP is your dependencies list for each software item in your medical device software. If your dependencies have dependencies, they are covered through your assessment of the original dependency.
• Manage risks: The standard requires you manage the risks related to the use of all SOUPs. This can be captured individually by SOUP or more broadly in your risk management file. If failure of a SOUP may lead to patient harm, document it in your risk analysis.
• Document SOUP requirements: For risk class B and C software, SOUP items need to have their functional and performance requirements documented as well as their system hardware and software requirements. In your list of SOUPs, you can specify this as what your SOUPs are required to do and what is required to run them, respectively.
• SOUP anomalies: It is required that all SOUPs are reviewed for any known anomalies. At a minimum, any anomaly lists that exist for the SOUPs should be reviewed to be sure that the known anomalies associated with the SOUP are known. 

Obviously, this can be a burdensome amount of documentation should you have long lists of third party libraries that you are incorporating into your software. We have found that using a table to document as much of your SOUP information as possible might work the best. Additionally, noting requirements of the SOUP in the software architecture documentation is good practice.

FormlyAI: Your Partner in Medical Device Certification

At FormlyAI, we understand the complexities of MDR medical device certification. Our service provides a streamlined, efficient path to CE marking and all the tools to ensure your medical device adheres to all necessary EU regulations. All for a fraction of the cost of using traditional consultants. This way you can build your compliance documentation and apply for CE marking in a matter of weeks, not years.  

Learn more about our software and accelerate your path to CE marking with Formly.