This page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3
Work Group Pharmacy & Public Health and Emergency Response | Standards Status: Informative |
This module is concerned with resources and functionality in 3 main domains:
Name | Description |
MedicationRequest |
Represents an instruction for the administration of medication to a patient - both in the inpatient (hospital) and community setting. It can also include instructions for the dispensing, the reasons why the administration should occur and other data. It is called an 'Request' to be consistent with other FHIR resources and the workflow pattern, but a common alias for this resource is a 'Prescription' or an 'Order'. The Order itself represents the content of the instruction and is not, by itself, actionable. The workflow process around 'fulfilling' the order is part of the generic FHIR workflow (see below), with the MedicationRequest representing the contents. |
MedicationDispense | The provision of a supply of a medication with the intention that it is subsequently consumed by a patient (usually in response to a prescription). |
MedicationAdministration | A record of a patient actually consuming a medicine, or if it has otherwise been administered to them |
MedicationStatement | This is a record indicating that a patient may be taking a medication now, has taken the medication in the past, or will be taking the medication in the future. The source for this information can be the patient, significant other (such as a family member or spouse), or a clinician. A common scenario where this information is captured is during the history taking process during a patient visit or stay. A medication statement is not a part of the prescribe->dispense->administer sequence, but is a report that such a sequence (or at least a part of it) did take place, resulting in a belief that the patient has received a particular medication. It may be used to construct a patients 'Current Medications' list. |
Medication | The medication resource represents an actual medication that can be given to a patient, and referenced by the other medication resources. In many cases, this resource is not needed and the drug is indicated by a reference to the appropriate terminology and so can be represented using a codeable concept. In other cases, however, it may be desired to indicate more details than the simple drug (such as the packaging, whether it is a generic medication or the active and inactive ingredients) and so the Medication resource can be used for this. |
MedicationKnowledge | The MedicationKnowledge resource is draft and is included for comment purposes. This resource represents information about a medication, for example, details about the medication including interactions, contraindications, cost, regulatory status, administration guidelines, etc. |
Name | Description |
Immunization | The Immunization resource is intended to cover the recording of current and historical administration of vaccines to patients across all healthcare disciplines in all care settings and all regions. This includes immunization of both humans and animals, but does not include the administration of non-vaccine agents, even those that may have or claim to have immunological effects. |
ImmunizationRecommendation | A patient's point-in-time immunization and recommendation (i.e. forecasting a patient's immunization eligibility according to a published schedule) with optional supporting justification |
ImmunizationEvaluation | The ImmunizationEvaluation resource is intended to cover communicating the results of an evaluation of a vaccine administration event (documented using the Immunization resource) against a set of published recommendations (protocols). |
Overview
Medication reconciliation is a process that collects all available medication information about a patient e.g., existing medication orders, patient reported medication orders, over-the-counter medication information (e.g., supplements, vitamins and other medications), medication dispenses, medication administrations, medication history and medication related claims or bills. After aggregating the medication information, the provider determines if any action needs to be taken related to the known medications. These actions include updating an existing prescription, writing a new prescription, writing a new order indicating that a patient should not take a medication, including one or more of the over-the-counter medications, etc. The end point of the medication reconciliation process is to end up with a reconciled medication list that can be shared with a provider or patient or patient representative.
This reconciliation process is often done when a patient is:
At transitions of care, it is best practice to perform a medication reconciliation process in order to determine the status of:
Sources for Medication Information
The source of uncurated medication information is often taken from one or more of the following:
The source data may be captured from systems, often EHRs, MARs, ePrescribing systems, pharmacy or billing systems. Depending on the architecture of the healthcare organization and the larger cross enterprise system the data may involve data housed in centralized healthcare data repositories that include medication related data, e.g., dispenses, orders, claims, Personal Health Records (PHR), or patient portals
How to represent the data that is pulled together and in turn make it available via a FHIR API?
Depending on the business requirements the overall list of medications may include data from diverse systems and if it is important to maintain the relationship of the data to the primary FHIR resources this could end up with a collection of data that is represented with the following resources:
Often, however the internal systems may make a business determination that they will expose the data via one of the resources e.g. If the list of medication data is to reflect what the patient "should" be taking, it would be accurate to represent this using the MedicationRequest resource. See US Core for one example for how to represent this type of approach.
As additional requirements evolve additional resources may be required to support creating a medication list. For example, if you want to include whether the patient is taking or not taking a medication, or whether the patient is taking or not taking the medication as prescribed, you may want to include MedicationStatement to reflect the taking or not taking.
Another example of an additional requirement may be if you want to create a reference to what type of data was used to create the entry on the medication list – this may result in exposing the referenced data as a MedicationRequest (common), MedicationDispense (often), MedicationAdministration(rare), or MedicationStatement (situational).
A strong suggestion is to consider carefully how you want to expose this information. This will influence what resources may be used in a FHIR API interface. A simple medication list may only include one or two of the primary Pharmacy resources e.g. MedicationRequest or MedicationStatement, but a more complex or full featured medication list may include many if not all of the Pharmacy resources.
Context Impacts Medication Reconciliation
In any example it is possible that some medication information may be constrained or even excluded from the medication reconciliation e.g., exclude history of long-past substance abuse, constrain to only prescribed medications. These limited Medication Reconciliation outputs will have some value to some end-uses, but not to all end-uses.
How is Medication Reconciliation information made available to patients or clinicians?
Patients often access the list of medications via a patient facing portal, or they may be provided a paper copy of their medications.
Providers may access the output of Medication Reconciliation directly in their ePrescribing system or EHR which reflects all known medications the patient should be taking at a point in time.
As with all clinical data, Medications (in particular) can be sensitive information as specific medications can indicate the presence of private information such as mental health disorders or HIV. However, withholding information about what medications a person is taking can lead to catastrophic results, and so needs to be considered very carefully. At the least, a clinician should be made aware that there is information available that they have not been given when making clinical decisions.
For more general considerations, see the Security and Privacy module.
The Pharmacy workgroup has plans to improve all existing resources e.g. adding in features that support detailing our conditional orders in a structured way; evaluating requirements for supporting drug formularies and medication knowledge. This work is expected to include the development and approval of a new resource and may involve updates to the Medication Resource.