HL7 FHIR for Dummies

Welcome to our short HL7 FHIR for Dummies article where we explore this strange term, which as you may have guessed is pronounced “fire”. FHIR has been around for about a decade now and it is revolutionizing health and research, but what exactly is HL7 FHIR?

Well, to put it simply FHIR is a standard for packaging up data in combination with another standard for moving those packages around. Let’s explain what that actually means and why you should care.

HL7 FHIR allows one or more software products to send information in a ‘standard format’. To understand why that is at all relevant or important, you really need to understand what a pain it is to not have a standard format.

We’ll use an EHR (Electronic Medical Record) as the example as FHIR is all about medical interoperability. If we pretend we’ve built a piece of software which displays you your own medical record, it has to get that data from many different EHRs at different hospitals or GP Practices. To get that data, a digital request must be made to each individual EHR where the individuals health data is stored. At this point without a standard (there’s that word again) each company who builds EHR software creates their own way of packaging up your health data and sending it to our hypothetical product to display us our medical record.

You’re probably thinking “So what is the issue then? You can receive the data, everything sounds great…?”. Well, that’s where you would be wrong. If every EHR software has their own standard, our awesome medical record displayer needs to be developed so it can read every single EHR vendor’s way of packaging up that data. That becomes a very lengthy and expensive task. It also makes our new piece of software more susceptible to fault. We’re trying to develop to so many different ways of receiving data it only takes a small change at one hospital or one vendor to potentially stop our platform from working for certain patients.

Then there is a the pain of documentation and support. If everyone has their own way of doing things will they have good quality documents to enable solid development and support? The answer to that question is “No”. Historically IgniteData have seen it first hand in the UK primary-care sector where different EHR vendors have drastically different ways to package data and documentation, leaving a lot to the imagination… How can we possibly build high-quality software product with this volatility … “With great difficulty” is the answer!

The pain is deeper than the simple description above, but if you understand the outline described, you’re well on your way to understanding the general point of HL7 FHIR.

HL7 FHIR is a way of unifying the way we package and move health data to help solve the pain. If we are building a software product to do something amazing in health or research we want it to be able to consume data from all EHRs with as little fuss as possible… we want to be able to build that software so it can reliably consume all of that data and process it in a more predicable way so it doesn’t become unmanageable or too expensive to support… we want to know that everyone globally is feeding into the way the standard should be managed… and we want to know the documentation is high-quality and available to build and solve the next health challenges.

The final piece of HL7 FHIR is how it is moved around. If HL7 FHIR is the box and bubble wrap, then the moving around bit is the UPS service we’re using to get it delivered.

HL7 FHIR ‘packages’ (let’s stick with that language to keep it simple!) are moved from one piece of software to another using something called RESTful APIs. Going into the differences between different API technology is far beyond the point of this article, so we will keep it simple. When using a RESTful API we are able to essentially ask the EHR for something. So if we want to GET some information on a patient, we’re able to ask the EHR a question such as “Can we please have XYZ information on John Smith please?”. The EHR will then go and pick up the data requested, bundle it into HL7 FHIR ‘packages’ and send this to our software.

Here at IgniteData we’ve been using HL7 FHIR to build our EHR to EDC automation software, Archer, for all the reasons above. We’ve also been helping lots of our clients understand and develop their own solutions using this technology. If you would like some friendly advice, or feel you’ve got something exciting to bring to the world, get in touch with us and we’re always happy to see how we might be able to help!