This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
(v4.0.1:
R4
-
Mixed
Normative
and
STU
3).
)
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
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
R4
R3
R2
Community
Based
Collaborative
Care
Work
Group
|
Maturity
Level
:
|
Trial Use | Security Category : Patient | 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.
The purpose of this Resource is to be used to express a Consent regarding Healthcare. There are four anticipated uses for the Consent Resource, all of which are written or verbal agreements by a healthcare consumer [grantor] or a personal representative, made to an authorized entity [grantee] concerning authorized or restricted actions with any limitations on purpose of use, and handling instructions to which the authorized entity must comply:
This resource is scoped to cover all four uses, but at this time, only the privacy use case is modeled. The scope of the resource may change when the other possible scopes are investigated, tested, or profiled.
A
FHIR
Consent
Directive
instance
is
considered
the
encoded
legally
binding
Consent
Directive
if
it
meets
requirements
of
a
policy
domain
requirements
for
an
enforceable
contract.
In
some
domains,
electronic
signatures
of
one
or
both
of
the
parties
to
the
content
of
an
encoded
representation
of
a
Consent
Form
is
deemed
to
constitute
a
legally
binding
Consent
Directive.
Some
domains
accept
a
notary’s
electronic
signature
over
the
wet
or
electronic
signature
of
a
party
to
the
Consent
Directive
as
the
additional
identity
proofing
required
to
make
an
encoded
Consent
Directive
legally
binding.
Other
domains
may
only
accept
a
wet
signature,
signature
or
may
might
not
require
the
parties’
signatures
at
all.
Whatever the criteria are for making an encoded FHIR Consent Directive legally binding, anything less than a legally binding representation of a Consent Directive must be identified as such, i.e., as a derivative of the legally binding Consent Directive, which has specific usage in Consent Directive workflow management.
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 |
| Consent Form | Human readable consent content describing one or more actions impacting the grantor for which the grantee would be authorized or prohibited from performing. It includes the terms, rules, and conditions pertaining to the authorization or restrictions, such as effective time, applicability or scope, purposes of use, obligations and prohibitions to which the grantee must comply. Once a Consent Form is “executed” by means required by policy, such as verbal agreement, wet signature, or electronic/digital signature, it becomes a legally binding Consent Directive. |
| Consent Directive Derivative |
Consent
Content
that
conveys
the
minimal
set
of
information
needed
to
manage
Consent
Directive
workflow,
including
providing
Consent
Directive
content
sufficient
to:
Derived Consent content includes the Security Labels encoding the applicable privacy and security policies. Consent Security Labels inform recipients about specific access control measures required for compliance. |
| Consent Statement |
A
Consent
Directive
derivative
has
less
than
full
fidelity
to
the
legally
binding
Consent
Directive
from
which
it
was
|
| Consent Registration | 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 timeA Consent Directive derivative that conveys the minimal set of information needed to register an active and revoked Consent Directive, or to update Consent status as it changes during its lifecycle. |
| Consent Query/Response Types |
The
FHIR
Consent
Resource
specifies
multiple
Consent
Search
parameters,
which
support
many
types
of
queries
for
Consent
Resource
content.
There
are
several
Query/Response
patterns
that
are
typically
used
for
obtaining
information
about
consent
directive
content
for
the
following
use
cases:
|
| 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 |
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 consumer to delegate authority to a Substitute Decision Maker who may act on behalf of that individual. Alternatively, a consumer 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 interoperable health information privacy consent directives in a standard form for the exchange and enforcement by sending, intermediating, or receiving systems of privacy policies that can be enforced by consuming systems (e.g., scanned documents, of computable structured entries elements, FHIR structures with optional attached, or referenced unstructured representations.) It may be used to represent the Privacy Consent Directive itself, a Consent Statement, which electronically represents a Consent Directive, or Consent Metadata, which is the minimum necessary consent content derived from a Consent Directive for use in workflow management.
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:
,
which
incorporated
the
IHE
Basic
Patient
Privacy
Consents
(BPPC)
),
either
directly,
or
in
a
reference
The
consent
statements
represent
a
chain
that
refers
back
to
the
original
source
consent
directive.
Applications
may
be
able
to
follow
the
chain
back
to
the
source,
source
but
should
not
generally
assume
that
they
are
authorized
to
do
this.
Consent Directives are executed by verbal acknowledge or by being 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.
The
Change
to
"The
Consent
resource
is
structured
with
a
base
policy
(represented
as
Consent.policy/Consent.policyRule)
which
is
either
opt-in
or
opt-out,
followed
by
a
listing
of
exceptions
to
that
policy.
policy
(represented
as
Consent.provision(s)).
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,
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
is
not
in
scope
for
the
Consent
resource.
This
resource
is
referenced
by
researchsubject
itself
and
ResearchSubject
Structure
| Name | Flags | Card. | Type |
Description
&
Constraints
|
|---|---|---|---|---|
|
I TU | DomainResource |
A
healthcare
consumer's
+ Rule: Either a Policy or PolicyRule + Rule: IF Scope=privacy, there must be a patient + Rule: IF Scope=research, there must be a patient + Rule: IF Scope=adr, there must be a patient + Rule: IF Scope=treatment, there must be a patient Elements defined in Ancestors: id , meta , implicitRules , language , text , contained , extension , modifierExtension |
|
|
Σ | 0..* | Identifier |
Identifier
for
this
record
(external
references)
|
|
?! Σ | 1..1 | code |
draft
|
proposed
|
active
|
rejected
|
inactive
|
entered-in-error
ConsentState ( Required ) |
|
?! Σ | 1..1 | CodeableConcept |
Which
of
the
Consent |
|
Σ |
|
|
Consent Category Codes ( Extensible ) |
|
Σ | 0..1 |
|
Who the consent applies to |
|
Σ | 0..1 | dateTime | When this Consent was created or indexed |
|
Σ | 0..* | Reference ( Organization | Patient | Practitioner | RelatedPerson | PractitionerRole ) |
Who
is
agreeing
to
the
policy
and
|
|
Σ | 0..* | Reference ( Organization ) |
Custodian
of
the
consent
|
|
Σ | 0..1 | Source from which this consent is taken | |
|
|
|
||
|
Reference ( Consent | DocumentReference | Contract | QuestionnaireResponse ) | |||
|
0..* | BackboneElement |
Policies
covered
by
this
consent
|
|
|
I | 0..1 | uri | Enforcement source for policy |
|
I | 0..1 | uri | Specific policy covered by this consent |
|
Σ I | 0..1 |
|
Regulation
that
this
consents
to
|
|
Σ | 0..* |
|
|
|
Σ | 1..1 |
|
Has been verified |
|
|
|
|
Person who verified |
|
0..1 |
|
When consent verified | |
|
Σ |
|
BackboneElement |
|
|
Σ | 0..1 | code |
deny
|
permit
|
|
Σ | 0..1 | Period |
Timeframe
for
this
|
|
0..* | BackboneElement |
Who|what
controlled
by
this
|
|
|
1..1 | CodeableConcept |
How
the
actor
is
involved
SecurityRoleType ( Extensible ) |
|
|
1..1 | Reference ( Device | Group | CareTeam | Organization | Patient | Practitioner | RelatedPerson | PractitionerRole ) | Resource for the actor (or group, by role) | |
|
Σ | 0..* | CodeableConcept |
Actions
controlled
by
this
Consent Action Codes ( Example ) |
|
Σ | 0..* | Coding |
Security
Labels
that
define
affected
resources
|
|
Σ | 0..* | Coding |
Context
of
activities
covered
by
this
|
|
Σ | 0..* | Coding |
e.g.
Resource
Type,
Profile,
Consent Content Class ( Extensible ) |
|
Σ | 0..* |
|
e.g.
LOINC
or
SNOMED
CT
code,
Consent Content Codes ( Example ) |
|
Σ | 0..1 | Period |
Timeframe
for
data
controlled
by
this
|
|
Σ | 0..* | BackboneElement |
Data
controlled
by
this
|
|
Σ | 1..1 | code |
instance
|
related
|
dependents
|
authoredby
ConsentDataMeaning ( Required ) |
|
Σ | 1..1 | Reference ( Any ) | The actual data reference |
| 0..* | see provision |
Nested
Exception
Rules
| |
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> < <</category> <</patient> <</period> < <| </consentingParty> < <</role> <| </reference> </actor> <</action><identifier><!-- 0..* Identifier Identifier for this record (external references) --></identifier> <status value="[code]"/><!-- 1..1 draft | proposed | active | rejected | inactive | entered-in-error --> <scope><!-- 1..1 CodeableConcept Which of the four areas this resource covers (extensible) --></scope> <category><!-- 1..* CodeableConcept Classification of the consent statement - for indexing/retrieval --></category> <patient><!-- 0..1 Reference(Patient) Who the consent applies to --></patient> <dateTime value="[dateTime]"/><!-- 0..1 When this Consent was created or indexed --> <performer><!-- 0..* Reference(Organization|Patient|Practitioner|RelatedPerson| PractitionerRole) Who is agreeing to the policy and rules --></performer> <organization><!-- 0..* Reference(Organization) Custodian of the consent --></organization><| </source[x]><source[x]><!-- 0..1 Attachment|Reference(Consent|DocumentReference|Contract| QuestionnaireResponse) Source from which this consent is taken --></source[x]> <policy> <!-- 0..* Policies covered by this consent -->< <<authority value="[uri]"/><!--0..1 Enforcement source for policy --> <uri value="[uri]"/><!--
0..1 Specific policy covered by this consent --> </policy>
< <</securityLabel> <</purpose> <</dataPeriod> < < <</reference> </data> < < <</period> < <</role> <| </reference><policyRule><!--0..1 CodeableConcept Regulation that this consents to --></policyRule> <verification> <!-- 0..* Consent Verified by patient or family --> <verified value="[boolean]"/><!-- 1..1 Has been verified --> <verifiedWith><!-- 0..1 Reference(Patient|RelatedPerson) Person who verified --></verifiedWith> <verificationDate value="[dateTime]"/><!-- 0..1 When consent verified --> </verification> <provision> <!-- 0..1 Constraints to the base Consent.policyRule --> <type value="[code]"/><!-- 0..1 deny | permit --> <period><!-- 0..1 Period Timeframe for this rule --></period> <actor> <!-- 0..* Who|what controlled by this rule (or group, by role) --> <role><!-- 1..1 CodeableConcept How the actor is involved --></role> <reference><!-- 1..1 Reference(Device|Group|CareTeam|Organization|Patient| Practitioner|RelatedPerson|PractitionerRole) Resource for the actor (or group, by role) --></reference> </actor>
<</action> <</securityLabel> <</purpose> <</class> <</code> <</dataPeriod> < < <</reference><action><!-- 0..* CodeableConcept Actions controlled by this rule --></action> <securityLabel><!-- 0..* Coding Security Labels that define affected resources --></securityLabel> <purpose><!-- 0..* Coding Context of activities covered by this rule --></purpose> <class><!-- 0..* Coding e.g. Resource Type, Profile, CDA, etc. --></class> <code><!-- 0..* CodeableConcept e.g. LOINC or SNOMED CT code, etc. in the content --></code> <dataPeriod><!-- 0..1 Period Timeframe for data controlled by this rule --></dataPeriod> <data> <!-- 0..* Data controlled by this rule --> <meaning value="[code]"/><!-- 1..1 instance | related | dependents | authoredby --> <reference><!-- 1..1 Reference(Any) The actual data reference --></reference> </data></except><provision><!-- 0..* Content as for Consent.provision Nested Exception Rules --></provision> </provision> </Consent>
JSON Template
{
"resourceType" : "",
"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
"scope" : { CodeableConcept }, // R! Which of the four areas this resource covers (extensible)
"category" : [{ CodeableConcept }], // R! Classification of the consent statement - for indexing/retrieval
"patient" : { Reference(Patient) }, // Who the consent applies to
"dateTime" : "<dateTime>", // When this Consent was created or indexed
"performer" : [{ Reference(Organization|Patient|Practitioner|RelatedPerson|
PractitionerRole) }], // Who is agreeing to the policy and rules
"organization" : [{ Reference(Organization) }], // Custodian of the consent
// source[x]: Source from which this consent is taken. One of these 2:
"sourceAttachment" : { Attachment },
"sourceReference" : { Reference(Consent|DocumentReference|Contract|
QuestionnaireResponse) },
"
"
"
"policy" : [{ // Policies covered by this consent
"authority" : "<uri>", // C? Enforcement source for policy
"uri" : "<uri>" // C? Specific policy covered by this consent
}],
"
"
"
"
"
"
"
"policyRule" : { CodeableConcept }, // C? Regulation that this consents to
"verification" : [{ // Consent Verified by patient or family
"verified" : <boolean>, // R! Has been verified
"verifiedWith" : { Reference(Patient|RelatedPerson) }, // Person who verified
"verificationDate" : "<dateTime>" // When consent verified
}],
"
"
"
"
"
"|
"provision" : { // Constraints to the base Consent.policyRule
"type" : "<code>", // deny | permit
"period" : { Period }, // Timeframe for this rule
"actor" : [{ // Who|what controlled by this rule (or group, by role)
"role" : { CodeableConcept }, // R! How the actor is involved
"reference" : { Reference(Device|Group|CareTeam|Organization|Patient|
Practitioner|RelatedPerson|PractitionerRole) } // R! Resource for the actor (or group, by role)
}],
"
"
"
"
"
"
"
"
"
}]
}]
"action" : [{ CodeableConcept }], // Actions controlled by this rule
"securityLabel" : [{ Coding }], // Security Labels that define affected resources
"purpose" : [{ Coding }], // Context of activities covered by this rule
"class" : [{ Coding }], // e.g. Resource Type, Profile, CDA, etc.
"code" : [{ CodeableConcept }], // e.g. LOINC or SNOMED CT code, etc. in the content
"dataPeriod" : { Period }, // Timeframe for data controlled by this rule
"data" : [{ // Data controlled by this rule
"meaning" : "<code>", // R! instance | related | dependents | authoredby
"reference" : { Reference(Any) } // R! The actual data reference
}],
"provision" : [{ Content as for Consent.provision }] // Nested Exception Rules
}
}
Turtle Template
@prefix fhir: <http://hl7.org/fhir/> .![]()
[ a 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 .modifierExtensionfhir:fhir:Consent.identifier [ Identifier ], ... ; # 0..* Identifier for this record (external references) fhir:Consent.status [ code ]; # 1..1 draft | proposed | active | rejected | inactive | entered-in-errorfhir: fhir: fhir:fhir:Consent.scope [ CodeableConcept ]; # 1..1 Which of the four areas this resource covers (extensible) fhir:Consent.category [ CodeableConcept ], ... ; # 1..* Classification of the consent statement - for indexing/retrieval fhir:Consent.patient [ Reference(Patient) ]; # 0..1 Who the consent applies to fhir:Consent.dateTime [ dateTime ]; # 0..1 When this Consent was created or indexedfhir: fhir: fhir: fhir: ], ...; fhir:fhir:Consent.performer [ Reference(Organization|Patient|Practitioner|RelatedPerson|PractitionerRole) ], ... ; # 0..* Who is agreeing to the policy and rules fhir:Consent.organization [ Reference(Organization) ], ... ; # 0..* Custodian of the consent# . One of these 3# Consent.source[x] : 0..1 Source from which this consent is taken. One of these 2 fhir:Consent.sourceAttachment [ Attachment ]fhir: ]fhir:Consent.sourceReference [ Reference(Consent|DocumentReference|Contract|QuestionnaireResponse) ] fhir:Consent.policy [ # 0..* Policies covered by this consentfhir:fhir:Consent.policy.authority [ uri ]; # 0..1 Enforcement source for policy fhir:Consent.policy.uri [ uri ]; # 0..1 Specific policy covered by this consent ], ...;fhir: fhir: fhir: fhir: fhir: fhir: fhir:fhir:Consent.policyRule [ CodeableConcept ]; # 0..1 Regulation that this consents to fhir:Consent.verification [ # 0..* Consent Verified by patient or family fhir:Consent.verification.verified [ boolean ]; # 1..1 Has been verified fhir:Consent.verification.verifiedWith [ Reference(Patient|RelatedPerson) ]; # 0..1 Person who verified fhir:Consent.verification.verificationDate [ dateTime ]; # 0..1 When consent verified ], ...;fhir: fhir: fhir: fhir: fhir: fhir:fhir:Consent.provision [ # 0..1 Constraints to the base Consent.policyRule fhir:Consent.provision.type [ code ]; # 0..1 deny | permit fhir:Consent.provision.period [ Period ]; # 0..1 Timeframe for this rule fhir:Consent.provision.actor [ # 0..* Who|what controlled by this rule (or group, by role) fhir:Consent.provision.actor.role [ CodeableConcept ]; # 1..1 How the actor is involved fhir:Consent.provision.actor.reference [ Reference(Device|Group|CareTeam|Organization|Patient|Practitioner|RelatedPerson| PractitionerRole) ]; # 1..1 Resource for the actor (or group, by role) ], ...;fhir: fhir: fhir: fhir: fhir: fhir: fhir: fhir: fhir:fhir:Consent.provision.action [ CodeableConcept ], ... ; # 0..* Actions controlled by this rule fhir:Consent.provision.securityLabel [ Coding ], ... ; # 0..* Security Labels that define affected resources fhir:Consent.provision.purpose [ Coding ], ... ; # 0..* Context of activities covered by this rule fhir:Consent.provision.class [ Coding ], ... ; # 0..* e.g. Resource Type, Profile, CDA, etc. fhir:Consent.provision.code [ CodeableConcept ], ... ; # 0..* e.g. LOINC or SNOMED CT code, etc. in the content fhir:Consent.provision.dataPeriod [ Period ]; # 0..1 Timeframe for data controlled by this rule fhir:Consent.provision.data [ # 0..* Data controlled by this rule fhir:Consent.provision.data.meaning [ code ]; # 1..1 instance | related | dependents | authoredby fhir:Consent.provision.data.reference [ Reference(Any) ]; # 1..1 The actual data reference ], ...;], ...;fhir:Consent.provision.provision [ See Consent.provision ], ... ; # 0..* Nested Exception Rules ]; ]
Changes
since
DSTU2
R3
| Consent | |
| Consent.identifier |
|
| Consent.status |
|
| Consent.scope |
|
| Consent.category |
|
| Consent.patient |
|
| Consent.performer |
|
| Consent.source[x] |
|
| Consent.policyRule |
|
| Consent.verification |
|
| Consent.verification.verified |
|
| Consent.verification.verifiedWith |
|
| Consent.verification.verificationDate |
|
| Consent.provision |
|
| Consent.provision.type |
|
| Consent.provision.period |
|
| Consent.provision.actor |
|
| Consent.provision.actor.role |
|
| Consent.provision.actor.reference |
|
| Consent.provision.action |
|
| Consent.provision.securityLabel |
|
| Consent.provision.purpose |
|
| Consent.provision.class |
|
| Consent.provision.code |
|
| Consent.provision.dataPeriod |
|
| Consent.provision.data |
|
| Consent.provision.data.meaning |
|
| Consent.provision.data.reference |
|
| Consent.provision.provision |
|
| Consent.period |
|
| Consent.consentingParty |
|
| Consent.actor |
|
| Consent.action |
|
| Consent.securityLabel |
|
| Consent.purpose |
|
| Consent.dataPeriod |
|
| Consent.data |
|
| Consent.except |
|
This
resource
did
not
exist
in
Release
2
See
the
Full
Difference
for
further
information
This analysis is available as XML or JSON .
See R3 <--> R4 Conversion Maps (status = 12 tests that all execute ok. All tests pass round-trip testing and 12 r3 resources are invalid (0 errors). )
Structure
| Name | Flags | Card. | Type |
Description
&
Constraints
|
|---|---|---|---|---|
|
I TU | DomainResource |
A
healthcare
consumer's
+ Rule: Either a Policy or PolicyRule + Rule: IF Scope=privacy, there must be a patient + Rule: IF Scope=research, there must be a patient + Rule: IF Scope=adr, there must be a patient + Rule: IF Scope=treatment, there must be a patient Elements defined in Ancestors: id , meta , implicitRules , language , text , contained , extension , modifierExtension |
|
|
Σ | 0..* | Identifier |
Identifier
for
this
record
(external
references)
|
|
?! Σ | 1..1 | code |
draft
|
proposed
|
active
|
rejected
|
inactive
|
entered-in-error
ConsentState ( Required ) |
|
?! Σ | 1..1 | CodeableConcept |
Which
of
the
Consent |
|
Σ |
|
|
Consent Category Codes ( Extensible ) |
|
Σ | 0..1 |
|
Who the consent applies to |
|
Σ | 0..1 | dateTime | When this Consent was created or indexed |
|
Σ | 0..* | Reference ( Organization | Patient | Practitioner | RelatedPerson | PractitionerRole ) |
Who
is
agreeing
to
the
policy
and
|
|
Σ | 0..* | Reference ( Organization ) |
Custodian
of
the
consent
|
|
Σ | 0..1 | Source from which this consent is taken | |
|
|
|
||
|
Reference ( Consent | DocumentReference | Contract | QuestionnaireResponse ) | |||
|
0..* | BackboneElement |
Policies
covered
by
this
consent
|
|
|
I | 0..1 | uri | Enforcement source for policy |
|
I | 0..1 | uri | Specific policy covered by this consent |
|
Σ I | 0..1 |
|
Regulation
that
this
consents
to
|
|
Σ | 0..* |
|
|
|
Σ | 1..1 |
|
Has been verified |
|
|
|
|
Person who verified |
|
0..1 |
|
When consent verified | |
|
Σ |
|
BackboneElement |
|
|
Σ | 0..1 | code |
deny
|
permit
|
|
Σ | 0..1 | Period |
Timeframe
for
this
|
|
0..* | BackboneElement |
Who|what
controlled
by
this
|
|
|
1..1 | CodeableConcept |
How
the
actor
is
involved
SecurityRoleType ( Extensible ) |
|
|
1..1 | Reference ( Device | Group | CareTeam | Organization | Patient | Practitioner | RelatedPerson | PractitionerRole ) | Resource for the actor (or group, by role) | |
|
Σ | 0..* | CodeableConcept |
Actions
controlled
by
this
Consent Action Codes ( Example ) |
|
Σ | 0..* | Coding |
Security
Labels
that
define
affected
resources
|
|
Σ | 0..* | Coding |
Context
of
activities
covered
by
this
|
|
Σ | 0..* | Coding |
e.g.
Resource
Type,
Profile,
Consent Content Class ( Extensible ) |
|
Σ | 0..* |
|
e.g.
LOINC
or
SNOMED
CT
code,
Consent Content Codes ( Example ) |
|
Σ | 0..1 | Period |
Timeframe
for
data
controlled
by
this
|
|
Σ | 0..* | BackboneElement |
Data
controlled
by
this
|
|
Σ | 1..1 | code |
instance
|
related
|
dependents
|
authoredby
ConsentDataMeaning ( Required ) |
|
Σ | 1..1 | Reference ( Any ) | The actual data reference |
| 0..* | see provision |
Nested
Exception
Rules
| |
Documentation
for
this
format
|
||||
XML Template
<<Consent xmlns="http://hl7.org/fhir"><!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension -->
<</identifier> < <</category> <</patient> <</period> < <| </consentingParty> < <</role> <| </reference> </actor> <</action><identifier><!-- 0..* Identifier Identifier for this record (external references) --></identifier> <status value="[code]"/><!-- 1..1 draft | proposed | active | rejected | inactive | entered-in-error --> <scope><!-- 1..1 CodeableConcept Which of the four areas this resource covers (extensible) --></scope> <category><!-- 1..* CodeableConcept Classification of the consent statement - for indexing/retrieval --></category> <patient><!-- 0..1 Reference(Patient) Who the consent applies to --></patient> <dateTime value="[dateTime]"/><!-- 0..1 When this Consent was created or indexed --> <performer><!-- 0..* Reference(Organization|Patient|Practitioner|RelatedPerson| PractitionerRole) Who is agreeing to the policy and rules --></performer> <organization><!-- 0..* Reference(Organization) Custodian of the consent --></organization><| </source[x]><source[x]><!-- 0..1 Attachment|Reference(Consent|DocumentReference|Contract| QuestionnaireResponse) Source from which this consent is taken --></source[x]> <policy> <!-- 0..* Policies covered by this consent -->< <<authority value="[uri]"/><!--0..1 Enforcement source for policy --> <uri value="[uri]"/><!--
0..1 Specific policy covered by this consent --> </policy>
< <</securityLabel> <</purpose> <</dataPeriod> < < <</reference> </data> < < <</period> < <</role> <| </reference><policyRule><!--0..1 CodeableConcept Regulation that this consents to --></policyRule> <verification> <!-- 0..* Consent Verified by patient or family --> <verified value="[boolean]"/><!-- 1..1 Has been verified --> <verifiedWith><!-- 0..1 Reference(Patient|RelatedPerson) Person who verified --></verifiedWith> <verificationDate value="[dateTime]"/><!-- 0..1 When consent verified --> </verification> <provision> <!-- 0..1 Constraints to the base Consent.policyRule --> <type value="[code]"/><!-- 0..1 deny | permit --> <period><!-- 0..1 Period Timeframe for this rule --></period> <actor> <!-- 0..* Who|what controlled by this rule (or group, by role) --> <role><!-- 1..1 CodeableConcept How the actor is involved --></role> <reference><!-- 1..1 Reference(Device|Group|CareTeam|Organization|Patient| Practitioner|RelatedPerson|PractitionerRole) Resource for the actor (or group, by role) --></reference> </actor>
<</action> <</securityLabel> <</purpose> <</class> <</code> <</dataPeriod> < < <</reference><action><!-- 0..* CodeableConcept Actions controlled by this rule --></action> <securityLabel><!-- 0..* Coding Security Labels that define affected resources --></securityLabel> <purpose><!-- 0..* Coding Context of activities covered by this rule --></purpose> <class><!-- 0..* Coding e.g. Resource Type, Profile, CDA, etc. --></class> <code><!-- 0..* CodeableConcept e.g. LOINC or SNOMED CT code, etc. in the content --></code> <dataPeriod><!-- 0..1 Period Timeframe for data controlled by this rule --></dataPeriod> <data> <!-- 0..* Data controlled by this rule --> <meaning value="[code]"/><!-- 1..1 instance | related | dependents | authoredby --> <reference><!-- 1..1 Reference(Any) The actual data reference --></reference> </data></except><provision><!-- 0..* Content as for Consent.provision Nested Exception Rules --></provision> </provision> </Consent>
JSON Template
{
"resourceType" : "",
"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
"scope" : { CodeableConcept }, // R! Which of the four areas this resource covers (extensible)
"category" : [{ CodeableConcept }], // R! Classification of the consent statement - for indexing/retrieval
"patient" : { Reference(Patient) }, // Who the consent applies to
"dateTime" : "<dateTime>", // When this Consent was created or indexed
"performer" : [{ Reference(Organization|Patient|Practitioner|RelatedPerson|
PractitionerRole) }], // Who is agreeing to the policy and rules
"organization" : [{ Reference(Organization) }], // Custodian of the consent
// source[x]: Source from which this consent is taken. One of these 2:
"sourceAttachment" : { Attachment },
"sourceReference" : { Reference(Consent|DocumentReference|Contract|
QuestionnaireResponse) },
"
"
"
"policy" : [{ // Policies covered by this consent
"authority" : "<uri>", // C? Enforcement source for policy
"uri" : "<uri>" // C? Specific policy covered by this consent
}],
"
"
"
"
"
"
"
"policyRule" : { CodeableConcept }, // C? Regulation that this consents to
"verification" : [{ // Consent Verified by patient or family
"verified" : <boolean>, // R! Has been verified
"verifiedWith" : { Reference(Patient|RelatedPerson) }, // Person who verified
"verificationDate" : "<dateTime>" // When consent verified
}],
"
"
"
"
"
"|
"provision" : { // Constraints to the base Consent.policyRule
"type" : "<code>", // deny | permit
"period" : { Period }, // Timeframe for this rule
"actor" : [{ // Who|what controlled by this rule (or group, by role)
"role" : { CodeableConcept }, // R! How the actor is involved
"reference" : { Reference(Device|Group|CareTeam|Organization|Patient|
Practitioner|RelatedPerson|PractitionerRole) } // R! Resource for the actor (or group, by role)
}],
"
"
"
"
"
"
"
"
"
}]
}]
"action" : [{ CodeableConcept }], // Actions controlled by this rule
"securityLabel" : [{ Coding }], // Security Labels that define affected resources
"purpose" : [{ Coding }], // Context of activities covered by this rule
"class" : [{ Coding }], // e.g. Resource Type, Profile, CDA, etc.
"code" : [{ CodeableConcept }], // e.g. LOINC or SNOMED CT code, etc. in the content
"dataPeriod" : { Period }, // Timeframe for data controlled by this rule
"data" : [{ // Data controlled by this rule
"meaning" : "<code>", // R! instance | related | dependents | authoredby
"reference" : { Reference(Any) } // R! The actual data reference
}],
"provision" : [{ Content as for Consent.provision }] // Nested Exception Rules
}
}
Turtle Template
@prefix fhir: <http://hl7.org/fhir/> .![]()
[ a 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 .modifierExtensionfhir:fhir:Consent.identifier [ Identifier ], ... ; # 0..* Identifier for this record (external references) fhir:Consent.status [ code ]; # 1..1 draft | proposed | active | rejected | inactive | entered-in-errorfhir: fhir: fhir:fhir:Consent.scope [ CodeableConcept ]; # 1..1 Which of the four areas this resource covers (extensible) fhir:Consent.category [ CodeableConcept ], ... ; # 1..* Classification of the consent statement - for indexing/retrieval fhir:Consent.patient [ Reference(Patient) ]; # 0..1 Who the consent applies to fhir:Consent.dateTime [ dateTime ]; # 0..1 When this Consent was created or indexedfhir: fhir: fhir: fhir: ], ...; fhir:fhir:Consent.performer [ Reference(Organization|Patient|Practitioner|RelatedPerson|PractitionerRole) ], ... ; # 0..* Who is agreeing to the policy and rules fhir:Consent.organization [ Reference(Organization) ], ... ; # 0..* Custodian of the consent# . One of these 3# Consent.source[x] : 0..1 Source from which this consent is taken. One of these 2 fhir:Consent.sourceAttachment [ Attachment ]fhir: ]fhir:Consent.sourceReference [ Reference(Consent|DocumentReference|Contract|QuestionnaireResponse) ] fhir:Consent.policy [ # 0..* Policies covered by this consentfhir:fhir:Consent.policy.authority [ uri ]; # 0..1 Enforcement source for policy fhir:Consent.policy.uri [ uri ]; # 0..1 Specific policy covered by this consent ], ...;fhir: fhir: fhir: fhir: fhir: fhir: fhir:fhir:Consent.policyRule [ CodeableConcept ]; # 0..1 Regulation that this consents to fhir:Consent.verification [ # 0..* Consent Verified by patient or family fhir:Consent.verification.verified [ boolean ]; # 1..1 Has been verified fhir:Consent.verification.verifiedWith [ Reference(Patient|RelatedPerson) ]; # 0..1 Person who verified fhir:Consent.verification.verificationDate [ dateTime ]; # 0..1 When consent verified ], ...;fhir: fhir: fhir: fhir: fhir: fhir:fhir:Consent.provision [ # 0..1 Constraints to the base Consent.policyRule fhir:Consent.provision.type [ code ]; # 0..1 deny | permit fhir:Consent.provision.period [ Period ]; # 0..1 Timeframe for this rule fhir:Consent.provision.actor [ # 0..* Who|what controlled by this rule (or group, by role) fhir:Consent.provision.actor.role [ CodeableConcept ]; # 1..1 How the actor is involved fhir:Consent.provision.actor.reference [ Reference(Device|Group|CareTeam|Organization|Patient|Practitioner|RelatedPerson| PractitionerRole) ]; # 1..1 Resource for the actor (or group, by role) ], ...;fhir: fhir: fhir: fhir: fhir: fhir: fhir: fhir: fhir:fhir:Consent.provision.action [ CodeableConcept ], ... ; # 0..* Actions controlled by this rule fhir:Consent.provision.securityLabel [ Coding ], ... ; # 0..* Security Labels that define affected resources fhir:Consent.provision.purpose [ Coding ], ... ; # 0..* Context of activities covered by this rule fhir:Consent.provision.class [ Coding ], ... ; # 0..* e.g. Resource Type, Profile, CDA, etc. fhir:Consent.provision.code [ CodeableConcept ], ... ; # 0..* e.g. LOINC or SNOMED CT code, etc. in the content fhir:Consent.provision.dataPeriod [ Period ]; # 0..1 Timeframe for data controlled by this rule fhir:Consent.provision.data [ # 0..* Data controlled by this rule fhir:Consent.provision.data.meaning [ code ]; # 1..1 instance | related | dependents | authoredby fhir:Consent.provision.data.reference [ Reference(Any) ]; # 1..1 The actual data reference ], ...;], ...;fhir:Consent.provision.provision [ See Consent.provision ], ... ; # 0..* Nested Exception Rules ]; ]
Changes
since
DSTU2
Release
3
| Consent | |
| Consent.identifier |
|
| Consent.status |
|
| Consent.scope |
|
| Consent.category |
|
| Consent.patient |
|
| Consent.performer |
|
| Consent.source[x] |
|
| Consent.policyRule |
|
| Consent.verification |
|
| Consent.verification.verified |
|
| Consent.verification.verifiedWith |
|
| Consent.verification.verificationDate |
|
| Consent.provision |
|
| Consent.provision.type |
|
| Consent.provision.period |
|
| Consent.provision.actor |
|
| Consent.provision.actor.role |
|
| Consent.provision.actor.reference |
|
| Consent.provision.action |
|
| Consent.provision.securityLabel |
|
| Consent.provision.purpose |
|
| Consent.provision.class |
|
| Consent.provision.code |
|
| Consent.provision.dataPeriod |
|
| Consent.provision.data |
|
| Consent.provision.data.meaning |
|
| Consent.provision.data.reference |
|
| Consent.provision.provision |
|
| Consent.period |
|
| Consent.consentingParty |
|
| Consent.actor |
|
| Consent.action |
|
| Consent.securityLabel |
|
| Consent.purpose |
|
| Consent.dataPeriod |
|
| Consent.data |
|
| Consent.except |
|
This
resource
did
not
exist
in
Release
2
See
the
Full
Difference
for
further
information
This analysis is available as XML or JSON .
See R3 <--> R4 Conversion Maps (status = 12 tests that all execute ok. All tests pass round-trip testing and 12 r3 resources are invalid (0 errors). )
Alternate
See
the
Profiles
&
Extensions
and
the
alternate
definitions:
Master
Definition
(
XML
,
+
JSON
),
,
XML
Schema
/
Schematron
(for
)
+
JSON
Schema
,
ShEx
(for
Turtle
)
+
see
the
extensions
&
the
dependency
analysis
| Path | Definition | Type | Reference |
|---|---|---|---|
| Consent.status |
Indicates
the
state
of
the
|
Required | ConsentState |
| Consent.scope | The four anticipated uses for the Consent Resource. | Extensible | ConsentScopeCodes |
| Consent.category |
A
classification
of
the
type
of
consents
found
in
a
consent
|
|
|
| Consent.policyRule | Regulatory policy examples. | Extensible | ConsentPolicyRuleCodes |
| Consent.provision.type | How a rule statement is applied, such as adding additional consent or removing consent. | Required | ConsentProvisionType |
|
|
How
an
actor
is
involved
in
the
consent
|
Extensible | SecurityRoleType |
|
|
Detailed codes for the consent action. | Example |
|
| Consent.provision.securityLabel | Security Labels from the Healthcare Privacy and Security Classification System. | Extensible | All Security Labels |
| Consent.provision.purpose |
What
purposes
of
use
are
controlled
by
this
exception.
If
more
than
one
label
is
specified,
operations
must
have
all
the
specified
|
Extensible |
|
|
|
The
class
(type)
of
information
a
consent
rule
|
Extensible |
|
|
|
If
this
code
is
found
in
an
instance,
then
the
exception
|
Example |
|
| Consent.provision.data.meaning | How a resource reference is interpreted when testing consent restrictions. | Required | ConsentDataMeaning |
| id | Level | Location | Description | Expression |
|
ppc-1
|
Rule | (base) |
Either
a
Policy
or
PolicyRule
|
|
| ppc-2 | Rule | (base) | IF Scope=privacy, there must be a patient |
patient.exists()
or
scope.coding.where(system='something'
and
code='patient-privacy').exists().not()
|
|
|
|
(base) | IF Scope=research, there must be a patient | patient.exists() or scope.coding.where(system='something' and code='research').exists().not() |
|
|
| (base) | IF Scope=adr, there must be a patient |
patient.exists()
or
|
|
|
| (base) | IF Scope=treatment, there must be a patient |
patient.exists()
or
scope.coding.where(system='something'
and
|
The
Consent
resource
has
a
reference
to
a
single
policyRule
.
Many
organizations
will
work
in
a
context
where
multiple
different
consent
regulations
and
policies
apply.
In
these
cases,
the
single
policy
rule
reference
refers
to
a
policy
document
that
resolves
and
reconciles
the
various
policies,
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,
the
policy
may
be
used.
The following is the general model of Privacy Consent Directives.
There are context setting parameters:
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.
For each of these patterns (positive or negative pattern), there can be exceptions. These exceptions are explicitly recorded in the except element.
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
"Core
consent
options”
options"
for
electronic
exchange:
A common exception is to explicitly exclude or explicitly include a period of time .
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"
"consent
to"
rather
than
"withhold"
"withhold"
or
"withdraw"
"withdraw"
consent
for.
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).
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 | Expression | In Common |
| action | token |
Actions
controlled
by
this
|
|
|
| actor | reference | Resource for the actor (or group, by role) |
( Practitioner , Group , Organization , CareTeam , Device , Patient , PractitionerRole , RelatedPerson ) |
|
| category | token | Classification of the consent statement - for indexing/retrieval | Consent.category | |
| consentor | reference |
Who
is
agreeing
to
the
policy
and
|
( Practitioner , Organization , Patient , PractitionerRole , RelatedPerson ) |
|
| data | reference | The actual 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 | Custodian of the consent |
Consent.organization
( Organization ) |
|
| patient | reference | Who the consent applies to |
Consent.patient
( Patient ) |
|
| period | date |
|
|
|
| purpose | token |
Context
of
activities
| Consent.provision.purpose | |
| scope | token |
Which
of
the
|
|
|
|
|
token | Security Labels that define affected resources |
|
|
|
|
reference |
|
Consent.source
( Consent , Contract , QuestionnaireResponse , DocumentReference ) |
|
| status | token | draft | proposed | active | rejected | inactive | entered-in-error | Consent.status |