This page is part of the FHIR Specification (v1.6.0: STU 3 Ballot 4). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

6.4 Resource Consent - Content

Community Based Collaborative Care

Work Group

Maturity Level: 0

Compartments: Patient

A record of a healthcare consumer’s policy choices, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time.

Note to balloters: Due to editorial oversight, this ballot document does not contain the Privacy Consent Directive (PCD) Profile, a profile on the Contract resource, it does however contain the Consent resource which the CBCC committee is considering as an alternative. Balloters can review the PCD content as published in the May2016 pre-STU3 frozen version. The May2016 pre-STU3 frozen version is the most recent version of the FHIR ‘Consent Directive Profile’.

6.4.1 Scope and Usage

Definitions:

Consent

The record of a healthcare consumer’s policy choices, which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time

Consent Directive

The legal record of a healthcare consumer's agreement with a party responsible for enforcing the consumer’s choices, which permits or denies identified actors or roles to perform actions affecting the consumer within a given context for specific purposes and periods of time

Policy context

Any organizational or jurisdictional policies, which may limit the consumer’s policy choices, and which includes the named range of actions allowed

Healthcare Consumer

The individual establishing his/her personal consent (i.e. Consenter). In FHIR, this is referred to as the 'Patient' though this word is not used across all contexts of care

The purpose of this Resource is to be used to express a Consent regarding Healthcare. There are 3 possible uses for consent:

Privacy Consent: consent to share information
Treatment Consent: consent to undergo a specific treatment (or record of refusal to consent)
Research Consent: privacy and medical consent to participate in clinical trial, translational medicine, or to permit collection, use, or disclosure of health information and specimen to registries or directly to research projects for use in e.g., biomedical research and population origins or ancestry research
Advance Care Directives (e.g. DNR)

This resource is scoped to cover all 3 uses, but at this time, only the privacy use case is investigated, and the scope of the resource may change when the other possible scopes are investigated and tested.

6.4.1.1 Privacy Consent Directive (PCD)

Privacy policies define how Individually Identifiable Health Information (IIHI) is to be collected, accessed, used and disclosed. A Privacy Consent Directive as a legal record of a patient's (e.g. a healthcare consumer) agreement with a party responsible for enforcing the patient's choices, which permits or denies identified actors or roles to perform actions affecting the patient within a given context for specific purposes and periods of time. All consent directives have a policy context, which is any set of organizational or jurisdictional policies which may limit the consumer’s policy choices, and which include a named range of actions allowed. In addition, Privacy Consent Directives provide the ability for a healthcare client to delegate authority to a Substitute Decision Maker who may act on behalf of that individual. Alternatively, a client may author/publish their privacy preferences as a self-declared Privacy Consent Directive.

The Consent resource on FHIR provides support for alternative representations for expressing health information privacy consent directives in a standard form for the exchange of privacy policies that can be enforced by consuming systems (e.g., scanned documents, computable structured entries). It may be used to represent the Privacy Consent Directive itself, or a derived consent statement that is not the original Consent Directive.

6.4.2 Boundaries and Relationships

Consent management - particularly privacy consent - is complicated by the fact that consent to share is often itself necessary to protect. The need to protect the privacy of the privacy statement itself competes with the execution of the consent statement. For this reason, it is common to deal with 'consent statements' that are only partial representations of the full consent statement that the patient provided.

For this reason, the consent resource contains two elements that refer back to the source: a master identifier, and a direct reference to content from which this Consent Statement was derived. That reference can be one of several things:

A reference to another consent resource from which this limited statement was derived
A reference to a document format for the original source (e.g. PDF or CDA - see the HL7 CDAR2 ConsentDirective Implementation Guide , which incorporated the IHE Basic Patient Privacy Consents (BPPC) ), either directly, or in a reference
The source can be included in the consent as an attachment

The consent statements represent a chain that refers back to the original source consent agreement. Applications may be able to follow the chain back to the source, but should not generally assume that they are authoriszd to do this.

Consent statements are often signed - either on paper, or digitally. Consent Signatures will be found in the Provenance resource (example consent and signature). Implementation Guides will generally make rules about what signatures are required, and how they are to be shared and used.

6.4.3 Interpretation

The Consent resource is structured with a base policy which is either opt-in or opt-out, followed by a listing of exceptions to that policy. The exceptions can be additional positive or negative exceptions upon the base policy. The set of exceptions include a list of data objects, list of authors, list of recipients, list of Organizations, list of purposeOfUse, and Date Range.

The enforcement of the Privacy Consent Directive is not included, but is expected that enforcement can be done using a mix of the various Access Control enforcement methodologies (e.g. OAuth, UMA, XACML). This enforcement includes the details of the enforcement meaning of the elements of the Privacy Consent Directive, such as the rules in place when there is an opt-in consent would be specific about which organizational roles have access to what kinds of resources (e.g. RBAC, ABAC). The specification of these details are not in scope for the Consent resource.

Structure

Name	Flags	Card.	Type	Description & Constraints
Consent			DomainResource	A healthcare consumer’s policy choices to permits or denies recipients or roles to perform actions for specific purposes and periods of time
identifier	Σ	0..1	Identifier	Identifier for this record (external references)
status	?!Σ	1..1	code	draft \| proposed \| active \| rejected \| inactive \| entered-in-error ConsentStatus (Required)
category	Σ	0..*	CodeableConcept	Classification of the consent statement - for indexing/retrieval Consent Category Codes (Example)
dateTime	Σ	0..1	dateTime	When this Consent was created or indexed
period	Σ	0..1	Period	Period that this consent applies
patient	Σ	1..1	Reference(Patient)	Who the consent applies to
consentor	Σ	0..*	Reference(Organization \| Patient \| Practitioner \| RelatedPerson)	Who is agreeing to the policy and exceptions
organization	Σ	0..1	Reference(Organization)	Organization that manages the consent
source[x]	Σ	0..1		Source from which this consent is taken
sourceAttachment			Attachment
sourceIdentifier			Identifier
sourceReference			Reference(Consent \| DocumentReference \| Contract \| QuestionnaireResponse)
policy	Σ	1..1	uri	Policy that this consents to
recipient	Σ	0..*	Reference(Device \| Group \| Organization \| Patient \| Practitioner \| RelatedPerson \| CareTeam)	Whose access is controlled by the policy
purpose	Σ	0..*	Coding	Context of activities for which the agreement is made PurposeOfUse (Extensible)
except	Σ	0..*	BackboneElement	Additional rule - addition or removal of permissions
type	Σ	1..1	code	deny \| permit ConsentExceptType (Required)
period	Σ	0..1	Period	Timeframe for data controlled by this exception
actor	Σ	0..*	BackboneElement	Who\|what controlled by this exception (or group, by role)
role		1..1	CodeableConcept	How the actor is/was involved Consent Actor Roles (Extensible)
reference		1..1	Reference(Device \| Group \| CareTeam \| Organization \| Patient \| Practitioner \| RelatedPerson)	Resource for the actor (or group, by role)
action	Σ	0..*	CodeableConcept	Actions controlled by this exception Consent Action Codes (Example)
securityLabel	Σ	0..*	Coding	Security Labels that define affected resources All Security Labels (Extensible)
purpose	Σ	0..*	Coding	Context of activities covered by this exception PurposeOfUse (Extensible)
class	Σ	0..*	Coding	e.g. Resource Type, Profile, or CDA etc Consent Content Class (Extensible)
code	Σ	0..*	Coding	e.g. LOINC or SNOMED CT code, etc in the content Consent Content Codes (Example)
data	Σ	0..*	BackboneElement	Data controlled by this exception
meaning	Σ	1..1	code	instance \| related \| dependents ConsentDataMeaning (Required)
reference	Σ	1..1	Reference(Any)	The actual data reference
Documentation for this format

UML Diagram (Legend)

XML Template

<Consent xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..1 Identifier Identifier for this record (external references) --></identifier>
 <status value="[code]"/><!-- 1..1 draft | proposed | active | rejected | inactive | entered-in-error -->
 <category><!-- 0..* CodeableConcept Classification of the consent statement - for indexing/retrieval --></category>
 <dateTime value="[dateTime]"/><!-- 0..1 When this Consent was created or indexed -->
 <period><!-- 0..1 Period Period that this consent applies --></period>
 <patient><!-- 1..1 Reference(Patient) Who the consent applies to --></patient>
 <consentor><!-- 0..* Reference(Organization|Patient|Practitioner|RelatedPerson) Who is agreeing to the policy and exceptions --></consentor>
 <organization><!-- 0..1 Reference(Organization) Organization that manages the consent --></organization>
 <source[x]><!-- 0..1 Attachment|Identifier|Reference(Consent|DocumentReference|
   Contract|QuestionnaireResponse) Source from which this consent is taken --></source[x]>
 <policy value="[uri]"/><!-- 1..1 Policy that this consents to -->
 <recipient><!-- 0..* Reference(Device|Group|Organization|Patient|Practitioner|
   RelatedPerson|CareTeam) Whose access is controlled by the policy --></recipient>
 <purpose><!-- 0..* Coding Context of activities for which the agreement is made --></purpose>
 <except>  <!-- 0..* Additional rule -  addition or removal of permissions -->
  <type value="[code]"/><!-- 1..1 deny | permit -->
  <period><!-- 0..1 Period Timeframe for data controlled by this exception --></period>
  <actor>  <!-- 0..* Who|what controlled by this exception (or group, by role) -->
   <role><!-- 1..1 CodeableConcept How the actor is/was involved --></role>
   <reference><!-- 1..1 Reference(Device|Group|CareTeam|Organization|Patient|
     Practitioner|RelatedPerson) Resource for the actor (or group, by role) --></reference>
  </actor>
  <action><!-- 0..* CodeableConcept Actions controlled by this exception --></action>
  <securityLabel><!-- 0..* Coding Security Labels that define affected resources --></securityLabel>
  <purpose><!-- 0..* Coding Context of activities covered by this exception --></purpose>
  <class><!-- 0..* Coding e.g. Resource Type, Profile, or CDA etc --></class>
  <code><!-- 0..* Coding e.g. LOINC or SNOMED CT code, etc in the content --></code>
  <data>  <!-- 0..* Data controlled by this exception -->
   <meaning value="[code]"/><!-- 1..1 instance | related | dependents -->
   <reference><!-- 1..1 Reference(Any) The actual data reference --></reference>
  </data>
 </except>
</Consent>

JSON Template

{
  "resourceType" : "Consent",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : { Identifier }, // Identifier for this record (external references)
  "status" : "<code>", // R!  draft | proposed | active | rejected | inactive | entered-in-error
  "category" : [{ CodeableConcept }], // Classification of the consent statement - for indexing/retrieval
  "dateTime" : "<dateTime>", // When this Consent was created or indexed
  "period" : { Period }, // Period that this consent applies
  "patient" : { Reference(Patient) }, // R!  Who the consent applies to
  "consentor" : [{ Reference(Organization|Patient|Practitioner|RelatedPerson) }], // Who is agreeing to the policy and exceptions
  "organization" : { Reference(Organization) }, // Organization that manages the consent
  // source[x]: Source from which this consent is taken. One of these 3:
  "sourceAttachment" : { Attachment },
  "sourceIdentifier" : { Identifier },
  "sourceReference" : { Reference(Consent|DocumentReference|Contract|
   QuestionnaireResponse) },
  "policy" : "<uri>", // R!  Policy that this consents to
  "recipient" : [{ Reference(Device|Group|Organization|Patient|Practitioner|
   RelatedPerson|CareTeam) }], // Whose access is controlled by the policy
  "purpose" : [{ Coding }], // Context of activities for which the agreement is made
  "except" : [{ // Additional rule -  addition or removal of permissions
    "type" : "<code>", // R!  deny | permit
    "period" : { Period }, // Timeframe for data controlled by this exception
    "actor" : [{ // Who|what controlled by this exception (or group, by role)
      "role" : { CodeableConcept }, // R!  How the actor is/was involved
      "reference" : { Reference(Device|Group|CareTeam|Organization|Patient|
     Practitioner|RelatedPerson) } // R!  Resource for the actor (or group, by role)
    }],
    "action" : [{ CodeableConcept }], // Actions controlled by this exception
    "securityLabel" : [{ Coding }], // Security Labels that define affected resources
    "purpose" : [{ Coding }], // Context of activities covered by this exception
    "class" : [{ Coding }], // e.g. Resource Type, Profile, or CDA etc
    "code" : [{ Coding }], // e.g. LOINC or SNOMED CT code, etc in the content
    "data" : [{ // Data controlled by this exception
      "meaning" : "<code>", // R!  instance | related | dependents
      "reference" : { Reference(Any) } // R!  The actual data reference
    }]
  }]
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .


[ a fhir:Consent;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:Consent.identifier [ Identifier ]; # 0..1 Identifier for this record (external references)
  fhir:Consent.status [ code ]; # 1..1 draft | proposed | active | rejected | inactive | entered-in-error
  fhir:Consent.category [ CodeableConcept ], ... ; # 0..* Classification of the consent statement - for indexing/retrieval
  fhir:Consent.dateTime [ dateTime ]; # 0..1 When this Consent was created or indexed
  fhir:Consent.period [ Period ]; # 0..1 Period that this consent applies
  fhir:Consent.patient [ Reference(Patient) ]; # 1..1 Who the consent applies to
  fhir:Consent.consentor [ Reference(Organization|Patient|Practitioner|RelatedPerson) ], ... ; # 0..* Who is agreeing to the policy and exceptions
  fhir:Consent.organization [ Reference(Organization) ]; # 0..1 Organization that manages the consent
  # Consent.source[x] : 0..1 Source from which this consent is taken. One of these 3
    fhir:Consent.sourceAttachment [ Attachment ]
    fhir:Consent.sourceIdentifier [ Identifier ]
    fhir:Consent.sourceReference [ Reference(Consent|DocumentReference|Contract|QuestionnaireResponse) ]
  fhir:Consent.policy [ uri ]; # 1..1 Policy that this consents to
  fhir:Consent.recipient [ Reference(Device|Group|Organization|Patient|Practitioner|RelatedPerson|CareTeam) ], ... ; # 0..* Whose access is controlled by the policy
  fhir:Consent.purpose [ Coding ], ... ; # 0..* Context of activities for which the agreement is made
  fhir:Consent.except [ # 0..* Additional rule -  addition or removal of permissions
    fhir:Consent.except.type [ code ]; # 1..1 deny | permit
    fhir:Consent.except.period [ Period ]; # 0..1 Timeframe for data controlled by this exception
    fhir:Consent.except.actor [ # 0..* Who|what controlled by this exception (or group, by role)
      fhir:Consent.except.actor.role [ CodeableConcept ]; # 1..1 How the actor is/was involved
      fhir:Consent.except.actor.reference [ Reference(Device|Group|CareTeam|Organization|Patient|Practitioner|RelatedPerson) ]; # 1..1 Resource for the actor (or group, by role)
    ], ...;
    fhir:Consent.except.action [ CodeableConcept ], ... ; # 0..* Actions controlled by this exception
    fhir:Consent.except.securityLabel [ Coding ], ... ; # 0..* Security Labels that define affected resources
    fhir:Consent.except.purpose [ Coding ], ... ; # 0..* Context of activities covered by this exception
    fhir:Consent.except.class [ Coding ], ... ; # 0..* e.g. Resource Type, Profile, or CDA etc
    fhir:Consent.except.code [ Coding ], ... ; # 0..* e.g. LOINC or SNOMED CT code, etc in the content
    fhir:Consent.except.data [ # 0..* Data controlled by this exception
      fhir:Consent.except.data.meaning [ code ]; # 1..1 instance | related | dependents
      fhir:Consent.except.data.reference [ Reference(Any) ]; # 1..1 The actual data reference
    ], ...;
  ], ...;
]

Changes since DSTU2

This resource did not exist in Release 2

Structure

Name	Flags	Card.	Type	Description & Constraints
Consent			DomainResource	A healthcare consumer’s policy choices to permits or denies recipients or roles to perform actions for specific purposes and periods of time
identifier	Σ	0..1	Identifier	Identifier for this record (external references)
status	?!Σ	1..1	code	draft \| proposed \| active \| rejected \| inactive \| entered-in-error ConsentStatus (Required)
category	Σ	0..*	CodeableConcept	Classification of the consent statement - for indexing/retrieval Consent Category Codes (Example)
dateTime	Σ	0..1	dateTime	When this Consent was created or indexed
period	Σ	0..1	Period	Period that this consent applies
patient	Σ	1..1	Reference(Patient)	Who the consent applies to
consentor	Σ	0..*	Reference(Organization \| Patient \| Practitioner \| RelatedPerson)	Who is agreeing to the policy and exceptions
organization	Σ	0..1	Reference(Organization)	Organization that manages the consent
source[x]	Σ	0..1		Source from which this consent is taken
sourceAttachment			Attachment
sourceIdentifier			Identifier
sourceReference			Reference(Consent \| DocumentReference \| Contract \| QuestionnaireResponse)
policy	Σ	1..1	uri	Policy that this consents to
recipient	Σ	0..*	Reference(Device \| Group \| Organization \| Patient \| Practitioner \| RelatedPerson \| CareTeam)	Whose access is controlled by the policy
purpose	Σ	0..*	Coding	Context of activities for which the agreement is made PurposeOfUse (Extensible)
except	Σ	0..*	BackboneElement	Additional rule - addition or removal of permissions
type	Σ	1..1	code	deny \| permit ConsentExceptType (Required)
period	Σ	0..1	Period	Timeframe for data controlled by this exception
actor	Σ	0..*	BackboneElement	Who\|what controlled by this exception (or group, by role)
role		1..1	CodeableConcept	How the actor is/was involved Consent Actor Roles (Extensible)
reference		1..1	Reference(Device \| Group \| CareTeam \| Organization \| Patient \| Practitioner \| RelatedPerson)	Resource for the actor (or group, by role)
action	Σ	0..*	CodeableConcept	Actions controlled by this exception Consent Action Codes (Example)
securityLabel	Σ	0..*	Coding	Security Labels that define affected resources All Security Labels (Extensible)
purpose	Σ	0..*	Coding	Context of activities covered by this exception PurposeOfUse (Extensible)
class	Σ	0..*	Coding	e.g. Resource Type, Profile, or CDA etc Consent Content Class (Extensible)
code	Σ	0..*	Coding	e.g. LOINC or SNOMED CT code, etc in the content Consent Content Codes (Example)
data	Σ	0..*	BackboneElement	Data controlled by this exception
meaning	Σ	1..1	code	instance \| related \| dependents ConsentDataMeaning (Required)
reference	Σ	1..1	Reference(Any)	The actual data reference
Documentation for this format

UML Diagram (Legend)

XML Template

<Consent xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..1 Identifier Identifier for this record (external references) --></identifier>
 <status value="[code]"/><!-- 1..1 draft | proposed | active | rejected | inactive | entered-in-error -->
 <category><!-- 0..* CodeableConcept Classification of the consent statement - for indexing/retrieval --></category>
 <dateTime value="[dateTime]"/><!-- 0..1 When this Consent was created or indexed -->
 <period><!-- 0..1 Period Period that this consent applies --></period>
 <patient><!-- 1..1 Reference(Patient) Who the consent applies to --></patient>
 <consentor><!-- 0..* Reference(Organization|Patient|Practitioner|RelatedPerson) Who is agreeing to the policy and exceptions --></consentor>
 <organization><!-- 0..1 Reference(Organization) Organization that manages the consent --></organization>
 <source[x]><!-- 0..1 Attachment|Identifier|Reference(Consent|DocumentReference|
   Contract|QuestionnaireResponse) Source from which this consent is taken --></source[x]>
 <policy value="[uri]"/><!-- 1..1 Policy that this consents to -->
 <recipient><!-- 0..* Reference(Device|Group|Organization|Patient|Practitioner|
   RelatedPerson|CareTeam) Whose access is controlled by the policy --></recipient>
 <purpose><!-- 0..* Coding Context of activities for which the agreement is made --></purpose>
 <except>  <!-- 0..* Additional rule -  addition or removal of permissions -->
  <type value="[code]"/><!-- 1..1 deny | permit -->
  <period><!-- 0..1 Period Timeframe for data controlled by this exception --></period>
  <actor>  <!-- 0..* Who|what controlled by this exception (or group, by role) -->
   <role><!-- 1..1 CodeableConcept How the actor is/was involved --></role>
   <reference><!-- 1..1 Reference(Device|Group|CareTeam|Organization|Patient|
     Practitioner|RelatedPerson) Resource for the actor (or group, by role) --></reference>
  </actor>
  <action><!-- 0..* CodeableConcept Actions controlled by this exception --></action>
  <securityLabel><!-- 0..* Coding Security Labels that define affected resources --></securityLabel>
  <purpose><!-- 0..* Coding Context of activities covered by this exception --></purpose>
  <class><!-- 0..* Coding e.g. Resource Type, Profile, or CDA etc --></class>
  <code><!-- 0..* Coding e.g. LOINC or SNOMED CT code, etc in the content --></code>
  <data>  <!-- 0..* Data controlled by this exception -->
   <meaning value="[code]"/><!-- 1..1 instance | related | dependents -->
   <reference><!-- 1..1 Reference(Any) The actual data reference --></reference>
  </data>
 </except>
</Consent>

JSON Template

{
  "resourceType" : "Consent",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : { Identifier }, // Identifier for this record (external references)
  "status" : "<code>", // R!  draft | proposed | active | rejected | inactive | entered-in-error
  "category" : [{ CodeableConcept }], // Classification of the consent statement - for indexing/retrieval
  "dateTime" : "<dateTime>", // When this Consent was created or indexed
  "period" : { Period }, // Period that this consent applies
  "patient" : { Reference(Patient) }, // R!  Who the consent applies to
  "consentor" : [{ Reference(Organization|Patient|Practitioner|RelatedPerson) }], // Who is agreeing to the policy and exceptions
  "organization" : { Reference(Organization) }, // Organization that manages the consent
  // source[x]: Source from which this consent is taken. One of these 3:
  "sourceAttachment" : { Attachment },
  "sourceIdentifier" : { Identifier },
  "sourceReference" : { Reference(Consent|DocumentReference|Contract|
   QuestionnaireResponse) },
  "policy" : "<uri>", // R!  Policy that this consents to
  "recipient" : [{ Reference(Device|Group|Organization|Patient|Practitioner|
   RelatedPerson|CareTeam) }], // Whose access is controlled by the policy
  "purpose" : [{ Coding }], // Context of activities for which the agreement is made
  "except" : [{ // Additional rule -  addition or removal of permissions
    "type" : "<code>", // R!  deny | permit
    "period" : { Period }, // Timeframe for data controlled by this exception
    "actor" : [{ // Who|what controlled by this exception (or group, by role)
      "role" : { CodeableConcept }, // R!  How the actor is/was involved
      "reference" : { Reference(Device|Group|CareTeam|Organization|Patient|
     Practitioner|RelatedPerson) } // R!  Resource for the actor (or group, by role)
    }],
    "action" : [{ CodeableConcept }], // Actions controlled by this exception
    "securityLabel" : [{ Coding }], // Security Labels that define affected resources
    "purpose" : [{ Coding }], // Context of activities covered by this exception
    "class" : [{ Coding }], // e.g. Resource Type, Profile, or CDA etc
    "code" : [{ Coding }], // e.g. LOINC or SNOMED CT code, etc in the content
    "data" : [{ // Data controlled by this exception
      "meaning" : "<code>", // R!  instance | related | dependents
      "reference" : { Reference(Any) } // R!  The actual data reference
    }]
  }]
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .


[ a fhir:Consent;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:Consent.identifier [ Identifier ]; # 0..1 Identifier for this record (external references)
  fhir:Consent.status [ code ]; # 1..1 draft | proposed | active | rejected | inactive | entered-in-error
  fhir:Consent.category [ CodeableConcept ], ... ; # 0..* Classification of the consent statement - for indexing/retrieval
  fhir:Consent.dateTime [ dateTime ]; # 0..1 When this Consent was created or indexed
  fhir:Consent.period [ Period ]; # 0..1 Period that this consent applies
  fhir:Consent.patient [ Reference(Patient) ]; # 1..1 Who the consent applies to
  fhir:Consent.consentor [ Reference(Organization|Patient|Practitioner|RelatedPerson) ], ... ; # 0..* Who is agreeing to the policy and exceptions
  fhir:Consent.organization [ Reference(Organization) ]; # 0..1 Organization that manages the consent
  # Consent.source[x] : 0..1 Source from which this consent is taken. One of these 3
    fhir:Consent.sourceAttachment [ Attachment ]
    fhir:Consent.sourceIdentifier [ Identifier ]
    fhir:Consent.sourceReference [ Reference(Consent|DocumentReference|Contract|QuestionnaireResponse) ]
  fhir:Consent.policy [ uri ]; # 1..1 Policy that this consents to
  fhir:Consent.recipient [ Reference(Device|Group|Organization|Patient|Practitioner|RelatedPerson|CareTeam) ], ... ; # 0..* Whose access is controlled by the policy
  fhir:Consent.purpose [ Coding ], ... ; # 0..* Context of activities for which the agreement is made
  fhir:Consent.except [ # 0..* Additional rule -  addition or removal of permissions
    fhir:Consent.except.type [ code ]; # 1..1 deny | permit
    fhir:Consent.except.period [ Period ]; # 0..1 Timeframe for data controlled by this exception
    fhir:Consent.except.actor [ # 0..* Who|what controlled by this exception (or group, by role)
      fhir:Consent.except.actor.role [ CodeableConcept ]; # 1..1 How the actor is/was involved
      fhir:Consent.except.actor.reference [ Reference(Device|Group|CareTeam|Organization|Patient|Practitioner|RelatedPerson) ]; # 1..1 Resource for the actor (or group, by role)
    ], ...;
    fhir:Consent.except.action [ CodeableConcept ], ... ; # 0..* Actions controlled by this exception
    fhir:Consent.except.securityLabel [ Coding ], ... ; # 0..* Security Labels that define affected resources
    fhir:Consent.except.purpose [ Coding ], ... ; # 0..* Context of activities covered by this exception
    fhir:Consent.except.class [ Coding ], ... ; # 0..* e.g. Resource Type, Profile, or CDA etc
    fhir:Consent.except.code [ Coding ], ... ; # 0..* e.g. LOINC or SNOMED CT code, etc in the content
    fhir:Consent.except.data [ # 0..* Data controlled by this exception
      fhir:Consent.except.data.meaning [ code ]; # 1..1 instance | related | dependents
      fhir:Consent.except.data.reference [ Reference(Any) ]; # 1..1 The actual data reference
    ], ...;
  ], ...;
]

Changes since DSTU2

This resource did not exist in Release 2

Alternate definitions: Master Definition (XML, JSON), XML Schema/Schematron (for ) + JSON Schema, ShEx (for Turtle)

6.4.4.1 Terminology Bindings

Path	Definition	Type	Reference
Consent.status	Indicates the status of the consent	Required	ConsentStatus
Consent.category	A classification of the type of consents found in a consent statement	Example	Consent Category Codes
Consent.purpose Consent.except.purpose	What purposes of use are controlled by this exception. If more than one label is specified, operations must have all the specified labels	Extensible	PurposeOfUse
Consent.except.type	How an exception is statement is applied, as adding additional consent, or removing consent	Required	ConsentExceptType
Consent.except.actor.role	How an actor is involved in the consent considerations	Extensible	Consent Actor Roles
Consent.except.action	Detailed codes for the consent action.	Example	Consent Action Codes
Consent.except.securityLabel	Security Labels from the Healthcare Privacy and Security Classification System.	Extensible	All Security Labels
Consent.except.class	The class (type) of information a consent rule covers	Extensible	Consent Content Class
Consent.except.code	If this code is found in an instance, then the exception applies	Example	Consent Content Codes
Consent.except.data.meaning	How a resource reference is interpreted when testing consent restrictions	Required	ConsentDataMeaning

Path

Definition

Type

Reference

Consent.status

Indicates the status of the consent

Required

ConsentStatus

Consent.category

A classification of the type of consents found in a consent statement

Example

Consent Category Codes

Consent.purpose
Consent.except.purpose

What purposes of use are controlled by this exception. If more than one label is specified, operations must have all the specified labels

Extensible

PurposeOfUse

Consent.except.type

How an exception is statement is applied, as adding additional consent, or removing consent

Required

ConsentExceptType

Consent.except.actor.role

How an actor is involved in the consent considerations

Extensible

Consent Actor Roles

Consent.except.action

Detailed codes for the consent action.

Example

Consent Action Codes

Consent.except.securityLabel

Security Labels from the Healthcare Privacy and Security Classification System.

Extensible

All Security Labels

Consent.except.class

The class (type) of information a consent rule covers

Extensible

Consent Content Class

Consent.except.code

If this code is found in an instance, then the exception applies

Example

Consent Content Codes

Consent.except.data.meaning

How a resource reference is interpreted when testing consent restrictions

Required

ConsentDataMeaning

6.4.5 Policies

This speciifcation defines 2 magic values for consent policies:

URI

Description

http://hl7.org/fhir/ConsentPolicy/opt-in

The basic policy is to grant no authority. No actions are approved, unless they are explicitly detailed in the exceptions

http://hl7.org/fhir/ConsentPolicy/opt-out

The basic policy is to grant all authority. All actions are approved, unless they are explicitly detailed in the exceptions

Other jurisdictions (e.g. HL7 Affiliates) may define their additional lists of consent policy URI values that represent consent policies established by law or regulation

The Consent resource has a reference to a single policy. Many organizations will work in a context where multiple different consent regulations and policies apply. In these cases, the single policy reference refers to a policy document that resolves and reconciles the various policies, and presents a single policy for patient consent. If it is still necessary to track which of the underlying policies an exception is make in regard to, an extension may be used.

6.4.6 General Model

The following is the general model of Privacy Consent Directives.

There are context setting parameters:

Who - The patient
What - The data - specific resources are listed, empty list means all data covered by the consent.
Where - The domain and authority - what is the location boundary and authority boundary of this consent
When - The issued or captured
When - The timeframe for which the Consent applies
How - The actions covered. (such as purposes of use that are covered)
Whom - The recipient are grantees by the consent.

A Privacy Consent may transition through many states including: that no consent has been sought, consent has been proposed, consent has been rejected, and consent approved.

There are set of patterns.

No consent: All settings need a policy for when no consent has been captured. Often this allows treatment only.;
Opt-out: No sharing allowed for the specified domain, location, actions, and purposes;
Opt-out with exceptions: No sharing allowed, with some exceptions where it is allowed. Example: Withhold Authorization for Treatment except for Emergency Treatment;
Opt-in: Sharing for some purpose of use is authorized Sharing allowed for Treatment, Payment, and normal Operations; and
Opt-in with restrictions: Sharing allowed, but the patient may make exceptions (See the Canadian examples).

For each of these patterns (positive or negative pattern), there can be exceptions. These exceptions are explicitly recorded in the except element.

6.4.7 Realm specifics

6.4.7.1 US Realm sample Use-Cases

Five categories of Privacy Consent Directives are described in the Office of the National Coordinator for Health Information (ONC) Consent Directives Document released March 31, 2010, and include the following US-specific “Core consent options” for electronic exchange:

No consent: Health information of patients is automatically included—patients cannot opt out;
Opt-out: Default is for health information of patients to be included automatically, but the patient can opt out completely;
Opt-out with exceptions: Default is for health information of patients to be included, but the patient can opt out completely or allow only select data to be included;
Opt-in: Default is that no patient health information is included; patients must actively express consent to be included, but if they do so then their information must be all in or all out; and
Opt-in with restrictions: Default is that no patient health information is made available, but the patient may allow a subset of select data to be included.

A common exception is to explicitly exclude or explicitly include a period of time.

6.4.7.2 Canada Realm sample Use-Cases

The following scenarios are based on existing jurisdictional policy and are realized in existing systems in Canada. The default policy is one of implied consent for the provision of care, so these scenarios all deal with withdrawal or withholding consent for that purpose. In other jurisdictions, where an express consent model is used (Opt-In), these examples would contain the phrase "consent to" rather than "withhold" or "withdraw" consent for.

Withhold or withdraw consent for disclosure of records related to specific domain (e.g. DI, LAB, etc.)
Withhold or withdraw consent for disclosure of a specific record (e.g. Lab Order/Result)
Withhold or withdraw consent for disclosure to a specific provider organization
Withhold or withdraw consent for disclosure to a specific provider agent (an individual within an organization)
Withhold or withdraw consent for disclosure of records that were authored by a specific organization (or service delivery location).
Combinations of the above

6.4.7.3 Non Treatment Use-Cases

Also shown is an example where a Patient has authorized disclosure to a specific individual for purposes directed by the patient (possibly not a treatment case).

6.4.8 Search Parameters

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name	Type	Description	Paths
action	token	Actions controlled by this exception	Consent.except.action
actor	reference	Resource for the actor (or group, by role)	Consent.except.actor.reference (Practitioner, Group, Organization, CareTeam, Device, Patient, RelatedPerson)
category	token	Classification of the consent statement - for indexing/retrieval	Consent.category
consentor	reference	Who is agreeing to the policy and exceptions	Consent.consentor (Practitioner, Organization, Patient, RelatedPerson)
data	reference	The actual data reference	Consent.except.data.reference (Any)
date	date	When this Consent was created or indexed	Consent.dateTime
identifier	token	Identifier for this record (external references)	Consent.identifier
organization	reference	Organization that manages the consent	Consent.organization (Organization)
patient	reference	Who the consent applies to	Consent.patient (Patient)
period	date	Period that this consent applies	Consent.period
purpose	token	Context of activities covered by this exception	Consent.except.purpose
recipient	reference	Whose access is controlled by the policy	Consent.recipient (Practitioner, Group, Organization, CareTeam, Device, Patient, RelatedPerson)
security	token	Security Labels that define affected resources	Consent.except.securityLabel
source	reference	Source from which this consent is taken	Consent.source[x] (Consent, Contract, QuestionnaireResponse, DocumentReference)
status	token	draft \| proposed \| active \| rejected \| inactive \| entered-in-error	Consent.status