| To: CyberMed@fda.hhs.gov
Cc: Suzanne Schwartz, Office of the Center Director
The following are questions and comments being submitted in response to the “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” document currently in circulation, published October 2018. Please don’t hesitate to contact me for any clarifications or follow up questions.
Questions and Comments
- Regarding the selection of a “Tier” for a device, the Tier 1 description reads “A cybersecurity incident affecting the device could directly result in patient harm to multiple patients”.
- Question 1: Was the singular ‘device’ and plural ‘patients’ reference intentional? For example, a single networked pacemaker device could directly harm a single patient, not multiple patients. You then go on to state that pacemaker would be considered a Tier 1 device. We expect that harm to just one patient would result in a Tier 1 assignment and clarification in the Tier 1 description could clarify your stance.
- Question 2: Can you clarify the definition of “Direct Harm”? For example, a patient diagnostic device could be compromised and create a situation in which the integrity of a key patient vital sign is compromised. This integrity problem could cause a provider to alter their course of care in a manner detrimental to the patient. Would the FDA consider this type of harm to be indirect? In the draft, it appears as though devices that provide decision making intelligence to providers may fall under Tier 2.
- The new guidance introduces some excellent suggestions and requirements for logging and monitoring of medical device events, patch management, and upgradeability.
- Question 3: The guidance does not appear to take a direct stance on who is responsible or eligible to do this monitoring, patching, upgrading, etc. While it may be that the answer is “it depends on the service level agreement between the provider and manufacturer”, clarifying the answer would avoid many future arguments between parties. For example, a statement saying that the operator of the device is responsible for consuming, storing, and monitoring these logs, unless that responsibility has been contracted to the manufacturer or other third party. Can you clarify in final guidance to help remedy the current industry ambiguities on responsibilities between manufacturer and provider?
- One item I consider a critical miss in the draft guidance is any mention of or reference to the FDA GUDID (for readers, the GUDID is an encoded barcode / ID number that uniquely identifies the device model (UDI) and individual build number, and it is required by the FDA – more here). We believe incorporation of the GUDID into all aspects of medical device management is a critical capability for hospital provider to be able to detect, identify, manage, and maintain their devices. Specific suggestions below:
- Comment 1: Require that all structured data provided by the manufacturer or the device be uniquely ‘keyed’ by the product ID (the UDI, or first portion of the GUDID that identifies the product)
- Comment 2: Require that manufacturers maintain detailed logs of all produced and sold GUDID’s, and report cyber security, vulnerability, and device recall data utilizing this GUDID as the unique / primary key for identification. For example, a manufacturer could produce a device recall or vulnerability alert for a small range of devices based on the build number of the device. This structured and keyed data could be easily used by providers to more quickly identify and remediate effected devices, with far greater accuracy and speed.
- Comment 3: It would be helpful to establish more clear standards for “structured” data. The guidance does not specify a particular format but asks that it be “structured”. The OpenFDA APIs (https://open.fda.gov) are an excellent start to making data more open and available. Providers, manufacturers, and the security community need access to more structured data. With improvement, these datasets could create a marketplace of better tools for managing medical device security. All future requests for structured data in FDA regulations should have a format and structure that is clear to manufacturers and providers and is in line with the technologies chosen and used in the OpenFDA APIs. Structured data is of no use as every manufacturer chooses their own way to structure the same content. Stating a data format such as JSON, and a structure (with some room for extensibility for the manufacturer to customize) would go a long way in ensuring downstream interoperability.
The actions proposed in this document are very encouraging for improving overall patient safety, and the ability for providers to manage their devices in a more secure manner. If these questions or comments can be clarified in any way, please don’t hesitate to contact me.
Mike Pinch
Director
Security Risk Advisors |
