FHIR Data Segmentation for Privacy
1.0.0 - trial-use
FHIR Data Segmentation for Privacy
1.0.0 - trial-use
FHIR Data Segmentation for Privacy, published by HL7 Security Working Group. This is not an authorized publication; it is the continuous build for version 1.0.0). This version is based on the current content of https://github.com/HL7/fhir-security-label-ds4p/ and changes regularly. See the Directory of published versions
This specification provides implementation guidance for the use of security labels in FHIR based on the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 (HCS). The HCS is the normative conceptual model upon which HL7 Messaging Version 2.9, the HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1, and the HL7 CDA® R2 Implementation Guide: Data Provenance, Release 1 - US Realm are based.
In FHIR, a security label is defined as a simple value of type Coding which is composed of (among other details), a code and the identifier of the system in which the code is defined, together with a human readable display name for the code. For example, the following data structure represents a FHIR security label for restricted confidentiality as defined by HL7 terminology:
{
"system" : "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
"code" : "R",
"display" : "restricted"
}
The HCS, on the other hand, defines Security Label as a more complex data structure based on the concept of Named Tag Set.
As implied by the title, a Named Tag Set is a collection of Tags together with a Tag Set Name. Each Tag is a simple code and the Tag Set Name assigns a name to the collection. The Tag Set Name is the identifier associated with the tag set that indicates the type and characteristics of the tags in it. In FHIR, is the name of the value set from which allowable codes may be drawn to populate a Named Tag Set, so, Tag Set Name is usually equivalent to the system attribute in a Coding data structure for a FHIR security label.
Conceptually, this is equivalent to the following abstract object (note that this is not valid FHIR JSON and is presented only for conceptual clarity):
{
"TagSetName" : "some name",
"Tags" : ["tag 1", "tag 2", "tag 3"],
}
In HCS, A Security Label is defined as a data structure composed of four Named Tag Sets:
that record security classification, security category, security control (also known as handling caveat), and security trust. Conceptually, this would be equivalent to the following abstract object (note that this is not valid FHIR JSON and is presented only for conceptual clarity):
[
{
"TagSetName" : "Security Classification",
"Tags" : ["..."]
},
{
"TagSetName" : "Security Category",
"Tags" : ["..."]
},
{
"TagSetName" : "Security Control",
"Tags" : ["..."]
},
{
"TagSetName" : "Security Trust",
"Tags" : ["..."]
}
]
In HCS, every Security Label must include one (and only one) security classification tag set ([1..1] cardinality) that must include one value from the HL7 Confidentiality code system. The other elements are optional. Since classification is used to determine whether a requester meets the minimum bar for accessing information protected at or below a given level of confidentiality protection, the Confidentiality code system is a total range hierarchy of protection levels. In HCS terms, a Confidentiality code is an essential element and the minimum bar for a compliant security label.
Unlike Security Classification, all of the other Named Tag Set fields are non-hierarchical and are not mandatory ([0..*] cardinality) unless otherwise required by a policy.
A simple example is depicted in the following diagram. A more detailed example is provided below at the end of this page.
Generally, a Security Label is assigned in accordance with a policy, which deems an aspect of a valued information object warrant a level of confidentiality protection. The policy is based on an assessment of the potential impact that a loss of confidentiality, integrity, or availability of such information or information system would have on organizational operations, organizational assets, or individuals (this definition of Security Category is used in a number of NIST publications, which are listed here).
To be conveyed as a security label, a policy must categorize the aspects of information that require a specific level of confidentiality protection.
These aspects are valued as “Tags” in the Security Category portion of a security label using the codes in the value sets associated with the Security Category Tag Set Names.
The current HCS-conformant Security Category Tag Set Names are: Sensitivity, Policy, Compartment, Integrity, and Provenance. These value sets are listed in the Detailed Specification Value Sets Summary.
0..*Information Sensitivity is the characteristic of an IT resource which implies its value or importance and may include its vulnerability [ISO 7498-2]. Along with any relevant policy, information sensitivity is a strong determinant of the required level of confidentiality protection.
Sensitivity labels are determined based on the information conveyed by the resource, including structured information (such as clinical codes) as well as unstructured information (such as textual notes). A resource may also convey sensitive information indirectly (i.e., by inference) based on its association with other resources or information. For example, an appointment resource at a facility that is known to provides specialized care of a type that is considered sensitive, such as substance use treatment.
Assigning sensitivity labels, therefore, requires a deep analysis of the content of a resource (both explicit and implicit) as well as its links with other resources and entities.
0..1It is critical that the policy dictating the sensitivity of labeled information be included in Security Label as the single Policy Tag indicating governed sensitive information, the level of confidentiality, other pertinent security categories relevant to the information, access limitations to a compartment of end users with a “need to know” such as a Care Team or Research Project.
If more than one policy applies to the information (e.g., the case with consent directives for Health Information Exchanges operating under multiple laws, or for compound research consent directives which combine both a privacy consent to disclose information for research, as well as consent to participate in a clinical study and to donate biospecimen) a best practice for interoperable consumption of labels is to create distinct labels for all aspects of such policies/consent directives.
Additional Security Category Tag Sets specified by policy may include compartment, integrity, provenance, and trust attributes pertinent to the governed information.
0..*A policy may require that the information may only be made available within a specific workflow or project, thereby isolating the information and limiting access to entities provisioned with clearance for that compartment (i.e., members of a group entitled to access). An entity’s access to information in a compartment may be further constrained by privileges based on roles or attributes.
0..*A policy may require that information be tagged to indicate confidence in its reliability, its status in being attested to or verified, any data alteration or syntactic/semantic transformation that it may have undergone, and whether it has been protected against any tampering or made non-repudiable. A hierarchical grading of confidence tag may be accompanied with other integrity or with provenance tags to support the assigned confidence level.
0..*A policy may require that the provenance of the information be accessible to end users to assist with the determination of their level of confidence in the trustworthiness, authenticity, and reliability of the labeled information, and whether or not (or to what extent) the information has been exchanged only within a trust framework where exchange partners are bound to maintaining the integrity of the exchanged information. Provenance tags are not a replacement for a provenance record but can be considered a flag indicating that such a record may be important. For example, a patient reporting that a provider asserted the patient’s allergy has a different weight in terms of reliability than a provider asserting a patient reported family history.
1..1Confidentiality labels are assigned based on the sensitivity of the information contained in the resources. If the sensitive information increases the risk of subjecting the information target (i.e., a patient) to stigmatization or discrimination (which might in turn deter seeking treatment or other services), then, the need to protect the confidentiality of that information is more stringent than the “normal,” and therefore, the confidentiality protections will be heightened beyond the “normal” level.
The process of assigning confidentiality level of the information is referred to as classification, which is the act or process by which information is assigned a level of confidentiality protection.
Classification is conducted by a Classifier who controls the classified information and has the authority to determine the appropriate level of protection.
Note that there may be more than one classifier during the lifetime of the information since custodians of the information are sometimes authorized by policy to change the classification. Not every custodian of information is a classifier, however, and some custodians do not have the authority to re-classify. Downstream classifiers may be required by policies to retain security labels assigned by previous classifiers.
The appropriate level of confidentiality protection is determined by the classifier’s assessment of the disclosure risks, usually identified by the magnitude or type of damage caused by disclosure, such as the risk of harm (including reputational harm), discrimination, or safety to an individual.
Ultimately, the appropriate level of confidentiality protection for a type of sensitive information is dictated by jurisdictional, organizational, or individual policy.
According to the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1, one, and only one, Confidentiality Tag code is assigned by a Custodian (information holder) to a Security Label when “classifying” the information. The Custodian may be the originator of the information to be protected, a Receiver of information from the Custodian, and may further disclose that information to a downstream Recipient. Any Custodian may be permitted to reclassify information per applicable policies and trading partner agreements.
The confidentiality protection afforded to sensitive information differs by applicable law. For example, in the US, HIV-sensitive information has “normal” (N) level of confidentiality if governed by HIPAA. However, if HIV sensitive information is governed under Title 38 Section 7332, 42 CFR Part 2 (as co-morbid with substance use disorder), or under some state laws, the level of confidentiality protection is coded as “restricted” (R), because these laws are more protective than HIPAA.
The criterion for assigning HL7 confidentiality codes is whether applicable policy deems the misuse of information as posing a greater or lesser risk of harm to or stigmatization of the data subject or an organization. The information may be about a sensitive health condition, but not necessarily so; for example, it could be business- or security-policy- sensitive.
The following HL7 Confidentiality Code criteria are intended to meet a healthcare-specific multi-level security model for access control by stipulating clearly distinguishable levels of protection, which can be specialized by realm:
The descriptions of Confidentiality Codes are based on variance from “normative” level of protection as a metric for differentiating the total order hierarchical demarcations for this multi-level security model.
This results in the following hierarchy from high to low (a total order): Very Restricted (V), Restricted (R), Normal (N), Moderate (M), Low (L), and Unrestricted (U), where Very Restricted is the parent, and each subsequent label is-a lesser protection level than its predecessor with Unrestricted being the lowest protection level:
U) is the lowest protection level, less protective than V, R, N, M, and L.L) is less protective than V, R, N, and M, but more protective than U.M) is less protective than V, R, and N, but more protective than L and U.N) is less protective than V and R, but more protective than M, L, and U.R) is less protective than V, but more protective than N, M, L, and U.V) is the highest protection level, more protective than R, N, M, L, and U.This is to convey the handling instructions or “caveats” to which senders and receivers must comply to access information labeled with specific Security Category tags (e.g., sensitivity tags). This security label includes 0..* Security Control Tags, each of which may have 1..* values.
Handling caveats are instructions about mandatory and prohibited actions (obligations and refrain policies) within a permitted use context or “purpose of use”.
Assign handling caveats as access control decision information to an information resource as required by policy to obtain an end-user’s implicit or explicit acceptance of a source rule prior to use or access.
The acceptance of a handling caveat may be implicit (e.g., in an Memorandum of Understanding, Data Use and Reciprocal Support Agreement, or contract) or explicit as in a returned response (e.g. a promise). The pre-established trust framework defines specific rules for complying with such handling caveat codes.
The Security Controls include:
0..*Purpose of Use (POU) tags indicates the circumstances under which an authorized receiver is permitted by policy to perform an activity (e.g., create, collect, access, use, or disclose). Information privacy, security, and trust policies typically include the list of permissible actions, to which senders require receivers to limit use.
The HL7 POU codes were drawn from a number of narrower US and international POU code systems, augmented with new use cases (e.g., research, healthcare payment and operations, quality measures, legal and public health) and organized according to workflows in order to ensure comprehensive coverage for healthcare activities.
0..*Obligations tags represent explicit mandatory actions which may be required by the policies of custodians, senders, and receivers about how information is to be handled and actions specified to be performed in conjunction with enforcement of an access control decision. For example, instructions to disclose only the minimum necessary and to encrypt while in transit.
0..*Refrain tags represent explicitly-prohibited actions which may be required by the policies of custodians, senders, and receivers about how information is not to be handled and actions not to be performed. Examples are constraints on collection, disclosure, routing, and communication path expected to be enforced by access control systems, a prohibition on persisting information for purposes other than explicitly permitted, and no re-disclosure without patient consent.
0..*Privacy Marks are human-readable security labels on accessed electronic information, such as markings rendered in the user interface or in a printout.
Per ISO 22600-3 (Section A.3.4.3), privacy marks are 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.
In the US, the norm of confidentiality protections under HIPAA are the baseline policy. Privacy laws that preempt HIPAA by offering more stringent protections and heightened levels of confidentiality protection are assigned Security Labels with more restrictive Confidentiality Tag, i.e., R (restricted), for example, some state laws related to adolescent health or an individual’s HIV status.
In the US, information governed by privacy laws, which do not preempt HIPAA, such as protections under FTC, Workers Compensation, or Gramm-Leach-Bliley Act, will be assigned the Confidentiality Tag M (moderate).
Information governed by policies addressing ad hoc, extremely sensitive information, such as victim of abuse or a legal hold, are typically assigned V (very restricted) by privacy officials.
Sensitive information is data that must be protected from unauthorized access and disclosure to safeguard the privacy or security of an individual or organization.
Sensitivity of information may be dictated by law, for example:
Depending on the policy context, the Authority determining information sensitivity may be a jurisdiction, an organization, or an individual. For example:
N, meaning that the normal level of confidentiality protection applies.R, meaning that access/use/disclosure of this PHI is restricted. Under certain circumstances, organizations may determine that PHI is especially vulnerable to risk of stigmatization or harm. Such PHI is labeled with a Confidentiality Code V, meaning that access/use/disclosure is very restricted.R (restricted).M for moderate confidentiality protections afforded by other applicable laws, such as Worker Compensation privacy laws, or by the privacy policies and terms of service of an entity, which may be governed by Federal Trade Commission privacy laws.
IG © 2023+ HL7 Security Working Group. Package hl7.fhir.uv.security-label-ds4p#1.0.0 based on FHIR 4.0.1. Generated 2023-04-17
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change