Preventive medicine for machines

April 24, 2008

By Raoul Jetley and Paul Anderson

The Center for Devices and Radiological Health (CDRH) at the FDA is responsible for post-market surveillance of medical devices. If a device failure resulting in actual or potential serious injury or death is reported, the manufacturer of the medical device is required to investigate, determine the root cause and contributory factors, develop appropriate corrective actions, and report their findings to CDRH.

In cases where the adequacy of the manufacturer's investigation or corrective action is in question, CDRH may conduct an independent investigation. Commensurate with the threat to public health, CDRH can unilaterally take a range of actions, including issuing public health notifications or mandating a product recall.

Performing a post-market investigation, however, is not an easy task. This is particularly true in the case of software, where the execution is often user-driven and system-specific. To further complicate matters, device software is usually event-driven, resulting in failures that are often unpredictable and may not be easily reproducible. In such cases, the only way to trace the software flaws has historically been to manually review the source code itself. Given the complexity of modern medical-device software, this is a very difficult and time-consuming task for a third-party investigator with no prior knowledge of the software.

Recently the CDRH's Office of Science and Engineering Laboratories (OSEL) has been investigating the use of static analysis technology to assist in this task. This article gives a brief introduction to static analysis and explains how we used this technique to detect flaws.

Static analysis

Historically, static analysis has been used mainly to enforce syntax checks and coding standards in software. Over the last few years, a new breed of static analysis tools, based on light-weight formal methods, has emerged that can be used to detect potentially fatal flaws in the software.

The flaws detected by these static analysis tools include runtime errors, such as buffer overruns, null pointer dereferences, race conditions, resource or memory leaks, and dangerous casts. Some advanced tools also incorporate a facility to detect inconsistencies in the code, such as redundant conditions or erroneous assumptions that may indicate programmer misunderstandings. Typically, when a potential flaw is found in the software, the tool generates a warning that allows the user to see not only where the flaw occurs, but the conditions that must hold in order for it to occur.

An advanced static analysis tool typically operates by performing 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, all 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 refine associated symbolic values and check for potential errors. If any of the values is determined to result in an error at any point along the path, a corresponding warning is issued.

Preventive medicine

Static analysis is a valuable tool for post-market investigation. By reasoning about potential run-time errors in the software, static analysis provides an independent, standardized, and repeatable inspection of a medical device's software, as part of a broader scientific analysis of the device. Further, providing the precise location of the failure and a corresponding execution trace enables the investigator to trace the root cause of failure to its origin in the source code. This ability not only helps reduce time and effort involved in post-market investigation, but also leads to a more accurate means for post-market analysis, as opposed to manual inspection. Most importantly, the use of static analysis allows the post-market investigator to evaluate the product, in this case the software, and not just the processes involved in developing it.

Much as static analysis helps the investigator, it can be leveraged to even greater effect by medical-device manufacturers. The manufacturers can use static analysis to help find flaws early in the development cycle. Static analysis lends itself readily to verification and validation activities and can easily be incorporated as part of the manufacturers' software-development processes. Doing so facilitates a deeper assessment of the code before releasing it to market and helps establish conformance to good programming practices.

On the basis of this experiment, we have reason to believe that static analysis--whether used in pre-deployment analysis by the manufacturer or during post-market surveillance by an investigator--has the potential to greatly reduce software anomalies and lead to safer, more dependable medical devices.

For the complete story and a description of the case study used by the FDA, go to: http://embedded.com/design/207000574?pgno=1

SOURCE: www.embedded.com