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?


  • 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 -->
     <url value="http://hl7.org/fhir/example-do-not-use#Patient.picture"/>
       <reference value="#pic1"/>
       <display value="Duck image"/>

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

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

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

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


About David Hay
I'm an independent contractor working with a number of Organizations in the health IT space. I'm an HL7 Fellow, Chair Emeritus of HL7 New Zealand and a co-chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the FHIR standard. I'm the author of a FHIR training and design tool - clinFHIR - which is sponsored by InterSystems Ltd.

13 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.


  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.

  5. dharma815 says:

    Hi David, I’m finding these articles very helpful.

    My question: how common is it now for Interface Engines – which typically don’t have access to the store of patient data – to simply push the ADT it receives from an EHR out in bundles to downstream applications expecting to receive FHIRs resources?

    It almost seems that this would be an Interface Engine’s MAIN use of FHIR, given that it couldn’t very well respond to FHIR requests for data.

  6. Phil Shields says:

    Thank you for your clear explanation. However, I am constantly frustrated by links to the ‘official’ FHIR documantation which I find confusing. For example, the extensibility documentation’s first sentence is “This exchange specification is based on generally agreed common requirements across healthcare – covering many jurisdictions, domains, and different functional approaches”. What is an ‘exchange specification’? What has it to do with extensibility? Also what is a jurisdiction, domain and functional approach? Most of the documentation assumes that the reader knows what the author is talking about, not a noob like me trying to learn.

    • David Hay says:

      Yeah – it can be really hard to explain things in terms that people new to the specification can understand! We do try as hard as we can to make it understandable, but are not always successful! To answer your specific questions though….

      An ‘exchange specification’ is about sharing information – rather than how it is stored within a system. In this case, extensibility refers to how a particular implementation can add information that is not in the core spec (FHIR deliberately keeps the core spec minimal, so the use of extensions is normal…)
      For Jurisdiction, think Country. Domains are specific ‘parts’ of healthcare – such as representing patient problems (Conditions), Allergies or Medications. Functional Approach refers to thinking about what you want to do, rather than the details of representation.

      Hope that helps – I’d suggest you join the FHIR chat at http://chat.fhir.org/ . We’re a friendly bunch – especially to newcomers!

      • Lloyd McKenzie says:

        One of our objectives with FHIR is to keep the specification simple and approachable, especially for those who don’t have deep knowledge of the space. Obviously we don’t always succeed. If you find wording that seems unclear or over-complicated and think you can do better, *please* submit a change proposal (propose a change link at the bottom of any page in the spec). We’re very happy to consider suggestions that make FHIR more readable.

      • Phil Shields says:

        Thank you David, your explanation was helpful. I come from an ontology background where ‘domain of interest’ seems equivalent to your ‘jurisdiction’. I have to understand FHIR better in order to write parts of the spec in plain English. I was reading the spec and I could hear my old supervisor in my head saying “where is the flow Phil” 🙂

Leave a Reply

%d bloggers like this: