Get Under the Hood of FHIR - A Closer Look
1upHealth Subject Matter Expert - Kevin Yamashita
What are FHIR® resources?
As we think about FHIR, FHIR resources are essentially the types of objects that we use to store data. So essentially, there are FHIR resources that represent a patient, an encounter, an observation. These are basically the different buckets that we might store different data into. They are data types at a very basic level.
What are FHIR® profiles?
FHIR profiles are essentially the rules of the road for a given FHIR resource. Let’s take a patient, for example. Out of the box with a FHIR patient resource, there’s not a lot of required fields, so that doesn’t make the patient resource all that useful. Essentially profiles say: “Here are the standard fields, the standard attributes, that a given patient record should have.” And when we agree on the application of a FHIR profile across the board, we can then count on certain information to always be there (a name, an address), as we apply these to different resources, an explanation of benefits for example – this allows us to be sure that we’re always getting certain amounts of data and that helps support interoperability use cases.
What are FHIR® APIs?
At a very basic level, APIs are a set of standards for how two different computers communicate. API stands for Application Programmer Interface. Essentially, we use APIs so that one IT system can talk to another IT system.
A really good analogy is a menu at a restaurant. When I walk into a restaurant and I sit down, I don’t need to worry about what they’re doing in the kitchen. Maybe I order a hamburger and French fries, and I don’t need to worry about whether they have to cut up the potato. I don’t have to worry about whether they’re going to knead the bread to bake the bun. All I know is I want to order a hamburger; I want some French fries. Essentially, APIs are the different menu offerings available to me.
By that same token, the back of the house, the kitchen doesn’t need to worry about what I’m going to do with those French fries. Maybe I put it on the burger; maybe I dump it in my milkshake. It doesn’t really matter. APIs are essentially a menu by which two different sides of the house can talk to one another without having to worry about how that data is used. And FHIR APIs, of course, then allow us to do all this on top of buyer-based healthcare data.
What are FHIR® operations?
There are very standard things I might do with a FHIR API. At a very basic level, the FHIR API specification supports CRUS operations: create, read, update, destroy. I can create a new patient object, I can update an encounter, I can delete a given object – but there might be more advanced things that I want to do. FHIR operations essentially give us a framework to define those different things. So if in addition to creating a resource I want to do some type of validation of the resource for conformance against a given implementation guide or FHIR profile to check X, Y, and Z structurally, I could make a call to a FHIR operation. In this case, it is something called $validate, and that would allow the FHIR server to do a validation operation. The idea is that the FHIR specification is extensible – as we need different operations, the specification gives us this space, this room, to find here are other functions that a FHIR server might need to do when API messages come in. That’s the benefit of a FHIR operation.
What is a FHIR® server?
A server in general is 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 FHIR 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 data, delete data, send data back out so folks 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. 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. 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 convergence. You can always be confident that when that data gets landed, it persists in FHIR.
What are FHIR® endpoints?
Endpoints essentially are the place where two servers communicate via API. At a very literal level, an endpoint is just a URL. Server A needs to know where to go to talk to server B, and in most cases it is a web URL that’s defined to indicate where that transaction happens.
What are FHIR® extensions?
FHIR extensions are a special type of FHIR resource. Essentially, they’re chameleons. FHIR is designed to be extensible, so there are going to be times when we want to land a type of data in FHIR for which there is not an appropriate FHIR resource. When that happens, rather than having developers and IT staff land data in a FHIR object against different attributes or fields in that object that don’t really make sense, we have this concept of an extension. It’s really an extensible resource type that is generic by design so you can define different data structures and different types of data formats when you don’t otherwise have an appropriate place to land that data.
What is SMART on FHIR®?
SMART on FHIR is a context for building applications on top of FHIR APIs. At a very basic level, what SMART on FHIR is trying to solve is the ability to build applications that launch generally in an EMR or a web portal context. The idea here is if you build an application with the SMART on FHIR framework, you are building an application that generally communicates with an underlying system via FHIR APIs. The premise here being that if I do this, I can deploy that SMART on FHIR application against EMR A or EMR B. And so long as both of those EMRs support the SMART on FHIR framework and support FHIR APIs, that application is generally plug-and-play.