The rapidly evolving landscape of healthcare IT presents new opportunities to healthcare providers, payers, and third party application developers. With widespread adoption of HL7 FHIR standards slowly becoming a reality, the stage has been set for the next generation of workflow and applications to be built on top of these APIs. This paper explores a development workflow between engineers and hospitalists to solve a real world resource utilization problem in a clinical environment.
Over the past decade the traditional barriers to healthcare interoperability have crumbled, led by innovations such as FHIR… we are seeing an unparalleled period of advancement. For those who have worked in healthcare IT for an extended period of time this is welcomed news as the industry as a whole has lagged behind many others in adoption of technology standards. A portion of this lag, arises from the special challenges unique to Healthcare, especially around protecting patient information and sharing large amounts of unstructured data across several different record systems. For years, the large players were incentivized to maintain their data in silos, with restricted access that reinforced their market edge. As the gatekeeper of data, they could then charge for additional products and services to facilitate access and interoperability of that data.
Leaders in healthcare IT and EMRs began to recognize the need for a single universal specification for applications to communicate health information. Out of this need the HL7 FHIR specification was born. This spec gives developers a standardized representation of healthcare data that is uniform across all FHIR compliant systems. The idea being that if there is one standardized API across the healthcare industry, applications could be built to run against any EMR system.
Getting Value From FHIR
The development and adoption of FHIR APIs is a fantastic step in the right direction, but there’s a little further to go before an organization can see returns from that adoption. Think of a FHIR API as a piece of infrastructure, like an electric or water line. It provides access to new capabilities, but by itself it isn’t particularly useful. Someone else needs to come along and create the house, swimming pool, or 50 story condo building that utilizes that infrastructure in a way that makes people’s lives better. This is where the developers step in. These developers should be working directly with stakeholders to understand the problems that exist in the hospital system, identify which of those problems could be addressed through the new infrastructure capabilities, and build solutions using constant iterative feedback from users to help refine the experience.
What FHIR offers specifically to application developers that is so compelling is a way to build clinical logic into applications that can plug and play into any FHIR compliant electronic medical record system. It begins to shift the technology paradigm behind healthcare IT from being driven by large complex projects that require consulting experts in the given EMR platform to being a more app store like experience. Healthcare providers can browse for compliant applications, and by granting those applications permissions in the EMR, the third party app has access to all the data it needs to do the job.
At SAPHUR we believe that customer driven development is the only way to identify and address the real needs of our clients. In these next sections of the paper, we sit down with a veteran hospitalist, identify a real world contributor to excess waste and costs within their day to day workflow, and propose a FHIR based solution to address the problem.
The Overuse of Oxygen
“I see this a lot of times at new hospitals I go to. There is a knee-jerk reaction to put hospitalized patients on oxygen regardless of the oxygen saturation measurements in their blood. If you don’t need oxygen, it isn’t very useful, and at times can even be harmful. Aside from wasting a resource on someone who doesn’t need it, the oxygen can interrupt sleep, cause a bloody nose, or pose a fall risk, especially in older patients who may trip over the oxygen tubing.” – Experienced Hospitalist
Here we have a real world problem that is based on imperfect information. We have a doctor telling us that they are routinely seeing something that likely goes against best practices. The first thing we want to do is validate this against a trusted source of best medical practices. After doing some searching we were able to find some relevant information on the NIH website: For the otherwise healthy patient, oxygen saturation targets are generally at 92 to 98% .
Now we officially have some confirmation, that according to the NIH, unless there is some reason to suspect this patient will have trouble with oxygen intake we should check their O2 saturation. If their oxygen saturation is greater than 92% maybe this isn’t a good candidate for oxygen. Now we can break down the steps of what it is we’re trying to do.
1. Identify if a doctor is ordering oxygen for a patient
2. See if the patient has a recent oxygen saturation reading
3a. If no reading, inform the user that they might check the patient’s oxygen levels first
3b. If yes, and reading is > 92%, inform the user that the patient may not need oxygen.
Now, we can map this domain information to FHIR resources.
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. Our 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. There are also platforms like the CART Monitoring system that can provide a code free bridge between logic running against FHIR and a wide array of distributed communication platforms.
Wrapping Up
This was just one small thought exercise on how developers can leverage the new FHIR infrastructure to turn ideas from stakeholders into meaningful automated action within the healthcare organization. As adoption continues, healthcare developers need to build their skills around translating the clinical domain into FHIR workflows in a manner similar to the one we’ve done in this paper.
Leveraging a FHIR Based Resource Monitoring Platform
The example we walked through above was taken directly from conversations between the software engineers and hospitalists at SAPHUR Healthcare Systems. It shows just one small example of how a little bit of logic applied in a timely fashion can help drive down waste and raise the quality of care within a hospital.
Similar to the oxygen problem, we’ve applied this process to an ever growing library of commonly found issues within the hospital. By leveraging this “plug and play” FHIR logic, hospitals can save hundreds of hours of development time and always stay up to date with new FHIR triggers being developed at SAPHUR.
The CART Monitoring platform constantly monitors FHIR looking for issues with resource utilization, length of stay, and patient status. These monitors are all configurable and trackable through a SMART application, allowing administrators to keep an eye on how the hospital is running with little to no IT intervention required.
The system is also designed to integrate into multiple communication channels, allowing your organization to easily set up and control who sees the real time alerts within the system. This ensures the right information gets to the right person in a timely enough manner to make an intervention.
Hi, this is a comment.
To get started with moderating, editing, and deleting comments, please visit the Comments screen in the dashboard.
Commenter avatars come from Gravatar.