This
page
is
part
of
the
FHIR
Specification
(v4.3.0:
R4B
(v5.0.0:
R5
-
STU
).
The
This
is
the
current
published
version
which
supercedes
in
it's
permanent
home
(it
will
always
be
available
at
this
version
is
5.0.0
.
URL).
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R5
R4B
R4
R3
R2
Work
Group
|
Maturity Level : N | Normative (from v4.0.0) |
Use
Context
:
|
Official
URL
:
http://hl7.org/fhir/ValueSet/security-labels
|
|
|||
| active as of 2014-07-28 |
|
|||
|
|
|
|||
This value set is used in the following places:
A single value set for all security labels defined by FHIR.
This value set includes codes based on the following rules:
This
expansion
generated
28
May
2022
26
Mar
2023
This
value
set
contains
488
416
concepts
Expansion based on:










| Code | System | Display | Definition |
|
http://terminology.hl7.org/CodeSystem/v3-Confidentiality | low |
Privacy
metadata
indicating
that
a
low
level
of
protection
is
required
to
safeguard
personal
and
healthcare
information,
which
has
been
altered
in
such
a
way
as
to
minimize
the
need
for
confidentiality
protections
with
some
residual
risks
associated
with
re-linking.
The
risk
of
harm
to
an
individual's
reputation
and
sense
of
privacy
if
disclosed
without
authorization
is
considered
negligible,
and
mitigations
are
in
place
to
address
reidentification
risk.
Usage Note:
The
level
of
protection
afforded
anonymized
and
pseudonymized,
and
non-personally
identifiable
information
(e.g.,
a
limited
data
set)
is
dictated
by
privacy
policies
and
data
use
agreements
intended
to
engender
trust
that
health
information
can
be
used
and
disclosed
with
little
or
no
risk
of
re-identification.
Example: Personal and healthcare information, which excludes 16 designated categories of direct identifiers in a HIPAA Limited Data Set. This information may be disclosed by HIPAA Covered Entities without patient authorization for a research, public health, and operations purposes if conditions are met, which includes obtaining a signed data use agreement from the recipient. See 45 CFR Section 164.514. This metadata indicates that the receiver may have an obligation to comply with a data use agreement with the discloser. The discloser may have obligations to comply with policies dictating the methods for de-identification.
Confidentiality
code
total
order
hierarchy:
Low
(L)
is
less
protective
than
|
M
|
http://terminology.hl7.org/CodeSystem/v3-Confidentiality | moderate |
Privacy
metadata
indicating
the
level
of
protection
required
to
safeguard
personal
and
healthcare
information,
which
if
disclosed
without
authorization,
would
present
a
moderate
risk
of
harm
to
an
individual's
reputation
and
sense
of
privacy.
Usage Note: The level of protection afforded moderately confidential information is dictated by privacy policies intended to engender trust in a service provider. May include publicly available information in jurisdictions that restrict uses of that information without the consent of the data subject. Privacy policies mandating moderate levels of protection, which preempt less protective privacy policies. "Moderate" confidentiality policies differ from and would be preempted by the prevailing privacy policies mandating the normative level of protection for information used in the delivery and management of healthcare.
Confidentiality
code
total
order
hierarchy:
Moderate
(M)
is
less
protective
than
Examples: Includes personal and health information that an individual authorizes to be collected, accessed, used or disclosed to a bank for a health credit card or savings account; to health oversight authorities; to a hospital patient directory; to worker compensation, disability, property and casualty or life insurers; and to personal health record systems, consumer-controlled devices, social media accounts and online Apps; or for marketing purposes |
N
|
http://terminology.hl7.org/CodeSystem/v3-Confidentiality | normal |
Privacy
metadata
indicating
the
level
of
protection
required
to
safeguard
personal
and
healthcare
information,
which
if
disclosed
without
authorization,
would
present
a
considerable
risk
of
harm
to
an
individual's
reputation
and
sense
of
privacy.
Usage Note: The level of protection afforded normatively confidential information is dictated by the prevailing normative privacy policies, which are intended to engender patient trust in their healthcare providers. Privacy policies mandating normative levels of protection, which preempt less protective privacy policies when the information is used in the delivery and management of healthcare. May be pre-empted by jurisdictional law (e.g., for public health reporting or emergency treatment).
Confidentiality
code
total
order
hierarchy:
Normal
(N)
is
less
protective
than
**Map:**Partial
Map
to
ISO
13606-4
Sensitivity
Level
(3)
Clinical
Care
when
purpose
of
use
is
treatment:
Default
for
normal
clinical
care
access
(i.e.,
most
clinical
staff
directly
caring
for
the
patient
should
be
able
to
access
nearly
all
of
the
EHR).
Maps
to
normal
confidentiality
for
treatment
information
but
not
to
ancillary
care,
payment
and
operations.
Examples: n the US, this includes what HIPAA identifies as protected health information (PHI) under 45 CFR Section 160.103. |
R
|
http://terminology.hl7.org/CodeSystem/v3-Confidentiality | restricted |
Privacy
metadata
indicating
the
level
of
protection
required
to
safeguard
potentially
stigmatizing
information,
which
if
disclosed
without
authorization,
would
present
a
high
risk
of
harm
to
an
individual's
reputation
and
sense
of
privacy.
Usage Note: The level of protection afforded restricted confidential information is dictated by specially protective organizational or jurisdictional privacy policies, including at an authorized individual’s request, intended to engender patient trust in providers of sensitive services. Privacy policies mandating additional levels of protection by restricting information access preempt less protective privacy policies when the information is used in the delivery and management of healthcare. May be pre-empted by jurisdictional law (e.g., for public health reporting or emergency treatment).
Confidentiality
code
total
order
hierarchy:
Restricted
(R)
is
less
protective
than
Examples: Includes information that is additionally protected such as sensitive conditions mental health, HIV, substance abuse, domestic violence, child abuse, genetic disease, and reproductive health; or sensitive demographic information such as a patient’s standing as an employee or a celebrity. May be used to indicate proprietary or classified information that is not related to an individual (e.g., secret ingredients in a therapeutic substance; or the name of a manufacturer). |
U
![]() | http://terminology.hl7.org/CodeSystem/v3-Confidentiality | unrestricted | Privacy metadata indicating that no level of protection is required to safeguard personal and healthcare information that has been disclosed by an authorized individual without restrictions on its use. Examples: Includes publicly available information e.g., business name, phone, email and physical address. Usage Note: The authorization to collect, access, use, and disclose this information may be stipulated in a contract of adhesion by a data user (e.g., via terms of service or data user privacy policies) in exchange for the data subject's use of a service. This metadata indicates that the receiver has no obligation to consider privacy policies other than its own when making access control decisions. This metadata indicates that the receiver has no obligation to consider privacy policies other than its own when making access control decisions. Confidentiality code total order hierarchy: Unrestricted (U) is less protective than V, R, N, M, and L , and is the lowest protection levels. |
V
|
http://terminology.hl7.org/CodeSystem/v3-Confidentiality | very restricted |
Privacy
metadata
indicating
the
level
of
protection
required
under
atypical
cicumstances
to
safeguard
potentially
damaging
or
harmful
information,
which
if
disclosed
without
authorization,
would
(1)
present
an
extremely
high
risk
of
harm
to
an
individual's
reputation,
sense
of
privacy,
and
possibly
safety;
or
(2)
impact
an
individual's
or
organization's
legal
matters.
Usage Note: The level of protection afforded very restricted confidential information is dictated by specially protective privacy or legal policies intended to ensure that under atypical circumstances additional protections limit access to only those with a high 'need to know' and the information is kept in highest confidence.. Privacy and legal policies mandating the highest level of protection by stringently restricting information access, preempt less protective privacy policies when the information is used in the delivery and management of healthcare including legal proceedings related to healthcare. May be pre-empted by jurisdictional law (e.g., for public health reporting or emergency treatment but only under limited circumstances).
Confidentiality
code
total
order
hierarchy:
Very
Restricted
(V)
is
the
highest
protection
level
and
subsumes
all
other
protection
levels
s
(i.e.,
Examples: Includes information about a victim of abuse, patient requested information sensitivity, and taboo subjects relating to health status that must be discussed with the patient by an attending provider before sharing with the patient. May also include information held under a legal hold or attorney-client privilege. |
_InformationSensitivityPolicy
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | InformationSensitivityPolicy |
A
mandate,
obligation,
requirement,
rule,
or
expectation
characterizing
the
value
or
importance
of
a
resource
and
may
include
its
vulnerability.
(Based
on
ISO7498-2:1989.
Note:
The
vulnerability
of
personally
identifiable
sensitive
information
may
be
based
on
concerns
that
the
unauthorized
disclosure
may
result
in
social
stigmatization
or
discrimination.)
Description:
Types
of
Sensitivity
policy
that
apply
to
Acts
or
Roles.
A
sensitivity
policy
is
adopted
by
an
enterprise
or
group
of
enterprises
(a
'policy
domain')
through
a
formal
data
use
agreement
that
stipulates
the
value,
importance,
and
vulnerability
of
information.
A
sensitivity
code
representing
a
sensitivity
policy
may
be
associated
with
criteria
such
as
categories
of
information
or
sets
of
information
identifiers
(e.g.,
a
value
set
of
clinical
codes
or
branch
in
a
code
system
hierarchy).
These
criteria
may
in
turn
be
used
for
the
Policy
Decision
Point
in
a
Security
Engine.
A
sensitivity
code
may
be
used
to
set
the
confidentiality
code
used
on
information
about
Acts
and
Roles
to
trigger
the
security
mechanisms
required
to
control
how
security
principals
(i.e.,
a
person,
a
machine,
a
software
application)
may
act
on
the
information
(e.g.,
collection,
access,
use,
or
disclosure).
Sensitivity
codes
are
never
assigned
to
the
transport
or
business
envelope
containing
patient
specific
information
being
exchanged
outside
of
a
policy
domain
as
this
would
disclose
the
information
intended
to
be
protected
by
the
policy.
When
sensitive
information
is
exchanged
with
others
outside
of
a
policy
domain,
the
confidentiality
code
on
the
transport
or
business
envelope
conveys
the
receiver's
responsibilities
and
indicates
the
how
the
information
is
to
be
safeguarded
without
unauthorized
disclosure
of
the
sensitive
information.
This
ensures
that
sensitive
information
is
treated
by
receivers
as
the
sender
intends,
accomplishing
interoperability
without
point
to
point
negotiations.
Usage Note: Sensitivity codes are not useful for interoperability outside of a policy domain because sensitivity policies are typically localized and vary drastically across policy domains even for the same information category because of differing organizational business rules, security policies, and jurisdictional requirements. For example, an employee's sensitivity code would make little sense for use outside of a policy domain. 'Taboo' would rarely be useful outside of a policy domain unless there are jurisdictional requirements requiring that a provider disclose sensitive information to a patient directly. Sensitivity codes may be more appropriate in a legacy system's Master Files in order to notify those who access a patient's orders and observations about the sensitivity policies that apply. Newer systems may have a security engine that uses a sensitivity policy's criteria directly. The specializable InformationSensitivityPolicy Act.code may be useful in some scenarios if used in combination with a sensitivity identifier and/or Act.title. |
_ActInformationSensitivityPolicy
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | ActInformationSensitivityPolicy |
Types
of
sensitivity
policies
that
apply
to
Acts.
Act.confidentialityCode
is
defined
in
the
RIM
as
"constraints
around
appropriate
disclosure
of
information
about
this
Act,
regardless
of
mood."
Usage Note: ActSensitivity codes are used to bind information to an Act.confidentialityCode according to local sensitivity policy so that those confidentiality codes can then govern its handling across enterprises. Internally to a policy domain, however, local policies guide the access control system on how end users in that policy domain are able to use information tagged with these sensitivity values. |
ETH
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | substance abuse information sensitivity |
Policy
for
handling
alcohol
or
drug-abuse
information,
which
will
be
afforded
heightened
confidentiality.
Information
handling
protocols
based
on
organizational
policies
related
to
alcohol
or
drug-abuse
information
that
is
deemed
sensitive.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
GDIS
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | genetic disease information sensitivity |
Policy
for
handling
genetic
disease
information,
which
will
be
afforded
heightened
confidentiality.
Information
handling
protocols
based
on
organizational
policies
related
to
genetic
disease
information
that
is
deemed
sensitive.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
HIV
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | HIV/AIDS information sensitivity |
Policy
for
handling
HIV
or
AIDS
information,
which
will
be
afforded
heightened
confidentiality.
Information
handling
protocols
based
on
organizational
policies
related
to
HIV
or
AIDS
information
that
is
deemed
sensitive.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
MST
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | military sexual trauma information sensitivity |
Policy for handling information related to sexual assault or repeated, threatening sexual harassment that occurred while the patient was in the military, which is afforded heightened confidentiality.
Access
control
concerns
for
military
sexual
trauma
is
based
on
the
patient
being
subject
to
control
by
a
higher
ranking
military
perpetrator
and/or
censure
by
others
within
the
military
unit.
Due
to
the
relatively
unfettered
access
to
healthcare
information
by
higher
ranking
military
personnel
and
those
who
have
command
over
the
patient,
there
is
a
need
to
sequester
this
information
outside
of
the
typical
controls
on
access
to
military
health
records.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. |
PREGNANT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | pregnancy information sensitivity |
Policy
for
handling
information
about
an
individual's
current
or
past
pregnancy
status,
deemed
sensitive
by
the
individual
or
by
policy,
which
may
be
afforded
heightened
confidentiality.
Usage Note: Information about a patient's current or past pregnancy status may be considered sensitive in circumstances in which that status could result in discrimination or stigmatization. |
SCA
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | sickle cell anemia information sensitivity |
Policy
for
handling
sickle
cell
disease
information,
which
is
afforded
heightened
confidentiality.
Information
handling
protocols
are
based
on
organizational
policies
related
to
sickle
cell
disease
information,
which
is
deemed
sensitive.
Usage Note: If there is a jurisdictional mandate, then the Act valued with this ActCode should be associated with an Act valued with any applicable laws from the ActPrivacyLaw code system. |
SDV
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | sexual assault, abuse, or domestic violence information sensitivity |
Policy for handling sexual assault, abuse, or domestic violence information, which will be afforded heightened confidentiality. Information handling protocols based on organizational policies related to sexual assault, abuse, or domestic violence information that is deemed sensitive.
SDV
code
covers
violence
perpetrated
by
related
and
non-related
persons.
This
code
should
be
specific
to
physical
and
mental
trauma
caused
by
a
related
person
only.
The
access
control
concerns
are
keeping
the
patient
safe
from
the
perpetrator
who
may
have
an
abusive
psychological
control
over
the
patient,
may
be
stalking
the
patient,
or
may
try
to
manipulate
care
givers
into
allowing
the
perpetrator
to
make
contact
with
the
patient.
The
definition
needs
to
be
clarified.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
SEX
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | sexuality and reproductive health information sensitivity |
Policy
for
handling
sexuality
and
reproductive
health
information,
which
will
be
afforded
heightened
confidentiality.
Information
handling
protocols
based
on
organizational
policies
related
to
sexuality
and
reproductive
health
information
that
is
deemed
sensitive.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
SPI
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | specially protected information sensitivity |
Policy
for
handling
information
deemed
specially
protected
by
law
or
policy
including
substance
abuse,
substance
use,
psychiatric,
mental
health,
behavioral
health,
and
cognitive
disorders,
which
is
afforded
heightened
confidentiality.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. |
BH
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | behavioral health information sensitivity |
Policy
for
handling
information
related
to
behavioral
and
emotional
disturbances
affecting
social
adjustment
and
physical
health,
which
is
afforded
heightened
confidentiality.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. |
COGN
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | cognitive disability information sensitivity |
Policy
for
handling
information
related
to
cognitive
disability
disorders
and
conditions
caused
by
these
disorders,
which
are
afforded
heightened
confidentiality.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. Examples may include dementia, traumatic brain injury, attention deficit, hearing and visual disability such as dyslexia and other disorders and related conditions which impair learning and self-sufficiency. However, the cognitive disabilities to which this term may apply versus other behavioral health categories varies by jurisdiction and organizational policy in part due to overlap with other behavioral health conditions. Implementers should constrain to those diagnoses applicable in the domain in which this code is used. |
DVD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | developmental disability information sensitivity |
Policy
for
handling
information
related
to
developmental
disability
disorders
and
conditions
caused
by
these
disorders,
which
is
afforded
heightened
confidentiality.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. A diverse group of chronic conditions that are due to mental or physical impairments impacting activities of daily living, self-care, language acuity, learning, mobility, independent living and economic self-sufficiency. Examples may include Down syndrome and Autism spectrum. However, the developmental disabilities to which this term applies versus other behavioral health categories varies by jurisdiction and organizational policy in part due to overlap with other behavioral health conditions. Implementers should constrain to those diagnoses applicable in the domain in which this code is used. |
EMOTDIS
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | emotional disturbance information sensitivity |
Policy
for
handling
information
related
to
emotional
disturbance
disorders
and
conditions
caused
by
these
disorders,
which
is
afforded
heightened
confidentiality.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. Typical used to characterize behavioral and mental health issues of adolescents where the disorder may be temporarily diagnosed in order to avoid the potential and unnecessary stigmatizing diagnoses of disorder long term. |
MH
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | mental health information sensitivity |
Policy
for
handling
information
related
to
psychological
disorders,
which
is
afforded
heightened
confidentiality.
Mental
health
information
may
be
deemed
specifically
sensitive
and
distinct
from
physical
health,
substance
use
disorders,
and
behavioral
disabilities
and
disorders
in
some
jurisdictions.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. |
PSY
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | psychiatry disorder information sensitivity |
Policy
for
handling
psychiatry
psychiatric
disorder
information,
which
is
afforded
heightened
confidentiality.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
PSYTHPN
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | psychotherapy note information sensitivity |
Policy
for
handling
psychotherapy
note
information,
which
is
afforded
heightened
confidentiality.
Usage Note: In some jurisdiction, disclosure of psychotherapy notes requires patient consent. If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
SUD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | substance use disorder information sensitivity |
Policy
for
handling
information
related
to
alcohol
or
drug
use
disorders
and
conditions
caused
by
these
disorders,
which
is
afforded
heightened
confidentiality.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. |
ETHUD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | alcohol use disorder information sensitivity |
Policy
for
handling
information
related
to
alcohol
use
disorders
and
conditions
caused
by
these
disorders,
which
is
afforded
heightened
confidentiality.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. |
OPIOIDUD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | opioid use disorder information sensitivity |
Policy
for
handling
information
related
to
opioid
use
disorders
and
conditions
caused
by
these
disorders,
which
is
afforded
heightened
confidentiality.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. |
STD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | sexually transmitted disease information sensitivity |
Policy
for
handling
sexually
transmitted
disease
information,
which
will
be
afforded
heightened
confidentiality.
Information
handling
protocols
based
on
organizational
policies
related
to
sexually
transmitted
disease
information
that
is
deemed
sensitive.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
TBOO
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | taboo |
Policy
for
handling
information
not
to
be
initially
disclosed
or
discussed
with
patient
except
by
a
physician
assigned
to
patient
in
this
case.
Information
handling
protocols
based
on
organizational
policies
related
to
sensitive
patient
information
that
must
be
initially
discussed
with
the
patient
by
an
attending
physician
before
being
disclosed
to
the
patient.
Usage
Note:
If
there
is
a
jurisdictional
mandate,
then
use
the
applicable
ActPrivacyLaw
code
system,
and
specify
the
law
rather
than
or
in
addition
to
this
more
generic
code.
Open Issue: This definition conflates a rule and a characteristic, and there may be a similar issue with ts sibling codes. |
VIO
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | violence information sensitivity |
Policy for handling information related to harm by violence, which is afforded heightened confidentiality. Harm by violence is perpetrated by an unrelated person.
Access
control
concerns
for
information
about
mental
or
physical
harm
resulting
from
violence
caused
by
an
unrelated
person
may
include
manipulation
of
care
givers
or
access
to
records
that
enable
the
perpetrator
contact
or
locate
the
patient,
but
the
perpetrator
will
likely
not
have
established
abusive
psychological
control
over
the
patient.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. |
IDS
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | Identifier Sensitivity |
Policy for handling information related to an identifier of an information subject, which will be afforded heightened confidentiality. Usage Note: Such policies may govern the sensitivity of information related to an identifier of an act, such as the identifier of a contract; a role, such as a citizen, a patient, a practitioner, or an organization; or an entity such as a medical device due to potential impact on the privacy, well-being, safety or integrity of an information subject. For example, protection against identity fraud or counterfeit. |
SICKLE
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | sickle cell |
Types
of
sensitivity
policies
that
apply
to
Acts.
Act.confidentialityCode
is
defined
in
the
RIM
as
"constraints
around
appropriate
disclosure
of
information
about
this
Act,
regardless
of
mood."
Usage Note: ActSensitivity codes are used to bind information to an Act.confidentialityCode according to local sensitivity policy so that those confidentiality codes can then govern its handling across enterprises. Internally to a policy domain, however, local policies guide the access control system on how end users in that policy domain are able to use information tagged with these sensitivity values. |
_EntitySensitivityPolicyType
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | EntityInformationSensitivityPolicy |
Types
of
sensitivity
policies
that
may
apply
to
a
sensitive
attribute
on
an
Entity.
Usage Note: EntitySensitivity codes are used to convey a policy that is applicable to sensitive information conveyed by an entity attribute. May be used to bind a Role.confidentialityCode associated with an Entity per organizational policy. Role.confidentialityCode is defined in the RIM as "an indication of the appropriate disclosure of information about this Role with respect to the playing Entity." |
DEMO
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | all demographic information sensitivity |
Policy
for
handling
all
demographic
information
about
an
information
subject,
which
will
be
afforded
heightened
confidentiality.
Policies
may
govern
sensitivity
of
information
related
to
all
demographic
about
an
information
subject,
the
disclosure
of
which
could
impact
the
privacy,
well-being,
or
safety
of
that
subject.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
DOB
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | date of birth information sensitivity |
Policy
for
handling
information
related
to
an
information
subject's
date
of
birth,
which
will
be
afforded
heightened
confidentiality.Policies
may
govern
sensitivity
of
information
related
to
an
information
subject's
date
of
birth,
the
disclosure
of
which
could
impact
the
privacy,
well-being,
or
safety
of
that
subject.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
GENDER
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | gender and sexual orientation information sensitivity |
Policy
for
handling
information
related
to
an
information
subject's
gender
and
sexual
orientation,
which
will
be
afforded
heightened
confidentiality.
Policies
may
govern
sensitivity
of
information
related
to
an
information
subject's
gender
and
sexual
orientation,
the
disclosure
of
which
could
impact
the
privacy,
well-being,
or
safety
of
that
subject.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
LIVARG
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | living arrangement information sensitivity |
Policy
for
handling
information
related
to
an
information
subject's
living
arrangement,
which
will
be
afforded
heightened
confidentiality.
Policies
may
govern
sensitivity
of
information
related
to
an
information
subject's
living
arrangement,
the
disclosure
of
which
could
impact
the
privacy,
well-being,
or
safety
of
that
subject.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
MARST
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | marital status information sensitivity |
Policy
for
handling
information
related
to
an
information
subject's
marital
status,
which
will
be
afforded
heightened
confidentiality.
Policies
may
govern
sensitivity
of
information
related
to
an
information
subject's
marital
status,
the
disclosure
of
which
could
impact
the
privacy,
well-being,
or
safety
of
that
subject.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
PATLOC
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | patient location |
Policy
for
handling
information
related
to
an
individual's
location,
which
is
deemed
sensitive
when
the
disclosure
could
impact
the
privacy,
well-being,
or
safety
of
that
subject,
and
requires
additional
protection.
Usage Note: If there is a jurisdictional, organizational, or individual mandate, then use the applicable ActPrivacyLaw or ActConsentDirective code from the ActCode system to and specify the law in addition to this more generic code. |
RACE
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | race information sensitivity |
Policy
for
handling
information
related
to
an
information
subject's
race,
which
will
be
afforded
heightened
confidentiality.
Policies
may
govern
sensitivity
of
information
related
to
an
information
subject's
race,
the
disclosure
of
which
could
impact
the
privacy,
well-being,
or
safety
of
that
subject.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
REL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | religion information sensitivity |
Policy
for
handling
information
related
to
an
information
subject's
religious
affiliation,
which
will
be
afforded
heightened
confidentiality.
Policies
may
govern
sensitivity
of
information
related
to
an
information
subject's
religion,
the
disclosure
of
which
could
impact
the
privacy,
well-being,
or
safety
of
that
subject.
Usage Notes: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
_RoleInformationSensitivityPolicy
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | RoleInformationSensitivityPolicy |
Types
of
sensitivity
policies
that
apply
to
Roles.
Usage Notes: RoleSensitivity codes are used to bind information to a Role.confidentialityCode per organizational policy. Role.confidentialityCode is defined in the RIM as "an indication of the appropriate disclosure of information about this Role with respect to the playing Entity." |
B
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | business information sensitivity |
Policy
for
handling
trade
secrets
such
as
financial
information
or
intellectual
property,
which
will
be
afforded
heightened
confidentiality.
Description:
Since
the
service
class
can
represent
knowledge
structures
that
may
be
considered
a
trade
or
business
secret,
there
is
sometimes
(though
rarely)
the
need
to
flag
those
items
as
of
business
level
confidentiality.
Usage Notes: No patient related information may ever be of this confidentiality level. If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
EMPL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | employer information sensitivity |
Policy
for
handling
information
related
to
an
employer
which
is
deemed
classified
to
protect
an
employee
who
is
the
information
subject,
and
which
will
be
afforded
heightened
confidentiality.
Description:
Policies
may
govern
sensitivity
of
information
related
to
an
employer,
such
as
law
enforcement
or
national
security,
the
identity
of
which
could
impact
the
privacy,
well-being,
or
safety
of
an
information
subject
who
is
an
employee.
Usage Notes: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
LOCIS
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | location information sensitivity |
Policy
for
handling
information
related
to
the
location
of
the
information
subject,
which
will
be
afforded
heightened
confidentiality.
Description:
Policies
may
govern
sensitivity
of
information
related
to
the
location
of
the
information
subject,
the
disclosure
of
which
could
impact
the
privacy,
well-being,
or
safety
of
that
subject.
Usage Notes: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
SSP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | sensitive service provider information sensitivity |
Policy
for
handling
information
related
to
a
provider
of
sensitive
services,
which
will
be
afforded
heightened
confidentiality.
Description:
Policies
may
govern
sensitivity
of
information
related
to
providers
who
deliver
sensitive
healthcare
services
in
order
to
protect
the
privacy,
well-being,
and
safety
of
the
provider
and
of
patients
receiving
sensitive
services.
Usage Notes: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
ADOL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | adolescent information sensitivity |
Policy
for
handling
information
related
to
an
adolescent,
which
will
be
afforded
heightened
confidentiality
per
applicable
organizational
or
jurisdictional
policy.
An
enterprise
may
have
a
policy
that
requires
that
adolescent
patient
information
be
provided
heightened
confidentiality.
Information
deemed
sensitive
typically
includes
health
information
and
patient
role
information
including
patient
status,
demographics,
next
of
kin,
and
location.
Usage Note: For use within an enterprise in which an adolescent is the information subject. If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
CEL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | celebrity information sensitivity |
Policy
for
handling
information
related
to
a
celebrity
(people
of
public
interest
(VIP),
which
will
be
afforded
heightened
confidentiality.
Celebrities
are
people
of
public
interest
(VIP)
about
whose
information
an
enterprise
may
have
a
policy
that
requires
heightened
confidentiality.
Information
deemed
sensitive
may
include
health
information
and
patient
role
information
including
patient
status,
demographics,
next
of
kin,
and
location.
Usage Note: For use within an enterprise in which the information subject is deemed a celebrity or very important person. If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
VIP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | celebrity information sensitivity |
Policy
for
handling
information
related
to
a
celebrity
(people
of
public
interest
(VIP),
which
will
be
afforded
heightened
confidentiality.
Celebrities
are
people
of
public
interest
(VIP)
about
whose
information
an
enterprise
may
have
a
policy
that
requires
heightened
confidentiality.
Information
deemed
sensitive
may
include
health
information
and
patient
role
information
including
patient
status,
demographics,
next
of
kin,
and
location.
Usage Note: For use within an enterprise in which the information subject is deemed a celebrity or very important person. If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
DIA
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | diagnosis information sensitivity |
Policy
for
handling
information
related
to
a
diagnosis,
health
condition
or
health
problem,
which
will
be
afforded
heightened
confidentiality.
Diagnostic,
health
condition
or
health
problem
related
information
may
be
deemed
sensitive
by
organizational
policy,
and
require
heightened
confidentiality.
Usage Note: For use within an enterprise that provides heightened confidentiality to diagnostic, health condition or health problem related information deemed sensitive. If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
DRGIS
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | drug information sensitivity |
Policy
for
handling
information
related
to
a
drug,
which
will
be
afforded
heightened
confidentiality.
Drug
information
may
be
deemed
sensitive
by
organizational
policy,
and
require
heightened
confidentiality.
Usage Note: For use within an enterprise that provides heightened confidentiality to drug information deemed sensitive. If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
EMP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | employee information sensitivity |
Policy
for
handling
information
related
to
an
employee,
which
will
be
afforded
heightened
confidentiality.
When
a
patient
is
an
employee,
an
enterprise
may
have
a
policy
that
requires
heightened
confidentiality.
Information
deemed
sensitive
typically
includes
health
information
and
patient
role
information
including
patient
status,
demographics,
next
of
kin,
and
location.
Usage Note: Policy for handling information related to an employee, which will be afforded heightened confidentiality. Description: When a patient is an employee, an enterprise may have a policy that requires heightened confidentiality. Information deemed sensitive typically includes health information and patient role information including patient status, demographics, next of kin, and location. |
PDS
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | patient default information sensitivity |
Policy
for
specially
protecting
information
reported
by
or
about
a
patient,
which
is
deemed
sensitive
within
the
enterprise
(i.e.,
by
default
regardless
of
whether
the
patient
requested
that
the
information
be
deemed
sensitive
for
another
reason.)
For
example
information
reported
by
the
patient
about
another
person,
e.g.,
a
family
member,
may
be
deemed
sensitive
by
default.
Organizational
policy
may
allow
the
sensitivity
tag
to
be
cleared
on
patient's
request.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law in addition to this more generic code. For example, VA deems employee information sensitive by default. Information about a patient who is being stalked or a victim of abuse or violence may be deemed sensitive by default per a provider organization's policies. |
PHY
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | physician requested information sensitivity |
Policy
for
handling
information
about
a
patient,
which
a
physician
or
other
licensed
healthcare
provider
deems
sensitive.
Once
tagged
by
the
provider,
this
may
trigger
alerts
for
follow
up
actions
according
to
organizational
policy
or
jurisdictional
law.
Usage Note: For use within an enterprise that provides heightened confidentiality to certain types of information designated by a physician as sensitive. If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. Use cases in which this code could be used are, e.g., in systems that lack the ability to automatically detect sensitive information and must rely on manual tagging; a system that lacks an applicable sensitivity tag, or for ad hoc situations where criticality of the situation requires that the tagging be done immediately by the provider before coding or transcription of consult notes can be completed, e.g., upon detection of a patient with suicidal tendencies or potential for violence. |
PRS
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | patient requested information sensitivity |
Policy
for
specially
protecting
information
reported
by
or
about
a
patient,
which
the
patient
deems
sensitive,
and
the
patient
requests
that
collection,
access,
use,
or
disclosure
of
that
information
be
restricted.
For
example,
a
minor
patient
may
request
that
information
about
reproductive
health
not
be
disclosed
to
the
patient's
family
or
to
particular
providers
and
payers.
Usage Note: If there is a jurisdictional mandate, then use the applicable ActPrivacyLaw code system, and specify the law rather than or in addition to this more generic code. |
COMPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | compartment |
This is the healthcare analog to the US Intelligence Community's concept of a Special Access Program. Compartment codes may be used in as a field value in an initiator's clearance to indicate permission to access and use an IT Resource with a security label having the same compartment value in security category label field. Map: Aligns with ISO 2382-8 definition of Compartment - "A division of data into isolated blocks with separate security controls for the purpose of reducing risk." |
ACOCOMPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | accountable care organization compartment |
A group of health care entities, which may include health care providers, care givers, hospitals, facilities, health plans, and other health care constituents who coordinate care for reimbursement based on quality metrics for improving outcomes and lowering costs, and may be authorized to access the consumer's health information because of membership in that group. Security Compartment Labels assigned to a consumer's information use in accountable care workflows should be met or exceeded by the Security Compartment attribute claimed by a participant in a an accountable care workflow who is requesting access to that information |
CDSSCOMPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | CDS system compartment |
This compartment code may be used as a field value in an initiator's clearance to indicate permission for its Clinical Decision Support system (CDSS) to access and use an IT Resource with a security label having the same compartment value in the security category label field. This code permits a CDS system to algorithmically process information with this compartment tag for the purpose of alerting an unauthorized end user that masked information is needed to address an emergency or a patient safety issue, such as a contraindicated medication. The alert would advise the end user to "break the glass", to access the masked information in an accountable manner, or to ask the patient about possibly masked information.
For
example,
releasing
a
list
of
sensitive
medications
with
this
compartment
tag
means
that
while
the
CDS
system
is
permitted
to
use
this
list
in
its
contraindication
analysis,
this
sensitive
information
should
not
be
shared
directly
with
unauthorized
end-users
or
end-user-facing
Apps.
Based
on
the
results
of
the
CDS
system
analysis
(e.g.,
warnings
about
prescriptions)
the
end-user
(e.g.,
a
clinician)
may
still
have
the
ability
to
access
to
the
sensitive
information
by
invoking
"break-the-glass
protocol".
Usage Note: A security label with the CDS system compartment may be used in conjunction with other security labels, e.g., a label authorizing an end user with adequate clearance to access the same CDS system compartment tagged information. For example, a patient may restrict sharing sensitive information with most care team members except in an emergency or to prevent an adverse event, and may consent to sharing with their sensitive service care team providers, e.g., for mental health or substance abuse. |
CTCOMPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | care team compartment |
Care coordination across participants in a care plan requires sharing of a healthcare consumer's information specific to that workflow. A care team member should only have access to that information while participating in that workflow or for other authorized uses. Security Compartment Labels assigned to a consumer's information use in care coordination workflows should be met or exceeded by the Security Compartment attribute claimed by a participant in a care team member workflow who is requesting access to that information |
FMCOMPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | financial management compartment |
Financial management department members who have access to healthcare consumer information as part of a patient account, billing and claims workflows. Security Compartment Labels assigned to consumer information used in these workflows should be met or exceeded by the Security Compartment attribute claimed by a participant in a financial management workflow who is requesting access to that information. |
HRCOMPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | human resource compartment |
A security category label field value, which indicates that access and use of an IT resource is restricted to members of human resources department or workflow. |
LRCOMPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | legitimate relationship compartment |
Providers and care givers who have an established relationship per criteria determined by policy are considered to have an established care provision relations with a healthcare consumer, and may be authorized to access the consumer's health information because of that relationship. Providers and care givers should only have access to that information while participating in legitimate relationship workflows or for other authorized uses. Security Compartment Labels assigned to a consumer's information use in legitimate relationship workflows should be met or exceeded by the Security Compartment attribute claimed by a participant in a legitimate relationship workflow who is requesting access to that information. |
PACOMPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | patient administration compartment |
Patient administration members who have access to healthcare consumer information as part of a patient administration workflows. Security Compartment Labels assigned to consumer information used in these workflows should be met or exceeded by the Security Compartment attribute claimed by a participant in a patient administration workflow who is requesting access to that information. |
RESCOMPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | research project compartment |
A security category label field value, which indicates that access and use of an IT resource is restricted to members of a research project. |
RMGTCOMPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | records management compartment |
A security category label field value, which indicates that access and use of an IT resource is restricted to members of records management department or workflow. |
_SECALTINTOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | alteration integrity |
Abstract security metadata observation values used to indicate mechanism used for authorized alteration of an IT resource (data, information object, service, or system capability) |
ABSTRED
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | abstracted |
Security metadata observation values used to indicate the use of a more abstract version of the content, e.g., replacing exact value of an age or date field with a range, or remove the left digits of a credit card number or SSN. |
AGGRED
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | aggregated |
Security metadata observation values used to indicate the use of an algorithmic combination of actual values with the result of an aggregate function, e.g., average, sum, or count in order to limit disclosure of an IT resource (data, information object, service, or system capability) to the minimum necessary. |
ANONYED
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | anonymized |
Security metadata observation value conveying the alteration integrity of an IT resource (data, information object, service, or system capability) by used to indicate the mechanism by which software systems can strip portions of the resource that could allow the identification of the source of the information or the information subject. No key to relink the data is retained. |
MAPPED
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | mapped |
Security
metadata
observation
value
used
to
indicate
that
the
IT
resource
semantic
content
has
been
transformed
from
one
encoding
to
another.
Usage Note: "MAP" code does not indicate the semantic fidelity of the transformed content. To indicate semantic fidelity for maps of HL7 to other code systems, this security alteration integrity observation may be further specified using an Act valued with Value Set: MapRelationship (2.16.840.1.113883.1.11.11052). Semantic fidelity of the mapped IT Resource may also be indicated using a SecurityIntegrityConfidenceObservation. |
MASKED
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | masked |
Security
metadata
observation
value
conveying
the
alteration
integrity
of
an
IT
resource
(data,
information
object,
service,
or
system
capability)
by
indicating
the
mechanism
by
which
software
systems
can
make
data
unintelligible
(that
is,
as
unreadable
and
unusable
by
algorithmically
transforming
plaintext
into
ciphertext)
such
that
it
can
only
be
accessed
or
used
by
authorized
users.
An
authorized
user
may
be
provided
a
key
to
decrypt
per
license
or
"shared
secret".
Usage Note: "MASKED" may be used, per applicable policy, as a flag to indicate to a user or receiver that some portion of an IT resource has been further encrypted, and may be accessed only by an authorized user or receiver to which a decryption key is provided. |
PSEUDED
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | pseudonymized |
Security
metadata
observation
value
conveying
the
alteration
integrity
of
an
IT
resource
(data,
information
object,
service,
or
system
capability),
by
indicating
the
mechanism
by
which
software
systems
can
strip
portions
of
the
resource
that
could
allow
the
identification
of
the
source
of
the
information
or
the
information
subject.
Custodian
may
retain
a
key
to
relink
data
necessary
to
reidentify
the
information
subject.
Rationale: Personal data which has been processed to make it impossible to know whose data it is. Used particularly for secondary use of health data. In some cases, it may be possible for authorized individuals to restore the identity of the individual, e.g.,for public health case management. Based on ISO/TS 25237:2008 Health informatics—Pseudonymization |
REDACTED
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | redacted |
Security
metadata
observation
value
used
to
indicate
the
mechanism
by
which
software
systems
can
filter
an
IT
resource
(data,
information
object,
service,
or
system
capability)
to
remove
any
portion
of
the
resource
that
is
not
authorized
to
be
access,
used,
or
disclosed.
Usage Note: "REDACTED" may be used, per applicable policy, as a flag to indicate to a user or receiver that some portion of an IT resource has filtered and not included in the content accessed or received. |
SUBSETTED
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | subsetted |
Metadata
observation
used
to
indicate
that
some
information
has
been
removed
from
the
source
object
when
the
view
this
object
contains
was
constructed
because
of
configuration
options
when
the
view
was
created.
The
content
may
not
be
suitable
for
use
as
the
basis
of
a
record
update
Usage Note: This is not suitable to be used when information is removed for security reasons - see the code REDACTED for this use. |
SYNTAC
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | syntactic transform |
Security
metadata
observation
value
used
to
indicate
that
the
IT
resource
syntax
has
been
transformed
from
one
syntactical
representation
to
another.
Usage Note: "SYNTAC" code does not indicate the syntactical correctness of the syntactically transformed IT resource. |
TRSLT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | translated |
Security
metadata
observation
value
used
to
indicate
that
the
IT
resource
has
been
translated
from
one
human
language
to
another.
Usage Note: "TRSLT" does not indicate the fidelity of the translation or the languages translated. The fidelity of the IT Resource translation may be indicated using a SecurityIntegrityConfidenceObservation. To indicate languages, use the Value Set:HumanLanguage (2.16.840.1.113883.1.11.11526) |
VERSIONED
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | versioned |
Security
metadata
observation
value
conveying
the
alteration
integrity
of
an
IT
resource
(data,
information
object,
service,
or
system
capability)
which
indicates
that
the
resource
only
retains
versions
of
an
IT
resource
for
access
and
use
per
applicable
policy
Usage Note: When this code is used, expectation is that the system has removed historical versions of the data that falls outside the time period deemed to be the effective time of the applicable version. |
_SECDATINTOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | data integrity |
Abstract
security
observation
values
used
to
indicate
data
integrity
metadata.
Examples: Codes conveying the mechanism used to preserve the accuracy and consistency of an IT resource such as a digital signature and a cryptographic hash function. |
CRYTOHASH
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | cryptographic hash function |
Security
metadata
observation
value
used
to
indicate
the
mechanism
by
which
software
systems
can
establish
that
data
was
not
modified
in
transit.
Rationale:
This
definition
is
intended
to
align
with
the
ISO
22600-2
3.3.19
definition
of
cryptographic
checkvalue:
Information
which
is
derived
by
performing
a
cryptographic
transformation
(see
cryptography)
on
the
data
unit.
The
derivation
of
the
checkvalue
may
be
performed
in
one
or
more
steps
and
is
a
result
of
a
mathematical
function
of
the
key
and
a
data
unit.
It
is
usually
used
to
check
the
integrity
of
a
data
unit.
Examples:
|
DIGSIG
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | digital signature |
Security
metadata
observation
value
used
to
indicate
the
mechanism
by
which
software
systems
use
digital
signature
to
establish
that
data
has
not
been
modified.
Rationale: This definition is intended to align with the ISO 22600-2 3.3.26 definition of digital signature: Data appended to, or a cryptographic transformation (see cryptography) of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g., by the recipient. |
_SECINTCONOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | integrity confidence |
Abstract
security
observation
value
used
to
indicate
integrity
confidence
metadata.
Examples: Codes conveying the level of reliability and trustworthiness of an IT resource. |
HRELIABLE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | highly reliable |
Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be very high. |
RELIABLE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | reliable |
Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be adequate. |
UNCERTREL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | uncertain reliability |
Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be uncertain. |
UNRELIABLE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | unreliable |
Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be inadequate. |
_SECINTPRVOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | provenance |
Abstract
security
metadata
observation
value
used
to
indicate
the
provenance
of
an
IT
resource
(data,
information
object,
service,
or
system
capability).
Examples: Codes conveying the provenance metadata about the entity reporting an IT resource. |
_SECINTPRVABOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | provenance asserted by |
Abstract
security
provenance
metadata
observation
value
used
to
indicate
the
entity
that
asserted
an
IT
resource
(data,
information
object,
service,
or
system
capability).
Examples: Codes conveying the provenance metadata about the entity asserting the resource. |
CLINAST
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | clinician asserted |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a clinician. |
DEVAST
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | device asserted |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a device. |
HCPAST
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | healthcare professional asserted |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a healthcare professional. |
PACQAST
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | patient acquaintance asserted |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a patient acquaintance. |
PATAST
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | patient asserted |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a patient. |
PAYAST
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | payer asserted |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a payer. |
PROAST
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | professional asserted |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a professional. |
SDMAST
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | substitute decision maker asserted |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a substitute decision maker. |
_SECINTPRVRBOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | provenance reported by |
Abstract
security
provenance
metadata
observation
value
used
to
indicate
the
entity
that
reported
the
resource
(data,
information
object,
service,
or
system
capability).
Examples: Codes conveying the provenance metadata about the entity reporting an IT resource. |
CLINRPT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | clinician reported |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a clinician. |
DEVRPT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | device reported |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a device. |
HCPRPT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | healthcare professional reported |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a healthcare professional. |
PACQRPT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | patient acquaintance reported |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a patient acquaintance. |
PATRPT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | patient reported |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a patient. |
PAYRPT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | payer reported |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a payer. |
PRORPT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | professional reported |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a professional. |
SDMRPT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | substitute decision maker reported |
Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a substitute decision maker. |
_SECINTSTOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | integrity status |
Abstract
security
observation
values
used
to
indicate
integrity
status
metadata.
Examples: Codes, such as those in the HL7 DocumentClassification code system conveying the workflow status of resource as authenticated, legally authenticated, and in progress. |
SecurityPolicy
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | security policy |
Types
of
security
policies
that
further
specify
the
ActClassPolicy
value
set.
Examples:
|
AUTHPOL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | authorization policy |
Authorisation policies are essentially security policies related to access-control and specify what activities a subject is permitted or forbidden to do, to a set of target objects. They are designed to protect target objects so are interpreted by access control agents or the run-time systems at the target system. A positive authorisation policy defines the actions that a subject is permitted to perform on a target. A negative authorisation policy specifies the actions that a subject is forbidden to perform on a target. Positive authorisation policies may also include filters to transform the parameters associated with their actions. (Based on PONDERS) |
ACCESSCONSCHEME
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | access control scheme |
An
access
control
policy
specific
to
the
type
of
access
control
scheme,
which
is
used
to
enforce
one
or
more
authorization
policies.
Usage Note: Access control schemes are the type of access control policy, which is comprised of access control policy rules concerning the provision of the access control service. There are two categories of access control policies, rule-based and identity-based, which are identified in CCITT Rec. X.800 aka ISO 7498-2. Rule-based access control policies are intended to apply to all access requests by any initiator on any target in a security domain. Identity-based access control policies are based on rules specific to an individual initiator, a group of initiators, entities acting on behalf of initiators, or originators acting in a specific role. Context can modify rule-based or identity-based access control policies. Context rules may define the entire policy in effect. Real systems will usually employ a combination of these policy types; if a rule-based policy is used, then an identity-based policy is usually in effect also.
An
access
control
scheme
may
be
based
on
access
control
lists,
capabilities,
labels,
and
context
or
a
combination
of
these.
An
access
control
scheme
is
a
component
of
an
access
control
mechanism
or
"service")
along
with
the
supporting
mechanisms
required
by
that
scheme
to
provide
access
control
decision
information
(ADI)
supplied
by
the
scheme
to
the
access
decision
facility
(ADF
also
known
as
a
PDP).
(Based
on
ISO/IEC
10181-3:1996)
Examples:
|
DELEPOL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | delegation policy |
Delegation policies specify which actions subjects are allowed to delegate to others. A delegation policy thus specifies an authorisation to delegate. Subjects must already possess the access rights to be delegated. Delegation policies are aimed at subjects delegating rights to servers or third parties to perform actions on their behalf and are not meant to be the means by which security administrators would assign rights to subjects. A negative delegation policy identifies what delegations are forbidden. A Delegation policy specifies the authorisation policy from which delegated rights are derived, the grantors, which are the entities which can delegate these access rights, and the grantees, which are the entities to which the access rights can be delegated. There are two types of delegation policy, positive and negative. (Based on PONDERS) |
ObligationPolicy
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | obligation policy |
Conveys
the
mandated
workflow
action
that
an
information
custodian,
receiver,
or
user
must
perform.
Usage Notes: Per ISO 22600-2, ObligationPolicy instances 'are event-triggered and define actions to be performed by manager agent'. Per HL7 Composite Security and Privacy Domain Analysis Model: This value set refers to the action required to receive the permission specified in the privacy rule. Per OASIS XACML, an obligation is an operation specified in a policy or policy that is performed in conjunction with the enforcement of an access control decision. |
ANONY
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | anonymize |
Custodian system must remove any information that could result in identifying the information subject. |
AOD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | accounting of disclosure |
Custodian system must make available to an information subject upon request an accounting of certain disclosures of the individual’s protected health information over a period of time. Policy may dictate that the accounting include information about the information disclosed, the date of disclosure, the identification of the receiver, the purpose of the disclosure, the time in which the disclosing entity must provide a response and the time period for which accountings of disclosure can be requested. |
AUDIT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | audit |
Custodian system must monitor systems to ensure that all users are authorized to operate on information objects. |
AUDTR
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | audit trail |
Custodian system must monitor and maintain retrievable log for each user and operation on information. |
CPLYPOL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | comply with policy |
Custodian
security
system
must
retrieve,
evaluate,
and
comply
with
applicable
policies
associated
with
the
target
information.
Usage Note: CPLYPOL may be used as a security label code to inform senders and receivers of the tagged information to comply with applicable policy without specifying the specific policy type(s). |
CPLYCC
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | comply with confidentiality code |
Custodian
security
system
must
retrieve,
evaluate,
and
comply
with
the
information
handling
directions
of
the
Confidentiality
Code
associated
with
an
information
target.
Usage Note: CPLYCC may be used as a security label code to inform senders and receivers of information tagged with a Confidentiality Code to comply with applicable level of protection required by the assigned confidentiality code. |
CPLYCD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | comply with consent directive |
Custodian
security
system
must
retrieve,
evaluate,
and
comply
with
applicable
information
subject
consent
directives.
Usage
Note:
CPLYCD
may
be
used
as
a
security
label
code
to
inform
senders
and
receivers
of
information
tagged
with
an
|
CPLYCUI
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | comply with controlled unclassified information policy |
Custodian
security
system
must
retrieve,
evaluate,
and
comply
with
applicable
Controlled
Unclassified
Information
(CUI)
policies
associated
with
the
target
information.
Usage Note: In the US, CPLYCUI may be used as a security label code to inform recipients of information designated by a US Federal Agency as Controlled Unclassified Information (CUI) to comply with the applicable laws, regulations, executive orders, and other guidances, such as included in DURSAs, to persist, mark, and enforce required CUI controls Background: In accordance with US 32 CFR Part 2002 and US Executive Order 13556 Controlled Unclassified Information, US Federal Agencies and their contractors are charged with classifying and marking certain information they create as Controlled Unclassified Information (CUI).
The
following
definitions,
which
are
provided
for
context,
are
based
on
terms
defined
by
the
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html
Once designated as CUI, US Federal Agencies and their contractors must assign CUI marks as prescribed by the National Archives and Records Administration (NARA) CUI Registry, and display marks as prescribed by the CUI Marking Handbook. CUI markings must be displayed on hard copy, on containers, electronic media, and to end users for IT systems.
When
HL7
content
is
designated
as
CUI,
these
computable
markings
can
be
interoperably
conveyed
using
HL7
security
label
CUI
tags,
and
may
be
included
in
HL7
text
and
narrative
elements
as
human
readable
markings.
Impact
of
CUI
CUI Custodians must enforce CUI security controls per applicable CUI policies. Federal agencies and their contractors must adhere to FISMA and NIST SP 800-53 security controls. Custodians, who are not Federal agencies or agency contractors, and are receivers of CUI, must adhere to NIST SP 800-171 security controls and those dictated by the Authorities indicated by the assigned CUI markings. For most participants in US healthcare information exchange, including Federal Agencies and their contractors, additional controls are required by HIPAA Security standards for health information US 42 USC 1320d-2(d)(2) https://www.govinfo.gov/content/pkg/USCODE-2016-title42/pdf/USCODE-2016-title42-chap7-subchapXI-partC-sec1320d-2.pdf Federal Agencies and their contractors may be the CUI classifier of original CUI content; or a CUI derivative classifier, which reclassifies CUI content that has been aggregated with other CUI or Unclassified Uncontrolled Information (U) or dissembled from a larger CUI content; or declassifiers, depending on the designating agency's policies.
Applicable
CUI
policies
include
the
following
and
any
future
applicable
updates
to
policies
or
laws
related
to
CUI:
|
CPLYJPP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | comply with jurisdictional privacy policy |
Custodian
security
system
must
retrieve,
evaluate,
and
comply
with
applicable
jurisdictional
privacy
policies
associated
with
the
target
information.
Usage
Note:
CPLYJPP
may
be
used
as
a
security
label
code
to
inform
senders
and
receivers
of
information
tagged
with
an
|
CPLYJSP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | comply with jurisdictional security policy |
Custodian
security
system
must
retrieve,
evaluate,
and
comply
with
applicable
jurisdictional
security
policies
associated
with
the
target
information.
Usage
Note:
CPLYJSP
may
be
used
as
a
security
label
code
to
inform
senders
and
receivers
of
information
tagged
with
an
|
CPLYOPP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | comply with organizational privacy policy |
Custodian
security
system
must
retrieve,
evaluate,
and
comply
with
applicable
organizational
privacy
policies
associated
with
the
target
information.
Usage
Note:
CPLYOPP
may
be
used
as
a
security
label
code
to
inform
senders
and
receivers
of
information
tagged
with
an
|
CPLYOSP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | comply with organizational security policy |
Custodian
security
system
must
retrieve,
evaluate,
and
comply
with
the
organizational
security
policies
associated
with
the
target
information.
Usage
Note:
CPLYOSP
may
be
used
as
a
security
label
code
to
inform
senders
and
receivers
of
information
tagged
with
an
|
DECLASSIFYLABEL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | declassify security label |
Custodian security system must declassify information assigned security labels by instantiating a new version of the classified information so as to break the binding of the classifying security label when assigning a new security label that marks the information as unclassified in accordance with applicable jurisdictional privacy policies associated with the target information. The system must retain an immutable record of the previous assignment and binding. |
DEID
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | deidentify |
Custodian system must strip information of data that would allow the identification of the source of the information or the information subject. |
DELAU
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | delete after use |
Custodian system must remove target information from access after use. |
DOWNGRDLABEL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | downgrade security label |
Custodian security system must downgrade information assigned security labels by instantiating a new version of the classified information so as to break the binding of the classifying security label when assigning a new security label that marks the information as classified at a less protected level in accordance with applicable jurisdictional privacy policies associated with the target information. The system must retain an immutable record of the previous assignment and binding. |
DRIVLABEL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | derive security label |
Custodian security system must assign and bind security labels derived from compilations of information by aggregation or disaggregation in order to classify information compiled in the information systems under its control for collection, access, use and disclosure in accordance with applicable jurisdictional privacy policies associated with the target information. The system must retain an immutable record of the previous assignment and binding. |
ENCRYPT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | encrypt |
Custodian
system
must
render
information
unreadable
by
algorithmically
transforming
plaintext
into
ciphertext.
Usage Notes: A mathematical transposition of a file or data stream so that it cannot be deciphered at the receiving end without the proper key. Encryption is a security feature that assures that only the parties who are supposed to be participating in a videoconference or data transfer are able to do so. It can include a password, public and private keys, or a complex combination of all. (Per Infoway.) |
ENCRYPTR
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | encrypt at rest |
Custodian system must render information unreadable and unusable by algorithmically transforming plaintext into ciphertext when "at rest" or in storage. |
ENCRYPTT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | encrypt in transit |
Custodian system must render information unreadable and unusable by algorithmically transforming plaintext into ciphertext while "in transit" or being transported by any means. |
ENCRYPTU
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | encrypt in use |
Custodian system must render information unreadable and unusable by algorithmically transforming plaintext into ciphertext while in use such that operations permitted on the target information are limited by the license granted to the end user. |
HUAPRV
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | human approval |
Custodian system must require human review and approval for permission requested. |
LABEL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | assign security label |
Custodian
security
system
must
assign
and
bind
security
labels
in
order
to
classify
information
created
in
the
information
systems
under
its
control
for
collection,
access,
use
and
disclosure
in
accordance
with
applicable
jurisdictional
privacy
policies
associated
with
the
target
information.
The
system
must
retain
an
immutable
record
of
the
assignment
and
binding.
Usage Note: In security systems, security policy label assignments do not change, they may supersede prior assignments, and such reassignments are always tracked for auditing and other purposes. |
MASK
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | mask |
Custodian system must render information unreadable and unusable by algorithmically transforming plaintext into ciphertext. User may be provided a key to decrypt per license or "shared secret". |
MINEC
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | minimum necessary |
Custodian
must
limit
access
and
disclosure
to
the
minimum
information
required
to
support
an
authorized
user's
purpose
of
use.
Usage Note: Limiting the information available for access and disclosure to that an authorized user or receiver "needs to know" in order to perform permitted workflow or purpose of use. |
PERSISTLABEL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | persist security label |
Custodian security system must persist the binding of security labels to classify information received or imported by information systems under its control for collection, access, use and disclosure in accordance with applicable jurisdictional privacy policies associated with the target information. The system must retain an immutable record of the assignment and binding. |
PRIVMARK
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | privacy mark |
Custodian must create and/or maintain human readable security label tags as required by policy. Map: Aligns with ISO 22600-3 Section A.3.4.3 description of privacy mark: "If present, the privacy-mark is not used for access control. The content of the privacy-mark may be defined by the security policy in force (identified by the security-policy-identifier) which may define a list of values to be used. Alternately, the value may be determined by the originator of the security-label." |
CUIMark
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | CUI Mark |
An
originator
must
mark,
persist,
display,
and
convey
computable
and
renderable
Controlled
Unclassified
Information
(CUI)
marks
as
required
by
policy.
A
recipient
must
consume,
persist,
display,
and
reconvey
CUI
marks
on
information
received
based
on
agreements
with
the
originator..
Examples:
Usage Note: In accordance with US 32 CFR Part 2002 and US Executive Order 13556 Controlled Unclassified Information, US Federal Agencies and their contractors are charged with classifying and marking certain information they create as Controlled Unclassified Information (CUI).
The
following
definitions,
which
are
provided
for
context,
are
based
on
terms
defined
by
the
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html
Once designated as CUI, US Federal Agencies and their contractors must assign CUI marks as prescribed by the National Archives and Records Administration (NARA) CUI Registry, and display marks as prescribed by the CUI Marking Handbook. CUI markings must be displayed on hard copy, on containers, electronic media, and to end users for IT systems.
When
HL7
content
is
designated
as
CUI,
these
computable
markings
can
be
interoperably
conveyed
using
HL7
security
label
CUI
tags,
and
may
be
included
in
HL7
text
and
narrative
elements
as
human
readable
markings.
Impact
of
CUI
CUI Custodians must enforce CUI security controls per applicable CUI policies. Federal agencies and their contractors must adhere to FISMA and NIST SP 800-53 security controls. Custodians, who are not Federal agencies or agency contractors, and are receivers of CUI, must adhere to NIST SP 800-171 security controls and those dictated by the Authorities indicated by the assigned CUI markings. For most participants in US healthcare information exchange, including Federal Agencies and their contractors, additional controls are required by HIPAA Security standards for health information US 42 USC 1320d-2(d)(2) https://www.govinfo.gov/content/pkg/USCODE-2016-title42/pdf/USCODE-2016-title42-chap7-subchapXI-partC-sec1320d-2.pdf Federal Agencies and their contractors may be the CUI classifier of original CUI content; or a CUI derivative classifier, which reclassifies CUI content that has been aggregated with other CUI or Unclassified Uncontrolled Information (U) or dissembled from a larger CUI content; or declassifiers, depending on the designating agency's policies.
Applicable
CUI
policies
include
the
following
and
any
future
applicable
updates
to
policies
or
laws
related
to
CUI:
|
PSEUD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | pseudonymize |
Custodian system must strip information of data that would allow the identification of the source of the information or the information subject. Custodian may retain a key to relink data necessary to reidentify the information subject. |
REDACT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | redact |
Custodian system must remove information, which is not authorized to be access, used, or disclosed from records made available to otherwise authorized users. |
UPGRDLABEL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | upgrade security label |
Custodian security system must declassify information assigned security labels by instantiating a new version of the classified information so as to break the binding of the classifying security label when assigning a new security label that marks the information as classified at a more protected level in accordance with applicable jurisdictional privacy policies associated with the target information. The system must retain an immutable record of the previous assignment and binding. |
PROCESSINLINELABEL
![]() | http://terminology.hl7.org/CodeSystem/v3-ActCode | process inline security label | Custodian security system must take note that the data object contains inline security labels and process them. |
PrivacyMark
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | privacy mark |
An abstract code for human readable marks indicating, e.g., the level of confidentiality protection, an authorized compartment, the integrity, or the handling instruction required by applicable policy. Such markings must be displayed as directed by applicable policy on electronically rendered information content and any electronic transmittal envelope or container; or on hardcopy information and any physical transmittal envelope or container.
Examples
of
protocols
for
marking
displays
on
electronic
or
hardcopy
rendered
content:
Across
the
top
or
"banner"
of
each
page
;
as
a
watermark
placed
diagonally
cross
each
page;
at
the
bottom
or
"footer"
of
each
page;
and
may
be
displayed
at
the
beginning
of
any
portion
within
the
content
that
required
markings
different
than
other
portions
of
the
content.
The
banner
or
top
of
page
marking
typically
acts
as
a
"high
watermark"
by
including
all
of
the
markings
made
on
any
marked
portions
within
the
entirety
of
the
information
content.
Usage
Note:
A
"Privacy
Mark"
is
a
Security
Control
Observation
(SECCONOBS)
named
tag
set
as
specified
by
the
HL7
Privacy
and
Security
Classification
System
(HCS).
A
Privacy
Mark
Named
Tag
Set
is
valued
with
a
Privacy
Mark
leaf
code
"tag",
which
is
a
member
of
the
Security
Control
Observation
Value
Foundational
standard
definitions:
ISO
22600-3
Section
A.3.4.3
-
If
present,
the
privacy-mark
is
not
used
for
access
control.
The
content
of
the
privacy-mark
may
be
defined
by
the
security
policy
in
force
(identified
by
the
security-policy-identifier)
which
may
define
a
list
of
values
to
be
used.
Alternately,
the
value
may
be
determined
by
the
originator
of
the
security-label.
IEEE
Security
Glossary
Compendium
93-
CESG
Memorandum
No.1
Issue
1.2
Oct
1992
-
Human
readable
word
or
phrase
acting
as
an
indicator
of
all
or
part
of
the
security
constraints
that
apply
to
a
document
so
marked.
NOTE:
A
machine
readable
representation
of
a
marking.
Comment: While policies requiring creators, processors, custodians, senders or recipients apply, enforce, and persist applicable Privacy Marks may be dictated by a jurisdiction, organization or personal privacy, security, or integrity policy, those required to comply may be governed under different policies, so compliance may need to be enforced through trust contracts. For example, information content marked with GDPR related policies may require adherence by processors or recipients outside of the European Union. For this reason, this code system is likely to evolve with the inclusion of multiple policy domains needing to communicate encoded policies in a standard, interoperable manner. |
ControlledUnclassifiedInformation
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | ControlledUnclassifiedInformation |
Information
the
US
Government
creates
or
possesses,
or
that
an
entity
creates
or
possesses
for
or
on
behalf
of
the
Government,
that
a
law,
regulation,
or
Government-wide
policy
requires
or
permits
an
agency
to
handle
using
safeguarding
or
dissemination
controls.
However,
CUI
does
not
include
classified
information
(see
definition
above)
or
information
a
non-executive
branch
entity
possesses
and
maintains
in
its
own
systems
that
did
not
come
from,
or
was
not
created
or
possessed
by
or
for,
an
executive
branch
agency
or
an
entity
acting
for
an
agency.
Law,
regulation,
or
Government-wide
policy
may
require
or
permit
safeguarding
or
dissemination
controls
in
three
ways:
Requiring
or
permitting
agencies
to
control
or
protect
the
information
but
providing
no
specific
controls,
which
makes
the
information
CUI
Basic;
requiring
or
permitting
agencies
to
control
or
protect
the
information
and
providing
specific
controls
for
doing
so,
which
makes
the
information
CUI
Specified;
or
requiring
or
permitting
agencies
to
control
the
information
and
specifying
only
some
of
those
controls,
which
makes
the
information
CUI
Specified,
but
with
CUI
Basic
controls
where
the
authority
does
not
specify.
Based
on
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html
.
Usage Note: Mandatory control marking, which must be displayed on the top portion of each rendered or printed page containing controlled information. Should be displayed at the bottom of each rendered or printed page containing controlled information. Must be displayed on each portion of controlled information at the portion level if portions are uncontrolled unclassified information. Based on CUI Marking Handbook https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf. For definitions of key terms see CUI Glossary https://www.archives.gov/cui/registry/cui-glossary.html. |
CONTROLLED
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | CONTROLLED |
A
displayed
mark,
required
to
be
rendered
as
"CONTROLLED",
indicating
that
the
electronic
or
hardcopy
information
is
protected
at
the
level
of
the
subset
of
CUI
for
which
the
authorizing
law,
regulation,
or
Government-wide
policy
does
not
set
out
specific
handling
or
dissemination
controls.
Agencies
handle
CUI
Basic
according
to
the
uniform
set
of
controls
set
forth
in
this
part
and
the
CUI
Registry.
CUI
Basic
differs
from
CUI
Specified
(see
definition
for
CUI
Specified),
and
CUI
Basic
controls
apply
whenever
CUI
Specified
ones
do
not
cover
the
involved
CUI.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage Note: Mandatory control marking, which must be displayed on the top portion of each rendered or printed page containing controlled information. Should be displayed at the bottom of each rendered or printed page containing controlled information. Must be displayed on each portion of controlled information at the portion level if portions are uncontrolled unclassified information. Based on CUI Marking Handbook https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf. |
CUI
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | CUI |
A
displayed
mark,
required
to
be
rendered
as
"CUI",
indicating
that
the
electronic
or
hardcopy
information
is
protected
at
the
level
of
the
subset
of
CUI
for
which
the
authorizing
law,
regulation,
or
Government-wide
policy
does
not
set
out
specific
handling
or
dissemination
controls.
Agencies
handle
CUI
Basic
according
to
the
uniform
set
of
controls
set
forth
in
this
part
and
the
CUI
Registry.
CUI
Basic
differs
from
CUI
Specified
(see
definition
for
CUI
Specified),
and
CUI
Basic
controls
apply
whenever
CUI
Specified
ones
do
not
cover
the
involved
CUI.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage Note: Mandatory control marking, which must be displayed on the top portion of each rendered or printed page containing controlled information. Should be displayed at the bottom of each rendered or printed page containing controlled information. Must be displayed on each portion of controlled information at the portion level if portions are uncontrolled unclassified information. Based on CUI Marking Handbook https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf. |
CUIHLTH
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | CUI//HLTH |
A
displayed
mark,
required
to
be
rendered
as
"CUI//HLTH",
indicating
that
the
electronic
or
hardcopy
information
is
protected
at
the
level
of
the
subset
of
CUI
for
which
the
authorizing
law,
regulation,
or
Government-wide
policy
does
not
set
out
specific
handling
or
dissemination
controls.
Agencies
handle
CUI
Basic
according
to
the
uniform
set
of
controls
set
forth
in
this
part
and
the
CUI
Registry.
CUI
Basic
differs
from
CUI
Specified
(see
definition
for
CUI
Specified),
and
CUI
Basic
controls
apply
whenever
CUI
Specified
ones
do
not
cover
the
involved
CUI.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage Note: Examples of healthcare regulation governing CUI Basic marking include HIPAA Unique Identifier provisions 42 USC 1320d-2 note(b) https://www.govinfo.gov/content/pkg/USCODE-2016-title42/pdf/USCODE-2016-title42-chap7-subchapXI-partC-sec1320d-2.pdf; Title 38 Section 7332 https://www.govinfo.gov/content/pkg/USCODE-2016-title38/pdf/USCODE-2016-title38-partV-chap73-subchapIII-sec7332.pdf; and several sections of 42 CFR Part 2.related to consent and confidentiality, e.g., https://www.govinfo.gov/content/pkg/CFR-2017-title42-vol1/pdf/CFR-2017-title42-vol1-sec2-12.pdf |
CUIHLTHP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | (CUI//HLTH) |
A
displayed
mark,
required
to
be
rendered
as
"(CUI//HLTH)",
indicating
that
a
portion
of
an
electronic
or
hardcopy
information
is
protected
at
the
level
of
the
subset
of
CUI
for
which
the
authorizing
law,
regulation,
or
Government-wide
policy
does
not
set
out
specific
handling
or
dissemination
controls.
Agencies
handle
CUI
Basic
according
to
the
uniform
set
of
controls
set
forth
in
this
part
and
the
CUI
Registry.
CUI
Basic
differs
from
CUI
Specified
(see
definition
for
CUI
Specified),
and
CUI
Basic
controls
apply
whenever
CUI
Specified
ones
do
not
cover
the
involved
CUI.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage Note: Examples of healthcare regulation governing CUI Basic marking include HIPAA Unique Identifier provisions 42 USC 1320d-2 note(b) https://www.govinfo.gov/content/pkg/USCODE-2016-title42/pdf/USCODE-2016-title42-chap7-subchapXI-partC-sec1320d-2.pdf; Title 38 Section 7332 https://www.govinfo.gov/content/pkg/USCODE-2016-title38/pdf/USCODE-2016-title38-partV-chap73-subchapIII-sec7332.pdf; and several sections of 42 CFR Part 2.related to consent and confidentiality, e.g., https://www.govinfo.gov/content/pkg/CFR-2017-title42-vol1/pdf/CFR-2017-title42-vol1-sec2-12.pdf |
CUIP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | (CUI) |
A
displayed
mark,
required
to
be
rendered
as
"(CUI)",
indicating
that
a
portion
of
an
electronic
or
hardcopy
information
is
protected
at
the
level
of
the
subset
of
CUI
for
which
the
authorizing
law,
regulation,
or
Government-wide
policy
does
not
set
out
specific
handling
or
dissemination
controls.
Agencies
handle
CUI
Basic
according
to
the
uniform
set
of
controls
set
forth
in
this
part
and
the
CUI
Registry.
CUI
Basic
differs
from
CUI
Specified
(see
definition
for
CUI
Specified),
and
CUI
Basic
controls
apply
whenever
CUI
Specified
ones
do
not
cover
the
involved
CUI.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage Note: Examples of healthcare regulation governing CUI Basic marking include HIPAA Unique Identifier provisions 42 USC 1320d-2 note(b) https://www.govinfo.gov/content/pkg/USCODE-2016-title42/pdf/USCODE-2016-title42-chap7-subchapXI-partC-sec1320d-2.pdf; Title 38 Section 7332 https://www.govinfo.gov/content/pkg/USCODE-2016-title38/pdf/USCODE-2016-title38-partV-chap73-subchapIII-sec7332.pdf; and several sections of 42 CFR Part 2.related to consent and confidentiality, e.g., https://www.govinfo.gov/content/pkg/CFR-2017-title42-vol1/pdf/CFR-2017-title42-vol1-sec2-12.pdf |
CUIPRVCY
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | CUI//PRVCY |
A
displayed
mark,
required
to
be
rendered
as
"CUI//PRVCY",
indicating
that
the
electronic
or
hardcopy
controlled
unclassified
basic
privacy
information
is
private
and
must
be
protected
at
the
level
of
the
subset
of
CUI
for
which
the
authorizing
law,
regulation,
or
Government-wide
policy
does
not
set
out
specific
handling
or
dissemination
controls.
Agencies
handle
CUI
Basic
according
to
the
uniform
set
of
controls
set
forth
in
this
part
and
the
CUI
Registry.
CUI
Basic
differs
from
CUI
Specified
(see
definition
for
CUI
Specified),
and
CUI
Basic
controls
apply
whenever
CUI
Specified
ones
do
not
cover
the
involved
CUI.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage Note: Examples of privacy regulation governing CUI Basic marking include 20 CFR 401.100 related to SSA disclosure of personal, program, and non-program information. https://www.govinfo.gov/content/pkg/CFR-2017-title20-vol2/pdf/CFR-2017-title20-vol2-sec401-100.pdf. |
CUIPRVCYP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | (CUI//PRVCY) |
A
displayed
mark,
required
to
be
rendered
as
"(CUI//PRVCY)",
indicating
that
a
portion
of
an
electronic
or
hardcopy
information
is
protected
at
the
level
of
the
subset
of
CUI
for
which
the
authorizing
law,
regulation,
or
Government-wide
policy
does
not
set
out
specific
handling
or
dissemination
controls.
Agencies
handle
CUI
Basic
according
to
the
uniform
set
of
controls
set
forth
in
this
part
and
the
CUI
Registry.
CUI
Basic
differs
from
CUI
Specified
(see
definition
for
CUI
Specified),
and
CUI
Basic
controls
apply
whenever
CUI
Specified
ones
do
not
cover
the
involved
CUI.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage Note: Examples of privacy regulation governing CUI Basic marking include 20 CFR 401.100 related to SSA disclosure of personal, program, and non-program information. https://www.govinfo.gov/content/pkg/CFR-2017-title20-vol2/pdf/CFR-2017-title20-vol2-sec401-100.pdf. |
CUISP-HLTH
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | CUI//SP-HLTH |
A
displayed
mark,
required
to
be
rendered
as
"CUI//SP-HLTH",
indicating
that
the
electronic
or
hardcopy
information
is
protected
at
the
level
of
the
subset
of
CUI
in
which
the
authorizing
law,
regulation,
or
Government-wide
policy
contains
specific
handling
controls
that
it
requires
or
permits
agencies
to
use
that
differ
from
those
for
CUI
Basic.
The
CUI
Registry
indicates
which
laws,
regulations,
and
Government-wide
policies
include
such
specific
requirements.
CUI
Specified
controls
may
be
more
stringent
than,
or
may
simply
differ
from,
those
required
by
CUI
Basic;
the
distinction
is
that
the
underlying
authority
spells
out
the
controls
for
CUI
Specified
information
and
does
not
for
CUI
Basic
information.
CUI
Basic
controls
apply
to
those
aspects
of
CUI
Specified
where
the
authorizing
laws,
regulations,
and
Government-wide
policies
do
not
provide
specific
guidance.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage Note: Examples of healthcare regulation governing CUI Specified marking include HIPAA Transaction and Code Sets and references the Congressional requirement that HHS promulgate Privacy, and Security rules https://www.govinfo.gov/content/pkg/USCODE-2016-title42/pdf/USCODE-2016-title42-chap7-subchapXI-partC-sec1320d-2.pdf. |
CUISP-HLTHP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | (CUI//SP-HLTH) |
A
displayed
mark,
required
to
be
rendered
as
"(CUI//SP-HLTH)",
indicating
that
a
portion
of
an
electronic
or
hardcopy
information
is
protected
at
the
level
of
the
subset
of
CUI
for
which
the
authorizing
law,
regulation,
or
Government-wide
policy
does
not
set
out
specific
handling
or
dissemination
controls.
Agencies
handle
CUI
Basic
according
to
the
uniform
set
of
controls
set
forth
in
this
part
and
the
CUI
Registry.
CUI
Basic
differs
from
CUI
Specified
(see
definition
for
CUI
Specified),
and
CUI
Basic
controls
apply
whenever
CUI
Specified
ones
do
not
cover
the
involved
CUI.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage Note: Examples of healthcare regulation governing CUI Specified marking include HIPAA Transaction and Code Sets and references the Congressional requirement that HHS promulgate Privacy, and Security rules https://www.govinfo.gov/content/pkg/USCODE-2016-title42/pdf/USCODE-2016-title42-chap7-subchapXI-partC-sec1320d-2.pdf |
CUISP-PRVCY
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | CUI//SP-PRVCY |
A
displayed
mark,
required
to
be
rendered
as
"CUI//SP-PRVCY",
indicating
that
the
electronic
or
hardcopy
information
is
protected
at
the
level
of
the
subset
of
CUI
for
which
the
authorizing
law,
regulation,
or
Government-wide
policy
does
not
set
out
specific
handling
or
dissemination
controls.
Agencies
handle
CUI
Basic
according
to
the
uniform
set
of
controls
set
forth
in
this
part
and
the
CUI
Registry.
CUI
Basic
differs
from
CUI
Specified
(see
definition
for
CUI
Specified),
and
CUI
Basic
controls
apply
whenever
CUI
Specified
ones
do
not
cover
the
involved
CUI.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage
Note:
Examples
of
privacy
regulation
governing
CUI
Specified
marking
is
OMB
M-17-12�
This
Memorandum
sets
forth
the
policy
for
Federal
agencies
to
prepare
for
and
respond
to
a
breach
of
personally
identifiable
information
(PII).
It
includes
a
framework
for
assessing
and
mitigating
the
risk
of
harm
to
individuals
potentially
affected
by
a
breach,
as
well
as
guidance
on
whether
and
how
to
provide
notification
and
services
to
those
individuals.
|
CUISP-PRVCYP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | (CUI//SP-PRVCY) |
A
displayed
mark,
required
to
be
rendered
as
"(CUI//SP-PRVCY)",
indicating
that
a
portion
of
an
electronic
or
hardcopy
information
is
protected
at
the
level
of
the
subset
of
CUI
for
which
the
authorizing
law,
regulation,
or
Government-wide
policy
does
not
set
out
specific
handling
or
dissemination
controls.
Agencies
handle
CUI
Basic
according
to
the
uniform
set
of
controls
set
forth
in
this
part
and
the
CUI
Registry.
CUI
Basic
differs
from
CUI
Specified
(see
definition
for
CUI
Specified),
and
CUI
Basic
controls
apply
whenever
CUI
Specified
ones
do
not
cover
the
involved
CUI.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html.
Usage
Note:
Examples
of
privacy
regulation
governing
CUI
Specified
marking
is
OMB
M-17-12�
This
Memorandum
sets
forth
the
policy
for
Federal
agencies
to
prepare
for
and
respond
to
a
breach
of
personally
identifiable
information
(PII).
It
includes
a
framework
for
assessing
and
mitigating
the
risk
of
harm
to
individuals
potentially
affected
by
a
breach,
as
well
as
guidance
on
whether
and
how
to
provide
notification
and
services
to
those
individuals.
|
UUI
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | (U) |
A
displayed
mark,
required
to
be
rendered
as
"(U)",
indicating
that
a
portion
of
an
electronic
or
hardcopy
information
is
neither
Executive
Order
13556
nor
classified
information
authorities
cover
as
protected.
Although
this
information
is
not
controlled
or
classified,
agencies
must
still
handle
it
in
accordance
with
Federal
Information
Security
Modernization
Act
(FISMA)
requirements.
From
CUI
Glossary
https://www.archives.gov/cui/registry/cui-glossary.html
Usage Note: Regulatory Source: 32 CFR § 2002.20 Marking. Federal Register Page 63344 63344 (ii) Authorized holders permitted to designate CUI must portion mark both CUI and uncontrolled unclassified portions. CUI Marking Handbook https://www.archives.gov/files/cui/20161206-cui-marking-handbook-v1-1.pdf CUI Portion Marking: Portion marking of CUI is optional in a fully unclassified document, but is permitted and encouraged to facilitate information sharing and proper handling of the information. Agency heads may approve the required use of CUI Portion marking on all CUI generated within their agency. As such, users should consult their agency CUI policy when creating CUI documents. When CUI Portion Markings are used and a portion does not contain CUI a “U� is placed in parentheses to indicate that the portion contains Uncontrolled Unclassified Information. (Page 14) CUI Portion Markings are placed at the beginning of the portion to which they apply and must be used throughout the entire document. They are presented in all capital letters and separated as indicated in this handbook and the CUI Registry. The presence of EVEN ONE item of CUI in a document requires CUI marking of that document. Because of this, CUI Portion Markings can be of great assistance in determining if a document contains CUI and therefore must be marked as such. Remember: When portion markings are used and any portion does not contain CUI, a “(U)� is placed in front of that portion to indicate that it contains Uncontrolled - or non-CUI - Unclassified Information. (Page 15) |
SecurityLabelMark
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | Security Label Mark |
An
abstract
code
for
displayed
Security
Label
tags.
Usage Note: These marks may be based on any of the HL7 Security Labeling related codes from various code systems and values sets, which are organized according to the HL7 Privacy and Security Classification System into HL7 Security Observation Type Named Tag Sets and valued with codes associated with the HL7 Security Observation Value Tag Set Names. |
ConfidentialMark
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | confidential mark |
A displayed mark rendered as "Confidential", which indicates to end users that the electronic or hardcopy information they are viewing must be protected at a level of protection as dictated by applicable policy.
May
be
used
to
indicate
proprietary
or
classified
information
that
is,
for
example,
business,
intelligence,
or
project
related,
e.g.,
secret
ingredients
in
a
therapeutic
substance;
location
of
disaster
health
facilities
and
providers,
or
the
name
of
a
manufacturer
or
project
contractor.
Example
use
cases
include
a
display
to
alert
authorized
business
system
users
that
they
are
viewing
additionally
protected
proprietary
and
business
confidential
information
deemed
proprietary
under
an
applicable
jurisdictional
or
organizational
policy.
Usage Note:
The
ConfidentialMark
(confidential
mark)
description
is
based
on
the
HL7
Confidentiality
Concept
Domain:
Types
of
privacy
metadata
classifying
an
IT
resource
(data,
information
object,
service,
or
system
capability)
according
to
its
level
of
sensitivity,
which
is
based
on
an
analysis
of
applicable
privacy
policies
and
the
risk
of
financial,
reputational,
or
other
harm
to
an
individual
or
entity
that
could
result
if
made
available
or
disclosed
to
unauthorized
individuals,
entities,
or
processes.
Usage Note: Confidentiality codes may be used in security labels and privacy markings to classify IT resources based on sensitivity to indicate the obligation of a custodian or receiver to ensure that the protected resource is not made available or disclosed to individuals, entities, or processes (security principals) unless authorized per applicable policies. Confidentiality codes may also be used in the clearances of initiators requesting access to protected resources. Map: Definition aligns with ISO 7498-2:1989 - Confidentiality is the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. |
COPYMark
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | copy of original mark |
A
displayed
mark
indicating
that
the
electronic
or
hardcopy
information
is
a
copy
of
an
authoritative
source
for
the
information.
The
copy
is
not
considered
authoritative
but
is
a
duplicate
of
the
authoritative
content.
Usage Note: Applicable policy will dictate how the COPY mark will be displayed. Typical renderings include the marking appearing at the top or "banner" of electronic or hardcopy pages, or as watermarks set diagonally across each page. |
DeliverToAddresseeOnlyMark
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | deliver only to addressee mark |
A
displayed
mark
on
an
electronic
transmission
or
physical
container
such
as
an
electronic
transmittal
wrapper,
batch
file,
message
header,
or
a
physical
envelop
or
package
indicating
that
the
contents,
whether
electronic
or
hardcopy
information,
must
only
be
delivered
to
the
authorized
recipient(s)
named
in
the
address.
Usage Note: Required by US 32 CRF Part 2002 for container storing or transmitting CUI. |
RedisclosureProhibitionMark
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | prohibition against redisclosure mark |
A
displayed
mark
rendered
to
end
users
as
a
prescribed
text
warning
that
the
electronic
or
hardcopy
information
shall
not
be
further
disclosed
without
consent
of
the
subject
of
the
information.
For
example,
in
order
to
warn
a
recipient
of
42
CFR
Part
2
information
of
the
redisclosure
restrictions,
the
rule
mandates
that
end
users
receive
a
written
prohibition
against
redisclosure
unless
authorized
by
patient
consent
or
otherwise
permitted
by
Part
2.
See
42
CFR
§
2.32
Prohibition
on
re-disclosure.
(a)Notice
to
accompany
disclosure.
Each
disclosure
made
with
the
patient's
written
consent
must
be
accompanied
by
one
of
the
following
written
statements:
(1)
This
information
has
been
disclosed
to
you
from
records
protected
by
federal
confidentiality
rules
(
42
CFR
part
2).
The
federal
rules
prohibit
you
from
making
any
further
disclosure
of
information
in
this
record
that
identifies
a
patient
as
having
or
having
had
a
substance
use
disorder
either
directly,
by
reference
to
publicly
available
information,
or
through
verification
of
such
identification
by
another
person
unless
further
disclosure
is
expressly
permitted
by
the
written
consent
of
the
individual
whose
information
is
being
disclosed
or
as
otherwise
permitted
by
42
CFR
part
2.
A
general
authorization
for
the
release
of
medical
or
other
information
is
NOT
sufficient
for
this
purpose
(see
§
2.31).
The
federal
rules
restrict
any
use
of
the
information
to
investigate
or
prosecute
with
regard
to
a
crime
any
patient
with
a
substance
use
disorder,
except
as
provided
at
§§
2.12(c)(5)
and
2.65;
or
(2)
42
CFR
part
2
prohibits
unauthorized
disclosure
of
these
records.
https://www.law.cornell.edu/cfr/text/42/2.32
Usage Note: Example of marking requirement from SAMHSA FAQ Response to question 13: Would a logon or splash page notification on an HIO’s portal that contains the Part 2 notice prohibiting redisclosure be sufficient to meet Part 2’s requirement that disclosures made with patient consent be accompanied by such a statement? No. Part 2 requires each disclosure made with written patient consent to be accompanied by a written statement that the information disclosed is protected by federal law and that the recipient cannot make any further disclosure of it unless permitted by the regulations (42 CFR § 2.32). A logon page is the page where a user logs onto a computer system; a splash page is an introductory page to a web site. A logon or splash page notification on a HIO's portal including the statement as required by § 2.32 would not be sufficient notification regarding prohibitions on redisclosure since it would not accompany a specific disclosure. The notification must be tied to the Part 2 information being disclosed in order to ensure that the recipient of that information knows that specific information is protected by Part 2 and cannot be redisclosed except as authorized by the express written consent of the person to whom it pertains or as otherwise permitted by Part 2. https://www.samhsa.gov/about-us/who-we-are/laws-regulations/confidentiality-regulations-faqs |
RestrictedConfidentialityMark
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | restricted confidentiality mark |
A
displayed
mark
rendered
to
end
users
as
"Restricted
Confidentiality",
which
indicates
that
the
electronic
or
hardcopy
information
they
are
viewing,
must
be
protected
at
a
restricted
level
of
confidentiality
protection
as
defined
by
HL7
Confidentiality
code
"R"
(restricted).
Examples:
Includes
information
that
is
additionally
protected
such
as
sensitive
conditions
mental
health,
HIV,
substance
abuse,
domestic
violence,
child
abuse,
genetic
disease,
and
reproductive
health;
or
sensitive
demographic
information
such
as
a
patient's
standing
as
an
employee
or
a
celebrity.
Use
cases
include
a
display
to
alert
authorized
EHR
users
that
they
are
viewing
additionally
protected
health
information
deemed
sensitive
by
an
applicable
jurisdictional,
organizational,
or
personal
privacy
policy.
Usage Note: The definition is based on HL7 Confidentiality code "R" (restricted), which is described as: Privacy metadata indicating highly sensitive, potentially stigmatizing information, which presents a high risk to the information subject if disclosed without authorization. May be pre-empted by jurisdictional law, e.g., for public health reporting or emergency treatment. Foundational definitions of Confidentiality: From HL7 Confidentiality Concept Domain: Types of privacy metadata classifying an IT resource (data, information object, service, or system capability) according to its level of sensitivity, which is based on an analysis of applicable privacy policies and the risk of financial, reputational, or other harm to an individual or entity that could result if made available or disclosed to unauthorized individuals, entities, or processes. Usage Note from HL7 Confidentiality code "R": Confidentiality codes may be used in security labels and privacy markings to classify IT resources based on sensitivity to indicate the obligation of a custodian or receiver to ensure that the protected resource is not made available or disclosed to individuals, entities, or processes (security principals) unless authorized per applicable policies. Confidentiality codes may also be used in the clearances of initiators requesting access to protected resources. This metadata indicates that the receiver may be obligated to comply with applicable, prevailing (default) jurisdictional privacy law or disclosure authorization. Map: Definition aligns with ISO 7498-2:1989 - Confidentiality is the property that information is not made available or disclosed to unauthorized individuals, entities, or processes. Map: Partial Map to ISO 13606-4 Sensitivity Level (3) Clinical Care: Default for normal clinical care access (i.e. most clinical staff directly caring for the patient should be able to access nearly all of the EHR). Maps to normal confidentiality for treatment information but not to ancillary care, payment and operations. |
DRAFTMark
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | Draft Mark |
A displayed mark indicating that the electronic or hard-copy information is still under development and is not yet considered to be ready for normal use. |
RefrainPolicy
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | refrain policy |
Conveys
prohibited
actions
which
an
information
custodian,
receiver,
or
user
is
not
permitted
to
perform
unless
otherwise
authorized
or
permitted
under
specified
circumstances.
Usage Notes: ISO 22600-2 species that a Refrain Policy "defines actions the subjects must refrain from performing". Per HL7 Composite Security and Privacy Domain Analysis Model: May be used to indicate that a specific action is prohibited based on specific access control attributes e.g., purpose of use, information type, user role, etc. |
NOAUTH
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no disclosure without subject authorization |
Prohibition on disclosure without information subject's authorization. |
NOCOLLECT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no collection |
Prohibition on collection or storage of the information. |
NODSCLCD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no disclosure without consent directive |
Prohibition on disclosure without organizational approved patient restriction. |
NODSCLCDS
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no disclosure without information subject's consent directive |
Prohibition on disclosure without a consent directive from the information subject. |
NOINTEGRATE
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no integration |
Prohibition on Integration into other records. |
NOLIST
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no unlisted entity disclosure |
Prohibition on disclosure except to entities on specific access list. |
NOMOU
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no disclosure without MOU |
Prohibition on disclosure without an interagency service agreement or memorandum of understanding (MOU). |
NOORGPOL
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no disclosure without organizational authorization |
Prohibition on disclosure without organizational authorization. |
NOPAT
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no disclosure to patient, family or caregivers without attending provider's authorization |
Prohibition
on
disclosing
information
to
patient,
family
or
caregivers
without
attending
provider's
authorization.
Usage Note: The information may be labeled with the ActInformationSensitivity TBOO code, triggering application of this RefrainPolicy code as a handling caveat controlling access. Maps to FHIR NOPAT: Typically, this is used on an Alert resource, when the alert records information on patient abuse or non-compliance.
FHIR
print
name
is
"keep
information
from
patient".
Maps
to
the
French
realm
-
code:
French use case: A label for documents that the author chose to hide from the patient until the content can be disclose to the patient in a face to face meeting between a healthcare professional and the patient (in French law some results like cancer diagnosis or AIDS diagnosis must be announced to the patient by a healthcare professional and should not be find out by the patient alone). |
NOPERSISTP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no collection beyond purpose of use |
Prohibition on collection of the information beyond time necessary to accomplish authorized purpose of use is prohibited. |
NORDSCLCD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no redisclosure without consent directive |
Prohibition on redisclosure without patient consent directive. |
NORDSLCD
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no redisclosure without consent directive |
Prohibition on redisclosure without patient consent directive. |
NORDSCLCDS
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no redisclosure without information subject's consent directive |
Prohibition on redisclosure without a consent directive from the information subject. |
NORDSCLW
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no disclosure without jurisdictional authorization |
Prohibition on disclosure without authorization under jurisdictional law. |
NORELINK
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no relinking |
Prohibition on associating de-identified or pseudonymized information with other information in a manner that could or does result in disclosing information intended to be masked. |
NOREUSE
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no reuse beyond purpose of use |
Prohibition on use of the information beyond the purpose of use initially authorized. |
NOVIP
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no unauthorized VIP disclosure |
Prohibition on disclosure except to principals with access permission to specific VIP information. |
ORCON
|
http://terminology.hl7.org/CodeSystem/v3-ActCode | no disclosure without originator authorization |
Prohibition on disclosure except as permitted by the information originator. |
HMARKT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | healthcare marketing |
To perform one or more operations on information for marketing services and products related to health care. |
HOPERAT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | healthcare operations |
To perform one or more operations on information used for conducting administrative and contractual activities related to the provision of health care. |
CAREMGT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | care management |
To
perform
analytics,
evaluation
and
other
secondary
uses
of
treatment
and
healthcare
related
information
to
manage
the
quality,
efficacy,
patient
safety,
population
health,
and
cost
effectiveness
of
healthcare
delivery.
Explicitly
excludes
the
use
of
information
to
organize
the
delivery
of
health
care
for
care
coordination
and
case
management,
or
to
provide
healthcare
treatment.
Usage
Note:
The
concept
of
care
management
is
narrower
than
the
list
of
activities
related
to
more
general
organizational
objectives
such
as
provider
profiling,
education
of
healthcare
and
non-healthcare
professionals;
insurance
underwriting,
premium
rating,
reinsurance;
organizational
legal,
medical
review,
auditing,
compliance
and
fraud
and
abuse
detection;
business
planning,
development,
and
restructuring;
fund-raising;
and
customer
service.
Map: Maps to ISO 14265 Classification Term "Health service management and quality assurance" described as "To inform persons or processes responsible for determining the availability, quality, safety, equity and cost-effectiveness of health care services." There is a semantic gap in concepts. This classification term is described as activities, i.e., "to inform persons" or "to inform processes" rather than the rationale for performing actions/operations on information related to the activity. |
DONAT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | donation |
To perform one or more operations on information used for cadaveric organ, eye or tissue donation. |
FRAUD
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | fraud |
To perform one or more operations on information used for fraud detection and prevention processes. |
GOV
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | government |
To perform one or more operations on information used within government processes. |
HACCRED
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | health accreditation |
To perform one or more operations on information for conducting activities related to meeting accreditation criteria. |
HCOMPL
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | health compliance |
To perform one or more operations on information used for conducting activities required to meet a mandate. |
HDECD
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | decedent |
To perform one or more operations on information used for handling deceased patient matters. |
HDIRECT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | directory |
To
perform
one
or
more
operation
operations
on
information
used
to
manage
a
patient
directory.
Examples:
|
HDM
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | healthcare delivery management |
To
perform
one
or
more
actions
on
information
used
for
conducting
administrative
and
contractual
activities
by
or
on
behalf
of
organizational
entities
responsible
for
delivery
of
an
individual's
benefits
in
a
healthcare
program,
health
plan
or
insurance.
Explicitly
excludes
the
use
of
information
to
organize
the
delivery
of
health
care
for
care
coordination
and
case
management,
or
to
provide
healthcare
treatment.
Usage
Note:
Examples
of
activities
conducted
under
this
purpose
of
use:
provider
profiling,
risk
adjustment,
underwriting,
fraud
and
abuse,
quality
improvement
population
health
and
care
management.
Aligns
with
HIPAA
Operation
POU
minus
coordination
of
care
or
other
treatment
related
activities.
Similar
to
the
description
in
SAMHSA
Confidentiality
of
Substance
Use
Disorder
Patient
Records
Supplemental
notice
of
proposed
rulemaking.
Map: Maps to ISO 14265 Classification Term "Administration of care for an individual subject of care" described as "To inform persons or processes responsible for enabling the availability of resources or funding or permissions for providing health care services to the subject of care." However, this classification term is described as activities, i.e., "to inform persons" or "to inform processes" rather than the rationale for performing actions/operations on information related to the activity. |
HLEGAL
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | legal |
To perform one or more operations on information for conducting activities required by legal proceeding. |
HOUTCOMS
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | health outcome measure |
To perform one or more operations on information used for assessing results and comparative effectiveness achieved by health care practices and interventions. |
HPRGRP
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | health program reporting |
To perform one or more operations on information used for conducting activities to meet program accounting requirements. |
HQUALIMP
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | health quality improvement |
To perform one or more operations on information used for conducting administrative activities to improve health care quality. |
HSYSADMIN
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | health system administration |
To perform one or more operations on information to administer the electronic systems used for the delivery of health care. |
LABELING
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | labeling |
To perform one or more operations on information to assign, persist, and manage labels to healthcare data to characterize various aspects, such as its security classification, sensitivity, compartment, integrity, and provenance; applicable privacy, consent, security, provenance, and trust policies; and handling caveats such as purpose of use, obligations, and refrain policies. Label management includes classification of target data by constructing and binding of a label set per applicable policies, security policy information file semantics, and classification guides. Label management also includes process and procedures for subsequent revision of a label for, e.g., reclassification, downgrading classification, and declassification. Label revisions may be triggered by, e.g., expiry of classification period; changes in applicable policy, e.g., revocation of a consent directive; or changes in the governing policy domain in which the data is relocated or a copy of the data is sent. If a label is revised, an audit log should be kept and the provenance of the label changes should be tracked. |
METAMGT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | metadata management |
To perform one or more operations on information to assign, persist, and manage metadata to healthcare data to characterize various aspects used for its indexing, discovery, retrieval, and processing by systems, applications, and end users. For example, master index identifier, media type, and location. |
MEMADMIN
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | member administration |
To perform one or more operations on information to administer health care coverage to an enrollee under a policy or program. |
MILCDM
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | military command |
To perform one or more operations on information for conducting activities required by military processes, procedures, policies, or law. |
PATADMIN
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | patient administration |
To perform one or more operations on information used for operational activities conducted to administer the delivery of health care to a patient. |
PATSFTY
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | patient safety |
To perform one or more operations on information in processes related to ensuring the safety of health care. |
PERFMSR
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | performance measure |
To perform one or more operations on information used for monitoring performance of recommended health care practices and interventions. |
RECORDMGT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | records management |
To perform one or more operations on information used within the health records management process. |
SYSDEV
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | system development |
To perform one or more operations on information to design, develop, implement, test, or deploy a healthcare system or application. |
HTEST
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | test health data |
To
perform
one
or
more
operations
on
information
that
is
simulated
or
synthetic
health
data
used
for
testing
system
capabilities
outside
of
a
production
or
operational
system
environment.
Usage Note: Data marked with a HTEST security label enables an access control system to permit interfacing systems or end users provisioned with a clearance, which includes a HTEST purpose of use attribute, to test, verify, or validate that a system or application will operate in production as intended based on design specifications. |
TRAIN
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | training |
To perform one or more operations on information used in training and education. |
HPAYMT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | healthcare payment |
To perform one or more operations on information for conducting financial or contractual activities related to payment for provision of health care. |
CLMATTCH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | claim attachment |
To perform one or more operations on information for provision of additional clinical evidence in support of a request for coverage or payment for health services. |
COVAUTH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | coverage authorization |
To perform one or more operations on information for conducting prior authorization or predetermination of coverage for services. |
COVERAGE
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | coverage under policy or program |
To perform one or more operations on information for conducting activities related to coverage under a program or policy. |
ELIGDTRM
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | eligibility determination |
To perform one or more operations on information used for conducting eligibility determination for coverage in a program or policy. May entail review of financial status or disability assessment. |
ELIGVER
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | eligibility verification |
To perform one or more operations on information used for conducting eligibility verification of coverage in a program or policy. May entail provider contacting coverage source (e.g., government health program such as workers compensation or health plan) for confirmation of enrollment, eligibility for specific services, and any applicable copays. |
ENROLLM
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | enrollment |
To perform one or more operations on information used for enrolling a covered party in a program or policy. May entail recording of covered party's and any dependent's demographic information and benefit choices. |
MILDCRG
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | military discharge |
To perform one or more operations on information for the process of releasing military personnel from their service obligations, which may include determining service merit, discharge benefits, and disability assessment. |
REMITADV
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | remittance advice |
To perform one or more operations on information about the amount remitted for a health care claim. |
HRESCH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | healthcare research |
To perform one or more operations on information for conducting scientific investigations to obtain health care knowledge. Use of the data iincludes basic and applied research such as biomedical, population origin or ancestry, translational research, and disease, discipline, specialty specific healthcare research and clinical trial research. |
BIORCH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | biomedical research |
To perform one or more operations on information for conducting scientific investigations to obtain health care knowledge. Use of the data must be related to specified biomedical basic or applied research. For example, research on rare plants to determine whether biologic properties may be useful for pharmaceutical development. May be used in combination with clinical trial and other healthcare research purposes of use. |
CLINTRCH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | clinical trial research |
To perform one or more operations on information for conducting scientific investigations in accordance with clinical trial protocols to obtain health care knowledge. |
CLINTRCHNPC
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | clinical trial research without patient care |
To perform one or more operations on information for conducting scientific investigations in accordance with clinical trial protocols to obtain health care knowledge without provision of patient care. May be post-coordinated or used with other purposes of use such as disease, discipline, specialty, population origins or ancestry, translational healthcare research. For example, a clinical trial conducted on laboratory specimens collected from a specified patient population. |
CLINTRCHPC
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | clinical trial research with patient care |
To perform one or more operations on information for conducting scientific investigations with patient care in accordance with clinical trial protocols to obtain health care knowledge. May be post-coordinated or used with other purposes of use such as disease, discipline, specialty, population origins or ancestry, translational healthcare research. For example, an "off-label" drug used for cancer therapy administer to a specified patient population. |
PRECLINTRCH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | preclinical trial research |
To perform one or more operations on information in preparation for conducting scientific investigation to obtain health care knowledge, such as research on animals or review of patient health records, to determine the feasibility of a clinical trial study; assist with protocol design; or in preparation for institutional review board or ethics committee approval process. May be post-coordinated or used with other purposes of use such as disease, discipline, specialty, population origins or ancestry, translational healthcare research. |
DSRCH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | disease specific healthcare research |
To perform one or more operations on information for conducting scientific investigations to obtain health care knowledge. Use of the data must be related to specified conditions, diagnosis, or disease healthcare research. For example, conducting cancer research by testing reaction of tumor cells to certain biologics. May be used in combination with clinical trial and other healthcare research purposes of use. |
POARCH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | population origins or ancestry healthcare research |
To perform one or more operations on information, including genealogical pedigrees, historical records, surveys, family health data, health records, and genetic information, for conducting scientific investigations to obtain health care knowledge. Use of the data must be related to population origins and/or ancestry healthcare research. For example, gathering genetic specimens from a specific population in order to determine the ancestry and population origins of that group. May be used in combination with clinical trial and other healthcare research purposes of use. |
TRANSRCH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | translational healthcare research |
To perform one or more operations on information for conducting scientific investigations to obtain health care knowledge related to evidence based medicine during the course of providing healthcare treatment. Sometimes referred to as "bench to bedside", which is the iterative feedback loop between healthcare research and clinical trials with input from information collected in the course of routine provision of healthcare. For example, by extending a patient encounter to conduct a survey related to a research topic such as attitudes about use of a wellness device that a patient agreed to use. May be used in combination with clinical trial and other healthcare research purposes of use. |
PATRQT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | patient requested |
To perform one or more operations on information in response to a patient's request. |
FAMRQT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | family requested |
To perform one or more operations on information in response to a request by a family member authorized by the patient. |
PWATRNY
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | power of attorney |
To perform one or more operations on information in response to a request by a person appointed as the patient's legal representative. |
SUPNWK
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | support network |
To perform one or more operations on information in response to a request by a person authorized by the patient. |
PUBHLTH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | public health |
To perform one or more operations on information for conducting public health activities, such as the reporting of notifiable conditions. |
DISASTER
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | disaster |
To perform one or more operations on information used for provision of immediately needed health care to a population of living subjects located in a disaster zone. |
THREAT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | threat |
To perform one or more operations on information used to prevent injury or disease to living subjects who may be the target of violence. |
TREAT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | treatment |
To perform one or more operations on information for provision of health care. |
CLINTRL
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | clinical trial |
To perform health care as part of the clinical trial protocol. |
COC
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | coordination of care |
To
perform
one
or
more
actions
on
information
in
order
to
organize
the
provision
and
case
management
of
an
individual’s
healthcare,
including:
Monitoring
a
person's
goals,
needs,
and
preferences;
acting
as
the
communication
link
between
two
or
more
participants
concerned
with
a
person's
health
and
wellness;
organizing
and
facilitating
care
activities
and
promoting
self-management
by
advocating
for,
empowering,
and
educating
a
person;
and
ensuring
safe,
appropriate,
non-duplicative,
and
effective
integrated
care.
Usage Note: Use when describing these functions: 1. Monitoring a person’s goals, needs, and preferences. 2. Acting as the communication link between two or more participants concerned with a person's health and wellness. 3. Organizing and facilitating care activities and promoting self-management by advocating for, empowering, and educating a person. 4. Ensuring safe, appropriate, non-duplicative, and effective integrated care. The goal is to clearly differentiate this type of coordination of care from HIPAA Operations by specifying that these actions on information are undertaken in the provision of healthcare treatment.
For
similar
uses
of
this
concept,
see
SAMHSA
Confidentiality
of
Substance
Use
Disorder
Patient
Records
Supplemental
notice
of
proposed
rulemaking,
which
differentiates
concepts
of
care
coordination
and
case
management
for
the
provision
of
treatment
as
specifically
distinct
from
activities
related
to
health
care
delivery
management
and
the
operations
of
organizational
entities
involved
in
the
delivery
of
healthcare.
Map: Maps to ISO 14265 Classification Terms: "Support of care activities within the provider organisation for an individual subject of care" described as "To inform persons or processes enabling others to provide health care services to the subject of care." "Subject of Care Uses" described as "To inform the subject of care in support of his or her own interests." |
ETREAT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | Emergency Treatment |
To perform one or more operations on information for provision of immediately needed health care for an emergent condition. |
BTG
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | break the glass |
To
perform
policy
override
operations
on
information
for
provision
of
immediately
needed
health
care
for
an
emergent
condition
affecting
potential
harm,
death
or
patient
safety
by
end
users
who
are
not
provisioned
for
this
purpose
of
use.
Includes
override
of
organizational
provisioning
policies
and
may
include
override
of
subject
of
care
consent
directive
restricting
access.
Map: Partially Maps to ISO 14265 Classification Term "Emergency care provision to an individual subject of care" described as "To inform persons needing to provide health care services to the subject of care urgently, possibly needing to over-ride the policies and consents pertaining to Purpose 1 above." Purpose 1 is equivalent to HL7 treatment purpose of use: "Clinical care provision to an individual subject of care" described as "To inform persons or processes responsible for providing health care services to the subject of care." The ISO description conflates both of the proposed specializations of HL7 ETREAT: break the glass and the typically broader access to health information normally available to providers who are provisioned for emergency workflows on a regular basis, e.g., Emergency Room providers. Examples of greater access than is normally accessible by providers based on the need to know are access to sensitive information for which access typically requires a patient's consent. This is not an override of a patient's dissent to disclose sensitive information in cases where the applicable policy waives the need for that consent to access this information. In US, Title 38 Section 7332 and 42 CFR Part 2 both permit emergency access without the need to override a patient's consent directive; rather, this access is a limitation to the patient's right to dissent from disclosure. |
ERTREAT
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | emergency room treatment |
To perform one or more operations on information for provision of immediately needed health care for an emergent condition in an emergency room or similar emergent care context by end users provisioned for this purpose, which does not constitute as policy override such as in a "Break the Glass" purpose of use. Map:Partially Maps to ISO 14265 Classification Term "Emergency care provision to an individual subject of care" described as "To inform persons needing to provide health care services to the subject of care urgently, possibly needing to over-ride the policies and consents pertaining to Purpose 1 above." Purpose 1 is equivalent to HL7 treatment purpose of use: "Clinical care provision to an individual subject of care" described as "To inform persons or processes responsible for providing health care services to the subject of care." The ISO description conflates both of the proposed specializations of HL7 ETREAT: break the glass and the typically broader access to health information normally available to providers who are provisioned for emergency workflows on a regular basis, e.g., Emergency Room providers. Examples of greater access than is normally accessible by providers based on the need to know are access to sensitive information for which access typically requires a patient's consent. This is not an override of a patient's dissent to disclose sensitive information in cases where the applicable policy waives the need for that consent to access this information. In US, Title 38 Section 7332 and 42 CFR Part 2 both permit emergency access without the need to override a patient's consent directive; rather, this access is a limitation to the patient's right to dissent from disclosure. There is a semantic gap in concepts. This classification term is described as activities “to inform persons� rather than the rationale for performing actions/operations on information related to the activity. |
POPHLTH
|
http://terminology.hl7.org/CodeSystem/v3-ActReason | population health |
To perform one or more operations on information for provision of health care to a population of living subjects, e.g., needle exchange program. |
_ActCoverageAssessmentObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | ActCoverageAssessmentObservationValue |
Codes specify the category of observation, evidence, or document used to assess for services, e.g., discharge planning, or to establish eligibility for coverage under a policy or program. The type of evidence is coded as observation values. |
_ActFinancialStatusObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | ActFinancialStatusObservationValue |
Code specifying financial indicators used to assess or establish eligibility for coverage under a policy or program; e.g., pay stub; tax or income document; asset document; living expenses. |
ASSET
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | asset |
Codes specifying asset indicators used to assess or establish eligibility for coverage under a policy or program. |
ANNUITY
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | annuity |
Indicator of annuity ownership or status as beneficiary. |
PROP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | real property |
Indicator of real property ownership, e.g., deed or real estate contract. |
RETACCT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | retirement investment account |
Indicator of retirement investment account ownership. |
TRUST
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | trust |
Indicator of status as trust beneficiary. |
INCOME
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | income |
Code specifying income indicators used to assess or establish eligibility for coverage under a policy or program; e.g., pay or pension check, child support payments received or provided, and taxes paid. |
CHILD
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | child support |
Indicator of child support payments received or provided. |
DISABL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | disability pay |
Indicator of disability income replacement payment. |
INVEST
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | investment income |
Indicator of investment income, e.g., dividend check, annuity payment; real estate rent, investment divestiture proceeds; trust or endowment check. |
PAY
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | paid employment |
Indicator of paid employment, e.g., letter of hire, contract, employer letter; copy of pay check or pay stub. |
RETIRE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | retirement pay |
Indicator of retirement payment, e.g., pension check. |
SPOUSAL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | spousal or partner support |
Indicator of spousal or partner support payments received or provided; e.g., alimony payment; support stipulations in a divorce settlement. |
SUPPLE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | income supplement |
Indicator of income supplement, e.g., gifting, parental income support; stipend, or grant. |
TAX
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | tax obligation |
Indicator of tax obligation or payment, e.g., statement of taxable income. |
LIVEXP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | living expense |
Codes specifying living expense indicators used to assess or establish eligibility for coverage under a policy or program. |
CLOTH
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | clothing expense |
Indicator of clothing expenses. |
FOOD
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | food expense |
Indicator of transportation expenses. |
HEALTH
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | health expense |
Indicator of health expenses; including medication costs, health service costs, financial participations, and health coverage premiums. |
HOUSE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | household expense |
Indicator of housing expense, e.g., household appliances, fixtures, furnishings, and maintenance and repairs. |
LEGAL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | legal expense |
Indicator of legal expenses. |
MORTG
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | mortgage |
Indicator of mortgage amount, interest, and payments. |
RENT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | rent |
Indicator of rental or lease payments. |
SUNDRY
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | sundry expense |
Indicator of transportation expenses. |
TRANS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | transportation expense |
Indicator of transportation expenses, e.g., vehicle payments, vehicle insurance, vehicle fuel, and vehicle maintenance and repairs. |
UTIL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | utility expense |
Indicator of transportation expenses. |
ELSTAT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | eligibility indicator |
Code specifying eligibility indicators used to assess or establish eligibility for coverage under a policy or program eligibility status, e.g., certificates of creditable coverage; student enrollment; adoption, marriage or birth certificate. |
ADOPT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | adoption document |
Indicator of adoption. |
BTHCERT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | birth certificate |
Indicator of birth. |
CCOC
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | creditable coverage document |
Indicator of creditable coverage. |
DRLIC
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | driver license |
Indicator of driving status. |
FOSTER
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | foster child document |
Indicator of foster child status. |
MEMBER
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | program or policy member |
Indicator of status as covered member under a policy or program, e.g., member id card or coverage document. |
MIL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | military identification |
Indicator of military status. |
MRGCERT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | marriage certificate |
Indicator of marriage status. |
PASSPORT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | passport |
Indicator of citizenship. |
STUDENRL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | student enrollment |
Indicator of student status. |
HLSTAT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | health status |
Code specifying non-clinical indicators related to health status used to assess or establish eligibility for coverage under a policy or program, e.g., pregnancy, disability, drug use, mental health issues. |
DISABLE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | disabled |
Indication of disability. |
DRUG
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | drug use |
Indication of drug use. |
IVDRG
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | IV drug use |
Indication of IV drug use . |
PGNT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | pregnant |
Non-clinical report of pregnancy. |
LIVDEP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | living dependency |
Code specifying observations related to living dependency, such as dependent upon spouse for activities of daily living. |
RELDEP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | relative dependent |
Continued living in private residence requires functional and health care assistance from one or more relatives. |
SPSDEP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | spouse dependent |
Continued living in private residence requires functional and health care assistance from spouse or life partner. |
URELDEP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | unrelated person dependent |
Continued living in private residence requires functional and health care assistance from one or more unrelated persons. |
LIVSIT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | living situation |
Code specifying observations related to living situation for a person in a private residence. |
ALONE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | alone |
Living
alone.
Maps
to
PD1-2
Living
arrangement
(IS)
00742
|
DEPCHD
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | dependent children |
Living with one or more dependent children requiring moderate supervision. |
DEPSPS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | dependent spouse |
Living with disabled spouse requiring functional and health care assistance |
DEPYGCHD
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | dependent young children |
Living with one or more dependent children requiring intensive supervision |
FAM
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | live with family |
Living
with
family.
Maps
to
PD1-2
Living
arrangement
(IS)
00742
|
RELAT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | relative |
Living
with
one
or
more
relatives.
Maps
to
PD1-2
Living
arrangement
(IS)
00742
|
SPS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | spouse only |
Living
only
with
spouse
or
life
partner.
Maps
to
PD1-2
Living
arrangement
(IS)
00742
|
UNREL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | unrelated person |
Living with one or more unrelated persons. |
SOECSTAT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | socio economic status |
Code specifying observations or indicators related to socio-economic status used to assess to assess for services, e.g., discharge planning, or to establish eligibility for coverage under a policy or program. |
ABUSE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | abuse victim |
Indication of abuse victim. |
HMLESS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | homeless |
Indication of status as homeless. |
ILGIM
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | illegal immigrant |
Indication of status as illegal immigrant. |
INCAR
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | incarcerated |
Indication of status as incarcerated. |
PROB
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | probation |
Indication of probation status. |
REFUG
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | refugee |
Indication of refugee status. |
UNEMPL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | unemployed |
Indication of unemployed status. |
_AllergyTestValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | AllergyTestValue |
Indicates the result of a particular allergy test. E.g. Negative, Mild, Moderate, Severe |
A0
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | no reaction |
**Description:**Patient exhibits no reaction to the challenge agent. |
A1
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | minimal reaction |
**Description:**Patient exhibits a minimal reaction to the challenge agent. |
A2
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | mild reaction |
**Description:**Patient exhibits a mild reaction to the challenge agent. |
A3
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | moderate reaction |
**Description:**Patient exhibits moderate reaction to the challenge agent. |
A4
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | severe reaction |
**Description:**Patient exhibits a severe reaction to the challenge agent. |
_CompositeMeasureScoring
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | CompositeMeasureScoring |
Observation values that communicate the method used in a quality measure to combine the component measure results included in an composite measure. |
ALLORNONESCR
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | All-or-nothing Scoring |
Code specifying that the measure uses all-or-nothing scoring. All-or-nothing scoring places an individual in the numerator of the composite measure if and only if they are in the numerator of all component measures in which they are in the denominator. |
LINEARSCR
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Linear Scoring |
Code specifying that the measure uses linear scoring. Linear scoring computes the fraction of component measures in which the individual appears in the numerator, giving equal weight to each component measure. |
OPPORSCR
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Opportunity Scoring |
Code specifying that the measure uses opportunity-based scoring. In opportunity-based scoring the measure score is determined by combining the denominator and numerator of each component measure to determine an overall composite score. |
WEIGHTSCR
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Weighted Scoring |
Code specifying that the measure uses weighted scoring. Weighted scoring assigns a factor to each component measure to weight that measure's contribution to the overall score. |
_CoverageLimitObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | CoverageLimitObservationValue |
**Description:**Coded observation values for coverage limitations, for e.g., types of claims or types of parties covered under a policy or program. |
_CoverageLevelObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | CoverageLevelObservationValue |
**Description:**Coded observation values for types of covered parties under a policy or program based on their personal relationships or employment status. |
ADC
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | adult child |
**Description:**Child over an age as specified by coverage policy or program, e.g., student, differently abled, and income dependent. |
CHD
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | child |
**Description:**Dependent biological, adopted, foster child as specified by coverage policy or program. |
DEP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | dependent |
**Description:**Person requiring functional and/or financial assistance from another person as specified by coverage policy or program. |
DP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | domestic partner |
**Description:**Persons registered as a family unit in a domestic partner registry as specified by law and by coverage policy or program. |
ECH
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | employee |
**Description:**An individual employed by an employer who receive remuneration in wages, salary, commission, tips, piece-rates, or pay-in-kind through the employeraTMs payment system (i.e., not a contractor) as specified by coverage policy or program. |
FLY
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | family coverage |
**Description:**As specified by coverage policy or program. |
IND
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | individual |
**Description:**Person as specified by coverage policy or program. |
SSP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | same sex partner |
**Description:**A pair of people of the same gender who live together as a family as specified by coverage policy or program, e.g., Naomi and Ruth from the Book of Ruth; Socrates and Alcibiades |
_CoverageItemLimitObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | CoverageItemLimitObservationValue |
**Description:**Coded observation values for types or instances of items for which coverage is provided under a policy or program, e.g., a type of vehicle or a named work of art. |
_CoverageLocationLimitObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | CoverageLocationLimitObservationValue |
**Description:**Coded observation values for types or instances of locations for which coverage is provided under a policy or program, e.g., in the covered party home, in state or in the country. |
_CriticalityObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | CriticalityObservationValue |
A clinical judgment as to the worst case result of a future exposure (including substance administration). When the worst case result is assessed to have a life-threatening or organ system threatening potential, it is considered to be of high criticality. |
CRITH
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | high criticality |
Worst case result of a future exposure is assessed to be life-threatening or having high potential for organ system failure. |
CRITL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | low criticality |
Worst case result of a future exposure is not assessed to be life-threatening or having high potential for organ system failure. |
CRITU
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | unable to assess criticality |
Unable to assess the worst case result of a future exposure. |
_EmploymentStatus
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | _EmploymentStatus |
Concepts representing whether a person does or does not currently have a job or is not currently in the labor pool seeking employment. |
Employed
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Employed |
Individuals who, during the last week: a) did any work for at least 1 hour as paid or unpaid employees of a business or government organization; worked in their own businesses, professions, or on their own farms; or b) were not working, but who have a job or business from which the individual was temporarily absent because of vacation, illness, bad weather, childcare problems, maternity or paternity leave, labor-management dispute, job training, or other family or personal reasons, regardless of whether or not they were paid for the time off or were seeking other jobs. |
NotInLaborForce
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Not In Labor Force |
Persons not classified as employed or unemployed, meaning those who have no job and are not looking for one. |
Unemployed
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Unemployed |
Persons who currently have no employment, but are available for work and have made specific efforts to find employment. |
_GeneticObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | GeneticObservationValue |
Description: The domain contains genetic analysis specific observation values, e.g. Homozygote, Heterozygote, etc. |
Homozygote
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | HOMO |
Description: An individual having different alleles at one or more loci regarding a specific character |
_MeasurementImprovementNotation
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Measurement Improvement Notation |
Observation values that indicate what change in a measurement value or score is indicative of an improvement in the measured item or scored issue. |
DecrIsImp
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Decreased score indicates improvement |
Improvement is indicated as a decrease in the score or measurement (e.g. Lower score indicates better quality) |
IncrIsImp
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Increased score indicates improvement |
Improvement is indicated as an increase in the score or measurement (e.g. Higher score indicates better quality) |
_ObservationMeasureScoring
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | ObservationMeasureScoring |
Observation values used to indicate the type of scoring (e.g. proportion, ratio) used by a health quality measure. |
COHORT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | cohort measure scoring |
A measure in which either short-term cross-section or long-term longitudinal analysis is performed over a group of subjects defined by a set of common properties or defining characteristics (e.g., Male smokers between the ages of 40 and 50 years, exposure to treatment, exposure duration). |
CONTVAR
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | continuous variable measure scoring |
A measure score in which each individual value for the measure can fall anywhere along a continuous scale (e.g., mean time to thrombolytics which aggregates the time in minutes from a case presenting with chest pain to the time of administration of thrombolytics). |
PROPOR
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | proportion measure scoring |
A score derived by dividing the number of cases that meet a criterion for quality (the numerator) by the number of eligible cases within a given time frame (the denominator) where the numerator cases are a subset of the denominator cases (e.g., percentage of eligible women with a mammogram performed in the last year). |
RATIO
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | ratio measure scoring |
A score that may have a value of zero or greater that is derived by dividing a count of one type of data by a count of another type of data (e.g., the number of patients with central lines who develop infection divided by the number of central line days). |
_ObservationMeasureType
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | ObservationMeasureType |
Observation values used to indicate what kind of health quality measure is used. |
COMPOSITE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | composite measure type |
A measure that is composed from one or more other measures and indicates an overall summary of those measures. |
EFFICIENCY
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | efficiency measure type |
A measure related to the efficiency of medical treatment. |
EXPERIENCE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | experience measure type |
A measure related to the level of patient engagement or patient experience of care. |
OUTCOME
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | outcome measure type |
A measure that indicates the result of the performance (or non-performance) of a function or process. |
INTERM-OM
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | intermediate clinical outcome measure |
A measure that evaluates the change over time of a physiologic state observable that is associated with a specific long-term health outcome. |
PRO-PM
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | patient reported outcome performance measure |
A measure that is a comparison of patient reported outcomes for a single or multiple patients collected via an instrument specifically designed to obtain input directly from patients. |
PROCESS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | process measure type |
A measure which focuses on a process which leads to a certain outcome, meaning that a scientific basis exists for believing that the process, when executed well, will increase the probability of achieving a desired outcome. |
APPROPRIATE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | appropriate use process measure |
A measure that assesses the use of one or more processes where the expected health benefit exceeds the expected negative consequences. |
RESOURCE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | resource use measure type |
A measure related to the extent of use of clinical resources or cost of care. |
STRUCTURE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | structure measure type |
A measure related to the structure of patient care. |
_ObservationPopulationInclusion
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | ObservationPopulationInclusion |
Observation values used to assert various populations that a subject falls into. |
DENEX
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | denominator exclusions |
Patients who should be removed from the eMeasure population and denominator before determining if numerator criteria are met. Denominator exclusions are used in proportion and ratio measures to help narrow the denominator. |
DENEXCEP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | denominator exceptions |
Denominator
exceptions
are
those
conditions
that
should
remove
a
patient,
procedure
or
unit
of
measurement
from
the
denominator
only
if
the
numerator
criteria
are
not
met.
Denominator
exceptions
allow
for
adjustment
of
the
calculated
score
for
those
providers
with
higher
risk
populations.
Denominator
exceptions
are
used
only
in
proportion
eMeasures.
They
are
not
appropriate
for
ratio
or
continuous
variable
eMeasures.
Denominator
exceptions
allow
for
the
exercise
of
clinical
judgment
and
should
be
specifically
defined
where
capturing
the
information
in
a
structured
manner
fits
the
clinical
workflow.
Generic
denominator
exception
reasons
used
in
proportion
eMeasures
fall
into
three
general
categories:
|
DENOM
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | denominator |
It can be the same as the initial patient population or a subset of the initial patient population to further constrain the population for the purpose of the eMeasure. Different measures within an eMeasure set may have different Denominators. Continuous Variable eMeasures do not have a Denominator, but instead define a Measure Population. |
IP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | initial population |
The initial population refers to all entities to be evaluated by a specific quality measure who share a common set of specified characteristics within a specific measurement set to which a given measure belongs. |
IPP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | initial patient population |
The initial patient population refers to all patients to be evaluated by a specific quality measure who share a common set of specified characteristics within a specific measurement set to which a given measure belongs. Details often include information based upon specific age groups, diagnoses, diagnostic and procedure codes, and enrollment periods. |
MSRPOPL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | measure population |
Measure population is used only in continuous variable eMeasures. It is a narrative description of the eMeasure population. (e.g., all patients seen in the Emergency Department during the measurement period). |
NUMER
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | numerator |
Numerators are used in proportion and ratio eMeasures. In proportion measures the numerator criteria are the processes or outcomes expected for each patient, procedure, or other unit of measurement defined in the denominator. In ratio measures the numerator is related, but not directly derived from the denominator (e.g., a numerator listing the number of central line blood stream infections and a denominator indicating the days per thousand of central line usage in a specific time period). |
NUMEX
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | numerator exclusions |
Numerator Exclusions are used only in ratio eMeasures to define instances that should not be included in the numerator data. (e.g., if the number of central line blood stream infections per 1000 catheter days were to exclude infections with a specific bacterium, that bacterium would be listed as a numerator exclusion.) |
_PartialCompletionScale
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | PartialCompletionScale |
|
G
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Great extent |
Value for Act.partialCompletionCode attribute that implies 81-99% completion |
LE
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Large extent |
Value for Act.partialCompletionCode attribute that implies 61-80% completion |
ME
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Medium extent |
Value for Act.partialCompletionCode attribute that implies 41-60% completion |
MI
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Minimal extent |
Value for Act.partialCompletionCode attribute that implies 1-20% completion |
N
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | None |
Value for Act.partialCompletionCode attribute that implies 0% completion |
S
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Some extent |
Value for Act.partialCompletionCode attribute that implies 21-40% completion |
_SecurityObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | SecurityObservationValue |
Observation values used to indicate security observation metadata. |
_SECCATOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | security category |
Abstract
security
observation
values
used
to
indicate
security
category
metadata.
Examples:
Codes
conveying:
|
_SECCLASSOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | security classification |
Abstract
security
observation
values
used
to
indicate
security
classification
metadata.
Examples: Confidentiality Codes |
_SECCONOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | security control |
Abstract
security
observation
values
used
to
indicate
security
control
metadata.
Examples: Codes conveying dissemination controls, information handling caveats, purpose of use, refrain policies, and obligations to which custodians and information receivers must comply. |
_SECINTOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | security integrity |
Abstract
security
observation
values
used
to
indicate
security
integrity
metadata.
Examples: Codes conveying integrity status, integrity confidence, and provenance. |
SECTRSTOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | security trust observation |
Observation value used to indicate aspects of trust applicable to an IT resource (data, information object, service, or system capability). |
TRSTACCRDOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | trust accreditation observation |
Values for security trust accreditation metadata observation made about the formal declaration by an authority or neutral third party that validates the technical, security, trust, and business practice conformance of Trust Agents to facilitate security, interoperability, and trust among participants within a security domain or trust framework. |
TRSTAGREOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | trust agreement observation |
Values
for
security
trust
agreement
metadata
observation
made
about
privacy
and
security
requirements
with
which
a
security
domain
must
comply.
|
TRSTCERTOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | trust certificate observation |
Values
for
security
trust
certificate
metadata
observation
made
about
a
set
of
security-relevant
data
issued
by
a
security
authority
or
trusted
third
party,
together
with
security
information
which
is
used
to
provide
the
integrity
and
data
origin
authentication
services
for
an
IT
resource
(data,
information
object,
service,
or
system
capability).
For example, a Certificate Policy (CP), which is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. A particular Certificate Policy might indicate the applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. Another example is Cross Certification with Federal Bridge. |
TRSTFWKOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | none supplied 5 |
Values
for
security
trust
framework
metadata
observation
made
about
a
complete
set
of
contracts,
regulations
or
commitments
that
enable
participating
actors
to
rely
on
certain
assertions
by
other
actors
to
fulfill
their
information
security
requirements.
|
TRSTLOAOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | trust assurance observation |
Values for security trust assurance metadata observation made about the digital quality or reliability of a trust assertion, activity, capability, information exchange, mechanism, process, or protocol. |
LOAAN
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | authentication level of assurance value |
The
value
assigned
as
the
indicator
of
the
digital
quality
or
reliability
of
the
verification
and
validation
process
used
to
verify
the
claimed
identity
of
an
entity
by
securely
associating
an
identifier
and
its
authenticator.
For
example,
the
degree
of
confidence
in
the
vetting
process
used
to
establish
the
identity
of
the
individual
to
whom
the
credential
was
issued,
and
2)
the
degree
of
confidence
that
the
individual
who
uses
the
credential
is
the
individual
to
whom
the
credential
was
issued.
|
LOAAN1
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | low authentication level of assurance |
Indicator
of
low
digital
quality
or
reliability
of
the
digital
reliability
of
the
verification
and
validation
process
used
to
verify
the
claimed
identity
of
an
entity
by
securely
associating
an
identifier
and
its
authenticator.
The
degree
of
confidence
in
the
vetting
process
used
to
establish
the
identity
of
the
individual
to
whom
the
credential
was
issued,
and
2)
the
degree
of
confidence
that
the
individual
who
uses
the
credential
is
the
individual
to
whom
the
credential
was
issued.
Low
authentication
level
of
assurance
indicates
that
the
relying
party
may
have
little
or
no
confidence
in
the
asserted
identity's
validity.
Level
1
requires
little
or
no
confidence
in
the
asserted
identity.
No
identity
proofing
is
required
at
this
level,
but
the
authentication
mechanism
should
provide
some
assurance
that
the
same
claimant
is
accessing
the
protected
transaction
or
data.
A
wide
range
of
available
authentication
technologies
can
be
employed
and
any
of
the
token
methods
of
Levels
2,
3,
or
4,
including
Personal
Identification
Numbers
(PINs),
may
be
used.
To
be
authenticated,
the
claimant
must
prove
control
of
the
token
through
a
secure
authentication
protocol.
At
Level
1,
long-term
shared
authentication
secrets
may
be
revealed
to
verifiers.
Assertions
issued
about
claimants
as
a
result
of
a
successful
authentication
are
either
cryptographically
authenticated
by
relying
parties
(using
approved
methods)
or
are
obtained
directly
from
a
trusted
party
via
a
secure
authentication
protocol.
|
LOAAN2
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | basic authentication level of assurance |
Indicator
of
basic
digital
quality
or
reliability
of
the
digital
reliability
of
the
verification
and
validation
process
used
to
verify
the
claimed
identity
of
an
entity
by
securely
associating
an
identifier
and
its
authenticator.
The
degree
of
confidence
in
the
vetting
process
used
to
establish
the
identity
of
the
individual
to
whom
the
credential
was
issued,
and
2)
the
degree
of
confidence
that
the
individual
who
uses
the
credential
is
the
individual
to
whom
the
credential
was
issued.
Basic
authentication
level
of
assurance
indicates
that
the
relying
party
may
have
some
confidence
in
the
asserted
identity's
validity.
Level
2
requires
confidence
that
the
asserted
identity
is
accurate.
Level
2
provides
for
single-factor
remote
network
authentication,
including
identity-proofing
requirements
for
presentation
of
identifying
materials
or
information.
A
wide
range
of
available
authentication
technologies
can
be
employed,
including
any
of
the
token
methods
of
Levels
3
or
4,
as
well
as
passwords.
Successful
authentication
requires
that
the
claimant
prove
through
a
secure
authentication
protocol
that
the
claimant
controls
the
token.
Eavesdropper,
replay,
and
online
guessing
attacks
are
prevented.
Long-term
shared
authentication
secrets,
if
used,
are
never
revealed
to
any
party
except
the
claimant
and
verifiers
operated
by
the
CSP;
however,
session
(temporary)
shared
secrets
may
be
provided
to
independent
verifiers
by
the
CSP.
Approved
cryptographic
techniques
are
required.
Assertions
issued
about
claimants
as
a
result
of
a
successful
authentication
are
either
cryptographically
authenticated
by
relying
parties
(using
approved
methods)
or
are
obtained
directly
from
a
trusted
party
via
a
secure
authentication
protocol.
|
LOAAN3
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | medium authentication level of assurance |
Indicator
of
medium
digital
quality
or
reliability
of
the
digital
reliability
of
verification
and
validation
of
the
process
used
to
verify
the
claimed
identity
of
an
entity
by
securely
associating
an
identifier
and
its
authenticator.
The
degree
of
confidence
in
the
vetting
process
used
to
establish
the
identity
of
the
individual
to
whom
the
credential
was
issued,
and
2)
the
degree
of
confidence
that
the
individual
who
uses
the
credential
is
the
individual
to
whom
the
credential
was
issued.
Medium
authentication
level
of
assurance
indicates
that
the
relying
party
may
have
high
confidence
in
the
asserted
identity's
validity.
Level
3
is
appropriate
for
transactions
that
need
high
confidence
in
the
accuracy
of
the
asserted
identity.
Level
3
provides
multifactor
remote
network
authentication.
At
this
level,
identity-proofing
procedures
require
verification
of
identifying
materials
and
information.
Authentication
is
based
on
proof
of
possession
of
a
key
or
password
through
a
cryptographic
protocol.
Cryptographic
strength
mechanisms
should
protect
the
primary
authentication
token
(a
cryptographic
key)
against
compromise
by
the
protocol
threats,
including
eavesdropper,
replay,
online
guessing,
verifier
impersonation,
and
man-in-the-middle
attacks.
A
minimum
of
two
authentication
factors
is
required.
Three
kinds
of
tokens
may
be
used:
Authentication
requires
that
the
claimant
prove
control
of
the
token
through
a
secure
authentication
protocol.
The
token
must
be
unlocked
with
a
password
or
biometric
representation,
or
a
password
must
be
used
in
a
secure
authentication
protocol,
to
establish
two-factor
authentication.
Long-term
shared
authentication
secrets,
if
used,
are
never
revealed
to
any
party
except
the
claimant
and
verifiers
operated
directly
by
the
CSP;
however,
session
(temporary)
shared
secrets
may
be
provided
to
independent
verifiers
by
the
CSP.
Approved
cryptographic
techniques
are
used
for
all
operations.
Assertions
issued
about
claimants
as
a
result
of
a
successful
authentication
are
either
cryptographically
authenticated
by
relying
parties
(using
approved
methods)
or
are
obtained
directly
from
a
trusted
party
via
a
secure
authentication
protocol.
|
LOAAN4
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | high authentication level of assurance |
Indicator
of
high
digital
quality
or
reliability
of
the
digital
reliability
of
the
verification
and
validation
process
used
to
verify
the
claimed
identity
of
an
entity
by
securely
associating
an
identifier
and
its
authenticator.
The
degree
of
confidence
in
the
vetting
process
used
to
establish
the
identity
of
the
individual
to
whom
the
credential
was
issued,
and
2)
the
degree
of
confidence
that
the
individual
who
uses
the
credential
is
the
individual
to
whom
the
credential
was
issued.
High authentication level of assurance indicates that the relying party may have very high confidence in the asserted identity's validity. Level 4 is for transactions that need very high confidence in the accuracy of the asserted identity. Level 4 provides the highest practical assurance of remote network authentication. Authentication is based on proof of possession of a key through a cryptographic protocol. This level is similar to Level 3 except that only “hard� cryptographic tokens are allowed, cryptographic module validation requirements are strengthened, and subsequent critical data transfers must be authenticated via a key that is bound to the authentication process. The token should be a hardware cryptographic module validated at FIPS 140-2 Level 2 or higher overall with at least FIPS 140-2 Level 3 physical security. This level requires a physical token, which cannot readily be copied, and operator authentication at Level 2 and higher, and ensures good, two-factor remote authentication.
Level
4
requires
strong
cryptographic
authentication
of
all
parties
and
all
sensitive
data
transfers
between
the
parties.
Either
public
key
or
symmetric
key
technology
may
be
used.
Authentication
requires
that
the
claimant
prove
through
a
secure
authentication
protocol
that
the
claimant
controls
the
token.
Eavesdropper,
replay,
online
guessing,
verifier
impersonation,
and
man-in-the-middle
attacks
are
prevented.
Long-term
shared
authentication
secrets,
if
used,
are
never
revealed
to
any
party
except
the
claimant
and
verifiers
operated
directly
by
the
CSP;
however,
session
(temporary)
shared
secrets
may
be
provided
to
independent
verifiers
by
the
CSP.
Strong
approved
cryptographic
techniques
are
used
for
all
operations.
All
sensitive
data
transfers
are
cryptographically
authenticated
using
keys
bound
to
the
authentication
process.
|
LOAAP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | authentication process level of assurance value |
The
value
assigned
as
the
indicator
of
the
digital
quality
or
reliability
of
a
defined
sequence
of
messages
between
a
Claimant
and
a
Verifier
that
demonstrates
that
the
Claimant
has
possession
and
control
of
a
valid
token
to
establish
his/her
identity,
and
optionally,
demonstrates
to
the
Claimant
that
he
or
she
is
communicating
with
the
intended
Verifier.
|
LOAAP1
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | low authentication process level of assurance |
Indicator
of
the
low
digital
quality
or
reliability
of
a
defined
sequence
of
messages
between
a
Claimant
and
a
Verifier
that
demonstrates
that
the
Claimant
has
possession
and
control
of
a
valid
token
to
establish
his/her
identity,
and
optionally,
demonstrates
to
the
Claimant
that
he
or
she
is
communicating
with
the
intended
Verifier.
Low
authentication
process
level
of
assurance
indicates
that
(1)
long-term
shared
authentication
secrets
may
be
revealed
to
verifiers;
and
(2)
assertions
and
assertion
references
require
protection
from
manufacture/modification
and
reuse
attacks.
|
LOAAP2
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | basic authentication process level of assurance |
Indicator
of
the
basic
digital
quality
or
reliability
of
a
defined
sequence
of
messages
between
a
Claimant
and
a
Verifier
that
demonstrates
that
the
Claimant
has
possession
and
control
of
a
valid
token
to
establish
his/her
identity,
and
optionally,
demonstrates
to
the
Claimant
that
he
or
she
is
communicating
with
the
intended
Verifier.
Basic
authentication
process
level
of
assurance
indicates
that
long-term
shared
authentication
secrets
are
never
revealed
to
any
other
party
except
Credential
Service
Provider
(CSP).
Sessions
(temporary)
shared
secrets
may
be
provided
to
independent
verifiers
by
CSP.
Long-term
shared
authentication
secrets,
if
used,
are
never
revealed
to
any
other
party
except
Verifiers
operated
by
the
Credential
Service
Provider
(CSP);
however,
session
(temporary)
shared
secrets
may
be
provided
to
independent
Verifiers
by
the
CSP.
In
addition
to
Level
1
requirements,
assertions
are
resistant
to
disclosure,
redirection,
capture
and
substitution
attacks.
Approved
cryptographic
techniques
are
required.
|
LOAAP3
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | medium authentication process level of assurance |
Indicator
of
the
medium
digital
quality
or
reliability
of
a
defined
sequence
of
messages
between
a
Claimant
and
a
Verifier
that
demonstrates
that
the
Claimant
has
possession
and
control
of
a
valid
token
to
establish
his/her
identity,
and
optionally,
demonstrates
to
the
Claimant
that
he
or
she
is
communicating
with
the
intended
Verifier.
Medium authentication process level of assurance indicates that the token can be unlocked with password, biometric, or uses a secure multi-token authentication protocol to establish two-factor authentication. Long-term shared authentication secrets are never revealed to any party except the Claimant and Credential Service Provider (CSP). Authentication requires that the Claimant prove, through a secure authentication protocol, that he or she controls the token. The Claimant unlocks the token with a password or biometric, or uses a secure multi-token authentication protocol to establish two-factor authentication (through proof of possession of a physical or software token in combination with some memorized secret knowledge). Long-term shared authentication secrets, if used, are never revealed to any party except the Claimant and Verifiers operated directly by the CSP; however, session (temporary) shared secrets may be provided to independent Verifiers by the CSP. In addition to Level 2 requirements, assertions are protected against repudiation by the Verifier. |
LOAAP4
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | high authentication process level of assurance |
Indicator
of
the
high
digital
quality
or
reliability
of
a
defined
sequence
of
messages
between
a
Claimant
and
a
Verifier
that
demonstrates
that
the
Claimant
has
possession
and
control
of
a
valid
token
to
establish
his/her
identity,
and
optionally,
demonstrates
to
the
Claimant
that
he
or
she
is
communicating
with
the
intended
Verifier.
High
authentication
process
level
of
assurance
indicates
all
sensitive
data
transfer
are
cryptographically
authenticated
using
keys
bound
to
the
authentication
process.
Level
4
requires
strong
cryptographic
authentication
of
all
communicating
parties
and
all
sensitive
data
transfers
between
the
parties.
Either
public
key
or
symmetric
key
technology
may
be
used.
Authentication
requires
that
the
Claimant
prove
through
a
secure
authentication
protocol
that
he
or
she
controls
the
token.
All
protocol
threats
at
Level
3
are
required
to
be
prevented
at
Level
4.
Protocols
shall
also
be
strongly
resistant
to
man-in-the-middle
attacks.
Long-term
shared
authentication
secrets,
if
used,
are
never
revealed
to
any
party
except
the
Claimant
and
Verifiers
operated
directly
by
the
CSP;
however,
session
(temporary)
shared
secrets
may
be
provided
to
independent
Verifiers
by
the
CSP.
Approved
cryptographic
techniques
are
used
for
all
operations.
All
sensitive
data
transfers
are
cryptographically
authenticated
using
keys
bound
to
the
authentication
process.
|
LOAAS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | assertion level of assurance value |
The value assigned as the indicator of the high quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes. |
LOAAS1
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | low assertion level of assurance |
Indicator of the low quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes.
Assertions
and
assertion
references
require
protection
from
modification
and
reuse
attacks.
|
LOAAS2
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | basic assertion level of assurance |
Indicator of the basic quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes.
Assertions
are
resistant
to
disclosure,
redirection,
capture
and
substitution
attacks.
Approved
cryptographic
techniques
are
required
for
all
assertion
protocols.
|
LOAAS3
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | medium assertion level of assurance |
Indicator of the medium quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes.
Assertions
are
protected
against
repudiation
by
the
verifier.
|
LOAAS4
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | high assertion level of assurance |
Indicator of the high quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes.
Strongly
resistant
to
man-in-the-middle
attacks.
"Bearer"
assertions
are
not
used.
"Holder-of-key"
assertions
may
be
used.
RP
maintains
records
of
the
assertions.
|
LOACM
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | token and credential management level of assurance value) |
Indicator
of
the
digital
quality
or
reliability
of
the
activities
performed
by
the
Credential
Service
Provider
(CSP)
subsequent
to
electronic
authentication
registration,
identity
proofing
and
issuance
activities
to
manage
and
safeguard
the
integrity
of
an
issued
credential
and
its
binding
to
an
identity.
|
LOACM1
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | low token and credential management level of assurance |
Indicator
of
the
low
digital
quality
or
reliability
of
the
activities
performed
by
the
Credential
Service
Provider
(CSP)
subsequent
to
electronic
authentication
registration,
identity
proofing
and
issuance
activities
to
manage
and
safeguard
the
integrity
of
an
issued
credential
and
its
binding
to
an
identity.
Little
or
no
confidence
that
an
individual
has
maintained
control
over
a
token
that
has
been
entrusted
to
him
or
her
and
that
that
token
has
not
been
compromised.
Characteristics
include
weak
identity
binding
to
tokens
and
plaintext
passwords
or
secrets
not
transmitted
across
a
network.
|
LOACM2
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | basic token and credential management level of assurance |
Indicator
of
the
basic
digital
quality
or
reliability
of
the
activities
performed
by
the
Credential
Service
Provider
(CSP)
subsequent
to
electronic
authentication
registration,
identity
proofing
and
issuance
activities
to
manage
and
safeguard
the
integrity
of
an
issued
credential
and
its
binding
to
an
identity.
Some
confidence
that
an
individual
has
maintained
control
over
a
token
that
has
been
entrusted
to
him
or
her
and
that
that
token
has
not
been
compromised.
Characteristics
include:
Verification
must
prove
claimant
controls
the
token;
token
resists
online
guessing,
replay,
session
hijacking,
and
eavesdropping
attacks;
and
token
is
at
least
weakly
resistant
to
man-in-the
middle
attacks.
|
LOACM3
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | medium token and credential management level of assurance |
Indicator
of
the
medium
digital
quality
or
reliability
of
the
activities
performed
by
the
Credential
Service
Provider
(CSP)
subsequent
to
electronic
authentication
registration,
identity
proofing
and
issuance
activities
to
manage
and
safeguard
the
integrity
of
an
issued
credential
and
it’s
binding
to
an
identity.
High
confidence
that
an
individual
has
maintained
control
over
a
token
that
has
been
entrusted
to
him
or
her
and
that
that
token
has
not
been
compromised.
Characteristics
include:
Ownership
of
token
verifiable
through
security
authentication
protocol
and
credential
management
protects
against
verifier
impersonation
attacks.
|
LOACM4
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | high token and credential management level of assurance |
Indicator
of
the
high
digital
quality
or
reliability
of
the
activities
performed
by
the
Credential
Service
Provider
(CSP)
subsequent
to
electronic
authentication
registration,
identity
proofing
and
issuance
activities
to
manage
and
safeguard
the
integrity
of
an
issued
credential
and
it’s
binding
to
an
identity.
Very
high
confidence
that
an
individual
has
maintained
control
over
a
token
that
has
been
entrusted
to
him
or
her
and
that
that
token
has
not
been
compromised.
Characteristics
include:
Verifier
can
prove
control
of
token
through
a
secure
protocol;
credential
management
supports
strong
cryptographic
authentication
of
all
communication
parties.
|
LOAID
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | identity proofing level of assurance |
Indicator of the quality or reliability in the process of ascertaining that an individual is who he or she claims to be. |
LOAID1
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | low identity proofing level of assurance |
Indicator
of
low
digital
quality
or
reliability
in
the
process
of
ascertaining
that
an
individual
is
who
he
or
she
claims
to
be.
Requires
that
a
continuity
of
identity
be
maintained
but
does
not
require
identity
proofing.
|
LOAID2
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | basic identity proofing level of assurance |
Indicator
of
some
digital
quality
or
reliability
in
the
process
of
ascertaining
that
that
an
individual
is
who
he
or
she
claims
to
be.
Requires
identity
proofing
via
presentation
of
identifying
material
or
information.
|
LOAID3
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | medium identity proofing level of assurance |
Indicator
of
high
digital
quality
or
reliability
in
the
process
of
ascertaining
that
an
individual
is
who
he
or
she
claims
to
be.
Requires
identity
proofing
procedures
for
verification
of
identifying
materials
and
information.
|
LOAID4
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | high identity proofing level of assurance |
Indicator
of
high
digital
quality
or
reliability
in
the
process
of
ascertaining
that
an
individual
is
who
he
or
she
claims
to
be.
Requires
identity
proofing
procedures
for
verification
of
identifying
materials
and
information.
|
LOANR
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | non-repudiation level of assurance value |
Indicator
of
the
digital
quality
or
reliability
in
the
process
of
establishing
proof
of
delivery
and
proof
of
origin.
|
LOANR1
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | low non-repudiation level of assurance |
Indicator
of
low
digital
quality
or
reliability
in
the
process
of
establishing
proof
of
delivery
and
proof
of
origin.
|
LOANR2
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | basic non-repudiation level of assurance |
Indicator
of
basic
digital
quality
or
reliability
in
the
process
of
establishing
proof
of
delivery
and
proof
of
origin.
|
LOANR3
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | medium non-repudiation level of assurance |
Indicator
of
medium
digital
quality
or
reliability
in
the
process
of
establishing
proof
of
delivery
and
proof
of
origin.
|
LOANR4
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | high non-repudiation level of assurance |
Indicator
of
high
digital
quality
or
reliability
in
the
process
of
establishing
proof
of
delivery
and
proof
of
origin.
|
LOARA
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | remote access level of assurance value |
Indicator
of
the
digital
quality
or
reliability
of
the
information
exchange
between
network-connected
devices
where
the
information
cannot
be
reliably
protected
end-to-end
by
a
single
organization’s
security
controls.
|
LOARA1
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | low remote access level of assurance |
Indicator
of
low
digital
quality
or
reliability
of
the
information
exchange
between
network-connected
devices
where
the
information
cannot
be
reliably
protected
end-to-end
by
a
single
organization’s
security
controls.
|
LOARA2
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | basic remote access level of assurance |
Indicator
of
basic
digital
quality
or
reliability
of
the
information
exchange
between
network-connected
devices
where
the
information
cannot
be
reliably
protected
end-to-end
by
a
single
organization’s
security
controls.
|
LOARA3
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | medium remote access level of assurance |
Indicator
of
medium
digital
quality
or
reliability
of
the
information
exchange
between
network-connected
devices
where
the
information
cannot
be
reliably
protected
end-to-end
by
a
single
organization’s
security
controls.
|
LOARA4
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | high remote access level of assurance |
Indicator
of
high
digital
quality
or
reliability
of
the
information
exchange
between
network-connected
devices
where
the
information
cannot
be
reliably
protected
end-to-end
by
a
single
organization's
security
controls.
|
LOATK
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | token level of assurance value |
Indicator
of
the
digital
quality
or
reliability
of
single
and
multi-token
authentication.
|
LOATK1
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | low token level of assurance |
Indicator
of
the
low
digital
quality
or
reliability
of
single
and
multi-token
authentication.
Permits
the
use
of
any
of
the
token
methods
of
Levels
2,
3,
or
4.
|
LOATK2
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | basic token level of assurance |
Indicator
of
the
basic
digital
quality
or
reliability
of
single
and
multi-token
authentication.
Requires
single
factor
authentication
using
memorized
secret
tokens,
pre-registered
knowledge
tokens,
look-up
secret
tokens,
out
of
band
tokens,
or
single
factor
one-time
password
devices.
|
LOATK3
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | medium token level of assurance |
Indicator
of
the
medium
digital
quality
or
reliability
of
single
and
multi-token
authentication.
Requires
two
authentication
factors.
Provides
multi-factor
remote
network
authentication.
Permits
multi-factor
software
cryptographic
token.
|
LOATK4
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | high token level of assurance |
Indicator
of
the
high
digital
quality
or
reliability
of
single
and
multi-token
authentication.
Requires
token
that
is
a
hardware
cryptographic
module
validated
at
validated
at
Federal
Information
Processing
Standard
(FIPS)
140-2
Level
2
or
higher
overall
with
at
least
FIPS
140-2
Level
3
physical
security.
Level
4
token
requirements
can
be
met
by
using
the
PIV
authentication
key
of
a
FIPS
201
compliant
Personal
Identity
Verification
(PIV)
Card.
|
TRSTMECOBV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | none supplied 6 |
Values for security trust mechanism metadata observation made about a security architecture system component that supports enforcement of security policies. |
_SeverityObservation
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | SeverityObservation |
Potential values for observations of severity. |
H
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | High |
Indicates the condition may be life-threatening or has the potential to cause permanent injury. |
L
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Low |
Indicates the condition may result in some adverse consequences but is unlikely to substantially affect the situation of the subject. |
M
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Moderate |
Indicates the condition may result in noticable adverse adverse consequences but is unlikely to be life-threatening or cause permanent injury. |
_SubjectBodyPosition
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | _SubjectBodyPosition |
Contains codes for defining the observed, physical position of a subject, such as during an observation, assessment, collection of a specimen, etc. ECG waveforms and vital signs, such as blood pressure, are two examples where a general, observed position typically needs to be noted. |
LLD
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | left lateral decubitus |
Lying on the left side. |
PRN
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | prone |
Lying with the front or ventral surface downward; lying face down. |
RLD
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | right lateral decubitus |
Lying on the right side. |
SFWL
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Semi-Fowler's |
A semi-sitting position in bed with the head of the bed elevated approximately 45 degrees. |
SIT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | sitting |
Resting the body on the buttocks, typically with upper torso erect or semi erect. |
STN
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | standing |
To be stationary, upright, vertical, on one's legs. |
SUP
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | supine |
|
RTRD
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | reverse trendelenburg |
Lying on the back, on an inclined plane, typically about 30-45 degrees with head raised and feet lowered. |
TRD
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | trendelenburg |
Lying on the back, on an inclined plane, typically about 30-45 degrees, with head lowered and feet raised. |
_VerificationOutcomeValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | verification outcome |
Values
for
observations
of
verification
act
results
Examples: Verified, not verified, verified with warning. |
ACT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | active coverage |
Definition: Coverage is in effect for healthcare service(s) and/or product(s). |
ACTPEND
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | active - pending investigation |
Definition: Coverage is in effect for healthcare service(s) and/or product(s) - Pending Investigation |
ELG
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | eligible |
Definition: Coverage is in effect for healthcare service(s) and/or product(s). |
INACT
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | inactive |
Definition: Coverage is not in effect for healthcare service(s) and/or product(s). |
INPNDINV
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | inactive - pending investigation |
Definition: Coverage is not in effect for healthcare service(s) and/or product(s) - Pending Investigation. |
INPNDUPD
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | inactive - pending eligibility update |
Definition: Coverage is not in effect for healthcare service(s) and/or product(s) - Pending Eligibility Update. |
NELG
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | not eligible |
Definition: Coverage is not in effect for healthcare service(s) and/or product(s). May optionally include reasons for the ineligibility. |
_WorkSchedule
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | _WorkSchedule |
Concepts that describe an individual's typical arrangement of working hours for an occupation. |
DS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | daytime shift |
A person who is scheduled for work during daytime hours (for example between 6am and 6pm) on a regular basis. |
EMS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | early morning shift |
Consistent Early morning schedule of 13 hours or less per shift (between 2 am and 2 pm) |
ES
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | evening shift |
A person who is scheduled for work during evening hours (for example between 2pm and midnight) on a regular basis. |
NS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | night shift |
Scheduled for work during nighttime hours (for example between 9pm and 8am) on a regular basis. |
RSWN
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | rotating shift with nights |
Scheduled for work times that change periodically between days, and/or evenings, and includes some night shifts. |
RSWON
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | rotating shift without nights |
Scheduled for work days/times that change periodically between days, but does not include night or evening work. |
SS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | split shift |
Shift consisting of two distinct work periods each day that are separated by a break of a few hours (for example 2 to 4 hours) |
VLS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | very long shift |
Shifts of 17 or more hours. |
VS
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | variable shift |
Irregular, unpredictable hours scheduled on a short notice (for example, less than 2 day notice): inconsistent schedule, on-call, as needed, as available. |
_AnnotationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | AnnotationValue |
|
_ECGAnnotationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | ECGAnnotationValue |
|
_CommonClinicalObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | common clinical observation |
**Description:**Used in a patient care message to value simple clinical (non-lab) observations. |
_CommonClinicalObservationAssertionValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | CommonClinicalObservationAssertionValue |
Definition: The non-laboratory, non-DI (diagnostic imaging) coded observation if no value is also required to convey the full meaning of the observation. This may be a single concept code or a complex expression. |
_CommonClinicalObservationResultValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | CommonClinicalObservationResultValue |
Definition:
The
non-laboratory,
non-diagnostic
imaging
coded
result
of
the
coded
observable
or
"question"
represented
by
the
paired
concept
from
the
the
NonLabDICodedObservationType
domain.
] **Examples:**An APGAR result, a functional assessment, etc. The value must not require a specific unit of measure. |
_CoverageChemicalDependencyValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | CoverageChemicalDependencyValue |
Definition: The category of addiction used for coverage purposes that may refer to a substance, the consumption of which may result in physical or emotional harm. |
_IndividualCaseSafetyReportValueDomains
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Individual Case Safety Report Value Domains |
This domain is established as a parent to a variety of value domains being defined to support the communication of Individual Case Safety Reports to regulatory bodies. Arguably, this aggregation is not taxonomically pure, but the grouping will facilitate the management of these domains. |
_CaseSeriousnessCriteria
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | CaseSeriousnessCriteria |
A code that provides information on the overall effect or outcome of the adverse reaction/adverse event reported in the ICSR. Note the criterion applies to the case as a whole and not to an individual reaction. Example concepts are: death, disability, hospitalization, congenital anomaly/ birth defect, and other medically important condition. |
_DeviceManufacturerEvaluationInterpretation
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | DeviceManufacturerEvaluationInterpretation |
A code set that includes codes that are used to characterize the outcome of the device evaluation process. The code defines the manufacturer's conclusions following the evaluation. Examples include: inadequate alarms, device maintenance contributed to event, device failed just prior to use, user error caused event |
_DeviceManufacturerEvaluationMethod
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | DeviceManufacturerEvaluationMethod |
Code assigned to indicate a relevant fact within the context of the evaluation of a reported product. There are a number of concept types including the status of the evaluation, the type of evaluation findings, and the type of activity carried out as part of the evaluation process. Examples include: Actual device involved in incident was evaluated, electrical tests performed, visual examination. |
_DeviceManufacturerEvaluationResult
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | DeviceManufacturerEvaluationResult |
Code assigned to indicate an outcome of the manufacturer's investigation of a product for which a defect has been reported. Examples include:.component/subassembly failure: air cleaner, computer-, imaging system-, microprocessor-controlled device problem: cache memory, design -- not fail safe. |
_PertinentReactionRelatedness
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Pertinent Reaction Relatedness |
A code to capture the reporter's assessment of the extent to which the reaction is related to the suspect product reported in the ICSR. Example concepts include: related, not related, possibly related and unlikely related. |
_ProductCharacterization
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Product Characterization |
A code that characterizes the role that the primary reporter felt that the suspect intervention -- either a substance administration or a device related procedure - played in the incident being reported. This code will capture the primary reporter's assessment of the role that the suspect product played in the incident reported in the ICSR. Examples include: Suspect, Concomitant, Interacting, Re-challenge. |
_ReactionActionTaken
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | ReactionActionTaken |
Code used to indicate the action taken by practitioner in response to the problem (whether drug or device related) that is reported in the ICSR. Examples include: failing device replaced, medication stopped, medication dose adjusted. |
_SubjectReaction
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | Subject Reaction |
A code to capture the kind of reaction that was suffered by the investigated subject, and that is being reported in the ICSR. At this point, SNOMED or MedDRA have been suggested as code systems to be used for providing this information. Example concepts include hives, swelling, rash, anaphylactic shock. |
_SubjectReactionEmphasis
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | SubjectReactionEmphasis |
Code that captures the emphasis that the reporter placed on this reaction. Examples include: highlighted by the reporter, NOT serious, Not highlighted by the reporter, NOT serious, Highlighted by the reporter, SERIOUS, Not highlighted by the reporter, SERIOUS. |
_SubjectReactionOutcome
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | SubjectReactionOutcome |
Code that captures the type of outcome from an individual outcome of a reaction to the suspect product reported in the ICSR. Examples include: Recovered/resolved. Recovering/resolving, Not recovered/not resolved, Recovered/resolved with sequelae, Fatal. |
_InjuryObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | InjuryObservationValue |
Values for observations of injuries. |
_IntoleranceValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | IntoleranceValue |
Codes identifying pariticular groupings of allergens and other agents which cause allergies and intolerances. E.g. the drug, allergen group, food or environmental agent which triggers the intolerance |
_IssueTriggerObservationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | IssueTriggerObservationValue |
The combined domain for different types of coded observation issue triggers, such as diagnoses, allergies, etc. |
_OtherIndicationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | OtherIndicationValue |
Indicates an observed reason for a medical action other than an indication or symptom. E.g. Need for a contrast agent prior to a diagnostic image, need for anesthesia prior to surgery, etc. |
_IndicationValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | IndicationValue |
Indicates the specific observation result which is the reason for the action (prescription, lab test, etc.). E.g. Headache, Ear infection, planned diagnostic image (requiring contrast agent), etc. |
_DiagnosisValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | DiagnosisValue |
Diagnosis Value |
_SymptomValue
|
http://terminology.hl7.org/CodeSystem/v3-ObservationValue | SymptomValue |
Indicates an observed abnormality in the patientaTMs condition, but does not assert causation. E.g. Runny nose, swelling, flaky skin, etc. |
_ActUSPrivacyLaw
|
http://terminology.hl7.org/CodeSystem/v3-ActUSPrivacyLaw | ActUSPrivacyLaw |
Definition:
A
jurisdictional
mandate
in
the
U.S.
relating
to
privacy.
Usage Note: ActPrivacyLaw codes may be associated with an Act or a Role to indicate the legal provision to which the assignment of an Act.confidentialityCode or Role.confidentialtyCode complies. May be used to further specify rationale for assignment of other ActPrivacyPolicy codes in the US realm, e.g., ETH and 42CFRPart2 can be differentiated from ETH and Title38Part1. |
42CFRPart2
|
http://terminology.hl7.org/CodeSystem/v3-ActUSPrivacyLaw | 42 CFR Part2 |
42
CFR
Part
2
stipulates
the
right
of
an
individual
who
has
applied
for
or
been
given
diagnosis
or
treatment
for
alcohol
or
drug
abuse
at
a
federally
assisted
program.
Definition:
Non-disclosure
of
health
information
relating
to
health
care
paid
for
by
a
federally
assisted
substance
abuse
program
without
patient
consent.
Usage Note: May be associated with an Act or a Role to indicate the legal provision to which the assignment of an Act.confidentialityCode or Role.confidentialityCode complies. |
CommonRule
|
http://terminology.hl7.org/CodeSystem/v3-ActUSPrivacyLaw | Common Rule |
U.S.
Federal
regulations
governing
the
protection
of
human
subjects
in
research
(codified
at
Subpart
A
of
45
CFR
part
46)
that
has
been
adopted
by
15
U.S.
Federal
departments
and
agencies
in
an
effort
to
promote
uniformity,
understanding,
and
compliance
with
human
subject
protections.
Existing
regulations
governing
the
protection
of
human
subjects
in
Food
and
Drug
Administration
(FDA)-regulated
research
(21
CFR
parts
50,
56,
312,
and
812)
are
separate
from
the
Common
Rule
but
include
similar
requirements.
Definition:
U.S.
federal
laws
governing
research-related
privacy
policies.
Usage Note: May be associated with an Act or a Role to indicate the legal provision to which the assignment of an Act.confidentialityCode or Role.confidentialtyCode complies. |
HIPAANOPP
|
http://terminology.hl7.org/CodeSystem/v3-ActUSPrivacyLaw | HIPAA notice of privacy practices |
The
U.S.
Public
Law
104-191
Health
Insurance
Portability
and
Accountability
Act
(HIPAA)
Privacy
Rule
(45
CFR
Part
164
Subpart
E)
permits
access,
use
and
disclosure
of
certain
personal
health
information
(PHI
as
defined
under
the
law)
for
purposes
of
Treatment,
Payment,
and
Operations,
and
requires
that
the
provider
ask
that
patients
acknowledge
the
Provider's
Notice
of
Privacy
Practices
as
permitted
conduct
under
the
law.
Definition:
Notification
of
HIPAA
Privacy
Practices.
Usage Note: May be associated with an Act or a Role to indicate the legal provision to which the assignment of an Act.confidentialityCode or Role.confidentialtyCode complies. |
HIPAAPsyNotes
|
http://terminology.hl7.org/CodeSystem/v3-ActUSPrivacyLaw | HIPAA psychotherapy notes |
The
U.S.
Public
Law
104-191
Health
Insurance
Portability
and
Accountability
Act
(HIPAA)
Privacy
Rule
(45
CFR
Part
164
Section
164.508)
requires
authorization
for
certain
uses
and
disclosure
of
psychotherapy
notes.
Definition:
Authorization
that
must
be
obtained
for
disclosure
of
psychotherapy
notes.
Usage Note: May be associated with an Act or a Role to indicate the legal provision to which the assignment of an Act.confidentialityCode or Role.confidentialityCode complies. |
HIPAASelfPay
|
http://terminology.hl7.org/CodeSystem/v3-ActUSPrivacyLaw | HIPAA self-pay |
Section
13405(a)
of
the
Health
Information
Technology
for
Economic
and
Clinical
Health
Act
(HITECH)
stipulates
the
right
of
an
individual
to
have
disclosures
regarding
certain
health
care
items
or
services
for
which
the
individual
pays
out
of
pocket
in
full
restricted
from
a
health
plan.
Definition:
Non-disclosure
of
health
information
to
a
health
plan
relating
to
health
care
items
or
services
for
which
an
individual
pays
out
of
pocket
in
full.
Usage Note: May be associated with an Act or a Role to indicate the legal provision to which the assignment of an Act.confidentialityCode or Role.confidentialityCode complies. |
Title38Section7332
|
http://terminology.hl7.org/CodeSystem/v3-ActUSPrivacyLaw | Title 38 Section 7332 |
Title
38
Part
1-protected
information
may
only
be
disclosed
to
a
third
party
with
the
special
written
consent
of
the
patient
except
where
expressly
authorized
by
38
USC
7332.
VA
may
disclose
this
information
for
specific
purposes
to:
VA
employees
on
a
need
to
know
basis
-
more
restrictive
than
Privacy
Act
need
to
know;
contractors
who
need
the
information
in
order
to
perform
or
fulfill
the
duties
of
the
contract;
and
researchers
who
provide
assurances
that
the
information
will
not
be
identified
in
any
report.
This
information
may
also
be
disclosed
without
consent
where
patient
lacks
decision-making
capacity;
in
a
medical
emergency
for
the
purpose
of
treating
a
condition
which
poses
an
immediate
threat
to
the
health
of
any
individual
and
which
requires
immediate
medical
intervention;
for
eye,
tissue,
or
organ
donation
purposes;
and
disclosure
of
HIV
information
for
public
health
purposes.
Definition: Title 38 Part 1 - §1.462 Confidentiality restrictions.
(a)
General.
The
patient
records
to
which
§§1.460
through
1.499
of
this
part
apply
may
be
disclosed
or
used
only
as
permitted
by
these
regulations
and
may
not
otherwise
be
disclosed
or
used
in
any
civil,
criminal,
administrative,
or
legislative
proceedings
conducted
by
any
Federal,
State,
or
local
authority.
Any
disclosure
made
under
these
regulations
must
be
limited
to
that
information
which
is
necessary
to
carry
out
the
purpose
of
the
disclosure.
SUBCHAPTER
III--PROTECTION
OF
PATIENT
RIGHTS
Sec.
7332.
Confidentiality
of
certain
medical
records
(a)(1)
Records
of
the
identity,
diagnosis,
prognosis,
or
treatment
of
any
patient
or
subject
which
are
maintained
in
connection
with
the
performance
of
any
program
or
activity
(including
education,
training,
treatment,
rehabilitation,
or
research)
relating
to
drug
abuse,
alcoholism
or
alcohol
abuse,
infection
with
the
human
immunodeficiency
virus,
or
sickle
cell
anemia
which
is
carried
out
by
or
for
the
Department
under
this
title
shall,
except
as
provided
in
subsections
(e)
and
(f),
be
confidential,
and
(section
5701
of
this
title
to
the
contrary
notwithstanding)
such
records
may
be
disclosed
only
for
the
purposes
and
under
the
circumstances
expressly
authorized
under
subsection
(b).
Usage Note: May be associated with an Act or a Role to indicate the legal provision to which the assignment of an Act.confidentialityCode or Role.confidentialityCode complies. |
Title38Part1
|
http://terminology.hl7.org/CodeSystem/v3-ActUSPrivacyLaw | Title 38 Section 7332 |
Title
38
Part
1-protected
information
may
only
be
disclosed
to
a
third
party
with
the
special
written
consent
of
the
patient
except
where
expressly
authorized
by
38
USC
7332.
VA
may
disclose
this
information
for
specific
purposes
to:
VA
employees
on
a
need
to
know
basis
-
more
restrictive
than
Privacy
Act
need
to
know;
contractors
who
need
the
information
in
order
to
perform
or
fulfill
the
duties
of
the
contract;
and
researchers
who
provide
assurances
that
the
information
will
not
be
identified
in
any
report.
This
information
may
also
be
disclosed
without
consent
where
patient
lacks
decision-making
capacity;
in
a
medical
emergency
for
the
purpose
of
treating
a
condition
which
poses
an
immediate
threat
to
the
health
of
any
individual
and
which
requires
immediate
medical
intervention;
for
eye,
tissue,
or
organ
donation
purposes;
and
disclosure
of
HIV
information
for
public
health
purposes.
Definition: Title 38 Part 1 - §1.462 Confidentiality restrictions.
(a)
General.
The
patient
records
to
which
§§1.460
through
1.499
of
this
part
apply
may
be
disclosed
or
used
only
as
permitted
by
these
regulations
and
may
not
otherwise
be
disclosed
or
used
in
any
civil,
criminal,
administrative,
or
legislative
proceedings
conducted
by
any
Federal,
State,
or
local
authority.
Any
disclosure
made
under
these
regulations
must
be
limited
to
that
information
which
is
necessary
to
carry
out
the
purpose
of
the
disclosure.
SUBCHAPTER
III--PROTECTION
OF
PATIENT
RIGHTS
Sec.
7332.
Confidentiality
of
certain
medical
records
(a)(1)
Records
of
the
identity,
diagnosis,
prognosis,
or
treatment
of
any
patient
or
subject
which
are
maintained
in
connection
with
the
performance
of
any
program
or
activity
(including
education,
training,
treatment,
rehabilitation,
or
research)
relating
to
drug
abuse,
alcoholism
or
alcohol
abuse,
infection
with
the
human
immunodeficiency
virus,
or
sickle
cell
anemia
which
is
carried
out
by
or
for
the
Department
under
this
title
shall,
except
as
provided
in
subsections
(e)
and
(f),
be
confidential,
and
(section
5701
of
this
title
to
the
contrary
notwithstanding)
such
records
may
be
disclosed
only
for
the
purposes
and
under
the
circumstances
expressly
authorized
under
subsection
(b).
Usage Note: May be associated with an Act or a Role to indicate the legal provision to which the assignment of an Act.confidentialityCode or Role.confidentialityCode complies. |
See the full registry of value sets defined as part of FHIR.
Explanation of the columns that may appear on this page:
| Lvl | A few code lists that FHIR defines are hierarchical - each code is assigned a level. For value sets, levels are mostly used to organize codes for user convenience, but may follow code system hierarchy - see Code System for further information |
| Source | The source of the definition of the code (when the value set draws in codes defined elsewhere) |
| Code | The code (used as the code in the resource instance). If the code is in italics, this indicates that the code is not selectable ('Abstract') |
| Display | The display (used in the display element of a Coding ). If there is no display, implementers should not simply display the code, but map the concept into their application |
| Definition | An explanation of the meaning of the concept |
| Comments | Additional notes about how to use the code |