Stream: Security and Privacy
Topic: Consent rules clarity
John Moehrke (Jan 29 2021 at 12:11):
@David Pyke I just added some CR to help draw some clarity to the provisions model in Consent
John Moehrke (Jan 29 2021 at 12:12):
Need to make more clear how in .provisions AND and OR are to be used.
The general rule that I designed, but I don't see stated anywhere. This was designed to enable all possible logic. This is also why the .provisions are not restricted on how deep they can go:
1) adjacent provisions are in an OR relationship
2) adjacent elements within a provision are in an AND relationship
3) all values within an element are in an AND relationship
John Moehrke (Jan 29 2021 at 12:12):
Thus
A) Permit Dr Bob for Treatment purpose access to vital-signs that are normal confidentiality and published between 2000-2020. This indicates that no one other than Dr Bob, nothing other than Treatment, nothing other than vital-signs, nothing other than data that are normal, and nothing outside of the timeframe. Thus this is all encoded in one sub .provision. The parent provision would be a DENY, and this sub .provision would have have elements indicating these.
* provision.type = #deny
* provision.provision[0].type = #permit
* provision.provision[0].actor = Dr Bob
* provision.provision[0].purpose = #Treatment
* provision.provision[0].class = #vital-signs
* provision.provision[0].securityLabel = #N
* provision.provision[0].datePeriod = 2000-2020
```
John Moehrke (Jan 29 2021 at 12:13):
B) Permit Dr Bob, Permit Treatment purpose access, permit vital-signs, permit normal confidentiality, and permit data published between 2000-2020. This indicates that Dr Bob is to be permitted for everything, Treatment purpose of access for everything, vital-signs for any purpose, normal confidentiality tagged data, and permit data published between 2000-2020
* provision.type = #deny
* provision.provision[0].type = #permit
* provision.provision[0].actor = Dr Bob
* provision.provision[1].type = #permit
* provision.provision[1].purpose = #Treatment
* provision.provision[2].type = #permit
* provision.provision[2].class = #vital-signs
* provision.provision[3].type = #permit
* provision.provision[3].securityLabel = #N
* provision.provision[4].type = #permit
* provision.provision[4].datePeriod = 2000-2020
of course these are all in an OR relationship, which given the rules will result in permitting everything. Thus the result of this is to permit everything not explicitly denied, and given the parent clause didn't explicitly deny anything specific, the result is everything is permitted under the consent base policy.
* provision.type = #permit
John Moehrke (Jan 29 2021 at 12:15):
C) Permit requests for Treatment, Payment, and Operations. Which means Permit Treatment and Permit Payment, and Permit Operations, or any combination of the three. Are encoded how? Does this require three .provision elements? or is this done with one .provision with three values in the .purpose? I tend to think that this argues that they must be in an AND relationship, thus to encode this TPO use, we need three .provisions.
so this authorizes request that declare they want Treatment, Payment, AND Operations access. But this would not authorize someone asking only for Treatment:
* provision.provision[0].type = #permit
* provision.provision[0].purpose[0] = #Treatment
* provision.provision[0].purpose[1] = #Payment
* provision.provision[0].purpose[2] = #Operations
so this authorizes requests that declare they want Treatment, payment, AND Operations access, but would also authorize access requests for only Treatment, or only Payment, or only Operations, or Treatment+Payment, or ....
* provision.provision[0].type = #permit
* provision.provision[0].purpose[0] = #Treatment
* provision.provision[1].type = #permit
* provision.provision[1].purpose[0] = #Payment
* provision.provision[2].type = #permit
* provision.provision[2].purpose[0] = #Operations
Mohammad Jafari (Mar 04 2021 at 19:18):
Thanks @John Moehrke if we are opening the discussion on provisions, I want to share our findings in LEAP as well.
https://sdhealthconnect.github.io/leap/blog/2020/05/13/provisions.html
The gist of our proposal is to get rid of the recursive, multi-level provision structure and use a flat array of provisions together with a decision combining strategy. I will file a CR to that effect as well to be considered in the new round of updates to the consent resource.
David Pyke (Mar 04 2021 at 19:23):
Please do!
Mohammad Jafari (Mar 04 2021 at 23:17):
@David Pyke FHIR-31412
Jose Costa Teixeira (Apr 02 2021 at 09:59):
I am surprised that the patients would sign off on these things. You have very patient patients
Jose Costa Teixeira (Apr 02 2021 at 10:01):
(i.e. the amount of rules and their complexity). We also do something like that in Europe but it becomes a blanket consent for being treated, which is one of the misuses I think were introduced with the GDPR rush.
John Moehrke (Apr 02 2021 at 11:36):
@Jose Costa Teixeira the change is just a change in the encoding. The complexity is still supported. However we have not been presented with anyone that wants to do anything other than a few exceptions to a base policy.
Jose Costa Teixeira (Apr 02 2021 at 11:40):
Ok. I was just feeling for the patient.
I think it is good to support more complex scenarios (hoping that this complexity does not end up on the patient)
John Moehrke (Apr 02 2021 at 11:54):
There is nothing we can do to make it easier or harder on the Patient. That falls to those writing the policies, writing the User Interface, etc.
Josh Mandel (Apr 02 2021 at 14:09):
I'm not sure about that. Often the features supported by a system influence how the system is leveraged in implementations, which in turn influences usability.
Last updated: Apr 12 2022 at 19:14 UTC
