STU3 Candidate

This page is part of the FHIR Specification (v1.8.0: STU 3 Draft). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

6.1.1 Security Labels

FHIR Infrastructure Work Group Maturity Level : N/A Ballot Status : STU 3

A security label is a concept attached to a resource or bundle that provides specific security metadata about the information it is fixed to. The Access Control decision engine uses the security label together with any provenance resources associated with the resource and other metadata (e.g. the resource type, resource contents, etc.) to

  • approve read, change, and other operations
  • determine what level of the resource can be returned
  • determine what handling caveats must be conveyed with the data

Security Labels enable more data to flow as they enable policy fragments to accompany the resource data.

The intent of a security label is that the recipient of resources or bundles with security-tags is obligated to enforce the handling caveats of the tags and carry the security labels forward as appropriate.

Security labels are only a device to connect specific resources, bundles, or operations to a wider security framework; a full set of policy and consent statements and their consequent obligations is needed to give the labels meaning. As a consequence of this, security labels are most effective in fully trusted environments - that is, where all trading partners have agreed to abide by them in a Mutual Trust Framework. Note also that security labels support policy, and specific tagging of individual resources is not always required to implement policy correctly.

In the absence of this kind of pre-agreement, Security Labels may still be used by individual parties to assist with security role checking, but they may not all be recognized and enforced, which in turn limits what information is allowed to flow.

Local agreements and implementation profiles for the use security labels should describe how the security labels connect to the relevant consent and policy statements, and in particular:

  • Which Security Labels are able to be used
  • What to do if a resource has an unrecognized security label on it
  • Authoring obligations around security labels
  • Operational implications of security labels

This specification defines a basic set of labels for the most common use cases trading partners, and also a wider array of security labels that allow much finer grained management of the information.

6.1.1.1 Representing Security Labels

A security label is represented as a Coding , with the following important properties:

system The coding scheme from which label is taken (see code system URI , and below)
code a code from the coding scheme that identifies the security label and code is an value from the code system
display The display form for the code (mostly for use when a system doesn't recognize the code)

An XML patient resource with a "celebrity" tag associated with it, as represented in an HTTP response: 

<Patient xmlns="http://hl7.org/fhir">
  <meta>
    <security>
      <system value="http://hl7.org/fhir/v3/ActCode"/>
      <code value="CEL"/>
      <display value="Celebrity"/>
    </security>    
  </meta>
...  [snip] ...
</Patient>

A JSON search result that includes a resource that the receiving application must delete all copies of the resource after using it: 

{
  "resourceType" : "Bundle",
  "type" : "searchset",
  ... other headers etc.....
  "entry" : [
     ... other entries ....
     {
       "resource": {
         "id" : "1",
         "meta" : {
           "security" : [{
             "system" : "http://hl7.org/fhir/v3/ActCode",
             "code" : "DELAU",
             "display" : "delete after use"
           }]
         }
         ... other content etc.....
       }
     },
     ... other entries ....
  ]
}

Note: the actual terms used in these examples are described below.

The basic framework for security labels is described by the HL7 Healthcare Classification System (HCS; ref todo). This specification identifies how security labels are defined and provides a relatively comprehensive list of labels. All of the HCS defined labels (see below for the lists) can be used as security labels on FHIR resources and bundles (e.g. requests and responses).

In addition, other security labels not defined here or in the HCS can be defined by jurisdictions, vendors and/or projects and used as appropriate. However, note that:

  • Defining additional security labels will increase costs associated with information and system portability
  • Implementation guides and applications SHOULD always use the applicable label defined by the HCS if one exists

Note: The use of security labels and the expression of common shared security policies is a matter of ongoing discussion and development in several communities at this time.

6.1.1.2 Core Security Labels

This specification defines a set of core security labels for all FHIR systems. All conformant FHIR Applications SHOULD use these labels where appropriate. For all of these labels, how they are operationalised - their use and interpretation - is subject to the applicable Mutual Trust Framework agreement as described above. These codes all come from one of two code systems: http://hl7.org/fhir/v3/Confidentiality, and http://hl7.org/fhir/v3/ActCode,

Name/ Tag Description
Context of Use
Confidentiality codes These confidentiality class (system = http://hl7.org/fhir/v3/Confidentiality) can be applied to any resource or bundle. They are generally assigned by the author of the resource, but can be modified subsequently as a matter of operational management. The Confidentiality classifications describe the sensitivity of the information in a resource with regard to whether it should made available or disclosed to unauthorized individuals, entities, or processes.
Notes:
  • In the absence of a confidentiality code, the basic confidentiality of a resource may be implied by its definition and content; e.g. a patient's condition is far more likely to be confidential than a practitioner resource, and a Diagnostic Report with an HIV test is always highly confidential, whereas a routine electrolytes is rarely particularly confidential
  • A few resources have a confidentiality code in the resource itself. This should always be understood as the original intended confidentiality, whereas a confidentiality tag is the current confidentiality of the content; e.g. the confidentiality may change in response to patient concern
  • The confidentiality of a bundle is always as confidential as the most confidential resource in the bundle
The additional more specific labels below are defined to support very specific fine-grained access control, and should always be used in association with an appropriate confidentiality label.
Celebrity / VIP: ActCode. CEL Use on any resource to indicate that the subject/patient is a celebrity or well known to the staff in the institution.
Notes:
  • This may be applied to the Patient resource, with implied behavior for the entire patient compartment , or it may be applied to individual resources
  • Resources affected by this label are more likely to be the subject of active audit maintenance or additional security policy
Staff: ActCode. EMP Use on a Patient resource and resources with a subject of that patient to indicate that the patient is a staff member of the institution. This is a variation on being a celebrity.
Notes:
  • This may be applied to the Patient resource, with implied behavior for the entire patient compartment , or it may be applied to individual resources
  • Resources affected by this label are (even) more likely to be the subject of active audit maintenance or additional security policy
Keep information from patient: ActCode. TBOO Used on any resource to indicate that information is not to be made available to the patient or their relatives/carers, except by the personal decision of a physician assigned to the patient.
Notes:
  • A common use for this is with Flag resources, when the alert records information on patient abuse or non-compliance
  • This label might also be used temporarily on laboratory or other test results where policy is for the results to be initially disclosed by direct discussion with the patient's physician
Contact/Employment Details Confidential: ActCode. DEMO Used on a Patient resource to indicate that the patient's address and contact details (phone numbers, email addresses) - including employment information - are sensitive and shouldn't be shared with the patient's family or others without specific authorization
Diagnosis-related confidentiality: ActCode. DIA Used on any resource to indicate that the resource relates to a diagnosis (or potential diagnosis) which is generally associated with confidentiality requirements - or is for this particular patient. This may be associated for diagnoses including STDs, psychiatric conditions, adolescent related issues, drug abuse, genetics conditions and others.
Notes:
  • Generally, this security label cascades logically; e.g. any Diagnostic Reports produced because of a Diagnostic Request with this security label should also have the same security label.
  • There may be additional labels classifying the diagnosis; such labels SHOULD always be accompanied by this label so that more systems will know that restrictions apply
Author Consent needed: ActCode. ORCON The author's consent is needed for disclosure. Typically, this is used by a treating practitioner to label portions of their own record confidential. Any such resource is only shared with the author or with other parties as arranged.
Control of Flow
Delete After Use: ActCode. DELAU An application receiving a resource with this label must delete all copies after the immediate use for which the resource/feed was exchanged is complete.
Notes:
  • This may imply a prohibition not storing the resource in any audit trail as well
  • Additional security labels are allowed to make exceptions to the blanket restriction this implies. This allows a resource to be exchanged with a blanket rule not to retain copies unless the exact rules for retaining it can be followed
Do Not Re-use: ActCode. NOREUSE An application receiving a resource with this label may only use it for the immediate purpose of use. In particular, the application is not authorized to re-distribute (i.e. exchange this resource with any other application).
Notes:
  • The exact interpretation of "immediate purpose of use" and the boundaries of "the application" are determined by local policy
  • Additional security labels are allowed to make exceptions to the blanket restriction this implies. This allows a resource to be exchanged with a blanket rule not to re-use unless the exact rules for doing so can be followed

6.1.1.3 Break The Glass

There is a special security label to support the commonly encountered "break-the-glass" protocol, where a clinician (usually in an emergency context) requests emergency unauthorized access to the patient's record. This specification does not make any policy recommendations or rules about the operation, merely provides support for it. See this paper for discussion of the issues involved in break-the-glass operations.

When the operation occurs, it is represented as a security label on the request, rather than on a resource, and so is represented differently. The break the glass tag needs to be used as part of an agreed policy and protocol. FHIR does not attempt to define this policy or protocol, it must be agreed on an implementation by implementation basis. For example as a URL:

Break The Glass http://hl7.org/fhir/security-label#break-the-glass The requester is asking for emergency access for patient treatment. Typically, this means that the patient is unconscious and not able to provide relevant information or consent.

The URL is represented in the request as a web category : 

HTTP/1.1 GET fhir/Patient/482735/condition
Content-Type: text/xml
Access-Control-Allow-Origin: *
Last-Modified: Thu, 19 Nov 2013 07:07:32 +1100
ETag: 24
Category: http://hl7.org/fhir/security-label#break-the-glass; scheme="http://hl7.org/fhir/tag/security"; label="Break The Glass"

6.1.1.4 Healthcare Privacy and Security Classification System (HCS)

The security labels described above are a subset of the full set of security labels defined by the HL7 Healthcare Privacy and Security Classification System (HCS; ref todo). The HCS defines 5 categories of security labels that may be applied to a resource:

Security Label Card. Values Description
Confidentiality Classification 0..1 ConfidentialityClassification Security label metadata classifying an IT resource (clinical fact, 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.
Example Uses: Unrestricted, Normal, Very restricted
Sensitivity Category 0..* InformationSensitivityPolicy Security label metadata that "segments" an IT resource by categorizing the value, importance, and vulnerability of an IT resource perceived as undesirable to share.
Example Uses: STDs, Psychiatric care, Celebrity status
Compartment Category 0..* Compartment Security label metadata that "segments" an IT resource by indicating that access and use is restricted to members of a defined community or project
Note: this is a different use of "Compartment" to the Patient Compartment use.
Example Uses: Research, HR records
Integrity Category 0..* SecurityIntegrityObservationValue Security label metadata that "segments" an IT resource by conveying the completeness, veracity, reliability, trustworthiness, and provenance of an IT resource
Example Uses: Anonymized, signed, patient reported
Handling Caveat 0..* SecurityControlObservationValue Security label metadata conveying dissemination controls and information handling instructions such as obligations and retention policies to which an IT resource custodian or receiver must comply.
This type of handling caveat SHALL be assigned to a clinical fact if required by jurisdictional or organizational policy, which may be triggered by a patient consent directive
Example Uses: do not disclose, various restrictions on use, and policy marks

Each of these security labels identifies a ValueSet that lists a set of possible codes for the security label.

6.1.1.4.1 Jurisdiction Specific Security Labels

The HL7 Healthcare Classification System also allows for Realm-specific privacy law or policy category codes for use in security labels in particular domains. These domains are included with this specification:

Security Label Card. Values Description
US Privacy Law 0..* ActUSPrivacyLaw Security label metadata that "segments" an IT resource by indicating the legal provisions to which the assignment of a Confidentiality Classification complies in the US.