medicaldeviceslegal

The MDR and IVDR are here now, but the General Data Protection Regulation (GDPR) already beat them to the finish line as it was just adopted.

I have written a lot about current and future EU data protection requirements, both on this blog (here, here and here for example) and in other publications. What I have referred to as future EU data protection requirements, the GDPR, is no longer future now that it has finally been adopted and published.

It will apply as of 25 May 2018 so all companies collecting and processing personal data in the EU will have to be compliant by that date. That looks like a lot of time, but don’t forget that a lot needs to happen when you are processing data concerning health (which all medical devices companies will be). And you will have to do it while implementing the MDR, IVDR or both. Better start immediately. By the way, like under the MDR and IVDR everything will become more complex and technical. The fines are astronomical, deliberately to scare companies into compliance (how about 4% of your annual worldwide turnover?).

Why is the GDPR relevant?

Why is the GDPR relevant to medical devices manufacturers? If you are posing yourself that question you have not paid attention to the intense lobby by the healthcare industry with respect to the GDPR. You may also not understand that more and more the customer and patient data that manufacturers process is crucial to their business. Consider this presentation I made to the Personal Connected Health Alliance:

The hateful eight described in this presentation mostly apply to medical devices manufacturers in general:

1.Informed consent criteria

The GDPR increases the risk related to a consent-based business model  considerably by imposing additional and onerous requirements with respect to informed consent. Medical devices manufacturers will need to spend considerably more attention on their consent processes and the way their phrase their privacy policies, because there is a requirement to provide intelligible consent language and to obtain consent by affirmative action. Especially companies that consider their consent processes and policy a formality will likely run into problems under the consent requirements in the GDPR.

Like under the MDR and IVDR there is no grandfathering, so existing consents do not remain valid if they do not meet the new requirements. You will need to do a gap analysis for all consents obtained.

Consent is invalid “in a specific case where there is a clear imbalance between the data subject and the controller”. This will be a tricky one in practice for business models that entail provision of services to the clinical profession and institutions. When a doctor prescribes the use of an app that the hospital uses for monitoring patients at a distance, the patient will mostly not feel in a position to refuse this. Consent would then likely have been obtained in a case of imbalance and be invalid, regardless of the patient ticking all the consent boxes in the app. The imbalance criterion will play an important role in clinical research as well.

Secondary processing (e.g. for the purposes of a registry, or of registry data for other purposes than initially declared) is allowed for scientific purposes without having to go back to the patient for additional consent, provided that the company implements ‘appropriate safeguards’.

2.Data concerning health scope

The definition of health data under the GDPR does not differ materially from the DPD (it’s “personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status”), but its scope is very expansive because of the way the GDPR interprets ‘health status’:

“all data pertaining to the health status of a data subject which reveal information relating to the past, current or future physical or mental health status of the data subject. This includes information about the natural person collected in the course of the registration for, or the provision of, health care services as referred to in Directive 2011/24/EU of the European Parliament and of the Council to that natural person; a number, symbol or particular assigned to a natural person to uniquely identify the natural person for health purposes; information derived from the testing or examination of a body part or bodily substance, including from genetic data and biological samples; and any information on, for example, a disease, disability, disease risk, medical history, clinical treatment or the physiological or biomedical state of the data subject independent of its source, for example from a physician or other health professional, a hospital, a medical device or an in vitro diagnostic test.” (recital 35)

In addition, the GDPR also introduces the concepts of genetic data and biometric data, which may overlap with the concept of personal data concerning health and are largely treated the same as personal data concerning health under the regime for the special categories of personal data. Holding any biological sample is therefore considered processing of personal data.

3.Right to be forgotten (right to erasure)

The right to be the right to be forgotten applies to any processing of health data that is not covered under the concept of scientific research under GDPR, so basically any commercial collection and processing of health data outside clinical research. This is a safe assumption since this exclusion was adopted specifically to address the concern that exercise of the right to erasure could de-power clinical trials. Whether it applies to other research outside clinical research is unclear.

Companies have to implement technically that they can erase any personal data that they process about a person upon request, and also implement this among the companies that process data for them or have received that personal data from them. Withdrawal of consent to processing is sufficient grounds for this. And withdrawal of consent may not be made difficult under the GDPR. 

4.Impact assessment

The GDPR requires that all companies that process personal data concerning health and/or engage in profiling of data subjects conduct a Privacy Impact Assessment (PIA) prior to the processing. A single assessment may address a set of similar processing operations that present similar high risks, which means that a company does not have to perform a new PIA when it extends a service with new functionality, unless that new functionality presents new risks that have not been addressed in the PIA that was performed.

As I have blogged before, having no PIA currently already makes your company unattractive as a target to invest in or acquire, but with the insanely high penalties under the GDPR (max 4% of your company’s last year world wide turnover) processing personal data concerning health without not having conducted a PIA is pretty reckless behavior for a company. In medical devices logic it is tantamount to developing a medical device without doing risk management, usability design and other essential design inputs.

The GDPR provides as minimum requirements for PIA:

(a) a systematic description of the envisaged processing operations and the purposes of the processing. The systematic description is necessary as basis for assessment and help the company determine all the ways in which it collects and processes personal data, and the associated purposes. Describing the purpose of processing accurately and completely is very important, because companies often collect and processes personal data for multiple purposes (e.g. provision of the service to the consumer and use of the personal data collected in provision of the service to monetize that data).

(b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes. This part of the PIA requires for example application of the principles of data minimization and purpose limitation to ensure that not more personal data is processed that is necessary for the declared purpose and that the processing and collection of data happens in a way compatible with the declared purposes.

(c) an assessment of the risks to the rights and freedoms of data subjects. This element forces the company to think about what the processing means for the data subjects and think about whether the way it processes data still allows for exercise of the data subjects’ rights, such as the right of erasure, the right to object to profiling, the right to correction, etc. If the conclusion is for example that the processing is set up in a way that these rights cannot be exercise, the processing cannot be lawful and has to be modified in order to bring it into compliance with the GDPR.

(d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with the GDPR taking into account the rights and legitimate interests of data subjects and other persons concerned. The GDPR is far more prescriptive with regard to security than the DPD and defines a catalogue of security principles and measures. The controller has to document its choices for security and risk management in its PIA.

A good place to start is with the UK ICO’s PIA Code of Practice, which provides for guidance  on conducting a PIA on your company’s processes.

5.Profiling requirements

Profiling is what makes the use of personal data in healthcare relevant, for example to be able to form a picture of how a patient’ health develops over time and to monitor a patient over time. The GDPR defines monitoring as “any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person’s performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements”, which is precisely what any good medical device service does. As a result, many medical devices manufacturers will need to comply with the profiling requirements. This means:

• informing the data subject of profiling and its details in advance, more specifically “meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject”;
• in case of profiling based on data concerning health obtaining explicit informed consent from the data subject for that profiling;
• when profiling is based on personal data concerning health performing PIA before commencing ; and
• implementing suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests, at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision.

I expect manufacturers to have a steep learning curve in explaining their profiling to their patients in a meaningful way, performing PIAs and implementing measures to address the risks identified as most companies currently see obtaining meaningful (or even legal) informed consent as an inconvenience.

6.Data portability right of user

This requirement will have a great impact in the medical devices industry but also in eHealth in general (e.g. the electronic health record industry). It means that patients can request the data from their pacemakers or EHR for example and even request that the data is transferred to another provider. While the GDPR does not impose an obligation of controllers to maintain technically compatible systems,

“[t]he data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided”.

Companies have to explicitly inform users about the right of data portability. Where technically feasible, the data subject has the right to have the personal data transmitted directly from one controller to another. When exactly this is technically feasible or not is not addressed in the GDPR, but it is safe to say that the data protection agencies will make a point of portability when looking at whether a company has met its privacy by design obligations. This will likely not be the case where a company deliberately designs personal health data processing devices in a way that the data cannot be exported in a commonly used format.

Especially the right of data portability may necessitate that companies redesign existing systems, since there is no grandfathering under the GDPR. That means that by 25 May 2018 all existing systems must be adapted for data portability. Companies that are currently designing systems may want to do a gap assessment to see if their design complies with data portability requirements.

7.Security requirements

We know risk management and (cyber)security from the medical devices standards and rules. The GDPR will require more or less the same with regard to security. This means privacy by design at work, and achieve the level of the state of art in security, which als needs to be a level appropriate to the risk involved with the data processing.

This means implementing, as appropriate, pseudomisation, encryption, redundancy, regular penetration tests and intrusion detection measures, and implementing a continuous process for evaluating the effectiveness of the measures implemented.

The GDPR will moreover feature a pan-EU breach notification mechanism. Personal data breaches have to be notified to the competent DPA without undue delay, but in any event in less than 72 hours after becoming aware of the breach (unless a delay can be justified), and notify the data subjects concerned if their interests may be affected. A personal data breach is a “breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”.This means that the obligation can be triggered regardless of whether data was stolen or deleted after a security breach. What exactly constitutes a security breach will be further defined in guidelines by the new European Data Protection Board.

8.Export of data to extra-EU jurisdictions

Export of personal data outside the EEA will remain only permissible with adequate level of protection, much like is currently the case and the export requirements will not be materially different.

The question is however if the Privacy Shield for export to the US will ever be accepted and what the member states will do, as they retain the competence to maintain or introduce further conditions, including limitations, with regard to the processing of genetic data, biometric data or data concerning health. This means that e.g. the French healthcare data hosting requirements and similar national measures will continue to exist.

Now what?

In the face of regulatory adversity you make a plan and you follow through, so here is the outline for a plan based on the ABCDE (accept/breathe/consider/decide/engage) model:

Accept:

• that a dramatically more onerous regime is upcoming and appoint a Data Protection Officer
• And you will be implementing this alongside the MDR and/or IVDR so your regulatory department will be stretched to or beyond its limits

Breathe:

Conduct an audit of:

• data currently held and what you do with that data
• legal basis for processing data
• data “exports”
• data subject access requests

Consider:

• Rewrite (or at least revisit) for compliance with additional data protection requirements
  • all consent structures
    • consider the information provided as much as the consent itself
  • all privacy notices and policies
  • all anonymisation and pseudonomisation structures (legal justification and state of art?)
  • legal bases for export of personal data to outside of the EU
  • data processing agreements

Decide how to:

• Embed “privacy and accountability by design”
• Design workable structures to give access to patient-level data (or anonymiseearly)
• Strengthen anonymisationand pseudonymisation tools egISO 27001
• Legally “export” personal data.

Engage with Competent Authorities, Industry bodies and other third parties to

• Watch out for specific Member State rules on health data etc, including between Member States
• Practice procedures for breach
• Practice data protection Impact Assessments
• Ask Industry Bodies to update any codes of conduct that were drafted under the old regime of the Data Protection Directive

Some authorities have already provided guidance on what they expect from you, like the UK ICO’s helpful 12 steps plan for implementing the GDPR. Surprise surprise, they also strongly recommend you implement a PIA already now.

Keep Calm – Visit Axon’s seminar on the GDPR

My law firm organises a seminar about the GDPR’s impact in the healthcare industry in Amsterdam on Monday 13 June, which will get you up to speed on the GDPR. One of the guest speakers is the Dutch Data Protection Authority, so you will be able to check assumptions with the competent authority. Please RSVP if you plan to attend – you can bring as many friends and colleagues as you like (just let us know how many).