Software in Medical Devices, by MD101 Consulting

Definitions

You will find the definitions of SOUP in IEC 62304 and Maintained software, Supported software, Required software in IEC 81001-5-1:

• SOUP: software of unknown provenance. Practically speaking, if you want to integrate some 3rd party sw in your medical device, that hasn't been developed with IEC 62304, that's SOUP,
• Maintained software: software item for which the manufacturer will assume the risk related to security,
• Supported software: software item for which the manufacturer will notify the customer regarding known risks related to security,
• Required software: software item for which the manufacturer will consider security-related risks known before release of the health software.

Required software

The case of required software is easy to manage with medical device software. The definition tells us that the manufacturer will consider security-related risks known before release of the health software. Thus, not after release of the health software.
That contradicts ISO 14971 requirement on post-production activities and more generally requirements on post-market surveillance of regulations.
Thus, that's not possible to have required software in medical devices.
That's possible to have required software in health software not qualified as medical devices, but this is another story outside the scope of this blog.

Supported software

With supported software, the manufacturer [notifies] the customer regarding known risks related to security. That's a way to manage risks, so that's possible to do so with ISO 14971 and MD regulations. Provided that risks are acceptable, doing it that way.
Practically speaking, if we only notify about risks, that means that supported software isn't integrated into the medical device. If it were integrated in the medical device, we'd not only notify but also provide the customer with a new version of our software.

Maintained software

With maintained software, the manufacturer [assumes] the risk related to security. That's the only way to manage risks when some software is integrated into the medical device.
We retrieve here a similarity between our plain old SOUP and maintained software! With SOUP integrated in our medical device software, we have to assume the risks in the design process (IEC 62304 clause 7.1) and in the maintenance process (IEC 62304 clause 6.1).
Practically speaking, when some issue (bug or vulnerability) is found in a SOUP in design, we fix it. When it is found in maintenance, we fix it (usually upgrading SOUP version and rebuilding software) and we release a new version of our software.

Maintained software could be expanded to software not integrated into the medical device, thus not SOUP. That's a possibility. We could sum up that by SOUP ≤ Maintained software.
But, if we want to keep things simple, we can consider that the two concepts are applicable to the same set. We could sum up that by SOUP = Maintained software.

Some examples

The sketch of theory above deserves some examples.

Mobile app or PC application

All 3rd party libraries (not developed and maintained according to IEC 62304) linked to these kind of apps at build time are SOUP and maintained software.
The operating system (PC platform or mobile platform) is a supported software.
We cannot place the OS in required software. If we become aware of some unacceptable risk coming from the OS, we would notify the customer.
Conversely, the operating system is not maintained software. We don't update it, we only notify the customer to update their OS.

Software embedded in hardware medical device

Once again, all 3rd party libraries (not developed and maintained according to IEC 62304) linked to our embedded binary at build time are SOUP and maintained software.
The operating system (PC platform or mobile platform) is also a maintained software. If we become aware of some unacceptable risk coming from the OS, we would provide the customer with a new version of our embedded software (logistics can be tricky, but that doesn't affect the concept) with a new OS version.

Web application - front

All 3rd party dependencies (not developed and maintained according to IEC 62304) pulled by our code are SOUP.
The operating system (PC platform or mobile platform) and the browser are supported software. We cannot place them in required software. If we become aware of some unacceptable risk coming from the OS or the browser, we would notify the customer.

Web application - back-end, and cloud software

All 3rd party dependencies (not developed and maintained according to IEC 62304) pulled by our code are SOUP.
Here, we have a question about where we draw the line between SOUP and not SOUP. See the article When web meets SOUP about the possible answers on SOUP, OTSS, which is not SOUP, and infrastructure.
We have to place the OTSS and underlying infrastructure (be it containerization or virtualization) in maintained software. We cannot place them neither in required software, nor in supported software. If we become aware of some unacceptable risk coming from one of these, we would upgrade the infrastructure version.

Two software devices by two different manufacturers

Let's assume we develop and maintain a medical device software, which integrates another medical device software developed by another manufacturer.
Here the 3rd party software is a medical device (we assume that the manufacturer did their homework with IEC 62304), thus not a SOUP. If that other manufacturer becomes aware of some issue, they will notify us and provide us with a software update (as per IEC 62304 clause 6.1). Likewise we will update our software with this dependency update. Thus, that other medical device software is for us a maintained software.
That's a peculiar case where maintained software ≠ SOUP. It is shown in this article to demonstrate that maintained software and SOUP are different concepts. But, to keep it simple, in the vast majority of cases, maintained software = SOUP.

Conclusion

One interesting consequence of new definitions brought by IEC 81001-5-1 is to help us understanding wether to place 3rd party software in SOUP or not in SOUP. It's frequent that design teams hesitate to place an OS in SOUP. The concepts of maintained software and supported software, are not equivalent to SOUP (the word incorporated appears in SOUP definition, not in required / supported / maintained software definitions). But, if we simplify by assuming that maintained software = SOUP, then we have criteria to place OS, and some other borderline cases, in SOUP or not.