FHIR: Burning a path to interoperability in healthcare

By Eric Liu

84% of hospitals in the US have adopted FHIR-enabled technology as of 2019 (Posnack & Barker 2021). A lot right? But, I’m getting too ahead of myself. Let’s start from the beginning to give that statistic some context.

Interoperability. That’s a big word, but what does it mean? Well, interoperability is when different computer systems are able to exchange information in a way so that it is understandable and the data can actually be used once it’s been received. And right now, this process is a challenge in healthcare. You may be wondering, why? Why is it a challenge? Why is it even important? It’s a challenge because of the nature of the data being shared. Health data is extremely personal information, so as you can imagine, privacy and security are of utmost importance. How do you share such sensitive information then? Because it’s important that it is shared so that healthcare practitioners are able to get a full, complete understanding of what a patient needs.

Let’s think of a possible scenario where you may face this interoperability issue. Say you’ve noticed a change in your health; something a bit weird that you haven’t previously seen or experienced. You’re slightly concerned, so you go to your family doctor to get it checked out. Depending on the situation, a few things could happen. If they’re not sure about the problem, your doctor may refer you to see a specialist. Or maybe they’ll ask you to go to a lab to get some testing done, or get a CT scan. Or maybe you just need to go to a pharmacy afterwards and get a prescription. Now, what if all these places have different IT systems set up? How will they be able to access your health information?

Introducing: the FHIR standard

FHIR is an acronym for Fast Healthcare Interoperability Resources, and is an international standard for exchanging healthcare information electronically. The first version of FHIR was released back in 2014 by Health Level 7 International – a non-profit standards development organisation that focuses on interoperability in healthcare. To achieve their goal, HL7 designed FHIR so that it defines how health data should be organised and structured so that it is able to be shared across computer systems without being misinterpreted. This is important because then all the different places we mentioned earlier would be able to access a patient’s data.

Graph showing hospitals, pharmacies, doctors, and labs being able to access EHR (electronic health record) due to FHIR — (Hospitals, pharmacies, etc. being able to access an EHR (electronic health record) to get patient information because of FHIR)

Resources

But, how does HL7 do it? Well, they do this by using something known as resources. Resources are the building blocks of FHIR; they’re individual components of data that represent important concepts in healthcare. For example, a person that is receiving care is represented in FHIR by the Patient resource, and a person providing the care is represented by the Practitioner resource. These resources are structured so that they can be interpreted by different systems and applications. Resources can be represented in multiple different formats as well, like JSON or XML.

Code Snippet #1: Patient resource – the “Hello World” of FHIR

{
  "resourceType": "Patient",
  "id": "f201",
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p><b>Roel(OFFICIAL)</b> male, DoB: 1960-03-13 ( BSN: 123456789 (OFFICIAL))</p></div>"
  },
  "identifier": [
    {
      "use": "official",
      "type": {
        "text": "BSN"
      },
      "system": "urn:oid:2.16.840.1.113883.2.4.6.3",
      "value": "123456789"
    },
    {
      "use": "official",
      "type": {
        "text": "BSN"
      },
      "system": "urn:oid:2.16.840.1.113883.2.4.6.3",
      "value": "123456789"
    }
  ],
  "active": true,
  "name": [
    {
      "use": "official",
      "text": "Roel",
      "family": "Bor",
      "given": [
        "Roelof Olaf"
      ],
      "prefix": [
        "Drs."
      ],
      "suffix": [
        "PDEng."
      ]
    }
  ],
  "telecom": [
    {
      "system": "phone",
      "value": "+31612345678",
      "use": "mobile"
    },
    {
      "system": "phone",
      "value": "+31201234567",
      "use": "home"
    }
  ],
  "gender": "male",
  "birthDate": "1960-03-13",
  "deceasedBoolean": false,
  "address": [
    {
      "use": "home",
      "line": [
        "Bos en Lommerplein 280"
      ],
      "city": "Amsterdam",
      "postalCode": "1055RW",
      "country": "NLD"
    }
  ]
}

Each resource has its own list of attributes that help model what it is. As you can see in the example above, a Patient resource has attributes to describe the person receiving care; things like their name, phone number, birth date, address, etc. Resources can also be combined with each other through the use of References to show the relationships between them in order to model their specific scenario.

Code Snippet #2: Immunization resource – record of vaccines


  "resourceType" : "Immunization",
  "id" : "example",
  "text" : {
    "status" : "generated",
      "identifier" : [{
    "system" : "urn:ietf:rfc:3986",
    "value" : "urn:oid:1.3.6.1.4.1.21367.2005.3.7.1234"
  }],
  "status" : "completed",
  "vaccineCode" : {
    "coding" : [{
      "system" : "urn:oid:1.2.36.1.2001.1005.17",
      "code" : "FLUCEL VAX"
    }],
    "text" : "Flucelvax (Influenza)"
  },
  "administeredProduct" : {
    "concept" : {
      "coding" : [{
        "system" : "urn:oid:2.16.840.1.113883.6.69",
        "code" : "70461-0321-03"
      }],
      "text" : "Flucelvax (Influenza, injectable, MDCK, preservative free, quadrivalent)"
    }
  },
  "patient" : {
    "reference" : "Patient/example"
  },
  "performer" : [{
    "function" : {
      "coding" : [{
        "system" : "http://terminology.hl7.org/CodeSystem/v2-0443",
        "code" : "OP"
      }]
    },
    "actor" : {
      "reference" : "Practitioner/example"
    }
  }]
}

The example above shows an Immunization resource – the record of the vaccines the patient has gotten. The resource is referencing a Patient and Practitioner resource, where the Patient is the person receiving the vaccine and the Practitioner is the person administering it. The format of the reference can either be the absolute URL of the referenced resource, or the relative URL to whatever the FHIR URL is.

The overall goal is to have all the resources necessary so that either alone or combined, they can meet most clinical use cases. A valuable resource that highlights this is the Bundle. The Bundle allows you to do operations on a collection of FHIR resources. There are multiple Bundle types, so how it gets executed depends on its type.

Code Snippet #3: “Transaction” Bundle

{
  "resourceType": "Bundle",
  "id": "bundle-transaction",
  "meta": {
    "lastUpdated": "2014-08-18T01:43:30Z"
  },
  "type": "transaction",
  "entry": [
    {
      "fullUrl": "urn:uuid:61ebe359-bfdc-4613-8bf2-c5e300945f0a",
      "resource": {
        "resourceType": "Patient",
        "text": {
          "status": "generated",
          "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">Some narrative</div>"
        },
        "active": true,
        "name": [
          {
            "use": "official",
            "family": "Chalmers",
            "given": [
              "Peter",
              "James"
            ]
          }
        ],
        "gender": "male",
        "birthDate": "1974-12-25"
      },
      "request": {
        "method": "POST",
        "url": "Patient"
      }
    },
    {
      "request": {
        "method": "DELETE",
        "url": "Patient/234"
      }
    },
    {
      "request": {
        "method": "GET",
        "url": "Patient?name=peter"
      }
    }]
}

This is an example of a ‘transaction’ Bundle, where you’re able to do multiple operations at once. As you can see, we are not only creating a new Patient resource in this Bundle, but we are also getting and deleting existing Patients as well. For this type of bundle, you must include the HTTP request that you wish to perform on the resource. An important thing to note about ‘transaction’ Bundles is that the operations are dependent on one another. What this means is that if one operation fails to execute, then the entire Bundle will fail as well.

RESTful API

So now we’ve established how to structure all of our healthcare data. But how do we actually send it and access it? Fortunately, FHIR offers a REST API just for this. What that means is that we’re able to request and receive our resources using the HTTPS protocol; so, you can do your standard CRUD (create, read, update and delete) operations through HTTP commands (POST, GET, PUT, DELETE). This is possible because FHIR resources are accessed via URL.

Let’s do a simple example. Say we have an existing Patient resource, like the example Patient resource above, and we’re trying to update it because they moved and their address has changed. What we’ll first need to do is construct a new Patient resource with the updated data. If we’re changing their address, then we can just modify the address attribute.

"address": [
    {
      "use": "home",
      "line": [
        "Van Egmondkade 23"
      ],
      "city": "Amsterdam",
      "postalCode": "1024 RJ",
      "country": "NLD"
    }
  ]

After we construct the new resource, there are still a few things we need to know before we can update it on the server. The first thing is the endpoint of the FHIR server – this is the location of where the resource is being stored. We also need to know what type of resource we’re trying to update – in this case it’s the Patient resource. The last thing we need is the ID of the resource – this is a unique identifier that is assigned to the resource by the server when it’s first created. To get this unique ID, we can do a search (more details about searching can be found below). For this example, let’s say we know the name of the patient. Then, we can do a search with their name as our search parameter and get their ID from the corresponding returned resource. Now, with all the information we’ve gathered we can construct the following URL:

https://r4.smarthealthit.org/Patient/123

where https://r4.smarthealthit.org/ is our FHIR endpoint, Patient is our FHIR resource, and 123 is our resource ID. If we do an HTTP PUT request with that endpoint, then we’ll be able to update the Patient resource associated with that ID on the given FHIR server with our new Patient resource.

As mentioned above, the FHIR API also supports searching in addition to CRUD operations. So, you’ll be able to find the specific data you’re looking for. The structure of the URL will largely be the same – you still need the FHIR endpoint and the resource type, but instead of the resource ID, you put in your search parameters.

https://r4.smarthealthit.org/Patient?name=jim

The example above will return all the patients with the name “Jim”. Of course, you’re able to add multiple search parameters to narrow down your results.

SMART on FHIR

So, that’s FHIR. A universal method to exchange healthcare data in a seamless way. But, there’s one more thing we need to talk about, and that’s SMART. It’s another acronym and stands for Substitutable Medical Applications, Reusable Technologies. SMART is a specification that defines how to integrate a FHIR-based application with a FHIR-enabled EHR so that it can securely access data within the EHR. To do this, it leverages the OAuth 2.0 protocol for authorization.

What’s OAuth, you may ask? OAuth is an industry standard for accessing resources that are stored on another server on behalf of a user. Here’s an example of this that I think everyone is familiar with: when you’re trying to access a website and it gives you the option to sign in with Google or Facebook. You can use your account credentials from Google or Facebook to authorize and gain access to whatever website you’re going to. Convenient, isn’t it? But, what’s going on behind the scenes?

Let’s take a couple of steps back and start from the beginning. Say you’ve developed a healthcare application using FHIR. Great! Now, to integrate your new app with a FHIR-compatible EHR, a few things would occur. The following steps highlight the key points of the authorization flow:

The first step would be to register the app with the EHR; doing so will register it with the EHR’s authorization service, as well as provide the necessary client credentials (an ID and a Secret) to start the authorization flow.
Once it is registered, we can launch the application. When this happens, a request is made to the discovery URL of the FHIR server; from this URL we can retrieve the authorization and token endpoints.
With the authorization endpoint we can construct a request to the authorization server with the data the app needs to access; this data is also known as the scopes.
If successful, the server will respond with an authorization code. This code is then used to make a request to the token endpoint to exchange it for an access token. The access token is important because it’s what’s used to authorize our application’s requests to the FHIR server. With it, the data from the EHR is accessible to the app.
You are now able to request FHIR resources from the server!

The following diagram shows the authorization flow of an application launch:

Diagram of authorization flow of an application launch

https://www.hl7.org/fhir/smart-app-launch/app-launch.html

Conclusion

FHIR is an admittedly niche area of software development. But, from my experience working on a project that used it, I’ve learned how effective it can be and how important it is. It’s imperative that we solve the issue of interoperability in healthcare; the effect it has on the quality of care a person receives is not insignificant. Fortunately, FHIR has become quite popular and is being adopted by EHR vendors and governments. Even big tech companies like Microsoft, Google, and Amazon are offering FHIR solutions on their cloud computing platforms (Google Cloud, Microsoft Azure, Amazon Heathlake), and Apple is using it for their Health App.

I didn’t know a single thing about FHIR until I came to the UBC CIC, but I’m glad I’m able to leave it armed with this new knowledge.

References

Posnack, Steven, and Wes Barker. “The Heat Is On: US Caught FHIR in 2019.” Health IT Buzz, 30 Aug. 2021, https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-2019.

Projects

FHIR: Burning a path to interoperability in healthcare

FHIR: Burning a path to interoperability in healthcare

Introducing: the FHIR standard

Resources

Code Snippet #1: Patient resource – the “Hello World” of FHIR

Code Snippet #2: Immunization resource – record of vaccines

Code Snippet #3: “Transaction” Bundle

RESTful API

SMART on FHIR

Conclusion

References