Take your medicine, eat your SOUPThe FDA should scrap its panel for approving medical device and learn some lessons from the FAA.
This just in: surprise recommendation of Institute of Medicine panel--the FDA's medical device approval system should be scrapped because it offers little to no assurance of safety for patients.
I've been saying for a long time that the medical industry's certification process for life-critical devices, such as ventilators and pacemakers, is a joke because accreditors are not required to perform any kind of analysis of the device's software/firmware. A 510K FDA approval is essentially a rubber stamp: if the manufacturer can show that a product has essentially the same function as another device already on the market, then it simply doesn't matter if every single byte of code in the new product has been rewritten, relies on SOUP (software of uncertain provenance), or does not follow a quality development process. The government must rely on vendor self-management.
While my experience is that medical equipment developers often have very high internal quality standards and use suppliers with proven reliable products, this maturity is by no means universal, and some choices are downright idiotic. We may like Microsoft Windows for our desktop PCs, but do we want it controlling a digital radiography system that can fry you? The Therac-25 computerized X-ray system, deployed in the '80s, contained the equivalent of approximately 20,000 lines of C source code. Software flaws in the Therac-25 caused massive overdoses, maiming or killing six people. Did you know that some modern digital radiography systems contain 1 million lines of code?
Fixing the problem
The software regulatory environment for medical systems sits in stark contrast to some other life-critical embedded systems industries. The FAA has a rigorous certification process that imposes high assurance requirements on avionics systems contributing to aircraft safety. A flight control system must be certified to the stringent DO-178B standard at Level A, defined as systems whose failure can be catastrophic. The providers of Level A certified avionics have learned to develop and use high robustness components and systems.
Since Therac-25, hundreds of medical device recalls have been tracked directly back to software flaws. There has never been a commercial jet fatality directly attributed to software.
The response we'll hear from naysayers of the panel's findings is that increased safety assurance is bound to force costs up and profits down, which ultimately will defeat the purpose by reducing investment and stifling innovation. This reasoning is flawed.
First, we have the counterexample existence proof in avionics. Improving robustness of the electronics and its software content will actually raise the overall quality of suppliers. Those vendors who lack the experience and will to improve will fail. This will result in a smaller number of expert suppliers that will enjoy increased profits, market share, and long-term success.
Secondly, yet related to the first point: I have always asserted (based on experience) that it is possible to develop high robustness systems rapidly, when using the proper techniques and processes. Finally, modern CPU architectures and systems software technology enable medical device manufacturers to use Microsoft Windows (or Linux, Android, and other popular general-purpose software) alongside high-robustness software on the same embedded computer. Trends towards open source and powerful multimedia need not be sacrificed to achieve safety as long as system partitioning and control of these workloads is performed correctly. Here again is where the medical community can look to the commercial aircraft industry for an example: electronic flight bags (EFBs) are being designed that use Microsoft Windows for spreadsheet calculations yet safely interact with on-board avionics systems--all on the same computer and DO-178B certified.
The good news to take away from the panel's findings is that the sad status quo of medical device approval is now better exposed, and the organization that commissioned this study is none other than … the FDA. The first step to cure is admitting you have a problem.
Dave Kleidermacher is CTO of Green Hills Software. He writes about security issues, sharing his insights on techniques to improve the security of software for highly critical embedded systems.