RECOMMENDATION ID1:
Recommendation for HL7 RIM and/or
Vocabulary Changes
For Harmonization During: 11/2011
1
Sponsor’s Draft3:
Sponsored by2: CBCC and Security
Sponsor’s Status4 Pending
Date Approved by Sponsor: October 4, 2011
Editor/ Author: Kathleen Connor
PROPOSALNAME: Refactor Confidentiality concept domain, code system, and value sets
Class Model Change
Datatypes Change
Structural Vocabulary Change
Other Vocabulary Change
SUMMARY RECOMMENDATION
Confidentiality code system and value sets need to be restructured because they do not meet the definition of
Confidentiality concept domain: “Values that control disclosure of information”. Several value sets are related
to access control, which is better handled via participations and roles. Other value sets classify the information
sensitivity, which are policy-based determination of information value and importance, including vulnerability
to adverse effect for unauthorized disclosure. The sensitivity-related value sets should be relocated as ActCodes
specializing ActPolicyType.
VOCABULARY OBJECTS CHANGE SUMMARY
Abbrev.
D
S
C
V
B
Description
Concept Domains
Code Systems
Concept Codes in a Code System
Value Sets
Context Bindings
# to add
# to remove
2
13
4
# to change
1
1
4
3
POSITION OF CONCERNED ORGANIZATIONS:
ORG
RECOMMENDATION APPROVAL STATUS
AFFECTED ELEMENTS OF INTEREST TO ORG
CBCC
October 4, 2011
Entire proposal
ISSUES:
Issue A: Need to separate the interoperable Confidentiality Codes from the non-interoperable
ConfidentialityByInfoType codes, which are bound to a policy domain
The usage notes in the HL7 v.3 Normative Editions previous to 2011 suggest that the Act.confidentialityCode and
Role.confidentialityCode attributes are synonymous with ‘sensitivity.’
At harmonization in 2009, it was agreed that these two concepts are not equivalent per ISO 7498-2:1989 definitions:
1
2
3
4
Identifier by which proposal is known to sponsor
Must be sponsored by an HL7 TC, the HL7 International Committee, an HL7 SIG, or an ANSI or ISO accredited SDO
For sponsor tracking only; not for Harmonization identification
For sponsor tracking only; sponsor’s status must be “Approved” for submission to Harmonization
Page |2

Confidentiality is the property that information is not made available or disclosed to unauthorized individuals, entities,
or processes

Sensitivity is the characteristic of a resource which implies its value or importance and may include its vulnerability.
Note: Vulnerability here is defined as medically vulnerable; subject to social stigmatization
2009Nov_HARM_PR 2009Nov_HARM_CO
OPOSAL_RIM_MNM_w_beeler_ChangeDefinitionOfActConfidentialityCode_20091018223009.doc
VERPAGE_RIM_MNM_w_beeler_AddAttributeActSensitivityCode_20091018223107.doc
Subsequently, the definition of confidentialityCode in the 2011 Normative Edition was changed to read that Confidentiality
attribute on Act (and similarly on Role) can be used to convey both information sensitivity and the information handling
instructions, which are very different concepts.
6.5.15 Act.confidentialityCode :: SET<CE> (0..*)
Conformance constraint: U
Property isDocumentCharacteristic: true
Concept domain: Confidentiality
Definition:
Codes that identify how sensitive a piece of information is and/or that indicate how the information may be made
available or disclosed.
Open Issue:
The definition of this concept needs work in particular to help distinguish and identify the relationship between
the types of concepts that it conveys and how best to encode and communicate them with this one attribute.
The Open Issue indicates that work is required to distinguish and disambiguate the relationship between these two
concepts, and to find a solution to how these should be used given that there is only one attribute.
The HL7 Confidentiality Code Refactoring Project was initiated to develop a solution. One approach considered is to add
an additional attribute for sensitivity to ActClass and RoleClass. Upon further analysis, it was determined that the concept
of information sensitivity is akin to a privacy policy that is based on the evaluation of information importance and
vulnerability to adverse effect of unauthorized disclosure. Application of the policy results in a classification of information
sensitivity. Such a policy governs how information is to be handled, which is conveyed using a Confidentiality Code.
Further, a privacy policy reflects context and interdependency of information, which is difficult to communicate with a
single sensitivity code on a single class. For example, while a medication in and of itself may not be a sensitive piece of
information, in combination with the patient age (e.g., an adolescent), a patient’s role (victim of abuse), and a diagnosis
related to reproductive health, may become, by privacy policy, extremely sensitive.
If sensitivity were an attribute on Acts and Roles, then a document or message communicating this information would
have multiple sensitivity attributes scattered across the classes representing the patient entity, role, medication and
diagnosis. These would have to be collectively evaluated to determine that this information is, for example, governed by
an adolescent sensitive health and abuse-related privacy policy restricting disclosure for adolescent reproductive health
and safeguarding the patient from the abuser.
In addition, this approach would require authorized receivers to evaluate these sensitivity values in precisely the same
manner in order to determine the information handling obligations intended by the sender. This would require complex
point-to-point negotiations that would impede interoperability.
If, in the alternative, the sensitivity values were placed at the header of a document or in the control act wrapper of a
message, then multiple sensitivity attributes would need to be combined to convey the sensitivity of the payload (for
example, adolescent victim of abuse receiving reproductive health medication) or be so vague as to be uninformative, for
example, ‘sensitive adolescent health’.
Last, if sensitivity values are placed on a message or document wrapper to summarize the sensitivity level, then the
protected information would be revealed to unauthorized intermediaries and receivers.
Given that the purpose for tagging Acts and Roles with Confidentiality Codes is to convey information handling protocols
while protecting sensitive information from disclosure, the HL7 Confidentiality Code Refactoring Project concluded that it
Page |3
would be best to restrict the coded values that can be assigned to the Confidentiality attribute to a comprehensive but
limited set of interoperable Confidentiality Codes, which simply convey receivers’ information-handling obligations. These
codes would indicate how the receiver can acquire more detailed information about the information sensitivity and
applicable privacy policies to which the receiver must comply.
In order to communicate information sensitivity and applicable privacy policies that govern the assignment of a
Confidentiality Code on an Act or Role, an ActRelationship “COMPLY” may be associated with an ActClassPolicy, and a
coded concept from the ActPrivacyPolicyType value set could be used to identify the applicable privacy law or sensitivity
classification. A new ActPrivacyPolicyType code system will need to be adopted to fulfill this requirement. Ten of the
codes from current Confidentiality value sets related to sensitivity should be moved into that code system.
Issue B: Conflation of Confidentiality with Sensitive Information Categories
Findings from the HL7 Refactor Confidentiality Code project indicate that the current HL7 Confidentiality concept domain,
code system, and value sets are overloading the coded attributes of confidentiality. The current Confidentiality code
system conflates multiple purposes of access control, information handling protocols, patient roles, and sensitivity
classifications based on policies related to stigmatizing conditions.
Code
Definition
•
ConfidentialityByAccessKind
ConfidentialityModifiers
•
•
•
ConfidentialityByInfoType
A value set that allows access to
information by subject / role and
relationship based rights
These concepts are mutually
exclusive; one and only one
is required for a valid
confidentiality coding.
Modifiers of role-based access
rights
Multiple allowed
•
•
•
Concepts
By information type, only for
service catalog entries
Multiple allowed
Not to be used with actual
patient data!
•
•
•
Information handling protocols
Role-based access control
User-based access control
Patient role
Provider requested sensitivity
Patient requested sensitivity
•
•
•
•
Categories of stigmatized
conditions or patient status
As illustrated below, these “orthogonal” axes are an attempt to “model” relationships among different concept classes with
post-coordination. This enables implementers to change the meaning of the confidentialityCode attribute via the
vocabulary bindings. This results in ambiguous semantics and implementer confusion.
Page |4
As currently structured, it is permissible to combine one value (e.g., Restricted) from ConfidentialityByAccessKind with
multiple coded concepts from the ConfidentialityByInfoType and ConfidentialityModifiers, for example:
Confidentiality
ByAccessKind
Restricted
Clinician
Individual
Definition
ConfidentialityModifiers
Restricted access, e.g. only to
providers having a current care
relationship to the patient.



Celebrity
Taboo
Patient Requested
Only clinicians may see this item;
billing and administration persons
cannot access this item without
special permission.
Access only to individual persons
who are mentioned explicitly as
actors of this service and whose
actor type warrants that access (cf.
to actor type code).



Celebrity
Taboo
Patient Requested



Celebrity
Taboo
Patient Requested
ConfidentialityByInfoTyp
e

HIV

Substance Abuse

Mental Health

Domestic Violence

HIV

Substance Abuse

Mental Health

Domestic Violence

HIV

Substance Abuse

Mental Health

Domestic Violence
However, although there are obvious use cases in which all three of the ConfidentialityByAccessKind codes (Restricted,
Individual, and Clinician) could apply and even overlap, they are not permitted to be used together.
In addition, the “mutual exclusivity constraint”, which limits use to only one ConfidentialityByAccessKind code, is not
computably enforceable. That type of constraint can only be computably enforced by cardinality on the
ConfidentialityCode attribute, and limiting the value set to which that attribute can be bound to a rigorously defined,
representative realm code system as proposed in the Recommendation Section below.
Issue C: Compatibility with intended meaning of the RIM ConfidentialityCode attribute
The definition of the Confidentiality Concept Domain is about information handling protocols to prevent unauthorized
disclosure. The examples listed in the Concept Domain Definition/Description (below) include “substance abuse”, which
is a type of policy governing information sensitivity. The definition is incompatible with the definition of the RIM attribute
confidentialityCode, which was recently changed to reflect issues raised in the 2009 Harmonization Proposals as
discussed above in Issue A. MnM should consider reverting the RIM definition to that used prior to the 2011 Normative
Edition.
Confidentiality
Page |5
Lvl
0
Concept Domain Name
Value Set Binding
RIM Attribute(s)
Confidentiality
Act.confidentialityCode (DSET<CD>)
Confidentiality (R1 as CWE) Role.confidentialityCode (DSET<CD>)
Definition/Description
Definition:
Values that control disclosure of
information.
Example: Normal, restricted, substance
abuse related.
2010 Normative Edition
5.5.15 Act.confidentialityCode :: SET<CE> (0..*)
Conformance constraint: U
Property isDocumentCharacteristic: true
Concept domain: Confidentiality
Definition:
Constraints around appropriate disclosure of information about this Act, regardless of mood.
2011 Normative Edition
.5.15 Act.confidentialityCode :: SET<CE> (0..*)
Conformance constraint: U
Property isDocumentCharacteristic: true
Concept domain: Confidentiality
Definition:
Codes that identify how sensitive a piece of information is and/or that indicate how the information may be made
available or disclosed.
ISSUE SUMMARY
In summary, these issues indicate that the current Confidentiality vocabulary and the definition of the confidentialityCode
are sufficiently discombobulated as to require major overhaul.
CURRENT STATE:
Value sets using code system: Confidentiality [2.16.840.1.113883.5.25]
Confidentiality
ConfidentialityByInfoType
x_BasicConfidentialityKind
ConfidentialityByAccessKind
ConfidentialityModifiers
x_VeryBasicConfidentialityKind
Code
Definition
•
ConfidentialityByAccessKind
ConfidentialityModifiers
ConfidentialityByInfoType
•
A value set that allows access to information by subject / role and
relationship based rights
These concepts are mutually exclusive, one and only one is
required for a valid confidentiality coding)
Modifiers of role based access rights
Multiple allowed
•
•
•
•
•
By information type, only for service catalog entries
Multiple allowed
Not to be used with actual patient data!
Page |6
ConfidentialityByAccessKind mixes role-based and user-based access control values (clinician and individual) with codes
that convey information handling protocols and obligations such as Normal and Restricted. The access control coded
concepts would be better modeled as roles and participations with permitted actions.
ConfidentialityModifiers are codes for policies related to, for example, a patient characteristic that may be the reason why
the information has access control or information handling requirements within policy domains governed by the same
jurisdictional and organizational policies. The actual policy would need to be consulted in order to understand the
semantics. This value set contains only a few of the multitude of similar policy based sensitivity indicators. Others
typically included are employee (which only makes sense within an enterprise); emancipated minor; and provider of
sensitive services.
ConfidentialityByInfoType is an incomplete, non-interoperable sensitive information scheme that might be used within
policy domains governed by the same jurisdictional and organizational policies. Clearly, these are only examples of the
many coded concepts that could be used as stigmatizing conditions and procedures change regularly. One would expect
to see coded concepts for genetic disease and sickle cell disease. The problem is getting consensus across multiple
policy domains about the information objects to which these coded concepts apply.
ConfidentialityModifiers and ConfidentialityByInfoType could be used as metadata for sensitivity classification and data
segmentation purposes internal to a policy domain. This would facilitate the sender’s assignment of interoperable
Confidentiality Codes at exchange time. These should be coded concepts in a code system with context binding to
ActPrivacyPolicyType as a specialization of the ActPolicyType.
OPTIONS CONSIDERED:
Three options have been considered to resolve issues surrounding the Confidentiality code system.
1. Refine the current multi-axial vocabulary by restructuring the Confidentiality code vocabulary and postcoordination rules to meet vocabulary best practices.
2. Create two class attributes on Acts and Roles – one for confidentiality and one for sensitivity, but that results in
the issue discussed above – that sensitivity classifications are inherently non-interoperable because they reflect a
policy domain’s classification of information value and vulnerability to adverse effects resulting in unauthorized
disclosure. This was proposed at the 2009 Harmonization meeting but tabled because of missing information.
2009Nov_HARM_PR
OPOSAL_RIM_SECURE_ioana_singureanu_HL7 RIM Change Sensitivity Code_20091030003236.doc
3. Create separate vocabulary for Confidentiality and Sensitivity, binding the confidentialityCode attribute to the
Confidentiality value set and relocating the Sensitivity concepts under ActPolicyType, which is a specialization of
the ActCode concept domain.
Page |7
RATIONALE:
A key impetus for this project is that Government regulations internationally allow patients to specify finer constraints on
the sharing of their medical records
RECOMMENDATION DETAILS:
The RIM attribute confidentialityCode should be made a Normative Code System with Data Type CS as the proposed HL7
code system is intended to cover all known values that control disclosure of information. The value sets: v:
Confidentiality; x_BasicConfidentialityKind; and v: x_VeryBasicConfidentialityKind should be flagged immutable.5
Summary of Changes:
Changes to ConfidentialityByInfoType and Confidentiality Modifiers:
 Relocated as example policies governing the assignment of confidentiality codes to the ActPrivacyPolicyType
ActCode vocabulary

WRT to Checklist Question 47: If deprecating a value set, have you identified a reason for the deprecation and
provided guidance for what should be used instead? We recommend that where a model is intended to represent
that the assignment of a ConfidentialityCode on an Act or a Role complies with a policy, that the target class be
associated with 1…* ActClassPolicy classes, which can be valued with applicable ActPolicyType e.g., v:
InformationSensitivityPolicy (where the codes deprecated from ConfidentialityByInfoType and Confidentiality
Modifiers have been relocated.)
Changes to ConfidentialityByAccessType:







Add two Confidentiality Codes for unrestricted and moderate confidentiality
Refined definitions for low, normal, restricted, and very restricted
Defined all Confidentiality Codes to reflect the full range of possible sensitivity classifications typical of security
policies
Added usage notes that indicate that further obligations that may govern authorized receivers
Deprecate codes Clinician and Individual as these are better modeled as access control by role or entity
Relocate Business to ActPrivacyPolicyType as an example policy governing the Confidentiality value assigned to
a role, e.g., SPL ingredient role as restricted because of trade secret policy.
WRT to Checklist Question 47: If deprecating a value set, have you identified a reason for the deprecation and
provided guidance for what should be used instead? We recommend that models intended to convey role or user
access control constraints use restrictive participations to target acts for relevant role types. “Business” has been
moved to the ActPolicyType code system, and the remediation discussed above applies.
Changes illustrated below:
5
I.e., marked as IsImmutable in DEFN=UV=VO=1099-20110726.coremif: <valueSet id="2.16.840.1.113883.1.11.10228"
name="Confidentiality" isImmutable="true">
Page |8
class ConfidentialityCodes
«Abstract Code»
Confidentiality
«DomainCodedValue»
+ Low = L
+ Moderate = M
+ Normal = N
+ Restricted = R
+ Unrestricted = U
+ Very Restricted = VR
«Abstract Code»
x_BasicConfidentialityKind
«DomainCodedValue»
+ Normal = N
+ Restricted = R
+ Very Restricted = VR
«Abstract Code»
x_VeryBasicConfidentialityKind
«DomainCodedValue»
+ Normal = N
+ Restricted = R
Below is an attached spreadsheet with the entire vocabulary including new concept sub-domains, code system, and value
set.
Confidentiality Code
Vocabulary.xlsx
Table below included for discussion purposes only. In case of any discrepancies, please consider the attached
spreadsheet (above) with complete vocabulary to be the “source of truth”.
Page |9
Refactored Confidentiality Codes
Lv
lT
y
p
Concept Code
Head Codedefined Value
Set
RIM Attribute Definition, Properties, Relationships
or
Print Name
0- _Confidentiality
A
Definition: Privacy metadata indicating the sender’s sensitivity classification, which is based on an analysis of applicable
privacy policies and the risk of harm that could result to the information subject from unauthorized disclosure.
Description: The confidentiality code assigned by a sender based on the information’s sensitivity classification, which
may convey a receiver’s obligation to ensure that the information is not made available or redisclosure to unauthorized
individuals, entities, or processes (security principals) per applicable policies.
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.
Concept Relationships:
Specializes: Confidentiality
Generalizes (derived): .U, .L, .M, .N, .R, .V
Current Definitions
Current Definition: By accessing
subject / role and relationship based
rights (These concepts are mutually
exclusive, one and only one is
required for a valid confidentiality
coding.)
Concept Relationships:
Generalizes (derived): B D I L N R V
1- .U
L
unrestricted
Definition: Privacy metadata indicating that the information is not classified as sensitive.
N/A
Examples: Includes information subject publicly available information, e.g., business name, phone, email or physical
address.
Usage Note: This metadata indicates that the receiver has no obligation to consider additional policies when making
access control decisions. Note that in some jurisdictions, personally identifiable information must be protected as
confidential, so it would not be appropriate to assign a confidentiality code of "unrestricted" to that information even if
it is publicly available.
Concept Relationships:
Specializes: _Confidentiality
1- .L
L
low
Definition: Privacy metadata indicating that the information has been de-identified, and there are mitigating
circumstances that prevent re-identification, which minimize risk of harm to the information subject from unauthorized
disclosure. The information requires protection to maintain low sensitivity.
Examples: Includes anonymized, pseudonymized, or non-personally identifiable information such as HIPAA limited data
sets.
Usage Note: This metadata indicates the receiver may have an obligation to comply with a data use agreement.
No clear map to ISO 13606-4 Sensitivity Level (1) Care Management: RECORD_COMPONENTs that might need to be
accessed by a wide range of administrative staff to manage the subject of care’s access to health services.
Concept Relationships:
Specializes: _Confidentiality
1- . M
L
moderate
Definition: Privacy metadata indicating moderately sensitive information, which presents moderate risk of harm to the N/A
information subject if disclosed without authorization.
Examples: includes allergies of non-sensitive nature used inform food service; health information a patient authorizes
to be used for marketing, released to a bank for a health credit card or savings account; or information in personal
health record systems that are not governed under health privacy laws.
Usage Note: This metadata indicates that the receiver may be obligated to comply with the receiver’s terms of use or
privacy policies.
Partial Map to ISO 13606-4 Sensitivity Level (2) Clinical Management: Less sensitive RECORD_COMPONENTs that might
need to be accessed by a wider range of personnel not all of whom are actively caring for the patient (e.g. radiology
staff).
Concept Relationships:
Specializes: _Confidentiality
1- . N
L
normal
Definition: Privacy metadata indicating that the information is typical, non-stigmatizing health information, which
presents typical risk of harm to the information subject if disclosed without authorization.
Examples: In the US, this includes what HIPAA identifies as the minimum necessary protected health information (PHI)
given a covered purpose of use (treatment, payment, or operations). Includes typical, non-stigmatizing health
information disclosed in an application for health, workers compensation, disability, or life insurance.
Usage Note: This metadata indicates that the receiver may be obligated to comply with applicable jurisdictional
privacy law or disclosure authorization.
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.
Concept Relationships:
Specializes: _Confidentiality
Current Definition: Normal
confidentiality rules (according to
good health care practice) apply, that
is, only authorized individuals with a
legitimate medical or business need
may access this item.
Concept Relationships:
Specializes: _Confidentiality
1- . R
L
restricted
Definition: Privacy metadata indicating highly sensitive, potentially stigmatizing information, which presents a high risk
to the information subject if disclosed without authorization. May be preempted by jurisdictional law, e.g., for public
health reporting or emergency treatment.
Examples: Includes information related to mental health, HIV, substance abuse, domestic violence, child abuse, genetic
disease, and reproductive health.
Usage Note: This metadata indicates that the receiver may be obligated to comply with the information subject’s
consent directive or with organizational policies that are more stringent than jurisdictional privacy laws.
Partial Map to ISO 13606-4 Sensitivity Level (4) Privileged Care: Access restricted to a small group of people caring
intimately for the patient, perhaps an immediate care team or senior clinical party (the privileged clinical setting needs
to be specified e.g. mental health).
Concept Relationships:
Specializes: _Confidentiality
Current Definition: Restricted
access, e.g. only to providers having
a current care relationship to the
patient.
Concept Relationships:
Specializes: _Confidentiality
1- . V
L
very
restricted
Definition: Privacy metadata indicating extremely sensitive, likely stigmatizing information, which presents a very high
risk to the information subject if disclosed without authorization. This information must be kept in the highest
confidence.
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 “legal lock”.
Usage Note: This metadata indicates that the receiver may not disclose this information except as directed by the
information custodian, who may be the information subject.
Partial Map to ISO 13606-4 Sensitivity Level (5) Personal Care: To be shared by the subject of care perhaps with only
one or two other people whom they trust most, or only accessible to the subject of care (and to others by one-off
authorizations).
Concept Relationships:
Specializes: _Confidentiality
Current Definition: No patient
record item can be of low
confidentiality. However, some
service objects are not patient
related and therefore may have low
confidentiality.
Concept Relationships:
Specializes: _Confidentiality
Current Definition: Very restricted
access as declared by the Privacy
Officer of the record holder.
Concept Relationships:
Specializes: _Confidentiality
DISCUSSION:
The following activity diagram illustrates how to implement a sender system capable of assigning confidentiality codes and
a receiver system capable of complying with confidentiality codes.
act Use of Priv acy Metadata for Data Segmentation
Sending System
Receiv ing System
System initiates
disclosure
Select data to be disclosed
Very restricted data is
excluded from exchange
[some data is
deemed very
restricted]
Is any data
protected?
[some data is
confidentialtiy=normal]
[some data is protected]
Is consent required
[consent not required AND
confidentiality=normal]
Assign priv acy metadata to
health data
Receiv e health data
[required AND consent not
available]
Request and record
priv acy consent
Process priv acy
metadata
[consent granted AND
confidentiality=restricted]
Is health data
de-identified?
Is priv acy consent
granted?
[confidentiality=restricted]
[consent
granted with
conditions]
Add conditions and
consent to
transmission
[confidentiality=
restricted]
[de-identified AND
confidentiality=low]
[confidentiality=low OR
confidentiality= normal]
Rev ise priv acy
metadata
Ev aluate obligations
and priv acy consent
Send health data, its
metadata and other related
information
Record
disclosure
Consent
withheld
Accept Data
[able to comply]
Able to
comply?
[unable to comply]
Automatic disclosure
failed
Rej ect data
P a g e | 11
P a g e | 12
class ConfidentialityCodes & ActPolicyVocabulary
«Abstract Code»
ActPolicy Vocabulary::
ActPolicyType
«Abstract Code»
ConfidentialityCodes::
Confidentiality
«DomainCodedVal...
+ coverage policy
«DomainCodedValue»
+ Low = L
+ Moderate = M
+ Normal = N
+ Restricted = R
+ Unrestricted = U
+ Very Restricted = VR
CompliesWith
«Abstract Co...
ActPolicy
Vocabulary::
ActPriv acyPolicy
«Abstract Code»
ActPolicy Vocabulary::
ActConsentDirectiv e
+
+
+
Emergency only
Opt-in
Opt-out
«Abstract Code»
ActPolicy Vocabulary::
InformationSensitiv ityPolicy
«DomainCodedValue»
+ adolescent information sensitivity
+ celebrity information sensitivity
+ diagnosis information sensitivity
+ drug information sensitivity
+ employee information sensitivity
+ patient default sensitivty
+ patient requested sensitivity
«Abstract Code»
ConfidentialityCodes::
x_BasicConfidentialityKind
«Abstract Code»
ConfidentialityCodes::
x_VeryBasicConfidentialityKind
«DomainCodedValue»
+ Normal = N
+ Restricted = R
+ Very Restricted = VR
«DomainCodedValue»
+ Normal = N
+ Restricted = R
«Abstract Co...
ActPolicy
Vocabulary::
ActPriv acyLaw
«Abstract Code»
ActPolicy Vocabulary::
ActUSPriv acyLaw
«DomainCodedValue»
+ 42 CFR Part2
+ Common Rule
+ HIPAA notice of privacy practices
+ HIPAA psychotherapy notes
+ HIPAA self-pay
«Abstract Code»
ActPolicy Vocabulary::
EntityInformationSensitiv ityPolicy
«Abstract Code»
ActPolicy Vocabulary::
RoleInformationSensitiv ityPolicy
«DomainCodedValue»
+ all demographic information sensitivity
+ date of birth information sensitivity
+ marital status information sensitivity
+ race information sensitivity
+ religion information sensitivity
«DomainCodedValue»
+ business information sensitivity
+ employer information sensitivity
+ location information sensitivity
«Abstract Code»
ActPolicy Vocabulary::ActInformationSensitiv ityPolicy
«DomainCodedValue»
+ genetic disease information sensitivity
+ HIV/AIDS information sensitivity
+ psychiatry information sensitivity
+ sexual assault, abuse, or domestic violence information sensitivity
+ sexually transmitted disease information sensitivity
+ substance abuse information sensitivity
+ taboo
ACTION ITEMS:
P a g e | 13
1. Review and approve associated Harmonization proposal for ActPolicyTypeCode, in which the codes from the
current Confidentiality code system value set ConfidentialityByInfoType and ConfidentialityModifiers are
relocated.
2. M&M to implement recommendation
RESOLUTION:
<< REQUIRED before recommendation can be closed. Indicates how recommendation was brought to closure. Can
include notes on further study or networking required, and by whom.>>
Checklist for HL7 Vocabulary Harmonization Submissions
The following checklist must be completed for each submission and attached as part of the submission posting
for every HL7 harmonization proposal that proposes a change to any HL7 terminology artifact. (Submit your
proposal as a zip containing the base proposal and this form, or copy this form onto the end of your proposal.)
If a revised proposal is submitted (e.g. detailed proposal after cover page), a new copy of the checklist must be
attached confirming that the revised proposal has been re-reviewed. The failure to attach a completed checklist
will result in the tabling or deferral of the proposal to a subsequent harmonization meeting with the assumption
the proposal will be re-introduced with a completed form.
The proposal has been constructed in such a way that the “correct” answer to each question is either “Yes” or
“N/A”. In the event that the answer is “No”, please provide an explanation at the end noting the question
number and the reason why the checklist item has not been met. Harmonization proposals that do not satisfy all
checklist items may still be considered at harmonization at the discretion of the harmonization group and the
vocabulary maintenance team if there is a satisfactory reason the checklist item could not be met. Lack of time
to complete the form does not constitute a satisfactory reason.
A section of the form may be marked as “N/A” and all checklist items within that section ignored if none of the
terminology items submitted apply to that section.
In most circumstances, this checklist should be completed by the sponsor committee’s vocabulary facilitator,
but it may be completed by any submitter.
Note: When checking for existing codes, code systems, value sets, etc., please make sure that your RoseTree
configuration options are set to display Retired and Deprecated elements, as the “no duplicates” rule applies to
those as well.
Before completing this checklist, please consult the following “best practices” and guidelines documents.
(They will be updated from time to time, so please review the documents for changes prior to each
harmonization.)
Concept domain & Value set naming:
http://wiki.hl7.org/index.php?title=Concept_Domain_Naming_Conventions
http://wiki.hl7.org/index.php?title=Value_Set_Naming_Conventions
Definitions: http://wiki.hl7.org/index.php?title=Annotations_Best_Practices
Terminology Good Practices: http://wiki.hl7.org/index.php?title=Good_Terminology_Practices
General
General
1. Has the proposal, in its final form, been reviewed by the sponsor committee’s vocabulary facilitator (mark N/A if
there is no facilitator)? (
- Yes;
- No;
- N/A)
2. Have you completely filled out header section for the proposal and checked that the dates are correct and the
submission number is unique across all of your submissions for this harmonization cycle? ( - Yes; - No;
N/A)
3. Have you filled out the summary form identifying the number of created, updated and deprecated objects of
each type? ( - Yes ; - No;
- N/A)
4. Has your proposal been submitted to and reviewed by all relevant WGs and been formally endorsed (with a vote
recorded in the WG minutes) to be brought forward to harmonization? (For harmonization submissions from
international affiliates, approval by an appropriate affiliate level committee or project is sufficient, though
submission to the relevant HL7 UV WG is strongly recommended.) ( - Yes;
- No;
- N/A)
New Concept Domains (
- N/A)
For all concept domains being created by this proposal:
P a g e | 15
5. Have you done a key-word search for equivalent or similar concept domains and, if any exist, identified
appropriate parent and child relationships to position your concept domain?
- Yes;
- No;
- N/A)
6. Have you provided a name for your concept domain that follows the naming guidelines?(
N/A)
- Yes;
- No;
-
7. If your concept domain is not associated with a new RIM attribute or datatype property, have you identified a
parent for your concept domain?( - Yes;
- No;
- N/A)
8. Have you checked whether any existing concept domains are proper specializations of your concept domain
and, if so, identified those new specialization relationships as part of your proposal? ( - Yes;
- No;
N/A)
9. If your concept domain is in the ActCode, RoleCode or EntityCode hierarchy, have you identified the classCode
that acts as the “root” for the concept domain? ( - Yes;
- No;
- N/A)
10. Have you verified that all concept domains referenced as parent or child concepts actually exist in the most
recent vocabulary repository and are correctly spelled in your proposal using U.S. language settings? ( - Yes;
- No;
- N/A)
11. Have you provided a concise, non-tautological definition for your concept domain and confirmed that the
definition follows the best practices for definitions? ( - Yes;
- No;
- N/A)
12. Have you checked the name of your concept domain and associated definition for appropriate spelling and
grammar using U.S. language settings, and consistency with the current Concept Domain naming conventions? (
- Yes;
- No;
- N/A)
13. Have you either: Provided 3 distinct examples; identified a binding to an example value set with 3 distinct
example codes; identified a representative binding; or identified a universal binding? ( - Yes;
- No;
N/A)
Revised Concept Domains (
-
- N/A)
For all concept domains being revised by this proposal:
14. Have you identified the name of the existing concept domain, and verified that the concept domain does in fact
exist in the most recent vocabulary repository with the name spelled as referenced? (( - Yes;
- No;
N/A)
15. Have you verified that any additional concept domains identified as parents or children and any code referenced
as the anchor for the concept domain actually exist and are spelled properly? (( - Yes;
- No;
- N/A)
16. Have you confirmed that any change to the definition would not cause backwards compatibility issues with any
models that reference the Concept Domain under the old definition? ( - Yes;
- No;
- N/A)
17. Have you confirmed that any changes to the Concept Domain definition continue to comply with best practices
for definitions? ( - Yes;
- No;
- N/A)
18. Have you spell-checked and grammar checked your revised definition using U.S. language settings? (
- No;
- N/A)
New/Revised Code System (
- N/A)
For all code systems created or whose metadata is updated by this proposal:
- Yes;;
P a g e | 16
19. For new HL7-maintained code systems, have you confirmed that no other terminology maintenance
organization is a more appropriate organization to maintain the code system and codes within it? ( - Yes;
No;
- N/A) Reviewed codes in 13606-4.
20. For new external code systems, have you confirmed that the code system follows the good terminology
practices and is therefore appropriate for use in HL7 instances? ( - Yes;
- No;
- N/A)
21. For external code systems where there is a desire for HL7 to publish codes from the external code system, have
you verified that there are no copyright issues associated with the publication and provided a justification for
why HL7 should take on this administrative effort as well as identified how the HL7 published versions will be
kept in sync with the source? ( - Yes;
- No;
- N/A)
22. Have you provided a short-name for the code system that is unique among all other code systems found in the
HL7 OID registry? ( - Yes;
- No;
- N/A)
23. For all code systems, have you provided:
a. A long, unique “descriptive” name for the code system? (
- Yes;
b. A description of the intended use and scope of the code system (
- No;
- Yes;
- N/A)
- No;
- N/A)
24. For external code systems, have you provided:
a. OID for the code system (if already registered in the HL7 OID registry or otherwise assigned an OID)? (
- Yes;
- No;
- N/A)
b. Licensing information (
- Yes;
- No;
- N/A)
c. URL information for the official source of the vocabulary (
d. Contact Information (
- Yes;
- No;
- Yes;
- No;
- N/A)
- N/A)
e. The “short name” for the code system is consistent with the following rules (ISO Secondary Identifier
rules plus some HL7 constraints)
i. No spaces
ii. Only the characters 0-9, a-z, A-Z and hyphens
iii. Cannot have multiple consecutive hyphens or end with a hyphen
iv. Leading character must be a lower-case alpha
v. Must be unique from among all registered code systems in HL7’s OID registry
vi. Should not match any code system in HL7’s OID registry even when treating both as upper-case
Revised Code in Code System (
- N/A)
For all new codes created by this proposal:
25. Have you searched the code system in the most recent repository using keywords to verify that an equivalent
code doesn’t already exist? ( - Yes;
- Yes;
- No;
- N/A)
26. Have you searched the code system in the most recent repository to confirm that no code already exists with
the same code? ( - Yes;
- No;
- N/A) Note that you must also check existing retired and/or deprecated
codes for existence.
-
P a g e | 17
27. If adding a code from an external code system for HL7 publication (where HL7 has agreed to publish codes from
the external code system), have you confirmed that the code has actually been accepted by the external code
system and confirmed the code, print names and definition are identical to those in the most recent version of
the external code system? ( - Yes;
- No;
- N/A)
Added or Revised Code in Code System (
- N/A)
For all new codes created or updated by this proposal:
28. When adding a code or changing a print name, have you search searched the code system in the most recent
repository that no code already exists with the same print name? ( - Yes;
- No;
- N/A)
29. Have you provided a code values and (where appropriate) print names that align with the naming convention for
the code system? (Generally all upper case, no spaces for codes, lower case for print names. Depending on the
code system, the code may be mnemonic or not). ( - Yes;;
- No;
- N/A)
30. Have you provided a definition for the code that follows the best practices for definitions? (
- N/A)
- Yes;
- No;
31. Have you spell-checked (and for definitions grammar-checked) the definitions and print names using U.S.
language settings? ( - Yes;;
- No;
- N/A)
32. Have you defined all required properties for the code system in which the code is being added? (
No;
- N/A)
- Yes;;
-
a. ActClass: “specialized by concept domain”, Formal class name, formal name for association from
participation to Act
b. ActCode: “specialized by concept domain”
c. ActMood: Formal name
d. ActRelationshipType: “is document characteristic?”; applies to; how applies; Formal name from Act to
outbound ActRelationship, ActRelationship to source Act, ActRelationship to target Act and Act to
inbound ActRelationship; Sort for Act to inbound ActRelationship and Act to outbound ActRelationship
e. CompressionAlgorithm: howApplies (mandatory, deprecated, other)
f.
EntityClass: “specialized by concept domain”, applies to determinerCode, Formal class name
g. EntityDeterminer: Formal name
h. GTSAbbreviation: Equivalent expression
i.
ObservationMethod: how applies?
j.
ParticipationType: “specialized by concept domain”, “is document characteristic?”, Formal name from
Act to Participation and Role to Participation; Sort from Act to Participation and Role to Participation
k. RoleClass: “specialized by concept domain”, Formal name, Participation to Role name, Role to player
Entity name, Entity to played Role name, Entity to scoped Role name, Role to scoper Entity name, Entity
to played Role sort, Entity to scoped Role sort
l.
RoleCode: conceptStatusQualifier
m. RoleLinkType: Formal name from Role to outbound RoleLink, RoleLink to source Role, RoleLink to target
Role and Role to inbound RoleLink; Sort for Role to inbound RoleLink and Role to outboundRoleLink
P a g e | 18
33. Have you checked the current version of the code system and identified all code(s) that should be parents
and/or children of the new concept and verified that you have listed them all appropriately (and spelled
correctly) in your proposal? ( - Yes;;
- No;
- N/A)
34. Have you identified whether the code should be considered abstract or not?(
- Yes;
- No;
- N/A)
35. If deprecating a code, have you identified a reason for the deprecation and provided guidance for what should
be used instead? ( - Yes;;
- No;
- N/A)
New Value Sets (
- N/A)
For all new value sets created as part of this proposal:
36. Have you verified that the value set is appropriate to be registered in the HL7 Inc. repository (created against
structural code systems, used in a UV, Example or Representative binding)? ( - Yes;
- No;
- N/A)
37. Have you identified whether the value set definition is immutable? I.e. It is a definition that must never be
changed. (
- Yes;
- No;
- N/A)
38. Have you verified that the name for the value set does not already exist in the existing HL7 repository? (
- No;
- N/A)
39. Have you named the value set using the naming guidelines found here:
http://wiki.hl7.org/index.php?title=Value_Set_Naming_Conventions ( - Yes;
New or Modified Value Sets (
- No;
- Yes;
- N/A)
- N/A)
For all value sets created or modified as part of this proposal:
40. That any modified value sets are not flagged as immutable. ( - Yes;
- No;
- N/A) The value sets: v:
Confidentiality; x_BasicConfidentialityKind; and v: x_VeryBasicConfidentialityKind should be flagged immutable.
41. For non-immutable value sets, have you provided a description that explains the scope of the value set and the
“owning” WG that should be responsible for determining how the value set definition evolves over time? ( Yes;
- No;
- N/A)
42. Have you defined all required properties for value sets drawn from one of the following structural code
systems? ( - Yes;
- No;
- N/A)
a. ActClass: Formal class name, formal name for association from participation to Act
b. ActMood: Formal name
c. ActRelationshipType: Formal name from Act to outbound ActRelationship, ActRelationship to source
Act, ActRelationship to target Act and Act to inbound ActRelationship; Sort for Act to inbound
ActRelationship and Act to outbound ActRelationship
d. EntityClassFormal class name
e. EntityDeterminer: Formal name
f.
ParticipationType: Formal name from Act to Participation and Role to Participation; Sort from Act to
Participation and Role to Participation
g. RoleClass: Formal name, Participation to Role name, Role to player Entity name, Entity to played Role
name, Entity to scoped Role name, Role to scoper Entity name, Entity to played Role sort, Entity to
scoped Role sort
P a g e | 19
h. RoleLinkType: Formal name from Role to outbound RoleLink, RoleLink to source Role, RoleLink to target
Role and Role to inbound RoleLink; Sort for Role to inbound RoleLink and Role to outboundRoleLink
43. Have you checked that your value set name and description are correctly spelled (and for descriptions, have
correct grammar) using U.S. language settings, and is consistent with the current Value Set naming conventions?
( - Yes;
- No;
- N/A)
44. Have you checked that all references to codes in your value set definition identify their associated code system
and actually exist within the current version of their respective code systems (both HL7 and external code
systems)? ( - Yes;
- No;
- N/A)
45. Have you verified that if your value set content definition is enumerated (extensional) that there is no
appropriate or better way to define it as an expression-based (intentional) definition? ( - Yes;
- No;
N/A)
-
46. For expression-based value set content definitions, have you confirmed that your expression is expressed in a
way that is fully defined against the HL7 metamodel? ( - Yes;
- No;
- N/A)
a. For code-based value sets, identify whether the head-code is included or not
b. For code-based value sets, identify whether the included codes should be children, all descendants or
leaf nodes only
c. For code based value sets, that the specific type of association to be navigated is identified if it is
something other than the subsumption relationship
d. For complex value sets, that they are expressed as a combination of unions, intersections and exclusions
where “order of operations” is clearly documented
e. For property-based value sets, that the referenced property names actually exist in their respective code
systems and are spelled correctly
f.
That for mnemonic-based value sets, that the reg-ex expression to be evaluated against the codes is a
valid reg-ex expression
47. If deprecating a value set, have you identified a reason for the deprecation and provided guidance for what
should be used instead? ( - Yes;
- No;
- N/A)
48. New Binding Realms (
- N/A)
For all new Binding Realms created as part of this proposal:
49. Have you identified the owning affiliate and the superset binding realm? (
- Yes;
- No;
50. Have you received official permission from the affiliate to create the new binding realm (
N/A)
- N/A)
- Yes;
- No;
-
51. Have you identified a proposed code for the binding realm that is unique amongst all binding realms in the most
recent version of the repository following binding realm naming conventions (i.e. starting with the code for the
affiliate)? ( - Yes;
- No;
- N/A)
52. Have you provided a unique descriptive name for the new binding realm? (
- Yes;
- No;
- N/A)
53. Have you provided a description that explains the scope of the new binding realm and spell-checked and
grammar-checked it? ( - Yes;
- No;
- N/A)
P a g e | 20
New Context Bindings (
- N/A)
For all new Context Bindings created as part of this proposal:
54. Have you declared the name of the concept domain, the binding realm and the value set name or OID? (
Yes;
- No;
- N/A)
-
55. Have you checked that the concept domain name, binding realm code and value set name or OID actually exist
in the most recent version of the repository? ( - Yes;
- No;
- N/A)
56. If the binding is not to be effective immediately upon harmonization approval and application of approved
changes, have you identified the effective date? ( - Yes;
- No;
- N/A)
57. Have you checked whether there is already a binding for the same concept domain and binding realm and if so,
either specified a new sequence number (to allow parallel bindings) or a date to on which the old binding should
end and the new one should become effective? ( - Yes;
- No;
- N/A)
58. If binding in a realm other than “example”, have you conformed that the set of codes in the valueset being
bound provides full coverage for the concept space defined by the concept domain? ( - Yes;
- No;
N/A)
Explanation for N/A Items
The N/A items did not apply to the proposal.
<codeSystem name="Confidentiality" title="Confidentiality" codeSystemId="2.16.840.1.113883.5.25">
<header>
<legalese>
<notation>Is in UMLS.</notation>
</legalese>
<responsibleGroup organizationName="Health Level 7"/>
<contributor>
<role>Sponsor</role>
<name name="Health Level Seven"/>
</contributor>
</header>
<annotations>
<documentation>
<description>
<text>
<p>Values that control disclosure of information.</p>
<p>
<i>Example:</i> Normal, restricted, substance abuse
related.</p>
<p>
<i>OpenIssue: </i>Description copied from Concept Domain of
same name. Must be verified.</p>
</text>
</description>
</documentation>
</annotations>
<releasedVersion releaseDate="2011-07-26" publisherVersionId="134" hl7MaintainedIndicator="true"
completeCodesIndicator="true" hl7ApprovedIndicator="true">
<supportedLanguage>en</supportedLanguage>
<supportedConceptRelationship relationshipKind="Specializes" name="Specializes"
inverseName="Generalizes" isNavigable="true" reflexivity="irreflexive" symmetry="antisymmetric" transitivity="transitive">
<description>The child code is a more narrow version of the concept represented by the
parent code. I.e. Every child concept is also a valid parent concept. Used to allow determination of subsumption. Must
be transitive, irreflexive, antisymmetric.</description>
P a g e | 21
</supportedConceptRelationship>
<supportedConceptRelationship relationshipKind="Generalizes" name="Generalizes"
inverseName="Specializes" isNavigable="true" reflexivity="irreflexive" symmetry="antisymmetric" transitivity="transitive">
<description>Inverse of Specializes. Only included as a derived
relationship.</description>
</supportedConceptRelationship>
<supportedConceptProperty propertyName="internalId" type="Token"
isMandatoryIndicator="false">
<description>The internal identifier for the concept in the HL7 Access database
repository.</description>
</supportedConceptProperty>
<concept isSelectable="false">
<annotations>
<documentation>
<definition>
<text>
<p>By accessing subject / role and relationship based
rights (These concepts are mutually exclusive, one and only one is required for a valid confidentiality coding.)</p>
</text>
</definition>
</documentation>
</annotations>
<conceptProperty name="internalId" value="21049"/>
<printName language="en" preferredForLanguage="true"
text="ConfidentialityByAccessKind"/>
<code code="_ConfidentialityByAccessKind" status="active"/>
</concept>
<concept isSelectable="false">
<annotations>
<documentation>
<definition>
<text>
<p>By information type, only for service catalog entries
(multiples allowed). Not to be used with actual patient data!</p>
</text>
</definition>
</documentation>
</annotations>
<conceptProperty name="internalId" value="21050"/>
<printName language="en" preferredForLanguage="true"
text="ConfidentialityByInfoType"/>
<code code="_ConfidentialityByInfoType" status="active"/>
</concept>
<concept isSelectable="false">
<annotations>
<documentation>
<definition>
<text>
<p>Modifiers of role based access rights (multiple
allowed)</p>
</text>
</definition>
</documentation>
</annotations>
<conceptProperty name="internalId" value="21051"/>
<printName language="en" preferredForLanguage="true"
text="ConfidentialityModifiers"/>
<code code="_ConfidentialityModifiers" status="active"/>
</concept>
P a g e | 22
<concept>
<contextBinding conceptDomain="Confidentiality" valueSet="2.16.840.1.113883.1.11.10228"
bindingRealmName="R1" codingStrength="CWE" effectiveDate="2011-07-26"/>
<annotations>
<documentation>
<definition>
<text>
<p>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. However, no patient related information may ever be of this confidentiality
level.</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityByAccessKind"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10235"/>
<printName language="en" preferredForLanguage="true" text="business"/>
<code code="B" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>Only clinicians may see this item, billing and
administration persons can not access this item without special permission.</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityByAccessKind"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10231"/>
<printName language="en" preferredForLanguage="true" text="clinician"/>
<code code="D" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>Access only to individual persons who are
mentioned explicitly as actors of this service and whose actor type warrants that access (cf. to actor type code).</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityByAccessKind"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10233"/>
<printName language="en" preferredForLanguage="true" text="individual"/>
<code code="I" status="active"/>
</concept>
<concept>
P a g e | 23
<annotations>
<documentation>
<definition>
<text>
<p>No patient record item can be of low confidentiality.
However, some service objects are not patient related and therefore may have low confidentiality.</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityByAccessKind"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10234"/>
<printName language="en" preferredForLanguage="true" text="low"/>
<code code="L" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>Normal confidentiality rules (according to good
health care practice) apply, that is, only authorized individuals with a legitimate medical or business need may access this
item.</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityByAccessKind"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10230"/>
<printName language="en" preferredForLanguage="true" text="normal"/>
<code code="N" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>Restricted access, e.g. only to providers having a
current care relationship to the patient.</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityByAccessKind"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10232"/>
<printName language="en" preferredForLanguage="true" text="restricted"/>
<code code="R" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
P a g e | 24
<p>Very restricted access as declared by the Privacy
Officer of the record holder.</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityByAccessKind"/>
</conceptRelationship>
<conceptProperty name="internalId" value="14799"/>
<printName language="en" preferredForLanguage="true" text="very restricted"/>
<code code="V" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>Alcohol/drug-abuse related item</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityByInfoType"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10243"/>
<printName language="en" preferredForLanguage="true" text="substance abuse
related"/>
<code code="ETH" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>HIV and AIDS related item</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityByInfoType"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10241"/>
<printName language="en" preferredForLanguage="true" text="HIV related"/>
<code code="HIV" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>Psychiatry related item</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
P a g e | 25
<targetConcept code="_ConfidentialityByInfoType"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10242"/>
<printName language="en" preferredForLanguage="true" text="psychiatry relate"/>
<code code="PSY" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>Sexual assault / domestic violence related item</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityByInfoType"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10244"/>
<printName language="en" preferredForLanguage="true" text="sexual and domestic
violence related"/>
<code code="SDV" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>Celebrities are people of public interest (VIP)
including employees, whose information require special protection.</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityModifiers"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10239"/>
<printName language="en" preferredForLanguage="true" text="celebrity"/>
<code code="C" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>Information for which the patient seeks heightened
confidentiality. Sensitive information is not to be shared with family members. Information reported by the patient about
family members is sensitive by default. Flag can be set or cleared on patient's request.</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityModifiers"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10237"/>
<printName language="en" preferredForLanguage="true" text="sensitive"/>
P a g e | 26
<code code="S" status="active"/>
</concept>
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>Information not to be disclosed or discussed with
patient except through physician assigned to patient in this case. This is usually a temporary constraint only, example use
is a new fatal diagnosis or finding, such as malignancy or HIV.</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="_ConfidentialityModifiers"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10238"/>
<printName language="en" preferredForLanguage="true" text="taboo"/>
<code code="T" status="active"/>
</concept>