Any web developer who has consumed information from a third party web service in the modern internet age has a pretty good assumption of the mechanics of how they are going to access that information. Your going to make some kind of request over Secure Hypertext Transfer Protocol, it is going to return some data back via the same protocol. To make it it easier to understand how to ask for and read this information the service might be built in a RESTful manner. RESTful services are nice because they allow us developers to have a basic idea of the rules of the information… I am going to be interacting with entities that are hard nouns (Customers, Orders, Books, Tourist Attractions, etc.) and I am going to be creating, removing, or altering them with a set of verbs (Get, Put, Post, etc.). I also know that the information I am sending and receiving will be coming in JSON format.
Fast Healthcare Interoperability Resources (FHIR) were created as means to make the EMR system more accessible to developers like myself by creating a RESTlike web service that applications can interact with. Here the “interoperability resource” profiles are essentially the REST nouns we were talking about above (Patient, Encounter, MedicationRequest, etc.) and the standard rest verbs are used.
This means as a developer who already understands the fundamentals of REST web services, I can get up and running, developing real applications against electronic medical records without needing to learn any new technology. The same fundamentals that power some of the most successful web services in the world are available through the EMR via FHIR.
First FHIR Calls
Above is a link to a Postman collection you can use to try out your own queries against the HAPI FHIR server.
Let’s get right into it shall we? As we mentioned in the FHIR introduction, we’re going to be making HTTPS calls to a FHIR server, interacting with a resource through an http verb.
Patient
This is the GET call we would make to a FHIR server to access information about a patient with the identifier 118.
http://hapi.fhir.org/baseR4/Patient/118
Now let’s take a little look at what is going on in this response payload and how it compares to the documentation on the patient FHIR resource definition on the HL7 website. Looking at the definition you’ll see there’s quite a number of fields that can be on a patient resource. However many of these aren’t required, and you’ll find that not all information listed in the resource definition is going to be available in every EMR environment.
You’ll see in our test example that while the patient does have the basic information like name, DOB, and status. Many of the fields that are in the FHIR definition but are not required are not included in the response, things like emergency contact are not available for this patient. This is meant to illustrate one of the dangers to keep in mind as you venture out into the world a FHIR development. Even though FHIR is designed to standardize and simplify access to EMRs, there are still a lot of nuances between different system configurations and environments. Expecting that the information in the FHIR API will behave precisely the same between two different hospitals is not a guarantee!
Observation
http://hapi.fhir.org/baseR4/Observation?patient=118
Here is the GET call that will get any observations for the patient we had queried above. Similar to the patient resource, the FHIR documentation and specification provide for a wide and robust amount of information to be attached, but in reality only a very small amount of information is actually required to create an instance of that resource. Let’s break down this observation a little bit to see what it actually is telling us.
The code section will give us some useful information as to what sort of event this observation actually was. In this one we it’s telling us this observation is coded as LOINC code 29463-7
. A quick Google search tells me that this is a LOINC code for body weight.
There’s also references to a subject, which will be a patient id in the system, and an id referencing the encounter the weight was recorded during.
The valueQuantity field is where the juicy data we want to work with lives. You can see that in that object we have a report of a value, a unit, and a coding system to which that unit belongs.
Explore FHIR
I hope these two examples are enough to get the juices flowing around what you can do with FHIR API. Really it’s just a standardized RESTlike interface, just like working with an API from one of the heavy hitters in tech.
If FHIR is brand new to you, I would highly recommend you take some time here to explore the resources on the FHIR website. This will help you start to get an idea of the shape of the domain. As you get familiar with the resources and how they reference each other, you can really start to build a model in your head around how the events happening in a hospital translate to additions, subtractions, and alterations to the resource profiles.
Examples:
A patient (id = 456) has a scheduled phsyical examination translated to FHIR
When the appointment was created a new Encounter instance was created that references patient 456 and has a status of “planned”. When the exam begins, the status of the encounter is changed to “in-progress”. As the examination continues, data like weight and blood pressure are being recorded in the system. This creates new Observation resources that have a reference to the current encounter and patient. These observations have some kind of code that tells us what they are and information about the actual measurements valueQuantity field. When the visit is completed, the status of the encounter is changed to “completed”.
A patient is brought in by ambulance with a broken leg, gets a painkiller and an x-ray.
Patient reaches the hospital and a new encounter is created already with an in-progress status. The doctor examines the patient and suspects the leg is broken, so he orders a pain killer and an x-ray examination of the break. This creates a MedicationRequest and ServiceRequest in FHIR coded for the painkiller and the x-ray. When the prescription is filled, the MedicationRequest becomes just a Medication attached to that patient. Once the results of the x-ray come back, new observations are available in the system with data coming from the procedure.
Add allergies – insurance type –
Spinoff ideas: “Where’s my patient?” – Routing of information – OB visit check blood sugar control – A1C or Hemoglobin A1C or Hb A1C or etc.
A Michigan hospital was tied with others 100 miles away, didn’t get order at hospital, instead accidentally ordered a scan coded for a different facility, so it was delivered to radiology in a hospital 300 miles away. No feedback was given.
Labs might have different coding systems as well. From a physician perspective they have to know the number, certain EMRs could have specific codings that change between health systems.
Outpatient Obstetrical
- Registration
- Vitals
- Observations
- Labs – (advance?)
- ServiceRequest
- Observation
- Ultrasound
- ServiceRequest
- Documentation or Imaging
- Prescriptions
- Demographics
Both of these examples are extremely simplified versions of what is likely actually going to be happening within the system at a living breathing hospital. It was meant to illustrate how FHIR can be used as the language you can model the healthcare journey after. As you’re exploring the different resources available, be thinking about what sort of events may have an effect on this particular kind of resource.
Wrapping up
Hopefully this introduction to querying FHIR has given you a better understanding of what FHIR is and why it is super useful to developers. It provides a quick and intuitive interface that web developers already understand how to use for directly interacting with the electronic medical record system. In the upcoming section we’ll begin to take a look at how we can build applications that are able to authenticate themselves and consume information from FHIR servers.
