Understanding FHIR with 1upHealth

1upHealth Resource Center

Understanding FHIR® with 1upHealth

This video breaks down the ins and outs of FHIR, what it is, how it works, and why it matters for healthcare interoperability.

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 healthcar

Transcription

Kevin Yamashita:

FHIR is a data standard for healthcare data. Essentially, it’s actually 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, FIHR is just the application of very basic web technologies. We store the data in JSON and we transmit it [inaudible 00:00:25] accounts. Now these are technologies that have powered the internet in 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 and technology that’s used in all of their industries to really turbocharge what they’re doing for healthcare.

So a server in general, it’s just a computer. That’s all it is. So as we think about a FHIR server, a FHIR server is just a computer shatteringly connected to the internet that supports FHIR APIs. Now there are two different ways that we see FHIR servers manifest themselves. Some FHIR servers actually persist the data. They have this concept of a FIHR repository. They store data in the FHIR format, and when API requests come in, they look at that data repository and they’re able to update the data, create the data, delete the data, send data back out so books can do reads.

There’s another type of FHIR server called a facade. Essentially, this is a layer that sits on top of a database that is generally not FHIR, and this is interesting because it allows you to do some FHIR operations, but not all FHIR operations. Generally, FHIR servers that are the facade model are faster to implement because you just slap the facade on top, but the problem is that these facade models don’t generally support the storage of FHIR based data. So when data comes into a FHIR server that is of the facade model, there’s nowhere for the data to go. 1upHealth is interesting and unique in that we are a repository based FHIR server. We store the data natively in the FHIR format, which means that you never have to deal with transformations or conversions. You can always be confident that when that data gets landed, it persists in FHIR.

Well, the premise of FHIR is essentially all these different organizations can agree on one standard language, right? 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 it, but they never really stuck in the industry. The government has really doubled down on FHIR though, and because of that, we are now seen on the provider side. EMRs have to support FHIR APIs. On the health plan side, payers must now support FHIR APIs. Suddenly, there’s 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 fire is it’s 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 risk in JSON can start to take advantage of FHIR and build interesting and novel things on top of the technology.

So the big idea between FHIR is it allows us to join data sets in ways that we couldn’t before. So 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 can happen and certainly that helps patient outcomes, but more importantly is you can then start to share that data more effectively between organizations.

So 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 patient. The ability to kind of merge data from between different organizations of course gives you a better 360 degree view 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 the healthcare outcomes.

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 talked about interoperability, we’re trying to solve both of those things and FHIR helps us in both fronts. Of course, FHIR makes data more available as more FHIR endpoints are lit up, as more systems support fire 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. So it makes all that data much more actionable in a way that we did not always have before, a way you could at least count on.