Skip to end of metadata
Go to start of metadata

Security Labeling Track links

Github repository


The goal of the track is to test the capabilities of a FHIR® server in processing Security Labels in accordance with the FHIR® Data Segmentation for Privacy Implementation Guide (DS4P IG).




Participant Interest, Role, Component and Activities & some zoom chat



Mohammad Jafari

VA/Book Zurman

Track Co-Lead and FHIR DS4P IG Author.  Set up Vonk Server with  Pauldron Proxy Authorization Service for track tests.


Kathleen Connor

VA/Book Zurman

Security WG Cochair, Track Co-Lead and FHIR DS4P IG Author.  Half set up a Vonk Server late in the game. Track scribe.


Chris Shawn


VHA Security WG Cochair interested in implementations of FHIR Security Labels and DS4P.


Eric Heflin

eHealth Exchange

Interested in how to implement CUI for eHealth Exchange. Questions about what CUI codes are needed, and how to assign them.


Duane Decouteau

Saperi Systems

Integrated FHIR Security Labeling Service (SLS) into Hapi FHIR as part of the San Diego Health Connect ONC LEAP FHIR Consent Grant. SLS is an HL7 Standard.  A docker image of SLS will be made available as soon as Duane is able to reconcile remaining issues from this track.


Jerry Goodnoug

Cognitive medicine

Provided assistance with locating a Synthea patient with sensitive conditions for Duane to test in SLS.


Frank Yang


Google Cloud Healthcare API - Connectathon test R4 endpoint up.  Able to implement DS4P extensions and past test scripts, but not Security Labeling. May be future work.

Collaborated with Mohammad on setting up Google API access to run test scripts.

Frank offered insightful comments on issues that others were having.


Ceila Wong


Allscripts has CDA DS4P at header.  Allscript did not have a FHIR server that supports Security Labeling, but two of their product owners were present and mentioned that they’re in the planning phase for implementing SLS, and wanted to learn from others’ experience in implementing it.


Dave Pyke

Ready Computing

Signed up but did not attend.


Gary Dickinson

EHR Standards Consulting

Signed up but did not attend.


Didi Davis

The Sequoia Project

Signed up but did not attend.


Ian Bacher

Brown University

Signed up but did not attend.


Michael McCune

eHealth Exchange

Signed up but did not attend.


Stoyan Halkaliev

NursIT Institute GmbH

Signed up but did not attend.


Keerthivasan Ramanathan

AigilxHealth Technologies Pvt Ltd

Signed up but did not attend.


Linus Österlund

RCC Väst

Signed up but did not attend.

RCC Väst


 Alan Scott

Red Hat

Signed up but did not attend.


Terrie Read

Reed McCullough, LLC

Signed up but did not attend.


Beatrice Nilsson

Regionalt cancercentrum

Signed up but did not attend.


Sudhansu Mishra

Signed up but did not attend.



The participants are expected to provide a FHIR server that meets the requirements of the track. The following are the minimum requirements:

  • The FHIR Server must provide a CapabilityStatement resource at the /metadata endpoint with an Implementation
  • Guide attribute that includes the following:

  • The FHIR Server is capable of accepting labeled resources including labels bearing the extensions defined by the DS4P IG by ensuring the labels (including the extensions) are persisted.
  • The FHIR Server enforces the 1..1 cardinality constraint for confidentiality labels by either:
    • Rejecting a labeled resource that does not bear a confidentiality label, or
    • Labeling the resource after accepting it and assigning a confidentiality label to it.
  • The FHIR Server is capable of adding high-watermark confidentiality label to a response bundle based on the contents of the bundle.
  • (bonus) Supporting high-watermark on the response bundle for other types security labels (other than confidentiality).

Running the Test Scripts

You can run the test scripts provided in this repository by following the steps below. As prerequisites, you will need node.js and yarn installed in your environment.

  • Clone the repository and change directory to the repository:

git clone
cd hl7-fhir-connectathon-may2020-sec-labeling-track

  • Install the dependencies:

yarn install

  • Create a config file named .env.test and set the value of FHIR_BASE to the base URL of your FHIR server (no trailing slash). See .env.test.example as an example.

echo FHIR_BASE= > .env.test

  • Run the tests and examine the results:

yarn test

From <>


✕ provides a compliant CapabilityStatement at the metadata endpoint (1678ms)

Accepting and persisting labeled resources including extensions

✓ extension-must-display (702ms)

✓ extension-sec-label-basis (759ms)

✓ extension-sec-label-related-artifact (1430ms)

✓ extension-sec-label-classifier (819ms)

Enforce confidentiality label cardinality rules

✕ any labeled resource must have confidentiality label (698ms)

Confidentiality high watermark on bundles

✕ Bundles are labeled with high watermark confidentiality label based on contents (1445ms)


Frank Yang, Google FHIR Server

Frank Yang brought Google Cloud Healthcare API - Connectathon test R4 endpoint up to test ability to accept labeled resources including labels bearing the extensions defined by the DS4P IG by ensuring the labels (including the extensions) are persisted. Frank was able to implement DS4P extensions because the Google server implements extensions in a very generic way.  Frank's system passed the track test scripts, but not Security Labeling. This may be future work.

Duane DeCouteau LEAP Security Labeling and Privacy Protective Service

Duane DeCouteau, Saperi Systems, integrated the FHIR Security Labeling Service developed for the San Diego Health Connect ONC LEAP FHIR Consent Grant to HAPI FHIR server to successfully label outbound sensitive Resources and Bundles.

The SLS integration point is as an Interceptor at the Server_Outgoing_Response hook in the typical server flow.  This was an arbitrary decision. None of the participants could think of a use case for making the Server_Incoming_Request_Post_Processed hook the integration point.

Hapi FHIR SLS Interceptor

Integrate by registering the SLS Interceptor at Pointcut Server_Outgoing_Response, which ties it into the flow.


This Interceptor is where Bundles are decomposed into Resources. Then coded triples (code, code system, and display name) are run against the the SLS 3800 rules based on the SAMHSA VSAC Sensitive Condition Value Set to find specific sensitive information.

Interceptor running Resource codes against VSAC Sensitive Condition Value Set, which is available at

The screenshot below shows where the SLS Interceptor is registered in Hapi, and where it gets called from.

SLS Interceptor in registered in Hapi

Resulted in appropriately labeled Bundle and Resources.  Duane's Privacy Protective Services applied Confidentiality and Sensitivity label tags twice at the Bundle level, but not on the Resources.  He needs to fix that.

Bundle with CUI Marking Banner and Confidentiality and Sensitivity label tags

Jerry Goodnough assisted Duane to find Synthea (synthetic) patients with sensitive conditions. 

The SLS is integrated into the LEAP stack. Duane will make a Connectathon branch for implementers to check out and run a working FHIR SLS implementation in a Docker container.

This SLS implementation is based on the HL7 Security Labeling Service R1 standard. Implementers can use and manipulate it by plugging in their own SLS interceptor into a FHIR Server, sending in Resources and Bundles that are returned with this track's security labels - to prove to themselves that it's doable.  This is quite a benefit to the FHIR Community given that multiple implementers have asked about how to label using FHIR.  

Docker Container with integrated SLS

The LEAP Security Labeling and Privacy Protective Services handle HL7 V2 messages and C-CDA.  However, the V2 processing isn't based on V2 Security Labels.  Rather, the SLS checks the message for mental health related codes against the SAMHSA Sensitive Condition Value Set in VSAC.  If a mental health code is found, the entire message is redacted to prevent HIE dissemination.

Mohammad Jafari VA/BookZurman

Mohammad Jafari's system, which was configured using a Vonk Server, was able to successfully label and persist the track security labels at the Bundle and Resource levels, and to persist the FHIR DS4P IG extensions.

Additionally, Kathleen and Mohammad were able to provide details about both the HL7 Security Labeling Service and the companion HL7 Healthcare Privacy and Security Classification System to participants who had questions about how to do security labeling in FHIR.

Discovered Issues/Questions

Mohammad's Implementation

Mohammad found that HAPI FHIR Server won't persist unrecognized extensions, so will have to upload FHIR DS4P IG Extensions.

Frank's Implementation

Frank's Google FHIR Server does not have Security Labeling Service for assigning HL7 Confidentiality or CUI labels at Bundle and Resource. May be a future enhancement. Mohammad ran the test scripts.  He initially had issues getting authenticated, but that was resolved by the Google team.

From the Zoom chat 5/15 07:41:47 From Mohammad Jafari : Here is the result for the google server. It passes the tests for persisting the extensions and fails the tests for CapabilityStatement, confidentiality, and bundle high watermark

07:42:04 From Mohammad Jafari : I think failing those is expected since you have not implemented an SLS

07:50:20 From Frank Yang : That's right. In our server, extension is implemented in a very generic way. So it doesn't matter what extensions you have, as long as it conforms to FHIR standard, google server will persist them.

But we don't do anything about it. In the future, we'll support profile; then you'll be able to upload IG to google server to instruct the server behaviors.

Frank to team about authenticating to Google Server:

To access the test endpoint, first you need to get an access_token. Please use the following command, and the access_token will be in the printout response:
curl --location --request POST '' \
--header 'Authorization: Basic am94ZUhSNUo0aDJjT1pIOW9WektBTDc5cHVKWmlveFI6Mmh5SzN1bXNyOXA1QVhzcg==' \
--data-raw '{ "grantType" : "client_credentials", "scopes" : "user/*.*" }'

Once you have the access token, you can then use it in your FHIR request. For example, the following is a get patient everything call: curl --location --request GET '$everything' \
--header 'Authorization: Bearer {{access_token}}'

I should mention that the URL for getting the access_token is a bit different from sending the FHIR request.

To access the FHIR endpoint, you'd have to use the following base URL:

Duane's Implementation

Duane ran into a couple of glitches, e.g., structure in HAPI FHIR doesn't let one set the meta data the way it needs to such as duplicate labels on Bundles while Resources were labeled correctly.   This may be due to using an earlier version of the server (4.0). His system was not persisting test results.

The LEAP Privacy Protective Service has a suite of rules for organizations to delete sensitive information from the bundle. Duane had to remove those rules to show, e.g.,  MH (mental health) sensitivity on resources in the bundle.

Duane's SLS uses the v3 security labeling code systems, but the FHIR DS4P IG references FHIR Security Label value sets.  Duane will need to update SLS Rule DB for FHIR Security Labeling value sets.

PATRPT (patient reported) Provenance label in the track labeled Resource example is also not supported by Duane's SLS.  While the code is honored on way in, it is not processed.  Duane's SLS doesn't support use of provenance labels, e.g., to set confidence levels for end users such as indicating that information is patient generated or reported.

How would it be honored?  Processing as a provenance label would be used to alert the end user that the data is patient generated.

Duane had failures on running the test scripts that he had to work around.  In part of the flow of persisting a bundle or resource the as response coming back out the door it's seen as a bundle initially.  He did not know if James is initially creating a bundle and then stripping off for just the outcome resource.  This was creating havoc in the Interceptor.  Duane had to allow it to come through to the SLS, and  just return a "True"  to get reasonable outcomes in terms of persisting the labeled bundle/resource.  This did not seem typical of an implementation.  But perhaps Duane missed something.  He will put this finding on chat to get feedback.

Issues/Questions related to FHIR DS4P IG

CUI needs to be at the Bundle and the Resource Level. 

Chat about how FHIR should support Meaning of Security Labels on Bundles.
Also see Security Label High-Water Mark for further discussion.

Question about where to find the Federal Agency that is the CUI designator as distinct from the Resource/Bundle creator that applied the CUI.  Duane is correct, we should create a placeholder list of Federal Agencies and their contact information as a placeholder until the Federal Agencies let us.

Questions about what CUI codes should be used for eHealth Exchange. More discussion needed.  See current thinking at Controlled Unclassified Information (CUI) Problem and Solutions

Lessons Learned

FHIR servers can support Security Labeling and Privacy Protective Services

Testing a small use case with test scripts it a good way to find bugs.

Next Steps

Continue Security Labeling Track to exercise FHIR DS4P IG and FHIR US Regulatory Security Labeling IG using same approach in September.  Hope to engage same participants perhaps in a collaborative track with LEAP Consent.

Notify the community when the LEAP Security Labeling Docker image is available.

  • No labels