Software Defects and the FDA

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.

Leave a Reply