The OMOP CDM model

What you already know

The previous articles in this section laid out the why of OMOP (the original project, its community, the idea of a shared format). This article opens the how: what the model actually looks like when you examine its structure.

To follow, you just need a few notions covered in the Understanding health data warehouses section:

• A relational database is a collection of tables linked together by keys — shared columns whose value identifies the same object from one table to the next (for example person_id, which appears in every event table to tie each row back to a unique patient in the PERSON table). That’s exactly the logic described in the article How health data is organized.
• Health data is structured in long format: one row per event, columns to qualify that event.
• Medical codes (ICD-10, SNOMED CT, LOINC…) are kept in a standardized form to enable comparability across databases.

OMOP CDM applies these principles rigorously: a precisely-specified relational schema, identical from one institution to the next. That schema is what we detail from here on.

A brief history of versions

The Common Data Model isn’t frozen: it evolves through versions published by OHDSI on GitHub. Knowing the history helps you understand the version you’re using — and the ones you should avoid.

The broad table categories

The CDM v5.4 organizes its ~40 tables into six broad categories. Not all are used in every database: most hospital warehouses focus on clinical data and the health system.

Three fundamental conventions

Before diving into the tables one by one, three principles run through the whole model. Understanding them will save you a lot of time in practice.

1. Person-centric model

Every record in every event table is tied to a patient identifier (person_id) and at least one date. This is what guarantees that any analysis can produce a longitudinal view of a patient’s health.

The domains are modeled in a person-centric relational data model, where for each record the identity of the person and a date is captured as a minimum.

— Book of OHDSI, section 4.1 Design Principles

2. Source / standard duality

This is probably the most important OMOP convention to understand. For every clinical event, the model keeps two parallel representations:

• The original source code as it exists in the hospital system (for example an ICD-10 code for a diagnosis).
• The standardized OMOP concept that the source code has been mapped to (for example the equivalent SNOMED CT concept).

Concretely, every event table follows the same column pattern:

- <event>_concept_id        : standard OMOP concept identifier
- <event>_source_value      : raw source code/label
- <event>_source_concept_id : OMOP concept matching the source code

Why this dual representation? Because it gives both international comparability (via the standard concept) and traceability (by keeping the original source code you can always verify the data at the source).

3. type_concept_id: where does this record come from?

Many tables include a <event>_type_concept_id column. Watch out for the trap: this is not a categorization of the event itself, but an indication of its provenance.

For example, for a drug in DRUG_EXPOSURE, the drug_type_concept_id tells you whether the data comes from a prescription, a dispensing or an administration — not the nature of the drug.

This is useful for quality: you may want to restrict an analysis to drugs actually dispensed or administered, not merely prescribed.

With those three conventions in mind, let’s now look at the main tables of the model. We group them into two families: first the ones describing the patient and their journey through the healthcare system, then the ones describing the clinical events observed along that journey.

The patient and their journey

PERSON — the patients table

Everything starts with PERSON. It’s the demographics table: one row per unique patient in the database.

Note the nuance between year_of_birth (mandatory) and month_of_birth/day_of_birth (optional). The model accepts a partially-known birth date — common in claims databases.

VISIT_OCCURRENCE — encounters with the health system

Every encounter between a patient and the healthcare system (hospitalization, outpatient visit, emergency…) generates a row in VISIT_OCCURRENCE.

VISIT_DETAIL — unit-level stays within a hospitalization

During a hospitalization, a patient often moves through several units: emergency on arrival, ICU, then a medical ward for the remainder of the stay. VISIT_DETAIL captures these intermediate steps, each row pointing to the parent stay’s visit_occurrence_id — so you keep the overall view while still being able to analyse each unit-level stay.

Clinical events

MEASUREMENT — quantifiable values

MEASUREMENT holds everything that’s measured with a value — number, interval, or coded categorical result.

OBSERVATION — clinical facts without a numeric value

OBSERVATION is where clinical events that don’t fit any other domain table land: smoking status, occupation, reason for visit, family history, qualitative score, environmental exposure… When a concept doesn’t belong to the Condition, Drug, Procedure or Measurement domains, this is where it ends up.

A frequent question: where does a given piece of data go — MEASUREMENT or OBSERVATION? The official rule is that the concept’s domain determines the table — a Measurement-domain concept goes to MEASUREMENT, an Observation-domain concept goes to OBSERVATION. ATHENA tells you the domain of each concept.

CONDITION_OCCURRENCE — diagnoses

Every diagnosis given for a patient becomes a row in CONDITION_OCCURRENCE. A single admission can generate multiple rows (a principal diagnosis plus multiple comorbidities).

PROCEDURE_OCCURRENCE — medical procedures

PROCEDURE_OCCURRENCE documents everything that is done to the patient, as opposed to what is observed about them (CONDITION_OCCURRENCE) or given to them (DRUG_EXPOSURE).

DEVICE_EXPOSURE — medical devices

DEVICE_EXPOSURE stores what is applied to the patient when it’s a physical object — as opposed to a drug (DRUG_EXPOSURE) or an action (PROCEDURE_OCCURRENCE). The boundary with PROCEDURE_OCCURRENCE can blur: implanting a stent is a procedure, but the stent itself is a device. Both tables often coexist for the same episode of care.

NOTE — free-text clinical documents

NOTE holds the unstructured data: everything the other tables don’t capture because it’s free-form writing. It’s the raw material for NLP, whose results land in a dedicated table NOTE_NLP.

DRUG_EXPOSURE — medications

DRUG_EXPOSURE covers all drug exposures: prescriptions, dispensings, in-hospital administrations. drug_type_concept_id distinguishes these provenances.

Computing the actual dose received

A quirk of OMOP: the dose taken by the patient is not stored directly in DRUG_EXPOSURE. The quantity column only gives the number of units dispensed (tablets, vials, millilitres…). To go from a number of units to an actual dose in milligrams, you have to join DRUG_EXPOSURE with the DRUG_STRENGTH table, which holds the active ingredient concentration for every standard drug product.

Going further

This article has covered the tables that matter most for clinical practice. The other tables (PROVIDER, CARE_SITE, LOCATION, COST, SPECIMEN, EPISODE, NOTE_NLP…) follow the same principles.

• Our interactive OMOP v5.4 schema explorer gives column-by-column detail for every table.
• Chapter 4 of the Book of OHDSI is the complete official documentation.
• Precise conventions (date formats, constraints, allowed values) are documented in Themis, OHDSI’s official ETL conventions repository.