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

Data Element
Medication Prescription Do-Not-Perform
Description

Do-not-perform is an additional Boolean element in HL7 FHIR R4 Medication Request representing the provider’s intent that the prescription NOT be carried forward. If it is assumed that Status will be updated based on this command (ie, status will be changed to “cancelled” then this may be redundant. Alternative is an additional Status of “cancelled-by-provider”
Submitted By: Scott Gordon / Food and Drug Administration
Data Element Information
Use Case Description(s)
Use Case Description Healthcare usecase: The presense of a prescription record without the supplementary status risks providers within the healthcare system and/or in EHR networks will not be aware of prescriptions that was halted before dispensation and/or if the prescription was carried out to the next step. This ambiguity can result in misjugements on patient medication usage.

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. Researchers and regualtory reviewers will need to know enough information of the status of a prescription to determine if the drug at least reached the next phase (ie, dispensing) or if it was in fact halted before ever reching the patient. This information will supply critical differential information with which a researcher or regulatory reviewer can assess the relative probability of the listed drug record actually resulting in consumption by the patient. They can then determine the utility of the information in the context of the specific research and evidence generation needs of any given clinical study.
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.status
Additional Specifications Present in US Core Profiles
https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-medicationrequest.html
Each MedicationRequest must have:

a status
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 This shouldn’t be terribly difficult especially with FHIR. However, consistency in the actual Vocabulary being used to represent Status will be important for interoperability.
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 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 This data element represents a specialized use or a subset of the USCDI v4 data element Fill Status in the Medications data class.

Comment

Log in or register to post comments