Publish-box (todo)

6.1.1 Security Labels

Security 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",
    "meta" : {
      "security" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",
        "code" : "DELAU"     
      },{       
        "system" : "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",       
        "code" : "R" }
        ]
      },
    "type" : "searchset",
  ... other headers etc.....
    "entry" : [
       ... other entries ....
       {
         "resource": {
           "resourceType" : "Observation",
           "id" : "1",
           "meta" : {
              "security" : [{
                "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode",             
                "code" : "ETHUD" 
              },{             
                "system" : "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",             
                "code" : "R" }
                ]
              },
           ... 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.

The Security Label vocabulary has three patterns of use: (1) Bundle: Security/Privacy considerations of a data set, (2) Context: Describe security/privacy context of a request for data, and (3) Meta Data: to indicate security/privacy meta about that data.

Bundle: A bundle is a container for a collection of data. Some uses of bundle are for communicating search results, sending data, or persisting data (See Bundle). The Bundle would carry meta about the data contained in the bundle. Specifically the confidentiality 'high water" mark, the authorized purposeOfUse, the required compartment clearance, Refrain, and Obligations that must be maintained. Where the "high water" mark is an indication of the most high confidentiality. Depending on Policy, the Bundle might include the cross-section of sensitivity or integrity, although this is usually not included. Provided in the Security Label Event Examples valueSet contains of some security-label codes that would be used on Bundle.meta.security.

Context: Requests (e.g. Read, Query, message triggers) - would describe the context of the request using purposeOfUse and compartment/clearance. The request might declare the highest confidentiality desired. It is unlikely to see in a request a declaration of sensitivity or integrity. It is also unlikely to see Obligations within a Request. (See Bundle for Response, where these are appropriate)

Meta Data: All resources have a meta.security element to hold descriptions (meta) about the data relative to privacy and security risk. Thus data may be tagged with confidentiality, sensitivity, and integrity. The data might be tagged with the indication of collection context using compartment or purposeOfUse. Data would not typically be tagged with Refrain, or Obligations. Provided in the Security Label Data Examples valueSet contains of some security-label codes that would be used on data.

More complex use of tagging in the data resource, bundle, context, or in Provenance, is possible.

Name/ Tag	Description
Context of Use
Purpose of Use	These Purpose of Use (system = http://terminology.hl7.org/CodeSystem/v3-PurposeOfUse) is an indication of a reason for performing one or more operations on information. which may be permitted by source system's security policy in accordance with one or more privacy policies and consent directives. Such as collecting personal health information for research or public health purposes. Notes may be used as: The rationale or purpose for a request for data The use limitation on a data Bundle See discussion on HCS below
Data Sensitivity
Confidentiality codes	These confidentiality class (system = http://terminology.hl7.org/CodeSystem/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 about 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 report is rarely particularly confidential The confidentiality of a bundle is always as confidential as the most confidential resource in the bundle The additional security labels are more specific to support very specific fine-grained access control and should always be used in association with an appropriate confidentiality label. See discussion on HCS below
Control of Flow
Delete After Use: Obligation .DELAU	An application receiving a resource with this label must delete all copies after the immediate use for which the data was exchanged, is complete. Notes: This may imply a prohibition not storing the resource in any audit trail as well Additional security labels can 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: Refrain .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 can 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
Test Data: Purpose Of Use .HTEST	This marks that a resource has been created to test an application, and is not real production data Notes: Most testing is performed on dedicated test systems where all the data is test data Some testing is performed on production systems, which is where this security label is used This is a security label because different access control rules may apply to test resources

6.1.1.3 Break the Glass

Break-the-glass, or break-glass, as it's called within some EHR systems, refers to a procedure that enables a clinician or end user who doesn't have access privileges to gain access to ePHI in emergency circumstances. The name comes from the old-fashioned manual fire alarms that required their users to break a pane of glass before activating the alarm. The idea was that accidental contact wouldn't be forceful enough to break the glass, preventing the alarm from being triggered by mistake. Break-the-glass protocols typically involve alerting and control mechanisms, such as a pop-up screen warning the data about to be accessed is sensitive and restricted. Break-the-glass is a privileged function that is only given to the most trusted clinicians.

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 extra-authorized access to the patient's record. The clinician would need to have authorization to declare break-the-glass, and the act of breaking the glass would result in audit logs that would alert the Safety office and the Privacy office.

break the glass

http://terminology.hl7.org/CodeSystem/v3-ActReason#BTG

To perform policy override operations on information for provision of immediately needed health care for an emergent condition affecting potential harm, death or patient safety by end users who are not provisioned for this purpose of use. Includes override of organizational provisioning policies and may include override of subject of care consent directive restricting access. ...

While the principle of break-the-glass is understood, implementing it well has some challenges. Often break-the-glass is only implemented within an EHR system, and not exposed in an interoperability standards way. This section indicates some methods to indicate break-the-glass as a purpose of use , but does not define any policy or protocol around such requests. At a minimum, implementations must ensure:

• When and why to initiate the break-the-glass.
• How to initiate the break-the-glass.
• 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 break the glass example.
• How does the clinician know that break-the-glass is an option. An example OperationOutcome that might be used to indicate potential for break-the-glass.

The following are some potential methods of declaring break-the-glass. The first one uses OAuth 2 to request an access token under break-the-glass conditions, placing the authorization decision within the security layer. The second one simply declares break-the-glass in the http request, relying on the Resource Server to confirm that break-the-glass is legitimate, authorized, and traced.

6.1.1.3.1 using OAuth

When using the OAuth 2 client credentials grant, which has no user interaction, some profiles of OAuth 2 support passing the requested purpose of use in the access token request. In this case HL7 defines the break-the-glass as a purpose of use .

For example in HL7 UDAP Security , the purpose of use can be requested using hl7-b2b OAuth extension:

    "extensions" : {  
      "hl7-b2b" : {  
        "subject_name": "Dr. John Smith",
        "organization_name": "Central Hospital",
...
        "purpose_of_use": [
          "http://terminology.hl7.org/CodeSystem/v3-ActReason#BTG",
          "http://terminology.hl7.org/CodeSystem/v3-ActReason#TREAT"
          ]
      }}
  

When using the OAuth 2 authorization code grant, the authorization server may provide User Interface interactions to request break-the-glass permission, confirm the urgency, and capture the rationale.

In either case, the authorization server either grants or denies the request, logging the decision. If granted, the access token indicates break-the-glass authorization with expanded permissions, and the resource server enforces this elevated permissions.

6.1.1.3.2 using http Category

This solution utilizes an http header, specifically a draft ietf specification for a web category . The break-the-glass is indicated in the request as a web category on what would be an otherwise normal FHIR http interaction. This indicates to the Resource Server that the request is under break-the-glass conditions. The Resource Server would need to make sure that the user is allowed to declare break-the-glass, and then respond with different results based on this break-the-glass:

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"

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 . Note the use of "security label" is used broadly in FHIR for all security tags. There is a more formal definition in the security labeling community of "security label" that refers to an overall assessment, in HL7 this would be represented with a value from the ConfidentialityCode value set. For more detailed on how to implement security tagging and labeling, HL7 has published Data Segmentation for Privacy Implementation Guide for FHIR

Type of security metadata observation made about the classification of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security classification is defined by ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-1995 as: "the determination of which specific degree of protection against access the data or information requires, together with a designation of that degree of protection."

Security classification metadata is based on an analysis of applicable policies and the risk of financial, reputational, or other harm that could result from unauthorized disclosure.

Tag Set	Car.	Description	Example Tags
Confidentiality	1..1	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.	Unrestricted, Normal, Very Restricted

6.1.1.4.0.1 Security Category

Type of security metadata observation made about the category of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security category metadata is defined by ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-1995 as: "a nonhierarchical grouping of sensitive information used to control access to data more finely than with hierarchical security classification alone."

Tag Set	Car.	Description	Example Tags
Policy	0..1	Security label metadata that segments an IT resource by conveying a mandate, obligation, requirement, rule, or expectation relating to its privacy.
Sensitivity	0..*	Security label metadata that segments an IT resource by categorizing the value, importance, and vulnerability of an IT resource perceived as undesirable to share.	STD, HIV, SUD
Compartment	0..*	Security label metadata that segments an IT resource by indicating that access and use is restricted to members of a defined community or project.	Care Team, Research Project
Integrity	0..*	Security label metadata that segments an IT resource by conveying the completeness, veracity, reliability, trustworthiness, and provenance of an IT resource.	Anonymized, Digitally signed
Provenance	0..*	Security label metadata that segments an IT resource by conveying the provenance of the IT resource's asserted or reported source.	Patient reported, Clinician asserted
Trust	0..*	Security label metadata that segments an IT resource by conveying the basis for trusting the source.	Trust Accreditation, Trust Agreement

6.1.1.4.0.2 Security Control

Type of security metadata observation made about the control of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security control metadata conveys instructions for secure distribution, transmission, storage or use.

Tag Set	Car.	Description	Example Tags
Purpose of Use	0..*	Security label metadata that segments an IT resource by conveying the reason for performing one or more operations on information, which may be permitted by source system's security policy in accordance with one or more privacy policies and consent directives.	Treatment, Payment, Operation, Research
General Purpose of Use	0..*	Security label metadata that segments an IT resource by conveying the reason for performing one or more operations on information of purpose of use at a general level.	Coverage, Patient Requested, Emergency Treatment
Obligation **	0..*	Security label metadata that segments an IT resource by conveying the mandated workflow action that an information custodian, receiver, or user must perform.	Encrypt, mask, comply with policy
Refrain **	0..*	Security label metadata that segments an IT resource by conveying actions which an information custodian, receiver, or user is not permitted to perform unless otherwise authorized or permitted under specified circumstances.	Do not disclose without consent, no reuse

(**) Privacy-revealing Obligation or Refrain tags such as the Obligation Policy MASK (mask) or the Refrain Policy NODSCLCD (no disclosure without consent directive), shall not be included in the high-watermark labels of a Bundle, DocumentReference, or Message Resources.

Other Value-sets are defined by the FHIR DS4P IG .