Two shapes, one reality¶
The models disagree, and the disagreement is principled rather than accidental. Each was built for a job, and each is excellent at that job. Understanding the disagreement is what lets you make good decisions at the seam.
The core difference¶
| FHIR | OMOP | |
|---|---|---|
| Built for | Exchange between systems | Analysis across populations |
| Fundamental unit | The resource | The event row |
| Organizing question | What do I need to send you about this person? | What happened to this population, and when? |
| Shape | A graph of documents | A ledger of dated facts |
| Terminology | Bound per field, often loosely | Standardized globally, the core of the model |
| Time | An attribute of each resource | The spine of the entire model |
| Optionality | Extensive by design | Constrained by convention |
| Extension | Formal extension mechanism | Discouraged; use existing tables |
| Typical scale of one interaction | One person | Millions of people |
| Success looks like | The receiving system understood it | The same query returns comparable results everywhere |
Why FHIR is a graph¶
FHIR was designed for the moment when one system needs to tell another system about a person. That moment has a natural shape: here is the person, here is what happened, here is who did it, here is where.
A graph is the right structure for that. It preserves relationships, allows partial retrieval, and lets the sender include exactly as much context as the receiver needs. If you only want vitals, you fetch Observations. If you want the full picture, you follow references outward.
The cost of that design is that a graph is awkward to compute over at population scale. Answering "how many people started metformin within ninety days of a type 2 diabetes diagnosis" against a FHIR server means traversing references for every person individually. That query is natural in SQL over a ledger and painful over a graph.
Why OMOP is a ledger¶
OMOP was designed for the moment when a researcher wants to know something about many people at once, and wants the answer to be comparable to the answer someone else got somewhere else.
A ledger is the right structure for that. Every clinical fact is a row with a person, a date, and a standardized concept. The metformin question above becomes a join between DRUG_EXPOSURE and CONDITION_OCCURRENCE on person_id with a date condition. It is the same query at every OHDSI site in the world, and it returns comparable populations because the concepts are shared.
The cost of that design is that a ledger is a poor way to hand data to a clinical application. It has flattened the relationships, discarded some source structure, and translated the codes. You would not build a patient portal on top of an OMOP instance.
What each model refuses to represent¶
This is the most useful way to see the difference.
FHIR refuses to say when it does not know. There is no resource for "this person was in our system from March 2019 through November 2024 and any gap in that window means the event did not happen". FHIR describes what is, not the boundary of what is knowable. That refusal is correct for exchange and fatal for research, which is why OBSERVATION_PERIOD has to be derived.
OMOP refuses to preserve narrative structure. A DiagnosticReport that groups five Observations with a radiologist's interpretation becomes five MEASUREMENT rows and possibly a NOTE. The grouping and the interpretive relationship are largely gone unless you deliberately encode them in FACT_RELATIONSHIP. That refusal is correct for analysis and lossy for anything that needs clinical context.
FHIR refuses to standardize meaning by default. Base FHIR will let two servers code the same clinical idea completely differently and both are conformant. That is correct for a global exchange standard and unusable for pooled analysis.
OMOP refuses to keep things it cannot place. A source code with no standard concept gets a zero. The row exists but the meaning is gone from the analytical layer. That is correct for a model that promises comparability and it is why unmapped code tracking is a first-class quality concern.
The seam¶
Everything difficult in FHIR to OMOP work happens at four specific places where the two refusals collide.
Time boundary. FHIR has no observation period, OMOP requires one. You must invent it, and how you invent it changes the denominator of every future study.
Granularity. FHIR Encounters exist at whatever granularity the source system chose. OMOP wants a two-level structure with a coherent care episode on top. Bridging these is often the largest engineering task in a pipeline.
Meaning. FHIR permits any terminology. OMOP requires standard concepts from designated vocabularies. Every source code has to be run through a translation that may succeed, fail, or succeed misleadingly.
Placement. FHIR groups by resource type. OMOP groups by concept domain. These are different partitions of the same clinical universe and they do not line up.
Those four are the syllabus. Everything else is detail.
A useful mental exercise¶
Take one clinical event you know well and describe it twice.
Say a person had a hemoglobin A1c drawn at an office visit and the result was 7.8 percent.
As FHIR: an Observation resource with a LOINC code, a valueQuantity of 7.8 with UCUM unit %, a subject reference to the Patient, an encounter reference, an effectiveDateTime, a referenceRange, and a status of final. It knows who ordered it and where it was performed because it can point at those resources.
As OMOP: one row in MEASUREMENT with person_id, measurement_concept_id for the standard LOINC concept, measurement_date and measurement_datetime, value_as_number of 7.8, unit_concept_id for percent, range_low and range_high, measurement_type_concept_id recording that this came from a laboratory result, visit_occurrence_id linking to the visit, and measurement_source_value holding the original code string.
Same event. Both representations are complete for their purpose. The FHIR version can be handed to a clinical application. The OMOP version can be counted alongside forty million other A1c results from institutions that have never spoken to each other.
Now do the same exercise with something harder: a family history of breast cancer, a medication the person says they take but that was never prescribed in your system, or a diagnosis that was later refuted. Those are where the seams show, and where your judgment earns its keep.