Cybersecurity for software medical devices

In our previous regulatory article about the introduction of the MDR and its impact on AI solutions, we discussed the main changes for AI-based medical devices. Obviously, we devoted a large portion to the new definition of a medical device and the updated classification of software medical devices.

Under the previous legislation (also known as the Medical Device Directive, or ‘MDD’ 93/42/EEC), software was incorporated into the changes introduced in M5 (or ‘2007/47/EC’). These changes brought stand-alone medical devices into the scope of the MDD. This meant that software as a medical device would broadly need to meet similar requirements as hardware medical devices. The implementation failed to address, to some extent, software-specific requirements. Whilst, in our opinion, there is room for improvement in the new MDR as well (or Medical Device Regulation, 2017/745) with regards to software implementation, cybersecurity requirements, solely related to software devices (of course) are now addressed.

In this article, we are going to focus on regulatory requirements around cybersecurity. Detailed technical aspects of cybersecurity, which also carry a lot of importance, will be the topic of a different post.

Why is cybersecurity important?

Why is cybersecurity important for (software) medical devices? Three examples of recent security attacks in healthcare should answer the question:

• In 2017, the UK’s National Health Service (NHS) was the subject of the WannaCry cyber attack. Attackers managed to encrypt people’s data and demanded payments in cryptocurrency. The ransomware cancelled thousands of GP appointments and diverted NHS ambulances from their destinations. 
• In 2018, the FDA recalled two defibrillator models after detecting vulnerabilities in their cybersecurity systems. These vulnerabilities would allow cyber-attackers to access the devices and rapidly deplete their battery stores, or even issue improper cardiac pacing commands.
• Early 2019, an experiment conducted by researchers demonstrated that malware was capable of inserting or removing tumours from CT or MRI scans before the doctors’ examination.

General safety and performance requirements

Software medical device manufacturers must assess the General Safety and Performance Requirements (‘GSPR’) of Annex I of the MDR, particularly GSPR 17. The requirement specifies that software manufacturers need to consider state-of-the-art principles on information security. It further explains that minimum requirements need to be set out by manufacturers concerning security measures.

In our view as Aidence, these requirements still lack a bit of clarification. The regulation mentions ‘information security’, which has a rather broad scope, and doesn’t necessarily address the protection of devices against malicious attacks. Also, what constitutes ‘state-of-the-art’ remains unclear.

In the absence of further guidance, some national authorities have published their own requirements on how to interpret ‘state-of-the-art’ for security measures. For example, the ANSM (French medical device governing body) has published a guideline on cybersecurity, and Germany took it a step further by issuing specific regulations on cybersecurity for health applications and similar initiatives are taking place in other EU countries.

The MDCG guidance document

To lay down guidelines on a European level, the Medical Device Coordination Group (or ‘MDCG’) have developed a guidance document (MDCG 2019-16) to support manufacturers in their efforts to comply with the MDR requirements on ‘state-of-the-art’ and ‘information security’. 

The positive message of the guideline is that the methodology laid down in the document closely aligns with the requirements of IEC 62304 and ISO 14971. The guidance explains that security requirements need to be documented, developed, verified and validated. Risks are evaluated in line with the risk management methodology as laid down in ISO 14971.

Even though the document is only ‘supporting guidance’ to the MDR, it does introduce ‘hard’ requirements, e.g. by stipulating ‘shall’ and ‘must’ instead of using ‘should’ for several requirements. We are curious how this will be interpreted by the regulatory authorities, and whether the interpretation of such requirements will be similar to the MEDDEV documents (deviation from e.g. MEDDEV 2.7.1 is considered a non-conformity and could hold up certification). Another question is if the Notified Bodies have sufficient technical security knowledge and understanding to be able to ask the right critical questions. For example, when it comes to clinical aspects, Notified Bodies rely on clinical experts. Similarly, shouldn’t they rely on security experts to review the security aspects of a medical device?

Below are requirements from the MDCG 2019-16 guidance that caught our attention yet might be easy to overlook:

There are many more requirements defined within the document, requiring an in-depth read to fully grasp the implications.

MDR vs GDPR

While the MDR and MDCG mainly focus on the implementation of security measures to protect patients from potential safety hazards, the GDPR (General Data Protection Regulation or 2016/679) and ISO 27001 have a broader focus: to protect personal data. Let’s examine the difference through a practical example of security risk:

The MDR perspective

“A CT-scanner is connected to the hospital network. If a person with malicious intent breaks into the hospital network and gains access to the CT-scanner, they might be able to change its settings. This might lead to patient harm, for example by applying dangerous levels of radiation.”

This type of security risk is mainly addressed through the employment of the MDR, ISO 14971 and the MDCG 2019-16 document. It requires manufacturers to assess the security risks and implement requirements to protect such systems from security threats.

The GDPR perspective

“A CT-scanner is connected to the hospital network. If a person with malicious intent breaks into the hospital network and gains access to the CT-scanner, they might be able to reroute patient data through a backdoor, and systematically retrieve patient scans with patient details.”

This type of security risk is not addressed through the employment of the MDR but needs to be addressed through the GDPR since it poses a threat to the protection of personal data.

In terms of documentation, our approach at Aidence is to combine these risks as much as possible, assessing the severity of the risk against the highest level of impact. The reasoning is that the mitigating controls will be identical, namely preventing a system from being hacked in the first place. However, operational procedures related to the effect of either will be different, e.g. vigilance procedures vs security breach procedures.

The MDCG provides a clear picture of how such risks may and may not overlap, as in the figure below. An interesting point that the MDCG makes is that security measures designed to address security risks should not obstruct the safe use of a device. For instance, in an emergency citation, security measures that prevent unauthorised access should not block access to an implanted cardiac device.

Technical and organisational measures

GDPR requires controllers and processors alike to implement risk management activities in order to assess risks with regard to the rights and freedoms of natural persons. These risks need to be addressed through technical and organisational measures. Whilst the MDR might address some of the technical measures, it does not meet any requirements related to organisational measures. Also, the scope of the technical measures might be limited. 

Although GDPR does a great job of defining what needs to be considered (e.g. confidentiality, integrity, availability and resilience of processing systems) and gives clear proposals of favoured security measures (e.g. pseudonymisation and encryption), it leaves a lot of room for interpretation as to what appropriate measures are.

This is where ISO standards, such as ISO 27001 can come in. The standard supports companies in setting up their risk analysis methodologies and helps them to implement technical and organisational controls. As the standard is specific for healthcare companies, and since companies might process a lot of types of information (besides patient data), it allows manufacturers to define their own scope and the place in the organisation where they will apply the ISO 27001. 

The strength of multiple layers

In addition to compliance standards to help design secure systems, Aidence uses the experience of its technical personnel to implement a best-practice technical architecture. One example of this is a multi-layered security design.

When working with modern technology, for example, when working with cloud systems, it becomes increasingly complex as you add additional programs together. Because of this, we work on a multi-layered security design, such that if one layer is compromised (intentionally or not), other layers of defence are available before access to critical systems is permitted.

Using low-level firewall software, combined with strict authentication and authorisation, is an example of this. If the firewall was compromised, access to data is not implicitly granted. We use this philosophy in all aspects of our technical security design: compliance standards as a layer of defence, alongside other technical measures.

The extra mile at Aidence

At Aidence, we have found great value in implementing the ISO 27001 standard. It supports us in implementing measures that help protect patient data. The extra mile is that this protection goes beyond reasons of patient safety, to preserving data integrity, confidentiality and availability. Such additional measures include:

• Implementation of strict organisational controls (e.g training, regular reviews of information security, and segregation of duties);
• Implementation of strict password controls (e.g. password management systems);
• Strict pseudonymisation and anonymisation controls;
• Strict encryption policies for both the transport and storage of data, utilising the latest cyphers available;
• Automation of security systems, to ensure it is enabled by default;
• Active monitoring and review of production systems to ensure the processes defined are implemented;
• Working closely with industry-leading experts on security and compliance.

We are continuously monitoring the implementation of our controls. Where possible, we combine and balance regulatory compliance between the two fields, e.g. through post-market surveillance, and including security as a topic for PMS, CAPA systems, complaints and so on.