Stream: implementers
Topic: Data Ownership
Jose Costa Teixeira (Oct 02 2017 at 13:06):
Hi. Likely outside of the scope of FHIR at least for now, but is there any notion of who owns the data that is in the resources? Say, an appliance (in Software-as-a-service mode) uses FHIR resources to represent the data. Between the patient, the physician, the device vendor and the hospital - who owns the data. Is there any clarity?
John Moehrke (Oct 02 2017 at 13:09):
Please explain your definition of 'ownership'? The concept of 'custodian' is understood, where the data is managed. The concept of 'rights holder', covers who must be asked for rights to do something... But 'ownership' is a concept that is only applied to something that is physical, and thus can only be in one place at a time.
Jose Costa Teixeira (Oct 02 2017 at 13:12):
thx. something between "custodian" and "rights holder".
Simple question is "who can sell the data". I imagine that in a world where data is sold by the millions, this should be a common question now.
John Moehrke (Oct 02 2017 at 13:15):
That is the rights holder. This is classically the patient (or subject of the data); but they might have given consent to another actor to do specific things. One of those specific things might be to "sell in de-identified form", or even to "sell in fully identified form".
Stefan Lang (Oct 02 2017 at 13:26):
That would basically be a Consent instance.
If the consent covers only a part of the patient's resources (like "only the conditions, hemoglobin data and all medication"), there still would have to be a way to identify these. One could use tags for that, or an extensions referencing the consent. Depends on the use case. IMHO in any case something that would be part of the system's business logic.
John Moehrke (Oct 02 2017 at 13:33):
Nicely said Stefan. I would recommend that the Consent reference the data, not the data referencing the consent. The reason: Data does not change, but policies change often. Thus a system that is designed around Policy pointing at the data will be more sustainable over the changes that happen over a lifetime, and keeps the data 'medical records' from changing... This is why the Consent resource has many abilities to vector through the data space, with the most specific is .provision.data.reference to point at specific instances if that is what the policy needs... http://build.fhir.org/consent.html
René Spronk (Oct 04 2017 at 14:51):
@Jose Costa Teixeira You may wish to read up on the GDPR in Europe should you not be aware of it, e.g. via the links in http://www.ringholm.com/column/GDPR_impact_on%20healthcare_data_interoperability.htm - if one looks at the rights of the patient under that directive (right to ask for deletion, right to move the data elsewhere, right to limit the sharing of data by a healthcare provider / software vendor, ..) one could say that to a very large degree the patient "owns" the data. But the patient doesn't have full control however, one has to balance the interests of the patient with those of a healthcare provider and/or software vendor, and in turn balance that with the interests of society as a whole.
Jose Costa Teixeira (Oct 04 2017 at 14:53):
Thanks @René Spronk Forgot to mention: I am looking at this from a GDPR implementation perspective as well. I'm implementing that beast, so i am somewhat aware... :-)
Jose Costa Teixeira (Oct 04 2017 at 14:54):
I guess "one could say that to a very large degree the patient "owns" the data." is a valid point, but does he really? I mean, the patient is owning the information and its possible uses, but doesn't the hospital / IT vendor own the data that represents the information?
Jose Costa Teixeira (Oct 04 2017 at 14:55):
Once the data becomes de-identified, I guess it's no man's land, i mean there is no law, and contracts will dicatae ownership.
Patrick Werner (Oct 04 2017 at 14:58):
Please specify de-identified. Pseudomized data is still "owned" by the patient. As he has the right to ask for the delition of this data at any time.
Jose Costa Teixeira (Oct 04 2017 at 14:59):
welll, right to deletion is not supreme. Not according to GDPR, i think
Jose Costa Teixeira (Oct 04 2017 at 14:59):
The vital interests of the patient overrule the consent (if a guy is in shock I break any glass to see what he is allergic to). And of course legal aspects (i cannot delete my medication history to hide my opioid addiction)
Jose Costa Teixeira (Oct 04 2017 at 15:00):
(GDPR, not fhir fact: If data rights were absolute, we'd all go to the tax authorities right now and delete our history)
Jose Costa Teixeira (Oct 04 2017 at 15:02):
I don't want to make this a GDPR thing, but more of a "in your opinions or countries, is there any practice on how data ownership is handled"? I am thinking Data-as-a-service.
René Spronk (Oct 04 2017 at 15:05):
Article 9.2(j) of the GDPR is a typical example of where 'society as a whole' has rights that override those of the individual, i.e. one can't stop research from taking place on pseudonymous data. Article 9 lists only few of those cases, none of which (to me) seems to be a ground for "selling pseudonymous data". It could happen in a research context, article 89 doesn't specifically address the issue of payment/non payment, it only discusses the safeguards that have to be in place.
Jose Costa Teixeira (Oct 04 2017 at 15:06):
right! if I have pseunonymized data and I sell you that , but don't give you the key to re-identify, then you get anonymized data, right?
René Spronk (Oct 04 2017 at 15:10):
Data-as-a-service requires that the patient and/or a provider transmits data (hands over) to a third party (likely commercial). That will always require consent. It's easier if the storage is simply done on behalf of the provider, in which case that provider still the primary data controller.
René Spronk (Oct 04 2017 at 15:11):
If you provide the data, (for free, or for $, that doesn't matter) you need to identify a valid reason for doing so according to article 9. If there is such a valid reason, you can hand over the data to a third party.
Jose Costa Teixeira (Oct 04 2017 at 15:27):
agree. Point is: patient or provider? who must give consent for data to be reused- Patient. But is there any "ownership of the bits and bytes"?
Jose Costa Teixeira (Oct 04 2017 at 15:29):
sorry if this is challenging, I think you made me see things the better way: Ownership of data by an IT vendor or by a hospital actually may not exist before the patient consents, which kind of answers my question.
René Spronk (Oct 04 2017 at 15:46):
possession is 9/10ths of the law - but under GDPR one has to show/identify how one obtained the data, and the underlying reason (art 9 and 6) as to why one uses it for processing. Lots of Provenance resources.. and Consent.
Jose Costa Teixeira (Oct 04 2017 at 15:47):
indeed. So the answer becomes "who owns" is "whoever the patient agreed, and whoever has legitimate access to it"
John Moehrke (Oct 04 2017 at 16:26):
The questions you are asking are about Policy and Legal interpretation. Those are questions that should be asked of Policy and Legal experts. These are not questions that this community can answer. At least you can't get an authoritative answer, we all will willingly give you opinion.
Jose Costa Teixeira (Oct 04 2017 at 16:27):
Indeed, that is what I got (unless someone would point me to some legal texts). I'm thankful for the information.
John Moehrke (Oct 04 2017 at 16:27):
BUT, what we need to do is extract from that legal interpretation a set of fundamental 'reasonable policy patterns', these patterns are then used to confirm that the FHIR model can satisfy that pattern.
John Moehrke (Oct 04 2017 at 16:28):
The Consent resource has used ISO definitions of these patterns in the model driven development of the FHIR Consent resource
John Moehrke (Oct 04 2017 at 16:29):
ISO also has definitions of de-identification patterns, that have also been used by various implementations of de-identification.
Jose Costa Teixeira (Oct 04 2017 at 16:30):
wrt FHIR, by "reasonable policy patterns" should I expect a few code values for "justification of data sharing"? I haven't yet looked for the FHIR equivalent of a "data sharing agreement"
René Spronk (Oct 05 2017 at 06:09):
It would be reasonable to publish (as part of the FHIR spec) at least 2 GDPR based value sets: GDPRLawfulGround (article 6, 1a up to 1f - https://www.privacy-regulation.eu/en/6.htm) and GDPRSpecialDataprocessingReasons (article 9, 2a up to 2j - https://www.privacy-regulation.eu/en/9.htm). For healthcare data (each Resource) you'd have to capture BOTH.
Jose Costa Teixeira (Oct 05 2017 at 06:10):
Now we're talking! Agree, but I did not know where that would be.
Jose Costa Teixeira (Oct 05 2017 at 06:11):
where would we put it? Lawfulground does not apply to the data itself, but to the data transfer/processing
Jose Costa Teixeira (Oct 05 2017 at 06:12):
and it's kind of metadata, not transactional data.
Jose Costa Teixeira (Oct 05 2017 at 06:13):
so you would normally say "i need access to this patient's resource, and here is my justification for this access"
Jose Costa Teixeira (Oct 05 2017 at 06:16):
what I have in GDPR would correspond to something like: 1. There is a (static) repository of legal grounds. 2. There is a (design-time) list of "DPO-allowed data transfers" 3. Every query/response points to #2, not to #1
Jose Costa Teixeira (Oct 05 2017 at 06:18):
so, is there a mechanism to say "in this hospital, the following reasons to transfer data are approved, and systems using FHIR shall point to one of these reasons to get patient data"?
Jose Costa Teixeira (Oct 05 2017 at 06:21):
i guess securityLabels can be used on the request(?) but i lack knowledge on how this would look like
René Spronk (Oct 05 2017 at 06:38):
A: In Audit one would have to specify BOTH, and if you rely on Consent for processing, the details of the Consent.
B: In a data store one needs provenance as to where the data came from, for what processing reasons / uses the data was made available to that store, and any consents related to the data.
C: In a query I'd think you'd have the ability to specify what you'll be doing with the data that will be returned, or [in other words] the reason as to why you're querying (e.g. Break-Glass = Article 9.2(c) / Article 6.1(d)), and that you can provide any additional consents that may have an impact on the scope of the data that is to be returned. (I can seek additional consent once I discover that certain data is inaccessible to me). It's up to the access control engine of the receiving application to decide what they'll return, and if they return something: 1) it will be added to audit record (both by responder as well as querying party - see A above), and 2) the party which receives the data will have to store the data as well as any associated metadata that may impact its own future uses of that data (see B above)
My blog addresses some of the ways of doing this in FHIR, but I'll have to leave the details to the real FHIR Pundits.
René Spronk (Oct 05 2017 at 06:40):
.. and given that the above is fairly generic (not EU specific) I'm sure the security pundits will have to add something as well :-)
Jose Costa Teixeira (Oct 05 2017 at 06:40):
by "Consent" do you mean strictly patient consent, or also possibly "Consent can convey any approval"? Because consent provides one legal ground, but consent is not the same as legal ground.
Jose Costa Teixeira (Oct 05 2017 at 06:42):
C: I think in a query you would point to a pre-approved processing reason, not define one. I imagine that reasons for processing can not be done ad-hoc
Jose Costa Teixeira (Oct 05 2017 at 06:49):
I'll start looking at a use case and see how this would work - on the privacy part. The ownership seems clearer now
John Moehrke (Oct 05 2017 at 12:07):
The valuesets that we have and use in Consent, AuditEvent, and security labels are extensible; and are the very topics you are discussing. Where should the valuset be created? Somewhere EU centric. But making a ValueSet is rather easy.
John Moehrke (Oct 05 2017 at 12:09):
The scope of the Consent resource, in Privacy mode, is broad and inclusive of all forms of patient authorized data access. There are other usecases in scope for Consent resource for participation in an activity (study), and procedure (surgery). When the authorization is not specific to a patient, then Contract is recommended.
John Moehrke (Oct 05 2017 at 12:10):
please participate in those activities to help improve them.
Last updated: Apr 12 2022 at 19:14 UTC
