Security
and
Privacy
Community
Based
Collaborative
Care
Work
Group
|
Maturity
Level
:
| Trial Use | Security Category : Patient | Compartments : Patient |
A
record
of
a
healthcare
consumer’s
policy
choices,
choices
or
choices
made
on
their
behalf
by
a
third
party,
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
three
uses,
but
at
this
time,
only
the
privacy
use
case
is
modeled.
fully
modeled,
others
are
being
used
but
no
formal
modelling
exists.
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,
or
may
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:
Represent
a
Consent
Directive
Register
or
index
a
Consent
Directive
Query
and
respond
about
a
Consent
Directive
Retrieve
a
Consent
Directive
Notify
authorized
entities
about
Consent
Directive
status
changes
Determine
entities
authorized
to
collect,
access,
use
or
disclose
information
about
the
Consent
Directive
or
about
the
information
governed
by
the
Consent
Directive.
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
"transcribed".
It
provides
recipients
with
the
full
content
representation
they
may
require
for
compliance
purposes,
and
typically
include
a
reference
to
or
an
attached
unstructured
representation
for
recipients
needing
an
exact
copy
of
the
legal
agreement.
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:
Find
Active
Consent
Directive:
A
query
that
includes
sufficient
consent
directive
content
to
determine
whether
a
specific
party
is
authorized
to
share
information
governed
by
a
consent
directive
with
another
specific
party.
The
Response
is
either:
“Yes”
meaning
that
both
parties
are
authorized
to
share
the
information
with
one
another.
“No”
meaning
that
the
authorized
querier
is
not
permitted
to
share
with
another
specific
party
“No
information
found”
meaning
that
there
is
no
active
Consent
Directive
in
which
the
querier
is
authorized
to
share
the
governed
information.
Find
Consent
Directive
Authorized
Entities:
A
query
that
includes
sufficient
consent
directive
content
to
return
a
list
of
entities
with
which
the
querier
is
authorized
to
share
governed
information.
The
response
to
an
authorized
querier
is
the
list
of
any
authorized
entities
with
which
the
querier
is
permitted
to
share
governed
information.
The
response
to
an
unauthorized
querier
is
that
“no
information
is
found”.
Find
Consent
Directive(s):
A
query
that
includes
sufficient
consent
directive
content
to
return
a
list
of
Consent
Directive
metadata
for
an
authorized
querier
to
determine
what
Consent
Directives
are
available,
and
to
locate
and
retrieve
one
or
more
of
those
Consent
Directives
as
needed.
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
6.2.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
HL7
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
working
on
FHIR
provides
support
for
alternative
representations
for
expressing
interoperable
health
information
privacy
consent
directives
in
a
standard
form
for
the
exchange
Advance
Directives
and
enforcement
by
sending,
intermediating,
or
receiving
systems
of
privacy
policies
that
can
be
enforced
would
welcome
participation
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.
community.
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,
an
inline
attachment
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
acknowledgement
or
by
being
signed
-
either
on
paper,
or
digitally.
Consent
Signatures
will
be
found
in
the
Provenance
resource
(example
consent
and
signature
).
resource.
Implementation
Guides
will
generally
make
rules
about
what
signatures
are
required,
and
how
they
are
to
be
shared
and
used.
The
Consent
resource
is
structured
with
a
base
policy
(represented
as
Consent.policy/Consent.policyRule)
which
is
either
opt-in
permit
or
opt-out,
deny,
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,
Permission
and
ResearchSubject
.
This resource implements the Event pattern.
Structure
| Name | Flags | Card. | Type |
Description
&
Constraints
|
|---|---|---|---|---|
Consent
|
| DomainResource |
A
healthcare
consumer's
+ + Rule: IF Scope=research, Consent.subject must be a patient + Rule: IF Scope=treatment, Consent.subject must be a patient + Rule: IF Scope=research, ResearchStudyContext allowed Elements defined in Ancestors: id , meta , implicitRules , language , text , contained , extension , modifierExtension | |
identifier
|
Σ
| 0..* | Identifier |
Identifier
for
this
record
(external
references)
|
status
| ?! Σ | 1..1 | code |
draft
|
ConsentState ( Required ) |
|
scope
| ?! Σ | 1..1 | CodeableConcept |
Which
of
the
three
areas
this
resource
covers
(extensible)
Consent Scope Codes ( Extensible ) |
|
category
| Σ |
| CodeableConcept |
Classification
of
the
consent
statement
-
for
indexing/retrieval
Consent Category Codes ( |
subject
|
Σ
| 0..1 | Reference ( Patient | Practitioner ) | Who the consent applies to |
|
dateTime
| Σ | 0..1 | dateTime |
When
|
|
performer
| Σ | 0..* | Reference ( CareTeam | HealthcareService | Organization | Patient | Practitioner | RelatedPerson | PractitionerRole ) |
Who
is
agreeing
to
the
policy
and
|
|
|
|
Reference
(
|
| |
|
controller
| 0..* |
Reference
(
HealthcareService
|
Organization
|
Patient
|
Practitioner
)
|
Consent
Enforcer
| |
|
sourceAttachment
|
|
| Attachment |
Source
from
which
this
consent
is
taken
|
|
sourceReference
| 0..* | Reference ( Consent | DocumentReference | Contract | QuestionnaireResponse ) |
Source
from
which
this
consent
is
taken
| |
policy
| 0..* | BackboneElement |
Policies
covered
by
this
consent
| |
authority
| I | 0..1 | uri | Enforcement source for policy |
uri
| I | 0..1 | uri | Specific policy covered by this consent |
|
policyRule
| Σ I | 0..1 |
|
Regulation
that
this
consents
to
Consent PolicyRule Codes ( Extensible ) |
|
verification
| Σ | 0..* |
|
|
|
verified
|
Σ
| 1..1 |
| Has been verified |
|
|
| 0..1 |
|
Consent Vefication Codes ( Extensible ) |
|
verifiedBy
|
| 0..1 |
| Person conducting verification |
|
verifiedWith
|
|
|
| Person who verified |
|
verificationDate
|
| 0..* |
|
When
consent
verified
|
| Σ |
| BackboneElement |
|
type
|
Σ
| 0..1 | code |
deny
|
permit
|
|
period
| Σ | 0..1 | Period |
Timeframe
for
this
|
|
actor
| 0..* | BackboneElement |
Who|what
controlled
by
this
| |
|
role
| 1..1 | CodeableConcept |
How
the
actor
is
involved
SecurityRoleType ( Extensible ) | |
|
reference
| 1..1 | Reference ( Device | Group | CareTeam | Organization | Patient | Practitioner | RelatedPerson | PractitionerRole ) | Resource for the actor (or group, by role) | |
|
action
| Σ | 0..* | CodeableConcept |
Actions
controlled
by
this
Consent Action Codes ( Example ) |
|
securityLabel
| Σ | 0..* | Coding |
Security
Labels
that
define
affected
resources
|
|
purpose
| Σ | 0..* | Coding |
Context
of
activities
covered
by
this
PurposeOfUse
(
Extensible
)
|
|
class
| Σ | 0..* | Coding |
e.g.
Resource
Type,
Profile,
Consent Content Class ( Extensible ) |
|
code
| Σ | 0..* |
|
e.g.
LOINC
or
SNOMED
CT
code,
Consent Content Codes ( Example ) |
|
dataPeriod
| Σ | 0..1 | Period |
Timeframe
for
data
controlled
by
this
|
|
data
| Σ | 0..* | BackboneElement |
Data
controlled
by
this
|
|
meaning
| Σ | 1..1 | code |
instance
|
related
|
dependents
|
authoredby
ConsentDataMeaning ( Required ) |
|
reference
| Σ | 1..1 | Reference ( Any ) | The actual data reference |
provision
| 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> <</organization> <| </source[x]><identifier><!-- 0..* Identifier Identifier for this record (external references) --></identifier> <status value="[code]"/><!-- 1..1 draft | active | inactive | entered-in-error | unknown --> <scope><!-- 1..1 CodeableConcept Which of the three areas this resource covers (extensible) --></scope> <category><!-- 1..* CodeableConcept Classification of the consent statement - for indexing/retrieval --></category> <subject><!-- 0..1 Reference(Patient|Practitioner) Who the consent applies to --></subject> <dateTime value="[dateTime]"/><!-- 0..1 When consent was agreed to --> <performer><!-- 0..* Reference(CareTeam|HealthcareService|Organization|Patient| Practitioner|PractitionerRole|RelatedPerson) Who is agreeing to the policy and rules --></performer> <manager><!-- 0..* Reference(HealthcareService|Organization|Patient|Practitioner) Consent workflow management --></manager> <controller><!-- 0..* Reference(HealthcareService|Organization|Patient| Practitioner) Consent Enforcer --></controller> <sourceAttachment><!-- 0..* Attachment Source from which this consent is taken --></sourceAttachment> <sourceReference><!-- 0..* Reference(Consent|Contract|DocumentReference| QuestionnaireResponse) Source from which this consent is taken --></sourceReference> <policy> <!-- 0..* Policies covered by this consent -->< <<authority value="[uri]"/><!--0..1 Enforcement source for policy --> <uri value="[uri]"/><!--
< <</securityLabel> <</purpose> <</dataPeriod> < < <</reference> </data> < < <</period> < <</role> <| </reference><policyRule><!--<</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</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 | active | inactive | entered-in-error | unknown
"scope" : { CodeableConcept }, // R! Which of the three areas this resource covers (extensible)
"category" : [{ CodeableConcept }], // R! Classification of the consent statement - for indexing/retrieval
"subject" : { Reference(Patient|Practitioner) }, // Who the consent applies to
"dateTime" : "<dateTime>", // When consent was agreed to
"performer" : [{ Reference(CareTeam|HealthcareService|Organization|Patient|
Practitioner|PractitionerRole|RelatedPerson) }], // Who is agreeing to the policy and rules
"manager" : [{ Reference(HealthcareService|Organization|Patient|Practitioner) }], // Consent workflow management
"controller" : [{ Reference(HealthcareService|Organization|Patient|
Practitioner) }], // Consent Enforcer
"sourceAttachment" : [{ Attachment }], // Source from which this consent is taken
"sourceReference" : [{ Reference(Consent|Contract|DocumentReference|
QuestionnaireResponse) }], // Source from which this consent is taken
"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
"verificationType" : { CodeableConcept }, // Business case of verification
"verifiedBy" : { Reference(Organization|Practitioner|PractitionerRole) }, // Person conducting verification
"verifiedWith" : { Reference(Patient|RelatedPerson) }, // Person who verified
"verificationDate" : ["<dateTime>"] // When consent verified
}],
"
"
"
"
"
"|
"provision" : { // Constraints to the base Consent.policyRule/Consent.policy
"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(CareTeam|Device|Group|Organization|Patient|
Practitioner|PractitionerRole|RelatedPerson) } // 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: fhir: fhir: fhir: fhir: fhir: fhir: fhir: fhir: ], ...; fhir: fhir: # . One of these 3 fhir: ] fhir: ] fhir:) ]fhir:Consent.identifier [ Identifier ], ... ; # 0..* Identifier for this record (external references) fhir:Consent.status [ code ]; # 1..1 draft | active | inactive | entered-in-error | unknown fhir:Consent.scope [ CodeableConcept ]; # 1..1 Which of the three areas this resource covers (extensible) fhir:Consent.category [ CodeableConcept ], ... ; # 1..* Classification of the consent statement - for indexing/retrieval fhir:Consent.subject [ Reference(Patient|Practitioner) ]; # 0..1 Who the consent applies to fhir:Consent.dateTime [ dateTime ]; # 0..1 When consent was agreed to fhir:Consent.performer [ Reference(CareTeam|HealthcareService|Organization|Patient|Practitioner|PractitionerRole| RelatedPerson) ], ... ; # 0..* Who is agreeing to the policy and rules fhir:Consent.manager [ Reference(HealthcareService|Organization|Patient|Practitioner) ], ... ; # 0..* Consent workflow management fhir:Consent.controller [ Reference(HealthcareService|Organization|Patient|Practitioner) ], ... ; # 0..* Consent Enforcer fhir:Consent.sourceAttachment [ Attachment ], ... ; # 0..* Source from which this consent is taken fhir:Consent.sourceReference [ Reference(Consent|Contract|DocumentReference|QuestionnaireResponse) ], ... ; # 0..* Source from which this consent is taken 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.verificationType [ CodeableConcept ]; # 0..1 Business case of verification fhir:Consent.verification.verifiedBy [ Reference(Organization|Practitioner|PractitionerRole) ]; # 0..1 Person conducting verification fhir:Consent.verification.verifiedWith [ Reference(Patient|RelatedPerson) ]; # 0..1 Person who verified fhir:Consent.verification.verificationDate [ dateTime ], ... ; # 0..* When consent verified ], ...;fhir: fhir: fhir: fhir: fhir: fhir:fhir:Consent.provision [ # 0..1 Constraints to the base Consent.policyRule/Consent.policy 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(CareTeam|Device|Group|Organization|Patient|Practitioner|PractitionerRole| RelatedPerson) ]; # 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.status |
|
| Consent.subject |
|
| Consent.performer |
|
| Consent.manager |
|
| Consent.controller |
|
| Consent.sourceAttachment |
|
| Consent.sourceReference |
|
| Consent.verification.verificationType |
|
| Consent.verification.verifiedBy |
|
| Consent.verification.verificationDate |
|
| Consent.provision.type |
|
| Consent.provision.data.meaning |
|
| Consent.patient |
|
| Consent.organization |
|
| Consent.source[x] |
|
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
|
|---|---|---|---|---|
|
Consent
|
| DomainResource |
A
healthcare
consumer's
+ + Rule: IF Scope=research, Consent.subject must be a patient + Rule: IF Scope=treatment, Consent.subject must be a patient + Rule: IF Scope=research, ResearchStudyContext allowed Elements defined in Ancestors: id , meta , implicitRules , language , text , contained , extension , modifierExtension | |
|
identifier
|
Σ
| 0..* | Identifier |
Identifier
for
this
record
(external
references)
|
|
status
| ?! Σ | 1..1 | code |
draft
|
ConsentState ( Required ) |
|
scope
| ?! Σ | 1..1 | CodeableConcept |
Which
of
the
three
areas
this
resource
covers
(extensible)
Consent Scope Codes ( Extensible ) |
|
category
| Σ |
| CodeableConcept |
Classification
of
the
consent
statement
-
for
indexing/retrieval
Consent Category Codes ( |
|
subject
|
Σ
| 0..1 | Reference ( Patient | Practitioner ) | Who the consent applies to |
|
dateTime
| Σ | 0..1 | dateTime |
When
|
|
performer
| Σ | 0..* | Reference ( CareTeam | HealthcareService | Organization | Patient | Practitioner | RelatedPerson | PractitionerRole ) |
Who
is
agreeing
to
the
policy
and
|
|
|
|
Reference
(
|
| |
|
controller
| 0..* |
Reference
(
HealthcareService
|
Organization
|
Patient
|
Practitioner
)
|
Consent
Enforcer
| |
|
sourceAttachment
|
|
| Attachment |
Source
from
which
this
consent
is
taken
|
|
sourceReference
| 0..* | Reference ( Consent | DocumentReference | Contract | QuestionnaireResponse ) |
Source
from
which
this
consent
is
taken
| |
|
policy
| 0..* | BackboneElement |
Policies
covered
by
this
consent
| |
|
authority
| I | 0..1 | uri | Enforcement source for policy |
|
uri
| I | 0..1 | uri | Specific policy covered by this consent |
|
policyRule
| Σ I | 0..1 |
|
Regulation
that
this
consents
to
Consent PolicyRule Codes ( Extensible ) |
|
verification
| Σ | 0..* |
|
|
|
verified
|
Σ
| 1..1 |
| Has been verified |
|
|
| 0..1 |
|
Consent Vefication Codes ( Extensible ) |
|
verifiedBy
|
| 0..1 |
| Person conducting verification |
|
verifiedWith
|
|
|
| Person who verified |
|
verificationDate
|
| 0..* |
|
When
consent
verified
|
|
| Σ |
| BackboneElement |
|
|
type
|
Σ
| 0..1 | code |
deny
|
permit
|
|
period
| Σ | 0..1 | Period |
Timeframe
for
this
|
|
actor
| 0..* | BackboneElement |
Who|what
controlled
by
this
| |
|
role
| 1..1 | CodeableConcept |
How
the
actor
is
involved
SecurityRoleType ( Extensible ) | |
|
reference
| 1..1 | Reference ( Device | Group | CareTeam | Organization | Patient | Practitioner | RelatedPerson | PractitionerRole ) | Resource for the actor (or group, by role) | |
|
action
| Σ | 0..* | CodeableConcept |
Actions
controlled
by
this
Consent Action Codes ( Example ) |
|
securityLabel
| Σ | 0..* | Coding |
Security
Labels
that
define
affected
resources
|
|
purpose
| Σ | 0..* | Coding |
Context
of
activities
covered
by
this
PurposeOfUse
(
Extensible
)
|
|
class
| Σ | 0..* | Coding |
e.g.
Resource
Type,
Profile,
Consent Content Class ( Extensible ) |
|
code
| Σ | 0..* |
|
e.g.
LOINC
or
SNOMED
CT
code,
Consent Content Codes ( Example ) |
|
dataPeriod
| Σ | 0..1 | Period |
Timeframe
for
data
controlled
by
this
|
|
data
| Σ | 0..* | BackboneElement |
Data
controlled
by
this
|
|
meaning
| Σ | 1..1 | code |
instance
|
related
|
dependents
|
authoredby
ConsentDataMeaning ( Required ) |
|
reference
| Σ | 1..1 | Reference ( Any ) | The actual data reference |
|
provision
| 0..* | see provision |
Nested
Exception
Rules
| |
|
Documentation
for
this
format
| ||||
XML Template
<Consent xmlns="http://hl7.org/fhir"><</identifier> < <</category> <</patient> <</period> < <| </consentingParty> < <</role> <| </reference> </actor> <</action> <</organization> <| </source[x]><identifier><!-- 0..* Identifier Identifier for this record (external references) --></identifier> <status value="[code]"/><!-- 1..1 draft | active | inactive | entered-in-error | unknown --> <scope><!-- 1..1 CodeableConcept Which of the three areas this resource covers (extensible) --></scope> <category><!-- 1..* CodeableConcept Classification of the consent statement - for indexing/retrieval --></category> <subject><!-- 0..1 Reference(Patient|Practitioner) Who the consent applies to --></subject> <dateTime value="[dateTime]"/><!-- 0..1 When consent was agreed to --> <performer><!-- 0..* Reference(CareTeam|HealthcareService|Organization|Patient| Practitioner|PractitionerRole|RelatedPerson) Who is agreeing to the policy and rules --></performer> <manager><!-- 0..* Reference(HealthcareService|Organization|Patient|Practitioner) Consent workflow management --></manager> <controller><!-- 0..* Reference(HealthcareService|Organization|Patient| Practitioner) Consent Enforcer --></controller> <sourceAttachment><!-- 0..* Attachment Source from which this consent is taken --></sourceAttachment> <sourceReference><!-- 0..* Reference(Consent|Contract|DocumentReference| QuestionnaireResponse) Source from which this consent is taken --></sourceReference> <policy> <!-- 0..* Policies covered by this consent -->< <<authority value="[uri]"/><!--< <</securityLabel> <</purpose> <</dataPeriod> < < <</reference> </data> < < <</period> < <</role> <| </reference><policyRule><!--<</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</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 | active | inactive | entered-in-error | unknown
"scope" : { CodeableConcept }, // R! Which of the three areas this resource covers (extensible)
"category" : [{ CodeableConcept }], // R! Classification of the consent statement - for indexing/retrieval
"subject" : { Reference(Patient|Practitioner) }, // Who the consent applies to
"dateTime" : "<dateTime>", // When consent was agreed to
"performer" : [{ Reference(CareTeam|HealthcareService|Organization|Patient|
Practitioner|PractitionerRole|RelatedPerson) }], // Who is agreeing to the policy and rules
"manager" : [{ Reference(HealthcareService|Organization|Patient|Practitioner) }], // Consent workflow management
"controller" : [{ Reference(HealthcareService|Organization|Patient|
Practitioner) }], // Consent Enforcer
"sourceAttachment" : [{ Attachment }], // Source from which this consent is taken
"sourceReference" : [{ Reference(Consent|Contract|DocumentReference|
QuestionnaireResponse) }], // Source from which this consent is taken
"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
"verificationType" : { CodeableConcept }, // Business case of verification
"verifiedBy" : { Reference(Organization|Practitioner|PractitionerRole) }, // Person conducting verification
"verifiedWith" : { Reference(Patient|RelatedPerson) }, // Person who verified
"verificationDate" : ["<dateTime>"] // When consent verified
}],
"
"
"
"
"
"|
"provision" : { // Constraints to the base Consent.policyRule/Consent.policy
"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(CareTeam|Device|Group|Organization|Patient|
Practitioner|PractitionerRole|RelatedPerson) } // 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: fhir: fhir: fhir: fhir: fhir: fhir: fhir: fhir: ], ...; fhir: fhir: # . One of these 3 fhir: ] fhir: ] fhir:) ]fhir:Consent.identifier [ Identifier ], ... ; # 0..* Identifier for this record (external references) fhir:Consent.status [ code ]; # 1..1 draft | active | inactive | entered-in-error | unknown fhir:Consent.scope [ CodeableConcept ]; # 1..1 Which of the three areas this resource covers (extensible) fhir:Consent.category [ CodeableConcept ], ... ; # 1..* Classification of the consent statement - for indexing/retrieval fhir:Consent.subject [ Reference(Patient|Practitioner) ]; # 0..1 Who the consent applies to fhir:Consent.dateTime [ dateTime ]; # 0..1 When consent was agreed to fhir:Consent.performer [ Reference(CareTeam|HealthcareService|Organization|Patient|Practitioner|PractitionerRole| RelatedPerson) ], ... ; # 0..* Who is agreeing to the policy and rules fhir:Consent.manager [ Reference(HealthcareService|Organization|Patient|Practitioner) ], ... ; # 0..* Consent workflow management fhir:Consent.controller [ Reference(HealthcareService|Organization|Patient|Practitioner) ], ... ; # 0..* Consent Enforcer fhir:Consent.sourceAttachment [ Attachment ], ... ; # 0..* Source from which this consent is taken fhir:Consent.sourceReference [ Reference(Consent|Contract|DocumentReference|QuestionnaireResponse) ], ... ; # 0..* Source from which this consent is taken 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.verificationType [ CodeableConcept ]; # 0..1 Business case of verification fhir:Consent.verification.verifiedBy [ Reference(Organization|Practitioner|PractitionerRole) ]; # 0..1 Person conducting verification fhir:Consent.verification.verifiedWith [ Reference(Patient|RelatedPerson) ]; # 0..1 Person who verified fhir:Consent.verification.verificationDate [ dateTime ], ... ; # 0..* When consent verified ], ...;fhir: fhir: fhir: fhir: fhir: fhir:fhir:Consent.provision [ # 0..1 Constraints to the base Consent.policyRule/Consent.policy 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(CareTeam|Device|Group|Organization|Patient|Practitioner|PractitionerRole| RelatedPerson) ]; # 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.status |
|
| Consent.subject |
|
| Consent.performer |
|
| Consent.manager |
|
| Consent.controller |
|
| Consent.sourceAttachment |
|
| Consent.sourceReference |
|
| Consent.verification.verificationType |
|
| Consent.verification.verifiedBy |
|
| Consent.verification.verificationDate |
|
| Consent.provision.type |
|
| Consent.provision.data.meaning |
|
| Consent.patient |
|
| Consent.organization |
|
| Consent.source[x] |
|
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
spreadsheet
version
&
the
dependency
analysis
a
| 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.verification.verificationType | Types of Verification/Validation. | Extensible | ConsentVerificationCodes |
| 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 |
|
|
What
purposes
of
use
are
controlled
by
this
exception.
If
more
than
one
label
is
specified,
operations
must
have
all
the
specified
| Extensible |
PurposeOfUse
|
|
|
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) |
IF
Scope=privacy,
Consent.subject
must
be
a
|
|
| ppc-2 | Rule | (base) | IF Scope=research, Consent.subject must be a patient |
(scope
=
'research'
and
subject.resolve().exists())
implies
(subject.resolve()
is
Patient)
|
|
|
|
|
|
(scope
=
'treatment'
and
subject.resolve().exists())
implies
(subject.resolve()
is
|
|
|
| (base) | IF Scope=research, ResearchStudyContext allowed |
Consent.provision.extension("http://hl7.org/fhir/StructureDefinition/consent-ResearchStudyContext").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.
Policies attached to Consent.policyRule language should be written using positive language. For an example, a patient wanting to opt-out will be recorded with an opt-in policy where the Consent.provision[0].type indicates "deny".
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
Tracking
changes
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:
can
be
managed
in
two
possible
ways:
HL7 does not recommend a specific method.
A
FHIR
Consent
Directive
instance
is
considered
the
encoded
legally
binding
Consent
Directive
if
it
meets
requirements
of
a
policy
domain
requirements
for
health
information
an
enforceable
contract.
In
some
domains,
electronic
signatures
of
patients
one
or
both
of
the
parties
to
be
included
automatically,
but
the
patient
can
opt
out
completely
;
Opt-out
with
exceptions:
Default
is
for
health
information
content
of
patients
an
encoded
representation
of
a
Consent
Form
is
deemed
to
be
included,
but
constitute
a
legally
binding
Consent
Directive.
Some
domains
accept
a
notary’s
electronic
signature
over
the
patient
can
opt
out
completely
wet
or
allow
only
select
data
electronic
signature
of
a
party
to
be
included;
Opt-in:
Default
is
that
no
patient
health
information
is
included;
patients
must
actively
express
consent
the
Consent
Directive
as
the
additional
identity
proofing
required
to
be
included,
but
if
they
do
so
then
their
information
must
be
all
in
make
an
encoded
Consent
Directive
legally
binding.
Other
domains
may
only
accept
a
wet
signature
or
all
out;
and
Opt-in
with
restrictions:
Default
is
that
no
patient
health
information
is
made
available,
but
might
not
require
the
patient
may
allow
parties’
signatures
at
all.
Whatever
the
criteria
are
for
making
an
encoded
FHIR
Consent
Directive
legally
binding,
anything
less
than
a
subset
legally
binding
representation
of
select
data
to
a
Consent
Directive
must
be
included.
A
common
exception
is
to
explicitly
exclude
or
explicitly
include
identified
as
such,
i.e.,
as
a
period
derivative
of
time
.
the
legally
binding
Consent
Directive,
which
has
specific
usage
in
Consent
Directive
workflow
management.
Definitions:
| Consent |
The
|
| Consent Directive |
The
|
| Consent Form |
Human
readable
consent
|
| 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
|
| Consent Statement |
A
Consent
Directive
derivative
has
less
than
full
fidelity
to
the
legally
binding
Consent
Directive
from
which
it
was
"transcribed".
It
provides
recipients
with
the
full
content
representation
they
may
require
for
compliance
purposes,
and
typically
include
a
|
| 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
|
| 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 |
Also
shown
Privacy
policies
define
how
Individually
Identifiable
Health
Information
(IIHI)
is
an
example
where
to
be
collected,
accessed,
used
and
disclosed.
A
Privacy
Consent
Directive
as
a
Patient
has
authorized
disclosure
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
specific
individual
given
context
for
specific
purposes
directed
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
patient
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.
The
following
steps
represent
the
optimal
path
for
searching
for
a
treatment
case).
Consent
resource.
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 , CareTeam , Patient , HealthcareService , PractitionerRole , RelatedPerson ) | |
| controller | reference | Consent Enforcer |
Consent.controller
( Practitioner , Organization , Patient , HealthcareService ) | |
| data | reference | The actual data reference |
(Any) | |
| date N | date |
When
| Consent.dateTime |
|
| identifier | token | Identifier for this record (external references) | Consent.identifier |
|
|
| reference |
|
( Practitioner , Organization , Patient , HealthcareService ) | |
| patient | reference | Who the consent applies to |
( Practitioner , Patient ) |
|
| period | date |
|
| |
| policy-uri N | uri | Search for Consents aligned with a specific policy or policy date/version. URIs should be complete with date/version and not assume the Resource will maintain versioning information | Consent.policy.uri | |
| purpose | token |
Context
of
activities
| Consent.provision.purpose | |
| scope | token |
Which
of
the
|
| |
|
| token | Security Labels that define affected resources |
| |
|
| reference |
|
( Consent , Contract , QuestionnaireResponse , DocumentReference ) | |
| status N | token |
draft
|
| Consent.status | |
| subject | reference | Who the consent applies to |
Consent.subject
( Practitioner , Patient ) | |
| verified N | token | Has been verified | Consent.verification.verified | |
| verified-date N | date | When consent verified | Consent.verification.verificationDate |
FHIR
®©
HL7.org
2011+.
FHIR
Release
3
(STU;
v3.0.2-11200)
R5
Preview
#3
hl7.fhir.core#4.5.0
generated
on
Thurs,
Oct
24,
2019
11:53+1100.
QA
Page
Fri,
Jan
15,
2021
05:57+0000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
QA
Page
|
Compare
to
DSTU2
R4
|
|
Propose
a
change