Photo of Steven Boranian

We have been tracking the issue of medical device cybersecurity for quite some time now.  We wrote here on how medical device hacking is both the stuff of Hollywood storytelling and also a genuine concern to which the FDA and medical device manufacturers are paying attention.  In June 2013, the FDA issued a Safety Communication entitled “Cybersecurity for Medical Devices and Hospital Networks,” and the agency finalized a guidance document in October 2014 on how to address cybersecurity in medical device premarket submissions.  In that guidance the FDA set forth a risk-based model, under which device manufacturers are to identify and assess both risks and strategies to mitigate the risks in preparing their premarket applications.  To complete the backstory, the FDA took the unusual step in July 2015 of issuing a Safety Communication regarding a specific cybersecurity vulnerability in a network-connected pain pump.  We wrote about that in our prior post, too.

The new development is the FDA’s release on January 15, 2016, of a draft guidance on postmarket management of cybersecurity in medical devices.  You can link to the draft guidance (which actually bears today’s date, January 22, 2016) here.  Again, the FDA is taking a risk-based approach, i.e., guiding manufacturers to identify, assess, and mitigate risks that emerge after a product has been introduced to market.  Come to think of it, the agency could hardly take a different approach, given that all medical devices present both benefits and risks and that risks cannot be complete mitigated in any device.  The draft guidance puts it this way:  “Because cybersecurity risks to medical devices are continually evolving, it is not possible to complete mitigate risks through premarket controls alone.  Therefore, it is essential that manufacturers implement comprehensive cybersecurity risk management programs . . . .”  (Draft Guidance, at 11)

What would the FDA recommend for such a program?  The programs should address vulnerabilities in technology that may impact patient safety, and critical components would include:

  • Monitoring cybersecurity information sources for identification and detection of cybersecurity vulnerabilities and risk;
  • Understanding, assessing and detecting the presence and impact of a vulnerability;
  • Establishing and communicating processes for vulnerability intake and handling;
  • Clearly defining essential clinical performance to develop mitigations that protect, respond and recover from the cybersecurity
  • Adopting a coordinated vulnerability disclosure policy and practice; and
  • Deploying mitigations that address cybersecurity risk early and prior to exploitation.

(Draft Guidance, at 11-12)  There are elements here that are familiar to the medical device world, including the concepts of detecting risks through postmarket surveillance and potentially taking corrective action.  But there are also elements that the FDA clearly has borrowed from the data security and privacy context, including adopting a cybersecurity disclosure policy.  In regulating data privacy as it relates to consumers, disclosure of a “privacy policy” is the guiding principle for many, if not most, of the key regulators.  The FDA seems to have borrowed that idea.

Some elements are vague and will surely be subject to comment.  We can imagine some confusion over which “cybersecurity information sources” should be monitored, and when preparing a “coordinated vulnerability disclosure policy,” to whom would that be directed?  We assume physicians, based mainly on our grounding in the learned intermediary doctrine.  Like any other risk/benefit information, physicians are uniquely equipped to understand and react to any disclosure that the draft guidance would call for.  In addition, we could see harm coming from disclosure of “vulnerabilities” directly to patients, who may overreact and ask their physicians to disable important medical device functions and thereby place their health at peril.

The draft guidance also suggests deploying mitigations “prior to exploitation” of a vulnerability.  We’ll think about this one.  Our initial reaction is that “exploitation” does not necessarily equate to any clinical consequence.  So not only is the FDA suggesting mitigation before any exploitation of a vulnerability actually occurs, but also before any patient experiences any related complication, reportable or otherwise.  We cannot see how that would work in practice.  We’re also not sure what “vulnerability intake and handling” would mean.  Is that different from the postmarket surveillance that medical device companies already undertake?  It is very possible that it is different, because the draft guidance seems to contemplate mitigation before any reportable adverse event occurs.

There are two other parts to the draft guidance that we would highlight.  First, in formulating its risk-based approach, the FDA would assess risk in reliance on two main variables:  (1) the “exploitability” of the technical vulnerability and (2) the severity of the potential impact on health.  (Draft Guidance, at 13-15)  Risk would be assessed according to these two factors on a sliding scale—a vulnerability that would be difficult to exploit and would pose little impact on health is the lowest risk (or a “controlled risk”).  On the flip slip, an easily exploited vulnerability that threatens a significant impact on health is the highest risk (called an “uncontrolled risk”).  The agency even published a nifty chart in the draft guidance to illustrate how different situations would fall into different shades of gray on the “exploitability/severity of impact to health” matrix.  (Id. at 15).  This is about as clear a demonstration of the risk-based model as we can imagine.

Second, the draft guidance contemplates remediation often in the form of software updates and patches.  Significantly, for routine updates and patches, the FDA will not typically need to conduct premarket review to clear or approve the software changes.  (Id. at 16)  Device manufacturers can just implement the patches without prior review.  Moreover, when “controlled risks” are involved (remember the sliding scale?), routine updates and patches will not have to be reported to the FDA, except in periodic reports required for PMA devices.  Different rules would apply for “uncontrolled risks.”  Where “unacceptable residual risk that the device’s essential clinical performance could be compromised due to insufficient risk mitigations and compensating controls,” immediate reporting may be required, but not always.  (Id. at 18)  As the FDA stated in the draft guidance’s introduction, “For a small subset of cybersecurity vulnerabilities and exploits that may compromise the essential clinical performance of a device and present a reasonable probability of serious adverse health consequences or death, the FDA would require medical device manufacturers to notify the Agency.”  (Id. at 4)

Actual harm caused by medical device hacking remains somewhat speculative, but the concern is genuine and growing.  The core message of the draft guidance (and also the 2014 guidance on premarket measures) is that medical device manufacturers should be systematic and proactive in approaching these risks.  The comment period for the draft guidance will be open for 90 days.