What is Software of Unknown Provenance (SOUP)?

When developing medical software, you may encounter the term “SOUP”, which stands for Software of Unknown Provenance. In today’s article, we will explore its importance for medical software development, the differences between SOUP and OTS, and the way of documenting your SOUPs.

Software of Unknown Provenance (SOUP) – definition

First, you should know that SOUP is defined in IEC 62304, a quality standard that states life cycle requirements for medical device software.

In this document, we read that Software of Unknown Provenance is “a software item which 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” (source: IEC 62304).

In simpler terms, SOUP is any software used in medical software which hasn’t been developed by the manufacturer responsible for said medical software. Thus, this software component is out of their control regarding the life cycle management.

Software of Unknown Provenance (SOUP) – examples

It’s always easier to understand the topic by learning some examples. So, what third-party software can be classified as SOUP?

1. Libraries are files with ready-to-apply fragments of the code. It is usually easier and faster for developers to use them to provide required functionalities rather than to code from scratch.
   
   Libraries can be published under many licences; however, two flagship examples are open source (freely accessible to everybody) and commercial (e.g., with subscription payment).
   
   

2. Development tools are programs which software developers use to create apps easier. There are many tools in this category, such as compilers or no code and low code platforms (NCLC). What are they? NCLC are software development programs that enable developers to design medical apps through drag-and-drop features without the need for manual coding (or with minimal integration into the code).
   
   

3. SaaS stands for Software as a Service and describes software which is distributed by the cloud providers. Thanks to this, every end user is able to access those services through the internet without having to install any app. A great example of Saas is Amazon Web Services.
   

What is the difference between (C)OTS and SOUP?

You might have heard about the terms OTS and COTS. What are they? How do they differ from SOUP?

• OTS stands for “Off-The-Shelf software” – which is “a generally available software component, used by a medical device manufacturer for which the manufacturer cannot claim complete software life cycle control (e.g., operating system, printer/display libraries)” (source: FDA),
  
  

• COTS is “Commercial Off-The-Shelf software” – an OTS from a commercial supplier (e.g., Microsoft Windows).

The term OTS was established by the FDA (Federal Drug Administration) in the 1990s, whereas SOUP comes from IEC 62304. Some say that they are the same, yet, we can notice a subtle difference between them.

The most significant distinction is that OTS is more capacious than SOUP. OTS can be considered a part of a medical device or software (e.g., a library) or an “imperative” to other software items the manufacturer uses.

What does it mean? Suppose you consider some software item to be a part of the infrastructure (according to ISO 13485 p. 6.3) typically used in your company. In that case, you must go through a verification and validation process according to ISO 13485. This way, you can use this software item without considering it a SOUP.

An example of this situation is using cloud software such as Amazon Web Services to support your medical app, even though it is not an element of the medical software (thus, it’s not a SOUP).

Now that we know that there are OTS which are not SOUP, you might wonder, is there any SOUP which is not OTS? Of course! Let’s go back to the SOUP’s definition, in which we read: “software previously developed for which adequate records of the development processes are not available”. What does it mean?

Let’s imagine that the manufacturer developed software before IEC 62304 came into force and thus did not prepare the documentation to comply with the standard. In such cases, we are talking about SOUP rather than OTS.

To sum up, there is a slight distinction between the SOUP and OTS stemming from their definitions. However, it's important to note that they are governed by different regulations tailored to specific regions.

What is a SOUP list?

If you decide to use SOUPs in your medical software, you will be obligated to maintain a list of all third party software that was used during the development of medical software. This list must include a different set of information depending on the software safety classes. What are they?

IEC 62304 mentions three software classes related to the safety of the patients who will use the final product. They are:

• Class A: no injury or damage to health is possible,

• Class B: non-serious injury is possible,

• Class C: death or serious injury is possible.

Once you establish the safety class of your medical software, there are different documentation requirements for the SOUP list.

For each type of software  (class A, B, and C), you should list a name of the SOUP, its version, the manufacturer, and the source of it.

If your software falls into the B or C class, you must also include functional, performance, hardware, and software requirements for your SOUP. Moreover, you must include a website with a list of SOUP's reported bugs and issues.

Last but not least, you are obligated to plan a risk analysis for every single SOUP you use, regardless of the safety class of the software.

A manufacturer should always consider creating such a list to maintain the highest level of transparency. Thus, at Revolve Healthcare, we prepare SOUP lists in compliance with IEC 62304 in every MDR (Medical Device Regulation) project. Our clients always receive comprehensive documentation regarding SOUP used in developing their medical software.

SOUP for medical device software

Using SOUP when developing medical device software can make the process more efficient as developers use software items already tested in live systems (even if those solutions aren’t medical). Moreover, using SOUPs can bring more functionality to the final product.

On the other hand, a manufacturer should be aware of the potential threats of using SOUPs (such as the possibility of SOUP’s malfunction influencing the usability of medical software and patient’s safety) and maintain the highest level of risk analysis to avoid malfunctions when the product is used by patients.

Do you plan to develop medical software? We can bring your idea to life while complying with all the necessary standards, guaranteeing the highest quality and safety. Want to talk about it? Schedule a free discovery meeting with our experienced experts.