Infusion Pump Software Safety Research at FDA
- Software Safety
- Model-Based Design of Infusion Pumps
- Generic Infusion Pump Project
- Static Analysis
- Recent Publications About Model-Based Software Development
Many infusion pumps are controlled by software that governs key aspects of the user interface, controls the pumping mechanism to maintain the prescribed infusion rate, and performs key safety functions. The purpose of software is to make the device safer and easier to use. Users often do not realize the extent to which software determines many of the key functional and performance characteristics of the system until something goes wrong.
Unfortunately, in some cases, the software does “go wrong” and compromises patient safety. Because software is inevitably complex, abstract, and intangible, design errors can be difficult to detect. Users and patients should expect infusion pump software to be free from errors. The occurrence of a software error should be a highly unusual event.
Historically, software safety has been focused on the software development process and system-level testing. Not coincidentally, the FDA has focused its regulatory oversight on these two elements as well. Having skilled engineers and a rigorous software development process, as required by FDA’s Quality System Regulation, is important to help to minimize errors. However, assessing the software development process provides only indirect insight into the "goodness" of the resulting software. And system-level testing that would comprehensively test the software is currently beyond the state of the art for all but the simplest of systems. Moreover, it is very difficult to actually test the software under real-world conditions until it has been married with the hardware in a finished prototype, and that typically doesn’t happen until late in the product development cycle.
The FDA has recognized that if product developers had tools that enable them to examine and evaluate software earlier in the development cycle, then there would be a greater likelihood that the resulting software would be more robust. Just as architects now have 3D modeling tools that allow them to take their clients on virtual tours of a new building before ground has been broken, the software engineering community has been developing tools for modeling software and its interactions with the system it controls. The safety properties of the model can be systematically examined, and once the model has been verified, the software derived from it can be proven to conform to the model. The result is software designs that are far more robust than those developed using traditional methods.
Over a period of years, the Software Engineering Laboratory at FDA (within the Center for Devices and Radiological Health) has been working with academic collaborators under the NSF/FDA Scholar-in-Residence program to develop and refine model-based engineering methods and associated verification techniques. Characteristically, these methods have been applied first in the aerospace and automotive industries, where the cost of failure is enormous in both social and economic terms and the incentive to make the necessary investment is correspondingly high. Years of research have finally been commercialized, yielding static analysis tools that are now readily available and being increasingly employed by medical device manufacturers.
One of our ongoing research projects related to model-based software development is the Generic Infusion Pump Project. The goal of this project is to develop a set of infusion pump safety models and reference specifications that can be used / adapted by manufacturers to verify safety properties of their own infusion pumps. Our collaborators include researchers at the University of Pennsylvania in Philadelphia and the Fraunhofer Center for Experimental Software Engineering in College Park, MD.
The Generic Infusion Pump project team has a website that provides a sample hazard analysis and reference safety specifications for a generic patient-controlled analgesic infusion pump. This kind of device, often known as a “pain pump,” is used to infuse medication to relieve chronic pain. Interested parties, including researchers and medical device software developers, are invited to participate with FDA in this research by refining and extending the models and specifications that have been developed. For details, please see the project website.
Software code is the name given by software engineers to the actual instructions — written in a programming language — that constitute a computer program. In modern infusion pumps, the software may contain more than 100,000 lines of code. Traditionally, three verification methods are used to determine whether the code is “correct”:
- manual code reviews, where one team of engineers systematically reviews the software developed by a different team.
- exhaustive testing of the system in which the software is used.
- simulating the execution of the software on a computer.
A fourth and relative new technique for verifying the “correctness” of the software is “static code analysis” — or “static analysis”. Static analysis is the name for a family of analytical techniques for finding bugs in software code and/or proving properties of the code related to its safety or correctness. Unlike traditional methods which run the software in a real or simulated environment to see how it performs, static analysis uses a computer to examine the source code looking for patterns that are indicative of potential design errors. Conceptually, this is exactly what human reviewers do when performing a code review, but static analysis examines the code exhaustively for certain kinds of insidious errors that are hard for human reviewers to detect.
For example, when a software program runs, it stores instructions and data values in the computer’s memory. Other parts of the software can then access this information and process it accordingly. When storing such information, the software must first request permission to access a specific amount of storage space from the operating system. Once the operating system specifies which part of memory to use, the software can place the information in the designated memory space.
Sometimes, due to a programming error, the software may inadvertently write beyond the allocated space it has been granted. In such a case, a portion of the instructions or data that were supposed to be stored is lost. Moreover, in some cases, the flawed software may overwrite data in an adjacent block of memory that was intended to be accessed by another part of the software. This problem, usually referred to as a “buffer overflow,” can result in device malfunction.
Buffer overflow is but one of many problems that can lurk in a body of software code. Static analysis is very effective in detecting a variety of different kinds of insidious software errors like buffer overflow. Since static analysis tools have to methodically trace all possible execution paths through the software, the analysis is very laborious. Until recently, these techniques were exclusively the province of the world's fastest supercomputers, but today's desktop machines have surpassed the performance of the supercomputers of a few years ago. As a result, static analysis tools have been made available commercially from a number of vendors, and as with model-based development techniques, are being increasingly embraced by medical device manufacturers.
The CDRH Software Engineering Laboratory has developed proficiency in performing static analysis of medical device software. In a letter to infusion pump manufacturers dated April 23, 2010, CDRH Director Dr. Jeffrey Shuren offered to make this capability available on a voluntary basis to any infusion pump manufacturer who wishes to make use of it. For further information, please contact Mr. Richard Chapman in the Software Engineering Laboratory at (301) 796-2585 or Richard.Chapman@fda.hhs.gov.
Recent Publications About Model-Based Software Development from the CDRH Software Engineering Laboratory
- Yi Zhang, Paul Jones and Raoul Jetley. A Hazard Analysis for a Generic Insulin Infusion Pump. Published in the Journal of Diabetes Science and Technology, Volume 4, Issue 2, Pages 263-283, March 2010.
- Arnab Ray and Raoul Jetley. Model Based Development: An Emerging Approach for Engineering Medical Device Software. Published in the AAMI Biomedical Instrumentation & Technology (BI&T) journal Volume 44, Number 1, Pages 51-53, February 2010.
- Paul Jones, Raoul Jetley and Jay Abraham. A Formal Methods-based Verification Approach to Medical Device Software Analysis. Embedded.com, February 2010.
- Raoul Jetley and Ben Chelf. Diagnosing Medical Device Software Defects using Static Analysis. Medical Device & Diagnostic Industry, Volume 31, Number 5, Pages 72-83, May 2009.
- Arnab Ray, Raoul Jetley and Paul Jones. Engineering High Confidence Medical Device Software. Proceedings of the 2nd Joint Workshop on High Confidence Medical Devices, Software, and Systems, SIGBED Review, Volume 6, Number 2, Pages 1-7, July 2009.
- Raoul Jetley, Paul Jones and Paul Anderson. Static Analysis of Medical Device Software using CodeSonar. Proceedings of the 2008 ACM SIGPLAN Workshop on Static Analysis, Pages 22-29, June 2008.
- Raoul Jetley and Paul Anderson. Using Static Analysis to Evaluate Software in Medical Devices. Embedded Systems Design, Volume 21, Number 4, Pages 40-44, April 2008.
- Raoul Jetley and Paul Jones. Safety Requirements based Analysis of Infusion Pump Software. Proceedings of the Workshop on Software and Systems for Medical Devices and Services, held in conjunction with IEEE Real Time Systems Symposium, Tucson, AZ, Pages 21-24, December 2007.
http://www-users.itlabs.umn.edu/classes/ Spring-2009/csci5980-med/ SMDS07_jetley_jones.pdf
- David Arney, Raoul Jetley, Paul Jones, Insup Lee and Oleg Sokolsky. Formal Methods Based Development of a PCA Infusion Pump Reference Model: Generic Infusion Pump (GIP) Project. Proceedings of the High Confidence Medical Device Software and Systems (HCMDSS), Boston, Pages 23-33, June 2007.
http://www.computer.org/portal/ web/csdl/doi/10.1109/ HCMDSS-MDPnP.2007.36