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/

Further discussion should be done on the FHIR chat system. A specific thread is found at https://chat.fhir.org/#narrow/stream/implementers/topic/Consent

Informal Comments and Questions

please provide your comments and questions here.

Grahame's responses

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

GG: in the current design, VA could bind category to that value set for their usage. What would that not accomplish?

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

GG: I don't understand what the definition of that element would be, or what the value set is. It's a mess of broad categories, specific form references, jurisdictional specific things, and it overlaps problematically with the value set suggested for category above. What would a system do with this? Where does the robust access control come from? I think that a lot of this goes in profile - see further discussion below

author

• SB 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?

GG: Author is "Who made the Consent statement - this is the persion who takes responsibility for the content, not the scribe who recorded it" nor is it who witnessed/signed. In many jurisdictions, of course, the person making the statements is also expected/required to sign it, but this is certainly not true in all workflows where consent is used, particularly in tracking/subset consent resources, where the consent statement is not original. It's certainly not signed, but it is attributable to someone. See below for signature discussion.

so re:KS, yes, I think it is. re SB: I don't think there's a need for 0..* for the author. I don't think the question call the definition into question.

signature

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

GG: the question here is why using a detached signature using provenance is not appropriate, as compared to all other resources. In general, we always have provenance in the background. We denormalise things out of provenance into the resource itself when we hold that there's operational reasons to do the denormalisation. Signature is particularly problematic as an attached signature on a RESTful API - there's technical reasons to stick with a detached signature. What reasons are there to say that encapsulated signature(s) are required for operational reasons? And how do multiple encapsulated signatures work in a FHIR resource - that's pretty problematic. In the call, the main argument was that there needed to be signatures, but since there are (in provenance), the mere need doesn't address the denormalisation issue.

I propose that the way to handle this is to note in the scope that consents are usually signed, and that if the Consent resource is the primary vehicle for the consent agreement, and therefore needs a signature, then the signature goes in a Provenance resource. And then we can revisit that if implementation experience shows that there's practical problems with using the Provenance signature.

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"?

GG re SB: 'The organization that manages the consent, and the framework within which it is executed' - so I don't think that's unclear re KC: yes, that's ambiguous, but it should be clearer to say 'manages this consent record' as opposed to 'manages the consent policy'. In the case of an HIE managing consent, the HIE would be the organization. I'm not sure what 'hospital that submits the consent directive' is - is the idea that the hospital has it's own consent agrement that it shares via the HIE? so the HIE IS just a sharing repository for other organization's consent? then the the other orgs would be in the organisation

re JM: well, yes, not always the same, but what does scope/location/jurisdiction do? is it different to policy? (see below)

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) .

GG: So it seemed to me that this is the must fundamental idea that I introduced: that rather than using a 'type' code, you would use a URI. The URI could be a literal reference to some policy statement (web site, PDF, XACML), or it could be symbolic - e.g. arbitrarily defined. I proposed with that idea that the base specification would define a few base values, and jurisdictions would define additional values e.g. HIPAA rules for USA. At some time, the committee might take it upon itself to define a resource for consent policy agreements (though it can always choose not to)

It would be interesting to define a list of nationally defined US consent policies. A number of acronyms and legal references went by in the discussion on the call. We could define such a list as part of the FHIR spec - in the US realm specific section. Same for Canada - how many policies are there?

I'm not sure if this what the BPPC uses referenceIdList for - what's that?

actor

• JM .actor - would be easier to process if we defined elements for the specific actors rather than a code and pointer
• 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".

GG: That might be true (though see below) but the role is extensible. And I think that's important, though if the committee thinks that it's not, then we can strip it to a code (simpler for everyone) or split into multiple named elements.

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

GG: A key part of consent is

• allow [actor] to see [something] - PRCP primary recipient
• allow X to see anything [actor] authored - AUT author
• allow X to see anything [actor] stores - CST custodian
• prevent X from seeing anything that [actor] provided - INF informant
• prevent X from seeing any information about [actor] that is the subject (e.g. my child) - SBJ subject
• allow X to see anything associated with referrals from [actor] - REF referral

So actor can be referenced in various roles. I think this is clear, but the definitions might be able to be improved.

Kathleen's list of roles, with my comments:

• Care giver information receiver | care team information receiver | legitimate relationship information receiver | work area information receiver - I don't understand how any of these are different to 'recipient'. How does the differentiation matter?
• Ammender - I don't know how this differs usefully from author. Why would I consent to amending differently to authoring?
• Affiliate - I can't imagine what this is (or isn't) - seems too abstract to be useful
• Agent - Also too abstract to be useful
• Assigned entity - also too abstract to be useful
• Author - same as AUT above
• Authorization server - I don't understand the use case for this - allow X where the [actor] is the authorization server? Does not compute?

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?

GG: so, profile = http://hl7.org/fhir/ConsentPolicy/opt-in + an except of type deny, and conditions for X records and Y person

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.

GG: perhaps that's true. but if it's true of them, why isn't it true of actor and data?

• SB Consent.action - we need to support "disclose" or some synonym.

GG: that's 'read' - isn't that the same thing? If disclose is a better word, what's a better word for 'write' access?

• LM I don't understand "purpose"

GG: if you allow access for research - that's not 'allow access to information tagged as research related', it's allow access for the purpose of research - a property of the operational context

• 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?

GG: not sure. I don't think it does, unless you're choosing not be conformant to FHIR itself. Can you be specific with an example?

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

GG: well, I did start more simple, but the examples were full of 'I don't know how to do this'. That's sure evidence that it was too simple. In particular, the difference between 'this resource', 'resources linked to this resource' and 'resources that link to this resource' are typical things to do. Another common requirement that came up for me and other implementers is API linked - resources that meet a particular criteria, such as type. That's profile. The one where I'm clearly going out on a limb beyond existing requirements is "value set" - I think that will indeed prove a powerful tool, but it has problems, yes.

• SB Consent.data.meaning -- may be better described as "Consent.data.type" because the "meaning" is tricky but the "coded type" is more straightforward.

GG: umm, changing the name won't make any difference to the definition and use of the element. Is the definition a problem? Or maybe I just don't understand the comment?

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

GG: not confident. no. This is a candidate for splitting up, though it makes re-use hard, and potentially indexing/searching. I suspect the list of meanings will grow a little. And at 5, it's already sitting on MnM's cut0-off value

• 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?

GG: yes, value set in particular is problematic (though powerful). It could be computable - at least the value set membership testing part is simple, but the determination might be tricky to get conformant and efficient at the same time.

• 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?

both of those would be done by actors - those criteria are actor based. Data link is for instances of records. Check the examples in the spec for several uses

except

• JM .except -- I like the updates. -- we still need to address combining meaning when multiple elements are specified in one except instance.

GG: example?

• SB Consent.except -- may be better described as Consent.condition.

GG: could be, but it is an *exception* to the policy (in theory anyway)

• 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?

GG: this is just a re-used type. A contained resource us not indicated here. And yes, in both places, recieving provider = actor[role=PRCP]

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

GG: don't understand what the implication is? You couldn't say 'I authorise access for research, but I don't authorise my psych records for anything?' - I don't understand and suspect that there's a mis-understanding somewhere

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?

GG: oops. the example shows how to do it, but I missed removing that text

• 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?

yes, with meaning = value set. If that stands. Else, I have no idea how it would be done.

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.