Software in Medical Devices, by MD101 Consulting

Postmarket Management of Cybersecurity in Medical Devices

The FDA released the final version of this guidance in December 2016. Let's see what changes the FDA made, compared to the draft version.
This guidance underwent many changes, compared to the draft version. One of the most prominent is in the scope:

This guidance applies to any marketed and distributed medical device including: 1) medical devices that contain software (including firmware) or programmable logic; and 2) software that is a medical device, including mobile medical applications. In addition, this guidance applies to medical devices that are considered part of an interoperable system and to “legacy devices,” i.e., devices that are already on the market or in use.

Argh! Legacy devices! Good luck...
Well, this scope was updated to cover any type of medical device with software or with data transmission functions (i.e. the presence of interoperable device) and to make it as articulate as possible.

Essential Clinical Performance replaced by Patient Harm

In the Definitions section, the essential clinical performance disappeared and was replaced by Patient Harm. The concept of “essential clinical performance”, which was developed in the draft guidance, was removed in the final version.
The definition of patient harm is fairly long and won't be copy-pasted here. It is aligned with the definition of patient harm in ISO 14971. The guidance stresses out the risk-based assessment of cybersecurity vulnerabilities, which can lead by a sequence of events to patient harm.

Interestingly, the guidance excludes vulnerabilities compromising confidential data. It only recommends to protect devices from such situations, and refers to other regulations like HIPAA.

Postmarket Considerations

The posmarket considerations were updated to remove to recommendation to "Clearly [define] essential clinical performance to develop mitigations that protect, respond and recover from the cybersecurity risk". It was replaced by (emphasis added):

Using threat modeling to clearly define how to maintain safety and essential performance of a device by developing mitigations that protect, respond and recover from the cybersecurity risk.

The postmarket considerations were also augmented with the recommendation:

Maintaining robust software lifecycle processes that include mechanisms for:
o monitoring third party software components for new vulnerabilities throughout the device’s total product lifecycle;
o design verification and validation for software updates and patches that are used to remediate vulnerabilities, including those related to Off-the-shelf software

We retrieve somewhat here the requirements on software maintenance of section 6 of IEC 62304, read through the lens of cybersecurity management.

Talking about standards, the guidance mentions that the FDA has recognized ISO/IEC 30111:2013: Information Technology – Security Techniques – Vulnerability Handling Processes, and ISO/IEC 29147:2014: Information Technology – Security Techniques – Vulnerability Disclosure, which the FDA thinks may be useful for manufacturers.

Maintaining Safety and Essential Performance

In relation with the removal of essential clinical performance, the section on "Defining Essential Clinical Performance" was removed and replaced by "Maintaining Safety and Essential Performance".
This section draws the link between cybersecurity risk management, safety and essential performance, threat modeling, and remediations (in cybersecurity vocabulary) / mitigation actions.

Evaluation and control of risk patient harm

Likewise, the section on "Evaluation of Risk to Essential Clinical Performance" was replaced by "Evaluation of Risk of Patient Harm", and the section on "Control of Risk to Essential Clinical Performance" was replaced by "Control of Risk of Patient Harm"
The body text of both sections was almost left untouched, with a direct search-and-replace of essential clinical performance by patient harm. It makes their wording more in line with what QA/RA people have the habit to read: risk management addresses patient harm.
These sections were also slightly updated, with recommendations on adopting a vulnerability disclosure policy, and recognizing that changes (mitigations / remediations) may have an impact on the performance of a medical device. In other words, a risk resulting of the mitigation action.

Criteria for defining active participation by a manufacturer in an ISAO

ISAO: Information Sharing Analysis Organization - see ISAO FAQ to better understand the purpose of these organizations.
. This is a new section in the final guidance. It emphasizes the participation of manufacturers in an ISAO. Reading between the lines, this is the kind of recommendation, which can become a compulsory practice.

Elements of an effective postmarket cybersecurity program

To finish with this quick scan of the guidance, this appendix hasn't changed that much. We retrieve the direct search-and-replace of essential clinical performance by patient harm, along with small changes to the body text.

Conclusion

Compared to the draft guidance, this final guidance contains only small fixes and a clarification of management of cybersecurity vs patient harm. It doesn't reduce nor increase the burden of cybersecurity management. While reducing the burden could have been an expectation of some manufacturers, it is not feasible. Fortunately, it hasn't increased between the draft and the final guidance.

With this final guidance on Postmarket Management of Cybersecurity in Medical Devices, and the guidance on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, we now have a full set of recommendations for cybersecurity management over the medical device software lifecycle.

We now have GCyP: Good Cybersecurity Practices.