Representing a Patients list of Medications in FHIR

An interesting use case for FHIR is maintaining a list of a patients medications – i.e. the medications that they should be taking on a regular basis. Most EMR (Electronic Medical Record) systems will maintain such a list.

Each medication will have it’s own properties (such as drug name, dosage, how often to take, period of use and so forth), but for the purposes of this post we’ll focus on how to maintain the list on a day to day basis – including changes to the list – and consider the details of representing a single medication in a later post.

Knowing this list when treating a patient is, of course, of critical importance in healthcare as ‘medication related incidents’ – ranging from minor drug reactions through hospital admission and even death is a common cause of injury to the patient, as well as massive costs to the health system.

It is also important to know the history of changes to the list – i.e. when medications have been changed/stopped and new ones added, who made the change and the reasons why these changes have occurred. In some jurisdictions, this is called ‘reconciling’ the list from different sources of medication information such as dispense and administration information.

To represent this in FHIR, we’re going to need a number of resources.

Obviously we’ll need those that describe each medication. This is the MedicationPrescription resource that records the details of how a single medication should be taken. It includes references to the medication resource (representing the drug), the patient and the prescriber.

To represent the list that is active at any one time, we have a number of options.

Option 1: Query the MedicationPrescription resources for a patient

Each MedicationPrescription resource has a ‘status’ property whose value can be active, paused, completed or nullified. One option then is to get a list of all MedicationPrescription resources that have an active status like this:

GET /Patient/100/MedicationPrescription?status=active

(This uses the compartment feature to retrieve active MedicationPrescription resources for the patient with the ID of 100).

This would certainly work – but it becomes difficult to track changes over time – especially the reason for change.

Option 2: The document

Another option would be to place the medications in a FHIR document. We could have a section for the initial list of drugs and another section for the changed list of drugs. The advantage of this approach is that we can record the name of the person making the change, dates, locations etc. The disadvantage is that it’s a somewhat complex approach – requiring submitters and consumers to create and read documents.

Option 3: The List

There is a third approach that allows us to record these other data items as well as the actual list of medications – the List resource. This resource has been specifically created to maintain lists like this, and offers the following properties:

  • The type of list (we’ll use the LOINC code for ‘history of medication use’ to be consistent with CCDA). This is the code property, and is a codeableConcept datatype
  • The subject of the list – which will be a reference to the Patient resource
  • The source of the list. In this case it will be a reference to the Practitioner who created the list. The cool thing here is that when the list changes, we’ll create a new version of the list setting the source property to the Practitioner who changed it.
  • The date the list (or this version of the list) was created.
  • The mode of the list. In our scenario we’ll set this to ‘working’ as we intend it to be the on-going master list but there are other values that can be of use – eg ‘snapshot’ at a point in time which we may want to use in a referral for example.

Then there are any number of entries in the list. Each entry represents a single medication in the list, and has the following properties:

  • A reference to the medicationPrescription.
  • A flag for the entry. This allows us to indicate the nature of any change to the item between versions of the list – which is incredibly useful in reconciliation situations, or in Use Cases like representing the changes in medication when a patient is discharged from hospital. For example, one of the options could be ‘ceased’ to indicate that the patient was taking the medication on admission, but it was stopped while in hospital.
  • The deleted property. This allows us to explicitly state that this item is no longer active – it has been discontinued. In our case when we stop a medication we will also set the flag and the status in the

One thing that is missing in the entry is the reason for any change. For this we’ll add an extension to the entry element with a datatype of CodeableConcept and we’ll define a set of common reasons why a change occurred. In the example the extension is defined in a profile located at profile/mlomChangeReason

Putting all this together, the following example shows a medication list with two items:

  • Atenolol – which has been stopped due to an allergic reaction.
  • Labetolol – which was started in it’s place.

so the patient is actually only taking Labetolol. If you wanted the details of each prescription, you would get it from the reference in the list.
The list was created by Dr Welby on November 1st, 2011 for Mr I. Amanexample.

<?xml version="1.0" encoding="utf-16"?>
<!-- An example showinf a single item in the list - atenolol. As it is cancelled (due to an 
  allergic reaction), we know that the patient is not taking any medicines (as far as we know)-->
<List xmlns="">
    <status value="generated"/>
    <div xmlns="">
        <li>Atenolol 50mg at night was stopped due to an allergis reaction</li>
        <li>Labetolol 50mg at night was started as a replacement</li>
  <!-- This is the list Code - udentifying it as a list of medications -->
      <system value=""/>
      <code value="10160-0"/>
      <display value="History of Medication Use"/>
    <text value="Medication List"/>
  <!-- The patient the list refers to -->
    <reference value="Patient/example"/>
    <display value="Mr I Amanexample"/>
  <!-- who created the list -->
    <reference value="Practitioner/100"/>
    <display value="Dr Welby"/>
  <date value="2013-11-01"/>
  <mode value='working'/>
  <!-- The first medication entry -->
    <!-- The reason for change -->
      <url value="profile/mlomChangeReason"/>
          <system value="urn:oid:"/>
          <code value="ar"/>
          <display value="Allergic Reaction"/>
        <text value="Developed a rash shortly after starting"/>
    <!-- Indicates this is a concelled medication -->
        <system value="urn:oid:"/>
        <code value="03"/>
        <display value="Cancelled"/>
    <!-- So any consumner of this resource knows it is a cancelled med. The deleted property is a code with
    a fixed set of values, whereaes the flag is a codeableConcept, and the meaning depends on the terminology used.
    Every FHIR consumer MUST understand what a deleted property means...-->
    <deleted value="true"/>
    <date value="2013-11-01"/>
      <!-- The reference is to the actual prescription resource. This will have details of dose, prescriber etc. -->
      <reference value="MedicationPrescription/100"/>
      <display value="Atelolol 50mg at night"/>
        <system value="urn:oid:"/>
        <code value="04"/>
        <display value="Prescribed"/>
      <text value="Started"/>
    <deleted value="true"/>
    <date value="2013-11-01"/>
    <!-- The reference is to the actual prescription resource. This will have details of dose, prescriber etc. -->
      <reference value="MedicationPrescription/101"/>
      <display value="Labetolol 10mg at night"/>

We can retrieve this list as follows:

GET /Patient/100/List?code=10160-0


  • This is actually a query in FHIR, so would return a bundle containing the List resource – and there should only ever be one that matches for a patient.

In the next post, we’ll look at how we can record changes to the medication list, using the versioning mechanism in FHIR, as well as updates to the medicationPrescription resources as well.

About David Hay
I'm an independent contractor working with a number of Organizations in the health IT space. I'm an HL7 Fellow, Chair Emeritus of HL7 New Zealand and a co-chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the FHIR standard. I'm the author of a FHIR training and design tool - clinFHIR - which is sponsored by InterSystems Ltd.

16 Responses to Representing a Patients list of Medications in FHIR

  1. Friendly Fhir says:

    I have a question about the nature of your lists of medications. Are they ordered lists and do they permit duplicates?
    I read from the documentation that the List resource “enumerates a collection of resources that are in some list” but I’m worried that in practical use I won’t be able to distinguish a List from a Group from a Compartment.
    For example, why could’t I define a PatientMedication resource that had a PatientID and thus created a Compartment (“a logical grouping of resources which share a common property”) of medications taken by that patient?
    Alternatively, I could create a Group of medications to represent the same thing – a Group being “a defined collection of entities that may be discussed or acted upon collectively but which are not expected to act collectively …”

    • There are different possible architectures to solve the same problem. If you use the Partition approach, then there’s no human intervention involved and the queries are resource-specific. I.e. You can access all of the MedicationPrescriptions for a patient or all of the MedicationDispenses for a patient or all of the MedicationStatements for a patient. And you can filter them by search criteria as you wish. (You actually don’t even need partitions for this. Partitions just alter how the URL is structured. They don’t change the ability to query at all.)

      With a List, you have manual intervention. The plus is you end up with curated content, so identifying the important things, filtering duplicates, ordering in a clinically relevant way, etc. The downside is you’re dependent on the curation being current. If a new drug is dispensed but no-one updates the List, then that medication won’t be reflected. While in theory you could have an auto-updating list, the benefit of doing that over just querying the individual resources is unclear (though in theory you might have a system that algorithmically adds much of the value human curation could add)

      Group is a completely different thing. Group is definition of kinds of things. So “all females age 35-50” or “all cows within 10km of a particular origin point”. You could have a group of “All medications involved in pneumonia treatment” or something like that, but it wouldn’t make sense to group dispense records or prescription records or something like that.

      • David Hay says:

        Thanks Lloyd! btw – I suspect you meant ‘compartment’ in place of ‘partition’…
        I especially liked your comment on Group – as this shows how resources can be grouped together in different ways, which is difficult to do in a document paradigm…

      • Friendly Fhir says:

        Thanks. List doesn’t seem to require its component resources to be of the same type. Is there some way of declaring that my List is made up of (say) patient medications specifically?
        The Group concept seems rather wide ranging.
        Is there some way of constructing a Set (order unimportant, no duplicates)?

      • David Hay says:

        You could do that using a profile I believe (though I’m not sure if the ‘no duplicates’ could be enforced….). However, for medications I’m not sure that you’d want to enforce that anyway – for example you might have a prescription for warfarin 5mg and 1mg tablets with the dose titrated by INR value)

  2. Pingback: Saying ‘No’ with FHIR: The List resource | Hay on FHIR

  3. Pingback: Clinical Scenarios in FHIR: Adverse reaction | Hay on FHIR

  4. Pingback: Clinical Scenarios in FHIR | Hay on FHIR

  5. Ian McNicoll says:

    Hi David,

    I am interested to understand your choice of Medication Prescription as against Medication Statement. If I am reading the specification correctly, at least some of the meds rec. source documents are likely to be in the form of a medicationStatement e.g Emergency GP Summary.

    Not sure I really disagree with your choice of Prescriptino but intewrested to know if Statement was considered.


  6. David Hay says:

    Good question!

    Well, the reason why I chose MedicationPrescription was that there were elements in that resource that I wanted to capture – like the reason why the person is taking the medication, and who decided to start it, PRN status and so forth. However, I note on reviewing the spec that the scope of usage for medication statement is specifically for “the summarization of a patients ‘active medications’ in a patient profile”, so I guess that was not the right decision!

    However, I do want to record those details (at least the reason why it was being taken and/or PRN), so I guess I need to petition for a change to MedicationStatement or add extensions to that resource…

    I will ask some of my colleagues in the Pharmacy WorkGroup for a comment as well…

  7. Pingback: Medication lists revisited | Hay on FHIR

  8. Joshua Vivian Robert says:

    I have a question about the “GET” method for List. Unlike other resource where the “GET” method looks like “GET/someServerName /Patient/1”, is the GET Url for the List resource similar to the other resources or is there a different way to define the GET Url for List.

    • David Hay says:

      Hi Joshua,

      The List resource is the same as any other so GET [server]/List/1 would return the List resource with the id of 1. You can search in the same way as any other resource – the defined parameters at the bottom of the page:

      The whole question of lists of things is being refined for the ‘official’DSTU-2 so keep an eye on that – should be available in a few weeks. I’ll try to remember to place a link here – or maybe another post!


  9. Paul says:

    Hi David, we are currently looking at implementing this very feature using FHIR. I see this is a relatively old post with DSTU-2 released since then. Is there anything of importance you need to point out that may have changed or does the majority of this post still hold true? (I see MedicationPrescription is now MedicationOrder for example). Do you feel MedicationStatement with extensions or a list of MedicationOrders is better suited for reconciliation?

Leave a Reply

%d bloggers like this: