What is FHIR (and why should I care)?

In my self-appointed role as ‘FHIR evangelist’ (some would say ‘FHIR Fanatic’) at Orion Health and HL7 New Zealand I’m often asked ‘what is FHIR, and why should I care’. Rather than trying to explain each time, I’m going to write a short post here, so I can refer people to it, rather than trying to remember all the good points at the time.

So, what is FHIR?

Well…

  • FHIR (Fast Health Interoperability Resources) is the latest interoperability standard from HL7, following on from Version 3. (Strictly speaking it builds on rather than replacing v3, but also pulls in ideas from other organizations such as openEHR or IHE).
  • FHIR has the fundamental concept of “Resources”, where a resource is the basic unit of interoperability – the smallest ‘thing’ that makes sense to talk about – such as a Patient, a Condition (Problem) or a Practitioner.
  • Resources have a number of common characteristics, including:
    • A small number of ‘core’ properties that most (80%) of systems currently support. Each property is a specific datatype (although some resources allow more than one datatype to be used for a property)
    • A standard extension mechanism that allows implementers to add new properties in a safe and discoverable way. (This is the lesson of version 2)
    • An ‘identity’ by which it can be saved, located & retrieved
    • A human readable component that summarizes the data in the resource for a human to read (This is the lesson of CDA).
  • Resources can be re-used across interoperability paradigms. You could receive (or save)  a resource via a REST service, and then package it in a Message or include it in a Document.
  • There is a built in versioning system. Each resource can have multiple versions, and there are mechanisms to retrieve the history of a specific resource, and/or a specific version.
  • The specification itself is on-line, and fully hyperlinked. You can link through from resource, to a property, to the datatype of that property. Where a particular terminology or code set has been defined for a property, you can hyperlink to that dataset. (Terminologies are a bit more tricky to link to).

Why should you care?

  • FHIR has been build with the needs of the Implementer in mind. We try to be as simple as possible, but no simpler.
  • This extends to the use of connectathons, where developers can try out ideas before being included in the specification.
  • Standard tooling can be used.
  • You can use XML or JSON representation.
  • Each resource has a specific validation schema / schematron (again, a lesson from CDA)
  • All the artifacts (including the schema) are automatically built using a build process (similar to a software build). This significantly improves the overall quality of the specification.
  • Each resource has multiple examples that shows how the resource can be used. The resources themselves are ‘round-tripped’ from XML -> JSON ->XML and validated as part of the build process to ensure accuracy.
  • FHIR (especially the JSON representation) is great for mobile development
  • There are number of open-source clients to make it even easier to use
  • There are also some test servers to test your work out on.
  • Lots of other people are looking very closely at FHIR

An example of a Patient resource is shown below. This one also has an embedded picture within it.


<?xml version="1.0" encoding="UTF-8"?>
 <Patient xmlns="http://hl7.org/fhir">

   <!-- Each extension is at the top of the resource. This one points to the embedded photo of Donald -->
   <extension>
     <url value="http://hl7.org/fhir/example-do-not-use#Patient.picture"/>
     <valueResource>
       <reference value="#pic1"/>
       <display value="Duck image"/>
     </valueResource>
   </extension>

   <!-- Here is the Human readible part...-->
   <text>
     <status value="generated"/>
     <div xmlns="http://www.w3.org/1999/xhtml">
       <p>Patient Donald DUCK @ Acme Healthcare, Inc. MR = 654321</p>
     </div>
   </text>

   <!-- Contained elements allow an 'anonymous' resource to be embedded. In this case the image -->
   <contained>
     <Binary id="pic1" contentType="image/gif">adads -- rest of b64 encoded image here....</Binary>
   </contained>

   <!-- The elements below this are the 'core' elements of the resource -->
   <identifier>
     <use value="usual"/>
     <label value="MRN"/>
     <system value="urn:oid:0.1.2.3.4.5.6.7"/>
     <value value="654321"/>
   </identifier>
   <name>
     <use value="official"/>
     <family value="Donald"/>
     <given value="Duck"/>
   </name>
   <gender>
     <coding>
       <system value="http://hl7.org/fhir/v3/AdministrativeGender"/>
       <code value="M"/>
       <display value="Male"/>
     </coding>
   </gender>
   <active value="true"/>
 </Patient>

Well, I hope I’ve answered the question of “what is FHIR and why should you care”. Feel free to leave any comments below.

Cheers…

About David Hay
I'm a Product Strategist at Orion Health, Chair emeritus of HL7 New Zealand and co-Chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the new FHIR standard.

7 Responses to What is FHIR (and why should I care)?

  1. Pingback: A REST primer – FHIR style – part I. | Hay on FHIR

  2. Koray Atalag says:

    Reblogged this on openEHR New Zealand and commented:
    I (together with some other openEHR folk) believe the emerging HL7 FHIR standard can leverage from clinical modelling using Archetypes while we (and rest of the world!) could benefit from modern and lightweight REST based exchange mechanism. Here is a post from my fellow colleague, David Day, describing nicely what FHIR is all about on his increasingly popular blog: Hay on FHIR!

  3. Anita Bhojwani says:

    Is the patient resource mentioned above a query or a response message?

    • David Hay says:

      well, it can be either! If you know the id of the resource, then GET [host]/Patient/{id} would return it. Or, it could be included in a bundle from a query like GET [host]/Patient?name=Duck. Or, it could be the body of a post – POST [host]/Patient.

      Think of it as the model of the Patient that is being exchanged.

      cheers…

  4. Boris Tyukin says:

    Hi David, very helpful blog! I enjoyed reading it. Have you worked by any chance or felt the need to normalize FHIR documents into RDBMS flat tables? We want to load data from FHIR server for analytics and while we can store JSON documents, it is not easy to consume this data for analytics / dashboards. I wonder if you have done any work in that direction or if it even makes sense for you given the use case. I cannot find any related projects. E.g. patient resource will turn into multiple related tables with columns and simple values such as patient, patient_names, patient_identifiers etc.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: