This page is part of the Vulcan FHIR to OMOP FHIR Implementation Guide (v1.0.0-ballot: INFORMATIVE 1 Ballot 1) based on FHIR (HL7® FHIR® Standard) v5.0.0. No current official version has been published yet. For a full list of available versions, see the Directory of published versions
Official URL: http://hl7.org/fhir/uv/omop/StructureMap/MedicationMap | Version: 1.0.0-ballot | |||
Standards status: Informative | Maturity Level: 1 | Computable Name: MedicationMap |
This mapping maps FHIR MedicationStatement instances to OMOP Drug Exposure Table objects. NOTE: It does not map FHIR MedicationRequest instances although there is a discussion of those instances in the notes.
Please note: this StructureMap page contains both MedicationRequest and MedicationStatement FHIR Resource source recommendations and considerations.
The FHIR MedicationRequest resource represents a prescription or order for medication, capturing the intent to prescribe rather than confirming actual medication administration or patient adherence. A challenge with MedicationRequest resources is appropriate reconciliation of administrative workflow data with clinical research requirements. When mapping MedicationRequest data to the OMOP Common Data Model's drug_exposure table, implementers should consider the inherent limitations of prescription data and apply appropriate transformation processes to prevent misinterpretation in downstream analyses. OMOP conventions acknowledge this difference and allow utilization of prescriptions as drug exposure records. Appropriate utilization of the drug_type_concept to differenetiate prescribed medication records from administered medications (covered under FHIR MedicationStatemnt Resource section below), medication histories, patient-reported exposures etc is required.
The FHIR to OMOP working group determined that the FHIR MedicationRequest Intent field should deliberately be excluded from OMOP mapping. This field captures medication order administrative workflow values such as "proposal," "plan," "order," and "instance-order," which serve care coordination and clinical decision-making but do not contribute meaningful clinical information. This decision aligns with OMOP's focus on clinically significant events rather than process-oriented workflow data, maintaining a streamlined structure that prioritizes patient outcomes and treatment analysis over administrative context. If an OMOP implementation is focused on analyses of administrative processes as a primary use case, this exclusion may be reconsidered at implementation, but for the purposes of this IG, this element has been deemed as out-of-scope.
To address the fundamental discrepancy between medication intent/reporting and actual exposure while maintaining research utility, implementers should evaluate the source data context and consistently utilize the OMOP .(see Type Concepts in the OMOP Common Data Model) This approach not only provides data source transparency, but supports informed decisions about data inclusion based on specific use case requirements. As a required field in the OMOP CDM, each drug_exposure entry must receive an appropriate classification that explicitly indicates data source characteristics. Options include differentiating between prescriptions written, prescriptions dispensed, medication history, and patient-reported exposure.
The AuthoredOn field in MedicationRequest indicates when the medication was prescribed or requested by the provider. This date represents the prescriptive event rather than the initiation of actual medication use. When mapping to OMOP's drug_exposure.start_date, implementers should exercise caution. The AuthoredOn date should only be mapped to drug_exposure.start_date when no other temporal information is available, such as administration dates or patient-reported start dates. This mapping carries the assumption that the prescription date approximates when medication exposure began, though this assumption may not hold in practice due to delays in filling prescriptions, patient adherence patterns, or other factors. Please also see: Condition Start Date vs. Recorded Date guidance for a similar discussion regarding managing date implementation.
The Requester field identifies the healthcare provider who issued the medication prescription. This field maps directly to the provider_id in OMOP's drug_exposure table, establishing a clear link between the prescribing provider and the medication record. It is important to note that this mapping specifically identifies the prescribing provider rather than the individual who may have administered the medication or confirmed patient adherence. This distinction is particularly relevant in healthcare settings where prescription, dispensing, and administration may involve different providers.
The dosageInstruction field within MedicationRequest provides valuable information for populating OMOP's SIG (signatura) or dose-related fields. This information captures the prescribed dosing regimen and administration instructions, which can be crucial for understanding the intended therapeutic approach even when actual adherence cannot be confirmed.
Among the Best Practices reccommended by this IG, clear documentation should accompany any transformation that includes MedicationRequest mappings, specifically addressing:
The FHIR MedicationStatement resource represents documented or observed medication intake, providing evidence that is closer to actual drug exposure than prescription data or medication histories alone. When implementing MedicationStatement to OMOP drug_exposure mappings, consider MedicationStatement data as closer to confirmed exposure than MedicationRequest, but apply appropriate caution for self-reported information. The mapping should preserve temporal information through effectiveDate, maintain medication coding through mapping to Standard OMOP concepts, document status information for research context, and utilize appropriate drug_type_concept_id values to reflect the data's provenance. This approach balances the enhanced exposure evidence that MedicationStatement provides while maintaining appropriate skepticism about data quality inherent in patient-reported medication information and ensuring proper categorization for downstream analysis.
While MedicationStatement represents stronger evidence of exposure compared to MedicationRequest, implementers should recognize that this data may vary in reliability. Patient-reported data can involve recall bias, and retrospective statements may not capture exact intake dates. The implementation guide recommends treating MedicationStatement data with attention to these limitations while acknowledging its superiority over purely prescriptive data.
The effectiveDate field in MedicationStatement represents the date or time period when the medication was reportedly taken or administered. This temporal information is crucial as it provides data closer to actual exposure than prescription dates alone. The effectiveDate should map to drug_exposure.start_date in OMOP, and when an end date is included in the effectiveDate period, it should map to drug_exposure.end_date. This field represents a date range that aligns with the observed or reported period of medication intake, providing researchers with temporal boundaries for exposure analysis.
The medication field captures the specific drug or medication name, typically coded using standard terminologies such as RxNorm or SNOMED. This field should map directly to drug_concept_id in OMOP when a recognized concept ID is available. In cases where a medication code is missing, free-text entries can be used as non-standard concepts. (See: Impact of OMOP Standard Concepts & Domains for more information about OMOP Non-Standrd concepts.) When a MedicationStatement references a separate Medication resource, the mapping should incorporate data from that referenced resource to capture complete medication details accurately.
Dosage instructions within MedicationStatement provide a SIG (signatura) or detailed information on the amount, frequency, and route of administration. These elements should map to dose_unit_concept_id, dose_value, and route_concept_id in OMOP. Any specific administration instructions can be preserved in the SIG field within drug_exposure. This mapping is particularly valuable for research studies requiring analysis of drug exposure quantity and frequency patterns.
Given that MedicationStatement may represent retrospective statements or patient-reported intake, implementers should document that medicationStatment status and effectiveDate elements may vary in reliability. Research teams should be encouraged to consider these limitations when designing studies, particularly when dealing with patient-reported data that may be subject to recall bias or incomplete documentation.
The drug_type_concept_id field in OMOP serves a critical role in differentiating the provenance and nature of drug exposure records. When mapping FHIR MedicationStatement resources to the drug_exposure table, implementers must carefully select the appropriate drug_type_concept_id to distinguish between prescribed medications, administered medications, medication histories, and patient-reported exposures. This classification enables downstream users to appropriately filter and interpret data based on their analytical needs. When mapping MedicationStatement resources, implementers should choose the drug_type_concept_id that best represents the provenance of the record. The OMOP type concepts provide standardized options for delineating between prescriptions written, prescriptions dispensed, medication history, and patient-reported exposure. For MedicationStatement resources, the type concept should typically reflect patient-reported exposure or medication history, depending on the source and context of the data. (see Type Concepts in the OMOP Common Data Model
The OMOP CDM focuses exclusively on events that occur to the patient, meaning actions that suggest the drug was actually administered. If a patient missed or refused a dose of medication, no record should be created in the CDM. This principle guides the selection of drug_type_concept_id values, ensuring that only meaningful exposure events are captured in the database. If an OMOP implementation is focused on analyses of administrative processes as a primary use case, this exclusion may be reconsidered at implementation, but for the purposes of this IG, this element has been deemed as out-of-scope.
When medication dosages change during a treatment period, the mapping should end the first record and create a new record with the updated quantity. This approach ensures that each drug_exposure record represents a consistent dosage regimen, providing accurate temporal and quantitative information for analysis. The drug_type_concept_id should remain consistent across these records unless the nature of the data source changes.
/// url = 'http://hl7.org/fhir/uv/omop/StructureMap/MedicationMap' /// name = 'MedicationMap' /// title = 'Mapping MedicationStatement resource to DrugExposure OMOP Domain' /// status = 'draft' uses "http://hl7.org/fhir/StructureDefinition/MedicationStatement" alias MedState as source uses "http://hl7.org/fhir/uv/omop/StructureDefinition/DrugExposure" alias DrugExpTable as target group MedExposure(source src : MedState, target tgt : DrugExpTable) { src.medication : CodeableReference as s -> tgt then { s.concept as scs -> tgt then { scs.coding as sc -> tgt then { sc.code as a -> tgt.drug_concept_id = a; }; }; }; // src.id as id -> tgt.drug_exposure_id = cast(id, "integer"); src.effective : dateTime as edt -> tgt.drug_exposure_start_datetime = edt, tgt.drug_exposure_start_date = cast(edt, 'date'); src.effective : Period as s -> tgt then { s.start as fps -> tgt.drug_exposure_start_datetime = fps, tgt.drug_exposure_start_date = cast(fps, 'date'); }; src.effective : Period as s -> tgt then { s.end as fpe -> tgt.drug_exposure_end_datetime = fpe, tgt.drug_exposure_end_date = cast(fps, 'date'); }; src.effective : Period as s -> tgt then { s.end as fpe -> tgt.verbatim_end_date = cast(fps, 'date'); }; src.category : CodeableConcept as s -> tgt then { s.coding as sc -> tgt then { sc.code as a -> tgt.drug_type_concept_id = a; }; }; src.reason : CodeableReference as s -> tgt then { s.concept as scs -> tgt then { scs.coding as sc -> tgt then { sc.code as a -> tgt.stop_reason = a; }; }; }; }