SBOM, CBOM, OTS, COTS, SOUP The complete guide

There are lot's of names used in different regulations and standards to describe software components not developed according to your own IEC 62304 inspired processes.

This article explains what these terms mean, how the work you're doing is related to them & what you need to do to ensure efficiency.

We start firstly with the most commonly used terms that occur in regulations about medical device related software, and some abbreviations that are very often used in this context. The goal is to help you understand what they mean, where they come from and what are the differences / overlaps.

Most important terms for Software as Medical Device

Note: all terms are explained according to their definitions in the 62304:2006 + Amd1:2015, unless noticed otherwise.

Health Software

A Software System that is intended to be used specifically for managing, maintaining, or improving health of individual persons, or the delivery of care, or which has been developed for the purpose of being incorporated into a Medical Device. Health Software fully includes what is considered Software as a Medical Device (SaMD). 

Legacy Software / Legacy Device

In the terms of any regulation for medical devices, this term "Legacy" refers to products that were placed on the market before the date of publication of the regulation for which the manufacturer of that product seeks conformance retrospectively. However, this is only the case as long as the software or device have not been changed significantly.

Medical Device Software

A Software System that has been developed for the purpose of being incorporated into a medical device (SiMD), or is developed to be Software as a medical device (SaMD).

Software Item

Software Item is any identifiable part of a computer program, i.e. source code, object code, control code, control data, or a collection of these items. It becomes an "item" by the definition of the components that make up the software architecture, and software documentation, may it be for development or testing tasks, or to allow identification of software components for risk analysis and risk control documentation. "Software Item" is the main term that covers everything which is not the final software product itself, but a sub-part of it. Software Items are subject to the "Configuration Management process" that defines how these items are named and versioned to allow their identification throughout the product lifecycle.

Software System

This is the integrated collection of Software Items organized to accomplish a specific function or set of functions.

For Software as Medical Device, the Software System provides the Intended Use.

Software Unit

The software unit is any Software Item that is not subdivided into other items. Even though there may be software-specific components that make up that unit, like libraries, software functions or classes (any language dependent coding objects), the Software Units in the scope of the IEC 62304 can be seen as the smallest possible "black boxes" of the product architecture. According to the risk analysis regarding safety for system, patient, user and for cybersecurity, the Software Units are determined by the need for investigating the code structure and functional relations of the code to ensure proper risk control. That is why, the "granularity" of the software is defined by the software manufacturer.

A Software System is composed by one or more Software Items, which can be decomposed into one or more Software Items, which can be one or more Software Units, depending on the need to evaluate the composition of a Software Item during the product lifecycle. 

Software Units are the smallest objects which can and will be tested separately. Which tests need to be done separately is defined by risk management and the software development and software maintenance process definitions and activities.

The definition of the Software Items and the Software Units is part of the development activity "Detailled Design" according to the IEC 62304.

Software Units like other Software Items need to be covered by the Configuration Management Process to ensure their unique identification and the documentation of their relationships and compatibility with each other and other product components. Examples are shared software code objects like libraries or files, code branches, packages, builds, installations, archives, up to software products. The latter is the case for software objects which are used via interfaces, or make up functional software units that are used as-is.

Most important abbreviations

SOUP: Software Of Unknown Provenance

This terms comes with IEC 62304. The standard says, SOUP is generally available and has not been developed for the purpose to be incorporated into the Software System that makes up the medical device. This also implies, that no documentation is available according to the software design process of the current software manufacturer. SOUP can be third party software as well as previously developed (legacy) software which is not documented as SaMD independent of the manufacturing company or team.

A SOUP Software usually is also its own Software Unit. To consider a large functional software object as-is without evaluation of its components is the reason for defining it as "SOUP". SOUP needs to be validated as black box, and if SOUP shall be used with another software item, the interfaces with the SOUP software must be evaluated for their intended functionality and potential risks that are related with the use of that SOUP, or with that SOUP itself.

SOUP can be OTS. There is SOUP that is no OTS - this is the case when the SOUP has been developed by the same manufacturer, or for any other software which is not commonly available.

OTS: Off-The-Shelf software

In FDA guidelines, we often this term instead of "SOUP"- it means software which is used as-is, independent of the software origin from any supplier or software vendor. Both terms, OTS and SOUP, are covering software which was not developed to become part of the intended medical device software system. That is why no design process documentation according to the manufacturers processes is available. OTS however is any software that was not developed to be used with the intended medical device software.

OTS can be SOUP. However, there is a lot of commonly available software that is not intended to become part of any medical device - this is however also considered as OTS.

Since OTS can also be software that is not used in the medical device, it can be software that is used in the process to create the medical device software. In that case, OTS is equipment in the software design or maintainance process and needs to be validated according to the relevant processes for Computer System Validation.

FDA has given a guideline how to manage OTS and COTS in medical devices which you can learn more about here: Off-The-Shelf Software Use in Medical Devices

COTS: Commercial Of-The-Shelf software

Following the FDA guideline on OTS software in medical devices (Off-The-Shelf Software Use in Medical Devices), COTS are all software products that are available by commercial suppliers. Usually, for these products, documentation or legal responsibilities can be identified.

Common considerations for SOUP, OTS and COTS:

For all software items which are part of the medical device, independent from their origin, the requirements to function, performance and safety need to be documented and validated. This includes respective tests of SOUP, OTS and COTS software items in the use content of the medical device (software) system. Also, the requirements of SOUP, OTS and COTS to hardware components need to be evaluated for the final medical device product.

SOUP, OTS and COTS must be managed in the configuration process, too, to ensure proper identification and compatibility relations.

OTS and COTS may be subject to tools and equipment validation, depending on their use in the product lifecycle process.

For SOUP, OTS and COTS risk management is necessary, especially with regards to cybersecurity, and Artificial intelligence/machine learning aspects.

For SOUP (in the scope of IEC 62304), the risk classification according to the software system in which the SOUP is used needs to be considered, and the validation accordingly. For risk class "C", the detailled design of the software is required, which is a challenge for using a SOUP as main functional unit of a class C software system.

For OTS in the scope of FDA, the level of concern needs to be estimated. For major level of concern after risk mitigation activities, FDA requires an audit of the manufacturer which usually is not possible. This implies that using OTS in a software system of major level of concerns after risk mitigation should not be considered.

... and more to come:

there are so many more challenging terms and abbreviations in the medical device software area. We want to let you time to digest the basic terminology now regarding the main terms about software as or in medical devices, and perhaps see how you are using them in your process descriptions, and to align understanding of these terms in your teams.

And then, we have more articles - the next one on terms around "Cybersecurity".