Stream: Security and Privacy
Topic: Consent provisions with AND OR
John Moehrke (Mar 05 2019 at 16:08):
I have submitted GF#20503 given some discussion on monday's GDPR call. I am interested in discussion that would help us understand the need and understand if the solution I mention is sufficient. Here is the body of the GF item
There are needs to encode into a privacy Consent provisions of various combinations. That is there are times when I want to say:
a) AND -- these two element values MUST exist for the provision to be evaluated
b) OR -- either of these two element values MUST exist for the provision to be evaluated
For example:
a) The consent authorizes access when the request for data has both RESEARCH and RESEARCH_XYZ purposeOfUse
b) The consent authorizaes access when the request for data is either RESEARCH or RESEARCH_XYZ purposeOfUse
Back when consent had .except; this was handled by
a) One except would include in the purpseOfUse two values for RESEARCH and RESEARCH_XYZ
b) Two except would exist with one including purposeOfUse of RESEARCH, the other except would have RESEARCH_XYZ.
Thus OR is handled at the .except repitition level, and AND is handled with repitition of the element within the .except
With .provision this is unclear, especially since .provision can infinitely nest. Is it true that repitition at the .provision level is always OR, and repitition at the elements within .provision is always AND (with the exception of provision.provision).? It is not clear this is the intent, and not clear if this is possible,.
Would be good to have the examples I give above expressed as examples of this, and encoded in examples.
This topic came up on the HL7 GDPR call March 4, 2019; as they were trying to encode some GDPR like consents and needed AND/OR logic.
I submitted GF#13420 which was dismissed withiout understanding my request for AND/OR capability.
John Moehrke (Mar 05 2019 at 16:22):
@David Pyke
David Pyke (Mar 05 2019 at 16:28):
Ah, that makes more sense. We need to handle the nested provisions as either specifically or/and. My understanding of the design was that a nested provision was to make an exception to the parent provision. Additions would be handled at the parent. I can ask this at today's CBCP meeting.
John Moehrke (Mar 05 2019 at 16:34):
I am just not sure that my recommendation (repeated .provisions are considered OR, repeated elements inside .provision are AND) will always work. Need to setup some examples of permit vs deny to determine if this works. It was far easier to understand when there was just one level of .except
David Pyke (Mar 05 2019 at 16:43):
My thought it we need a flag inside provision to mark it as "or" or "except"
John Moehrke (Mar 05 2019 at 16:44):
I hope not. but we did discuss that on monday... it would make processing much harder
John Moehrke (Mar 05 2019 at 16:44):
I think if we need to start down that path, we should abandon the whole provision and just tell people to use XACML
David Pyke (Mar 05 2019 at 16:44):
It was designed around except logic for sub-provisions. I don't think anyone considered the Or case
John Moehrke (Mar 05 2019 at 16:46):
I did include it in the original Consent that had .except
John Moehrke (Mar 05 2019 at 16:46):
and I am sure I described AND and OR logic -- as I have expressed in the new gForge.
David Pyke (Mar 05 2019 at 16:48):
It is mentioned in the description in STU3 but not how one distinguishes between except and OR
David Pyke (Mar 05 2019 at 16:48):
CBCP meets in 12 minutes so we can discuss it there
John Moehrke (Mar 05 2019 at 20:37):
Here are two distinct use-cases to show AND vs OR. They are somewhat contrived to be compact, but not really unusual. I will use purposeOfUse as a flat vocabulary, where as there is some structure such that Research_XYZ would be seen as a more specific version of Research, thus a request for data on Research_XYZ could be seen as the same as Research+Research_XYZ In the first one ( 1 ) the patient is authorizing requests that have purpose of either Research or the xyz specific research project; and ( 2 ) the patient is authorizing only requests that are declared as both Research and xyz specific research project.
Given that the root provision must exist, I simply made the root .provision that denies all access to everything covered by the .policy. Presumably .policy is clear about how it relates to other Consent(s) so as to not have this policy negate another that is Treatment authorizing. This root level and combination with other Consents is the topic of another discussion with @grahame. There was a root level set of context setting elements (period, actor, purpose, etc), where these context setting elements were simply identifying the context that this Consent applies to. Thus a transaction that does not fit within the context given, is not applicable to that Consent.
trying to do a compact pseudo json... I might be horably wrong with this pseudo-json encoding
1) Authorize all requests for data with purpose of Research and all requests with purpose of Research_XYZ
.provision
{
"type":"deny",
"provision":
[{"type":"permit","purpose":["RESEARCH"]},
{"type":"permit","purpose":["RESEARCH_XYZ"]}]
}
2) Authorize all requests for data that have both purpose of Research and Research_XYZ indicated. Meaning a request that just asks for purpose of Research would be denied.
.provision
{
"type":"deny",
"provision":
[{"type":"permit","purpose":["RESEARCH", "RESEARCH_XYZ"]}],
}
I guess in the case of ( 1 ), one could/should have a deeper nested deny for the opposite purpose value. (e.g. permit research and deny research_xyz; or permit research_xyz and deny research) Which is where I am not clear everything works.
I wonder if the structure of .provision is going to work.
John Moehrke (Mar 05 2019 at 20:37):
@Grahame Grieve ?
Giorgio Cangioli (Mar 25 2019 at 14:59):
Hi everyone. Any conclusion on this thread ? What about to consider OR what is inside the same element (e.g. policyRule; provision) and consider AND the relationship between elements. I prepared a matrix with possible combinations based on the above case that I hope we can discuss in the incoming GDPR on FHIR call.
John Moehrke (Mar 25 2019 at 15:01):
@David Pyke can you join the HL7 GDPR call today?
David Pyke (Mar 25 2019 at 15:05):
Yep, I'll bethere
Last updated: Apr 12 2022 at 19:14 UTC
