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

• blah
• blah blah
• blah blah blah

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 any 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 [1] 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...
• 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.securityLabel - not sure how this applies to a consent.
• 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.data is referring to the Consent.data or is it another structure distinct from the Consent.data? Basically can I specify some data in Consent.data and some additional data sets in Consent.condition/except?

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?