Both the FDA and IEC 62304 recognize software developed by third parties. They refer to Off-the-Shelf Software (OTS) and Software Of Unknown Provenance (SOUP).
What is the difference between OTS and SOUP? What do they have in common? What legal requirements do they have to meet?
This article provides answers.
1. SOUP and OTS: definition and differentiation
a) Definition SOUP
“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“
Source: IEC 62304
IEC 62304:2006+A1:2015 has added the following note to the definition of the term SOUP:
“A MEDICAL DEVICE SOFTWARE SYSTEM in itself cannot be claimed to be SOUP.“
IEC 62304:2006+A1:2015
The unfortunate experiences of auditors who had to deal with dubious arguments from their customers seem to have been incorporated here.
The FDA also used the term SOUP in the previous guidance document, but this has been dropped in the new 2023 guidance document, which (hopefully) causes less confusion:
“Some or all of the software contained in a Software Device may have been obtained by the submitter from a third party. […] Software for which adequate documentation may be difficult to obtain is referred to as Software of Unknown Pedigree or ‚SOUP‘.“
Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, 2005
b) Definition OTS
“a generally available software component, used by a medical device manufacturer for which the manufacturer can not claim complete software life cycle control (e.g., operating system, printer/display libraries).“
FDA guidance document “Content of Premarket Submissions for Device Software Functions“, 2023;
and identical in the FDA guidance document “Off-The-Shelf Software Use in Medical Devices“, 2023
A particular case of OTS is COTS, the Commercial OTS Software, i.e., OTS from a commercial provider.
c) Similarities and differences between SOUP and OTS
Overview
The SOUP and OTS concepts are not entirely congruent:
- There is SOUP, which is also OTS:
Any generally available component not designed to become part of the medical device being developed and over whose development process the manufacturer, therefore, has no control, is both SOUP and OTS. - There is SOUP that is not OTS:
All software items that are not generally available, such as those that the medical device manufacturer has developed itself but for a different purpose and now wants to integrate into the medical device, are SOUP but not OTS. - There is OTS that is not SOUP:
A typical example is any process software from other manufacturers that falls under OTS Software.
Explanations
First of all, it is noticeable that the FDA’s definition is not limited to use in medical devices (“A generally available software component, used by a medical device manufacturer …”). The guidance document in which the definition can be found is called Off-the-Shelf Software Use in Medical devices. And as the title suggests, the document only deals with OTS Software that is part of a medical device (or is supplied by the manufacturer as a runtime environment for the device’s software).
This makes it easy to assume that the terms are essentially identical. But this is not the case! The document in question only deals with one particular application of OTS Software.
However, there is also another one. This becomes clear on closer reading of the General Principles on Software Validation. Chapter 6 deals with “Validation of automated process equipment and quality system software.” It states: “Software tools are frequently used to design, build, and test the software that goes into an automated medical device. […] All of these applications are subject to the requirement of software validation […].”
What does this have to do with OTS Software? Chapter 6.3, “Validation of the Off-the-Shelf Software,” establishes this connection. All the software mentioned above, “to design, build and test the software,” falls under the term OTS Software if other manufacturers distribute it. This leads to the above conclusion.
2. Regulatory requirements
a) Regulatory requirements for SOUP
Requirements as for any other software item
IEC 62304 considers SOUPs to be software components. Manufacturers must specify the requirements for SOUPs (as for any other component) and test their fulfillment. In addition to “normal” components, manufacturers must also specify the prerequisites on which a SOUP can be based, e.g., with regard to resources (RAM, CPU, etc.) or the operating system.
SOUP documentation
To implement the requirements of IEC 62304, I recommend that you document the SOUPs using the following parameters, e.g., in a table:
- Name of the SOUP
- Version (SOUPs are subject to version control like all other artifacts)
- SOUP manufacturer
- SOUP requirements (reference to separate document or software architecture if necessary)
- Requirements by SOUP, e.g., for memory or hardware
- Website of bug reports and release notes
Determination of the safety class for SOUPs
Because SOUPs are software components, they inherit the safety class of the surrounding software system or software item. However, this safety class only regulates the scope of the documentation to be created. IEC 62304 does not impose requirements such as those known to the FDA with the supplier audit.
Specification and review of requirements
As with any other software item, manufacturers must specify the requirements for a SOUP and check compliance later.
Some manufacturers feel obliged to specify and check the complete SOUP, which, for example, is unlikely to succeed with an operating system.
Instead, manufacturers must specify the requirements for the SOUP that they need as part of the software system. In the case of an operating system, these are requirements for access to the hard disk and networks or the capability of parallel processing. It is precisely these requirements that must then be reviewed.
Determination and review of the requirements
IEC 62304 obliges manufacturers to review whether the requirements for the use of a SOUP are met. Examples of such requirements are
- Available main memory (RAM)
- Type and version of the underlying operating system
- Type and version of runtime environments such as Java Run Time and the .NET runtime environment
- Versions of libraries with which the SOUP is to interact
b) Regulatory requirements for OTS
Determination of the Level of Concern for OTS Software (valid until August 2023)
Manufacturers had to determine the Level of Concern in accordance with the provisions of the FDA’s OTS guidance document. Many manufacturers wonder whether they must determine the Level of Concern before or after risk control measures.
This question is crucial for the documentation to be submitted and influences the decision as to whether the OTS may be used at all.
In the Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, the FDA requires the manufacturer to first determine the Level of Concern “prior to mitigation of hazards.” In the case of OTS Software with a “major” Level of Concern, this would mean that the manufacturer would have to conduct an audit at the OTS manufacturer, which is usually not possible.
The good news regarding OTS Software is that there is a level of concern both before and after the risk minimization measures.
Only if the OTS Software still has a “Major Level of Concern” after these measures is the “Special Documentation” necessary, including the OTS manufacturer’s audit.
Risk-based approach
Although the FDA recognizes the term SOUP, the requirements are rather fuzzy:
“Therefore, we recommend that you explain the origin of the software and the circumstances surrounding the software documentation. Additionally, your Hazard Analysis should encompass the risks associated with the SOUP regarding missing or incomplete documentation or lack of documentation of prior testing. Nonetheless, the responsibility for adequate testing of the device and for providing appropriate documentation of software test plans and results remains with you.“
However, the risk-based approach is recognizable.
Determination of the Documentation Level (valid from August 2023)
In August 2023, the FDA published the new version of the guidance document “Off-the-shelf Software Use in Medical Devices.”
This comparison helps to compare the FDA’s guidance documents on OTS Software.
One significant change concerns the previous Level of Concern. The FDA is thus adapting the guidance to the changes from the FDA guidance “Content of Premarket Submissions for Device Software Functions” (2023) and no longer distinguishes between three classes but two. It also no longer refers to the Level of Concern but to the Basic or Enhanced “Documentation Level.” These Documentation Levels (like the Level of Concern) determine the software documentation to be provided for submission to the FDA. Unlike IEC 62304, however, this does not mean that activities in development can be dispensed with in principle, e.g., the “Basic Documentation Level”:
“During premarket review, FDA may request additional information, if needed, to evaluate the safety and effectiveness of the device.„
FDA guidance „Off-The-Shelf Software Use in Medical Devices“, 2023
The OTS is also no longer classified independently but inherits the “Documentation Level” of the medical device, as the example in Appendix B (3) illustrates:
“[…] since the device has an Enhanced Documentation Level, the OTS Software Documentation will follow the Enhanced Documentation Level in this guidance“
FDA guidance „Off-The-Shelf Software Use in Medical Devices“, 2023
Depending on the Documtenation Level, the FDA expects the following documentation:
| Documentation | Basic | Enhanced |
| Description of the OTS Software | X | X |
| Risk evaluation of the OTSS | X | X |
| Software testing | X | X |
| Ensuring the “Development Methodologies and Continued Maintenance” | – | X |
The last requirement for the “Enhanced Documentation Level” ultimately means that the development process and methods are known. This means that this software would still be OTS Software but not necessarily a SOUP in the sense of IEC 62304, as the life cycle records would have to be available.
As the Documentation Level applies to the entire medical device (“[…] the documentation level reflects the device as a whole“) and the OTS inherits the Documentation Level of the medical device, this means that many OTS will fall into the Enhanced Documentation Level.
Consider the typical safety architecture of critical systems consisting of a control unit and a monitoring unit. According to the FDA, the device as a whole would have an Enhanced Documentation Level. All OTS would have an Enhanced Documentation Level where, from the perspective of IEC 62304, the control unit might have been downgraded or assigned a different Level of Concern under the previous OTS guidance.
These Enhanced Documentation Level requirements cannot be met for many OTS Software. This means that manufacturers of medical devices face the same challenges as before with the “Major Level of Concern.” It is not yet entirely clear whether, with the change from “audit” to “review” of the OTS development documentation, the FDA is deliberately softening the requirement and thus approaching the manufacturers.
Fortunately, the new guidance also offers the possibility of justifying the use of OTS via risk management after measures, even if it is not possible to audit the development process and the methods used by the OTS supplier.
c) Comparison of the requirements
The definitions of the two terms are very similar, but there is the following regulatory difference:
- For the SOUP, the safety class has no direct influence on the approval or usability. In particular, it does not require a supplier audit under certain circumstances.
- This is the case with OTS.
In both cases, risks must be analyzed and assessed by SOUP or OTS.
Further differences are:
- The FDA uses a risk-based approach to scale claims to OTS. These requirements can go as far as banning OTS. IEC 62304 does not specify any concrete requirements; in particular, there is no dependence on the safety class.
- The FDA has a specific list of properties that must be documented for each OTS component. IEC 62304 is less specific (see Sections 5.3.3 and 5.3.4).
- The FDA does not allow proprietary software for which adequate records are not available to be treated as OTSS.
d) “Indirect” regulatory requirements for SOUP & OTS
Version control
Like all others, SOUPs must also be subject to version control. In contrast to the source code, however, the compiled code (e.g., the DLL or JAR file, the executable) is not checked into the version control system.
In addition, the software to be delivered, i.e., the output of the build process, is subject to configuration control – and not just the artifacts that serve as its input.
Post-market surveillance
As part of post-market surveillance and the post-production phase of risk management, manufacturers must actively track information that allows conclusions to be drawn about bugs or risks caused by SOUP. Sources of information include:
- Customer feedback (complaints, bug reports, observers).
- Messages from manufacturers, e.g., in the form of release notes or bug reports
- Reports from other manufacturers on problems with the SOUP, e.g., from the BfArM or the FDA’s MAUDE database
- Information on problems with IT security, e.g., in the NIST database
As with any potential problem, the manufacturer must analyze the problem and take appropriate action. These include:
- Replacement of the SOUP with the new version
- Replacement with own or other components
- Removal and, if necessary, deactivation of functionality
- Prohibition to continue using the device
- Instructions on how to handle the device or the error
One of our articles describes the regulatory requirements for IT security.
3. Practical tips for dealing with SOUP and OTS
a) Criteria for selecting SOUPs and OTSs
The following criteria will help you to select a SOUP manufacturer or SOUP:
- Can the SOUP manufacturer be audited? =>, e.g., a supplier audit of the development process and the maintenance process
- Does the SOUP offer the functionality we need? Does it fully meet our requirements?
- Can we provide the SOUP with the runtime conditions it requires, such as hardware, RAM, operating system, etc.?
- How often is the SOUP in use? => Estimate the probability of errors
- Does the manufacturer publish bug lists? => Input for the risk analysis
- Is technical documentation of the SOUP available, such as an architecture? Are there test reports?
- Are test results even available, as is the case with apache projects, for example?
- Is even the source code available?
- Are there reports from previous audits?
- Does the SOUP manufacturer have a QM system in place? => e.g., according to standards ISO 9001, ISO 15504, ISO 13485, etc.
- Is the SOUP already in use in other medical devices?
- How much does it cost?
- How good is the support? How quickly does it respond? At what times is it available?
Create a user value analysis with which you can weigh the individual criteria for your specific use case.
b) Dealing with SOUP or OTS in hardware components
How to deal with software that is already included in components that manufacturers obtain from third parties, e.g.
- software in a modem or GSM chip,
- software in a USB module,
- software in display controllers, or
- software in ethernet chips and other microcontrollers?
The question of whether software in hardware components is considered a SOUP is mainly posed by manufacturers who define all software in a medical device as the software system. The Johner Institute advises against this.
Define the software system as the entirety of the software within a processor or memory area.
There can, therefore, be several software systems in a medical device, at least one per PESS (Programmable Electrical Subsystem). You can find out why this should be divided up in the video training courses in the Medical Device University.
The Johner Institute recommends not treating this software as a SOUP for the following reasons:
- It is impossible for the manufacturer to understand which part of the functionality of purchased hardware is implemented in software. This means that the manufacturer cannot formulate any requirements for this software, as formulated by IEC 62304.
- This “embedded” software does not fall under the definition of SOUP.
- An auditor will probably not refer to this software but to the entire component. Do not make things unnecessarily complicated.
- You cannot and should not discuss and manage the risks that this software contains errors at the level of this software but at the level of the component or the system architecture.
c) Dealing with linkers
How do auditors deal with linkers? Unfortunately, there are different answers to this question:
One auditor thought that a linker would link software parts into the program for the compilation process. In this respect, this part of the software linked into the software should be considered SOUP.
This opinion is not shared by other auditors and the Johner Institute: A linker itself is not a SOUP. Rather, like the compiler, it is a process software. One could rather discuss whether the linker should, therefore, be validated.
A SOUP is, again, as a reminder,
“a software item that has already been developed and is generally available and that has not been developed to be integrated into the medical device, or software that has already been developed and for which adequate records of the development process are not available.”
IEC 62304
However, a linker does not create components, and what the linker creates was by no means pre-existing and generally available.
d) Be careful with the claim that a SOUP is “certified”
The question often arises: Wouldn’t it be better to use a certified SOUP? Some operating system manufacturers offer something like this (example).
It is always the objective to choose a manufacturer that develops software professionally. In principle, however, no SOUP manufacturer needs to observe the regulations on medical devices (e.g., the MDR or IEC 62304), as they are not placing them on the market.
The fact that there should be IEC 62304-certified devices seems questionable, as IEC 62304 is a process standard, not a product one. This means that you can only be certified as compliant with this standard’s (minor) requirements. However, this says nothing about the quality of the device.
This form of advertising or communication is, at the very least, misleading.
4. Conclusion and summary
In medical devices, the proportion of software that manufacturers no longer write themselves but instead adopt in the form of libraries, for example, is growing continuously. This makes it increasingly important for manufacturers to prove their devices’ conformity even if they use third-party software. The Log4J disaster has raised awareness of this problem.
IEC 62304 and the FDA are introducing the not entirely congruent concepts of SOUP and OTS Software. Manufacturers need to be aware of these concepts and the associated regulatory requirements to avoid difficulties with approvals and audits and, above all, problems with the safety of their devices.
The Johner Institute supports medical device manufacturers in developing software compliant with standards and legislation. We ensure that you achieve “approvals” for your devices quickly and reliably, avoid unnecessary effort, and develop safe medical devices.
Contact us if you would like to receive support, whether in creating or investigating the software file or pentesting the devices.
Change history
- 2023-11-15: Minor corrections, clarification for better comprehensibility
- 2023-10-30: In chapter 2.b) additions to the new 2023 guidance document added
- 2023-09-05: In chapter 2.b) subchapter on the new FDA guidance document added
- 2023-03-13: Article completely revised and updated and merged with the previous keyword article
- 2017-09-13: First version of the article
