Linux is the operating system (OS) of choice for a wide range of medical devices, from vital sign monitors to hospital bedside 'infotainment' systems to complex imaging equipment. Yet not all Linux implementations are alike. Because patients' lives may be in the balance, software used in medical devices must meet stringent regulatory guidelines to ensure that it will perform as promised.
Trying to cobble together solutions from pure Linux without commercial support puts the burdens of testing, validation, documentation and compliance on the device manufacturers and software developers - an onerous, time consuming and complex process that can turn 'free' Linux into a very costly proposition.
There are, of course, commercial vendors of Linux who provide value-added stabilised versions of the open-source software, along with board support packages. Service, support and documentation levels, however, vary widely among them with some chip vendors providing software, but no real post-sales support.
The Advantages and Challenges of Open Source
Linux appears in various medical devices and as a general-purpose OS, it has all the advantages of open source. Free distributions are available and it can be modified and redistributed under the GNU General Public License (GPL).
Linux has been widely adopted and scrutinised by many experienced developers. Linux is also supported by all major hardware manufacturers and runs on virtually any processor. It also has a large ecosystem of board and software providers that use proven toolchains and application programming interfaces (APIs), and has exceptional graphics support, which is important for clear and readable device screens. The innovation and maturity of Linux has made it a mainstay in medical device development, but it also poses many challenges.
Medical devices marketed in the US are regulated by the Center for Device and Radiological Health (CDRH), a branch of the Food and Drug Administration (FDA). The FDA is recognized globally as providing the leading guidance for medical devices, which European manufacturers need to follow to sell product in the US. Whether or not the device maker is claiming compliance to IEC 62304 for medical device software, it must follow several FDA guidance documents.
An OS may be treated as Software of Unknown Provenance (SOUP) or off-the-shelf (OTS) software. The FDA also makes it clear that the burden of ensuring safe and reliable performance does not end with product launch. So, when evaluating operating systems, it is necessary to plan for bug fixes and security updates for the entire product lifecycle.
Medical devices and their components must undergo a hazard analysis, typically performed by the device manufacturer - not to try and predict a likelihood of failure, but to analyse the effect on the patient in the event of failure. The FDA sets out full details in its "Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices". Choosing a commercial Linux vendor that can help a device maker satisfy these requirements is essential.
Cybersecurity: Assuring the Safety of Networked Devices
If Linux based medical device are being used in networks, then the FDA's guidance on cybersecurity applies: "Guidance for Industry - Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software." In basic terms, it states that networks are vulnerable to hacking and the manufacturer must have a software-maintenance plan to deal with networking vulnerabilities, specifying that formal business relationships should be maintained with OTS software vendors to ensure timely receipt of information concerning quality problems and recommended corrective and preventive actions.
If a commercial Linux vendor does not enter into formal support relationships with its customers or does not have an on-going cybersecurity plan in place, the burden falls upon the device manufacturer to monitor the Linux community, identify vulnerabilities and take necessary action - this requires a dedicated and highly specialised team.
If security functionality is not a core competency of the device manufacturer, it is critical to have an OS vendor to assist with the configuration of the security components of the network stack. Manufacturers need to be especially vigilant in the face of growing malware attacks such as the Stuxnet worm.
Device manufacturers have to decide what level of security is appropriate. In devices where prevention of any kind of breach is mission critical, manufacturers may want the added assurance of security functionality built into the OS.
Support for Implementation
There are also practical concerns of building a device that is reliable in performance and successful in meeting market needs:
• High-quality test tools are crucial and being able to show validation artifacts for those tools is also a requirement. Using an automated testing system that automatically creates the documentation of the testing performed may deliver time-to-market advantages over manual systems, while reducing the likelihood of human error and increasing confidence in the results.
• It is also essential to comply with the requirements of the GPL and other applicable open-source licenses.
• Board Support Packages (BSPs) are essential in implementing embedded operating systems, including Linux. Few manufacturers are equipped to develop BSPs in-house and creating customised BSPs can be extremely costly.
In multicore system development, simplifying the design while still gaining the performance advantages of multiple processors and operating systems presents new challenges. Developers using advanced analysis tools in a Linux environment may encounter many new obstacles in a multicore or multithreaded environment. Using tools from a commercial OS provider reduces burden for developers.
Increasingly developers are using embedded hypervisors to leverage virtualisation and enable multiple operating systems to run on a single board. An embedded hypervisor can configure the multicore environment, boot several cores, allocate hardware resources, provide access to and protect memory (for safety and security), and monitor system health.
To successfully manage all these regulatory, safety, security, design and implementation issues, it is important to have a commercial OTS Linux partner with the resources, expertise and long-term support to help device makers deliver effective products that will not only win regulatory approval, but also perform reliably for many years.
