Stream: implementers
Topic: Consent Status
Raffael Bild (Nov 14 2018 at 11:44):
Hello everybody,
I noticed that the Consent Resource of FHIR Release 3 uses the value set ConsentState
(https://www.hl7.org/fhir/valueset-consent-state-codes.html)
for encoding the attribute "status".
In Release 4, the same status codes are listed in the description of the resource content at
https://build.fhir.org/consent.html
however, the link pointing to the value set is now referencing a different value set, namely EventStatus
(https://build.fhir.org/valueset-event-status.html)
I suppose that the status codes listed at
https://build.fhir.org/consent.html
are outdated and that the correct value set for Release 4 would be EventStatus, is that correct?
And, on another note, I'm wondering about the semantic level on which consent status are specified...
It seems to me that ConsentState mainly describes the legal validity of the consent as a consequence of real-world actions at given points in time, e.g. it would be "active" when a patient signs a consent form (implying that the permissions specified in the ressource have to be enforced), and it would switch to "inactive" when the patient later withdraws his consent (implying that the permissions specified in the ressource must not be enforced anymore). Only the code "entered-in-error" seems to be a technical code indicating that the actual instance of the consent ressource has been created wrongly, i.e. it doesn't correctly represent what has happened in the real world.
The valueset EventStatus, as I see it, would then focus more on the state of the real-world process of consenting, e.g. it would be "completed" when a patient signs a consent form (implying that the permissions specified in the ressource have to be enforced), and it would switch to "stopped" when the patient later withdraws his consent (implying that the permissions specified in the ressource must not be enforced anymore). "entered-in-error" would have the same meaning as in the value set ConsentState.
Are these interpretations correct, or did I misunderstand something?
Any input about these points would be greatly appreciated!
Lloyd McKenzie (Nov 14 2018 at 12:15):
@Paul Knapp ?
Paul Knapp (Nov 14 2018 at 12:41):
Thanks @Lloyd McKenzie, but I think @John Moehrke should field this one.
John Moehrke (Nov 14 2018 at 14:37):
Raffael, The Consent resource has been aligned with the Event pattern in FHIR. This is a pattern that FHIR leadership is trying to drive across all Resources that record the result of an Event. This has caused some restructuring, as you have noticed. This restructuring is not well understood. So your question, and clarification, is well timed. We too are learning how we might want to leverage the codes that come from the Event pattern. It might be good to record your question as a Change Request, so that it can drive some improvement of the text and codes. @David Pyke might have a better answer.
Raffael Bild (Nov 16 2018 at 16:54):
Dear John, thanks a lot for the explanation! Regarding the semantics of the status in Release 3, I would suppose that the following real-life events would be reflected by the following codes, which in turn have the following implications on the validity of the permissions specified in the instance of the consent resource:
Person signs a consent form -> status "active" -> permissions are valid and have to be enforced
Person refuses to sign a consent form -> status "rejected" -> permissions must not be enforced
Person withdraws consent or validity period of consent expires -> status "inactive" -> permissions must not be enforced
The instance of the consent resrource has been created in error -> status "entered-in-error" -> permissions must not be enforced
Would that be a correct way of using the resource? I'd appreciate it if anybody could confirm or correct this.
John Moehrke (Nov 16 2018 at 18:35):
That seems like one possibility. I would just need to stop short of saying that other uses of this core standard resource are forbidden. To say this another way, the elements in the Consent resource are provided to support various use-cases and various policies. You are free to choose a policy that interprets the .status element the way you have.
That said, the use of .status alone may not be sufficient to support your needs. Often a Consent has a sunset timeframe. One could implement a sunset with an agent that updates each Consent that has expired, but often this kind of an update would be seen as modification of a legal record. Thus the timeframe should also be examined in addition to the status being active, to notice when a consent has expired.
Morten Ernebjerg (Nov 17 2018 at 15:50):
@Raffael Bild I don't have extensive experience on this, but we also arrived at exactly the semantics you outlined above in a project.
Morten Ernebjerg (Nov 17 2018 at 15:50):
(Also nice for us to hear from other on this!)
Sebastian Stäubert (Nov 29 2018 at 15:25):
In order to extend Raffael Bild's request, I would like to present a concrete scenario and ask for feedback from this round.
in the German MI Initiative, the consent status in FHIR but also in BPPC documents for the exchange between university hospitals (or their data integration centres) should be mapped. A consent form (consisting of 4 modules and a total of 8 statements to which consent can be given) was developed for this purpose, which is now to be completed by patients (electronically if possible). The question now is how concretely a FHIR Consent Resource (R4, http://build.fhir.org/consent.html) can be used for this.
We have found 2 variants and are looking forward to your feedback:
Variant 1: The element policyRule (http://build.fhir.org/consent-definitions.html#Consent.policyRule) is used to map Statement+Status. For this the Value Set ConsentPolicyRulesCodes would have to be extended by a code system for the MI-Consent (which is possible). The MI-I-Consent code system would then contain all possible characteristics for the statements, e.g. Modul1Statement1_consented, Modul1Statement1_rejected, etc. . For each statement the patient gave a response to, a FHIR Consent resource would be created with a policyRule containing the code matching the statement from the MI-I-Consent Code System. I.e. if the patient fills out the complete consent form, 8 FHIR Consent resources would be created. In addition, further information could be displayed in these resources via provision (http://build.fhir.org/consent-definitions.html#Consent.provision), e.g. a timeframe for the validity of the consent via period (http://build.fhir.org/consent-definitions.html#Consent.provision.period). Would this be a permitted use of the FHIR Consent resource?
Variant 2: The element policyRule is used to refer to the MI-I Consent form. The provision element would then express the consent of the statements. A code system or value set would also have to be created so that the statements can be referenced within the provision element. The question is, how would the statements be represented as code (http://build.fhir.org/consent-definitions.html#Consent.provision.code), class (http://build.fhir.org/consent-definitions.html#Consent.provision.class), action (http://build.fhir.org/consent-definitions.html#Consent.provision.action) or any other way? The problem is that neither class nor code fits 100%, since these elements address concrete object types, but the MI-I-Consent statements are abstract, e.g. "I agree that xyz may contact me again, in order to ..." or "I agree that zyx may use my medical data for research purposes ...".
To map the decision to a statement, the code system could also be designed as in variant 1, i.e. one code per statement/character combination (2.a) or the code system contains only the statements and the agreement is expressed via type element (http://build.fhir.org/consent-definitions.html#Consent.provision.type) (2.b).
What are your recommendations?
Sebastian Stäubert (Nov 29 2018 at 15:31):
The consent form is available only in german, but i link it here anyway to get an idea of it: http://www.medizininformatik-initiative.de/sites/default/files/2018-11/MII_Einheitlicher_Mustertext_v1.5_unkommentiert.pdf
John Moehrke (Nov 29 2018 at 15:34):
Hi @Sebastian Stäubert That is a very deep and detailed question. It might take me a bit to digest it and give a response. The first thought I have is that I really should put in a Mapping between Consent and BPPC. For those that are using BPPC as defined in IHE, there would be a deterministic mapping to Consent elements to hold the same data, plus the Consent.sourceReference could point at a DocumentReference that holds the BPPC document.
Mohammad Jafari (Nov 29 2018 at 19:31):
@Sebastian Stäubert
On a general note, one of the issues we noticed in our demos is that there is a difference between consent as a patient-facing artefact and what the patient signs vs. consent as a low-level policy vessel for making authorization/release decisions. If you are aiming at using the consent resource in the former sense, I think you should keep the FHIR consent resource as close as possible to what the patient signs (i.e. a single consent object representing the one signed by patient). If you want to use the Consent resource for the latter case, then you'd probably want to make a design choice that makes processing the consent policy rules as easy as possible for your use-cases. In that case, you can still capture the document signed by the patient as a different FHIR resource, e.g. a contract or a questionnaire, and then create consent resources as derivatives of that initial document to capture the policy rules stated by the consent.
So, I think determining the answer to this broader question can be helpful in answering some of the more low-level questions here.
Aside from that, is there a reason that in variant 1, you're not using multiple policyRule or multiple policy element to model different statements instead of creating multiple consent resources?
John Moehrke (Nov 29 2018 at 23:25):
@Sebastian Stäubert I am going to agree with @Mohammad Jafari and extend the message a bit further. The User Interface you use should be optimized for human understanding, yet the encoding of rules should be optimized for authorization decision correctness. There does not need to be a one-for-one mapping. I would expect that often one human readable clause will result in many provisions.
I would expect that the human readable form will be captured exactly in the .source[x] element. This might be as a screen capture, image of paper, questionaire, or anyother method that meets your needs. The source[x] element is intended to hold that which the human that agreed will find persuasive that they have indeed given that consent.
The provisions are a hierarchical structure for rules. Generally the root level provision is positive or negative based on the overall characteristic, with the next level provision.provision being the exceptions to that, with further nesting possible if needed.
Thus I expect that Consent.policy would indicate your root policy identifier. And that Consent.provision.code would be details about the overall policy. With Consent.provision.provision(s) as needed to record the various statement choices the patient approves or forbids.
Note, I don't like how the existing examples express this, and the concept of the mandatory root provision with nesting further seems awkward and distracting. I would like to work with you on a specific example.
John Moehrke (Nov 29 2018 at 23:26):
To answer your Variant 1 question... You could certainly do this, but it will be harder to manage going forward, and by having many Consent resources you will need to identify which one is prime. This model is not what I had envisioned for your kind of usecase.
John Moehrke (Nov 29 2018 at 23:34):
I always saw Consent.policyRule to be the equivalent of BPPC "Patient Privacy Policy Identifier"... that is the policy identifier for this base policy logic.
I understood the Consent.policyRule to be an indication of the regulations that caused this consent policy to be written. There is no equivalent of this in BPPC, as the usecase for knowing this was not clear. Once the organization comes up with a Patient Privacy Policy, that policy text would express why each clause is there. Exposing this in the Interop object has little value. However some want to be able to find all the policies written because of regulation X, so it is included as an element. Seems to me this kind of search is best done in other tools. So in my view this element is mostly useless and left blank.
Mikael Rinnetmäki (Nov 30 2018 at 06:32):
Hi all, I gave a presentation on FhirDevDays regarding consent and how we have modeled that - using the V3 status codes. I'm also interested in discussing how the states in V4 should be mapped to the old codes. Screenshot-2018-11-30-08.30.22.png
Sebastian Stäubert (Nov 30 2018 at 10:09):
@Mohammad Jafari Thank you for your reply.
(...) you can still capture the document signed by the patient as a different FHIR resource, e.g. a contract or a questionnaire, and then create consent resources as derivatives of that initial document to capture the policy rules stated by the consent.
I like that idea. The consent statements would then be questionaire.item(s) which could be referenced (somehow?) by a consent resource each, right?
@Sebastian Stäubert
Aside from that, is there a reason that in variant 1, you're not using multiplepolicyRuleor multiplepolicyelement to model different statements instead of creating multiple consent resources?
policyRule has a cardinality 0..1 and one has to choose either policy or policyRule.
As i understand these two elements should point to a consent directive, which is a set of statements to which the patient can respond. In our scenario this is the consent form of the medical informatics initiative.
John Moehrke (Nov 30 2018 at 13:19):
I did not notice ppc-1 rule. I am not sure why that rule exists. It is not explained. However I see no reason why that rule forces you to do something specific. As I expressed I expect for Privacy Consents that .policy will always be populated, and see little use for .policyRule.
I would also express that .policy should be profiled a cardinality 1..1; because I find, like BPPC does, that there needs to be one policy that expresses all the rules of the consent. Having this means there is no need to include broader logic that can support overlapping policyRules. When more than one Consent can be applied to a activity, then one must have complex logic support for how those multiple Consent rules are combined. The most simple of these rules recognizes OR vs AND relationships, but one must include rule language that addresses superior vs inferior; etc; and lastly the rules must support logic that expresses how conflicting decisions are resolved. There is no place for this broader logic, that broader logic is complex, and thus I prefer to push that broader logic into the preparation world where legal people can work out the details and give the technology/interoperability one policy with internal conditions and rules.
Sebastian Stäubert (Nov 30 2018 at 14:40):
@John Moehrke
I would expect that often one human readable clause will result in many provisions.
I would expect that the human readable form will be captured exactly in the .source[x] element. This might be as a screen capture, image of paper, questionaire, or anyother method that meets your needs. The source[x] element is intended to hold that which the human that agreed will find persuasive that they have indeed given that consent.
I created a example questionaire resource (=consent form) and a questionaireresponse resource (=consent form with answers from a patient).
The questionaireresponse resource now can be used in the consent.source element, as you wrote.
So the relationship is based on instances. If one would like to know on wich consent form the consent was created, he/she has to follow the consent.source to questionaireresponse.questionaire to questionaire. Consent.policyRule could be a direct way, but is recommended, as i understand you right.
The provisions are a hierarchical structure for rules. Generally the root level provision is positive or negative based on the overall characteristic, with the next level provision.provision being the exceptions to that, with further nesting possible if needed.
Thus I expect that Consent.policy would indicate your root policy identifier. And that Consent.provision.code would be details about the overall policy. With Consent.provision.provision(s) as needed to record the various statement choices the patient approves or forbids.
Ok, so i our case, we will define the root level provision as "deny" to implement a opt-in scenario. The next level provisions are then linked to the responses of the questionaireresponse from the patient. Is there a way to make this link? Or must create a software based on the questionaireresponse this?
How does this work: "Consent.policy would indicate your root policy identifier"? Where comes the root policy identifier from? From the questionaire resource?
John Moehrke (Nov 30 2018 at 14:53):
I don't think we have seen a request for linking provisions to questionaire response. Is there a reason you want a item-by-item linking? I am expecting the one Consent resource linking to the one questionaire response is sufficient. That adding deeper linking doesn't add value. That said, there surely does need to be somewhere a mapping. This mapping would be in a document expressing the overall policy linking to enforcement technology. This would be one document that expresses the facts for the whole system. This one document is more efficient than having millions of Consent resources duplicating this documented linkage.. right?
John Moehrke (Nov 30 2018 at 14:54):
note that this document I refer to is likely the overall policy, which is given an identifier, and that identifier is your .policy identifier.
John Moehrke (Nov 30 2018 at 14:59):
Hi all, I gave a presentation on FhirDevDays regarding consent and how we have modeled that - using the V3 status codes. I'm also interested in discussing how the states in V4 should be mapped to the old codes. Screenshot-2018-11-30-08.30.22.png
@Mikael Rinnetmäki note that we just noticed that the Consent.status vocabulary was not what we think it should be. Thus the committee is likely to approve reverting to the vocabulary used in STU3. The current build shows this reverted model.
Mikael Rinnetmäki (Nov 30 2018 at 15:22):
Excellent!
Mohammad Jafari (Nov 30 2018 at 20:35):
@John Moehrke @Sebastian Stäubert :
RE linking consents to questionnaires: we did not actually end up implementing this but one of the designs we considered for our consent demo was using the Provenance resource to register a link between a consent resource and the questionnaire resource that captures the patient's raw input on a patient-facing consent form. This approach does not provide an efficient mechanism to trace rules in a consent resource back to the questionnaire resource they're based on, so I think now that there is a source field, it's definitely more efficient to use that to reference the questionnaire, unless in your use-case the derivation event is important enough that you would want to record more provenance information around it.
RE conflict resolution, these are generally overarching policies that apply system-wide –e.g. based on organizational or jurisdictional rules. So, arguably, they're outside of the scope of individual Consents resources and in our implementations we stored and processed such policies separately in the authorization system alongside other overarching policies e.g. whether the patient consent is required at all to begin with for a given transaction.
Having said this, back to the original dichotomy (consent as a means to record low-level policy vs. consent as means for capturing the result of a patient/user interaction), there were also some developers in the connectathon who argued that the consent resource should record to _final_ authorization decision after all the adjudication with overarching policies takes place. In other words, it should be possible to look at the latest version of the consent and safely use it to make a final authorization decision (note that this implies that there will never be conflicting consents because they're preemptively dealt with at the derivation time).
I think there are some serious limitations to this approach though since a) it puts too much authorization burden on the consent resource which does not seem to be designed to be a policy language, and b) it presumes that overarching policies don't change often, because if overarching policies change, a large number of consent resources need to be reevaluated and re-processed to ensure sound adjudication based on the updated overarching rules.
Screen-Shot-2018-11-30-at-12.47.26-PM.png
Last updated: Apr 12 2022 at 19:14 UTC
