The FDA sets manufacturer’s expectations on what is expected to address data security threats in medical devices.
This draft guidance (pdf download) applies to conventional embedded system medical devices with embedded software (firmware or programmable logic) and software products regulated as medical devices. Think about that for a few seconds and let the scope of impact become clear in your mind.
The FDA press release hits the high points. Perhaps the biggest is this statement (emphasis mine):
The FDA sets manufacturer’s expectations on what is expected to address data security threats in medical devices.
This draft guidance (pdf download) applies to conventional embedded system medical devices with embedded software (firmware or programmable logic) and software products regulated as medical devices. Think about that for a few seconds and let the scope of impact become clear in your mind.
The FDA press release hits the high points. Perhaps the biggest is this statement (emphasis mine):
More Read
For the majority of cases, actions taken by manufacturers to address cybersecurity vulnerabilities and exploits are considered “cybersecurity routine updates or patches,” for which the FDA does not require advance notification, additional premarket review or reporting under its regulations.
For many years, manufacturers have shrugged off implementing operating system and security patches — at all or in a timely fashion — because of FDA regulatory requirements. Of course, there are no such regulatory requirements precluding manufacturers from patching their systems, and it is interesting that FDA feels the need to reinforce this in their press release. This is important because FDA clearly states that data security remediation does not have to be reviewed or cleared by FDA — but manufacturers are still required to follow their Quality System. Based on this, I would not be surprised to see increased enforcement discretion regarding this guidance.
Here’s more (again, emphasis mine):
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.
This sounds almost like a recall scenario, perhaps even ship-holds by the manufacturer until the vulnerability is mitigated. There have been plenty of medical devices infected by malicious software in the past. The biggest impact to date has been the loss of the use of infected devices until their software is restored rather than patient safety impacts.
Speaking of notifications, the draft guidance does describe notifications to customers:
Section VII describes recommendations for remediating and reporting identified cybersecurity vulnerabilities, including the development, implementation and user notification concerning official fixes, temporary fixes, and work-arounds. Manufacturers should also adopt a coordinated vulnerability disclosure policy. FDA has recognized ISO/IEC 29147:2014: Information Technology – Security Techniques – Vulnerability Disclosure that may be a useful resource for manufacturers.So customer notifications will be expected by the FDA are described in some detail, and a new standard is highlighted as a benchmark for future 510k submissions.
Another pretty big change is the “recommendation” for manufacturers to work together in some sort of multi-vendor alliance to manage the risks posed by malicious software to medical devices:
Today’s draft guidance outlines postmarket recommendations for medical device manufacturers, including […] the importance of information sharing via participation in an Information Sharing Analysis Organization (ISAO), a collaborative group in which public and private-sector members share cybersecurity information.
Will the HITRUST Alliance extend their franchise to include medical devices, will HIMSS jump in, will a new entity be formed for this purpose, or will this recommendation be ignored by industry?
After an initial quick review, an interesting question is whether a medical device with just a serial port, say a ventilator, should address cybersecurity. The manufacturer is not claiming any network connectivity, but customers are increasingly using third party software (an MDDS from Capsule, or a Bernoulli system) to integrate their ventilators to the enterprise network. Per the guidance, all medical devices with embedded software will be expected to follow this guidance.
A definite cybersecurity red flag is a medical device have a USB connector, regardless of an absence of networking claims.
Implications
FDA guidance are more than just recommendations. In a sense, they are defacto requirements, unless the manufacturer can provide justification as to why the recommendations should not apply to them or their product. Once a guidance is final, subsequent 510k submissions are evaluated with the expectation that relevant guidance will be incorporated in the filing. When expected guidance is not followed, the reviewer looks for suitable justification in the filing for not conforming to the guidance. Should suitable justification not be found (or accepted) the manufacturer will receive questions from the reviewer seeking either suitable justification or compliance with the guidance.
Manufacturers and software developers should start upping their data security game now. While it may take a year or more for the final guidance to be released, data security is not a trivial undertaking and industry should use this time between the draft and final guidance as an opportunity to get things squared away.
Changes like this are always less expensive when done in a considered manner over a reasonable period of time. Rushing things at the last minute to complete a 510k submission is more expensive and results in a less ideal outcome.
Love ’em or hate ’em, the FDA typically does a pretty good job of doing their homework. This draft guidance is another example of FDA taking a topic that’s relatively new to them and the industry, doing their homework, and developing a thoughtful approach to dealing with the issue. While I’m sure there will be some substantive feedback during the comment period, I would not count on this Guidance being drastically changed or watered down.
