OMOP Common Data Model

Fall 2026

Piyush Chaudhari | Qian Li

2026-09-11

OMOP Common Data Model

The Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) is an open community data standard, designed to standardize the structure and content of observational data and to enable efficient analyses that can produce reliable evidence

OMOP Common Data Model

The OMOP Common Data Model organizes data into clinical event tables (facts about a patient over time), a person/demographic table, and standardized vocabulary tables
Every clinical fact is represented using a standard concept, which is why most columns end in _concept_id and resolve through concept

person

One row per patient, this is the anchor table every other table joins back to via person_id

Column	Description
`person_id`	Unique patient identifier (primary key)
`gender_concept_id`	Standard concept for sex/gender
`year_of_birth`, `month_of_birth`, `day_of_birth`	Birth date components
`race_concept_id`, `ethnicity_concept_id`	Standard demographic concepts
`location_id`	FK to `location` (address/geography)
`provider_id`	FK to `provider` (usual care provider)
`care_site_id`	FK to `care_site` (usual site of care)

observation_period

Defines the span(s) of time during which a patient’s data is considered complete/observable. Critical for cohort eligibility and lookback/washout logic.

Column	Description
`observation_period_id`	Primary key
`person_id`	FK to `person`
`observation_period_start_date`	Start of observable window
`observation_period_end_date`	End of observable window
`period_type_concept_id`	How the period was derived (e.g., from EHR, insurance enrollment)

visit_occurrence

One row per patient encounter (inpatient stay, outpatient visit, ER visit, etc.). Most clinical event tables optionally link back to the visit during which they occurred.

Column	Description
`visit_occurrence_id`	Primary key
`person_id`	FK to `person`
`visit_concept_id`	Type of visit (inpatient, outpatient, ER, etc.)
`visit_start_date` / `visit_end_date`	Encounter start/end
`visit_type_concept_id`	Provenance of the visit record
`care_site_id`	FK to `care_site`
`admitted_from_concept_id`, `discharged_to_concept_id`	Admission/discharge disposition

condition_occurrence

Diagnoses - problems, complaints, and clinical impressions recorded for a patient.

Column	Description
`condition_occurrence_id`	Primary key
`person_id`	FK to `person`
`condition_concept_id`	Standard concept for the diagnosis (joins to `concept`)
`condition_start_date` / `condition_end_date`	Onset/resolution dates
`condition_type_concept_id`	Provenance (e.g., primary diagnosis, billing code)
`visit_occurrence_id`	FK to the visit during which it was recorded
`condition_status_concept_id`	e.g., admitting vs. final diagnosis

drug_exposure

Records of drug utilization - prescriptions, administrations, and dispensations.

Column	Description
`drug_exposure_id`	Primary key
`person_id`	FK to `person`
`drug_concept_id`	Standard concept for the drug (joins to `concept`, typically RxNorm)
`drug_exposure_start_date` / `drug_exposure_end_date`	Exposure window
`quantity`, `days_supply`, `refills`	Dosing/supply details
`route_concept_id`	Route of administration
`visit_occurrence_id`	FK to the visit during which it was prescribed/administered

measurement

Quantitative and qualitative clinical measurements - labs, vitals, and other structured test results.

Column	Description
`measurement_id`	Primary key
`person_id`	FK to `person`
`measurement_concept_id`	Standard concept for the test (joins to `concept`, typically LOINC)
`measurement_date` / `measurement_datetime`	When the measurement was taken
`value_as_number`	Numeric result (e.g., lab value)
`value_as_concept_id`	Coded result, when the value isn’t numeric
`unit_concept_id`	Unit of measure
`range_low`, `range_high`	Reference range for the test

procedure_occurrence

Records of procedures performed - surgeries, imaging, therapeutic interventions.

Column	Description
`procedure_occurrence_id`	Primary key
`person_id`	FK to `person`
`procedure_concept_id`	Standard concept for the procedure
`procedure_date`	When the procedure occurred
`visit_occurrence_id`	FK to the associated visit

observation

A catch-all clinical fact table for observations that don’t fit condition/drug/procedure/measurement - e.g., family history, social history, survey responses.

Column	Description
`observation_id`	Primary key
`person_id`	FK to `person`
`observation_concept_id`	Standard concept for what was observed
`observation_date`	Date of the observation
`value_as_number`, `value_as_string`, `value_as_concept_id`	Result, in whichever form applies

concept

The vocabulary backbone of OMOP (Standardized Vocabulary). Every *_concept_id column across every table is a foreign key into this table.

Column	Description
`concept_id`	Primary key - the number stored in every event table
`concept_name`	Human-readable name
`domain_id`	Which clinical area it belongs to (Condition, Drug, Measurement, etc.)
`vocabulary_id`	Source vocabulary (SNOMED, RxNorm, LOINC, ICD10CM, etc.)
`concept_class_id`	Finer-grained classification within the vocabulary
`standard_concept`	`'S'` if this is the standard concept to use for analysis
`concept_code`	The original code within its source vocabulary

Standard Concepts

OMOP maps heterogeneous source codes (ICD-10, local lab codes, etc.) onto a single standard vocabulary per domain, so analytic queries only need to filter on standard concept_id values
The concept_relationship and concept_ancestor tables support mapping between source and standard, and traversing concept hierarchies (e.g., “all descendants of Type 2 Diabetes”)

Connectivity of OMOP Tables

Every clinical event table has a person_id (who) and usually a visit_occurrence_id (during which visit), and every *_concept_id resolves through concept (what, in standardized concept term)