The OMOP Common Data Model (OMOP CDM) is an open, freely available data standard maintained by OHDSI (Observational Health Data Sciences and Informatics) for structuring observational health data — electronic health records, administrative claims, disease registries — into a single, consistent relational format. Once a source database has been mapped, or “ETL’d,” into the CDM, the same analytic code can run unchanged against any other CDM-conformant database, regardless of what EHR system, claims processor, or country it originated from. That portability is the entire point of the model: it lets a research question be answered as a distributed network study across dozens of institutions without any institution moving patient-level data off its own servers.
This is a mapping guide, not a vendor pitch: OMOP CDM is free and open-source, and OHDSI is a community, not a company. The procedure below is the same one any institution follows — academic medical center, health system, or CRO — when it takes on its first CDM conversion.
OMOP CDM vs. CDISC SDTM: Different Standard, Different Job
CASRAI’s Dictionary already covers SDTM (Study Data Tabulation Model), and the two are easy to conflate because both are relational data standards for clinical data. They are not interchangeable, and mapping to the wrong one wastes real effort:
| Dimension | OMOP CDM (OHDSI) | SDTM (CDISC) |
|---|---|---|
| What it structures | Observational, real-world data: EHR, claims, registries | Data collected within a single, protocol-driven clinical trial |
| Primary purpose | Multi-database network research, pharmacoepidemiology, real-world evidence | Regulatory submission of trial results (FDA, PMDA) |
| Governing body | OHDSI (open, community-governed) | CDISC |
| Vocabulary anchor | Standard concepts in the OMOP Vocabulary (Athena), sourced from SNOMED CT, RxNorm, LOINC and others | CDISC Controlled Terminology, domain-specific variable naming (DM, AE, VS, LB…) |
| Typical source | Existing, already-collected operational data (secondary use) | Case report form data collected prospectively for the trial |
A study built on already-collected EHR or claims data, run across multiple sites without moving raw patient data, is an OMOP CDM problem. A trial preparing a dataset for FDA submission is an SDTM problem. Some programs need both: a trial’s operational EHR data feeding site-level dashboards in OMOP, while the trial’s outcome data is separately structured in SDTM for submission.
The Core Clinical Tables
The CDM (current version 5.4, per the OHDSI CommonDataModel specification) organizes clinical facts into a fixed set of relational tables, each holding one class of clinical event. Every mapping project works domain-by-domain against this structure:
| OMOP CDM table | What it holds | Typical source data |
|---|---|---|
| PERSON | One row per patient: demographics, birth date, race/ethnicity concept | EHR patient master, enrollment file |
| VISIT_OCCURRENCE | Encounters — inpatient stays, outpatient visits, ED visits | Encounter/admission tables, claims header records |
| CONDITION_OCCURRENCE | Diagnoses recorded during a visit | ICD-9-CM/ICD-10-CM diagnosis codes |
| DRUG_EXPOSURE | Medications dispensed, administered, or prescribed | NDC codes, pharmacy dispensing records, eMAR data |
| PROCEDURE_OCCURRENCE | Procedures performed | CPT-4, HCPCS, ICD-10-PCS codes |
| MEASUREMENT | Lab results, vitals, and other quantitative findings | Lab result tables (LOINC-coded), vitals flowsheets |
| OBSERVATION | Clinical facts that don’t fit the other domains — family history, smoking status, patient-reported data | Structured EHR fields, registry questionnaire data |
| DEATH | Date and, where known, cause of death | EHR mortality flag, death registry linkage |
Deciding which table a given source field belongs in is a real judgment call, not a lookup — the same source field can map differently depending on how it was captured (see the crosswalk challenges below).
The Standardized Vocabulary: Why It’s Central, Not Optional
A CDM conversion is not finished when data lands in the right tables — every clinical fact also has to be recoded from the source system’s native codes (a hospital’s local lab codes, an insurer’s proprietary drug codes) to a standard concept in the OMOP Vocabulary. OHDSI distributes this vocabulary through Athena, which aggregates and cross-references source vocabularies including SNOMED CT (conditions/procedures), RxNorm (drugs), LOINC (labs/measurements), and CPT-4/HCPCS/ICD-10, among others, into a single concept hierarchy. Standard concepts are what make cross-database analysis possible: a query against MEASUREMENT for a specific LOINC-backed concept returns comparable results whether the underlying hospital used its own internal lab codes or a national lab vendor’s codes, because both were mapped to the same standard concept during ETL.
The ETL Procedure: Source Data to OMOP CDM
OHDSI publishes a standard toolchain for this work, and most conversions follow the same sequence:
- Profile the source data with White Rabbit. White Rabbit scans the source database and produces a scan report: every table, field, and the actual distinct values/frequencies present. This is the step that surfaces data-quality problems (inconsistent coding, sparse fields, undocumented local codes) before any mapping decisions are made.
- Map source vocabulary to standard concepts with Usagi. For fields carrying free-text or non-standard local codes, Usagi provides approximate string-matching against the OMOP Vocabulary to suggest candidate standard concepts, which a data analyst then reviews and confirms — this manual review step is unavoidable and is where most of the real ETL effort lives, since automated matching is a starting point, not a final answer.
- Design the table-level mapping with Rabbit-in-a-Hat. Working from the White Rabbit scan report, Rabbit-in-a-Hat is used to interactively document which source table/field maps to which CDM table/field, producing the ETL specification that a developer then implements as SQL, dbt models, or another transformation pipeline.
- Implement and run the transformation. The documented mapping is built out as actual ETL code against the source system, populating the CDM tables and the vocabulary-mapped concept fields together, so no clinical fact enters the CDM without also carrying its standard concept.
- Validate the result. OHDSI’s Data Quality Dashboard (DQD) runs a large, standardized battery of checks against the populated CDM instance — plausibility, conformance, and completeness checks — and ACHILLES generates descriptive statistics across the whole database, both used to catch mapping errors (implausible date ranges, orphaned foreign keys, concepts left unmapped) before the database is used for research.
Where the Judgment Calls Are
The tooling above documents and speeds up the work; it does not remove the need for domain expertise. The recurring difficult decisions in a real conversion:
- Domain assignment ambiguity. Some source fields don’t obviously belong to one CDM table — a structured “smoking status” field, for example, is commonly mapped to OBSERVATION rather than CONDITION_OCCURRENCE, because it represents a patient characteristic rather than a diagnosed condition, but different EHR configurations capture it differently.
- Non-standard and unmapped source codes. Local, homegrown codes with no clean match in Athena either need a custom concept (used sparingly and clearly documented, since it breaks cross-database comparability for that field) or must be mapped to a broader standard concept, trading precision for comparability.
- Granularity mismatches. A single source lab test can correspond to several LOINC codes depending on specimen type or method, and the reverse is also common — several source codes converging on one standard concept. Getting this wrong either fragments what should be one measurement or collapses clinically distinct results together.
- Provenance and traceability. A defensible ETL keeps the original source value and code alongside the mapped standard concept (the CDM’s *_SOURCE_VALUE and *_SOURCE_CONCEPT_ID fields exist for exactly this), so a later reviewer can trace any analytic result back to what was actually in the source system.
Frequently Asked Questions
What does OMOP stand for?
OMOP stands for Observational Medical Outcomes Partnership, the original public-private research initiative (2008–2013) that developed the common data model. The model and its supporting tools and vocabulary are now maintained and extended by OHDSI, the open community that grew out of that initiative.
Is OMOP CDM free to use?
Yes. The CDM specification, the OMOP Vocabulary (via Athena), and the OHDSI toolchain (White Rabbit, Usagi, Rabbit-in-a-Hat, ATLAS, the Data Quality Dashboard) are all open-source and free to use, developed and maintained by the OHDSI community rather than a commercial vendor.
How is OMOP CDM different from a data warehouse?
A conventional clinical data warehouse is typically modeled around a single institution’s own reporting needs, using whatever coding conventions that institution’s source systems produce. OMOP CDM is a fixed, published schema plus a mandated standard vocabulary — every conforming database, at any institution, uses the identical table structure and the identical concept identifiers for the same clinical fact, which is what makes multi-site network analysis possible without custom mapping for every pairwise comparison.
Do I need OHDSI’s specific tools to build an OMOP CDM ETL?
No — the CDM is a published open specification, so any ETL tooling can in principle populate it. White Rabbit, Usagi, and Rabbit-in-a-Hat are the tools OHDSI itself publishes and documents for this purpose, and most published conversions use them (or ETL frameworks built on the same underlying logic), largely because they’re purpose-built for the vocabulary-mapping step that’s otherwise the hardest part to get right.
Last verified 2026-08-16 against the OHDSI CommonDataModel specification (ohdsi.github.io/CommonDataModel) and ohdsi.org. CDM version and tool names confirmed directly against these primary sources; verify against the current specification before relying on version-specific details, since OHDSI revises the model on a regular release cycle.
Related CASRAI Resources
- Study Data Tabulation Model (SDTM) — the CDISC standard for regulatory trial-submission data, contrasted above
- Good Clinical Data Management Practices (GCDMP)
- Clinical Data Registry
- Federated Data Infrastructure — the broader pattern of analyzing data across institutions without centralizing it, which OMOP CDM’s network-study model relies on
- HIPAA in Clinical Research
- Clinical Research Administration hub
