FHIR vs. OMOP: two data models, two jobs, one pipeline

A bank keeps a ledger, and a bank publishes a quarterly report. The ledger records every transaction exactly as it happened, attributable and timestamped. The report aggregates millions of those entries into a shape built for analysis. Nobody asks which one is better, because the question is malformed — and yet health-data architecture discussions ask its equivalent constantly: FHIR or OMOP?

Same money, two shapes. Same patient, two shapes. The interesting question was never which model wins. It is which job each model holds, and what order the pipeline runs in.

Two models, two questions

FHIR is built to answer: what happened to this patient, exactly as recorded, by whom, and when. OMOP is built to answer: what happens to patients like this one, measured across thousands or millions at a time. The first question is record-keeping and exchange; the second is research. Every design choice in each model follows from its question.

That is the whole comparison in two sentences. The rest is detail — but the detail is where projects go wrong, so it is worth walking through. Teams that pick one model and force it to do both jobs end up with either a research warehouse that cannot prove where its numbers came from, or an exchange layer that buckles under analytic queries it was never shaped for.

What FHIR is built for

FHIR is HL7's standard for exchanging health data as granular resources over web APIs — the origin story and design are covered in What is FHIR?. The property that matters here is transactional fidelity. Resources mirror clinical acts one by one: this Observation, recorded by this clinician, in this encounter, referencing this patient. Provenance is first-class, references knit records together, and the API serves live data the moment it is written.

Regulation reinforced the role: US patient-access rules pinned certified APIs to FHIR R4, which made it the natural grammar for the system of record — the place where a patient's data arrives, is validated, and is kept with its history intact.

That fidelity is also FHIR's weakness as a research substrate. Codes arrive however the source system coded them. The structure is nested and reference-linked, which is faithful for one record and punishing for a query across a million patients. FHIR keeps every tree in the forest labeled; it was never designed to count the forest.

What OMOP is built for

The OMOP Common Data Model, stewarded by the OHDSI community, makes the opposite trade. Data is reshaped into flat, person-centric tables, and every source code is mapped to a standard concept — SNOMED CT for conditions, RxNorm for drugs, LOINC for labs. The payoff is uniformity: one cohort definition, one analysis script, running unchanged across any site that holds OMOP-shaped data.

The cost is loss, accepted on purpose. Normalization sheds narrative nuance and operational detail; the model is refreshed in batches, not written in real time; and it was never meant to serve a single patient's record back with legal fidelity. OMOP counts the forest superbly. It no longer knows each tree the way the source did.

Side by side

Not rivals: the ETL pattern

The standard architecture is a pipeline: keep records in FHIR, transform them into OMOP for analysis. This is well-trodden ground — the HL7 and OHDSI communities formally collaborate on FHIR-to-OMOP mapping, and the vocabulary machinery that makes it possible, maintained in the US through the National Library of Medicine, is shared infrastructure for both worlds. The translation is real engineering: source codes to standard concepts (the subject of the vocabularies of medicine, decoded), encounters to visits, units reconciled, dates resolved.

A concrete example makes the loss visible. A FHIR MedicationRequest knows the prescriber, the encounter, the dosage instructions as written, the pharmacy notes. The OMOP drug_exposure row that results keeps the standard drug concept, the dates, the quantity — and deliberately drops the rest, because a comparative study across forty sites cannot use free-text dosage prose. Some loss is not a bug; analysis requires the uniformity that loss buys.

Direction, however, is not negotiable. If the OMOP copy becomes primary — if it is edited, enriched, or trusted independently of its source — three things break quietly. You can no longer answer "show me the record this number came from." Provenance evaporates, because OMOP does not carry it. And when you find an ETL bug, you cannot re-derive a clean copy, because there is no longer a clean upstream to derive from.

The durable pattern treats OMOP as a projection: disposable, regenerable, improvable. Fix the mapping, re-project, and every downstream view is corrected at once. The ledger stays authoritative; the report is reprinted.

Where consent and privacy live

Neither model carries permission semantics — no field in a FHIR Observation or an OMOP row says whether the patient agreed to this particular use, or has since withdrawn. Governance therefore has to wrap the pipeline, not live inside either format.

This is precisely how Mithras Health assembles the machine. FHIR R4 with US Core 6.1.0 profiles is the system of record, validated on ingest; OMOP CDM views are projected from it for research. Per-study, revocable consent is checked before any cohort is assembled, queries run federated and return aggregates only, a hard k ≥ 5 floor gates every release, and the whole sequence lands on an append-only audit trail. One pipeline, with truth at one end and governance at every joint — so a patient's "no" propagates through the same machinery as their "yes."

Keep the ledger honest and you can print a thousand reports, each one checkable against it. Print reports without a ledger and you have numbers no one can verify — which, in health research, is another way of saying numbers no one should trust.