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.

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 [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.
  • 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.