Stream: Security and Privacy
Topic: Consent perspective
John Moehrke (May 08 2019 at 14:14):
@Jose Costa Teixeira has an excellent visualization of the various elements of a Privacy Authorization
http://zeora.net/blog/2019/05/06/data-processing-and-privacy-metadata-analysis/
Jose Costa Teixeira (May 09 2019 at 16:30):
I will try to join some discussions with this group to discuss some steps, e.g. perhaps propose a new construct called "ProcessingPermission".
Could be a resource, a complex data type...
Jose Costa Teixeira (May 09 2019 at 16:34):
what is the best time to do that?
John Moehrke (May 09 2019 at 18:39):
weekly CBCP t-con. Check the hl7 calendar for when that is
Zoran Milosevic (May 15 2019 at 02:07):
Yes, quite nice conceptual presentation of the consent problem. Looks like 'justification' is similar (or the same) as the concept of 'purpose' in the existing consent resource. Correct ?
Jose Costa Teixeira (May 15 2019 at 14:44):
Justification is "why do i think i can do this with the data"
Jose Costa Teixeira (May 15 2019 at 14:44):
so I think those are different. At least in the analysis
Jose Costa Teixeira (May 31 2019 at 15:10):
btw, @John Moehrke when is a good time to discuss an eventual proposal for a "permission" resource ?
Lloyd McKenzie (May 31 2019 at 15:11):
How would a 'permission' resource relate to the existing request resources - and the 'directive' intent?
Jose Costa Teixeira (May 31 2019 at 15:12):
"permission" is: what is known about whether/how this data can be used
Lloyd McKenzie (May 31 2019 at 15:13):
And this is distinct from Consent?
Jose Costa Teixeira (May 31 2019 at 15:14):
yes, and I think you mentioned an example of that recently, @Lloyd McKenzie
Lloyd McKenzie (May 31 2019 at 15:15):
You expect me to remember what I've mentioned?? ;)
Jose Costa Teixeira (May 31 2019 at 15:16):
no????? I'm trying to find it anyay ;)
Jose Costa Teixeira (May 31 2019 at 15:20):
i can't find it. perhaps it was another Lloyd Mckenzie. Or perhaps i was sleep deprived. anyway:
Jose Costa Teixeira (May 31 2019 at 15:22):
some discussion here - https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/FHIR-Security.20and.20Privacy.20Overview.20Mon.20Q3
and I think in a related topic there was a statement that "the fact that we can use the data may have something or nothing to do with consent".
Jose Costa Teixeira (May 31 2019 at 15:24):
so, Permission is: a) what data can be used, b) for what purpose, c) the supporting documentation etc.
John Moehrke (May 31 2019 at 15:24):
I think what @Jose Costa Teixeira is wanting is what we have modeled in Consent, but might be intentially abstracted. One of the problems with the word "Consent" is that it is overloaded with many more things than simply 'these permissions are authorized, and these permissions are denied'. We think we have modeled this 'more things' too, but there is continued disagreement.
Jose Costa Teixeira (May 31 2019 at 15:25):
for what data can be used, i think we can use a GraphDefinition
John Moehrke (May 31 2019 at 15:25):
We might be simply wanting to rename "Consent" to "Permission" and it would suit
John Moehrke (May 31 2019 at 15:25):
There has been discussion of supporting GraphDefinition in Consent resource, but no one who understands GraphDefinition has stepped forward to offer how that works.
John Moehrke (May 31 2019 at 15:26):
if that is all we need, then we can add it to Consent.
John Moehrke (May 31 2019 at 15:26):
If the worry is about the word "Consent" then we can discuss renaming the whole thing to "Permission" or some other word.
Jose Costa Teixeira (May 31 2019 at 15:26):
yes, consent is overloaded, but the stated scope of consent seems to indicate what the patient agreed with. And normally, we don't really care if the patient agrees that the prescription system will share the patient's name with the nurse's mobile app.
John Moehrke (May 31 2019 at 15:27):
I am not against renaming, as there clearly is emotional/legal issues around the word "Consent"
Jose Costa Teixeira (May 31 2019 at 15:27):
or if the patient agrees that their treatment data can be shared with their insurance
John Moehrke (May 31 2019 at 15:27):
hmmm... those specific rules are expected to be encoded in ways that don't need to be interoperable.
John Moehrke (May 31 2019 at 15:28):
as in the business rules that make things work...
John Moehrke (May 31 2019 at 15:28):
the Consent resource is only after the kinds of permissions that the patient CAN affect
Jose Costa Teixeira (May 31 2019 at 15:28):
ah then perhaps we need indeed another resource.
John Moehrke (May 31 2019 at 15:28):
those that the patient can't affect are considered part of business
John Moehrke (May 31 2019 at 15:29):
why? IN what way do these business rules need to be interoperable?
John Moehrke (May 31 2019 at 15:29):
they certainly affect the interface.. permit/deny... but why would one organization need to see another organizations business rules?
John Moehrke (May 31 2019 at 15:30):
@David Pyke --- FYI Discussion on Consent.
Jose Costa Teixeira (May 31 2019 at 15:32):
not sure if they are business rules - i see them as suporting documentation for GDPR Art 30 (record of processing).
every time someone transfers data, I imagine this comes with a label - "This is what you need to know about this data for when you use it or pass it forward".
John Moehrke (May 31 2019 at 15:32):
We do have security lables for data (Resources) and bundles for that kind of thing.
Jose Costa Teixeira (May 31 2019 at 15:33):
There has been discussion of supporting GraphDefinition in Consent resource, but no one who understands GraphDefinition has stepped forward to offer how that works.
I asked about the time for such a discussion so taht I could prepare accordingly.
John Moehrke (May 31 2019 at 15:33):
Specifically there are a set of Obligations that one would apply to a bundle being communicated
John Moehrke (May 31 2019 at 15:33):
got it... I wasn't trying to get the discussion over with.. I am myself trying to understand the topic so that I too can prepare.
Jose Costa Teixeira (May 31 2019 at 15:34):
indeed, good to pre-align.
David Pyke (May 31 2019 at 15:37):
Reading back, it seems that the Security Labels and the Consent resource cover your use cases. When sending data forward, the security label should indicate permitted use, Consent allows for override of the security label
John Moehrke (May 31 2019 at 15:37):
the FHIR GDPR effort has uncovered a need to write an IG that discusses these kinds of details ... when would Consent be used, how deep does Consent document... What tags would be used in meta.security on data (facts about the data itself only), vs the other kinds of tags (e.g. Obligations) that would be used on a Bundle to communicate conditions of a communication. these things have not been said well enough, and it continues to draw misunderstandings.
John Moehrke (May 31 2019 at 15:41):
as to WHEN... @David Pyke would host this on the CBCP call, which is more EU friendly. They likely can host you anytime during their normal tuesday call. I suspect, it will take a few discussions to tease out the issues and actions.
Jose Costa Teixeira (May 31 2019 at 15:42):
In my post I post at the metadata needs. In FHIR, I still find a gap between that, and what we can do with security labels + consent.
Jose Costa Teixeira (May 31 2019 at 15:42):
Consent is simply evidence that the patient agrees with something - with data sharing, or going under surgery, or paying the bills...
I want to see how we transmit the rest of the information: When someone says "For this purposes (treatment and billing) this data doesn't need consent to be shared, but for marketing purposes, the patient has agreed with it."
John Moehrke (May 31 2019 at 15:42):
Note that I like renaming Consent to Permission.. which aligns better with negative authorizations, and also addresses the Provider Directory permissions that are not patient centric.
Jose Costa Teixeira (May 31 2019 at 15:42):
and most interesting, "For purposes of treatment, only the following data can be shared with these entities" (example: sharing psychiatric treatment data only with psychiatrist)
Jose Costa Teixeira (May 31 2019 at 15:43):
I start from the other end - i prefer a non-contaminated name and a clean slate to scaffold something, and if at the end we realise this is Consent we do it. Looking at requirements, flwshing them out, and only then projecting them in a solution
Jose Costa Teixeira (May 31 2019 at 15:44):
sorry if this seems fuzzy. I will try to update the post or make another one.
John Moehrke (May 31 2019 at 15:44):
question I have on that... is this a communication need? Or a storage need? FHIR should address communication needs, but does no address storage needs... as in, what is the use-case when a sender of data includes complex permissions to a recipient? All use-cases today are rather single PurposeOfUse centric... not to say there are none, but we need clear use-case to model this properly.
Jose Costa Teixeira (May 31 2019 at 15:45):
anyway, the best is to participate in a call where we have time for this.
John Moehrke (May 31 2019 at 15:45):
yes, agreed
David Pyke (May 31 2019 at 15:46):
Perhaps the three of us could get together on a call early next week to get a better understanding of the use case. Then we can bring specific recommendations to Security and CBCP
John Moehrke (May 31 2019 at 15:48):
yes
Jose Costa Teixeira (May 31 2019 at 15:52):
yep, let me know how/when
David Pyke (May 31 2019 at 16:03):
Jose, what time zone are you in?
Jose Costa Teixeira (May 31 2019 at 16:04):
Father-of-a-newborn timezone: what is a timezone? What is time?
Jose Costa Teixeira (May 31 2019 at 16:05):
Europe time
David Pyke (May 31 2019 at 16:05):
Europe has more than one timezone. I checked
David Pyke (May 31 2019 at 16:05):
UTC+1 +2?
David Pyke (May 31 2019 at 16:05):
UTC-1?
Jose Costa Teixeira (May 31 2019 at 16:06):
indeed :) as of next week, UTC +2
Jose Costa Teixeira (May 31 2019 at 16:06):
sorry, +1
Jose Costa Teixeira (May 31 2019 at 16:07):
Brussels
Jose Costa Teixeira (May 31 2019 at 16:10):
(now wishing i was in UTC-1)
Last updated: Apr 12 2022 at 19:14 UTC
