This page will be used to capture discussion around how to query for medication lists for a patient using FHIR Resources.
Summary
Objective
Document guidance on how to retrieve a medication list. This guidance would cover lists like:
- active medication list - as represented by the patient
- active medication list - as represented by a healthcare organization
- dispense related medication lists
- administration related medication lists
- Medication to be administered
- Medication that has been administered
- Medication that has been "reported" to be administrated
- 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
History
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.
Discussion
- 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
7 Comments
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.
John Hatem
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.
Jay Lyle
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.).
John Hatem
Notes from meeting on Feb 23 MLG call. Input from EPIC: John H reviewed the Medication Administration lists section and asked questions to understand's EPICs current process for inpatient Medication Administration. Clinician enters Order via EPIC module, order sent to Pharmacy, Medication order processing within Pharmacy system. Medications delivered to Med Dispensing systems on IP units. When nurse determines in the MAR in EPIC that a Med should be administered, the Nurse goes the Med Dispensing system, logs in and obtains the Med(s) from the system. The Med Dispensing systems logs this as a "dispense". The nurse administers the med(S) via policy and enters the Med Admin with the EPIC MAR. John H felt this was consistent with how the MLG visioned the use of Med Adm FHIR resources. The types of lists in Med Admin e.g. the list of meds to be administered are essentially Med Requests, and the the list of Meds that have been administered are essentially Med Admins is consistent.
The next discussion was abbreviated but began the conversation regarding Medication Reconciliation process. In Epic they collate all of the information for a patient as the first step and this list of med information may Med Requests, Med Admin and Med Claims, but is represented as a list of Med Requests. Need confirmation of how the "collated" list of meds is represented. Note that at this point the list has not been reconciled, it is just a "unfiltered or assessed" (my words) list of meds. Discussion to be continued next week.
Peter Jordan
This reads very much like a secondary care workflow - i.e. the nurse does this and that. Without wishing to underestimate the importance of that use case, it does not represent the vast majority of prescribing, dispensing and administration events which actually take place in the community. I'm also pretty sure that any country with a national e-prescribing solution will maintain that, in the absence of any administration data, the most dependable source of what medication a patient is actually taking is dispensing data. Furthermore, and from purely personal/family experience, community pharmacists enjoy the highest degree of trust with regard to medication management.
John Hatem
Peter, thanks for your comments. I am not sure what you mean by "secondary care workflow". Most of my comments were made in response to the many discussions we have had in pharmacy with various stakeholders. The most important part of the comment was that depending on the "context" of any medication list, the types of resources may differ for representing the various types of data. When I say "context" I am talking about inpatient e-prescribing as a context, discharge med list at the time a patient is discharged from a hospital is another context, a patient maintaining there own list of medications via some app is another context. When a medication administration is done in a hospital that is a context too. Medication reconciliation is a process and in this exercise it is a context too. There are many other contexts where medication lists are generated and maintained. I agree that in many national systems where dispensing information is available it is often used to construct a medication list ( and yes that is a context too). My comments were much broader in that I was speaking to institutional settings not just community settings; and was also trying to capture what came during that call on the 23rd.
Peter Jordan
Hi John, by "secondary care workflow" I was referring to hospital in-patient use cases. Although I'm not a clinician, I fully understand the variety of contexts in which e-prescribing and medications reconciliation take place - partly due to experiences with octogenarian family members having long medication lists. Unfortunately, the NZ e-Prescribing Service isn't yet implemented in many secondary care settings and, from a medications management perspective, what goes on in hospital stays in hospital with the exception of discharge prescriptions which are usually dispensed by community pharmacies. That's where my experience of medication reconciliation has taken place and the pharmacist generally finds at least one error in any given discharge script. On admission to hospital, community dispensing and prescribing information can be downloaded from the national system in a growing number of districts in NZ; however, our wonderful community pharmacist provides an up to date medications list for me to hand to ambulance workers and ED if/when that system cannot be accessed.