Quality and Open-Source Software in Medical Devices

Many companies are using Open-Source Software (OSS) such as Linux in devices across every imaginable industry. Linux (and packages that run with it) are even being used quite heavily in systems where safety is a foremost concern, whether that system is an industrial robot, advanced safety functionality in automobiles, or other areas where failures can cause harm to humans, including loss of life.

Nowhere is this trend more evident than in the Medical Device industry. Modern medical devices require the connectivity, graphics, and a programming model understood by their engineers but still have stringent safety and security considerations. These drivers are leading many of these manufacturers to consider Linux as a foundational piece of their devices, and more are doing so all the time.

At the same time, the FDA and equivalent agencies around the globe such as the PMDA in Japan, are asking device developers to more stringently safeguard safety and security in their devices. Since OSS is not developed to medical software standards such as those outlined in IEC 62304, it can be difficult to understand the overall quality of these packages as required by the agencies, and it can also be difficult to manage other requirements such as maintaining security and safety by understanding the risks and updates to these packages.

Today, Siemens has announced the Quality Package for Embedded Linux, which is now available for both the Siemens Embedded’s Linux distributions, Sokol FLEX OS and Sokol OMNI OS. While the press release can be found here, I wanted to go into a little detail about what is included in the quality package, and how it helps our customers achieve regulatory approval for devices which include Linux.

As a software provider to medical device creators, we look towards the guidance of the IEC 62304 standard – “Medical device software – Software Life Cycle Processes”, as well as guidance from the FDA when we work with customers interested in using our software in their devices. According to the language in IEC 62304, any OSS module is SOUP (Software of Unknown Provenance), which is any software not developed to the requirements of IEC 62304. The contents of the quality package are designed to help meet these requirements.

For a SOUP component to be used in a medical device, the manufacturer must perform several activities above and beyond determining that the SOUP does what is necessary and can run on their device:

  • Understand how a failure on a SOUP module might impact the device (and how to maintain safety if it does)
  • Evaluate all known issues in the SOUP they are using, focusing on issues that might cause failures in the device
  • Understand how they’re going to evaluate and implement updates to the SOUP modules as bugs are fixed and security issues managed

Beyond this, the device manufacturer also needs to understand the communities around the OSS modules that they are using. Is the community mature, fixing issues as they are found with best-in-class processes guarding changes to the module? Or is it part of somebody’s PhD dissertation from a decade ago with no obvious maintenance which might provide interesting functionality, but with no understanding of the kinds of underlying issues it might have?

This is where the quality package can help our customers through providing guidance on these (and other) topics. For example, the quality package provides historical information, practices, etc. of some of the most important OSS modules you might use in a medical device such as the Linux kernel, OpenSSL, and several others, which provides evidence of the underlying quality of these modules. It also provides evidence of the testing that Siemens Embedded performs on these modules, which includes both test harnesses developed by the Open-Source communities, as well as additional testing influenced by our expertise in working with customers employing these modules in their devices.

Additionally, it maps both Siemens Embedded’s and the various Open-Source communities processes to important medical standards such as ISO 13485 (Medical Devices – Quality Management Systems), and IEC 62304. We will shortly be adding mappings to additional standards/FDA guidance; most importantly being recently new FDA guidance around the quality considerations around cybersecurity in medical devices, as well as updated guidance on the overall requirements on pre-market submissions for Software in a Medical Device (SiMD). We also discuss with our customers their experience using this information as part of their submission processes and improve the package based on their feedback.

The contents of the quality package can be paired with Embedded Services from Siemens Embedded, allowing the information about your OSS usage to be tied to the specific OSS packages you’re using in terms of verification procedures and results, as well as monitoring of security vulnerabilities and helping to both manage and understand the defect lists from those Open-Source communities that are important to your device (and required by IEC 62304). While the quality package cannot answer if OSS is appropriate for your device, it provides significant information for a customer to answer those questions for themselves, and if they do decide to use OSS in their devices can help them justify that use to the satisfaction of their national authorities.

Want to stay up to date on news from Siemens Digital Industries Software? Click here to choose content that's right for you

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/embedded-software/2022/12/01/quality-and-open-source-software-in-medical-devices/