Medical device manufacturers operate in a challenging environment filled with stringent regulatory requirements and industry pressures. With a rise in mainstream competitors from the consumer electronics space and an uptake of touch-screen interfaces and wireless connectivity, medical device manufacturers must develop increasingly complex devices in timelines that are more typical of consumer-grade electronics, but difficult to meet in a regulated industry.
So, how can the lives of medical device developers be simplified? Let’s start with a look at the software integration process.
You begin by building the software architecture for your medical device. You’ve locked in on an operating system (OS), you have a good idea about the cybersecurity requirements, and you’ve completed the safety design. So you purchase a reference hardware board, download an evaluation copy of the OS you have chosen, and begin preliminary proof-of-concept benchmarks. Only, the OS doesn’t have the drivers for the Wi-Fi device you selected. Or the version of the OS doesn’t line up with the version of the Wi-Fi driver. Or you’re restricted to a specific Bluetooth hardware module, as it supports the profile that you require for your medical device, but your hardware platform does not support that module. What should be a simple integration of OS, device drivers, and hardware modules instead becomes a major amount of work. And you still need to build in a hazard and risk analysis, a failure analysis, a safety case. And you haven’t even begun to code your app.
Clearly, the effort of assembling all of the underlying software components for a medical device can be as sizeable, and as fraught with risk, as the actual development of your specific application. The number of technology suppliers that you, the developer, must coordinate with in order to build complete functionality is a major challenge. (See Figure 1)
So what can help alleviate some of this pain? To begin with, the choice of OS can improve this whole (square peg, round hole) process. Furthermore, the right OS can be an even bigger boon to compliance validation than to the overall development/test cycle, which is just a small component of the overall product delivery cycle. In other words, the compliance efforts for your new device can take more time than actual development. So, while it’s important to reduce the time for coding, testing, and building, it’s just as important to determine how the compliance process can be made easier, faster, and cheaper. When evaluating an OS, you need to examine how it can help or hinder your product development and certification process. (See Figure 2)
When selecting an OS, the fundamental choice comes down to open source or commercial-off-the-shelf (COTS). But before we go into detail on OS selection, we must introduce the medical compliance standard known as IEC 62304. It has significant bearing on the choice of OS.
IEC 62304 is a standard that has been endorsed under medical device-related directives by the FDA in the US and by the Directorate-General for Health and Consumers in the EU, enabling manufacturers to follow good development practices and to produce high-quality software for the medical community. IEC 62304 forms an important part of the OS discussion.
Agencies, such as the FDA, evaluate devices as a whole and not their discrete parts, so it is to a manufacturer’s advantage to use an OS that has a history of use in devices that comply with regulatory requirements. Also, using an OS that has already been proven to comply with a design standard, such as IEC 62304, can significantly reduce the effort, cost, and time to achieve certification.
IEC 62304 uses phraseology such as Software Of Unknown Provenance, or SOUP, which is software that a manufacturer uses in a medical device but has not explicitly developed for that device. IEC 62304 assumes that commercial or open source software will be used and it offers two definitions of SOUP, which can be software not developed for a medical device or that has unavailable or inadequate records of its development processes. IEC 62304 does not prohibit using SOUP in a medical device and, in fact, several clauses in the standard make the assumption that SOUP will be used. So, then, the question isn’t whether we’re allowed to use COTS software or SOUP in medical device software, but how we decide whether a particular COTS or SOUP item is appropriate for the medical device in question, and how we validate whether the item supports the functional safety requirements for the device. (See Figure 3)
The difficulty with using open source in functionally safe systems like a medical device is that the processes for open source development are neither clearly defined nor well documented. This is precisely what concerns IEC 62304 compliance. With open source, you typically don’t know how the software was designed, coded, or verified; attempting to validate functional safety claims without this knowledge can be an onerous undertaking.
IEC 62304 requires that all dead code, or code not directly related to the functionality of the medical device, be removed. For an open source OS, this requires extensive examination of the source code and implementation. Even if the dead code can be extracted without disrupting the confidence from use derived from years of active service of this software, IEC 62304 also requires the device manufacturer to maintain the code for as long at the device is in service—meaning that the development team needs to monitor and examine all patches to the open source project to determine if the patches are relevant to the medical device. And, if the patches are relevant, the patches must then be ported to the modified source tree, which has all this dead code removed.
IEC 62304 accounts for the inclusion of off-the-shelf components, like the OS. It’s not expected that the device manufacturer also be an OS company.
If the ultimate goal of a medical device manufacturer is to get the device certified, then a COTS OS offers the path of least resistance. But remember, all operating systems are not created equal. To be truly appropriate for being used in medical devices, the OS vendor’s software must have a well-documented quality management system. And at some point, the software must undergo a complete fault-tree analysis. This will be difficult to do on behalf of the vendor because the device manufacturer won’t know the architecture and design of the OS, so knowing if the vendor has performed this fault-tree analysis will be very relevant. Having access to the fault-tree analysis can greatly reduce the work for the device manufacturer, similarly so for the software being accompanied by a safety manual that supports these claims. If the COTS OS is accompanied by a safety manual, the job of building safety case becomes much easier.
Again, the choice of OS is exactly that—a choice. A criterion in this selection, when arriving at a choice, should be how that OS helps or hinders with the compliance of a medical device. An OS that offers complete pre-integrated components like the Wi-Fi and Bluetooth drivers, the Qt graphics packages, clock synchronization libraries and processes, etc., all integrated and version-aligned, will suit timelines better than one lacking these traits. Better timelines mean faster to market, faster to revenue, and reduced risk.
This article was writtten by Chris Ault, Senior Product Manager, QNX Software Systems, Ottawa, Ontario, Canada. For more information, Click Here .