3

I need to exchange data from a patient providing its own health data to a healthcare provider over my server. The data is encrypted on the patient's device by the public key of the healthcare provider before it is sent to my server. It is then downloaded and decrypted by the healthcare provider.

During the whole process I don't know the identity of the patient nor am I able to decrypt the data.

Is the data being sent over my server still subject to Art. 9 (1) of the GDPR?

To my understanding the data does not reveal anything about who the patient is nor what the content is. But of course, I don't want to risk anything.

3

Recital 26 contains

To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly.

In the opinion of the Advocate General in C‑582/14 the definition of "reasonable" is further clarified:

  1. That is a practical possibility within the framework of the law and, therefore, ‘reasonable’. The reasonable means of access referred to in Directive 95/46 must, by definition, be lawful means. (20) That is, naturally, the premiss on which the referring court proceeds, as the German Government points out. (21) Thus, the legally relevant means of access are reduced significantly, since they must be exclusively lawful. However, so long as they exist, no matter how restrictive they may be in their practical application, they constitute a ‘reasonable means’, for the purpose of Directive 95/46.

This means if there is a way to obtain the decryption key, encrypted personal data is also personal data. It does not matter how limited the possibility is.

However, the Art. 29 WP has written in their Opinion 05/2014 on Anonymisation Techniques:

The most used pseudonymisation techniques are as follows:

  • Encryption with secret key:

    in this case, the holder of the key can trivially re-identify each data subject through decryption of the dataset because the personal data are still contained in the dataset, albeit in an encrypted form. Assuming that a state-of-the-art encryption scheme was applied, decryption can only be possible with the knowledge of the key.

Art. 4 has the following definition of "pseudonymisation":

‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;

Pseudonymised personal data is still personal data. See recital 26:

Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person.

5

Yes, encrypted personal data potentially still is personal data, so some prior thought is necessary. But are you a controller who is processing this personal data? Possibly not. This hinges on what kind of metadata you process, and whether the encryption happens under your authority, e.g. by a software that you provision. If all you can ever get is the encrypted data but not the plaintext, then you can probably treat this similar to pseudonymous or anonymous data.

A related example is a postal service. Letters might contain sensitive personal data. But the postal service is not processing the letter contents, and cannot be treated as a controller of this data. (The postal service is prevented by law from processing this data, you are prevented by the encryption). However, a postal service processes personal data like addresses on the envelope.

You might want to create a Records of Processing document, which will help you understand what (potentially) personal data you will process.

If you are processing patient data on behalf of a healthcare provider, you might want to look into whether you are a controller or a processor. Processor status is not automatic but requires a suitable contract with the controller. As a processor you still have to take appropriate security measures, but you are not responsible for determining the purposes of processing or for responding to data subject requests.

0

If you want to be safe: Get a lawyer.

That said, it depends on the data. Even if it is encrypted, the content might be identifying data, so it is best to handle it as such. On the other hand you can't access the data itself but just the encrypted package that you can't decrypt. To you, the data package is useless.

You might get away easy because you can't access the data itself, but just in case you should outline a data handling directive that lays out that any non encrypted data is to be deleted instantly.

  • Thank you. It is pretty much in line with my assumptions. I'll get a lawyer anyway but wanted to see what the community thinks. Relying on the fact that I'm locked out by the encryption seems to be too easy to be true. Also, handling deletion requests needs to be considered as I have no way of telling who the sender is. – Paul May 24 at 15:41
  • I'll leave the question open for a bit longer to see if there is any other input. – Paul May 24 at 15:42
  • You might need some kind of anonymous identifier that can be used to tell your server "I am authorised to delete this" like a delete link or code. – Trish May 24 at 15:44
0

The fact the Data was encrypted does not mean it no longer is able to identify a natural person, only that few have access to it. So, it is not "available" Data, yet still Personal Data. The process of "transforming" Personal Data into non-personal Data is Anonymization, not Encryption. Yet, anonymization must be well thought of, for even if not possible to identify a natural person out of it where internally cross-referenced, there may be external sources that allow it, rendering anonymization not valid/ secure/ effective.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.