Opinion: Why FHIR is the iPhone of clinical data standards
When we talk about innovations in achieving interoperability, we don’t usually think of healthcare data standards. But I’m going to change your mind, I think. Hopefully I’ll also convince you to start working now with the new FHIR standard and seriously consider how to integrate it with your existing healthcare information systems.
FHIR, or Fast Healthcare Interoperability Resources, which is the newest clinical data standard from the Health Level Seven International (HL7) standards organisation, is in itself an innovation. Using the same technology as the internet, it enables innovation for people using healthcare data.
One thing that makes FHIR a necessary innovation is that the meaning of interoperability has changed. In the 1980s, interoperability was about connecting two systems together, and that’s where the data standards we use today came from. They were built to connect one system to another system, and then we’ve leveraged those standards to connect one system to multiple systems. But those standards really weren’t designed to do that.
In the 21st century, interoperability is starting to mean something very different. Interoperability now means being able to be in one place and see the data of an individual or a population of individuals from that one place in real time. And that data is no longer in a hospital system alone. It’s in many different systems: it’s in clinics and pharmacies, it’s in devices that people have at home and in wearables, it’s in mobile devices, it’s in government agencies, it’s in genomic sequencing labs, it’s in literally hundreds of other databases. And, we are learning, even data that isn’t what we previously considered healthcare data is also important to an individual’s health.
We have to be able to get that data to one place, to see it and to use it for clinical care, and for other uses of that data like quality improvement and care coordination. And we can’t do it with the standards that were developed in the 1980s. That’s what HL7 FHIR is all about. It was built to meet this challenge.
A thousand facts per complex decision
There is another part of this challenge. Not only is data in more places, but there’s a lot more data than there was 30 or 40 years ago. William Stead from Vanderbilt University estimates how many facts there are for a complex decision in medicine. In 1980, there were about 10 facts per decision. In 2020, if you extrapolate on Dr Stead’s graph, there are around 1000 facts per complex decision.
The other number that you should know is the number of facts a human mind can handle in making a decision. That’s five. I like to think I’m maybe six or seven, but even in 1980, I was way behind, and now like everyone else, I’m hopelessly behind. Yet in clinical care, our workflows are still very much the way were in 1980. We still act as if physicians can come up with a conclusion in their head. That needs to change. And the way that we can enable that change is with technologies like FHIR.
Medical errors are the third leading cause of death in the US after heart disease and cancer, according to a study by patient safety experts at John Hopkins University. And I would probably say, if we looked at each of those closely, a lot of them are not truly errors. A lot of them are that the wrong decision was made because all of the data wasn’t available to make the best decision and because there wasn’t a decision support system that can handle more than five facts to help clinicians make that decision.
Creating a new standard from scratch
It was recognition of that reality that led to the creation of FHIR. In 2011, HL7 created a task force that was asked the question: if we created a new standard from scratch, what would it look like? And after a time, a gentleman from Australia, Grahame Grieve, came forward with a concept that we now call FHIR. At that point, the existing HL7 standards were almost 30 years old.
I am not saying the old standards will go away. They don’t meet the needs of the present but the systems which use those earlier standards will still be there for a long time. I think HL7 v2 will survive the apocalypse! But we need to connect all the data from all of those systems, some of which can only import and export HL7 v2 standards. So in addition to needing to have new standards that fits the needs of the future we also need to have a strategy, a platform for connecting all those standards and seeing all the data as one collection of data.
Let me talk about what FHIR is conceptually without being very technical. It’s what’s called a representational state application programming interface, or a RESTful API. REST doesn’t refer to sleep or relaxation. It’s an acronym for REpresentational STate, which means that you represent the data on one server in its current state on another server. It’s the basis of Facebook and Google and all the ecommerce and social media applications we use daily.
Probably the easiest way to explain REST is the airline booking sites that we all use. If you go to your favourite airline booking site, and you say you want to go from Sydney to Melbourne on May the 5th, in a few seconds you see several flights on different airlines. That doesn’t work because your favourite travel site has downloaded all the airline schedules. It works because the airline industry has agreed on how they’re going to represent the data in an airline flight. The departure time, the arrival time, the price. And that is what FHIR is in healthcare. It is a contract between systems on how to ask and what you get back. It’s both the same technology as those internet services use, and it’s also the meaning of the data in healthcare.
One thing that this means, which is a complete paradigm shift from existing standards, is that when you represent data as FHIR resources, you can move that data to a different interoperability paradigm, and it doesn’t change. You can use that FHIR data in a message from one system to another, like an HL7 v2 message would be sent. You can put that data in a document that would be analogous to a CDA document. You can represent that data as a REST API. And you can use that data just as it is in services – in a decision support service or alert service, for example. That’s not true of any of the existing standards.
If you have a lab test result, for example, in an HL7 v2 message, you cannot simply drop it into a CDA document. There’s some transformation required. But in FHIR, you can literally cut and paste the data into a different interoperability paradigm because it carries with it all the value sets and relationships of that data. You can take that data from a FHIR API and put it in a FHIR document or a FHIR message just as it is. You can use that data in a decision support service, for example, because it’s computable represented as it is. We can achieve this concept of true interoperability: we exchange data, and it means the same thing to both ends of that data exchange.
Query for specific pieces of healthcare data
And the other important thing about FHIR that is not true of the other standards is that you can query for specific pieces of data. With FHIR you can receive a minimal set of data instead of getting a huge summary when all that you wanted was the patient’s problem list or the patient’s current medications. That makes FHIR innovative and uniquely suited to the idea of seeing data in different places in real time from where you are or where the patient is. FHIR is profoundly different and moves us into this new concept of interoperability.
How does that compare with earlier concepts? Take a typical clinical document, like a history and physical. If you printed it out on paper, you know what the data represents, because it’s in a certain place in the document. But if you took a pair of scissors and cut that document into data elements, you wouldn’t know what the meaning of that data is. Say it’s diabetes type 2. You don’t know whether that’s a condition the patient has or whether it’s a condition they had before they had surgery and lost 200 pounds, and they no longer have it. Or whether it’s a condition their mother had that is listed in the family history.
FHIR, on the other hand, digitally represents the relationships that we have typically received as a human from a document that structures the data in a certain way. If we took a high-level view of a FHIR procedure profile – it might be a lab procedure, an imaging procedure, or a surgical procedure, for example. We could see a patient upon whom the procedure was performed, the specific procedure that was done, and the provider who was the performer of the procedure. We could see the condition that was the reason the procedure was done and the diagnostic report that comes out of that procedure. All of those are connected in an encoded way, not as a document, but as a FHIR profile.
FHIR follows the iPhone model of maturity
So you may be thinking, well, isn’t FHIR just a draft standard? It hasn’t been around that long. But I think we need to have a different concept of what a draft standard is in this new interoperability era. The previous idea of standards maturity was that a standard was published as a document that was not going to change and so now you could start using it. That idea has changed to what I call the iPhone model of maturity. The iPhone 2, we now know, wasn’t very mature. It didn’t have nearly the functions that the iPhone X has today. But people were buying iPhones early on because they could do things with them they couldn’t do before. It is the same with FHIR.
And last year we had FHIR release 4 which in its core is normative. Normative in the standards world means that you can count on not seeing substantial changes going forward and to backwards compatibility with future versions of the standards. So FHIR has reached a very important milestone. There are parts of it that are still evolving and being developed but we are at a point where you can confidently start building things with FHIR that you can expect to have a long life cycle.
I don’t know if FHIR will ever be at its ultimate level. Just like I don’t know if there will be a final iPhone. What I do know is that healthcare organisations around the world are adopting FHIR because they can do things with it that they couldn’t do before. They are displaying data in ways they couldn’t before – data that was in their own systems but which they couldn’t visualise in a way that was clinically useful. They have implemented FHIR for mobile apps, not for exchanging data across organisations so much, but for being able to access the data in their own systems that they couldn’t get to efficiently before.
They are making that data useful in clinical care by delivering data to apps that are based on FHIR that are customised for the provider or the clinician or the patient. They are using FHIR to pass data from electronic medical record (EMR) systems to decision support services in a standardised way, so decision support can be more accurate and personalised to the patient.
And it’s only going to get better, like the iPhone or any other brand of smartphone. Each subsequent release of FHIR is going to have more functionality, more capability. It is innovation in a data standard and it is driving innovations in healthcare in ways and on a scale that simply wasn’t possible before.
About the author
With an engineering background and over 20 years of medical practice, Dr Russell Leftwich is senior clinical advisor, interoperability, for InterSystems and Adjunct Assistant Professor of Biomedical Informatics at Vanderbilt University School of Medicine. He is board certified in internal medicine and clinical informatics. Follow him on Twitter at @DocOnFHIR.
Are you a CHIA member? Reading this Pulse+IT article entitles you to CPD points. Click here to record your participation.
Posted in Australian eHealth