Stream: Security and Privacy
Topic: Consent Provisions
Mohammad Jafari (Jun 07 2020 at 17:36):
As part of the implementation of consent in the ONC LEAP project, we have identified some issues with the current provision structure. I wanted to share this here for some feedback before I file a CR.
https://sdhealthconnect.github.io/leap/blog/2020/05/13/provisions.html
Jose Costa Teixeira (Jun 07 2020 at 20:44):
I don't know if you want to apply this to Consent (as in patient-given consent) or if this applies to Permission (if that stands).
Jose Costa Teixeira (Jun 07 2020 at 20:44):
The description seems to be for "permission-like" provisions, whether it is patient-given or policy-driven
Mohammad Jafari (Jun 07 2020 at 21:28):
Our focus is on Consent for now. I think when/if the Permission resource is released and more widely used, the Consent resource may have to go through more changes to offload the "rules" parts to a Permission resource but right now we're focusing on Consent as it stands.
Jose Costa Teixeira (Jun 07 2020 at 21:40):
ok I just wanted to confirm. I think the approach makes sense - adding a provision about if rules are conflicting.
Jose Costa Teixeira (Jun 07 2020 at 21:40):
About the implementation approach - a set of codes combning {what} {happens} - e.g. {permit} {overrides} - is that robust enough? what about other things like {court-ordered} {overrides}? Or more possible combinations, like "this overrides all permits unless patient is dead". ?
Or you don't want to cover that?
Mohammad Jafari (Jun 07 2020 at 21:53):
I think this is purely at the rules-level. When you evaluate a request context against a collection of rules, the outcome for each rule is either permit, deny, or notApplicable(i.e. the request didn't match the rule and therefore the rule does not say anything about the request). Now, if more than one rule match the request and they have conflicting decisions, i.e., one says deny and another says permit, we need a conflict resolution strategy to reconcile these decisions and make a final call. The common conflict resolutions in the access control policy and rights languages are the ones I have listed. Other conflict resolution strategies can of course be considered as long as the consent processor can actually have a well-defined way of applying them.
John Moehrke (Jun 08 2020 at 13:00):
might we experiment with your new model in the Permission resource first?
John Moehrke (Jun 08 2020 at 14:48):
@Mohammad Jafari can you correct this paragraph in your article so that I can understand what you mean to be saying? I think you have too many "except" in the sentence and can't figure out which is not intended:
Figure 2 shows a (hypothetical) example for this model. These provisions articulate that during the time period from 01/01/2020 to 31/12/2022, all access except is permitted except:
John Moehrke (Jun 08 2020 at 14:56):
I am not following why Figure 2 and 3 have the effect on Org1 and HLEGAL you assert.
Mohammad Jafari (Jun 08 2020 at 14:59):
Thanks @John Moehrke I fixed that typo.
John Moehrke (Jun 08 2020 at 15:00):
firstMatchOverrides presumes ordered lists. I don't think that FHIR guarantees ordered lists
John Moehrke (Jun 08 2020 at 15:01):
note the reason I had permit/deny in the original model was following the override model. Just never got the chance to get the override concept into the model before nesting took over.
Mohammad Jafari (Jun 08 2020 at 15:03):
I agree that firstMatchOverrides (and any other order-based logic) is not a good idea.
Mohammad Jafari (Jun 08 2020 at 15:09):
I am not following why Figure 2 and 3 have the effect on Org1 and HLEGAL you assert.
In Figure 2, the default is permit and a request by Org1 for the purpose of HLEGAL will not match any of the second-tier provisions therefore goes by the default in the root which is permit.
In Figure 3, a request by Org1 for the purpose of HLEGAL matches the second-tier provision which denies anything by Org1 unless for the ones matching the third-tier provisions (none of which match the HLEGAL purpose).
John Moehrke (Jun 08 2020 at 15:14):
right. so Figure 2 is likely poorly designed policy fragment... which we can't stop bad policy writing. But I get your point that the current model is potentially easier to do something stupid
John Moehrke (Jun 08 2020 at 15:15):
The initial use-cases were simple http://build.fhir.org/consent.html#model
John Moehrke (Jun 08 2020 at 15:48):
note that repetitions at the element level (more than one .provision.class means that one must match ALL the values given). although this is not well stated on current Consent page. An OR is achieved with multiple .provision elements. So if one wants class of account, claim, OR claimResponse; one would need three .provision repetitions; which enables one to define a rule on data that has a class of account, claim, AND claimResponse. How would your proposal support AND and OR mechanics like this?
Mohammad Jafari (Mar 25 2021 at 19:30):
I have finally filed a CR for this: https://jira.hl7.org/browse/FHIR-31412
Last updated: Apr 12 2022 at 19:14 UTC
