This page is part of the FHIR Specification (v4.0.1: R4 - Mixed Normative and STU ) in it's permanent home (it will always be available at this URL). (v4.2.0: R5 Preview #1). 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 : 3

Standards Status : Trial Use

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 resources 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. Because 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 might not all be recognized and enforced, which in turn limits what information can 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 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:

<Patient xmlns="http://hl7.org/fhir">
  <meta>
    <security>
      <system value="http://terminology.hl7.org/CodeSystem/v3-Confidentiality"/>
      <code value="R"/>
      <display value="Restricted"/>
    </security>
  </meta>
...  [snip] ...
</Patient>

{
  "resourceType" : "Bundle",
  "type" : "searchset",
  ... other headers etc.....
  "entry" : [
     ... other entries ....
     {
       "resource": {
         "id" : "1",
         "meta" : {
           "security" : [{
             "system" : "http://terminology.hl7.org/CodeSystem/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 . This specification identifies how security labels are defined and provides a relatively comprehensive list of labels. All 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.

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 these labels, how they are operationalized - their use and interpretation - is subject to the applicable Mutual Trust Framework agreement as described above.

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 purpose of use label is represented as a security label on the request, rather than on a resource, and so 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://terminology.hl7.org/CodeSystem/v3-ActReason#BTG; scheme="http://hl7.org/fhir/tag/security"; label="break the glass"

While the principle of break-the-glass is well understood, implementing it well has some challenges. This specification defines a method to represent break-the-glass in an HTTP request, but does not define any policy or protocol around such requests. At a minimum, implementations must ensure:

• How, when and why to initiate the break-the-glass is well understood
• Appropriate authorization, consent checking, and access control is used to ensure it is used properly (e.g. if using OAuth, checking that the Authorization Server allows this)
• Any use is well-represented in an AuditEvent (todo: profile for break the glass) glass example .
• Note an example OperationOutcome that might be used to indicate potential for break-glass .

See this paper for discussion of the issues involved in break-the-glass operations.

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 . The HCS defines 5 categories of security labels that may be applied to a resource:

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 specific domains. These domains are included with this specification: