Here are some thoughts regarding the article: I feel a little uncomfortable about computerized medical devices, and here’s why.
- Just about all medical devices are computerized these days. Most will not harm or kill you if their software fails (Class I & II), but that’s no excuse for writing crappy code.
- As pointed out, the mission critical nature of mass transit systems (airplanes, subways, etc.) affords those industries a much higher level of scrutiny then cars or medical devices ever will. But that’s still no excuse for writing crappy code.
Even through drugs and airplanes need advance approval from authorities before being brought to the market, medical devices and software do not, at least in the United States.
- This statement is not correct. All medical devices, including diagnostic and therapeutic software-only products, require FDA clearance to be sold in the US market (see the Class I & II link above). There are many exemptions, but a 510k pre-market approval is generally a minimum requirement. After you receive approval the FDA can pull your device off the market (the dreaded “recall”) at any time due to complaints or unsatisfactory audit results.
- The FDA QSR Subpart C (§ 820.30) looks a lot like DO-178B as quality system design controls go, but I’m sure the aviation standard enforcement is far more rigorous (well, at least I hope it is). It’s true, there are no coding standards for medical device software. Good companies set their own development standards and practices — some even use static analysis! It’s all the other companies that don’t bother to do anything that you have to worry about.
I’m certain that static analysis technology has improved vastly in the four years since some of the articles below were written. The challenge is that the complexity of medical device software and the systems they run on has also increased tremendously during that time. In particular, the explosion of high bandwidth wireless networks along with advances in handheld computing power and graphics capability (think iPhone/iPad, of course) is fundamentally changing the way medical devices will be developed and delivered to the market in the future.
Static analysis will remain a valuable tool for identifying critical software defects, but new methods will have to be developed for rooting out risks in the new network-connected, multi-touch world.
It’s sad to say, but you should probably be more than “a little uncomfortable.”
Other static analysis articles:
A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World
More Software Forensics and Why Analogies Suck
Medical Device Software Forensics
Pascal’s 3 part static analysis series that starts here:
Guest Article: Static Analysis in Medical Device Software (Part 1) — The Traps of C