Stream: Security and Privacy
Topic: Consent Question
Grahame Grieve (Feb 25 2019 at 04:38):
I'm looking at the R4 consent - it no longer has a basic policy like Consent.policyRule to which exceptions apply to. If, when I'm processing the R4 Consent, none of the provisions apply, how do I know whether the default answer is yes or no?
Grahame Grieve (Feb 25 2019 at 04:38):
@John Moehrke @Alexander Mense
Grahame Grieve (Feb 25 2019 at 04:41):
Also, I'd like to clarify the use of Consent.provision.actor.role - what would the right role be for the person using the restful interface to get information about the patient?
John Moehrke (Feb 25 2019 at 14:43):
The .policyRule is still at the root.
Im not happy about it either.. but the group chose to force all of that into the first provision. So you would put that base policy into the first provision, and nested provisions in provision.provision would be counter access rules, with potential to have provision.provision.provision counter rules to those. It seems that each provision should have had a .policyRule?
David Pyke (Feb 25 2019 at 16:33):
The actor.role is a policy decision. We simply allow for filtering based on that
David Pyke (Feb 25 2019 at 16:35):
Both Consent.policy and Consent.policyRule exist at the root. Where are you looking to see that it no longer applies or am I reading your comment wrong?
Mohammad Jafari (Feb 25 2019 at 18:25):
I want to add that the outcome of evaluating a consent resource against an access request is not necessarily either a yes or a no. It can be neither, as captured by the XACML NotApplicable. Whether or not a NotApplicable eventually results in denying or permitting access depends on the overarching policies and is beyond the scope of an individual consent policy.
Grahame Grieve (Feb 25 2019 at 23:12):
ok it did not change. But what's a consent engine to do if it runs through the provisions, and none of them apply?
Grahame Grieve (Feb 25 2019 at 23:13):
and I don't understand the response about actor role - if I'm making a consent statement, but I don't know how to describe what I'm consenting to, how can that work?
John Moehrke (Feb 25 2019 at 23:13):
in that case then that consent doesn't apply... this will happen... a Consent that authorizes a Research project will NOT apply to a Treatment usecase
Grahame Grieve (Feb 25 2019 at 23:16):
so. that raises question for me... how would a server know what the use case is?
Grahame Grieve (Feb 25 2019 at 23:17):
I don't believe that we've described that (or any options for that). The nearest we've come is: http://hl7.org/fhir/security-labels.html#break-the-glass
Mohammad Jafari (Feb 25 2019 at 23:19):
@Grahame Grieve
As I mentioned above, in this case the result should be NotApplicable. This is a common case in policy evaluation by an authorization engine.
"Grahame Grieve: ok it did not change. But what's a consent engine to do if it runs through the provisions, and none of them apply?"
Grahame Grieve (Feb 25 2019 at 23:21):
well, ok. have we defined a way for patient to say anything about the global outcome?
Grahame Grieve (Feb 25 2019 at 23:21):
actually, I guess, I'm asking whether we've defined anything about whether to stop processing and say that you've found an answer, or whether to keep looking for further exceptions to the rule
John Moehrke (Feb 26 2019 at 14:39):
Within one Consent, one walks all the provisions. When one finds a provision that applies and none of the nested exceptions apply; then that provision (PERMIT/DENY) applies... The vision that I originally had, which has been slightly upset by the redesign, was to lay the structure of the provisions very similar to XACML. Where in XACML the top most rule is the default that will be enforced if no underlying exceptions apply. This is somewhat how I explained the Consent provisions above. The main difference I had with XACML is that provisions are nested to show precidence, where in XACML it is an ordered list of rules with the last one stated in the policy-set is the default to use if no previous rule fired. The unknown is how exhaustively one must search the provisions, that is to say, how does one know that a provision applies 'better' than a provision that is listed later. XACML deals with this with ordered rules.
How one knows which Consent applies and which ones don't apply at all; likely requires exhaustive search.
Mohammad Jafari (Feb 26 2019 at 17:32):
@John Moehrke XACML uses target essentially as a mechanism to index policies/rules to match them against an incoming request. The idea is to have a simple condition (e.g. PoU) based on which rules can be indexed so that a quick scan of that index can narrow down the set of potentially applicable target policies/rules to examine further. More complex conditions are then expressed in the condition element which should be evaluated exhaustively for every matching target rule.
This model has been criticized and some have called to deprecate target and only use condition but I think it provides a flexible indexing/look-up mechanism in cases where the number of rules/policies is large.
In the case of Consent, I think the patient ID and the date provides a very efficient way to index and narrow down the search space for an incoming request in most use-cases (bulk access could be an exception) so we already have something like target.
XACML also uses decision-combining algorithms for resolving potentially conflicting decisions from different matching rules/policies and the order-based precedence you mentioned is just one of them. I think the more common ones are deny-overrides and permit-overrides. Personally, I think this is less complicated compared to the hierarchical rule structure currently defined in the consent resource. I think when we think of expressing access control rules, intuitively we often think of AND/OR-ing exceptions rather than a deep chain of exceptions to other exceptions.
Aside from that, I think the most important thing that is missing from the Consent specifications right now is defining the semantics of the rule language in the provision element. It is currently not clearly defined how these rules must be processed and interpreted. I think we should have at least an informal definition for the semantics to answer some of the questions in this thread.
John Moehrke (Feb 26 2019 at 17:43):
Note that we did loose a section on how to interpret the consent -- see this historic http://hl7.org/fhir/2016Sep/consent.html#int
John Moehrke (Feb 26 2019 at 17:44):
it wasn't great, but it did try to cover some of this.
John Moehrke (Feb 26 2019 at 17:45):
we did explictly not take on all of the complexity of XACML, with th expectation that if someone really needs that complexity then they should use XACML and not .provisions
Grahame Grieve (Feb 27 2019 at 07:13):
I am certainly interested in the rule language of the provision element. I’m not sure that ‘semantics’ is quite the right word. I want to choose a subset of it, and find a way to have consistent implementations across the RESTful API
Grahame Grieve (Feb 27 2019 at 07:14):
What I haven’t figured out right now is, I can see how I process a set of provisions in a single Consent resource... but I have a set of resources. Do I have to decide which applicable provision is the narrowest? Can you supersede a consent agreement with an additional one on one specific provision without rendering the entire original consent invalid?
John Moehrke (Feb 27 2019 at 14:35):
the easy answer is: thats policy... but I expect that you do need to exhaustively process all consents. Usually we recommend that harmonization of a set of consents should be done when consents are created/updated; so that processing consents in real-time are not burdened. This sometimes results in a policy that allows only one consent, thus finding more than one is a policy failure.
Mohammad Jafari (Feb 27 2019 at 22:19):
In our preliminary demo, the Consent Decision Point would look at all the consents applicable to a patient and then use a most-recent-overrides strategy for resolving any potential conflicts. This implementation would still needs to fetch and parse all the Consents for the given patient before being able to determine whether the Consent is applicable to the current access request (because the patient may have different consents focused on different purposes, organizations, etc.) One area I think we can improve and elaborate in an implementation guide is how to use search parameters to narrow this down so a more precise set of applicable Consents is fetched, parsed, and examined.
Jose Costa Teixeira (Mar 01 2019 at 18:58):
@Mohammad Jafari what is "all the consents applicable to a patient"?
Jose Costa Teixeira (Mar 01 2019 at 19:08):
just checking because it reads similarly to "purpose" and I am always afraid that we use consent for purpose.
Mohammad Jafari (Mar 01 2019 at 22:19):
This was a simple query based on Consent.patient which would return all the consents applied to the given patient. I agree that this query can definitely improved to filter out consents with other purposes etc.
Last updated: Apr 12 2022 at 19:14 UTC
