FHIR Consent - Grahame's model

Notes of June 17th, 2016

Grahame has drafted a Consent resource that in his view harmonizes various proposals including Privacy Consent Directive IG, Privacy Consent Resource, Consent Tracker.

http://hl7-fhir.github.io/consent.html

Grahame will present this to the CBCC workgroup during the regular CBCC Tuesday meeting on June 21. (See CBCC for details)

Please review Grahame's model first. Please add comments below that we can use for future discussions and improvements. (Rather than email list that tends to be noisy and lossy)

STU3 timeframe can be found described at https://onfhir.hl7.org/2016/05/20/fhir-meeting-report-montreal-may-2016/

Informal Comments and Questions

please provide your comments and questions here.

Grahame's repsonses

This section gathers the comments below on a per element basis

scope

• JM I am concerned we can't finish Privacy Consent Directive, even basic form... this new model adds all other forms of consent in the scope. How do we assure we can approach reasonably? Ballot comments can derail success if we can't focus

GG: Yes, but the converse is, if you exclude it from scope, then you get churn about whether you should. The approach I've proposed avoids this: we say, our focus is these 3 things, but we're focusing on the privacy/information sharing part. It might be that we change our minds about the others when we do them, and we will do them, but we do have a focus. Any comments on the other uses can be considered for future use if necessary to get to closure for now. There seemed to be general agreement that this was a workable approach

identifier

• JM .identifier is it common for identifier to be just one or should it be may (0..*)? What is the intent of this identifier vs the 'source' attachment or identifier?

GG: well, I think it should be 0..1 until clear need for ..* arises. The identifier identifies *this* consent statement (e.g. for references outside FHIR) as opposed to any other consent. The source identifier references some other consent statement.

status

• KC Bind Consent.status to the [ a more comprehensive consent directive lifecycle and management workflow[valueset-consentdirective-status.xml http://gforge.hl7.org/gf/download/docmanfileversion/9291/14448/valueset-consentdirective-status.xml valueset-consentdirective-status]

GG: the alternative status codes have: draft, amended, appended, cancelled, entered-in-error, pending, completed, in-progress, requested, policy, rejected, renewed, resolved, revoked, terminated. When I looked at this list, and compared it to the standard status codes in a FHIR resources, it seemed to me that there were 2 different things here - the status of the consent statement itself, and the status of the process around it. An alternative way to look at this is that there's the status codes of interest to the consumer of the consent, and those of interest to the maintainer of the consent. Even then, how many of these codes are really needed?

• what's the impact of amended vs appended? I'm only familiar with that as as document/narrative thing.
• policy - that's something completely different, not a *status* of a the resource
• which parties in the eco-system care about the difference between rejected, revoked, terminated, and cancelled? What difference does it make to whom?
• what is the impact of the difference between draft and pending?
• active = completed?
• in progress = suspended? (this is the opposite meaning of 'in-progress' for all other FHIR resources. Consistency is not a rigid requirement but the opposite meaning is a surprise factor)

More generally, what's the anticipated interop workflow for maintenance of a consent statement? I imagined that it would be authored/managed in a single system, then shared externally to consumers of the knowledge. If this isn't the case, can we storyboard the interop involved in the maintenance of consent statements? Generally, we have 3 choices:

• Agree that the maintenance part is out of scope
• put the maintenance part of the consent in a separate element that tracks the workflow around change
• permutate it into status as proposed, and have a longer list of status codes for all systems to work with

category/type

• JM.category can this be Coding? Having the more flexible CodeableConcept makes for harder to automate

GG: well, I don't agree. Having the more flexible CodeableConcept makes it easier to use in the real world. It's the strength of the binding that affects usability. I'd certainly like a tighter binding, but nothing I saw in the existing work suggested that there was any hope of even an extensible binding (though it's possible to ban text, and require code(s))

• SB Consent.category does not meet existing requirements ("Classification of the consent statement - for indexing/retrieval" - any of the data elements could be used for retrieval, the patient record will likely be most frequently used for that purpose) and value set would not work for 42CFR or Title 38 comments. the exampe value set is duplicating Conset.policy but it's optional so not an issue.

GG: agree that the example value set needs improvement. The question to ask is, if you removed category, what is it that you couldn't achieve?

• KS Consent.category: How much granularity are we supporting w/ Category? Just the broad "privacy|treatment|advance", or are we going down to the next level of "opt-in|opt-out|DNR|emergency"?

GG: the example value set is a bit misleading here. It was intended to be finer granularity - the next level or the one after that. It might be necessary to add a specific class element for privacy|treatment|advance - I think that would become clear when those other areas are explored in depth

• KC Bind Consent.category to the valueset-consentdirective-classcode rather than to a value set of actual consent directive types. Consent category was intended in the proposed FHIR Consent Tracker and the updated version of the FHIR CD profile [that is yet published in the build but discussed in CBCC FHIR CD calls]to group consent directive types.
  • This is needed to address different workflow requirements per policy, especially where only one "Opt-in with restriction or Opt-out with exception" consent directive is permitted to exist at one time. E.g., the VA only needs to request that the patient revoke a current eHealth Exchange consent directive if a provider pushes a new VA consent directive with a request that contains a pre-approved restriction, which could overrides a current VA eHealth Exchange Opt-in with restrictin consent directive.
  • Use Case: A Veteran Choice provider might push a Title 38 Section 7332 Opt-in with restrictions on a consent directive type VA Form 10-5345 Request for and Authorization to Release Medical Records or Health Information that overrides the veteran's current consent directive, which indicates that this provider is not authorized to receive 7332 protected conditions. VA policy would likely require that the VA send a "no information found" type indicator and to then contact the veteran to request a revocation of the current CD so that the new one can replace it. [Note: Form is available at http://www.va.gov/vaforms/medical/pdf/vha-10-5345-fill.pdf and Revocation of Authorization for Use and Release of Individually Identifiable Health Information for Veterans Health Administration Research. VA-1010116
• KC Create a Consent.type and bind to the [1] to support granular consent directive typing, which are associated in many cases with particular HL7/ISO Consent Directive Categories. This supports robust access control, consent directive registration and retrieval, and consent management communications without, in many cases, requiring hard-coded rules policies, which are domain specific or manual retrieval and review of applicable, typically unstructure policies.

author

• SB We need to record how signed the consent! This is a "must have" requirement. Unfortunately "author" is ambiguous. We struggled to find a purpose for in CDA and it was hard to do. We need to record the organization/provider how receives the consent (e.g. authorization to disclose data for research) from a patient or their proxy. Someone has to sign this consent and we need to record that.
• SB Question2 : Is Consent.author intended to store "patient who gave consent" and "witness who witnessed the signatured" or "proxy who signed the consent". We may need to change the cardinality to * from 0..1
• KS Consent.author: Just to confirm, this is usually the Patient or SDM, and in the case of an emergency, the Physician/Provider/Organization?
• KC Need optional link to FHIR Signature datatype, which is being updated per Provenance.signature CP to support (1) general requirement for many organizations [VA,states, international,that consent directives memorialize the Grantor and/or Grantee signature, regardless of techology used, e.g., wet/scanned, digital, and electronic signatures.
• KC Provenance.signature CP supports a representative signing on behalf of an accountable Consent Directive Grantor/Grantee actor type/reference. It would be odd to have a Provenance Resource, which targets a Consent Directive, have an optional signature and not have the ability to convey the same signature on the Consent Directive if required by applicable policy.

organization

• JM missing an indication of the scope/location/jurisdiction - not always directly related to organization
• SB Question 1: is the Consent.organization the entity that received the consent from the patient or their proxy? It's unclear...
• KS Consent.organization: Is this organization the Province/State that legislated and/or manages inter-provider Consent Directives? or is this the Hospital that is submitting the Consent Directive? How do we define "manages the consent"?

profile

• JM .policy - I assume this is the pointer to region defined base policy (if used) ? This is what BPPC uses the referenceIdList for... right?
• SB Consent.policy "policy that this consents to"... I think I understand the intent but we need to clarify how the consent relates to a specific policy (e.g. DURSA, 42 CFR Part 2, Title 38) .

actor

• JM .actor - would be easier to process if we defined elements for the specific actors rather than a code and pointer
• SB Consent.actor - this was amibiguous in Contract and it's unclear "Who|what controlled by this concept (or group, by role)" - what concept? It would be nice if we could clarify these data elements.
• LM The name/value pair "actor" relationship goes against MnM's recommended practice of having explicit associations. Explicit named associations makes profiling easier, makes it easier to manage the 80%, allows proper assertion of w5 mappings, allows consistent ordering of elements with other resources, etc. The need for "additional" relationships can be handled by extensions (which is also easier to discover and manage than a reference to some code from an unknown code system). As well, some of the listed codes seem like they either don't apply (or at least probably aren't in the 80%) where actor is re-used in "except".
• KC Bind Consent.actor.role to a more comprehensive valueset-actor-type, which is planned to be bound to the Provenance Resource among others. In final clean up review.

General structure issues

• KS In Ontario, we follow an Implied Consent model. Most consent directives would be of the form "Block Access to X Records from Y Person". Would the "X Records" be captured in Consent.except.data (and Consent resource is an Implied Consent for all Data)? Would all similar "Block Access to ..." be implemented using Consent.except.type=deny?

action, securityLabel & Purpose

• JM .action, .securityLabel, and purpose - At the root seems either a duplicate of .policy at the root; or something that would conflict with .policy. I would recommend it be removed until we can understand how it is actually used. Trying to orchestrate a policy out of three elements of (0..*) with no combining verbs is not helpful processible.
• SB Consent.action - we need to support "disclose" or some synonym.
• LM I don't understand "purpose"
• KS Consent.securityLabel: I assume this is driven/derived from the current IHE-BPPC / CDA Consent implementation pattern, with the use of SecurityLabels similar to Confidentiality Codes. What is the impact of SecurityLabels for organizations that currently to not use the IHE-BPPC/CDA Consent model? Does this create a gap in the feature?

data

• JM .data - historically we just pointed at the specific items that are addressed. You have tried to add logic in the .meaning that might be useful in the future but today is very unusual and problematic. I recommend we start more simple.
• SB Consent.data.meaning -- may be better described as "Consent.data.type" because the "meaning" is tricky but the "coded type" is more straightforward.
• LM Similar concern for "data". Are we confident all of the data.meaning codes are in the 80%? If not, it should also be represented with explicit relationships rather than a name-value pair.
• KS Consent.data.meaning: Potential to have a very complicated implementation, given the definition of the value set. Will this be computable and electronically enforceable?
• KS Consent.data.reference, Consent.except.data.refence: Not quite sure how this is implemented. Could we have examples of this? Can this represent a single record ID? Can this represent all data within a specific data repository? Can this represent all records created from Facility Q?

except

• JM .except -- I like the updates. -- we still need to address combining meaning when multiple elements are specified in one except instance.
• SB Consent.except -- may be better described as Consent.condition.
• SB Consent.except.actor is referring to the Consent.actor? Should we just use a contained resource? Is this where we refer to receving provider?
• SB Consent.except.purpose - this seems to indicate that we could specify a different purpose-of-use for each data referenced. That is not valid for privacy consent or authorization to disclose. We recommend removing it because you can't change the purpose per Consent.condition.

examples

• KS In the "Canada Realm Use Cases", why is "specific domain" listed as "NOT SUPPORTED"? In Ontario, we use the term "domain" to specify a repository, e.g. Medication Claims, Diagnostic Imaging Results, Lab Results, Primary Care Clinical Documents, Acute Care Clinical documents. Is there no way to identify this using Consent.except.data?
• KS There's an additional Ontario use case of Consent Directive to block access to Medication Records for a generic drug, and any related named drugs, within a medication repository. Could this be supported using Consent.except.data?

John Moehrke Comments/questions

Overall I like it.

• I am concerned we can't finish Privacy Consent Directive, even basic form... this new model adds all other forms of consent in the scope. How do we assure we can approach reasonably? Ballot comments can derail success if we can't focs
• .identifier is it common for identifier to be just one or should it be may (0..*)? What is the intent of this identifier vs the 'source' attachment or identifier?
• .category can this be Coding? Having the more flexible CodeableConcept makes for harder to automate
• missing an indication of the scope/location/jurisdiction - not always directly related to organization
• .policy - I assume this is the pointer to region defined base policy (if used) ? This is what BPPC uses the referenceIdList for... right?
• .actor - would be easier to process if we defined elements for the specific actors rather than a code and pointer
• .action, .securityLabel, and purpose - At the root seems either a duplicate of .policy at the root; or something that would conflict with .policy. I would recommend it be removed until we can understand how it is actually used. Trying to orchestrate a policy out of three elements of (0..*) with no combining verbs is not helpful processible.
• .data - historically we just pointed at the specific items that are addressed. You have tried to add logic in the .meaning that might be useful in the future but today is very unusual and problematic. I recommend we start more simple.
• .except -- I like the updates. -- we still need to address combining meaning when multiple elements are specified in one except instance.
• I would like to see the community focus on improving this model and expanding our scope after we succeed at the narrow scope.

SAMHSA/BHITS Project Comments/Questions

• We need to record how signed the consent! This is a "must have" requirement. Unfortunately "author" is ambiguous. We struggled to find a purpose for in CDA and it was hard to do. We need to record the organization/provider how receives the consent (e.g. authorization to disclose data for research) from a patient or their proxy. Someone has to sign this consent and we need to record that.
• Consent.category does not meet existing requirements ("Classification of the consent statement - for indexing/retrieval" - any of the data elements could be used for retrieval, the patient record will likely be most frequently used for that purpose) and value set would not work for 42CFR or Title 38 comments. the exampe value set is duplicating Conset.policy but it's optional so not an issue.
• Question 1: is the Consent.organization the entity that received the consent from the patient or their proxy? It's unclear...
• Question2 : Is Consent.author intended to store "patient who gave consent" and "witness who witnessed the signatured" or "proxy who signed the consent". We may need to change the cardinality to * from 0..1
• Consent.policy "policy that this consents to"... I think I understand the intent but we need to clarify how the consent relates to a specific policy (e.g. DURSA, 42 CFR Part 2, Title 38) .
• Consent.actor - this was amibiguous in Contract and it's unclear "Who|what controlled by this concept (or group, by role)" - what concept? It would be nice if we could clarify these data elements.
• Consent.action - we need to support "disclose" or some synonym.
• Consent.data.meaning -- may be better described as "Consent.data.type" because the "meaning" is tricky but the "coded type" is more straightforward.
• Consent.except -- may be better described as Consent.condition.
• Consent.except.actor is referring to the Consent.actor? Should we just use a contained resource? Is this where we refer to receving provider?
• Consent.except.purpose - this seems to indicate that we could specify a different purpose-of-use for each data referenced. That is not valid for privacy consent or authorization to disclose. We recommend removing it because you can't change the purpose per Consent.condition.

Lloyd McKenzie comments/questions

The name/value pair "actor" relationship goes against MnM's recommended practice of having explicit associations. Explicit named associations makes profiling easier, makes it easier to manage the 80%, allows proper assertion of w5 mappings, allows consistent ordering of elements with other resources, etc. The need for "additional" relationships can be handled by extensions (which is also easier to discover and manage than a reference to some code from an unknown code system). As well, some of the listed codes seem like they either don't apply (or at least probably aren't in the 80%) where actor is re-used in "except".

Similar concern for "data". Are we confident all of the data.meaning codes are in the 80%? If not, it should also be represented with explicit relationships rather than a name-value pair.

I don't understand "purpose"

Ken Sinn comments/questions

• In Ontario, we follow an Implied Consent model. Most consent directives would be of the form "Block Access to X Records from Y Person". Would the "X Records" be captured in Consent.except.data (and Consent resource is an Implied Consent for all Data)? Would all similar "Block Access to ..." be implemented using Consent.except.type=deny?

• Consent.category: How much granularity are we supporting w/ Category? Just the broad "privacy|treatment|advance", or are we going down to the next level of "opt-in|opt-out|DNR|emergency"?

• Consent.author: Just to confirm, this is usually the Patient or SDM, and in the case of an emergency, the Physician/Provider/Organization?

• Consent.organization: Is this organization the Province/State that legislated and/or manages inter-provider Consent Directives? or is this the Hospital that is submitting the Consent Directive? How do we define "manages the consent"?

• Consent.securityLabel: I assume this is driven/derived from the current IHE-BPPC / CDA Consent implementation pattern, with the use of SecurityLabels similar to Confidentiality Codes. What is the impact of SecurityLabels for organizations that currently to not use the IHE-BPPC/CDA Consent model? Does this create a gap in the feature?

• Consent.data.meaning: Potential to have a very complicated implementation, given the definition of the value set. Will this be computable and electronically enforceable?

• Consent.data.reference, Consent.except.data.refence: Not quite sure how this is implemented. Could we have examples of this? Can this represent a single record ID? Can this represent all data within a specific data repository? Can this represent all records created from Facility Q?

• In the "Canada Realm Use Cases", why is "specific domain" listed as "NOT SUPPORTED"? In Ontario, we use the term "domain" to specify a repository, e.g. Medication Claims, Diagnostic Imaging Results, Lab Results, Primary Care Clinical Documents, Acute Care Clinical documents. Is there no way to identify this using Consent.except.data?

• There's an additional Ontario use case of Consent Directive to block access to Medication Records for a generic drug, and any related named drugs, within a medication repository. Could this be supported using Consent.except.data?

Kathleen Connor's Comments

Would like to ensure that the following gaps [among others] are addressed so that this version of the FHIR Consent Resource support well-documented implementer requirements and enable prospective implementers, who are struggling with using alterative consent directive model to support their use cases are able to embrace this approach.

• Need optional link to FHIR Signature datatype, which is being updated per Provenance.signature CP to support (1) general requirement for many organizations [VA,states, international,that consent directives memorialize the Grantor and/or Grantee signature, regardless of techology used, e.g., wet/scanned, digital, and electronic signatures.
  • Provenance.signature CP supports a representative signing on behalf of an accountable Consent Directive Grantor/Grantee actor type/reference. It would be odd to have a Provenance Resource, which targets a Consent Directive, have an optional signature and not have the ability to convey the same signature on the Consent Directive if required by applicable policy.
• Need more Robust binding valuesets such as the proposed:
  • Bind Consent.category to the valueset-consentdirective-classcode rather than to a value set of actual consent directive types. Consent category was intended in the proposed FHIR Consent Tracker and the updated version of the FHIR CD profile [that is yet published in the build but discussed in CBCC FHIR CD calls]to group consent directive types.
    • This is needed to address different workflow requirements per policy, especially where only one "Opt-in with restriction or Opt-out with exception" consent directive is permitted to exist at one time. E.g., the VA only needs to request that the patient revoke a current eHealth Exchange consent directive if a provider pushes a new VA consent directive with a request that contains a pre-approved restriction, which could overrides a current VA eHealth Exchange Opt-in with restrictin consent directive.
    • Use Case: A Veteran Choice provider might push a Title 38 Section 7332 Opt-in with restrictions on a consent directive type VA Form 10-5345 Request for and Authorization to Release Medical Records or Health Information that overrides the veteran's current consent directive, which indicates that this provider is not authorized to receive 7332 protected conditions. VA policy would likely require that the VA send a "no information found" type indicator and to then contact the veteran to request a revocation of the current CD so that the new one can replace it. [Note: Form is available at http://www.va.gov/vaforms/medical/pdf/vha-10-5345-fill.pdf and Revocation of Authorization for Use and Release of Individually Identifiable Health Information for Veterans Health Administration Research. VA-1010116
  • Create a Consent.type and bind to the [2] to support granular consent directive typing, which are associated in many cases with particular HL7/ISO Consent Directive Categories. This supports robust access control, consent directive registration and retrieval, and consent management communications without, in many cases, requiring hard-coded rules policies, which are domain specific or manual retrieval and review of applicable, typically unstructure policies.
  • Bind Consent.status to the [ a more comprehensive consent directive lifecycle and management workflow[valueset-consentdirective-status.xml http://gforge.hl7.org/gf/download/docmanfileversion/9291/14448/valueset-consentdirective-status.xml valueset-consentdirective-status]
  • Bind Consent.actor.role to a more comprehensive valueset-actor-type, which is planned to be bound to the Provenance Resource among others. In final clean up review.
• I have more comments, but prioritized these for initial discussion.