Quality Considerations of Open-Source Software for Medical Devices

Traditionally, software intended to run on a medical device was expected to be written by companies well versed in writing software that can be determined to be safe using processes that have long held sway in the medical device industry such as ISO 62304 (Medical Device Software – Software Life Cycle Practices), ISO 13485 (Medical Devices – Quality Management Systems – Requirements for Regulatory Purposes), and many others. Even if some of the software was acquired by a supplier, it was expected to be created under these same rules, with limited exceptions for general-purpose software such as a Real-Time Operating System (RTOS), and even then, it was expected that the software be certified to a standard like ISO 62304.

This status-quo was acceptable for many years, but modern requirements have made it more and more difficult for these device manufacturers to live up to these rigorous quality and safety standards:

• Medical devices now have connectivity requirements that more resemble computers or cell phones than a traditional medical device. While the market for home-medical devices started this trend, it now applies to almost all therapeutic settings.
• The graphical and user-interface requirements of these devices have become significantly more complex, requiring graphics that would be more at-home on a smart phone or tablet than the traditional wavy lines that are associated with medical devices.
• This connectivity leads to security requirements that are extremely rigorous. Regulations such as HIPPA in the United States or GDPR in Europe require connected medical devices to meet security requirements that are just as strong as those used in the financial industry.

Worse yet for the device manufacturer, these are now mostly “table stakes”, which are minimum requirements for marketing a new device, while requiring extensive and expensive expertise to develop. This cost and time must be considered even before developing the innovative therapeutic treatments that these devices support.

These trends have led many device manufacturers to look for better solutions to these foundational capabilities that allows them to have solid solutions for these commercial and regulatory requirements and allow them to focus their internal efforts towards the actual goals of the device. These manufacturers first looked to closed-source, 3^rd party solutions that were pre-certified for medical devices. There are cases where such a solution is fine for all or part of a medical device; for example, for the life-critical parts of an infusion pump, it might make sense to use a pre-certified RTOS (such as Siemens Embedded’s Nucleus™ SafetyCert™ Real-time Operating System) to control the part of the logic that determines how much medicine to dispense at a given time. However, the landscape for connectivity, security and graphics is moving very quickly; more quickly than even third-party safety software specialists can keep up, meaning if your device requires these modern features, you’ll need to wait a long time to get them through this route.

All of this leads to device manufactures looking at Open-Source Software (OSS) such as Linux and a universe of capabilities that run with it to help them build these capabilities into their device. Unfortunately, none of this software is certified to medical standards, and is not implemented, reviewed, or tested with these standards in mind. Additionally, this software is quite complex, and while your engineers might understand the capabilities that they provide, only an expert would fully understand how they are implemented. How is a medical device manufacturer able to traverse this potential minefield and be able to leverage the capabilities they need while being able to achieve regulatory approval for their device?

IEC 62304 defines a concept named SOUP (Software of Unknown Provenance), that allows a medical device manufacturer to use uncertified software on a device as long as they fully consider the risks of using the SOUP on their device and mitigate them appropriately based on the kinds of risks that a failure of the SOUP might expose a patient to. Beyond that, the manufacturer is required to consider the possibility that future issues might be identified in their SOUP and how they might manage these as-yet-unknown failures (NOTE that this is also required for management of security flaws in software that may not be known at the time of the product’s release). As a result, being able to understand both the quality of the SOUP being used up-front as well as understanding how that will be maintained must be considered before it is used.  

Siemens Embedded has many facilities to help medical device manufactures to wade through these SOUP requirements for OSS, including professional product development and verification, services, security, and defect monitoring and more that helps fulfil the requirements to use OSS as SOUP in a device. Most recently we have augmented these offerings with a package we call the Linux® Quality Package to further answer regulator’s questions about the kinds of open-source software that is being used. Some of the information provided in the Linux Quality Package are:

• A history of Linux and other important OSS modules, and how they are developed and maintained by their communities. This helps to explain why these modules are of high quality even if they are not certified to a medical safety or security standard.
• A mapping of both the community and Siemens Embedded practices to these standards such as ISO 13485 and IEC 62304.
• A security design guide mapping security best practices to the capabilities of Linux and major open-source modules such as OpenSSL.
• Test Plans and results for our Sokol™ Linux products

This information can be combined with Siemens Embedded’s expertise, professional services, and post-release support for security issues such as those that through the Common Vulnerabilities and Exposures (CVE) process to streamline the justification for using Linux as SOUP in medical devices, which facilitates the risk management requirements of using this software, which streamlines this part of regulatory approval. All of which allows the manufacturer to focus on the capabilities of the devices they’re working towards instead of those foundational capabilities that are required.

Download this recent white paper Using Linux in Medical