SOUP – Software of Unknown Provenance
SOUP is an acronym for “Software of Unknown Provenance”. The IEC 62304 defines a SOUP as follows:
„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 3.29
Please mind, that the term SOUP is not quite equivalent to the term OTS of the FDA.
SOUPs, COTS, OTS: Differences and Similarities of Terms
It’s exactly these three terms that confuse many manufacturers of medical devices that contain software or standalone software, namely COTS, OTS, and SOUP. These terms are not entirely congruent.
- Off-The-Shelf Software (OTS Software): A generally available software component, used by a medical device manufacturer for which the manufacturer cannot claim complete software life cycle control (Definition from the FDA).
- Commercial Off-The-Shelf Software (COTS Software): OTS software that comes from a commercial supplier.
- Software of Unknown Provenance (SOUP Software): SOFTWARE COMPONENT that is already developed and widely available, and that has not been developed, to be integrated into the MEDICAL DEVICE (also known as “Off-The-Shelf Software”), or previously developed software for which adequate records of the development process are not available.
There are software components that are SOUP but not OTS and vice versa.
- Software that is SOUP but not OTS:
Software that is not generally available such as legacy components previously developed by the manufacturer without following and documenting software life cycle processes
- Software that is OTS but not SOUP:
Software that is generally available but not part of the medical device such as an operating system in the software controlling a sterilization process
- Software that is OTS and SOUP:
Software that is generally available and a component of a medical device such as a library or an operating system embedded in a medical device
OTS / SOUP Requirements
The FDA, which defines the term OTS(S), and IEC 62304, from which the term SOUP originates, also have different approaches when it comes to dealing with these components. These differences include:
- The FDA uses a “risk-based” approach (but then falls back on the Level of Concern) to scale the demands of OTS. These requirements may go as far as to ban the OTS. The IEC 62304 does not mention any concrete demands, there is no dependence on the safety class.
- The FDA has a specific list of properties that must be documented for each OTS component. The IEC 62304 is less specific (see chapter 5.3.3 and 5.3.4)
- The FDA knows a supplier audit for critical software in which the software lifecycle processes should be assessed. If this is impossible – which is expected in most COTS and in (almost) all OTSS manufacturers that are not COTS, this might be the case: – the OTS software cannot be used.
- The FDA does not allow its own software, for which no adequate records are available, to be treated as OTS.
Do you need assistance in evaluating the COT, OTS, or SOUP software to comply with certain demands of European and US regulations? Please contact us. We offer complimentary support.
Software in Hardware Components
How do you deal with software that has already included components, that manufacturers get from third parties?
Components such as:
- Software in a modem or GSM chip
- Software in a USB device
- Software in display controllers
- Software in Ethernet chips and other microcontrollers
Johner Institute does not recommend treating this software as SOUP, for the following reasons:
- For the manufacturer, it is not possible to trace whether the functionality of a purchased component is realized in hardware or software. Thus, the manufacturer cannot specify any software requirements as demanded by IEC 62304.
- These “embedded” software do not fall under the definition of SOUP.
- An auditor is probably more interested in how you verified component requirements have been met rather than the actual software requirements. Don’t make it unnecessarily complicated for this matter.
- The risk that the software contains errors, can be but should not be discussed and controlled at the level of the software, but at the level of the component respectively system architecture.
The question of whether software within hardware components is a SOUP is a question we get a lot from manufacturers who define the totality of all software in a medical device as the software system. But we advise against it. You should define a software system as the totality of software within a processor- or storage system.
In medical devices, there can be several software systems: At least one per PESS (programmable electrical subsystem). Why should you want to split it, we reveal, among other things, in the e-learning library.
Criteria for Selecting SOUPs
The following criteria may be relevant when selecting a SOUP manufacturer or a SOUP:
- Can you audit the SOUP manufacturers? (E.g., a supplier audit of the development process and the maintenance process)
- Does the SOUP provide the functionality you need? How does the SOUP satisfy your requirements completely?
- Are you capable of providing the necessary run-time environment for the SOUP, such as hardware, RAM, operating system, etc.?
- How often is this SOUP in use? => Estimate the error probability
- Has the manufacturer published a bug-lists? => Input for risk analysis
- Is technical documentation of SOUP available? For example, architecture? Reviews?
- Are there any test results published, such as in the Apache projects?
- Is the source code even available?
- Are there any reports of previous audits?
- Do the SOUP manufacturers have a quality management system? E.g. according to standards like ISO 9001, ISO 15504, ISO 13485, etc.
- Is the SOUP already used in other medical devices?
- What does the SOUP cost?
- How good is the support? How quickly does the supplier respond? What are the business hours?
Create a value benefit analysis and weigh the criteria specified for your situation and application.
Regulatory Requirements and SOUPs
Demands of the IEC 62304
The IEC 62304 treats SOUP as software components. The manufacturer must specify the requirements for the SOUP and test their performance (like for any other component).
In addition, to “normal” components, manufacturers must also specify the preconditions with respect to resources (RAM, CPU, …) or to the operating system.
Documentation of SOUPs
In order to implement the requirements of the IEC 62304, the Johner Institute recommends that the SOUPs are documented (e.g. in tabular form) based on the following parameters:
- Name of SOUP
- Version of SOUP
- SOUP manufacturer
- SOUP requirements (possibly a reference to a separate document or software architecture)
- Requirements/prerequisites for using the SOUP e.g. memory, operating system, etc.
- A website with bug reports and release notes
Are there IEC 62304 certified SOUPs?
The question often arises: Would it not be better to take a certified SOUP? There would be, for example, manufacturers of operating systems that would offer something like this.
A SOUP manufacturer must not comply with any medical device regulation, as they are not a manufacturer placing medical devices into the market. Of course, it would make sense to select a SOUP manufacturer, from which one can assume that he is developing software professionally.
It is questionable that there are products marketed as IEC 62304 compliant because the IEC 62304 is a process standard and not a product standard. This means that one can only get certified if one remains compliant with the standard. But this doesn’t say anything about the quality of the product.
We even consider this form of advertising/communication to be misleading.