Sharing & transferring health data.

When you share patient data as a doctor, for example, referring your patient to a cardiologist colleague, you are ‘disclosing personal data’. You don’t have to disclose the transfer of the information to the patient or data subject if you are still respecting professional confidentiality. The receiver or recipient of this data then becomes the data controller with the inherent obligations.

Patients too have the right to take their data with them wherever they go, this is the right to data portability.

Apps are not covered by professional confidentiality. So any changes in who has access to or is processing the data have to be informed in full to the app user including the identity of the new app data controller, the categories of data which will be used and the recipients of the data among others. It is a long list, but how many people just click on the “updated terms and conditions” without reading them? Most of us…

Being based outside the EU does not exempt an app from complying with GDPR if the data subject or app downloader is based in the EU. So unless you are 100% certain that you are complying with GDPR you should limit your app store access to countries not covered by the GDPR.

If the data is being shared outside the EU (of particular interest in the context of Brexit), then similar levels of protection should be requested. Chapter V covers the transfer of data outside of the EU and clearly states that once the EU has decided if the minimum requirements are met, this has to be reviewed every 4 years. It is the European Commission who decides if the standards are being met

Data protection for app developers & large organisations.

You may think that ensuring compliance with data protection in a large organisation is even harder than in a smaller clinic. However, it can be the complete opposite as you may find yourself having to appoint a Data Protection Officer (DPO) who takes over this role. Whether you need to do this or not will depend on the conclusions of a Data Protection Impact Assessment (DPIA) as per Article 35.

The use of new technologies such as EHR or health apps combined with large quantities of sensitive data such as in the case of a hospital means it is necessary to carry out a DPIA following the advice of a DPO. It is the data controller (doctor or other in charge of the data) who has to instigate this.

Data processors too have to think about a DPIA and if you are developing a health app this means you also have a responsibility:

When appointing a DPO, whether in the context of a larger clinical setting or app development, you can use the same DPO as other establishments as long as you easy access to that person. They can be part of your staff (and potentially fulfil other functions). You must communicate who your DPO is to the supervisory authority.

Even if a DPO is appointed the data controller is still required to record all the processing activities.

GDPR and health data – the questions you need to ask as a doctor.

As a doctor, I have always been very aware of the importance of patient confidentiality. Not only for ethical or legal reasons but also for purely practical purposes. If you don’t have all the information you can’t make the right decisions, and you will only get all the embarrassing information if patients are confident it won’t go any further.

However, from a legal perspective, it is not always that clear, especially when we are talking about health data which now comes from sources other than just the patient. Fitness trackers, for example, give useful information, but how should I store that data?

And if you are looking to buy into some new digital technology, what are the questions you need to ask?

If you are still using paper records or are outside of the EU, this too affects you as all data are covered by articles 2 and 3 of the GDPR.

Historically this has been recognised as a concern as early as 1970 with privacy being covered in the European Convention on Human Rights. Data protection was mentioned in 1981 in the Convention 108 for the Protection of Individuals with regard to Automatic Processing of Personal Data. Therefore the right to data protection is a fundamental right. Now, most people will have heard of the General Data Protection Regulation or GDPR which came into effect in May 2018, if only because of the pop-ups requesting permissions or in the case of certain non-EU websites, refusing access altogether.

For doctors, the essential concepts to understand about data processing or actions on information that can identify their patient are:

  1. Data controller: Person who decides what data is collected, how this data is collected and for which purpose. As a doctor, you or your institution can be a data controller.
  2. Data processor: Person or service who processes the data under the instructions of the controller and as a doctor using #digitaltech this can be the software you are buying storing the data and which needs to be formalised with a contract.
  3. Data subject: Patient or identifiable person.

Article 5 of the GDPR covers data processing, and as a doctor/data controller, you need to be aware that the data you collect should be:

  1. Lawful, fair and transparent.
  2. Limited to purpose – you need to be recording data with a specific, limited and explicit purpose.
  3. Minimised – irrelevant data should not be recorded.
  4. Accurate – doctors are used to keeping treatment changes, for example, and we are all aware of the legal consequences of not keeping legible notes.
  5. Storage limitation – this refers to not keeping the data for longer than required. Health is probably one of the few exceptions where you can argue that the data should be stored for the entire life of a person to give the best care.
  6. Integrity and confidentiality. This refers to the fact that the data must be protected appropriately through technical and organisational means. You need to consider not only loss and damage (accidental or other) but also that it is not accessed inappropriately by different members of staff. This is a core question when being presented with a new medical application or technology for your practice. Larger institutions such as hospitals will have an information security officer, but if you practise in a smaller setting, this responsibility will be yours.

Finally, to process any data, you need to be sure that there are legal grounds for processing the data you have collected. For doctors, the concepts are familiar:

  1. Consent has been given.
  2. It is necessary for a contract to be carried out and specifically, in the health care setting, this includes an agreement to medical treatment either implicitly or explicitly.
  3. You are complying with a legal obligation.
  4. You are protecting the vital interests of a patient.
  5. You are carrying out a task in the public interest or in your capacity as an official authority.
  6. There exists a legitimate interest for processing.

Sensitive data, as health data is, get more privacy protection, and Article 9 covers this specifically. Safeguards used include:

  1. Pseudonymisation: This is removing identifying fields such as name, date of birth and address but in health needs to go even further. A diagnosis of a specific disease and treating hospital plus gender may be enough to identify the patient. With big data and large amounts of patients, it becomes harder to identify individuals, but even there it is important to think about unusual characteristics which may make the patient stand out. Some doctors have fallen foul to this on twitter when making what they thought were generic comments about a type of patient they may have seen during a specific shift. However, at the same time you still have to have the correct data to treat your patient. This means that you need additional information in order to access all the information about your specific patient.
  2. Anonymisation: This means that you strip away all the identifying aspects from the data and can no longer identify the patient. This is a valid technique for research. You can no longer identify the person even if you have the additional information. As mentioned previously, it is very hard to anonymise medical data and there is a chilling report here for al those with any level of data protection responsibility about how supposedly anonymised health data sets were not so anonymous once compared to local newspaper reports. 43% of the individuals were identified.
  3. Encryption: This encoding of the data is very much more a technical aspect.  Most doctors would find it hard to know what questions to ask and then interpret the answers. However, thinking of specific clinical contexts may make the technical team think about uses and deviations which they had not come across.

In general, observing good medical practice will set you on the right road, but the questions come when you want to contract a new software.

  1. What / who is the data processor you use? Are they compliant with GDPR and what sort of guarantees do they offer?
  2. As this is sensitive data, how is it:
    1. Pseudonymised?
    2. Encrypted?
  3. How are you complying with data protection by design and default?

Although most clinicians without any programming or technical knowledge would find it hard to ask specific questions and then understand the answers. However, technicians don’t have the situation-specific understanding of how this data will be used and going through a typical consultation together step by step can help uncover moments when there may be data compliance issues. This is the data protection by default – only the sensitive data needed for the specific process can be processed. For example:

  • How do you lock the screen temporarily while examining a patient when family members may be present?
  • How do you deal with multiple doctors using the same computer?
  • How are blood results transferred between the laboratory and your EHR?
  • Are emails encrypted if you have to do a referral to a colleague?

The company selling you any software should be able to give you clear answers and explanations as to how they are helping you comply with your obligations as a data controller in the clinical setting. Your obligations when contracting a data processor are set out in Article 28, and even if you don’t know the article in detail (!), the people selling you the EHR should.