Stream: Security and Privacy
Topic: Consent.scope
Mohammad Jafari (May 06 2021 at 18:00):
There is a proposal at the CBCP WG to phase out Consent.scope and use the multiplicity in Consent.categoryto capture the the consent scope value. We wanted to ask for some feedback from the implementer and other in the community about how Consent scope is being used currently and whether there is any consequences for the current use-cases as a result of this change. I will cross-post this at the implementer stream as well.
There is a JIRA ticket for this here:
https://jira.hl7.org/browse/FHIR-31903
John Moehrke (May 06 2021 at 18:02):
what is the motivation? Seems wrong.
David Pyke (May 06 2021 at 18:03):
It's seen that Consent.scope and Consent.category are duplicative
John Moehrke (May 06 2021 at 18:03):
meaning, seems there is a good reason to have one element for the major kind of consent, and the other for the more refined kind. I do understand how that is not against the rules for multiplicity... but as independent elements it is easy to define rules... otherwise slicing is needed.
David Pyke (May 06 2021 at 18:04):
Which should be done at the profile level. With the two, we have effectively created slicing.
David Pyke (May 06 2021 at 18:04):
There has been some discussion at the Jira J#31903
John Moehrke (May 06 2021 at 18:07):
I would not mind switching element names... the intent as I understand it is the same intent as is common in other resources for .category vs .code... see Observation, DocumentReference, etc
John Moehrke (May 06 2021 at 18:08):
so to me Consent.scope is like Observation.category... and Consent.category is like Observation.code
David Pyke (May 06 2021 at 18:55):
I guess the question is, is the scope code a useful thing that gives utility beyond what would be in consent.category alone?
Lloyd McKenzie (May 06 2021 at 23:02):
The main motivators are:
- we can't mandate what the category codes are for consent - different organizations are going to categorize differently and won't necessarily be able to easily map to whatever set of categories HL7 happens to define
- some types of contents will fit multiple categories
- there are use-cases for a variety of types of categorization, some having different granularities and some which are orthogonal to each other.
- there's no one 'magic' set of categories we can expect interoperability with across all possible uses of the resource across all countries
Therefore: simply define category as 0..*, define a preferred value set and leave it up to implementation guides to drive interoperability on categorization within domain spaces where it's possible to gain agreement on a coherent set of codes everyone finds useful and can map to.
Lloyd McKenzie (May 06 2021 at 23:03):
At the moment, there's no equivalent of Observation.code for consent. Both scope and category were both types of high-level categorization.
John Moehrke (May 10 2021 at 14:22):
I disagree. as I said above.
John Moehrke (May 10 2021 at 14:27):
im not necessarily against going to just one code. but today I do think that scope is like Observation.category, and category is like Observation.code.
John Moehrke (May 10 2021 at 14:28):
where a paper consent covers multiple topics... this can easily be done with two instances of Consent both pointing at the same attachment. so that argument seems false
David Pyke (May 10 2021 at 14:34):
John, one issue that you may not be seeing is that Lloyd's use case is using Consent as an envelope for sending a document that covers multiple scopes. In that case, it would make sense that the Consent resource have multiple scopes and require only one Consent to be pushed
John Moehrke (May 10 2021 at 14:46):
I was not aware of that, but it did come out. I did say that my view would be that there would be multiple instances of Consent for the different purposes.
If we really think that a single Consent instance can address multiple purposes, then we must remove the .provisions. As it would be very confusing to have mixture of .provisions for different purposes. I am okay with removing .provision, as I would prefer this concept be rolled into Permission and out of Consent.
Lloyd McKenzie (May 10 2021 at 14:59):
category isn't like Observation.code - it's not conveying 'detail'. It's also 0..*, which makes no sense for a 'code' type element. If you're categorizing, you only need one element to capture a wide variety of categories.
Lloyd McKenzie (May 10 2021 at 15:01):
The categorization of a consent doesn't drive the behavior of provisions. Categories are used for discovery. Consent.scope is just a category - it doesn't change what the consent does or doesn't do. And the current proposed codes for Consent.scope are not orthogonal or even necessarily complete.
Last updated: Apr 12 2022 at 19:14 UTC
