Medications

NCPDP Comment

For all of data elements under Medication data class in Level 2, NCPDP recommends a review and restructure because it currently creates confusion and potential duplication.

Medication Administration Date/Time and Route

Consider adding data elements for:

• Date/Time of Medication Administration
• Route of Medication Administration

This comment is submitted on behalf of the National Emergency Medical Services Information System (NEMSIS) Technical Assistance Center.

Level 2 data element to USCDI v3

Vizient recommends adding the below Level 2 data elements to USCDI v3 to the Medications class. In support of these additions, use cases are also provided for consideration:

o Medication Administration: This allows for further insight and analyses of which medications were administered within visits.
o Negation Rationale: This will allow for analyses as to what medication orders are being placed and then subsequently cancelled on a regular basis in addition to why they are being cancelled.
o Dosage: This information allows for sharing of detailed dose information to patients and other parties rather than simple medication name which can lead to additional insights on dosing patterns.
o Discharge Medications: This distinguishes which medications were prescribed for a patient to start/continue from the point of discharge and minimize confusion with medications prescribed as an inpatient.
o Medications Dispensed: The allows for differentiation of which ordered medications were actually dispensed (e.g., generic). This may be different from what was ordered or administered as it is the result of a pharmacy system responding to a medication order.

Lantana Consulting Group Comment

The details of prescribing, dispensing, and administering medications are essential to patient care, care coordination, and quality measurement. Adverse drug events and opioid use/misuse is difficult to properly evaluate without the specifics of when a medication was administered or prescribed.  

Relying on Medication Request as the only USCDI medication data element limits the representation of medication exposure in healthcare data in the U.S and provides a distorted and inaccurate picture of the medication workflows in the healthcare system. A medication request is the clinician’s prescription but is a separate event from dispensing and administering the medication. A different medication may be dispensed or administered. 

We support data elements for full range of medication events to support public health, regulatory, research, and pandemic response. Lantana recommends the following elements for inclusion in USCDI V3:

• Medication Administration

• Code
• Performer
• Reason Reference
• Date/DateTime

• Medication Prescribed
  • Code
  • Date
  • Reason Reference

• Medication Dispensed
• Discharge Medications (Medication Request)
• Dosage
• Dosage/Route
  • Administered Dose
  • Administered Dose Units
  • Prescribed Dose
  • Prescribed Dose Units
  • Negation Rationale

The current Medication data elements specify the actual medication but does not differentiate medication order, medication administrations, and medication dispensing activities. It also does not provide information about when the medication was ordered, dispensed, and administered to the patient.

The current MedicationRequest profile should emphasize that it represents requests or orders. The MedicationAdministration profile which would represent medications received at the hospital remains at USCDI Level 2 which impedes accurate medication data collection.

Data Class: Medications

IMO would like to note while many the proposed Level 2 data elements for the Medication data class are collected and exchanged by ONC certified HIT, not all the proposed Level 2 data elements meet ONC criteria for inclusion in USCDI V3.  We have categorized our review of the proposed data elements by these criteria.

Data Elements for Medications: Meet Level 2 Critiera

These data elements are incorporated in eCQMs reported in CMS quality programs, represented in implemented terminology specifications, and incorporated in requirements for ONC Certified HIT.

• Level 2 Data Element: Medication Administration
• Level 2 Data Element: Negation Rationale
• Level 2 Data Element: Dosage
• Level 2 Data Element: Discharge medications
• Level 2 Data Element: Date Medication Prescribed
• Level 2 Data Element: Medication Prescribed Code
• Level 2 Data Element: Medication Prescribed Dose
• Level 2 Data Element: Medication Prescribed Dose Units
• Level 2 Data Element: Date Medication Administered
• Level 2 Data Element: Medications Dispensed
• Level 2 Data Element: Medication Request
• Level 2 Data Element: Medication Statement

Data Elements for Medications: Do Not Meet Level 2 Critiera

The following technical specifications are cited in support of proposed Level 2 data elements. These technical specifications vary in maturity and do not yet have widespread implementation in ONC Certified Health IT.  Specifications include:

• FHIR US Core MedicationRequest Profile - FHIR v4.0.1
• FHIR US Core MedicationStatement Profile - FHIR v4.0.1
• HL7 CDA® R2 Implementation Guide: Public Health Case Report - the Electronic Initial Case Report (eICR) Release 1, STU Release 3.0
• Making EHR Data More Available for Research and Public Health (MedMorph) Reference Architecture

As the technical specifications that include these proposed data elements mature and are implemented in production environments these data elements could be reconsidered in future versions of USCDI.

• Level 2 Data Element: Therapeutic Medication Response
• Level 2 Data Element: Medication Prescription Do-Not-Perform
• Level 2 Data Element: Medication Prescription Status
• Level 2 Data Element: Medication Prescription Patient
• Level 2 Data Element: Medication Knowledge
• Level 2 Data Element: Medication Administration Status
• Level 2 Data Element: Medication Administered Performer
• Level 2 Data Element: Medication Prescribed Reason Reference
• Level 2 Data Element: Reported Medication (unique)

Prime Therapeutics Comments on USCDI V3

Prime Therapeutics LLC (Prime) helps people get the medicine they need to feel better and live well. Prime provides total drug management solutions for health plans, employers, and government programs including Medicare and Medicaid. We serve nearly 33 million people and are collectively owned by 19 Blue Cross and Blue Shield Plans, subsidiaries or affiliates of those plans. 

Prime Therapeutics requests ONC add National Drug Code (NDC) as an identifier for medications all.  RXNORM codes do not contain the specificity to identify specific drug manufacturer, all the active and inactive ingredients, etc.

CMS-CCSQ Continued Support of Medication data elements: USCDI v3

Management of medications is critical to patient care and coordination between providers, as well as related quality and public health enterprises. The current concept of medications in USCDI Draft version 3 does not differentiate those that are active, ordered, or actually administered to the patient, and do not provide necessary details for patient safety (i.e., dose and route). Medication details support an ONC criteria for public health reporting and investigation including using data to support safer use of opioids.

CMS-CCSQ recommend the following Medication data elements be added to Final USCDI v3:

1. Medications Administration/Medication Administered Code; defined as a code (or set of codes) that specifies the medication administered to a patient
2. Medications Dispensed; defined as a code (or set of codes) that specifies the medication dispensed
3. Discharge Medications; specifies the medication(s) active at discharge which should be taken by the patient upon release from a facility
4. Dosage (and route); defined as the dose and route instructions for medications

Maturity:

• Current standards:
  • In FHIR US Core, there is a distinction between Medication and MedicationRequest; base FHIR and FHIR QI Core IG includes MedicationAdministration and MedicationDispense profiles.
  • Within MedicationRequest, the ‘category’ is used to define discharge medications.
  • Dose and route instructions are also contextualized within the MedicationRequest, MedicationAdministration, and MedicationDispense profiles in US/QI Core IGs.
• Current uses, exchange, and use cases: Medication data is routinely captured in EHR systems used by hospitals, providers, and other healthcare stakeholders including pharmacies. Medication details are routinely exchanged across providers and payers. Medication data is used extensively in CMS quality measurement. Additionally, when prior authorization is necessary for a medication, details related to the medication (e.g., why the medication is given, the quantity needed) are exchanged to support the approval process.

CMS-CCSQ Support for Medication data elements for USCDI v3

CMS-CCSQ recommend the following Medication data elements be added to USCDI V3:

1. Data Element: Medication Administration; defined as a code (or set of codes) that specifies the medication administered to a patient.
2. Data Element: Discharge Medications; specifies the medication(s) active at discharge which should be taken by the patient upon release from a facility.
3. Data Element: Medications Dispensed; defined as a code (or set of codes) that specifies the medication dispensed
4. Data Element: Medication Dosage (and Route); defined as the dose and route instructions for medications
5. Data Element: Medication Negation Rationale; defined as the reason a medication was not ordered/administered

Rationale: CMS recommends adding more specificity to the USCDI Medications Data Class because interoperability of medication information and management of medications is critical to ensure patients receive appropriate and safe care. The current concept of medications in USCDI does not differentiate among medications that are active, ordered, and actually administered/dispensed to the patient. Given these complexities, more clarity and structure are necessary in this data class to accurately evaluate and provide clinical care. Additionally, the currently required data lack important clinical specificity (dosage and route instructions). Finally, the reason a medication was not given (negation rationale) provides important context for clinical care and patient engagement and improves patient-provider communication when this information travels with the patient across care settings. These additional medication details are critical to contextualize a medication and ensure patients and clinicians understand the mediations necessary for a patient, and how those should be taken, throughout the continuum of care. These detailed medication data are used extensively in quality measurement and are routinely exchanged when prior authorization is required.

Maturity:

• Current standards:
  • In FHIR US Core, there is a distinction between "Medication" and "Medication Request”; base FHIR and FHIR QI Core IG includes "Medication Administration" and “Medication Dispensed” profiles.
  • Within Medication Request, the ‘category’ is used to define discharge medications.
  • Dose and route instructions are also contextualized within the Medication Request, Medication Administration, and Medication Dispense profiles in US/QI Core IGs.
  • Negation details are expressed within the status reason (for not done) in Medication Request profile and Not Done profiles within QI Core.
• Current uses, exchange, and use cases: Medication data is routinely captured in EHR systems used by hospitals, providers, and other healthcare stakeholders including pharmacies. Medication details are routinely exchanged across providers and payers. Medication data is used extensively in CMS quality measurement. Additionally, when prior authorization is necessary for a medication, details related to the medication (e.g., why the medication is given, the quantity needed) are exchanged to support the approval process.

More clarity is needed sooner for the Medications Data Class

Currently, the Medications data class presents many interoperability challenges.  Work done within C-CDA shows there remains a great deal of confusion over how to represent medication information that is gathered from a patient's report of the medications they say they take versus actual medication administration reports documented by providers who are administering medications to the patient. Also challenging is the representation of medications that are prescribed by a provider. Prescribed medications may or may not actually be taken by the patient. 

The growing number of data elements in the Medications data class is a sign of the complexity of this data class.  A much larger effort is needed to straighten out the definitions and representations of the many nuanced aspects of this data class. The assessment and planning for this data class needs to be done sooner rather than later. It needs to be a top-down exercise, not a bottom-up exercise in order for all the many data element parts to actually make sense together.