Example: an intelligent asthma monitoring device

As an example, let's take a connected asthma monitoring device worn by the patient to track their cough rate, respiration patterns, heartbeat, temperature and other relevant asthma symptoms. It might also allow the patient to record journal entries about their feelings and behaviours. The data is sent by the device to the data controller (or a data processor) where a back-end algorithm then analyses this data, builds an understanding of the patient's 'normal' so as to detect any unusual deviations, and sends that information to the associated smartphone app. All or some of this data could be shared, not only with the patient but also with designated third parties such as parents, caregivers, medical professionals and/or hospitals.

The hard stuff: security and privacy by design

Cybersecurity

Data breaches are a major risk associated with smart medical devices, whether caused by malicious actors or insufficiently robust cybersecurity. Data breaches can arise in many different ways, with potentially serious consequences for our Asthma Monitor users, for example:

Unauthorised disclosure: A data breach could expose highly sensitive information about our Asthma Monitor users. A user's ethnic and health profile, as well as their everyday sleep, exercise and even emotions patterns could be exposed to unwanted third parties as a result of some ransomware or other cyberattack.

Data loss/destruction: If a patient relies on their Asthma Monitor to record all of their asthma-related data, a cyberattack could erase that data.

Compromise of data integrity/data alteration: A malevolent hacker could manipulate the data produced and stored by the device and its associated platform(s), resulting in false diagnosis and potentially serious consequences, for instance if the false data leads to a Type I error diagnosis (false negative).

These are just the risks to the patient's data, an attack could have life threatening implications depending on the nature of the device.

Most of the vulnerability in a connected device comes from the multiplicity of potential points of failure. Because a device like our Asthma Monitor is connected to other devices and networks and shares its data with multiple entities (the patient's and loved ones' smartphones, the hospital, the manufacturer and possibly others), a cyberattack exposing or destroying patient data can potentially take advantage of any device or entity that receives the data. The connected nature of access points goes both ways – an insecure IoMT device could also be an entry point into wider networks as well as providing a way into the data it processes.

Whether existing laws regulating medical devices fully tackle the risk of hacking is uncertain. The revamped Medical Devices Regulation (MDR) came into force in May 2017 and will apply from May 2020. While it does extend its reach to cover pure software as a medical device, and imposes more stringent responsibilities on manufacturers, it is still very much focused on traditional device safety and according to the RAE, does not really engage with cybersecurity.

Product liability laws will certainly be a head of liability for defective devices, but as Katie Chandler explains, their applicability to smart medical devices is still limited – in part because the number of actors involved and the complexity and spread of the networks surrounding those devices will make it difficult to pin down one responsible party.

The GDPR, however, provides an easy avenue for regulators to assign responsibility for failures of security in smart medical devices: the data controllers. It requires data controllers to ensure the "confidentiality, integrity and availability" (the 'CIA triad') of systems and data under Article 32(1). The appropriate level of security is assessed in the strictest terms for devices like our Asthma Monitor, due to the particularly serious risks that can result from a security breach. Data processors carrying out data processing on the instructions of data controllers also have independent data security responsibilities.

It's essential to use data encryption, security patches and regular updates to protect against attack and resolve vulnerabilities in order to prevent and mitigate data breaches and associated device recall, financial penalties and reputational damage.

Privacy by design

Also relevant is the GDPR's principle of privacy by design (Article 25(1)), which requires data controllers to "integrate or 'bake in' data protection into their processing activities and business practices, from the design stage right through the lifecycle". The onus is on the data controller to ensure that every single step in the design process and ongoing service delivery is compliant with this principle.

In the product lifecycle of smart medical devices, this is complicated both upstream and downstream at the product development stage by the globalisation of supply chains and the cohabitation in one device of multiple third party intellectual property, and at the service delivery stage by the lack of control over distribution networks.

Data controllers for devices like the Asthma Monitor should create and maintain perfect visibility and control over each critical point, by using comprehensive records and carrying out regular Data Protection Impact Assessments.

To achieve high cybersecurity standards, the medical devices industry may benefit from following non-binding draft recommendations recently published by the FDA. Cybersecurity laws being in some respects more stringent in the US than in the EU, following these precise, practical recommendations provides a comfortable basis for compliance with the GDPR standard as regards device and operations design.

Some of the soft stuff: consent, transparency and privacy by default

Consent

If consent is relied upon as the lawful basis for processing data, or as an exemption to the general prohibition on processing sensitive personal data, the GDPR requires consent to be freely given, specific, informed, unambiguous and a positive indication of the data subject's wishes. In relation to sensitive data, consent must also be explicit.

The 'specific' requirement is difficult to fulfil for connected medical devices. The type of data, the way in which it is collected and processed, and the purpose for which it is used will systematically change over the device's lifecycle. The Asthma Monitor collects data on a patient's symptoms not only to monitor that patient, but also to learn from that patient's patterns and behaviour in order to fine-tune other patients' diagnoses.

Obtaining specific consent for these uses is extremely demanding, and the standard of consent for use of such sensitive data is very high. Consent for the use of the device is not the same as consent to the data processing and the two must not be confused or joined together. Moreover, because users of a device might rely on it for life-saving treatment, it is unclear that a supervisory authority would consider consent to be 'freely given'. Another factor is that the Asthma Device is often used by children so parental consent may be required. One way or another, obtaining valid consent is likely to be a challenge.

Transparency and privacy by default

Whatever the legal basis for processing, controllers will always have to comply with the transparency principle which requires information about the processing of data to be provided in a clear and transparent manner, and to be accessible to any user. This is where device designers need to get creative to explain in digestible terms how the data is analysed and used – this is a tough exercise, especially for the Asthma Monitor, which is largely used by children.

Even where a parent has given consent for their child to use a device, that child may still have a right to information about how their data will be collected and used. This right will become increasingly important as they grow older and, ultimately, the child becomes old enough to exercise their own decisions around personal data. Transparency is also relevant when devices provide choices to users about the way their data is used. Indeed, better transparency means more informed choices. When providing any set of choices, however, device designers must remember that the privacy by default principle requires the highest level of privacy settings to be automatically set.

Understanding the data journey

It should now be clear that GDPR compliance requires a thorough understanding of a connected medical device's "data journey". For many device designers and manufacturers this means reviewing the role played by their entire supply chain and dependencies, as existing quality and safety control systems are often not adapted to a whole new network of threats which need to be identified and monitored. It is hard to see how regulators will tolerate anything less than complete control and transparency over the treatment of the often highly sensitive data processed by a smart medical device.