FHIR Chat · Consent Resource Provision Element & Decision Combination · Security and Privacy

Stream: Security and Privacy

Topic: Consent Resource Provision Element & Decision Combination

Mohammad Jafari (Mar 06 2019 at 00:57):

Since this came up a few times in other threads and @John Moehrke alluded to it again in the conversation today, I wanted to bring this to everyone's attentions in a separate thread.
I think by adding a combining or conflict resolution strategy, the current nesting provision structure in the Consent resource can be simplified to a flat array instead of the nested structure. Here are some arguments in favour of this:

• Simpler and more Intuitive Semantics: A flat structure is easier to understand and corresponds better with the way we usually articulate policies and preferences (e.g. checkboxes in a form). Nested provisions deeper than two levels are too hard to follow to correspond to a user interface like a form and using them to model complicated policies soon leads to mental gymnastics which uses the nesting to implement something that can most likely be modelled in a simpler way. Single-layer nesting ("general rule... except...") which seems to be the only form realistically corresponding to real use-cases can easily be flattened into an array [general rule, exception rule] together with a suitable deny-override or permit-override conflict resolution strategy.
• Existing best practice: two most notable existing authorization/rights language, XACML and ODRL use this strategy. XACML defines decision combining algorithms to be associated with a policy to adjudicate possible conflicting outcomes from individual rules. Similarly, ODRL defines a policy conflict property to adjudicate any disagreements between the set of permissions and prohibitions in a policy.
• Implementation: Having an array of provisions with a combining/conflict resolution strategy fits perfectly with the map and reduce processing model common in most modern programming languages. This makes the logic for evaluating the provisions straightforward, i.e. map each rule to a decision and then reduce based on the combining strategy. Nested provisions in contrast are arguably more complicated to implement and understand.

Grahame Grieve (Mar 06 2019 at 01:39):

The simplification message got a bit complicated at the end there but I was feeling good about it to that point

Grahame Grieve (Mar 06 2019 at 01:40):

the and/or thing scares me; I know how that has played out elsewhere (e.g. value sets). Bad enough for programmers let alone general public.

John Moehrke (Mar 06 2019 at 13:24):

I like where this is going, and have very much been against the infinite nesting concept. But I am not clear on what it would look like. I think what you are describing is one repetition of something like .provision, with a combining rule for combinging repetitions, and within each provision one can have one layer of exceptions to that provision? Thus the root .provision goes to 0..*, remove the infinite .provision.provision, add in a provision.exception.

Mohammad Jafari (Mar 06 2019 at 17:47):

Here is an example of what I mean. The provisions element includes one property for combining strategy and an array of provisions (each of which more or less follows the form of the existing provision element in the Consent resource minus the nesting).
For example the following means access is granted by default except for the purpose of research.

"provisions": {
    "combine": "deny-override",
    "provision": [
        {
            "type": "permit"
        },
        {
            "type": "deny",
            "purpose": "research"
        }
    ]
}

In essence, this is (almost) semantically equivalent to a simplified XACML policy (without support for obligations, complex conditions, and AnyOf and AllOf match types).

I think the combine attribute should be 0..1 so that it can be skipped when the provision element contains only a single provision –and therefore no combining is necessary.

David Pyke (Mar 06 2019 at 17:54):

At that point, using XACML is far more efficient.

Mohammad Jafari (Mar 06 2019 at 18:03):

@David Pyke I agree. I think as much as we should keep the provisions simple and avoid re-inventing XACML or ODRL, it is also appropriate to keep this model close to these existing best practices so that
a) we don't re-invent a completely different authorization language, and
b) people who use provision for simple use-cases can smoothly switch to more complex authz/rights languages without a lot of cognitive overhead as/when their requirements get more complex .

Jose Costa Teixeira (Mar 06 2019 at 20:20):

sorry for out-of-context question, but is this discussion really specific for consent? or is it related to permission for using data (which imo may be consent or something else)?

David Pyke (Mar 06 2019 at 20:22):

Permission (from the patient) to use data is the use case for patient-privacy consent. If this isn't patient based, then it's something else.

Mohammad Jafari (Mar 06 2019 at 20:22):

@Jose Costa Teixeira this thread is specifically about the structure of the provision element in the Consent resource.

Jose Costa Teixeira (Mar 06 2019 at 20:22):

in other words, do we expect to have a resource for "permission to use data" (currently handled by security labels), and when we do, will the same discussion apply?

Jose Costa Teixeira (Mar 06 2019 at 20:24):

Permission (from the patient) to use data is the use case for patient-privacy consent. If this isn't patient based, then it's something else.

don't understand "it's something else" - do you mean "this discussion does not apply"?

Jose Costa Teixeira (Mar 06 2019 at 20:24):

if so, i am good.

David Pyke (Mar 06 2019 at 20:25):

This discussion is specifically around the stucture of the Consent resource which is based around patient-granted consent. For other forms of permission, security labels is the basics of what you're looking for

Jose Costa Teixeira (Mar 06 2019 at 20:27):

ok. just asking for a friend who does GDPR :) (where we could end up needing something elaborate, and imo consent is not a safe ground)

Jose Costa Teixeira (Mar 06 2019 at 20:27):

thanks and sorry for distracting.

David Pyke (Mar 06 2019 at 20:28):

No, that's no problem. In fact there is a project to review FHIR and GDPR. You may want to look here and join in https://confluence.hl7.org/display/SEC/FHIR+-+GDPR

David Pyke (Mar 06 2019 at 20:28):

We meet Mondays at 12PM ET

Mohammad Jafari (Mar 06 2019 at 21:42):

Thanks @David Pyke and @Jose Costa Teixeira. I'm going to re-up the last couple of posts to resume where we left off with the original topic.

Mohammad Jafari (Mar 06 2019 at 21:42):

@Mohammad Jafari: Here is an example of what I mean. The provisions element includes one property for combining strategy and an array of provisions (each of which more or less follows the form of the existing provision element in the Consent resource minus the nesting).
For example the following means access is granted by default except for the purpose of research.

"provisions": {
    "combine": "deny-override",
    "provision": [
        {
            "type": "permit"
        },
        {
            "type": "deny",
            "purpose": "research"
        }
    ]
}

In essence, this is (almost) semantically equivalent to a simplified XACML policy (without support for obligations, complex conditions, and AnyOf and AllOf match types).

I think the combine attribute should be 0..1 so that it can be skipped when the provision element contains only a single provision –and therefore no combining is necessary.

@David Pyke: "At that point, using XACML is far more efficient."

@Mohammad Jafari: I agree. I think as much as we should keep the provisions simple and avoid re-inventing XACML or ODRL, it is also appropriate to keep this model close to these existing best practices so that
a) we don't re-invent a completely different authorization language, and
b) people who use provision for simple use-cases can smoothly switch to more complex authz/rights languages without a lot of cognitive overhead as/when their requirements get more complex .

John Moehrke (Mar 06 2019 at 22:02):

ok. just asking for a friend who does GDPR :) (where we could end up needing something elaborate, and imo consent is not a safe ground)

@Jose Costa Teixeira the Consent resource is intended to cover the larger scope that you are asking about.

John Moehrke (Mar 06 2019 at 22:06):

I hope that we can cover basic privacy authorizations in the Consent. More complex use-cases should be expected to leverage more comprehensive rules languages like XACML, where the Consent resource is still available to provide the linkage reference. This said, what we need to determine is what level of basic rules are worthy of doing in a FHIR specific way, and what is the line where the need is more complex? I have high hope that the set of basic rules is near 80% (ish) of the overall need. If it is only at the 20% of the overall need, then we should abandon all expectation that we can do something in a FHIR way for privacy rules.

Mohammad Jafari (Mar 06 2019 at 22:54):

I agree with all the points about expressiveness and the pareto principle, but to clarify, the rationale for this proposal (i.e. flattening the recursive provisions) is not to increase expressiveness. I don't think making the structure a flat array will enable the consent resource to model more complex rules and in fact (without having done any formal semantics comparison) I suspect that the expressiveness remains more or less the same should this change take place.
The rationale behind the proposed change is to avoid the infinite nesting in order to:
- make the provisions simpler to understand and more intuitive.
- use a more similar approach to existing best practices of authz/rights policy languages.
- stay closer to existing authz/rights languages so that transition of policies from(to) those languages to (from) consent provisions is smooth and easy to follow.
- make it easier for implementers to understand and write the processing logic for provisions.

Jose Costa Teixeira (Mar 07 2019 at 05:56):

@John Moehrke i do not think a resource called "consent" should convy anything other than "a healthcare consumer’s choices, which permits or denies".

Jose Costa Teixeira (Mar 07 2019 at 05:57):

from GDPR view, consent must be free and explicit. which in healthcare it is not really a given.

Jose Costa Teixeira (Mar 07 2019 at 05:59):

i am not a lawyer, but a patient's frail condition can be argued to be why a consent in healthcare may not be freely given

Jose Costa Teixeira (Mar 07 2019 at 05:59):

Personally, if I go to a hospital and I get a paper that says "sign here and we will use your data to make money out of pharma industry or lab results" i will gladly sign it just to see a physician.

Jose Costa Teixeira (Mar 07 2019 at 06:00):

that is about consent, and why i think it is a very valid resource but hospitals need to support GDPR and they will typically not do it via consent.

Jose Costa Teixeira (Mar 07 2019 at 06:00):

they will do it via a valid purpose for processing.

Jose Costa Teixeira (Mar 07 2019 at 06:02):

this is why i did not feel i would be very hopeful in discussions around consent.

Jose Costa Teixeira (Mar 07 2019 at 06:03):

If the discussion is about "how do we capture the processing of data, the corresponding purposes and lawfulness", then my experience may be helpful.

John Moehrke (Mar 07 2019 at 13:23):

@Jose Costa Teixeira you keep bringing this up.. what is your alternative for the scope that we have been asked to cover? Note that the scope is beyond privacy consent, we are also asked to cover medical treatment consent, research consent, etc.. This word 'Consent' is understood globally to cover these cases. I don't disagree with you at all that in Principle Consent must be informed and given freely. I don't disagree with your GDPR perspective. We even cover these differences in the spec and papers. However we are at the technical level, not at the politics or ethics side of the argument. I would move very quickly to a different name than Consent if you offer a useful one. Picking a Resource name is hard, and a community effort.

John Moehrke (Mar 07 2019 at 14:07):

Note that Consent can be used 100% compliant in GDPR environments. There is no way to make a standard that can't be used illegally, but we have done everything possible to make it able to be used legally.

Jose Costa Teixeira (Mar 07 2019 at 15:41):

@John Moehrke Consent means consent, which means "consent to share data" or "consent to operate", or "consent to visit".... and i do not want to change anything there.

David Pyke (Mar 07 2019 at 15:43):

We have talked in the past about the potential need for a DataAccess resource which, either the Consent would be a user or would be a possible profile on Consent.

Jose Costa Teixeira (Mar 07 2019 at 15:43):

I am just not sure our GDPR requirements are clear.

Jose Costa Teixeira (Mar 07 2019 at 15:45):

I think i will write something. From GDPR perspective, the notion of consent does not solve much of GDPR (IMO, it solves very little because of "consent must be free"..). It does not mean cosnent is useless or incompatible for GDPR - if I gave that impression, I apologize

Jose Costa Teixeira (Mar 07 2019 at 15:45):

You mean "data access" a profile of Consent? That does not compute

David Pyke (Mar 07 2019 at 15:46):

You can already extend the scope of Consent for non-patient based data use. So, creating a specific profile on consent with a new use case is easily done

Jose Costa Teixeira (Mar 07 2019 at 15:47):

so, we would profile Consent for other data access?

Jose Costa Teixeira (Mar 07 2019 at 15:47):

that i do not understand.

David Pyke (Mar 07 2019 at 15:49):

You can look at the Australian HPD use case. They're using consent for provider directory data. Creating a use case and model of what you want we can work to make it part of a profile or scope addition

Jose Costa Teixeira (Mar 07 2019 at 15:49):

Sorry for distraction, but my point is simple - consent is not sufficient to cover GDPR. The other things we need are not consent-related, and if we profile consent to cover those other things, this is not something that I would like to see.

David Pyke (Mar 07 2019 at 15:50):

And that's being reviewed as part of the Security Work Group GDPR project that I linked to earlier. You really should have a look at that and join the weekly calls

Jose Costa Teixeira (Mar 07 2019 at 15:51):

I will write something down in terms of GDPR requirements for discussion.
For now, i just wanted to see if we are using Consent for any kind of consent(as in agreement), or if we are trying to make Consent fit into GDPR uses.

David Pyke (Mar 07 2019 at 15:52):

We have done considerable work on GDPR requirements. Please have a look at the https://confluence.hl7.org/display/SEC/FHIR+-+GDPR

Jose Costa Teixeira (Mar 07 2019 at 15:52):

i need to write something down first, because otherwise it would be a debate without requirements, which would be less efficient.

David Pyke (Mar 07 2019 at 15:53):

Also: https://docs.google.com/spreadsheets/d/1--6HKnMY7QCqsorpJXdgIm9lC-MJ-O_qIPTcjPdUGKg/edit#gid=0

Jose Costa Teixeira (Mar 07 2019 at 15:53):

I know, and I have done conseiderable work in implementing GDPR, so I just want to help, even if I ask strange questions.

David Pyke (Mar 07 2019 at 15:53):

We would love your input. Please have a look and join the calls

Jose Costa Teixeira (Mar 07 2019 at 15:54):

and yes, I will catch up, perhaps things have changed since last time i saw the docs.

Jose Costa Teixeira (Mar 07 2019 at 15:54):

Thanks

Last updated: Apr 12 2022 at 19:14 UTC