Bob on Medical Device Software

There’s a recent article in the Baltimore Sun called Flaws in medical coding can kill which just rehashes static software  analysis (hat tip: FDA Trying to Crack Down on Software Errors).

I’ve discussed software forensics tools before. Yes, bad software has hurt and killed people, and there’s no excuse for it.  I still don’t think an expensive automated software tool is the silver bullet (which is implied by the article) for solving these problems.

But here’s what really bugs me:

“If architects worked this way, they’d only be able to find flaws by building a building and then watching it fall down”

This is a prime example of why analogies suck.  The quote is supposed to somehow bolster the FDA’s adoption of “new forensic technology”. If you stop and think about it, it does just the opposite.

I guess you first have to consider the source –  a VP of Engineering for a forensic software vendor. This is exactly what a you’d expect to hear in a sales pitch.

What’s truly ironic though is that a static analysis tool can only be used on source code! Think about it. Source code is the finished product of the software design and development process. Also, forensic science, by definition is the presentation of something that has already happened. It can only be done after the fact.

The logical conclusion you would draw from the analogy is that static analysis is probably useless because the building is already up!  If you step back and look at the full software quality process, this may well be true.

I’m not saying that static analysis tools don’t have value. Like all of the other software tools we use, they have their place.

Just beware when you try to use an analogy to make a point.

UPDATE (7/5/08):

Here’s another take on medical device bugs: When bugs really do matter: 22 years after the Therac 25.

UPDATE (7/16/08):
From Be Prepared: Software Forensics Gaining Steam at FDA, David Vogel of ­Intertech Engineering Associates says:

… that static tools are hyped to do more than they can actually deliver. “Static analysis looks for simple coding errors and does not apply heuristics to understand how it will perform dynamically because it is a static analysis tool”

I agree.

Pete Gordon asked a couple of questions regarding FDA regulations for Internet-based reporting software that interface with medical devices. The questions are essentially:

1. How much documentation (SRS, SDS, Test Plan) is required and at what stage can you provide the documentation?
2. How does the FDA view SaaS architectures?

The type of software you’re talking about has no real FDA regulatory over site. The FDA has recently proposed new rules for connectivity software. I’ve commented on the MDDS rules, but Tim has a complete overview here: FDA Issues New MDDS Rule. As Tim notes, if the FDA puts the MDDS rules into place and becomes more aggressive about regulation, many software vendors that provide medical devices interfaces will be required to submit 510(k) premarket approvals.

Dealing with the safety and effectiveness of medical devices in complex networked environments is on the horizon. IEC 80001 (and here) is a proposed process for applying risk management to enterprise networks incorporating medical devices.  My mantra: High quality software and well tested systems will always be the best way to mitigate risk.

Until something changes, the answer to question #1 is that if your software is not a medical device, you don’t need to even deal with the FDA. The answer to question #2 is the same. The FDA doesn’t know anything about SaaS architectures unless it’s submitted as part of a medical device 510(k).

I thought I’d take a more detailed look at the architecture we’re talking about so we can explore some of the issues that need to be addressed when implementing this type of functionality.

This is a simplified view of the way medical devices typically interface to the outside world. The Communications Server transmits and receives data from one or more medical devices via a proprietary protocol over whatever media the device supports (e.g. TCP/IP, USB, RS-232, etc.).

In addition to having local storage for test data, the server could pass data directly to an EMR system via HL7 or provide reporting services via HTTP to a Web client.

There are many other useful functions that external software systems can provide. By definition though, a MDDS does not do any real-time patient monitoring or alarm generation.

Now let’s look at what needs to be controlled and verified under these circumstances.

1. Communications interaction with proper medical device operation.
2. Device communications protocol and security.
3. Server database storage and retrieval.
4. Server security and user authentication.
5. Client/server protocol and security.
6. Client data transformation and presentation to the user (including printed reports).
7. Data export to others formats (XML, CSV, etc.).
8. Client HIPAA requirements.

Not only is the list long, but these systems involve the combination of custom written software (in multiple languages), multiple operating systems, configurable off-the-shelf software applications, and integrated commercial and open source libraries and frameworks. Also, all testing tools (hardware and software) must be fully validated.

One of the more daunting verification tasks is identifying all of the possible paths that data can take as it flows from one system to the next. Once identified, each path must be tested for data accuracy and integrity as it’s reformatted for different purposes, communications reliability, and security. Even a modest one-way store-and-forward system can end up with a hundred or more unique data paths.

A full set of requirements, specifications, and verification and validation test plans and procedures would need to be in place and fully executed for all of this functionality in order to satisfy the FDA Class II GMP requirements. This means that all of the software and systems must be complete and under revision control. There is no “implementation independent” scenario that will meet the GMP requirements.

It’s no wonder that most MDDS vendors (like EMR companies) don’t want to have to deal with this. Even for companies that already have good software quality practices in place, raising the bar up to meet FDA quality compliance standards would still be a significant organizational commitment and investment.

Many people still confuse verification (was the product built right?) and validation (was the right product built?). The benefits of both of these activities are well covered in Software Validation: Turning Concepts into Business Benefits:

Software V&V is a FDA requirement, but the same methodologies can be used to improve non-device software as well.

It’s Easy to Get into Trouble Because of CAPA summaries an audio conference on Implementing an Effective CAPA System: What You Need to Know (pdf) sponsored by FOI Services.

Creating a corporate culture that can carry out a quality system plan is a big challenge, especially for new medical device companies. As this figure aptly shows (hacked from page 42), aligning the organization with a formal project Mission Statement, Scope, Goals, and Communication Plan is a key component for implementing an effective CAPA system.

The survey statistics on the use of risk management tools and CAPA effectiveness are interesting. Of particular interest of course are the number of firms sited by the FDA for CAPA deficiencies. The slides detailing CAPA implementation and advice are also quite informative.

I stared at the “Big C” (page 23) for a while. I know it’s trying to show the relationship between CAPA (820.100, “little c”?) and the rest of the quality system. I thought I figured it out a couple of times, but in the end I was not able to decipher its true meaning. I could buy the audio CD to find out or maybe Jan can just clarify it for us.

As reported here and here, the FDA is proposing to reclassify a MDDS from a Class III to a Class I medical device. On the surface this might seem like a big deal. If you read the fine print though (my highlight):

FDA has already recognized that the class III requirements are not necessary for ensuring the safety and effectiveness of MDDS devices and has been exercising enforcement discretion with MDDS device manufacturers. These firms have not been required to submit PMAs or meet other requirements typically required of manufacturers of class III devices, but the agency believes that all or nearly all firms in this industry have in place good business practices, including quality systems.

They’re just formalizing already established practices.

“The Gray Sheet” has an article called CDRH Software Forensics Lab: Applying Rocket Science To Device Analysis. Can it really be true that CDRH is doing static code analysis for detecting software defects in recall investigations?

Static code analysis has been around for a long time. I remember using Lint back in the old days. Nowadays all commonly used computer languages (like C and C++) have fairly advanced analysis tools. For Microsoft .NET languages there are tools like FxCop and ReShaper. These tools are great for spotting trouble areas and maintaining code conventions during the development process.

I just have a hard time imagining a process using these tools that would successfully detect real defects in complex medical device software. Especially software that’s controlling hardware devices, doing communications tasks, and recording sensor data. Also, what about all of the assembly language code for embedded processors and DSPs?

Anyway, from the article:

A recent review in the forensics lab found 180 “questionable constructs” in 100,000 lines of code, but only two turned out to be real design issues, Taylor said.

He also pointed to two other cases where static analysis of the software did not find any bugs, thus clearing software as a root cause candidate in the recall investigations.

These statements beg the following questions:

1. Were the two “real design issues” related at all to the device failures?
2. Just because no static analysis “bugs” were found, why does that exonerate the software from being the cause of the failure?

I’m not impressed that static analysis has “been embraced by the aeronautical and automotive sectors”. IMHO this approach just seems like it would create a lot of work for very little return. The manufacturer that produced the device should be responsible for tracking down and fixing the software (and/or hardware) defects.

I’ll stop now.

UPDATE (25-Oct-07):

Check out Tim’s post on this subject: FDA Raises Bar on Medical Device Software Testing.

I’ve been involved in some informal discussions regarding the use of Agile methodologies for medical device software. The Medical Device and Diagnostic Industry (MD&DI) October 2007 article by Tim Bosch entitled Medical Device Software Development—Going Agile provides a good overview of the challenges that face medical device design and development organizations that want to embrace Agile. Here’s Figure 2 from the article:

I liked the organization ‘rejection, force fitting, or abandonment’ analysis. Changing organizational behavior is a difficult thing to do. Add in the documentation requirements and you can see why adopting Agile is an uphill battle. This is especially true for an organization that already has a history of doing software development the old fashioned way.

On the regulatory side, Tim references General Principles of Software Validation; Final Guidance for Industry and FDA Staff and claims that:

An agile development approach aligns well with this guidance.

I’m not so sure about that. As I’ve pointed out before, because of the validation requirements those guidelines are much better suited for the Waterfall development approach. That’s why most people do it that way. Agile can be applied, but it comes with increased cost and potential regulatory risk.

I think the advantages of Agile methodologies are real and application of them does have the potential to improve the functionality, cost effectiveness, and quality of medical device software. It’s good to see articles that detail the issues and provide a realistic strategy for achieving those goals.

CardioDynamics International Corporation (CDIC) Receives FDA 510(k) Clearance for Innovative Clinical Parameters and Electronic Medical Record Compatibility.

WooHoo! Congratulations to all of the CDIC R&D (including yours truly) and Quality teams for getting this done. Great job everyone!

I ran across this post: Why Making Software Companies Liable Will Not Improve Security. It’s a rather long piece that discusses the liability of software makers for security breaches. In the middle of the article he talks about his experience working on FDA regulated medical device software. I think his depiction is a little harsh, but probably not that far off depending on the environment you’re working in. The conclusion from his FDA experience is:

In short, I believe that any attempt to impose quality on software by inspection and rule books is doomed to failure.

I would say that there are no single set of rules that can ensure software quality (that’s not quite ‘doomed to failure’, but may be close). I think the FDA “rule book” (as I briefly describe here) is a full product life cycle quality system that generally meets its intended purpose. It doesn’t ensure that all medical device software is free from defect. Far from it. The regulations simply provide the FDA with a means for determining what the product requirements and design were and how well it was actually tested. It’s up to the regulators to use that information for deciding whether a product meets their quality standards.

On a side note, the post talked about how in 1997 50% of FDA device recalls were due to design defects. The article Failure Modes in Medical Device Software analyzes software-only FDA recalls from 1983-1997 and is a good read on the breakdown of software defects. According to that article, only about 10% of the total FDA recalls (1994-1996) were software related. It would be interesting to know how that number has changed since.

I contacted Frank Jacquette regarding my previous port on this subject (Agile development in a FDA regulated setting). His experience using Agile methodologies for pure software medical device projects does not correspond with my conclusion regarding cost effectiveness and regulatory risks. Frank said:

It has been a long while since I wrote that article, but we’ve applied the same approach to some fairly significant systems and they’ve all come in on time and within budget.

He does agree that the regulatory risk is a legitimate concern, but their experience with clients and regulators has always been positive.

I want to thank Frank for so graciously responding to my inquiry.

He also pointed me to a presentation called Integrating lightweight software processes into a regulated environment (pdf) by Adrian Barnes that I had not seen before. This is a far more detailed look at possible solutions for bridging the gap between “Agile Processes” and “Formal Processes”. The subject progression and graphics are very well done. It’s worth a careful look-through. I’ll let you be the judge, but I think Adrian’s conclusions have the same level of skepticism as mine. I broadly addressed cost effectiveness whereas he specifically deals with risk factors for his bridge solution. He has even less faith on the regulatory risk side: “A brave man would try to convince the FDA that Agile is OK”.

It’s always good to have multiple points-of-view on a subject.