FHIR to OMOP FHIR IG
2.0.0-ballot - STU 1 Ballot
FHIR to OMOP FHIR IG
2.0.0-ballot - STU 1 Ballot
FHIR to OMOP FHIR IG, published by HL7 International / Biomedical Research and Regulation. This guide is not an authorized publication; it is the continuous build for version 2.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-omop-ig/ and changes regularly. See the Directory of published versions
| Page standards status: Trial-use |
The canonical use case employed is querying a FHIR-enabled data repository to retrieve records and load them into an OMOP data store. This guide defines a set of logical models that represent the OMOP Common Data Model, v5.4. It also provides mappings, defined as FHIR StructureMaps and ConceptMaps (hosted on a FHIR terminology server), between the International Patient Access FHIR and US Core Encounter and Procedure profiles and the OMOP data tables.
An implementation of this guide declares which of the use cases described on this page it supports, so that the scope of any given FHIR-to-OMOP transformation is stated explicitly rather than inferred. See the conformance requirement referenced in the Conformance artifacts.
The NIH's All of Us Research Program is a historic initiative aiming to collect and analyze data from one million or more individuals residing in the United States. Currently, the Program has enrolled over 849,000 participants. The primary goal of the initiative is to promote better health outcomes by empowering thousands of researchers with diverse, longitudinal data gathered from participants, 80% of whom are traditionally underrepresented in biomedical research.
The Program collects various data types from consented participants, including:
Additional data currently being linked to participant records include:
All collected data are maintained and curated by the All of Us Data and Research Center (DRC) and are accessible to researchers through the All of Us Researcher Workbench. The primary data standard and clinical data model utilized by the All of Us Research Program is OMOP.
The All of Us Program collaborates with approximately 50 Health Provider Organizations (HPOs) across the United States to recruit participants. The All of Us Research Program leverages OMOP to standardize and structure its collected data, ensuring feasibility and facilitating researchers' ability to access and integrate data from diverse sources. These HPO partners extract participant EHR data, convert it into OMOP format, and submit 22 OMOP tables to the DRC on a quarterly basis. Given that EHR data represent the greatest demand for FHIR to OMOP mapping among the various All of Us data types, the All of Us program exemplifies real-world use cases for the utilization of EHR-sourced FHIR data transformed onto the OMOP CDM to generate evidence.
Studies were selected as examples based on the following criteria:
These selected studies offer practical, real-world examples of codes, data elements, and concept IDs. It is important to note that the examples might also incorporate additional codes and OMOP concept IDs as required.
Renedo, D., Acosta, J. N., Sujijantarat, N., Antonios, J. P., et al. (2022). Carotid Artery Disease Among Broadly Defined Underrepresented Groups: The All of Us Research Program. Stroke, 53. https://doi.org/10.1161/STROKEAHA.121.037554
Khan, M. S., Carroll, R. J. (2022). Inference-based correction of multi-site height and weight measurement data in the All of Us Research Program. Journal of the American Medical Informatics Association, 29(4), 626–630. https://doi.org/10.1093/jamia/ocab251 Additional OMOP concept IDs are included in the article text.
Berman, L., Ostchega, Y., Giannini, J., Anandan, L. P., et al. (2024). Application of a Data Quality Framework to Ductal Carcinoma In Situ Using Electronic Health Record Data From the All of Us Research Program. JCO Clinical Cancer Informatics. https://doi.org/10.1200/CCI.24.00052
The Vulcan Retrieval of Real World Data (RWD) for Clinical Research Implementation Guide (IG) aims to facilitate the transmission of clinical data generated during routine patient care (Electronic Health Record data, EHR) for use as Real World Data (RWD) supporting clinical research. Traditionally, clinical trials rely on prospective data collection tailored to specific research questions and analytics. In contrast, data generated through routine healthcare operations are rarely aligned with secondary research requirements. The Vulcan RWD IG defines FHIR profiles suitable for use within EHR systems, facilitating the retrieval and alignment of relevant clinical data from RWD sources for clinical research and regulatory submissions.
The Vulcan Real-World Data IG leverages the FHIR International Patient Access (IPA) IG to provide a foundational dataset and profiles necessary to address RWD use case requirements.
During the development of the Vulcan RWD IG, the following real-world clinical research studies from ClinicalTrials.gov were used as representative use cases to identify and scope the data elements most commonly required for clinical research. These studies are referenced here as illustrative background context; they informed the scoping decisions of the Vulcan RWD IG and, by extension, the prioritization of FHIR data elements relevant to this FHIR to OMOP IG. They are not presented as studies that were operationally conducted using the Vulcan RWD IG.
These studies specify the data elements required to identify, request, and retrieve relevant EHR data aligned with each study's cohort definition and research parameters. Most data elements are derived from the IPA profiles, providing a standardized minimal dataset. The Vulcan RWD IG further supports flexibility to accommodate local, regional, or study-specific needs through extensions, as illustrated in the RWD Conceptual Application Model pictured below:
Note: This document describes a target use case and conceptual framework. The AI classification capability outlined below represents the intended outcome of this work and is contingent on successfully implementing the FHIR-to-OMOP ETL transformation described herein. It has not yet been fully implemented.
The healthcare industry is increasingly leveraging Artificial Intelligence (AI) to extract actionable insights from clinical data. The OMOP Common Data Model is widely used for AI model training due to its robust, standardized structure designed to support large-scale data analysis, including clinical outcomes, drug safety, and efficacy research. However, FHIR (Fast Healthcare Interoperability Resources) is a newer, more flexible standard for health information exchange and is widely adopted for its ability to support real-time clinical workflows, such as through electronic health records (EHRs).
While OMOP provides a reliable foundation for building AI models, FHIR's versatility and growing adoption make it a popular choice for applying AI, which presents challenges when it comes to directly applying OMOP-trained AI models to FHIR data. The key issue is that AI models typically require data in a highly structured format (such as OMOP), but FHIR resources are more granular and often transmitted in a fragmented or single-message form. This misalignment makes it difficult to directly use FHIR for training AI models, which is why a transformation from FHIR to OMOP is necessary.
The goal of this work is to bridge this gap through the use of Extract, Transform, Load (ETL) processes to convert FHIR data into OMOP format. By transforming FHIR resources, whether from a single message (such as a single patient encounter or medication prescription) or aggregated messages, into the standardized OMOP format, healthcare organizations would be positioned to train AI models on OMOP data while leveraging real-time clinical data in FHIR for classification tasks.
Once implemented, this transformation would enable AI models trained on the OMOP CDM to be applied to clinical data captured in FHIR, ensuring that AI predictions are made based on consistent, normalized data. This would make it possible for even single-message FHIR resources (like a patient's admission record or a medication order) to be compatible with pre-existing, trained models, which are often designed to analyze more comprehensive patient data typically found in OMOP.
The following is an illustrative example of the type of AI application this work is intended to support. This use case has not yet been implemented; it represents the envisioned end state once the FHIR-to-OMOP transformation is in place.
A healthcare provider could use an AI model to predict medication adherence for patients. The AI model would be trained on historical clinical data stored in the OMOP format, which contains detailed, structured information about patient visits, medications, diagnoses, and more. The healthcare provider would collect patient data in real-time via FHIR resources, such as prescriptions and medication refills, stored in their EHR system.
Through the ETL process, the FHIR resources (prescription orders, medication administration records, etc.) would be transformed into the OMOP CDM format, ensuring compatibility with the trained model. Once transformed, the model would be applied to real-time data to predict whether a patient is likely to adhere to their prescribed medication regimen. The output of the model would then be classified based on this prediction and used to guide healthcare interventions.
What the transformation has to do when it runs for one patient at the point of care is described in Single-Patient FHIR to OMOP Transformation for Clinical Decision Support below.
The following benefits are expected to be realized upon successful implementation of the FHIR-to-OMOP transformation:
The FHIR-to-OMOP transformation is the foundational objective of this work. Achieving this transformation is what would enable healthcare organizations to apply real-time FHIR-based clinical data to pre-trained AI models that rely on the OMOP CDM. Through ETL processes, even fragmented or single-message FHIR resources would be made compatible with AI models trained on more comprehensive datasets, fostering more effective AI-driven healthcare decisions and interventions. This capability remains a target state; progress toward implementation is ongoing.
Organizations that train predictive models on OMOP data need the same OMOP representation at the point of care to run those models. The training data comes from a warehouse, loaded in bulk. The patient in front of the clinician arrives as FHIR resources from the EHR, one person at a time. This use case covers the transformation between the two: FHIR resources for a single patient, converted to OMOP on request, in time for a decision support application to act on the result.
An implementer raised the use case during the Informative ballot of this guide. It extends the classification half of the AI Training and Classification use case above. That section treats the model and its deployment as downstream of this guide. This section describes what the transformation has to do when the downstream consumer is a model running inside a clinical workflow.
A clinical event triggers the request: an admission, a medication order, a chart opening. The decision support application retrieves the patient's FHIR resources from the EHR's FHIR API. A transformation engine converts them to OMOP rows for that patient alone: one PERSON record plus the visits, conditions, drug exposures, measurements and observations the model reads. The model computes its features from those rows and returns a prediction to the workflow. The OMOP rows may be discarded once the prediction is returned.
Bulk conversion is outside this use case. An initial warehouse load from an EHR vendor's reporting database continues to use extract tooling built for that volume.
The logical models, StructureMaps, ConceptMaps and code mapping patterns in this guide operate on individual FHIR resources. They apply to one patient's resources in the same way they apply to a repository extract.
A model's validity depends on that sameness. A model trained on OMOP data expects point-of-care data to follow the conventions of its training data: the same domain assignments, the same standard concepts, the same handling of status elements and unmapped codes. Many training warehouses were loaded by a different pipeline than the one that will serve the model. The two pipelines can disagree about the same patient, and when they do the model receives inputs unlike its training data with no error raised. Comparing the output of both pipelines for a sample of patients before deployment exposes these disagreements.
| Repository to OMOP data store (canonical) | Single patient for decision support | |
|---|---|---|
| Unit of work | A population extract or an incremental batch | One patient's resources per request |
| Trigger | A schedule | A clinical event |
| Time available | Set by the load window | Set by the clinical workflow |
| Terminology mapping | Lookups can be slow; unmapped codes can be reviewed and remediated after the load | Lookups complete within the request; no reviewer is available |
| Keys | Assigned and tracked across loads | Needed only within one patient's rows, unless results are stored |
| Derived tables (eras, observation periods) | Computed over the full history after the load | Computed per request if the model reads them, from the history the FHIR API returned |
| Target | A persistent OMOP database | Possibly a transient representation held in memory |
This version of the guide defines no conformance requirements specific to this use case. Four questions need answers from implementers with point-of-care deployments before it can.
An implementation that supports this use case declares it under the Guidance below. The Biomedical Research and Regulation Work Group invites implementers with point-of-care deployments to bring their experience to the discussion forum.
An Implementer SHALL declare which use cases the transformation supports. The declared set MAY include any of the use cases described on this page, other use cases not described here, or a stated combination, so that the scope of a given FHIR-to-OMOP transformation is stated explicitly rather than inferred.§f2o-004
IG © 2023+ HL7 International / Biomedical Research and Regulation.
Package hl7.fhir.uv.omop#2.0.0-ballot based on FHIR 5.0.0.
Generated
2026-11-06
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change