View raw Markdown
type: resourceresource: MedicationRequest

MedicationRequest

Introduction

Scope and Usage

This resource covers all type of orders for medications for a patient. This includes inpatient medication orders as well as community orders (whether filled by the prescriber or by a pharmacy). It also includes orders for over-the-counter medications (e.g., Aspirin), total parenteral nutrition and diet/vitamin supplements. It may be used to support the order of medication-related devices e.g., prefilled syringes such as patient-controlled analgesia (PCA) syringes, or syringes used to administer other types of medications. e.g., insulin, narcotics. It can can also be used to order medication or substances NOT be taken.

This resource would not be used when ordering a device(s) that may have a medication coating e.g. heparin coated stints, or similar types of devices. These types of devices would be ordered using the Device Request or the SupplyRequest resources.

It is not intended for use in prescribing particular diets, or for ordering non-medication-related items (eyeglasses, supplies, etc.). In addition, the MedicationRequest may be used to report orders/request from external systems that have been reported for informational purposes and are not authoritative and are not expected to be acted upon (e.g. dispensed or administered).

The MedicationRequest resource is a "request" resource from a FHIR workflow perspective - see Workflow Request.

The MedicationRequest resource allows requesting only a single medication. If a workflow requires requesting multiple items simultaneously, this is done using multiple instances of this resource. These instances can be linked in different ways, depending on the needs of the workflow. For guidance, refer to the Request pattern.

Boundaries and Relationships

The MedicationRequest resource is used to request or order medication for a subject. It may also be used to report a medication request or order from one organization or source to another. When requesting supplies or devices when there is a patient focus or instructions regarding their use, SupplyRequest or DeviceRequest should be used instead. When reporting on the usage of a medication by a patient, the MedicationStatement resource should be used.

The Medication domain includes a number of related resources

MedicationRequestAn order for both supply of the medication and the instructions for administration of the medicine to a patient.
MedicationDispenseProvision of a supply of a medication with the intention that it is subsequently consumed by a patient (usually in response to a prescription or order or request).
MedicationAdministrationWhen a patient actually consumes a medicine, or it is otherwise administered to them.
MedicationStatementThis is a record of medication being taken by a patient, or that the medication has been given to a patient where the record is the result of a report from the patient, or another clinician. 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.

The MedicationRequest resource represents an authorization for both a dispense and an administration to be provided. Details about the fulfillment of the authorization are typically handled by the Task resource. For further information about this separation of responsibilities, refer to the link Fulfillment/Execution section of the Request pattern.

MedicationRequests can be instantiated from a protocol which is represented by a Definition resource - ActivityDefinition or PlanDefinition. For more information on protocols, see applying a PlanDefinition.

There are examples where a medication request may include the option of an oral dose or an Intravenous or Intramuscular dose. For example, "Ondansetron 8mg orally or IV twice a day as needed for nausea" or "Compazine® (prochlorperazine) 5-10mg PO or 25mg PR bid prn nausea or vomiting". In these cases, two MedicationRequest resources would be created that could be grouped together. The decision on which dose and route of administration to use is based on the patient's condition at the time the dose is needed. In general, each prescribed drug will be a separate Medication Request.

When drug orders are grouped together at the time of order entry, but each of the drugs can be manipulated independently e.g. changing the status of one order to 'completed' or 'cancelled', changing another order status to 'on-hold', the method to 'group' all of the medication requests together is to use MedicationRequest.groupIdentifier element. All of the orders grouped together in this manner will have the same groupIdentifier, and separately, each order in the group may have a unique identifier. There are cases that require grouping of Medication orders together when it is necessary to specify optionality e.g. order two drugs at one time, but stating either of these drugs may be used to treat the patient. The use of a RequestOrchestration should be used as a parent for the Medication orders that require this type of grouping. An example when it may be necessary to group medication orders together is when you specify timing relationships e.g. order drug 'xyz' with dose 123, then taper the same drug to a different dose after some interval of time precedence:

Notes

Dosage Instructions

Free text dosage instructions can be used for cases where the instructions are too complex to code. The content of this attribute does not include the name or description of the medication. When coded instructions are present, the free text instructions may still be present for display to humans taking or administering the medication. It is expected that the text instructions will always be populated. If the dosage.timing attribute is also populated, then the dosage.text should reflect the same information as the timing.

Grouping Medication Requests

In general, each prescribed drug will be a separate Medication Request.

When drug orders are grouped together at the time of order entry, but each of the drugs can be manipulated independently e.g. changing the status of one order to "completed" or "cancelled", changing another order status to "on-hold", the method to "group" all of the medication requests together is to use MedicationRequest.groupIdentifier element. All of the orders grouped together in this manner will have the same groupIdentifier, and separately, each order in the group may have a unique identifier.

There are cases that require grouping of Medication orders together when it is necessary to specify optionality e.g. order two drugs at one time, but stating either of these drugs may be used to treat the patient. The use of a RequestOrchestration should be used as a parent for the Medication orders that require this type of grouping. An example when it may be necessary to group medication orders together is when you specify:

Note that one should NOT use the List or Composition resource to accomplish the above requirements. You may use List or Composition for other business requirements, but not to address the specific requirements of grouping medication orders.

StructureDefinition

Elements (Simplified)

Mappings

Resource Packs

list-MedicationRequest-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../publish/List.xsd">
  <id value="MedicationRequest-packs"/>
  <status value="current"/>
  <mode value="working"/>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

medicationrequest-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements

medicationrequest-request-mapping-exceptions.xml

Divergent Elements

Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number. | resource=This is a business identifier, not a resource identifier.

A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds. | resource=This element is labeled as a modifier because the status contains codes that mark the resource as not currently valid.

Clinical decision support systems should take the status into account when determining which medications to include in their algorithms.

One exception to this is that the granularity of Request.intent is allowed to change. For example, a Request identified as an "order" might later be clarified to be a "filler-order". Or, in rarer cases (to meet recipient constraints), the reverse might also occur.

When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy. | resource=This element is expected to be immutable. E.g. A 'proposal' instance should never change to be a 'plan' instance or 'order' instance. Instead, a new instance 'basedOn' the prior instance should be created with the new 'intent' value. It is expected that the type of requester will be restricted for different stages of a MedicationRequest. For example, Proposals can be created by a patient, relatedPerson, Practitioner or Device. Plans can be created by Practitioners, Patients, RelatedPersons and Devices. Original orders can be created by a Practitioner only.

An instance-order is an instantiation of a request or order and may be used to populate Medication Administration Record.

This element is labeled as a modifier because the intent alters when and how the resource is actually applicable.

See additional guidance here. | resource=This might not include provenances for all versions of the request – only those deemed "relevant" or important. This SHALL NOT include the provenance associated with this current version of the resource. (If that provenance is deemed to be a "relevant" change, it will need to be added as part of a later update. Until then, it can be queried directly as the provenance that points to this version using _revinclude All Provenances should have some historical version of this Request as their subject.).

Unmapped Elements