Dev’s on FHIR — Introduction to Bundles, Care Connect (Part 1)

In this Dev’s on FHIR series I’m going to discuss how to handle documents (PDF, TIFF, JPEG’s) using FHIR. The narrative is a journey and starts from the initial requirement within a hospital trust and ends with national/local document sharing across care settings.

Audience: Developers and Implementors of HL7, FHIR, Care Connect and general interoperability projects exchanging health information across care settings
Technologies: HL7 FHIR, JSON, Java, HAPI
FHIR: Document Reference, Binary, Bundles
Photo by Paul Bulai on Unsplash

By the end of this series you will understand how and why to construct Bundles to solve your interoperability challenges. Don’t worry if you don’t understand the technologies, FHIR resources or concepts yet, that is the aim of these posts so let’s get going….


Background

I became interested in FHIR in 2014, we had a need to standardise the way documents moved through our hospital (NHS Trust) to the new electronic document management system (EDMS) which was being introduced as part of paperless 2020 and our GP correspondence portal.

Ideally we would have chosen HL7v2 but most of the systems (consumer and provider) were exchanging information using XML or JSON formats. Another key part was to standardise the document metadata, so when vital signs, theatres or digital dictation produced a document the data attached to the documents (metadata) was the same.

Choosing a Standard

To exchange information we specifically needed to transfer:

  • Patient identifiers (NHS Number and hospital numbers)
  • Document Type
  • Speciality
  • Date created
  • Author

So we chose FHIR DocumentReference (https://www.hl7.org/fhir/documentreference.html)

HL7 FHIR DocumentReference (STU3)

So what would a FHIR DocumentReference look like? It’s a little more than our initial requirement but more readable than HL7v2 and far less than a modelling approach such as HL7v3.

{
"resourceType": "DocumentReference",
"status": "current",
"type": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "734163000",
"display": "Care Plan"
}
]
},
"subject": {
"reference": "https://demographics.spineservices.nhs.uk/STU3/Patient/9658220169"
},
"indexed": "2018-12-05T10:56:09.673+00:00",
"author": [
{
"reference": "https://directory.spineservices.nhs.uk/STU3/Organization/RR8",
"display": "LEEDS TEACHING HOSPITALS NHS TRUST"
}
],
"context": {
"practiceSetting": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "408467006",
"display": "Adult mental illness"
}
]
}
}
}

First thing to notice is we have used SNOMED CT for document type and specialty. The codes for document types (type) comes from the NHS FHIR ValueSet DocumentType-1 (SNOMED CT RefSet 999000391000000109) and the specialty (practiceSetting) are NHS FHIR ValueSet called CareSettingType-1 (SNOMED CT RefSet 999000381000000107)

We have done this to help interoperability and include some future proofing.

So when we want to work with another health provider we won’t need to know which folder or file name they have used to store COPD discharge letters. We will know they will be tagged with 823701000000103|Discharge Letter type and practiceSetting may be 310141000|Thoracic surgery service

If you are familiar with IHE XDS you may have noticed some overlap, that’s not an accident. FHIR DocumentReference has been heavily influenced by IHE XDS and is used in IHE MHD. Also these ValueSets are using the same set of codes used in ITK HL7v3/CDA and also part of a recommendation by IHE UK for use with XDS.

Implementing FHIR

To generate this JSON we have used java together this a library called HAPI FHIR. Step one is to create link a FHIR Document Reference as shown below:

We have glossed over quite a bit here but in later posts we will be expanding on these but coming back to the DocumentReference, how/where do I put in the actual document.

The DocumentReference does have a spot for the actual document and that will be carried in a FHIR Binary resource. For simplicity we will be mocking a document using a simple string, in reality this would be the contents of a file base64 encoded.

{
"resourceType": "Binary",
"contentType": "text/html",
"content": "PCFET0NUWVBFIGh0bWw+PGh0bWw+PGJvZHk+U09NRSBURVhUPC9ib2R5PjwvaHRtbD4="
}

The Java Code to generate the Binary:

So now we have a FHIR DocumentReference and Binary, in our system we will be moving them around the system together. We need a resource that can hold both and so we use FHIR Bundle. Conceptually this is quite simple, we create a Bundle and add in the resources (DocumentReference and Binary).

However, it’s not as simple as that, we need to explicitly link the DocumentReference and Binary together. To do that we will first assign id’s to both resources, the specification allows any string for this but for reasons covered in a future blog post we will use UUID’s.

doc.setId(UUID.randomUUID().toString());
binary.setId(UUID.randomUUID().toString());

We use link the DocumentReference to the Binary resource as follows:

doc.addContent().getAttachment()
.setContentType(binary.getContentType())
.setUrl("urn:uuid:" + binary.getId());

urn:uuid: is the namespace for unique identifiers, so the DocumentReference is looking for a url starting with this and contains the binary.id. So we need to supply this in the Bundle. In addition we are also going to specify this as a collection Bundle.

The JSON FHIR output of this code is now:

{
"resourceType": "Bundle",
"type": "collection",
"entry": [
{
"fullUrl": "urn:uuid:b7ffefe3-361d-45a2-a297-69e46d701018",
"resource": {
"resourceType": "DocumentReference",
"id": "b7ffefe3-361d-45a2-a297-69e46d701018",
"status": "current",
"type": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "734163000",
"display": "Care plan"
}
]
},
"subject": {
"reference": "https://demographics.spineservices.nhs.uk/STU3/Patient/9658220169"
},
"indexed": "2018-12-05T15:03:32.057+00:00",
"author": [
{
"reference": "https://directory.spineservices.nhs.uk/STU3/Organization/RR8",
"display": "LEEDS TEACHING HOSPITALS NHS TRUST"
}
],
"content": [
{
"attachment": {
"contentType": "text/html",
"url": "urn:uuid:e1174bf5-f8e8-4d44-ac63-02b57417ac37"
}
}
],
"context": {
"practiceSetting": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "408467006",
"display": "Adult mental illness"
}
]
}
}
}
},
{
"fullUrl": "urn:uuid:e1174bf5-f8e8-4d44-ac63-02b57417ac37",
"resource": {
"resourceType": "Binary",
"id": "e1174bf5-f8e8-4d44-ac63-02b57417ac37",
"contentType": "text/html",
"content": "PCFET0NUWVBFIGh0bWw+PGh0bWw+PGJvZHk+U09NRSBURVhUPC9ib2R5PjwvaHRtbD4="
}
}
]
}

The complete code to construct the FHIR DocumentReference, Binary and combine it as a FHIR Bundle is shown below:

The last change we did was to add in a self referential url, or put another way the url in the DocumentReference points to the Binary resource also with the Bundle.


In recap

  • The Binary contains the actual document
  • The DocumentReference contains the document metadata
  • The Bundle contains the Binary and DocumentReference
  • The DocumentReference has a self referential link to the Binary in the Bundle.

In addition we have said:

  • Document types are defined in a SNOMED Reference Set (and FHIR ValueSet)
  • Service Type are also defined in a SNOMED Reference Set (and FHIR ValueSet)
  • The reference sets are used outside of FHIR such as HL7v3/CDA ITK and also IHE(UK) XDS and aid interoperability.

Architectural concepts

Using Enterprise Integration Patterns we have created a translator and started to adopt a canonical model called FHIR.

This is a simplified diagram of our process and if you are familiar with HL7v2 messaging this should be familiar. At the time very few systems supported FHIR so in reality our Trust Integration Engine was doing two translations.

That may sound like extra work but as we added more sources or endpoints they just needed to be converted to or from FHIR and then added to the existing system. We also became familiar with the requirements of the model which increased the quality of our systems.

It’s not an accurate description of our process but shows the gist of our solution. You may have noticed the reference url’s such the one used to reference the patient. We didn’t do this in practice as some of the endpoints (mostly external) needed a NHS Number and others used hospital numbers.

The solution was to remove these url’s and anyway this is a FHIR rule on Bundles: Bundle’s should be self referential. That is all the resources needed to process a bundle should be contained within the bundle.


What’s next

In the first part of this series we have covered how and why to construct Bundles using FHIR DocumentReference and Binary with Java examples, the HAPI FHIR library and introduced some FHIR related and architectural concepts. But to get to a working solution we will cover ways of fixing these external references in the next part of the Dev’s on FHIR series.

Part Two Populating the EDMS Repository

Photo by Remi Yuan on Unsplash