Introduction
Fast Healthcare Interoperability Resources (FHIR)® provide an easy programming interface for reading and writing information from the electronic medical record. How and what that information is used for is entirely up to the creativity and innovation of those developing the software applications. In our blog article over at SAPHUR we talk a bit about the need for more intelligence around putting patients on oxygen. You can read more about that information here.
Below we’re going to take a look at some of the raw URL queries an application could make to an electronic medical record. The goal here is to get relevant information about whether or not the patient meets thresholds for needing oxygen and making an informed decision to do so.
Notes on Coding
One of the important variables that may change between different health organizations’ EMRs is the coding that is used to describe different types of FHIR® resources. Two hospitals in two different health systems may use very different coding systems in order to communicate the same information. This is why it’s important to test any applications that consume FHIR® resources in the environment for which they are intended to be used.
Identify if a doctor is ordering oxygen for a patient
If we take a look at the list of FHIR resources, we can start pondering what the process of ordering oxygen for a patient would look like in the system. In a live system, you can query directly against data to get a better understanding of how your hospital expresses procedures for oxygen, but for our purposes we’re going to work entirely off of example profiles on the FHIR® website. So, let’s start by assuming that hooking a patient up to an oxygen tank is a Procedure. Though we don’t have a specific example of an oxygen tank procedure, on the FHIR® website we do have an example profile for attaching a patient to a different kind of device, a pacemaker. Let’s assume that when the procedure for adding oxygen is recorded, it is in the same type of format as the pacemaker procedure, just different medical codes and information.
That is a good start, we know we could query FHIR® for a procedure for the given patient that is coded for an oxygen tank, and it would tell us that the patient is on oxygen.
We’ve got a problem though, we want to identify that the patient is going on oxygen before they do. We need to move a little further up the chain of events.
FHIR® defines another resource called a ServiceRequest. By its definition in the specification, a ServiceRequest is an order that will result in either the creation of a Procedure or a DiagnosticReport. Sounds like exactly what we’re looking for! We can now write a FHIR® query to fetch any record of an order for oxygen in the system with a query that looks like this:
This should return any requests that have been made to put a patient on Oxygen. We can then look at the time and status on the record to determine if we need to move to step two.
Check to see if the patient has a recent oxygen saturation reading
Let’s repeat the process. This time we’re looking for a measurement from a medical device which falls under the category of an Observation. We can make a similar query to the Observations endpoint to find any reading for the patient that is coded as oxygen saturation readings. Here we are using a Loinc code:
If no reading, inform the user that they should check the patient’s O2 levels first
If the previous query were to return no results, or after taking a look at the record date on the observations they are all old enough to be considered stale, we’ll know that it’s time to get an O2 reading for the patient.
If there is a reading, check if it is greater than 92%
If the above query returns some results, then we can apply logic inside our code to see if any of the readings are within the last 24 hours. If they are, we can then dig into the valueQuantity field on the resource to get the actual value of the reading. In the case of our example observation, the patient has a current O2 saturation of 95%. This would trigger our logic as we can see that the patient has both a) a request for an oxygen tank procedure and b) a current oxygen saturation reading well above the NIH guidelines.
Informing the user
This is the one piece of the process that will require us to put on our software engineering hats and think outside of FHIR®. SAPHUR’s CART Monitoring application is simply logic running on a computer, and as such, it could take advantage of many of the numerous avenues that organizations use to communicate. It could send messages to users through a secure SMS API, or utilize webhooks to post information in Microsoft Teams. Just a friendly reminder that any patient medical information should only be shared through secure communication channels as defined by your organization. A platform like the CART Monitoring system can provide a code free bridge between logic running against FHIR and a wide array of distributed communication platforms.
Hospital vessel for improvement? Contact SAPHUR today to qualify for a free physician advisor-led consultation for your organization to identify opportunities.
