Stream: implementers
Topic: GDPR Data Controllers and FHIR
Håkan MacLean (Jun 29 2021 at 10:21):
We are a company based in EU and we will have FHIR data from multiple GPDR Data Controllers in our system, e.g. data from multiple GP Practices about the same patient.
The problem I'm currently thinking about is, if one of these GP Practices were to leave our platform, we need to delete their data. For example let's say we have Resource where v1 was created by the Patient, v2 by GP A and v3 by GP B and now GP B wants to leave the platform.
When I read the FHIR standard, it seems to me you cannot delete specific versions of a Resources. This causes me to believe that the only solution to this is to actually use multiple Resources, one for each Data Controller, even if they are about the same patient?
Lloyd McKenzie (Jun 29 2021 at 13:27):
@John Moehrke
John Moehrke (Jun 29 2021 at 13:44):
Most of the time each GP will be creating unique resource instances. These instances stand alone, although with relationships. They would have clear provenance. Few resources would be cooperative with multiple GP, those cases would be problematic as you describe. They likely would be patient medical safety risk to tear apart. Which brings up the question I have, what is the intended purpose of this data collection? If it is treatment, then the patient is the biggest factor.
Håkan MacLean (Jun 29 2021 at 13:49):
The company exists in many countries and provides both digital and physical primary care. Provided we have the patient's consent, we want a clinican to get the full picture of a patient, irrespective of which clinician (i.e. data controller) the patient met with previously.
So while we need separation for GDPR reasons, we would also like to be able to present a unified view for both patients and clinicians. But I guess we need to solve that using Provenance and/or Linkage resources? I was reading about the last two resources and I was missing a section on when to use which of these two, like there is a Boundaries and Relationships section for Observation.
Vassil Peytchev (Jun 29 2021 at 15:17):
What I am hearing is that the "data from multiple GP Practices about the same patient" is not available via the FHIR RESTful API on its own from these data sources, it is only through your FHIR server that the information is available, is that correct?
Jose Costa Teixeira (Jun 29 2021 at 18:51):
Håkan MacLean said:
if one of these GP Practices were to leave our platform, we need to delete their data. For example let's say we have Resource where v1 was created by the Patient, v2 by GP A and v3 by GP B and now GP B wants to leave the platform.
I don't understand the base requirement/assumption: when a GP leaves, why would GDPR say that you'd need to delete their updates to the patient record?
Håkan MacLean (Jun 29 2021 at 19:19):
Jose Costa Teixeira said:
I don't understand the base requirement/assumption: when a GP leaves, why would GDPR say that you'd need to delete their updates to the patient record?
In the example above, GP A works for Health Care Provider A and GP B works for Health Care Provider B. These are separate Data Controllers in the GDPR world. It is my understanding that if one of these Health Care Providers/Data Controllers wants to end their relationship with the company, we need hand over all the data we have to the Health Care Provider and then remove all the data from our servers.
Daniel Venton (Jun 29 2021 at 19:56):
If the data needs to be severable, then it seems like the data would be isolated. GP A and GP B wouldn't be able to update the same resources. Slicing out updates to a resource is just going to mangle the data. Audit trail. GP B creates resource, GP A updates, GP B updates based on previous update, GP A updates in B's update. GP B leaves the collective. Do you delete the resource or try to just slice out the updates made by B? That's a mess. If if have a data sharing agreement then as data is updated by GP A then those updates get applied to GP B data but GP B owns their "copy", GP A can leave but all that data that was shared is now held by GP B, you can't slice it out. - My opinion, IANAL.
Jose Costa Teixeira (Jun 29 2021 at 20:19):
Håkan MacLean said:
In the example above, GP A works for Health Care Provider A and GP B works for Health Care Provider B. These are separate Data Controllers in the GDPR world. It is my understanding that if one of these Health Care Providers/Data Controllers wants to end their relationship with the company, we need hand over all the data we have to the Health Care Provider and then remove all the data from our servers.
I am not a lawyer either but I would challenge this step. IMO it's a common (mis?)interpretation that GDPR gives the absolute write to erasure and erasure means delete everything.
Assuming your company is only doing statistics and your collected data is not used for benefit of the patient, I'd still say that the GPs provided the data while performing a contract, and unless the contract says they only let you use their data for a while, that data is yours.
Jose Costa Teixeira (Jun 29 2021 at 20:20):
if the concern is ownership of the data that results from the work performed, I don't see GDPR addressing this.
Jose Costa Teixeira (Jun 29 2021 at 20:22):
If the concern is the GP's privacy (that their privacy is affected if someone knows that they were the ones seeing the patient), you could cleanse the data in the source e.g. going to the tables / objects that hold the GP's id and replace by 00000Unknown.
Jose Costa Teixeira (Jun 29 2021 at 20:25):
And if the purpose of the data is actually clinical, the vital interests of the patient and the legitimate interests of your company should perhaps justify that you keep the data just for those purposes. I don't see a GP or anyone asking to delete vital data because of their privacy concerns.
Jose Costa Teixeira (Jun 29 2021 at 20:26):
I think that should be checked with the lawyers. I just jumped on this because I experienced that rush to overprotect everyone (sometimes everyone except the patient)
Grahame Grieve (Jun 30 2021 at 03:03):
GDPR also falls down once peers can affect each other's records
Håkan MacLean (Jun 30 2021 at 08:01):
Vassil Peytchev said:
What I am hearing is that the "data from multiple GP Practices about the same patient" is not available via the FHIR RESTful API on its own from these data sources, it is only through your FHIR server that the information is available, is that correct?
This does not necessarily have to be true. We could have FHIR endpoints on each service. However, the same service can handle data from different Health Care Providers (i.e. Data Controllers), so I'm not sure if that is relevant to the question?
Håkan MacLean (Jun 30 2021 at 08:01):
Grahame Grieve said:
GDPR also falls down once peers can affect each other's records
Sorry Graham, I failed to understand this. Do you have time to elaborate?
Grahame Grieve (Jun 30 2021 at 08:30):
sure. you have the right to see who accessed and modified your records. And you have the right to withdraw your data, as if you didn't exist. but if you accessed someone else's records, then you can no longer disappear from the database. GDPR generally fails to envisage this situation. There's verious outs in the law, of course
Håkan MacLean (Jun 30 2021 at 11:25):
Grahame Grieve said:
sure. you have the right to see who accessed and modified your records. And you have the right to withdraw your data, as if you didn't exist. but if you accessed someone else's records, then you can no longer disappear from the database. GDPR generally fails to envisage this situation. There's verious outs in the law, of course
as i understand it you as a data subject have the right to be forgotten (even though health data is slightly different), perform a subject access request (i.e. make a request to the data controller to show all the data they have on you, including logs of who has accessed your health data) etc.
but here I am not talking about the data subject wanting their data removed. now it's a data controller (who is storing data about a subject) that wants to move their data from our platform to somewhere else.
Vassil Peytchev (Jun 30 2021 at 12:27):
This does not necessarily have to be true. We could have FHIR endpoints on each service. However, the same service can handle data from different Health Care Providers (i.e. Data Controllers), so I'm not sure if that is relevant to the question?
I think what is relevant is whether you are simply replicating a FHIR interface to the data of the Data Controller using the data controller's FHIR API vs. having the data in your system. Having it in your system is presumably the result of some kind of agreement. That agreement is where you could avoid the need to "delete" versions of a resource, just because a Data Controller is withdrawing from the service.
Jose Costa Teixeira (Jun 30 2021 at 15:25):
Data subject rights are not absolute. In many cases you have the right to request the system to forget about you, but that doesn't mean the system will forget about you.
Jose Costa Teixeira (Jun 30 2021 at 15:27):
People don't have the right to erase their tax record or criminal record. Or professional record.
Jose Costa Teixeira (Jun 30 2021 at 15:35):
@Håkan MacLean if it is a data controller wanting to move their data to somewhere else, that seems far away from Data Access Rights. This seems a case for Privacy by Design - making sure that you preserve the integrity of the records while still granting the possibility to do-whatever-you-need-to-do-contractually.
Some thoughts:
- If the contract between processor and controller describes a need like "forget that the doctor that gave this diagnosis to Patient X was Dr Y", I'd really question that, but it may be legitimate. And you can always anonymize Dr. Y, from which moment you should not need to delete anything.
- If the contract describes the need like "when the contract is ended, the work that has been done by Dr. Y shall be removed from the platform", I'd have another check with the lawyers. Normally it doesn't work like that.
Jose Costa Teixeira (Jun 30 2021 at 15:38):
Grahame Grieve said:
And you have the right to withdraw your data, as if you didn't exist.
I'd say "you have the right to ask to withdraw your data, as if you didn't exist, and there is an obligation to fulfill that request to the maximum possible".
John Moehrke (Jul 06 2021 at 14:18):
note, healthcare treatment is a special case carved out of GDPR as part of the requirements to fulfill "other regulated requirements". Such as Medical Records Retention, and Medical Safety. As Jose indicates the subject can request data be erased, but that request does not overrule 'other regulated requirements'. From my understanding of this stream, this is not a subject request for erasure. This is a data source request to erase. I don't think GDPR has anything to say about this. Where is the GDPR linkage here? The only link I could understand is a business contract, which is where the solution should be. In that case, Jose also provides the solution I would recommend, and that is to de-identify the source organization identifiers. I would add that these de-identified (organization, provider, location, etc) should be proper Pseudonyms in that there will be legal reason to re-identify (legal challenge). --- note, i am not a lawyer, and you clearly need a lawyer. We are only providing technical solutions that are informed by the FHIR capability and our understanding of GDPR.
Last updated: Apr 12 2022 at 19:14 UTC
