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

Data Element
Medication Administration Patient
Description

The person who received the administered medication. While seemingly self-evident as a part of an administration record, the requirement of the patient being linked to the drug administered is critical (assuming Medication Administrations become part of USCDI
Submitted By: Scott Gordon / Food and Drug Administration
Data Element Information
Use Case Description(s)
Use Case Description Healthcare usecase: While seemingly self-evident, the lack of a required identification of the recipient of an administered drug 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/cliinical research context: Retrospective analyses of healthcare data are becoming a more common tool in clinical research for saftey 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 administration record and the recipient of the administration, 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/medicationadministration-definitions.html#MedicationAdministration.subject
Additional Specifications HL7 FHIR QI Core Implementation Guide STU4 based on FHIR R4, specifies MedicationAdministration, MedicationDispense profiles (http://hl7.org/fhir/us/qicore/StructureDefinition-qicore-medicationdispense.html ; http://hl7.org/fhir/us/qicore/StructureDefinition-qicore-medicationadministration.html )
HL7 FHIR QI Core Implementation Guide STU4 based on FHIR R4, MedicationAdministration, MedicationDispense, MedicationRequest, NotDone profiles, for negation rationale: http://hl7.org/fhir/us/qicore/profiles.html
Current Use This data element has been used at scale between multiple different production environments to support the majority of anticipated stakeholders
Supporting Artifacts Medication data is central for EHR systems used at healthcare sites and healthcare quality measures and payers track things such as completion of administrations etc. However the lack of *consistency* is the danger, and the lack of support in current FHIR implementations or US Core (for those providers that use in-house medication administration, is a glaring omission.
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 Medication data is central for EHR systems used at healthcare sites and healthcare quality measures and payers track things such as completion of administrations etc. However the lack of *consistency* is the danger, and the lack of support in current FHIR implementations or US Core (for those providers that use in-house medication administration, is a glaring omission.
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 While FHIR R4 fully supports this use, the fact that it is nor apparently implemented widely may make transition harder. Further, by not already being standardized, local proprietary data approaches to representing administration data may be widely divergent – another barrier to overcome for standardization.
Other Implementation Challenges none known
ONC 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 1 - Data element is captured, stored, or accessed in at least one production EHR or HIT module.
Criterion #3
Maturity - Current Exchange		 Level 1 - Data element is electronically exchanged between two production EHRs or other HIT modules using available interoperability standards.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 1 - Use cases apply to several care settings or specialties.

Comment

Log in or register to post comments