Recalls for medical devices are at an all-time high, and defective software is one of the top causes. FDA data indicate that one in every three medical devices that makes use of software for its operation has been recalled due to failure in the software itself.

The FDA is making medical device software quality a top priority. In response to an alarming number of complaints, the agency has announced more stringent safety requirements for new devices. Furthermore, it is looking at new software development practices. In particular, the FDA is now recommending the use of static analysis tools, including GrammaTech’s CodeSonar®, to help manufacturers eliminate software defects during development. The FDA itself has been using CodeSonar to investigate complaints and find out why medical devices fail in the field.

FDA Parses Pump Problems

Fig. 1 - As part of its Infusion Pump Improvement Initiative, the FDA is encouraging manufacturers to use static code analysis to detect software problems early in the development process.
One of the most problem-prone pieces of medical equipment today is also one of the most prevalent: the infusion pump. Infusion pumps are commonly used in patient care settings to deliver fluids, including nutrients and medications, into a patient’s body in a controlled manner. The FDA has received more than 10,000 complaints a year about infusion pumps, for the last five years. Device-related problems were responsible for a large number of serious injuries and more than 500 deaths. In that same time frame, manufacturers of infusion pumps issued 87 recalls, among the highest for any medical device.

Some pump manufacturers say that most problems occur when a nurse or healthcare worker enters the wrong data accidentally. However, FDA officials found that many deaths and injuries related to the devices were caused by product design and engineering flaws, rather than user error.

In response to one of the most widespread medical device recalls in recent history, the FDA introduced its Infusion Pump Improvement Initiative. This aggressive and far-reaching program will establish additional requirements for infusion pump manufacturers, proactively facilitate device improvements, and increase user awareness. With this initiative, the FDA is also driving the industry toward improved software development and verification practices. The Infusion Pump Improvement Initiative will eventually be broadened to cover other types of devices.

Currently, the FDA does not require third-party certification of source code for safety-critical software. The FDA requires only that manufacturers adhere to conventional development processes, and leaves validation and verification of software to the discretion of the manufacturer. In other words, there is no independent review required for software used in medical devices. Historically, the FDA has not attempted to assess the quality of the code directly because of resource limitations.

Up to now, manufacturers have relied on system level testing and code reviews to verify and validate their software. Unfortunately, the run-time execution testing performed typically exercises only a small percentage of possible code paths. In the past, it was possible to augment the testing with a manual code review, which enabled the examination of significantly more paths. However, for the large code bases associated with modern medical devices, it is impossible to manually analyze the truly huge number of paths in the software. Traditional verification methods find some bugs but do not verify the reliability of the remaining code.

Static Code Analysis Detects Potential Errors

As part of its Infusion Pump Improvement Initiative, the FDA is encouraging manufacturers to subject their software to static code analysis, a testing technique that can help detect software problems early in the device development process. Using automated tools for static analysis, it is possible to examine all possible execution paths.

Static analysis is a technique that examines a software application without actually executing the software. The CodeSonar static-analysis tool works very much like a compiler. It takes source code as input, which it then parses and converts to an intermediate representation (IR). Whereas a compiler would use the IR to generate object code, CodeSonar retains the IR, and uses the information to perform an abstract or symbolic execution of the program. During this execution, program variables containing actual concrete values are replaced by corresponding symbolic values. The analysis proceeds by using these symbolic values to follow all possible paths through the code. Along each path, possible symbolic values are recorded. As this execution proceeds, the analysis may learn facts about the variables and how they relate to each other. It uses these facts to check for potential errors.

Static analysis tools such as CodeSonar are capable of detecting many of the most critical defect types and security vulnerabilities. These include run-time errors, such as buffer overruns, null pointer dereferences, race conditions, resource or memory leaks, and dangerous casts. CodeSonar also detects inconsistencies in the code, such as redundant conditions or erroneous assumptions that may indicate programmer misunderstandings or errors. When a potential flaw is found in the software, a warning is generated, allowing the user to see not only where the flaw occurs, but also the conditions that must hold in order for it to occur. While static analysis tools do not guarantee the absence of runtime errors, CodeSonar can reduce the code review and testing burden, and even detect errors that in practice cannot be found by traditional testing.

CodeSonar Aids FDA Investigators

altWhen a widely deployed, commercial medical device failed in the field, FDA inves- tigators used CodeSonar to help determine the root cause. CodeSonar analyzed the device’s 200,000 lines of code and identified the problems shown in the table above.

The results of the analysis were compared with the 118 bugs known to the manu- facturer from complaints. Of these, 82 were successfully detected by CodeSonar, yielding a rate of approximately 70 percent. More importantly, CodeSonar detected an additional 45 errors that had not yet been reported. Conventional testing can only check code being executed. For real-world systems, the number of execution paths far exceeds the number that can be exercised by testing. Static analysis, on the other hand can examine all program paths — which is why it can be used to find many hid- den bugs, even in software that has undergone the most extensive testing.


Static analysis tools like CodeSonar lend themselves readily to verification and valida- tion activities and can easily be incorporated as part of a manufacturer’s software devel- opment processes. Doing so facilitates a deeper assessment of the code before releasing it to market and helps establish conformance to good programming practices.

This article was written by Paul Anderson, VP of Engineering for GrammaTech, Ithaca, NY. For more information, visit http://info.hotims.com/34459-164.