Pharmacologic agents used in the diagnosis, cure, mitigation, treatment, or prevention of disease.

Data Element
Medication Prescription Patient
Description
The person who is the intended recipient of the medication. While seemingly self-evident as a part of an prescription record, the requirement of the patient being linked to the drug administered is critical
Submitted By: Scott Gordon / Food and Drug Administration
Data Element Information
Use Case Description(s)
Use Case Description Healthcare use case: While seemingly self-evident, the lack of a required identification of the recipient of a prescribed medication allows potential implementation that lack this obvious critical need. For interoperability purposes alone, a clear link between a drug and its recipient is essential.

An FDA/clinical research context: Retrospective analyses of healthcare data are becoming a more common tool in clinical research for safety or efficacy for new indications of existing medications. In such analyses there may be one or more “exposure” drugs (ie, the drug of interest) and one or many “concomitant” medications. If there is no clear link between an prescription record and the intended recipient, there is no way to clearly determine who took any drug.
Estimate the breadth of applicability of the use case(s) for this data element All Electronic Healthcare Record systems, healthcare systems, clinical research users of healthcare data, regulatory reviewers of healthcare data
Link to use case project page https://confluence.hl7.org/display/FHIR/2021-09+Vulcan+-+Real+World+Data+%28RWD%29+Submission+to+FDA
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Reducing the cost of care
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) In FHIR R4, https://www.hl7.org/fhir/medicationrequest-definitions.html#MedicationRequest.subject
Additional Specifications FHIR US Core
https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-medicationrequest.html
Each MedicationRequest must have:
a patient
Current Use This data element has been used at scale between multiple different production environments to support the majority of anticipated stakeholders
Supporting Artifacts HL7.FHIR.US.CORE\US Core MedicationRequest Profile - FHIR v4.0.1
https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-medicationrequest.html
Specifications - Epic on FHIR
https://fhir.epic.com/Specifications?api=996
MedicationRequest | R4 API (cerner.com)
https://fhir.cerner.com/millennium/r4/clinical/medications/medication-request/
Extent of exchange 5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders.
Supporting Artifacts HL7.FHIR.US.CORE\US Core MedicationRequest Profile - FHIR v4.0.1
https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-medicationrequest.html
Specifications - Epic on FHIR
https://fhir.epic.com/Specifications?api=996
MedicationRequest | R4 API (cerner.com)
https://fhir.cerner.com/millennium/r4/clinical/medications/medication-request/
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) none known
Restrictions on Use (e.g. licensing, user fees) none known
Privacy and Security Concerns none known
Estimate of Overall Burden Possible unique privacy and/or security concerns must be addressed here. These concerns may invoke existing privacy and security regulations or restrictions such as HIPAA or 42 CFR Part 2. If a new data class/element is not specifically covered by these, this would need to be stated clearly, not assumed to be not applicable.
Other Implementation Challenges none
ASTP Evaluation Details
Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
Criterion #1
Maturity - Current Standards		 Level 2 - Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2
Maturity - Current Use 		Level 2 - Data element is captured, stored, or accessed in multiple production EHRs or other HIT modules from more than one developer.
Criterion #3
Maturity - Current Exchange		 Level 2 - Data element is electronically exchanged between more than two production EHRs or other HIT modules of different developers using available interoperability standards.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 0 - Use cases apply to a limited number of care settings or specialties, or data element represents a specialization of other, more general data elements.
Evaluation Comment The "subject" or "target" of a data element is implied to be to the patient or person identified by other USCDI data elements.

Comment

Submitted by Larissa3430 on

This field is for general…

This field is for general comments on this specific data element. To submit new USCDI data classes and/or data elements, please use the USCDI ONDEC system: https://healthit.gov/ONDEC

Log in or register to post comments