Advertisement

Medical device manufacturers are like parents — their responsibilities don’t end when their offspring leave the nest. When an in-field medical device requires maintenance, the responsibility often falls back on the device maker, much like a parent who gets the call from a college-age kid pleading for money.

In January 2016 the FDA issued a draft guidance document, “Postmarket Management of Cybersecurity in Medical Devices,” that outlines considerations for cybersecurity throughout a medical product’s lifecycle, particularly with regards to maintenance. This document follows on the heels of the October 2014 FDA report, “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices,” which provided manufacturers with recommendations on how to address cybersecurity during the entire product lifecycle of a device. With these two reports the FDA has laid out a mitigation guideline that addresses cybersecurity for medical devices, from “conception to obsolescence.”

So what implications does the FDA’s postmarket management document have on maintaining and updating software for medical devices?

Note that the document is a draft guideline, not an edict. Its purpose is to help companies manage postmarket cybersecurity vulnerabilities in marketed medical devices. The FDA also makes it clear that the burden of ensuring safe and reliable performance does not end with product launch. It recommends a proactive, risk-based approach to the postmarket phase of medical devices to mitigate emerging cybersecurity risks and to reduce any impact on patients. The recommended practices include cybersecurity information sharing and monitoring, routine device cyber maintenance, and assessment of postmarket information.

The postmarket FDA management document applies to: 1) medical devices that contain software (including firmware) or programmable logic, and 2) software that is regulated as a medical device. This guidance supplements the information addressed in the FDA guidance document, “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software.” The FDA recommends that, to manage postmarket cybersecurity risks, a company adopt a structured and systematic approach to risk management and quality management consistent with 21 CFR part 820, the regulation that covers quality systems. The FDA also recommends that manufacturers conduct software validation under 21 CFR 820.30(g) to ensure that any implemented remediation mitigates the target vulnerability without unintentionally creating exposure to other risks.

The IEC 62304 standard can help with software maintenance. It provides a framework of software development lifecycle processes with activities and tasks necessary for the safe design and maintenance of medical device software. IEC 62304 comprises 9 clauses; Clause 6 specifically outlines the software maintenance process.

The maintenance process requires the device manufacturer to monitor feedback on the in-field product, to ascertain how a problem should be addressed via upgrade or patch, and to determine whether a problem report should be created. The FDA must be notified when cybersecurity vulnerabilities and exploits may “compromise the essential clinical performance of a device and present a reasonable probability of serious adverse health consequences or death.”

IEC 62304 aligns well with the FDA postmarket management of cybersecurity in medical devices, but the same can’t be said for all software and operating systems that comply with 62304. In particular, Software of Unknown Provenance, or SOUP, may not be the best solution for medical devices. Processes for open source development that are neither clearly defined nor well documented are a specific concern of IEC 62304. In many cases, SOUP, and even some commercial off-the-shelf software, has more functionality than is needed, such as device drivers for hardware peripherals not found in the medical product or file system types not used by the product. Leaving dead code in the system is a practice expressly discouraged by functional safety standards such as IEC 62304 and its parent IEC 61508.

Using open source software like Linux becomes a significant impediment to medical device maintenance. Linux patches (that is, updates) arrive asynchronously and frequently, with no roadmap, no warning, and no coordination of patch releases. The challenge is not only to determine when and if to apply the patches, but how.

In order to meet certification, you may need to modify both the original Linux source and any new patch (for instance, to remove dead code or to change the behavior in error conditions). Unfortunately, you will also need to maintain these modifications for each subsequent patch. You may have removed dead code once, but it can show up again in the next patch. So you will need to remove the code again. And again. As a result, your version of Linux diverges more and more from the mainline distribution, making code maintenance more complex. Incoming Linux patch sets, as well as your own, can become less and less directly usable, and your maintenance costs increase accordingly.

When it comes to postmarket management of medical devices, using open source software is like having three children in college simultaneously.

Also read: 

Advertisement
Advertisement