What is the OMOP Common Data Model — and why researchers love it

A research team in Boston wants to know whether a decades-old generic drug eases symptoms in a poorly understood bladder condition. The records that could answer the question exist — in Nashville, Rotterdam, and Seoul, inside three different EHR systems, coded in three different ways, governed by three legal regimes.

The old way to run that study was months of bespoke work per site: new SQL, new code mappings, new arguments about what counts as a diagnosis. The OMOP way looks different. Each site has already reshaped its data into one common model. The team writes the analysis once, ships it as a package, and each site runs it locally overnight. No patient records move. Only aggregate results come back.

One shape for observational health data

The OMOP Common Data Model is a standard relational schema — plus a standard set of vocabularies — for observational patient data. Transform your source data into OMOP once, and any analysis written against OMOP runs on it without modification. That single property explains most of the enthusiasm.

The model is person-centric and longitudinal: one row per patient in a person table, with the events of their care — diagnoses, prescriptions, lab results, visits — recorded in standard event tables hanging off it. The shape is deliberately flat and query-friendly. Where an EHR is organized around the workflow of delivering care, OMOP is organized around the questions researchers actually ask: who, what, when, how often, compared with whom.

Born in drug safety, raised by a community

OMOP stands for Observational Medical Outcomes Partnership, a US public-private project launched in 2008 to answer a hard question for regulators including the FDA: could routine claims and EHR data reliably detect drug-safety signals? Testing methods across many databases required making those databases comparable first — and the common data model was born as a means to that end.

When the partnership wound down, the researchers refused to let the model die with the grant. Since 2014 it has been stewarded by OHDSI — Observational Health Data Sciences and Informatics, pronounced "Odyssey" — an open-science collaborative coordinated from Columbia University. By the community's own count, thousands of collaborators across dozens of countries now work on the model and its tools, and records for hundreds of millions of patients have been mapped into it. The model is now in its fifth major version, refined release by release in public.

Tables and vocabularies: the two halves

The tables are the visible half. A handful of them carry most of the weight:

The vocabularies are the harder half, and the real engine. Every code in the source data is mapped to a standard concept: conditions to SNOMED CT, drugs to RxNorm, measurements to LOINC — terminologies whose US distribution runs through the National Library of Medicine. The OHDSI community maintains the mapping tables and distributes them through its Athena service. The payoff is blunt and enormous: a German ICD-10-GM code and an American billing code for the same disease land on the same standard concept, so one query finds both. How those vocabularies carve up medicine — and why one disease can have five codes — is the subject of the vocabularies of medicine, decoded.

The network-study superpower

Because every participating site has the same tables and the same concepts, a study becomes code — and code travels better than data ever will. A researcher defines a cohort and an analysis once; each site executes it locally against its own OMOP instance; only aggregate results return to be pooled. The patient-level data never leaves the institution, the region, or the legal regime it lives in.

This is federated analytics in its most proven form, and OHDSI was running it at scale before the word was fashionable — network studies spanning millions of patients on multiple continents, including some of the largest comparative-effectiveness analyses ever conducted on routine care data. The same machinery makes cohort definitions themselves shareable, versionable scientific artifacts — the foundation of computable phenotypes.

What OMOP is not

OMOP is an analysis layer, not a system of record, and pretending otherwise causes real damage. The transformation is lossy by design: the model keeps what population queries need and sheds the rest — narrative nuance, operational detail, source-system context. ETL quality decides everything; a badly mapped source produces beautifully standardized garbage, which is why data quality in health research deserves its own discipline.

Just as fundamentally, the model carries no consent or permission semantics. Nothing in a condition_occurrence row says whether the patient agreed to this use, or whether they have since changed their mind. OMOP standardizes the shape of data, not the ethics of using it. Deciding what should sit underneath it as the source of truth is the subject of FHIR vs. OMOP.

Mithras Health uses OMOP the way the model deserves to be used: as a projection, not a foundation. FHIR R4 with US Core 6.1.0 profiles is the system of record; OMOP CDM views are generated from that validated truth for researchers to query. Consent is checked per study before any cohort is assembled, queries run federated and in-region and return aggregates only, and a hard k ≥ 5 floor plus an append-only audit trail sit in the release path — governance enforced around the model, because the model rightly does not try to enforce it.

The quiet achievement of OMOP is not technical at all. It is trust between strangers: a researcher in Boston can believe a number computed in Seoul because the table, the concept, and the code that produced it were identical to her own. Standards do not make discoveries. They make discoveries checkable — which, in observational research, is most of the battle.