A recipe for good SOUP: Part 1 — Defining external dependencies in SaMD

The speed and innovation of modern software development is only possible thanks to an entire ecosystem of third-party tools. In Software as a Medical Device (SaMD) development, these are collectively referred to as Software of Unknown Provenance, or SOUP, and they present a unique regulatory challenge for SaMD manufacturers.

The benefits offered by leveraging these tools come at the cost of introducing uncertainty and risk into medical devices. To account for this, harmonised standards like IEC 62304 have specific requirements for the documentation and management of SOUP. This blog post will be the first in a series where we will dive into the nuances of SOUP in SaMD.

What is (and isn’t) SOUP?

Most common components that could be categorised as SOUP comprise externally available, third-party software. However, presenting SOUP as only externally developed software isn’t entirely accurate, as IEC 62304 defines SOUP as a:

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

Put simply, SaMD manufacturers can think of SOUP as being from one of two general categories:

• Third-party software items that are generally available
• Internally developed software without adequately documented development processes

The third-party software case is fairly straightforward and will likely form the bulk of SOUP for any given SaMD. This could include:

• Open-source libraries/frameworks
• “Off-the-shelf” software
• Programming languages

However, it is important to note that there are circumstances in which internally developed components could qualify as SOUP:

• Components/modules inherited from legacy systems for which adequate records of development processes are unavailable. For example, a legacy image-enhancement module that was used in a non-medical product, or was used in a medical product that lacks documented conformity with ISO 13485/IEC 62304-compliant processes
• Proprietary/internal tools not developed solely for use in the medical device. For example, an internally developed cross-platform UI framework that was not developed for a medical device, or under ISO 13485/IEC 62304-compliant processes

Good SOUP in practice

There are several things to consider when leveraging SOUP in your device. These are some of the questions to ask while documenting your device’s SOUP components:

• What is the SOUP component, and where did it come from?
• What functionality does the SOUP component provide, and does it impact safety or clinical performance?
• How does the SOUP component interact with the rest of the device?
• What risks are associated with the use of the SOUP component, and how are these risks mitigated?
• How will the use of the SOUP component be maintained over the device’s software lifecycle?
• Where does AI fit in here? Do LLMs qualify as SOUP?

We will dive deeper into some of these questions in later blog posts, but first and foremost, let’s start with SOUP identification and how SOUP fits into the overarching software development process of SaMD.

Taking stock 

The first step in managing SOUP is to identify all the software components that qualify as SOUP in your device — capturing key pieces of identifying information. IEC 62304 Clause 8.1.2 outlines the minimum required here:

For each SOUP CONFIGURATION ITEM being used, including standard libraries, the MANUFACTURER shall document:

• a) the title,
• b) the MANUFACTURER, and
• c) the unique SOUP designator

Note: The unique SOUP designator could be, for example, a VERSION, a release date, a patch number or an upgrade designation

Detail matters here. In addition to the SOUP’s manufacturer and unique designator, it may be beneficial to include version history and licensing terms, depending on the source of the SOUP in question.

Software development process

Software items that make up the components and modules in a SaMD product are generally subject to the software development process requirements outlined in IEC 62304 Clauses 5-9. These requirements vary based on the software safety classification of each software item (Class A, B, C). 

Although SOUP components, by their definition, were not necessarily developed adhering to the standards of IEC 62304, you must still manage them within your SaMD’s lifecycle in line with IEC 62304. The extent of this also varies based on the SOUP component’s software safety classification. The table below provides an overview of the IEC 62304 requirements that explicitly reference SOUP, as well as those that are more difficult to apply to SOUP. Note that these requirements highlight when SOUP is most relevant for your software development process. You should always take SOUP into consideration in any software development planning or activity, even if not directly referenced in the requirements — particularly if it could impact the safety or performance of your device.

SOUP in summary

The definition of SOUP in SaMD development contains some interesting nuances that may not be immediately apparent from an initial read of the regulations and standards. Getting a firm grasp of the scope and implementation of SOUP in your medical device will allow you to leverage the benefits SOUP has to offer, while positioning you to better tackle the intricacies of SOUP management in your software development processes. 

Stay tuned for the next blog. In Part 2 of the SOUP series we'll explore how to ensure safety, performance, and regulatory compliance in SaMD development when integrating Software of Unknown Provenance, focusing on testing limitations, risk management, and applicable standards like IEC 62304.