Using Inline Security Labels in the FAST Directory IG

HL7 FHIR at Scale Taskforce (FAST) National Directory of Healthcare Providers & Services (NDH) Implementation Guide (IG) addresses the use cases for sharing information about providers via FHIR resources and making them discoverable via FHIR APIs and through various query mechanisms.

One of the requirement in these use cases is to mark certain granular data to be subject to specific protective policies. For example, the location of a women’s shelter may be considered sensitive information to ensure that access to this data element is restricted.

The current IG defines a rather complex mechanism for modeling such requirements:

• The Consent resource is profiled for modeling such restrictions. This profile defines an extension (called restrictFhirPath) to point to specific elements using FHIRPath expressions.

• Through the use of another extension (called base-ext-usage-restriction) a resource can point to a consent that carries the restrictions and include pointers to the restricted elements.

• The IG also requires that the Consent instance be embedded within the resource as a contained resource.

There are some issues with this approach: Policies like the one in this example usually apply to many resources. For example, restricting access to the location of women’s shelter usually applies to all such resources or a group of them (e.g., those in a particular jurisdiction). Embedding the policy within the resource leads to significant redundancy by repeating the same policy on each resource. Aside from adding to the volume of the data, this redundancy also makes it onerous to update the policy. If the overarching policy about the location of women’s shelter changes, for example, all of the resource instances need to be updated in order to change the embedded policy. This can be a costly and inefficient process which may also lead to inconsistencies –if for some reason some instances are not updated and end up bearing old policies. Generally, if a policy applies to many resources, it should be stored in a single place to avoid such redundancy and its negative consequences.

On the other hand, in this approach, if the consent policy is separated from the resource, determining whether a resource is subject to restrictions becomes complex. Because the link to the protected parts of the resource are in the consent, it is not clear by simply looking at a resource whether any restriction would apply. At the time of processing a resource (e.g., in response to a query), all consents need to be examined, and all the FHIRPath expressions in them have to be evaluated to find whether any of them may be applicable. This can be improved to some extent by using search parameters to narrow down the consents that should be examined but it is ultimately an inefficient process and would not scale well if the number of policies or FHRPath expressions grow.

Using Inline Labeling

The FHIR Data Segmentation for Privacy (DS4P) Implementation Guide has already addressed this use case through inline labeling.

To cover this requirement using the FHIR DS4P IG extensions the following mechanism should be used:

• Tag the resource with the PROCESSINLINELABEL security label (in the meta.security element) to indicate that there are inline labels in the resource and help the implementers decide whether a deep inspection is needed to identify element-level labels.

• Use the extension-inline-sec-label to record a sensitivity or confidentiality label directly on the sensitive element, for example, the location element in the HealthcareService for the women’s shelter.

• If needed, use the sec-label-related-artifact-extension on the resource (or the element) to point to a consent resource that models the applicable policy.

An example of this is given below:

{
  "resourceType": "HealthcareService",
  "id": "HealthcareServiceWomenShelter",
  "meta": {
    "lastUpdated": "...",
    "profile": [
      "http://hl7.org/fhir/us/ndh/StructureDefinition/ndhEx-HealthcareService"
    ],
    "security": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
        "code": "PROCESSINLINELABEL",
        "extension": [
          {
            "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-related-artifact",
            "valueRelatedArtifact": {
              "type": "depends-on",
              "resource": [
                {
                  "reference": "Consent/consent-usage-restriction"
                }
              ]
            }
          }
        ]
      }
    ]
  },
  "identifier": "....",
  "name": "Womens shelter",
  "active": true,
  "category": "...",
  "type": "...",
  "location": [
    {
      "reference": "Location/LocationWomenShelter",
      "display": "The W Womens Shelter",
      "extension": [
        {
          "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-inline-sec-label",
          "valueCoding": {
            "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
            "code": "R",
            "display": "restricted"
          }
        }
      ]
    }
  ],
  "telecom": "..."
}

In this approach, sensitive elements are tagged directly which enables a straightforward mechanism for the implementer to invoke additional access control when handling a resource by simply examining whether inline labels exist, and if the answer is yes, inspecting the resource to find the labeled elements.

If a usage policy applies, it is modeled as a single consent rather than being repeated as part of every resource with sensitive elements. Therefore, if the policy ever changes, it can be updated once and would apply to all resources covered by the policy.

Note that in some cases, the labeling alone may be sufficient and the applicable restrictions may be implied by broader rules as part of the service agreement.

I think considering this is a common class of sensitive information in health and social care, sensitive location and sensitive contact information probably deserve their own dedicated sensitivity category reflected by a standard code. This is something that a future update to the FHIR DS4P IG should consider.

A final point about this is on the use of Consent resource. Using Consent to carry general access policy in this manner is not quite semantically aligned with the purpose of the consent resource. Consent is a specific type of policy fragment set by patients (or someone on their behalf) that articulate some rules about the use of their data. It is understandable that in the R4 version of FHIR this was the only way to express a policy, but in the later versions of FHIR, the Permission resource was added for capturing more generic access control policy that are not necessarily tethered to a patient of their data.

Tweet