Stream: Security and Privacy
Topic: NoConsent
Jose Costa Teixeira (Aug 05 2019 at 15:17):
Is there a way to express "this doctor does not have my consent to work with my data, even if he is in my care team"?
John Moehrke (Aug 05 2019 at 15:21):
Yes, you can have a Consent resource that explicitly forbids access to specific data, to specific people, to specific purposeOfUse, etc... or combinations of such thing.
John Moehrke (Aug 05 2019 at 15:22):
see http://build.fhir.org/consent.html#6.2.7
John Moehrke (Aug 05 2019 at 15:25):
this example should be showing explicitly the concept you are asking about http://build.fhir.org/consent-example-notThem.html However the examples are known to need some fixup that we have not yet committed into continuous build
Jose Costa Teixeira (Aug 05 2019 at 15:27):
Where is the explicit "i do not consent"? I can't find it.
John Moehrke (Aug 05 2019 at 15:28):
Consent.provision.type == DENY
Jose Costa Teixeira (Aug 05 2019 at 15:29):
Ok i find it in the model. but I do not find it in the example resource instance
John Moehrke (Aug 05 2019 at 15:30):
this example should be showing explicitly the concept you are asking about http://build.fhir.org/consent-example-notThem.html However the examples are known to need some fixup that we have not yet committed into continuous build
RIGHT.. the examples are broken... the use-cases that drive the examples are good... we just got broken examples over time, and haven't fixed them... yet
John Moehrke (Aug 05 2019 at 15:32):
@David Pyke has CR to fix the examples. We WILL fix the examples...
Jose Costa Teixeira (Aug 05 2019 at 15:32):
let me know if I should help with anything. You know I think we still have to sharpen this a bit, but this case is a clear case of consent to me, so I will use this.
John Moehrke (Aug 05 2019 at 15:33):
can you confirm that the narrative on the Consent page is clear? We think it is, and think it is globally relevant... We did use use-case driven analysis. Just that the examples got away from us.
Jose Costa Teixeira (Aug 05 2019 at 15:38):
Last time we spoke i had understood that consent should also cover what I call "permission" (for which consent is not that relevant for GDPR) but the narrative is very clear that it is only for expression of consent (positive or negative).
Jose Costa Teixeira (Aug 05 2019 at 15:39):
but the narrative seems clear for the "consentment" use cases. i will confirm later, hopefully today
Jose Costa Teixeira (Aug 05 2019 at 15:40):
I want to do something on GDPR, that is why i express my hesitation, but to your question - it seems clear, let me see if I find any improvements. With sufficient examples you will cover a good set of use cases.
Jose Costa Teixeira (Aug 06 2019 at 19:43):
i think i have a rather different and data model on this matter. the consent resource model seems clear but is not something I find easy to articulate with the Consent resource.
Jose Costa Teixeira (Aug 06 2019 at 19:44):
and the text steers me in a different direction than what I have when looking at the resource structure.
Jose Costa Teixeira (Aug 06 2019 at 19:50):
so in this case I would use consent resource as is, but i will work on a model that could better support gdpr
Jose Costa Teixeira (Aug 06 2019 at 19:51):
the narrative was complicated to go through, but eventually i found the information needed
John Moehrke (Aug 07 2019 at 12:59):
I am unclear on what you mean by "gdpr". I am very familiar with GDPR, but those in the security workgroup from Europe did an assessment and did not find gaps to fill. They did find that an implementation guide would be useful, and that implementation guide might need to create regional vocabulary for things like activities and purpose of use. So I expect that you have identified some gap, it would be good to express what that gap is rather than just saying it is "gdpr". see https://confluence.hl7.org/display/SEC/FHIR+-+GDPR
Jose Costa Teixeira (Aug 07 2019 at 15:17):
Ah I almost forgot this page. Now there are 2 things that I think should be reviewed.
Jose Costa Teixeira (Aug 07 2019 at 15:21):
You asked if the guidance was clear, I replied it is somewhat clear, but my GDPR eyes on it cannot find the right focus.
Jose Costa Teixeira (Aug 07 2019 at 15:21):
I do not see the basic notion of "Permission to use data". I see something as "requirements to process data" which I can interpret in different ways, and then we just go into Consent as if Consent (GDPR speaking) were the most common or relevant ground to data processing.
Jose Costa Teixeira (Aug 07 2019 at 15:23):
If our metadata model is different, then it will be unclear to me. And I do not know what is the scope of the security group ppl from Europe. If it is Data subject rights and consent, it is ok, but to me the corollary of GDPR is Article 30. There I see gaps
Jose Costa Teixeira (Aug 07 2019 at 15:24):
I did capture "my" metadata model and I will need to implement something soon, so if I can be of help I will gladly do so, assuming that we are not going to orbit around Consent only.
John Moehrke (Aug 07 2019 at 15:50):
I do not see the basic notion of "Permission to use data". I see something as "requirements to process data" which I can interpret in different ways, and then we just go into Consent as if Consent (GDPR speaking) were the most common or relevant ground to data processing.
a "Permission to use data" is what the Consent resource is encoding. Mecanically I could understand how it could be viewed by access control engine purely as a 'requirements to process data', but that is just a perspective of an enforcement engine that has no interest in the context that leads up to the permission being granted. I would definitely like to understand how we can improve the text to be understood better, and used properly.
John Moehrke (Aug 07 2019 at 15:51):
If our metadata model is different, then it will be unclear to me. And I do not know what is the scope of the security group ppl from Europe. If it is Data subject rights and consent, it is ok, but to me the corollary of GDPR is Article 30. There I see gaps
The Consent resource is not owned by Security. It is owned by the CBCP workgroup which is charged with the Privacy focus. Security is engaged as the expectation is that security would be called upon to enforce the rules encoded in a Consent along with the normal Business rules including RBAC or ABAC.
Jose Costa Teixeira (Aug 07 2019 at 16:02):
a "Permission to use data" is what the Consent resource is encoding.
Thanks, that is the recurring discussion topic. "Consent" has different meanings as you said but
"Permission to use data" is "we need to send prescriptions to the insurance company in performance of our contract with them, and we did not need to ask the patient". or "we need to send TB results to the ministry because this is mandatory, and the patients do not have a say in that"
I do not read that in Consent.
John Moehrke (Aug 07 2019 at 16:08):
The use-cases for Consent are when one must get authorization/permission from the subject. The Consent resource can be used without a .subject element, for which the permit/deny rules apply to something other than data about the subject. For example in the Provider Directory space they use the Consent to hold rules on permissions to change a Provider Directory entry.
John Moehrke (Aug 07 2019 at 16:18):
I do recognize your interest in having a way to encode business access control rules that are agnostic to the subject. I would recommend that this is not FHIR specific, that a general purpose IT language for encoding access control rules would be best. Otherwise FHIR would be just re-inventing that standard and one would not be able to utilize tooling available for using that standard. Examples of these lanaguages are XACML,
Jose Costa Teixeira (Aug 07 2019 at 16:23):
Yes, the rules are in XACML, and that is good information.
Jose Costa Teixeira (Aug 07 2019 at 16:23):
What do we do with this?
"at any time of collection or processing of personal data we must know on which basis this has been done and for what purpose"
Jose Costa Teixeira (Aug 07 2019 at 16:24):
that should be there first for a GDPR analysis - "Why / for what is this data here".
The other part - "what are the rules that will determine what we can do" can be handled later.
Jose Costa Teixeira (Aug 07 2019 at 16:42):
Just to tune my own language:
it's not really about "agnostic to the subject" but "agnostic of what the subject has to say, if anything"
John Moehrke (Aug 07 2019 at 18:01):
is that a distinction without a difference?
John Moehrke (Aug 07 2019 at 18:02):
so... will Consent resource work for you where the .subject is not specified?
John Moehrke (Aug 07 2019 at 18:04):
example from the Provider directory (which I think needs some adjustments, but here it is)
<Consent>
<id value="restrict"/>
<meta>
<profile
value="http://hl7.org/fhir/uv/vhdir/StructureDefinition/vhdir-restriction"/>
</meta>
<status value="active"/>
<scope>
<coding>
<system value="http://hl7.org/fhir/uv/vhdir/CodeSystem/consent"/>
<code value="protect"/>
<display value="Protect"/>
</coding>
<text value="Direct Referral use only"/>
</scope>
<category>
<coding>
<system value="http://loinc.org"/>
<code value="57016-8"/>
<display value="Privacy policy acknowledgement Document"/>
</coding>
<text value="conditional release (per DUA)"/>
</category>
<dateTime value="2017-12-18"/>
<policy>
<uri value="http://example.org/federal/policy#womans-shelter"/>
</policy>
<provision>
<type value="permit"/>
<actor>
<role>
<coding>
<system
value="http://terminology.hl7.org/CodeSystem/v3-ParticipationType"/>
<code value="IRCP"/>
<display value="information recipient"/>
</coding>
</role>
<reference>
<display value="Blue Team @ The W shelter (CareTeam)"/>
</reference>
</actor>
<action>
<text value="specific value"/>
</action>
<securityLabel>
<display value="womens-abuse-councellors"/>
</securityLabel>
<purpose>
<display value="Women's Shelter"/>
</purpose>
</provision>
</Consent>
John Moehrke (Aug 08 2019 at 14:54):
@Jose Costa Teixeira I invented a use-case, inspired by your comments and the Provider Directory. I then did use-case analysis trying to write the sub-policy in a Consent resource. WOW this is ugly. I do agree that there might be a sub-set of use-cases that are not specific patient scoped, so we need these kind of use-cases brought forward so that we can better define the solution. See GF#23072
John Moehrke (Aug 08 2019 at 14:55):
I am still not convinced that this should be a FHIR specific solution... but until we do some use-case analysis, based on actual use-cases, we can't tell.
John Moehrke (Aug 08 2019 at 14:56):
of concern for me is that the use-case clearly needs to involve two parties needing to dynamically communicate policy sets. Most of the time organizations do this on paper as the policy tends to involve far more than is useful to code in access control rules.
John Moehrke (Aug 08 2019 at 15:00):
As we discussed, I could envision taking the <provision> structure out of Consent and putting it into a general security owned resource. And thus have Consent reference this other resource rather than include different provision rules.
Jose Costa Teixeira (Aug 08 2019 at 17:54):
thanks @John Moehrke . This is one step forward.
Just to be clear, I agree exchanging policy sets (if I understand it correctly) is not the most important.
The core of my questions is to exchange "why and for what do I have data from Mr Doe" which is one between policy and consent.
Jose Costa Teixeira (Aug 08 2019 at 17:55):
Good proposal, I will help with the use cases.
John Moehrke (Aug 08 2019 at 17:57):
can you describe that in human readable terms? I am working on another use-case that is more focused on attaching terms to a bulk-data export... but it is mostly made up of terms that can be placed on the Bundle.meta.security as obligation vocabulary values (only for research project XYZ, do not redisclose, must keep in encrypted form at all time, etc). No need for a policy resource if it can be expressed as a set of obligations.
John Moehrke (Aug 08 2019 at 17:58):
I am thinking the bulk-data export terms might be something like this
<text>
<status value="narrative"/>
<div xmlns="http:www.w3c.org/1999/xhtml">
<p>Permissions given by an organization to bulk data export</p>
<p>
Given that a bulk-data request is authorized, this Consent policy set expresses the authorizations given to the recipient and the obligations that recipient is under.
</p>
<p>
Note that the policy that authorized the release of data is managed by the custodian, and there is no benefit to it being encoded in an interoperable form. It might be encoded using XACML or some other language.</p>
<p>Specific conditions of this release of data authorization</p>
<ul>
<li>May be used for only Research Project (Purpose) XYZ</li>
<li>Must be stored in encrypted form at all time data is at rest</li>
<li>Must not be disclosed in itemized form to any party beyond Organization ABC.</li>
<li>May be disclosed in summarized form that can be proven to not identify any group smaller than 2000 individuals (k)</li>
<li>No contact can be made directly by Organization ABC to any individual</li>
<li>Custodian DEF will maintain a re-identification mechanism for 10 years for the sole purpose of addressing patient safety concerns uncovered during research or for any breach notification</li>
<li>All access to re-identification mechanism is controlled by Custodian DEF under terms managed by Custodian DEF</li>
</ul>
</p>
</div>
</text>
John Moehrke (Aug 08 2019 at 17:58):
I really want to start with human readable use-case, and do the analysis off of that. Starting with a solution and imagining what it is solving is not a good model for design.
Jose Costa Teixeira (Aug 08 2019 at 17:59):
I will try writing it in Human.English
Jose Costa Teixeira (Aug 08 2019 at 18:01):
(it's not so easy because some words are overloaded or have an intrinsic "feel" in other languages)
Jose Costa Teixeira (Aug 08 2019 at 18:03):
my starting point would be
a)(my understanding of) Art 30 of GDPR, and
b) my perspective that whatever data we exchange, should come along with a label on "why and how to use this".
John Moehrke (Aug 08 2019 at 18:29):
that is the spirit of my latest use-case on bulk-data export. using bulk-data as it is not ONE patient, but would have terms.
Jose Costa Teixeira (Aug 08 2019 at 19:11):
I would also want for one patient ("why and for what do I have data from Mr Doe")
John Moehrke (Aug 08 2019 at 22:25):
I think that any usecase involving a patient is what we have stressed today. I am glad to do the use-case analysis.
Last updated: Apr 12 2022 at 19:14 UTC
