Making Device Software Truly Trustworthy

Medical Device & Diagnostic Industry Magazine
MDDI Article Index

An MD&DI January 1998 Column

When Bill Wood examines the reason for conducting software risk analysis, he says, "We've seen devices fail and kill patients. One device that failed because of software shot high energy into a patient. Those sorts of things started piquing people's interest in understanding that the role of software had changed. And the failure of software very definitely could result in patient injury," he says.

In his article on page 139, Wood describes how the role of software has evolved, why conducting software risk analysis is critical, and how to conduct such analysis. From a safety viewpoint, he says, what's most important is whether a device is trustworthy. "When software does fail, are there things that will stop the failure from progressing to becoming a hazard to the patient? A truly trustworthy device is one that fails in a way that I can always predict," he says.

Bill Wood emphasizes trustworthiness.

Trustworthiness in medical devices is much more important than reliability, he explains. "What we're doing here is proving the trustworthiness of the system as opposed to the reliability. A device that is not reliable will fail and will be deemed ineffective, so we must have some level of reliability. But for an engineer, you want to isolate yourself on the risk side and say, 'Why am I looking at this?' You're saying, 'It's because I want something that's trustworthy.'"

Until a few years ago, medical software development had not been on the leading edge. When it was introduced into devices in the mid-1980s, most software was only reporting status or running reports. According to Wood, one reason that software use in medical devices is growing is because simply changing the software can often improve a device. This growth, he says, has meant that software is becoming responsible for the functional capabilities of devices.

Another factor that has heightened the need for software risk management is the increased regulatory attention prompted by software failures. Off-the-shelf software, he says, has introduced components of which the medical device developers have no structural knowledge, since they had no part in developing the software. "The off-the-shelf software brings up all sorts of issues that relate to safety. We discovered that with FDA, you couldn't just do a lot of hand waving to work your way through that. You have to show the analysis."

Wood emphasizes that good software risk analysis requires that engineers focus on the user very early. "With safety, you must focus on it very early, because it will have a definite impact on your architecture. A cascading series of analyses results in safety requirements. If you can codify those requirements—write them down and respond to them by either altering your architecture or making specific requirements that drive your implementation—then as you sharpen your pencil and perform more detailed analysis with fault trees and FMEAs, you can discover holes in your thinking."

People who are good at risk analysis, he says, can imagine how a failure progresses within a system. They can then use their hypothesis to figure out what it would take to stop potential failures. Risk analysis, says Wood, enables engineers to visualize the problem and the solution, and, later, to insert defects to see if their thinking is correct.

Wood points out that patterns are emerging that provide a basis for how to resolve and reduce typical hazards. The field is starting to mature, he says, which has led to the repeated use of certain solutions, such as the expectation that watchdog hardware will always be applied. The notion of patterns, he says, arises out of object-oriented design, which applies the concept of "supersets" to different problems. "One of the reasons I decided to write an article on software risk management was so we can think about the reapplication of what we've learned."

Copyright ©1999 Medical Device & Diagnostic Industry