An API for the Security Labeling Service (SLS)
- 9 minsAn essential component in the implementation of data segmentation for privacy (DS4P), security labeling service (SLS) is a software service that determines the security labels for a data item such a FHIR resource.
In order to communicate with the SLS, the client needs to submit the data in a request and receive the labels, perhaps incorporated into the data in the form of labeled data. There is currently no standard specification for such an interface.
Last year, for an academic project at Arizona State University, I added a very simple and rudimentary implementation of a SLS for FHIR resources to the LEAP Consent Decision Service code base. This service only works with FHIR data and does not accept other formats like CDS or HL7v2.
Since I had to decide on an interface for this API, I used the simplest possible interface: plain FHIR. The request body is either a FHIR resource or a FHIR Bundle
containing a collection of resources, and the response body is identical to the request except that labels are added to the resource(s) if applicable. A labeled FHIR resource is a resource with the security labels added to its meta.security
attribute.
Although this API was good enough as a proof of concept and for demos, it lacks some of the more sophisticated features. A more advanced SLS API needs to support the following:
-
Labeling Parameters: The client should be able to specify parameters about the labeling, for example, specify that it is requesting to assign sensitivity labels only.
-
Transaction Context: In cases where the labeling depends on the context of the transaction, transaction attributes such as the purpose of use or the identity of the requester should be communicated as part of the request. For example, assigning handling instruction labels may be specific to a recipient or the purpose of use for the transaction.
-
Related Data: In some cases, a granular FHIR resource alone is not sufficient for making a decision about the labels and other related data such as the context of the encounter or the organization where the data originates from are also important. Such related resources should be provided to the SLS in order to make the labeling decision.
-
Asynchronous Calls: When computationally heavy processing is involved (e.g., processing large volumes of unstructured text), the SLS may not be able to respond with the latency appropriate for a synchronous API call. Asynchronous API calls enable the SLS to involve such computations in the labeling process.
Among the available APIs around FHIR specifications, the CDS Hooks API (designed for interacting with a clinical decision support system) seems to be suitable for the SLS:
-
The
context
parameter in the request enables providing the data to be labeled as well as any other parameters for labeling. These parameters can be defined and documented as part of the specifications for the hook. This addresses (1) and (2). -
The
fhirAuthorization
attribute provides a mechanism for enabling the SLS to retrieve additional related FHIR resources that may be needed for labeling directly from a FHIR server. This is made possible by providing the SLS with an authorization token for the FHIR server as part of the request. This addresses (3). -
The
systemActions
attribute in the CDS hooks response can be leveraged to return labeled resources in the form ofupdate
actions. This also allows the SLS to only return resources that bear new labels (and leave out any other resources that does not need to be labeled) leading to a shorter response. -
As for (4), asynchronous calls are not supported by the current specifications of CDS hooks but if future SLS implementations really need this feature it can be added as an extension.
As a proof of concept, I added a CDS hooks interface for the SLS in LEAP-Consent Decision Service. A sample request and response is shown below.
The request includes two observations one of which is sensitive and the other is not. This is submitted as an attribute named bundle
under the context
attribute of the request which takes a FHIR Bundle
resource:
{
"hookInstance": "...",
"hook": "bundle-security-label",
"context": {
"bundle": {
"resourceType": "Bundle",
"entry": [
{
"fullUrl": "https://fhir.example/Observation/O1",
"resource": {
"resourceType": "Observation",
"id": "O1",
"status": "final",
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "724713006",
"display": "Harmful use of ketamine (disorder)"
}
]
},
"subject": {
"reference": "Patient/f201",
"display": "Roel"
},
"issued": "2013-04-04T14:34:00+01:00",
"performer": [
{
"reference": "Practitioner/P202",
"display": "Luigi"
}
],
"valueBoolean": true
}
},
{
"fullUrl": "https://fhir.example/Observation/O2",
"resource": {
"resourceType": "Observation",
"id": "O2",
"status": "final",
"code": {
"coding": [
{
"system": "http://acmelabs.org",
"code": "104177",
"display": "Blood culture"
},
{
"system": "http://loinc.org",
"code": "600-7",
"display": "Bacteria identified in Blood by Culture"
}
]
},
"subject": {
"reference": "Patient/f201",
"display": "Roel"
},
"issued": "2013-03-11T10:28:00+01:00",
"performer": [
{
"reference": "Practitioner/f202",
"display": "Luigi"
}
],
"valueCodeableConcept": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "3092008",
"display": "Staphylococcus aureus"
}
]
}
}
}
]
}
}
}
The response includes one update
action under the systemActions
attribute which includes the labeled resource (only the one that needed labeling). Note that the LEAP-CDS SLS also adds the basis for labeling (references to the rules and policies based on which the labels were determined) using the sec-label-basis
extension from the FHIR DS4P IG.
{
"cards": [],
"systemActions": [
{
"type": "update",
"description": "labeled resource",
"resource": {
"resourceType": "Observation",
"id": "O1",
"status": "final",
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "724713006",
"display": "Harmful use of ketamine (disorder)"
}
]
},
"subject": {
"reference": "Patient/f201",
"display": "Roel"
},
"issued": "2013-04-04T14:34:00+01:00",
"performer": [
{
"reference": "Practitioner/f202",
"display": "Luigi"
}
],
"valueBoolean": true,
"meta": {
"security": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality",
"code": "R",
"display": "restricted",
"extension": [
{
"url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-basis",
"valueCoding": {
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "42CFRPart2",
"display": "42 CFR Part2"
}
}
]
},
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "SUD",
"display": "substance use disorder information sensitivity",
"extension": [
{
"url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-basis",
"valueCoding": {
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "42CFRPart2",
"display": "42 CFR Part2"
}
},
{
"url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-sec-label-basis",
"valueCoding": {
"system": "sample-rule-1",
"code": "ketamine"
}
}
]
}
]
}
}
}
]
}