These days I am more and more involved in medical devices software matters: interesting questions about modularisation, whether or not EHRs are medical devices in Europe and negotiation of systems integration agreements within the systems integration clause of the EU medical devices directive, just to mention a few. But so far I have not really been dealing with any in-depth questions from clients regarding connected device security. No wonder that I was interested to see that the FDA released a draft guidance on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices last week. I was curious as to whether the guidance would provide any useful inspiration for us Europeans, like the draft guidance on mobile medical apps, which the FDA just can’t seem to be able to finish and keeps moving the deadline for publication of the definitive version of.

Short, and how definite is the thinking?

The guidance is kind of strikingly short, and the question is how definite the thinking expressed in it is. After all, it is a draft to invite comments. The Medical Connectivity Blog is skeptical and says

“An open question for me is whether even a draft sufficiently establishes an FDA expectation that should be followed in the interest of a smooth submission review.”

The FDA Law Update Blog, for its part, is on the other side of the spectrum and recommends that manufacturers should immediately address the principles set out in this guidance  in their design process and brace for FDA inspections on this  point. As we say in the Netherlands: the truth is probably somewhere in the middle, but I think it’s safe to say that we won’t know for certain until there is a definite version. Hopefully it will not take as long as with the Mobile Medical Apps guidance. In any event the FDA is under pressure to develop policy in this field.

New, or just a repack of what’s out there already?

The FDA says in the guidance that “Failure to maintain cybersecurity can result in compromised device functionality, loss of data availability or integrity, or exposure of other connected devices or networks to security threats.These, in turn, have the potential to result in patient illness, injury, or death.” I think nobody will argue with that: external parties gaining access to a device is not a nice scenario. Cybersecurity controls are  approached via the angle of information:

“Manufacturers should develop a set of security controls to assure medical device cybersecurity to maintain information confidentiality, integrity, and availability.”

If you compare the notice to what’s already out there, there is basically nothing really new in it for EU devices law purposes. The new bit would be the renewed attention to the subject and an intention to start to take this subject seriously (but even that is changing in Europe too, see below). The core of the notice is for manufacturers to:

“consider cybersecurity during the design phase of the medical device, as this can result in more robust and efficient mitigation of cybersecurity risks. Manufacturers should define and document the following components of their cybersecurity risk analysis and management plan as part of the risk analysis.”

For us Europeans this is not new at all. For EU purposes manufacturers have to meet MDD essential requirement 12.1a:

“For devices which incorporate software or which are medical software in themselves, the software must be validated according to the state of the art taking into account the principles of development lifecycle, risk management, validation and verification.”

The standard harmonised for this essential requirement is EN/IEC 62304:2006/AC:2008, which approaches security of medical devices along the exact same lines, from the angle of information security (see paragraphs 3.22 and 5.2.2 e)).

Useful examples and technical file guidance

The FDA guidance does provide useful examples of possible requirements to implement on access limitation, trusted content and fail safe & recovery features.

The guidance furthermore provides a nice checklist for the premarket submission, or in the EU: the technical file. I practice I often find that manufacturers have difficulties in determining how they will structure their design documentation, so why not use the checklist provided in this notice? Always useful if you want to go the US market at some point. Medical devices software security does not always have the attention that it should have, as is also apparent from the fact that the recent FAQ on EN/IEC 62304 do not contain any discussion of security issues. For example, the FDA requirement to have “appropriate documentation to demonstrate that the device will be provided to purchasers and users free of malware” will not be top of mind for many manufacturers. However, be warned – the examples do not follow EN/IEC 62304 methodology completely but rather seem some specific elements of that which the FDA considers especially interesting.

Also, don’t forget that the EU imposes additional requirements of software security via data protection legislation in case patient health data is processed. If you don’t follow those your device might be taken off of the market on grounds of violation of data protection law.

New EU enforcement initiatives

Currently MEDDEV 2.1/6 2.0 is in the works and is being held up with its desire to synchronise scope of the concept of medical device with the Green Paper on health and wellness apps that the Commission is preparing.

Authorities are however increasingly interested in the subject of medical software. I attended an invitational conference of the Dutch Healthcare Inspectorate (IGZ) on 5 June where it laid out its new enforcement policy in the field of medical software. IGZ had invited all serious players in the Dutch medical software market, including all EHR vendors, to tell them that they would enforce medical devices law rigorously as of 1 January 2014 in order to clear the market of non-CE marked software in scope of medical devices regulation. It will specifically audit manufacturers of  medical devices software, which means that it will look at the technical file to determine if that is sufficient basis for a CE mark in the cases of software that was CE marked as a medical device and take  software of the market if it should have been CE marked or the CE mark is not supported by the underlying documentation. IGZ inspectors told me that this initiative has been coordinated with the European Commission as a European pilot project for increased surveillance on software as medical device, so there is more to come in other EU member states.

So

Even if this FDA draft guidance may not be so new on substance, it is an important reminder to address cybersecurity in your device software seriously. Both the FDA and the EU authorities have their eyes on it.