| 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. |
| Estimated number of stakeholders capturing, accessing using or exchanging | 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 |
|
| 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/ |
| Number of organizations/individuals with which this data element has been electronically exchanged | 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 4 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 |
|
|---|---|
| Maturity – Standards/Technical Specifications | Level 1/2 - Must be represented by a vocabulary standard or an element of a published technical specification |
| Maturity - Current Use | Level 2 - Used at scale in more than 2 different production environments |
| Maturity - Current Exchange | Level 2 - Demonstrates exchange between 4 or more organizations with different EHR/HIT systems |
| Breadth of Applicability - # Stakeholders Impacted | Level 2 - Used by a majority of patients, providers or events requiring its use |
Comment