False: FDA does not allow software security patches

[Note the sarcasm in my title.  In fact, FDA guidelines promote keeping COTS software up-to-date.]

[Update: Way to go, NBC and TechNewsDaily!  Congrats on spreading false information that "under the current law, software used to run medical devices...must remain static." Totally false.  NBC should admit and correct the mistake. Hire some fact checkers or journalists! And get some more J.J. Abrams shows too. They can help you fact check.]

Manufacturers ought to provide regular software updates to address known security risks in medical devices that utilize off-the-shelf software like Windows XP, OS2, Linux, etc. Some do.  Some don't.  The next time a manufacturer refuses to issue a software update for a known security problem in your hospital computing systems, send them this blog entry.

False: FDA does not allow software security patches

I often hear complaints based on half-truths that "FDA does not allow software security patches."  False. (See my previous rant about compounder software.)  Let me get to why I say "half" true in a moment. Cybersecurity documents from FDA state that:

The need to be alert and responsive to cybersecurity issues is part of the device manufacturer’s obligation...Software patches and updates are essential to the continued safe and effective performance of medical devices. Typically, FDA approval is not required before install changes, updates, or patches that address cybersecurity issues (see question #10 of the guidance).

Ok, you're with me right?  FDA explicitly says that manufactures should issue software patches to address cybersecurity problems.

Most cybersecurity patches fall below the threshold for FDA review

In 2005, FDA issued what I consider "basic survival" guidance on cybersecurity of medical devices that depend on "off-the-shelf" software.  It's not perfect, but it's explicit on some topics.  John Murray of FDA's Office of Compliance later said:

Another question that always comes up is; I’ve gotten calls from users and they’ve said they’ve call the device manufacturer and the device manufacturer says, “I can’t do anything, I have to get FDA approval.” So we went back and examined this question and the answer is that pre-market review of a software patch or a cybersecurity update, usually does not require and FDA pre-market approval.

In 2004, John Murray spoke before a special HHS committee on medical device cybersecurity, the risks/benefits of network connectivity, and the cybersecurity challenges facing FDA:

FDA premarket review is rarely required prior to implementation of a software patch.  FDA has previously published detailed guidance on when FDA review of a design change is required, and most cybersecurity patches fall below the threshold for FDA review. 

True: Software updates are still complex to manufacture and manage

Ok, so why do manufacturers make the dubious claim that "FDA rules" prevent them from issuing software updates?  I think there are at least a couple rational reasons.

First, regression testing, validation, and other good manufacturing practices are non-trivial. It can take a heck of a lot of work to perform testing. The last thing a manufacturer wants to do is accidentally brick a medical device with an errant update. Remember back in college when getting code to compile was the last step of success? Yeah, well good manufacturing goes a wee bit further. Back when I worked in the software industry, the savvy software engineers ran automated regression tests every night and sometimes even after each new commit of code to the source repository. I imagine most medical manufacturers have such automated testing suites, but it still poses non-trivial challenges. How do you automatically validate things that connect to non-deterministic patients? Moreover, how do you perform testing on a component that will interoperate with other unknown components from different manufacturers? On modern medical devices, it's not feasible to "check the behavior of a complicated device to every possible, conceivable kind of input." A whole discipline of system engineering exists to help tame such complexity.

A second likely reason is that guidance documents are peppered with conditional language open to interpretation.  If you want to scare a regulatory affairs specialist, just add a bunch of implicit "if" or "unless" conditional branch statements.  So what happens when a risk-averse decider sees a statement like "rarely does..." or "if X, then cybersecurity updates do not require pre-market review"?  Ah, to be safe, let's just assume !X.  Therefore, the dubious claim comes true.  Not sure how to fix this one. Manufacturers: listen to your engineers. FDA: make your guidance less fuzzy.

I hope legislation is not necessary to solve these engineering and economic incentive problems.

Do the right thing.  If.  Unless.  So report me, maybe.

In summary, the absolute claim that "FDA rules prevent software security patches" is false. But there is a half truth hiding behind the sentiment. The rules are sufficiently fuzzy to cause misunderstandings and unintended interpretations. A manufacturer needs to plan ahead for these foreseeable cybersecurity risks, and budget for the inevitable software updates and regular maintenance.   Hospitals need to ask for and pay for the services for regular and timely security patches.  There's no perfect engineering solution, but not issuing any security patches for medical devices running on antiquated Windows XP is a decidedly unhelpful approach.

Your Homework

Go read the presentations from FDA on the topic of software updates.  I know of one hospital that uses these slides to confront manufacturers unwilling to issue security patches.

• "ECRI Audio Conference. Virtual Patient Safety: Worms, Viruses and Other Threats to Computer-Based Medical Technology" by Alford Taylor, FDA CDRH, November 2003.
• "FDA Regulatory Perspectives: Presented to the Philadelphia Area Medical Instrumentation Association" by Alford Taylor, FDA CDRH, February 2004.
• "Medical Product Software Development and FDA Regulations" by Cark Wyrwa, IEEE Orange County Computer Society, March 2006.