OMOP vs FHIR for clinical analytics: when to use each and how to bridge both
FHIR and the OMOP Common Data Model solve different problems. FHIR moves records between systems through APIs. OMOP restructures records into one analytic model with standard vocabularies, so the same query runs at every site. Most research platforms need both, joined by a mapping pipeline.
When should clinical analytics use OMOP instead of FHIR?
Quick answer
OMOP vs FHIR for clinical analytics depends on the question. FHIR with Bulk export to a warehouse is enough for operational dashboards inside one organization. The OMOP Common Data Model earns its mapping cost for multi-site research and reusable cohort definitions. Agnotic Technologies builds the FHIR to OMOP pipelines that join the two.
| Criterion | OMOP CDM | FHIR |
|---|---|---|
| Built for | Analysis across sources, with one schema and standard concepts | Exchange of records between systems through APIs |
| Data shape | Relational tables such as PERSON, VISIT_OCCURRENCE, CONDITION_OCCURRENCE, DRUG_EXPOSURE and MEASUREMENT | Nested JSON resources such as Patient, Encounter, Condition, MedicationRequest and Observation |
| Codes | Mapped to standard concepts; the original code stays in source_value fields | Kept as recorded, often with several coding systems on one element |
| Operational dashboards | Usually more model than the job needs | Fits: Bulk export or API feeds into a warehouse |
| Quality measures | Possible, but measure logic is rewritten for the model | Fits when the measures are written against FHIR resources |
| Multi-site research | Fits: one study package runs at every site | Local codes and profiles differ per site, so queries need rework |
| AI training sets | Fits when training data come from many sources | Fits for one source with stable coding |
| Refresh pattern | Batch ETL, as full rebuilds or incremental loads | Bulk export with _since for changed resources, or event feeds |
| Main engineering effort | Concept mapping and ETL conventions | Flattening nested resources for analysis |
What they are
What is OMOP CDM
The OMOP Common Data Model is the OHDSI community's analytic schema: person, visit, condition, drug, measurement and other tables, with clinical codes mapped to standard concepts in the OHDSI vocabularies. It is designed for analysis across many sources, not for exchanging records.
What is FHIR
HL7 FHIR is a standard for exchanging healthcare data as resources over REST APIs. For analytics, the FHIR Bulk Data Access guide exports whole populations as NDJSON files, which land in a warehouse with their original codes and structure intact.
Key differences
Is FHIR plus Bulk export enough for analytics?
For one organization's reporting, often yes. The FHIR Bulk Data Access guide defines Patient and Group level $export operations, requires servers to support NDJSON output, and offers a _since parameter that returns only resources changed after a given time. Land those files in a warehouse, flatten the resources you need and build dashboards on top. The limits appear when you combine sources whose codes and profiles differ.
What do the OMOP standardized vocabularies add?
The OHDSI documentation calls the standardized vocabularies a central component of the OMOP CDM: they organise and standardise medical terms so analyses and phenotypes mean the same thing at every site. Mapping local codes into them is the expensive part of an OMOP build, and it is also what makes a cohort definition portable between partners.
Is there a standard for mapping FHIR to OMOP?
Yes. HL7 has published the Vulcan FHIR to OMOP Implementation Guide, version 1.0.0, as an Informative guide based on FHIR R5. It sets out mapping principles and patterns, not a certified ETL, so you still make and document local decisions, especially for codes and visits.
How does de-identification change the OMOP copy?
Research copies are often de-identified. Under the HIPAA Safe Harbor method, all elements of dates except the year must be removed for dates directly related to an individual (45 CFR 164.514(b)(2)). Studies that need real intervals use expert determination or a limited data set instead, and any date shift must be applied identically to every date for a person.
Where does OMOP sit in a lakehouse?
As a curated layer, not the landing zone. Raw FHIR NDJSON and HL7 v2 feeds land first; a mapping job builds OMOP tables from them; analysts and OHDSI tools read OMOP. Keep the raw layer, so a mapping fix can be replayed without asking any source to resend.
When to use each
When to use OMOP Common Data Model
- Network or multi-site studies where the same analysis runs at every partner.
- Cohort and phenotype definitions you want to reuse across projects.
- Research teams that want to run OHDSI's open analytics tools on their data.
- AI training sets that combine sources with different local coding.
When to use HL7 FHIR
- Operational dashboards and reporting inside one organization.
- Quality measures already written against FHIR resources.
- Feeds that must stay current through the day, where a nightly OMOP rebuild is too late.
- Projects where source codes must stay exactly as recorded.
Where does FHIR to OMOP mapping lose data quality?
1. Local lab codes with no standard concept. The CDM conventions store an unmapped record with a concept ID of 0, and it drops out of every analysis that filters on standard concepts. Report unmapped records per source and map the most frequent codes first.
2. Unit conversion. The same lab test arrives in different units from different sites. Map units to standard unit concepts and convert values before comparing them, or flag the rows you cannot convert.
3. Visit derivation from encounters. FHIR Encounters do not line up one to one with OMOP visits, and the CDM conventions allow inpatient records within a day of each other to be strung into one visit. Write the rule down and apply it the same way at every site.
4. Condition versus problem list. A problem list entry, an encounter diagnosis and a billing diagnosis mean different things. Record the origin of each row in its type concept, or prevalence counts will mix them.
5. Dropped source values. Keep the original code and text in the source_value fields, so any mapping can be audited and corrected later.
6. Inconsistent date shifting. A de-identified copy that shifts each record separately scrambles the order of events. Shift per person, once.
Which sources does this comparison rely on?
- OHDSI, OMOP Common Data Model documentation (ohdsi.github.io)
- OHDSI, OMOP CDM v5.4 table and ETL conventions (ohdsi.github.io)
- HL7 Vulcan FHIR to OMOP Implementation Guide 1.0.0 (hl7.org)
- HL7 FHIR Bulk Data Access IG: export operation (hl7.org)
- 45 CFR 164.514: de-identification of protected health information (eCFR)