Open source in Medical Devices: Part of the Cure or Part of the Disease?

By Ido Sarig

The Economist recently published a very interesting article on the merits of open source in medical device development, which raises some questions and sparks an important discussion. 

In general, it is more common to see open source adoption in non-regulated industries. However, we are seeing it more and more in regulated industries primarily because it encourages rapid innovation at far lower costs.  That said, it is important to caution those in the regulated industries (aerospace & defense, medical, industrial automation, energy, automotive) towards embracing open source concepts without investing in lifecycle management tools to support the building of safe and effective devices.  [Proprietary software on the other hand, is a better fit for companies that design devices in environments where changes are few and far in between. Proprietary software also enables better control of the ecosystem, the lower the stack you go.]

As the Economist puts it, “exposing a design results in safe products.”  Maybe…Designing a device or ecosystem with safety in mind, results in safer products, hence the need for “design for safety.”  The FDA mandates a safe and effective design for any devices that gets approved in the US market -- this requires companies to have better control of their ecosystem.  Done proactively, this is an efficient method for product development; however, done reactively, companies incur a lot of costs and overheads trying to make open source fit.

The basic premise of the Economist article, and apparently the FDA’s thinking is that the more eyes on the code, the more bugs will be detected. But that premise is questionable.  A recent study commissioned by the U.S. Department of Homeland Security’s Scan project found that “Where codebases were of similar size, open source code quality was pretty much on par with proprietary code quality.”  For example, the open-source Linux codebase, which is about 7 million lines of code averaged 0.62 per 1000 lines of code (KLOC), while proprietary code bases that averaged around 7.5 million lines of code had 0.64 defects per KLOC. So it seems that in large, complex code bases, such as medical devices, open source is not a panacea, and rigorous testing still has to be performed. One of the most challenging aspects of thoroughly testing medical devices is testing all the error handling code and the exception handling code. This code often makes up 50% or more of the overall code in embedded software, yet is the least tested- because the error conditions themselves are difficult to set up or simulate.

With Wind River Test Management’s Sensorpoint technology, one can easily inject faults directly into fully optimized, production-ready code as part of the test process, making it easier to achieve the complete code coverage required by the FDA for regulatory approval.  In fact, one of our customers was able to reduce the amount of time required to get their latest ultrasonic surgical  knife approved for use by the FDA by 15%, using Test Management’s Sensorpoints.

Another risk factor associated with open source is the fact that contributions come from multiple sources, whose identity is not fully known, exposing the device to the possibility that malware may be incorporated into the code base. As we’ve seen, having the code base exposed to more eyes does not, in and of itself guarantee lower defect rates, so it stands to reason that it does not dramatically reduce the incidence of security flaws.  The problem is exacerbated by the fact that open source libraries are often download from a repository that does not have the latest version of the components.  Research by Sonatype and Aspect Security released earlier this year, confirms this:  looking at the most popular open source Java frameworks and security libraries, they found that 26 percent had known vulnerabilities, and 41 percent were older versions of the components.  Testing for security, incorporating techniques such as Fuzz testing, can help reduce that risk. With Fuzz testing incorporated into Wind River Test Management, even non-security testing professionals can make security testing a part of their normal QA routine.

The bottom line is that enabling open source with industry-leading embedded lifecycle tools will be a happy medium for companies that don’t want to be left behind in technology advances during the life of their devices. If we can extend better healthcare to the masses through affordable open source platforms, we are all for it. Do connect with us to have a discussion on how embedded devices can embrace open source strategies by the right adoption of tools and processes.