Skip to main content

Representing Current Medications List with FHIR

This post originally appeared on HL7 blog – reposting here with permission:

The HL7 FHIR Connectathon Medication Track

At the HL7 FHIR Connectathon 14, held January 14 – 15, 2017 in San Antonio, I participated in the medication track. See my previous post to learn more about how I ended up in the medication track.

HL7’s Fast Healthcare Interoperability Resources (FHIR®) standard has four key resources related to medication:

What’s tricky is that there is an implied workflow and hierarchy. The medication track discussion I participated in included Eric Haas, Melva Peters, Jenni Syed, Danielle Friend, and Brett Marquard. Our goal was to come to a simplified understanding.

Resources Workflow

The first three resources fit pretty nicely in a work flow:

Step 1. Someone orders medication for a patient (MedicationRequest)

Step 2. A pharmacy dispenses the medication to the patient (MedicationDispense)

Step 3. Someone (or the patient themselves) administers or takes the medication (MedicationAdministration)

So where does MedicationStatement fit into this?

It is similar to a summary/consolidation of these three resources and represents the entire list of medications ever ordered/dispensed/administered for a specific patient.

However, most electronic health records (EHRs) don’t store a patient’s medication history this way.

Typically, EHRs create an order for the medication, and as that medication gets dispensed and administered, the EHR updates the medication order to record the events and any changes. An EHR will also maintain a medication list for the patient, which is the complete list of medication a patient is currently taking.

Some of the medications in the medication list are self-reported by the patient (to record those, the EHR still creates them as an order, but designates in the order that it was self-reported by the patient).

Assuming this is similar to how your EHR records medication data, how do you share them using HL7 FHIR?

Two Common Use Cases

Let’s look at two common use cases:

First Use Case: How to share a patient’s current medication list

You can pull this data directly from your EHR’s medication list (or pull all medication orders for a patient for medications the patient is currently taking). You can then use the MedicationStatement resource to share this list.

Here are a few attributes to pay attention to:

  • Status = active
  • BasedOn – references to other FHIR resources which contributed the information in this MedicationStatement
  • DerivedFrom – references to actual EHR or pharmacy records from which this MedicationStatement is derived (for auditing purposes)
    API call will look like this:

GET MedicationStatement?patient=<patient FHIR id>&status=active

Second Use Case: How to share all medications related to a patient encounter

This will include all medication orders from your EHR related to a particular encounter. You can share these as an individual MedicationRequest resource, paying attention to the following attribute:

  • context – should refer to FHIR encounter resource representing the encounter

API call will look like this:

GET MedicationOrder?patient=<patient FHIR id>&encounter=<encounter reference>

What Happens if Medications Are Dispensed by a Pharmacy Outside the Provider Institution?

Also, if medications are dispensed by a pharmacy outside of the provider institution (for example, a UCSF specialist may prescribe a medication to a patient that is filled at Walgreens or CVS), then the EHR only knows about the MedicationRequest. The EHR does not have the information about dispense and administration.

As such, it may be desirable to get a data feed from the pharmacy, or from the healthcare payer since their claims data feed will also include any pharmacy benefits that will include the data on the medications dispensed by the pharmacy.

I’m not sure how easy it is to accomplish this, but with folks like SureScripts on their way to open up their APIs, it seems like a reasonable route to explore.

Melva Peters, one of the track leaders who hails from Canada, provided an interesting perspective on how this process works for a centralized (at least at the province-level) healthcare system. Pharmacies are required to provide a feed of their prescription-filling activities using HL7 Version 3. Any EHR in the province can subscribe to this feed so that providers may see all the prescription orders for their patients.

Conclusion: Crawl-Walk-Run

My recommendation is to follow a crawl-walk-run approach to see if you can make a patient’s current medication list visible using the MedicationStatement resource.

In the United States, the next step would be to use MedicationStatement resource that pulls data from multiple EHRs and then makes use of intelligence matching logic to create a unified MedicationStatement. This MedicationStatement would be accessible to providers across multiple organizations.

This sort of service will enable a specialist to see a patient’s up-to-date medication list from their primary care provider, as well as any other provider the patient may have visited.

HL7 FHIR Connectathon: First Time Impressions and Other Tidbits

This post originally appeared on HL7 blog – reposting here with permission:

Excitement Filled the Room

It was already 9:23 am. One could argue that on a normal Saturday morning, that’s an early start time.

But I was late. The conference room at the Hyatt Regency San Antonio on the Riverwalk was packed … and buzzing with excitement over FHIR resources, interoperability and the like:

I later learned the total number of participants at the HL7 FHIR Connectathon 14 was 200+ (a sharp increase from the 6 who attended the first Connectathon just a few years ago).

It seemed like 20+ round tables, packed close to each other, each with 6 to 10 participants, elbow to elbow. Some attendees engaged in lively discussion, some furiously wrote code, and some just stared at their screens (most displaying a FHIR resource page) brows creased in concentration.

Where Do I Start?

Why couldn’t I drag my behind out of bed a little earlier for the opening remarks so I could orient myself better?

Which table should I start from?

In this mild confusion, I walked past each table to see if I could find anyone I knew or a track I was familiar with.

What were these guys doing at a Connectathon? I had heard this wasn’t like a certification, but rather more about people testing their FHIR client or server applications against a series of test scripts.

Were there prizes?

How I Landed in the Medication Track

I saw Grahame Grieve (the “God of FHIR”) from the corner of my eye. I’d met him for the first time the week before. He gave me brief nod and carried on imparting wisdom to a seemingly appreciative colleague.

There were many tracks – from the left corner of the room to the right – Provider Directory and Scheduling, Terminology, Medication, US Core, Attachments, Care Plan, Patients (not just for Beginners), CDS Hooks (must be popular as there were 3 tables), Finance and Payers (2 tables), and so on.

Thankfully Eric Haas, who I’d met a couple of times (he lives in Napa, I’m in San Francisco), waved me over to the Medication Track. I dived right into a discussion about how to derive current medication list from the FHIR Medication resources and then …

Eight Hours Later

Fast forward 8 hours and my head was spinning from drinking from the “FHIR” hose (pardon the pun). It was amazing to get all the first-hand feedback from so many smart people, on a host of issues we were dealing with at work in designing a federated FHIR service that pulls and consolidates patient data from multiple sources.

Key Take Aways

I plan to write more about each of the tracks that I participated in, but here are a few of the quick takeaways:

  • With 200+ participants that included providers, EHR vendors, payers, developers, academics and government employees, plus the “Gods of FHIR” – the event was big enough to represent all key aspects of healthcare, but still small enough so that you could walk up to anyone and start a conversation
  • The Connectathon is not a certification. Rather, you run your client or server through a series of test scripts, work with track leaders and fellow participants to better understand the nuances of each failure case, and then make the code changes to become compliant.
  • While FHIR is a standard for data exchange, that doesn’t mean your internal healthcare data model has to be 100% based on FHIR. This seemed like a common trap people fall into as they tried to design their data repositories to be FHIR compliant. I was glad that veterans like Lloyd McKenzie, Brian Postlethwaite, and Grahame Grieve straightened me out. You should design your schema based on what suits your use case (and data sources) the best and then focus on following FHIR when you are sharing /serving that data to others.

Overall, it was very inspiring to see so many smart people working on many interesting applications, with advanced standards knowledge and all skill levels participating. As a first timer, you can’t ask for a better learning opportunity.