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.

Fig. 1 – Medical device manufacturers face a balancing act between time to market and certification efforts.
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)

Fig. 2 – Managing the process of designing software components is just one of the challenges of building a medical device.
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

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.