Example Usage Scenarios:

The following are example usage scenarios for the US Core-MedicationRequest profile. See the Medication List section for guidance on accessing a patient's medications:

• Fetching all medications that have been prescribed to a patient
• Fetching all active medications that have been prescribed to a patient
• Fetching all medications that have been prescribed to a patient during a particular encounter
• Record or update medications that have been prescribed for a patient

Mandatory and Must Support Data Elements

The following data elements must always be present (Mandatory definition) or must be supported if the data is present in the sending system (Must Support definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The Formal Views below provides the formal summary, definitions, and terminology requirements.

Each MedicationRequest Must Have:

1. a status
2. an intent code
3. a medication*
4. a patient

Each MedicationRequest Must Support:

1. the category (e.g., Discharge Medication)
2. the reported flag or reference signaling that information is from a secondary source such as a patient
3. the encounters
4. a prescriber
5. a date for when written
6. free text dosage instructions (the SIG)
7. when medication should be administered
8. the route of administration
9. the dose and rate
10. the amount dispensed and number of refills

Additional USCDI Requirements:

These Additional USCDI Requirements elements are not Mandatory or Must Support but are required for ONC Health IT certification testing and are included in the formal definition of the profile and the MedicationRequest examples.

1. the reason or indication for the prescription*
2. reported adherence to prescribed medication instructions*

* see guidance below

Profile Specific Implementation Guidance:

• See the Medication List section for guidance on accessing a patient's medications, including over-the-counter (OTC) medications and other substances taken for medical and recreational use.
  • When recording "self-prescribed" medication, requester SHOULD be used to indicate the Patient or RelatedPerson as the prescriber.
• *This Profile can represent a medication using a code or reference a Medication resource.
  • When using a code, RXNorm concepts are used. They are defined as an extensible binding to .medicationCodeableConcept. USCDI recommends the National Drug Codes (NDC) as an optional terminology. They can be supplied as an additional coding element.
    • Systems that primarily rely on NDC codes instead of RxNorm to represent medications can use the National Library of Medicine's (NLM) NDC to RxNorm mappings to aid in translations.
  • When referencing a Medication resource in .medicationReference, the resource may be contained or an external resource.
  • The Server systems are not required to support both a code and a reference, but SHALL support at least one of these methods.
  • If an external reference to a Medication resource is used, the Server SHALL support the _include parameter for searching this element.
  • The Client application SHALL support all methods.

• The MedicationRequest resource can represent that information is from a secondary source using either a boolean flag or a reference using MedicationRequest.reportedReference.
  • Although both are marked as Must Support, the Server system is not required to support both, but SHALL support at least one of these elements.
  • The Client application SHALL support both elements.
• *The MedicationRequest resource can communicate the reason or indication for treatment using either a code in MedicationRequest.reasonCode or a reference using MedicationRequest.reasonReference.
  • Although both MedicationRequest.reasonCode and MedicationRequest.reasonReference are marked as Additional USCDI Requirements. The certifying Server system is not required to support both, but SHALL support at least one of these elements. The certifying Client application SHALL support both elements.
    • when using MedicationRequest.reasonReference:
      • Servers SHALL support at least one target resource in MedicationRequest.reasonReference. Clients SHALL support all target resources in MedicationRequest.reasonReference.
      • The referenced resources SHOULD be a US Core Profile as documented in Referencing US Core Profiles.
• Source EHR identifiers SHOULD be included to support deduplication across MedicationRequest resources. Exposing the EHR identifiers helps Client applications identify duplicates.

• Servers SHALL follow the guidance on the Medication List page and return all active medications as MedicationRequest. It is always best practice to confirm this list with the Patient or Caregiver.

• * This profile uses the US Core Medication Adherence Extension to report medication adherence. This extension communicates whether a medication has been consumed according to instructions.

Changes since version 7.0.0:

Quick Start

Below is an overview of the required Server RESTful FHIR interactions for this profile - for example, search and read operations - when supporting the US Core interactions to access this profile's information (Profile Support + Interaction Support). Note that systems that support only US Core Profiles (Profile Only Support) are not required to support these interactions. See the US Core Server CapabilityStatement for a complete list of supported RESTful interactions for this IG.

• See the Scopes Format section for a description of the SMART scopes syntax.
• See the Search Syntax section for a description of the US Core search syntax.
• See the General Requirements section for additional rules and expectations when a Server requires status parameters.
• See the General Guidance section for additional guidance on searching for multiple patients.

US Core Scopes

Servers providing access to prescription data SHALL support these US Core SMART Scopes:

• resource level scopes: <patient|user|system>/MedicationRequest.rs

Mandatory Search Parameters:

1. SHALL support searching using the combination of the patient and intent search parameters:
   • including optional support for these _include parameters: MedicationRequest:medication
   • including support for OR search on intent (e.g.intent={system|}[code],{system|}[code],...)

   GET [base]/MedicationRequest?patient={Type/}[id]&intent=order,plan

   Example:

   1. GET [base]/MedicationRequest?patient=14676&intent=order,plan
   2. GET [base]/MedicationRequest?patient=14676&intent=order,plan&_include=MedicationRequest:medication

   Implementation Notes: Fetches a bundle of all MedicationRequest resources for the specified patient and intent code = order,plan (how to search by reference and how to search by token)

2. SHALL support searching using the combination of the patient and intent and status search parameters:
   • including optional support for these _include parameters: MedicationRequest:medication
   • including support for OR search on intent (e.g.intent={system|}[code],{system|}[code],...)
   • including support for OR search on status (e.g.status={system|}[code],{system|}[code],...)

   GET [base]/MedicationRequest?patient={Type/}[id]&intent=order,plan&status={system|}[code]{,{system|}[code],...}

   Example:

   1. GET [base]/MedicationRequest?patient=1137192&intent=order,plan&status=active
   2. GET [base]/MedicationRequest?patient=1137192&intent=order,plan&status=active&_include=MedicationRequest:medication

   Implementation Notes: Fetches a bundle of all MedicationRequest resources for the specified patient and intent code = order,plan and status (how to search by reference and how to search by token)

Optional Search Parameters:

The following search parameter combinations SHOULD be supported:

1. SHOULD support searching using the combination of the patient and intent and encounter search parameters:
   • including optional support for these _include parameters: MedicationRequest:medication
   • including support for OR search on intent (e.g.intent={system|}[code],{system|}[code],...)

   GET [base]/MedicationRequest?patient={Type/}[id]&intent=order,plan&encounter={Type/}[id]

   Example:

   1. GET [base]/MedicationRequest?patient=1137192&intent=order,plan&status=active&encounter=Encounter/123
   2. GET [base]/MedicationRequest?patient=1137192&intent=order,plan&status=active&&encounter=Encounter/123&_include=MedicationRequest:medication

   Implementation Notes: Fetches a bundle of all MedicationRequest resources for the specified patient and intent code = order,plan and encounter (how to search by reference and how to search by token)

2. SHOULD support searching using the combination of the patient and intent and authoredon search parameters:
   • including optional support for these _include parameters: MedicationRequest:medication
   • including support for OR search on intent (e.g.intent={system|}[code],{system|}[code],...)
   • including support for these authoredon comparators: gt,lt,ge,le
   • including optional support for AND search on authoredon (e.g.authoredon=[date]&authoredon=[date]]&...)

   GET [base]/MedicationRequest?patient={Type/}[id]&intent=order,plan&authoredon={gt|lt|ge|le}[date]{&authoredon={gt|lt|ge|le}[date]&...}

   Example:

   1. GET [base]/MedicationRequest?patient=1137192&intent=order,plan&authoredon=ge2019-01-01T00:00:00Z
   2. GET [base]/MedicationRequest?patient=1137192&intent=order,plan&authoredon=ge2019-01-01T00:00:00Z&_include=MedicationRequest:medication

   Implementation Notes: Fetches a bundle of all MedicationRequest resources for the specified patient and intent code = order,plan and authoredon date (how to search by reference and how to search by token and how to search by date)