| 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. |
| 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/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. |
| 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 |
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 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 1 - Used in limited production environments, 1 or 2 different systems |
| Maturity - Current Exchange | Level 1 - Demonstrates exchange between 2 or 3 organizations with different EHR/HIT systems |
| Breadth of Applicability - # Stakeholders Impacted | Level 1 - Used by many, but not most, patients, providers or events requiring its use |
Comment