Stream: Security and Privacy
Topic: GDPR
Grahame Grieve (May 31 2019 at 05:25):
https://truthonthemarket.com/2019/05/24/gdpr-after-one-year-costs-and-unintended-consequences/
Jose Costa Teixeira (May 31 2019 at 06:52):
i find some the comments are more enlightening than the tone of the article.
Jose Costa Teixeira (May 31 2019 at 06:55):
There was at least one school not wanting to publish their student's grades at the end of the year because of GDPR. And IIRC some politicians hiring public nominees and not disclosing their name "because of privacy". That is not GDPR, that is ignorance IMO.
Jose Costa Teixeira (May 31 2019 at 06:56):
the fact that some companies are closing down or not operating as they were in Europe - well, not too bad.
Jose Costa Teixeira (May 31 2019 at 07:01):
but more interestingly for us, this: “[B]iomedical researchers fear that the EU’s new General Data Protection Regulation (GDPR) will make it harder to share information across borders or outside their original research context.”.
We could always share sufficiently anonymized data, both before and after GDPR. if researchers (many? a few? two?) are afraid, that is a matter of education and perhaps we can publish some guidance.
Grahame Grieve (May 31 2019 at 07:02):
I expect that they sought legal advice, and they got uncertainty back .
Grahame Grieve (May 31 2019 at 07:03):
doubt we can publish anything that will change that
Jose Costa Teixeira (May 31 2019 at 07:04):
which is common. i had an it manager asking if they should just rather prepare to wipe their entire DW.
Jose Costa Teixeira (May 31 2019 at 07:06):
i think if we publish guidance on some use cases and mention "how does this touch GDPR", that could bring some light. It's just an idea.
I agree there is lots of uncertainty.
John Moehrke (May 31 2019 at 11:45):
We do have https://confluence.hl7.org/display/SEC/FHIR+-+GDPR Comments are welcome
Jose Costa Teixeira (Jul 01 2019 at 21:19):
In one project we have the notion of "access matrix" which says who can access what information. This is identical to the resource I suggested - having a definition of what can be accessed under which circumstances (i am calling it Permission to avoid that it gets swallowed by Consent discussions).
Jose Costa Teixeira (Jul 01 2019 at 21:21):
Consent can hang from that, but is not the same. Use case (proposed by me, I can confirm if this is something we want to go live with):
Medication information is visible to all physicians with a therapeutic relation with the patient.
Psychiatry-related drugs, observations and treatment are visible to
a) all clinicians in the therapeutic area
b) entire care team IF the patient has given consent for this (from which we hang the consent).
John Moehrke (Jul 02 2019 at 13:01):
This is not unique to GDPR... The underlying security policy is indeed something that is independent of Consent. I think the only disagreement we have is if it is important for FHIR to have a Resource specific to this underlying security policy. FHIR does not need to cover everything, it just needs to cover healthcare specific things.
John Moehrke (Jul 02 2019 at 13:01):
Here http://wiki.hl7.org/index.php?title=Security_%26_Privacy_DAM is a early draft of our Privacy and Security DAM. (Formal document is hard to reference and read)..... You can see the permission and many other things
Jose Costa Teixeira (Jul 02 2019 at 19:50):
I think the only disagreement we have is if it is important for FHIR to have a Resource specific to this underlying security policy. FHIR does not need to cover everything, it just needs to cover healthcare specific things.
Agree that is where we may disagree.
I don't see this as a security policy, it's lower level than that, but that's not important. What matters is that I hear that we want to cover a few use cases, and we use Consent where Consent does not fit, and then IIRC the definition of Consent is not fixed yet...
GDPR introduced the notion of "valid permissions to use data" and consent became less overruling. If we don't want to cover GDPR beyond consent that is a fair statement, but I disagree. And if we want to have operations like $erase, we do not have in Consent enough information.
Jose Costa Teixeira (Jul 02 2019 at 19:54):
Note that I want to ensure there is a common language to these things - i promised to make a proposal to a "Permission-like" resource, but if that is not desired, then we can discuss further or i stop execting it.
GDPR is important in my project and I will a) use what FHIR has, or b) propose improvements, or c) just make custom solutions. 2 out of these 3 approaches will work; 2 out of these 3 approaches will be interoperable.
Jose Costa Teixeira (Jul 02 2019 at 20:01):
So, @John Moehrke and @David Pyke : as discussed, I plan to propose a mechanism for exposing permission to use the data - not eviddence to patient-expressed consent , but "stated permission to use which data". As discussed we can see what is in Consent and look at GraphDefinition or any other ways to achieve what we need.
I do not want to do some small edits on Consent for that, especially keeping the name, because the name would be misleading. And discussion is already overloaded, now imagine if we had a resource that means different things to different people.
I plan to use that concept for my project. Hopefully we can show GDPR working on FHIR.
John Moehrke (Jul 02 2019 at 20:08):
understood. and I support any experimentation. I just wanted it to be clear that not everything need be encodable in FHIR... Note that Consent is just for when a individual (patient) gives consent for some action, and a Privacy consent is when they give rules around how their data is allowed to be used. There are other things that Contract would cover... I imagine a Permission like thing to be something that both Contract and Consent could use, and possibly some other organizational structure for overall rules encoding... So I am not against you working on this, just not convinced that it is something that 'should' be a FHIR Resource.
Jose Costa Teixeira (Jul 02 2019 at 20:15):
as we discussed those changes, I understood indeed your encouragement to experiment. And I did have the impression of hearing that Consent resource was supposed to be more than just the patient-expressed consentment but I may be wrong and i'd disagree anyway. So we are good.
Let me materialise (not only concepts but example) and i will bring it up. For now I was just happy to realise that a national group of experts had a similar idea and they call it "access matrix".
John Moehrke (Jul 02 2019 at 21:28):
Typically a Consent resource is just the evidence that the patient has agreed to a 'policy'. The 'policy' is not encoded in the Consent, but the Consent does point at the 'policy'. If there are variables in the 'policy' (e.g. life-time when expires), they can be recorded in the consent. If there are exceptions the patient has with the 'policy' (e.g. Not Dr Bob), those exceptions are expressed in the consent provisions. If there are additional permissions the patient defines (e.g. Steve is my legal guardian), those would be expressed in the consent provisions. But the 'policy' body of the rules is managed externally to the Consent resource. The body of the 'policy' rules is common to all patients. Thus there is only one encoding of this overall policy.
Jose Costa Teixeira (Jul 02 2019 at 22:01):
i really want to escape the Consent gravity field.
Jose Costa Teixeira (Jul 02 2019 at 22:02):
patient agreeing or reading policy or not is not relevant for this use case, so that is not the starring point.
Last updated: Apr 12 2022 at 19:14 UTC
