Don’t Get BHurned - Keeping an Eye on FHIR Safety

FHIR Jan 27, 2020

By Mike Wang, MD, and Clinical Product Lead at Commure

As a clinician at Commure, one of my roles is stressing the importance of clinically “safe practice” when working with FHIR data. This post will go over some of the expectations clinicians have about their data and demonstrate how ignoring some basic safety principles can lead to delayed or incorrect clinical decisions. For starters, FHIR has a safety checklist which can be found here: FHIR safety, and an accompanying blog post here: FHIR Implementer’s Safety Checklist. I would encourage all healthcare developers to check out Grahame Grieve’s post which includes examples regarding synchronization: Hard #FHIR Safety Problem: Synchronization. Why does this matter? Borrowing a quote from Grieve’s post,

“These safety checks … are mostly chores, and are easily ignored, but a warning: you ignore them at your peril. Actually, it’s worse than that – you ignore them at other people’s peril.”
Mike Wang

The Picky Physician

Physicians consume thousands of discrete data points in their daily practice. To navigate this deluge of data, they have all developed search patterns for navigating this data, whether it be in the EHR, emails, clinical decision support tools, or other sources of data. Search patterns allow physicians to know that by the time they have dissected the chart, they will have consumed all relevant data about a patient to make fully informed clinical decisions. Therefore, even subtle UI changes can be disruptive to these search patterns.

Imagine you are a developer building an app for an inpatient doctor. One common feature request would be a basic metabolic panel that is composed of seven laboratory tests that are commonly grouped together: Sodium, Potassium, Chloride, Bicarbonate, BUN, Creatinine, and Glucose.

Being a helpful developer, you decide to organize these labs alphabetically:

Unfortunately, this alphabetizing has a negative effect. Physicians expect this particular set of labs to be in a certain order as a part of their search pattern. Instead, the ordering should look like this:

If you had presented the physician with the alphabetical ordering above instead of the expected ordering, they might have looked at the Sodium row expecting it to be the Glucose row and consumed incorrect “normal” valued glucoses (remember they are often skimming through this in milliseconds), whereas the glucose values are rather high here.

I hope the above example illustrates that small changes in UI can have major clinical impacts and the second is that you should constantly iterate with your clinical users to make sure that things are displayed in a way that fits into their search patterns (within reason).

With this in mind, we built the Commure component library to make it easy for developers to create fantastic components for physicians. Take a look at our Laboratory components and Vital Signs components, which takes FHIR Observations and sorts them for you.When The Absence of Evidence isn’t the Evidence of Absence

Let’s dig a bit further into other assumptions clinicians might be making when looking at your lab table and let’s assume that this data is from Commure Community Clinic. Lets look at the well-formatted table again:

Notice here that instead of just a plain Sodium, Chloride, etc labels, I’m now showing CCC- Sodium. This means that the Sodium is coded as a Commure Community Clinic- specific Sodium code, something that’s very common in most healthcare settings. Let’s say that the clinician is looking at this table on Feb 2, 2020. When they see a table like this, they are assuming that no additional additional basic metabolic panel data is available between Jan 14, 2020 and Feb 2, 2020. When might this be problematic?

Physician stops looking here because everything looks OK on first glance except for the glucose.

Whoa! That’s some pretty abnormal labs! If you organized your laboratories like this, a physician could completely miss the basic metabolic panel from Feb 1, 2020 because it is not displayed with the other basic metabolic panels and its more than one full screens’ length away from that first set of BMPs. How could this happen?! Well, in this fairly common scenario, the patient had labs from two different sources: Commure Community Clinic and Mike’s Clinic. Because these two sources have their own code sets, the developer here just grouped all the labs by their codes without combining labs with two codes that are actually the same lab type. There are several lessons to take away from this example. First, it highlights the importance of this item on the FHIR safety checklist:

All resources in use are valid against the base specification and the profiles that apply to my system (see note about the correct run-time use of validation) Developers must have clear understanding of the relationship between the data they are displaying (in this case which code systems are being used in the data) and how it interacts with the queries and searches they use to retrieve and display the data.

Second, I will save the details on how to actually fix this problem later, but this example highlights the importance of having good terminology services where maps can be created linking labs like Mike’s Sodium to CCC- Sodium so that they can be grouped together.

Finally, this example also again highlights the importance of having good communication with your physician users. Often, it will be technically slow or impossible to deploy custom mappings to merge data with different codes. In these cases, it is very important to make sure to let your users know that they need to expand their visual search for labs from other sources.

That’s enough of labs for now. Let's take a more detailed look at something Grahme has already touched on in his synchronization example: medications. Again focusing on an inpatient setting, let's imagine that you’re building an app for a physician and he wants you to display all active medications for a patient.

“Easy!”, you say and pull all of the MedicationRequest resources for a patient:

  • Metoprolol Tartrate 25mg PO BID
  • Metoprolol Succinate 50mg PO qday
  • Metoprolol Tartrate 5mg IV q5min
  • Aspirin 81mg PO qday
  • Aspirin 81mg PO qday
  • Aspirin 81mg PO qday
  • Atorvastatin 40mg PO QHS
  • Atorvastatin 40mg PO QHS
  • Aspirin 81mg PO qday
  • Lovenox 40mg SubQ qday
  • Heparin IV gtt
  • Lasix 40mg IV BID

You excitedly show this to the physician, who frowns. “There’s too many medications on here.” In fact, you have forgotten to address this item on the checklist:

For each resource that my system handles, my system handles the full Life cycle (status codes, currency issues, and erroneous entry status)

In the case of MedicationRequests, you need to filter out for only medications with MedicationRequest.status = ‘Active’. Let’s inspect this field.

If you filter out for only the active medications, the list now looks like this:

Oddly, there are still duplicates here. It turns out that you also need to separate inpatient and outpatient medications. For an inpatient physician, you really should only display the inpatient medications. Exploring the Medication. Category codes gives you the following information

Great! Now we can just show the inpatient medications:

Why was it important to only display the inpatient medications? Notice that it’s only on this last cut that the physician obviously notices that Atorvastatin has NOT been ordered in as an inpatient medication. This is a crucial medication for some patients! It would have been very easy to just stop with the “Active” medication filter and display this list to the physician:

  • Metoprolol Tartrate 25mg PO BID
  • Metoprolol Succinate 50mg PO qday
  • Aspirin 81mg PO qday
  • Aspirin 81mg PO qday
  • Atorvastatin 40mg PO QHS (missing on inpatient med list)
  • Lovenox 40mg SubQ qday
  • Lasix 40mg IV BID

However, the physician would have INCORRECTLY assumed that Atorvastatin was already ordered in the inpatient setting.

This example clearly highlights the importance of understanding the lifecycle of a FHIR resource and how it impacts what clinicians expect to see. It also shows how physicians very much a set of contextual filters they expect on their data that they often will not explicitly tell developers. It will be up to the developer to realize that the inpatient context isf important and actually suggests filters on many of the resources that should be displayed. One helpful strategy in this example is to display as much information as possible if you are not sure what is relevant.

As long as you make sure to follow up with your physician users about your uncertainty, the two of you together will be able to sort out the appropriate display filters.

Work fast without breaking things

The purpose of this post is not to scare you away from developing software for physicians. Rather, it is simply meant to highlight of going through the FHIR safety checklist and asking questions when you don’t fully understand how they apply to your software. Commure’s tools will help you iterate quickly so that you can quickly resolve these complex issues with your physician partners. With that all being said, happy coding and don’t get BHurnt.

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.