What is FHIR? - An Introduction
1upHealth Subject Matter Expert - Kevin Yamashita
What is FHIR®?
FHIR is a data standard for healthcare data. Essentially, it’s two things. It is the way we store the data, the structure of that data, and the way we transmit it.
At a very basic level, FHIR is just the application of very basic web technologies. We store the data in JSON and we transmit it via REST APIs. Now, these are technologies that have powered the internet for the past 10 years, so they’re not particularly new or novel. What’s exciting about FHIR is the application of these tried and true web technologies in the healthcare space – allowing developers and IT departments to leverage commercial off-the-shelf tooling the technology that’s used in all other industries, to truly turbocharge what they’re doing for healthcare.
How does FHIR® work?
How does FHIR work? Well, that’s a broad question, right? So FHIR is a data standard. Essentially, FHIR is a standard set of rules of the road, a standard perspective on how to transmit different data. And it gives you different expectations on what that data looks like when it is received.
So essentially, what we are thinking about in the new world order full of FHIR-based interoperability is all of these different FHIR servers, all of these different web-based endpoints that are able to send FHIR messages out and to receive FHIR messages. Everyone is talking the same language and they’re using the same vocabulary – and that allows data to be transmitted between organizations in a way that we simply could not before in an older era of proprietary data standards, site specific customizations and configurations.
How is FHIR® different from HL7?
When people talk about HL7, they’re generally referring to HL7 v2. It’s an interface message standard. HL7 v2 is event-based. Essentially, in a hospital system when something happens, I send an HL7 message out to another system so it knows to do something or to take some action. HL7 v2 is an old technology. It was prolific through the ’90s and the early ‘00s. Though, it’s still in use at many hospital systems today.
One of the problems with HL7 v2 is it’s a very prescriptive data standard. It’s not always easy to get all the data points you want in the interface message. Oftentimes it’s used very differently between different sites and different systems, so it’s hard to interoperate and to integrate those systems together. There’s never a sense of a whole with HL7. Essentially, I can’t take all of my HL7 transactions, add them together and get a sense of “Who is this patient? What is the encounter?” I’m only getting snippets and slices along the way.
FHIR is something different altogether. With FHIR, there is a sense of a patient resource and encounter resource that is always holistic in spans and gives you a total view of what that thing is. And we use API messages and API transactions to pull that data back and forth. So instead of slices in time, there’s always a sense of a whole that’s being transmitted, which gives you a much broader, more stable foundation for interoperability.
Why use FHIR®?
The premise of FHIR is essentially that all these different organizations can agree on one standard language. For the first time ever, we have something that is both flexible and scalable for communicating healthcare data and that is FHIR. There had been other runs in, but they never really stuck in the industry. The government has really doubled down on FHIR though, and because of that, we are now seeing on the provider side EMRs have to support FHIR APIs, and on the health plan side payers must now support FHIR APIs. Suddenly, there is a groundswell of support for FHIR. So it is a language that people can consistently use to communicate in a way that we could not really do so before. And the beautiful thing about FHIR is it is based on standard web technologies. So it does not take a very niche subject matter expert to understand how to work with this. Anyone that understands REST in JSON can start to take advantage of FHIR and build interesting and novel things on top of the technology.
How does FHIR® improve access to healthcare?
One of the major problems with healthcare interoperability is that not only do you need to get the data, but then you need to do something with the data. So as we talk about interoperability, we’re trying to solve both of those things, and FHIR helps us on both fronts. Of course, FHIR makes data more available. As more FHIR endpoints are lit up, as more systems support FHIR APIs, there is a broad amount of data that becomes available. But because all that data is in the FHIR format, that means that it’s also usable; you know what to expect. There are certain rules of the road in terms of the topology and the shape of those resources and records that you receive. It makes all that data much more actionable in a way that we did not always have before in a way you could at least count on.
How does FHIR® improve outcomes in healthcare?
So the big idea behind FHIR is it allows us to join data sets in ways that we couldn’t before. Not only are we talking about joining data sets within an organization (maybe doing a better job of pulling data from the standard ambulatory EMR and joining that with the inpatient EMR and joining that with the oncology system, maybe helping us pull in structured data from a cardiology or radiology system) there’s this idea of data aggregation that could happen – and certainly that helps patient outcomes. But more importantly is you can then start to share that data more effectively between organizations.
For example, maybe a payer has a different slice of data from when you were previously going to another provider system. Maybe there are outside organizations like clinical research organizations that have data on a given member or a patient. The ability to merge data from between different organizations of course gives you a better 360 view of the patient, of the individual. It allows folks to take action on that data, and in some ways it democratizes that data and makes it more available to the individual, empowering them to take more control over their own healthcare and healthcare outcomes.
What is healthcare interoperability?
Healthcare interoperability really encompasses two things. It is both the ability for organizations to get data from various data sources (generally, from outside organizations, but in some cases from within the organization itself), and more importantly it’s the ability to do useful things with said data. So often when we think about interoperability, it’s simply about connecting disparate systems (two IT systems in a hospital, maybe a payer and a provider). And by and large, we are able to send data between different organizations and different systems.
Where interoperability is struggling these days is the ability to do functional, useful, value adding things with that data. That’s where FHIR becomes very useful. Because it is a consistent data format with rules of the road that everybody agrees to, as you get inbound data, it’s easier to merge and aggregate. It’s easier to build applications on top of this data structure, because you know what to expect – the idea being we can then use FHIR to help folks actually leverage that data to improve the outcomes.
What is different about FHIR® at 1upHealth?
Here at 1upHealth, we’re a FHIR-first company. That means everything we do is rooted in FHIR at the core. That’s one thing that’s different about us, but it’s not the most important thing I would argue. The FHIR spec does a lot, but as we see folks trying to use FHIR to actually do things, to improve outcomes, to integrate systems, what we realized early on is there’s a lot of peripheral necessity that the FHIR spec doesn’t address. What’s special about 1upHealth is we are not just a core FHIR server- we’re a core FHIR server with a lot of peripheral application functionality to actually help you get through that last mile.
You could go to a large cloud service provider and get a FHIR API and a FHIR server, but it’s not going to help you with things like authentication mechanisms for patient-mediated APIs. It’s not going to help you with things like member matching to make sure that you are merging data together appropriately. Here at 1upHealth, because we are FHIR-first we understand very, very well what the FHIR spec is and what it represents. That also means we understand where it falls short and those are all holes that we fill to make sure our customers can leverage FHIR to its fullest.