1upHealth Resource Center
How FHIR® Works
This video covers the technical workings of FHIR and helps you understand FHIR resources, APIs, endpoints, servers and more. For example, 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
Transcription
Kevin Yamashita:
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 if 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 FHIR based healthcare data.
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’s a web URL that’s defined to indicate where that transaction happens.
FHIR extensions are a special type of FHIR resource. Essentially, they’re chameleons. FHIR is designed to be extensible. There are going to be times 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.
How does FHIR work?
Well, that’s a broad question, right? 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’s 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 or site specific customizations and configurations.