Linux for medical devices is a valuable solution for OEMs (Original Equipment Manufacturers), but it’s important to understand the development of sources and reliability of the chosen operating system so that SOUP applications will be compliant with the FDA IEC 62304 documentation.
OEMs might have come across the terms SOUP when searching for the right operating system and provider to build medical devices. Although there are similarities, there are also several differences. Here is a basic breakdown of all three:
- OTS: Software available to OEMs but the OEM is not in control of the software development lifecycle
- COTS: Commercially supplied software
- SOUP: Software developed by a third party, but the OEM does not have access to adequate records of the software development lifecycle
SOUP – Software of Unknown Provenance
SOUP likely brings the most risk to the OEM. The software development lifecycle (SDLC) is hidden from the OEM’s quality control and maintenance. Regardless, the FDA requires OEMs to take a risk-based approach to the development of medical equipment. With critical medical devices, OEMs cannot use software where the SDLC cannot be documented and assessed. This serves as an obstacle to OEMs that do not develop their own medical software for devices, but it can be overcome with a provider like L4B.
IEC 62304 requires that OEM assigns a safety class (Class A, Class B, or Class C) to each software system.
The class assignments are based on the impact that (the failure of) the system may have:
- Class A: No injury or damage to health is possible
- Class B: Non-serious injury is possible
- Class C: Death or serious injury is possible
IEC 62304 impacts the use of SOUP as some of the medical device OEMs can rely on the use of COTS (Commercial Off-the-Shelf Software) operating systems based on Linux.
OEMs can still use SOUP with Linux for medical devices, but they need a provider that can document the following in case of an audit:
- Software requirements to create applications and device
- The architecture used to host and support applications
- Risk analysis to identify any potential vulnerabilities and mitigation plans
- Cybersecurity policies in place to test devices and applications for any vulnerabilities
- Procedures used to maintain the applications
It is probably fair to summarise the approach in IEC 62304 as one of segregation and containment to avoid the re-work of COTS OS provided by a supplier like L4B.
Why Work with Linux for Medical Devices?
SOUP-compliant Linux applications for medical devices have several benefits for OEMs. Using software from third-party providers also has its advantages if you have the resources in place to audit and document the SDLC. A solution provider like L4B can help to facilitate the development of medical device-compliant solutions that can be fully integrated with OEM development projects for medical devices both critical and non-critical.
Partnering with L4B for Healthcare Device OEMs
Because Linux is customizable, flexible, and capable of supporting critical and non-critical medical devices, it’s the obvious choice for OEMs. L4B helps OEMs oversee and handle the development, security, and maintenance of medical device software to ensure compliance with FDA standards and works with any customizations and embedded Linux applications necessary to power a variety of medical devices.
At L4B we build secure Linux operating systems that comply with OEM requirements and industry standards. We create a future-proof solution built upon the Linux operating system with customizable features that support an improved user experience.