Managing the Risk of Medical Device Software

As with most other industries in the last decade, the medical device sector has seen a tremendous increase in the amount of software used in its products. According to the Institute of Medicine (IOM), medical device manufacturers increasingly are relying on software to build new devices and to add new capabilities. More than 50 percent of existing medical devices rely on software for some functionality—the software is either embedded in the devices or plays an integral role in the production of the device. Companies that lead the medical device market in innovation and efficiency rely heavily on software for new product lines and enhanced functionality.

As a result, the complexity of software in these devices has steadily increased. The benefits of software, however, come with the cost of risk of failure due to the presence of defects—there typically is a strong correlation between code complexity and the number of defects in the software. The safety-critical nature of medical devices requires that a variety of testing methods be employed to ensure that defects don’t slip through development and end up risking the lives of those who use them. To ensure proper verification and validation of medical devices, a strong emphasis is placed on regulatory oversight and device approval before market release.

However, in a recent report by the IOM titled “Medical Devices and the Public’s Health: The FDA 510(k) Clearance Process at 35 Years,” the group evaluated the 510(k) device review process and recommended a complete overhaul of the system. Given the increasing use of software, the IOM committee reported on the increasing uncertainty introduced by device complexity as well as potentially unsafe interactions with other software systems and suggested that the U.S. Food and Drug Administration (FDA), which is responsible for regulatory oversight on medical software development process and testing, review and update its guidance on software validation.
Device manufacturers met these suggested regulatory overhauls with concern. According to industry associations such as AdvaMed, introducing new regulations would stifle innovation, increase costs and slow down the process of bringing new and valuable devices to the market.
 
Regulatory Guidance
In the past, the FDA has done its part when it has recognized a need for introducing new guidelines or updating existing ones. For medical device software, the FDA introduced the guidelines in the form of General Principles of Software Validation (created in 1997, updated in 2002). Such guidelines serve to help the device manufacturers put in processes and take specific actions to validate the software that helps operate medical devices. Most recently, the FDA started work on drafting guidance for mobile medical applications after acknowledging the recent growth in the use of mobile device applications for improving and facilitating patient care. These guidelines contain recommendations for software verification, defect prevention, software validation after changes to a code base, independent review and developer testing.

Device manufacturers take guidelines and modifications to existing approval processes very seriously and use tools such as static analysis to ensure their development process aligns with federal requirements. Since 2006, the use of static analysis to test code within traditional software verification and validation processes has seen a dramatic rise. Modern static analysis can discover complex defects in the code by simulating every possible execution path of the program without the need to actually execute the code. Additionally, by focusing on ‘run-time defects,’ new static analysis technologies evaluate more of the intricate interactions within code bases.

A simple example of this is tracking the values of variables as they are manipulated down a path through the code or the relationship between how parameters of functions are treated and the corresponding return values. To analyze code with this additional level of sophistication, mature analysis solutions combine path flow analysis with inter-procedural analysis to evaluate what happens when the flow of control passes from one function to another within a given software system. The entire analysis is automated and does not require a substantial modification to the existing development process.

The use of static analysis has given rise to building long-term best practices in the software development process for medical software. A good governance, risk, and compliance policy that builds on the strengths of automated code testing with static analysis can make medical devices safer and the development process more efficient. Such policies allow development organizations to define and test code against compliance and regulatory requirements to manage development risk throughout the development process. It also allows the organization to be proactive, prescriptive, and in control of the quality and safety of the software and devices they produce.
 
Security Concerns
Regardless if you’re a consumer, a device manufacturer or a regulatory body, it is clear that software enables medical device manufacturers to deliver innovative breakthrough devices that help patients lead better lives. However, medical device manufacturers must overcome the challenge of managing the risk of failure and complexity inherent in software. As devices evolve, new challenges like security threats can also be introduced.

The risk of security breaches needs to be taken into account as more devices incorporate features that require connectivity for control, reporting and monitoring. In the July issue of BusinessWeek, author Craig Cutler looked at the new armsrace driven by software code. The author referred to “The Cyber Commander’s eHandbook” by Kevin G. Coleman and noted the possibility of someone being able to shut off a hospital’s computer-controlled intravenous drip oxygen system remotely.

He also mentioned Stuxnet, a computer worm that was the first to target industrial systems. Culter’s article continues: “Coleman’s handbook lists about 40 types of attacks that play off botnets and exploits. No. 38 is assassination. Just as Stuxnet caused a centrifuge to spin out of control, a computer worm can shut off a hospital’s computer-controlled intravenous drip or oxygen system before the medical staff knows anything is wrong. No. 39: hacking cars. Cars are full of computers that run the brakes, transmission, engine, just about everything. Control those systems, and you control the vehicle—and can crash it at will. Sounds far-fetched? Last year researchers from Rutgers University hacked into the computers of a car traveling at 60 mph via a wireless system used to monitor tire pressure.”

These might be scary thoughts to think about, but they are becoming increasingly real. Fortunately, these challenges are being met with development testing solutions and best practices that ensure the integrity of safety-critical code bases.
 
Rutul Dave is a senior project manager for development testing firm Coverity Inc. based in San Francisco, Calif. Rutul received his master’s degree in Computer Science with a focus on networking and communications systems from the University of Southern California. Within nine months into graduate school, while learning about creating high-performance networking and distributed systems, he found his passion—creating real “bleeding-edge” technology systems at various California Bay Area-Silicon Valley startups such as Procket Networks, Topspin Communications and then moving to Cisco Systems. He has years of software development experience in embedded and real-time systems. Today, his focus is creating tools and technology to enhance the software development process and to equip developers with the best resources, techniques and practices to maximize the integrity of software. When not evangelizing about the benefits of software integrity, he scratches the coding itch by developing mobile apps and understanding the Linux kernel.