Skip to end of metadata
Go to start of metadata

This page will be used to capture discussion around how to query for medication lists using FHIR Resources.



Document guidance on how to retrieve a medication list.  This guidance would cover lists like: 

  1. active medication list  - as represented by the patient
  2. active medication list - as represented by a healthcare organization
  3. dispense related medication lists
  4. administration related medication lists
    1. Medication to be administered
    2. Medication that has been administered
    3. Medication that has been "reported" to be administrated
  5. Medication history lists  - based on MedicationUsage resource

There may be other lists of medications - EHRs or ePrescribing systems sometimes present to their users, list of active medication orders, orders on hold, orders that have run to completion, orders that are not filtered by any status, whether active or in another state e.g. hold, completed, entered in error, etc. 

to do: define what "active", "current", "regular", chronic

to do: define what it means when the patient states "I am currently taking a medication"

to do: what it means when we document what a patient "should be taking" and how to represent that in FHIR


In US-Meds IG (STU3), the active medication list was retrieved by querying MedicationRequest exclusively where intent = order or plan (i.e. derived from Statement).

In STU3, MedicationStatement had two elements for taken (Boolean) and status.

  • Taken was used to represent the medication usage (in the past)

  • Status was used to infer whether the medication should be on the “active meds list” (i.e. whether the patient should be taking the medication going forward)

In R4, MedicationStatement added not-taken into the status value set (and removed the taken Boolean). 

In R4, MedicationRequest was enhanced to add a new reported[x] element that indicates whether the MedicationRequest was reported (insert definition).

The Problem

Using MedicationStatement exclusively in R4 doesn’t work since we lost the ability to use MedicationStatement.status to convey whether a not-taken medication is active or not.  Some not-taken medications are associated with active orders/prescriptions while other not-taken statements are associated with old orders/prescriptions that have since been completed or stopped. 

Using MedicationRequest exclusively in R4 doesn’t work since it is still not scoped to handle patient statements about their over-the-counter (OTC) medication usage that don’t have an underlying prescription or request.

Using both MedicationStatement and MedicationRequest introduces patient safety risk if an application made a false assumption that all active medications were returned from a single resource.

Furthermore, the boundaries between MedicationStatement and a reported MedicationRequest present a challenge for systems that don’t make that fine distinction.  For example, the following use cases are often handled in the same way:

* Patient conveys to provider A that another provider B prescribed a given medication (this is debatable whether it is a MedicationStatement or a recorded MedicationRequest)

* Patient conveys they took an OTC medication (this is a MedicationStatement – since the patient isn’t requesting a new prescription)

* The system programmatically learns of an existing medication and makes a non-authoritative copy (this is a recorded MedicationRequest)

Most systems CAN differentiate between:

* What the patient said about their medication usage (taken vs not taken)

* Whether the provider wants to keep the recorded MedicationRequest or MedicationStatement on the active medication list

In summary, we have a bit of a catch 22 where:

* We can’t use MedicationStatement exclusively (when status = not-taken), nor can we use MedicationStatement to convey status of what was ordered (when usage differs from what was ordered).

* We can’t use MedicationRequest exclusively (when scope excludes patient statements about OTC medications)

* Systems often don’t differentiate between reported MedicationRequests vs MedicationStatements, so the boundaries are challenging to honor.

R4 Next Steps

Base specification allows the active med list to use MedicationRequest or MedicationStatement

Argonaut / US-Core IGs proposal to use MedicationRequest exclusively

R5 Next Steps

Clarify boundaries between reported MedicationRequest and MedicationUsage (and confirm that systems can honor those proposed boundaries)

MedicationUsage.status value set reviewed and updated to support:  Completed, Entered in Error, Unknown and removed all other status values.  

MedicationUsage was enhanced to add a new Adherence element that indicates whether the patient has Taken, Taken as Directed, Not Taken as Directed a medication. 



  • Should pull requirements together and include the context on the medication lists and their use
  • New Zealand - strongly view that MedicationStatement - patient's lists of medications drawn from multiple sources - national repositories, pharmacies, prescribing systems
  • need to consider how to get this done in light of updates to US Core
  • No labels


  1. Unknown User (peter_sergent)

    In New Zealand we have 3 use cases.

    Meds reconciliation where when a patient fronts at a hospital a list is generated of the current meds by the patients recollection and/or they bring their meds with them. This is compared with a Ministry web site “medsafe” which is a patient record built up from dispense data. This seems to me to be a med statement.

    NZ is building a “my meds” which will be a repository of a patients meds and other active substances. It is built from dispensed information and patient entered information relating to OTC meds and herbal meds. We flag certain meds as long term meds and assume that these will always be in the possession of the patient. Other meds are deemed to be active if they have been dispensed in the last 12 months. This data base also has links to patient data sheets

    Aged residential care facilities have medicine charts for the administration of medicines.

    You will note none of these depend or use medication orders. Charts may cause orders to be generated but not the other way round.

  2. Active Medication lists require context to understand what resources should be used to query a list of active medications. 

    For instance, if I want to construct a list of active medications, as reported by the patient, the list could/should be constructed by querying for Medication Statements. 

    However if you want to construct a list of active medications that is comprised of authorized Medication orders you would use the Medication Request resource. 

    The list of active medications that also includes both authorized Medication orders and externally created Medication orders, (outside of your institutional control), and also over the counter medications reported by the patient involve querying for both Medication Requests and potentially, Medication Statements.   

    Another requirement we have heard in Pharmacy has been the need to understand if the patient is compliant in taking the ordered Medications.  The notion of compliance should be defined with greater rigor.  However the current method to capture compliance via - taken/not taken is done by using the Medication Statement resource.  

    1. VA has submitted some requirements for Usage to USCDI here. This proposal also includes a less mature requirement for "experience" to reflect circumstances affecting adherence (side effects, social impediments, etc.).