Last Friday, Paul Sherman posted this FDA Recommendations document on the Biomedtalk biomed listserv. The document refers to medical devices (regulated devices with 510ks) that contain off the shelf (OTS) software.  These are most often specialized medical applications that run on personal computers.  Devices that appear to be embedded (not personal computers) can also be Windows computers “under the covers.”

Many medical devices are networked and can be exposed to viruses, worms and hackers.  By far the biggest risk comes from Microsoft system software; because it is so widely used, malicious programmers have ready access to Windows.  There are also many hacking scripts that can be used by “script kiddies” who, while not having much technical acumen, can run these programs and wreak havoc.

The FDA places the responsibility for these risks (and responding to the consequences when the risks become reality) squarely on the shoulders of the vendors.  The FDA also acknowledges that there may be cases where the customer, and their patients, are best served by addressing the problem on their own.  If you make any change (beyond an application level user configuration) to a regulated medical device YOU are responsible for any resulting patient injuries.

The FDA is really trying to make it easy for the vendors to do the right thing.  They explicitly recommend that vendors create a separate policy and procedure for dealing with these types of problems.  This enables the vendors to get patches out for their products very quickly, while maintaining compliance with the FDA QSR and ensuring patient safety.  If one of your products gets infected (and it can happen to any platform - UNIX, Solaris, Linus) and your vendor tells you they can’t provide the patch that Microsoft released 2 weeks ago because they would have to revalidate their entire product, they clearly have not followed the FDA’s recommendations.

Here are my recommendations:

  1. Know the underlying operating system and version of all the networked medical devices in your hospital.
  2. Only patch a vulnerable or infected system as a last resort.  Legally, YOU are responsible for any patient injuries resulting from applying a patch not released by the vendor.
  3. Request a copy of your vendor’s policy and procedures for dealing with OTS operating system patches from their system software vendor.  It should provide an up front risk management analysis so they can safely limit verification and validation to a scope consistent with the risk.  In many cases, little or no testing whill have to be done to release a patch.  If the vendor’s process does not support this risk-based streamlining, or they don’t have a specialized process at all, you run a risk of losing the use of your device or system for an extended period (perhaps until the next software release) should it become infected.
  4. When buying new equipment, get written documentation that the vendor of choice has a special process for OTS software patches.  If they don’t, buy from someone else.
  5. Ask whether the device is “hardened”.  This applies to existing product as well as when buying new.  A hardened device is one that runs an internal firewall on the box, protecting it from malicious code.  If the device in question has a 510k the vendor will likely support it, so don’t worry about whether someone internal has the expertise to support the firewall.  Typically, these are configured at the factory and never changed.
  6. Consider how you might improve security for networked medical devices.  Routing, gateways or private subnets are all potential solutions.

HIMSS has a Medical Device Security committee, of which I’m a member.  A manufacturer’s disclosure statement has been released.  This form should be completed by the vendor for all networked medical devices you have installed or are considering for purchase.

UPDATE: On February 10, the FDA released this updated Information for Healthcare Organizations about FDA’s “Guidance for Industry: Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) Software.”