The OMOP Common Data Model is a person-centric relational database schema maintained by the OHDSI collaborative that standardizes the structure and content of observational health data. It harmonizes disparate source data—including electronic health records, administrative claims, and disease registries—into a unified representation using standardized clinical terminologies such as SNOMED CT, LOINC, and RxNorm, enabling the execution of systematic, large-scale analytics without requiring researchers to learn site-specific data formats.
Glossary
OMOP Common Data Model

What is OMOP Common Data Model?
The OMOP Common Data Model (CDM) is an open community data standard that transforms heterogeneous clinical data into a consistent, standardized format of tables and vocabularies to enable systematic observational research across disparate health systems.
The model organizes data into clinically intuitive tables such as PERSON, DRUG_EXPOSURE, CONDITION_OCCURRENCE, and MEASUREMENT, each mapped to standardized vocabularies that resolve semantic inconsistencies between source systems. By converting raw clinical data into this common representation, the OMOP CDM enables the execution of distributed analytics and federated cohort discovery across a global network of data partners, allowing institutions to run identical analytical code on local data while producing comparable, reproducible real-world evidence.
Key Features of the OMOP CDM
The OMOP Common Data Model is not a physical database but a standardized schema design that enforces semantic interoperability. It separates clinical logic from source system specifics, enabling systematic analytics across disparate electronic health records.
Person-Centric Relational Schema
The model organizes data around the PERSON table, linking all clinical events—drug exposures, conditions, measurements—to a unique anonymized individual. This structure preserves longitudinal patient histories without storing direct identifiers, enabling cohort characterization and pathway analysis across time.
Standardized Vocabularies
Source codes (ICD-10, SNOMED, LOINC) are mapped to OMOP Standard Concepts via the CONCEPT table. This normalization eliminates semantic drift between institutions. The CONCEPT_RELATIONSHIP table further defines hierarchical and lateral links, enabling querying by clinical category rather than billing code.
CDM-Native Computation Engine
Analytics are executed directly against the CDM tables using standardized SQL or R routines. The ACHILLES tool profiles data quality, while ATLAS defines cohorts. This eliminates data extraction steps, preserving privacy by keeping patient-level data behind the institution's firewall.
Explicit Temporal Modeling
Every clinical record includes START_DATE and END_DATE fields, transforming static registries into dynamic timelines. This temporal precision is critical for federated survival analysis and calculating drug eras, allowing researchers to establish sequence and duration of exposures without manual chart review.
Source-to-Standard Audit Trail
The SOURCE_TO_CONCEPT_MAP table retains the raw vendor-specific code alongside the mapped standard concept. This transparency allows researchers to audit mapping quality, trace anomalies back to native terminologies, and maintain provenance when local coding customs differ from international standards.
Frequently Asked Questions
Clear, technical answers to the most common questions about the Observational Medical Outcomes Partnership Common Data Model, the open standard powering global observational research.
The OMOP Common Data Model (CDM) is an open community data standard that transforms heterogeneous clinical data—such as electronic health records, claims, and registries—into a consistent, standardized format of tables and vocabularies. It is necessary because raw clinical data from different institutions use incompatible structures and coding systems, making systematic, large-scale observational research impossible. By converting data to the OMOP CDM, the Observational Health Data Sciences and Informatics (OHDSI) community enables the execution of identical analytical code across disparate databases, generating reproducible real-world evidence without requiring researchers to learn each site's unique data schema.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Core concepts and standards that interoperate with the OMOP Common Data Model to enable large-scale, federated observational research.
Standardized Vocabularies
OMOP relies on a harmonized set of clinical terminologies to ensure semantic interoperability. Key vocabularies include:
- SNOMED CT: Standardized codes for diagnoses, procedures, and clinical findings.
- LOINC: Universal identifiers for laboratory tests and clinical measurements.
- RxNorm: Normalized names for clinical drugs and ingredients.
- ICD-10-CM/PCS: Classification systems for billing and inpatient procedures. The vocabulary mapping process transforms local source codes into these standard concepts, enabling cross-institutional querying.
Computable Phenotype
A machine-executable algorithm that identifies cohorts of patients with a specific condition from OMOP-structured data. Phenotypes combine logic across multiple domains—drug exposures, condition occurrences, measurements, and procedures—to define inclusion criteria. Tools like ATLAS allow researchers to design these definitions graphically, ensuring consistent cohort identification across disparate institutions without manual chart review.
ACHILLES
The Automated Characterization of Health Information for Longitudinal Evaluation Studies tool profiles OMOP databases to generate a comprehensive data quality assessment. It produces summary statistics on population demographics, data density, and vocabulary coverage. ACHILLES enables researchers to rapidly evaluate the fitness-for-use of a dataset before initiating a study, identifying gaps in data completeness or coding inconsistencies.
CDM Clinical Data Tables
The OMOP CDM organizes patient information into a relational schema of standardized clinical data tables. Core entities include:
- PERSON: Demographics and birth/death dates.
- CONDITION_OCCURRENCE: Diagnoses mapped to SNOMED concepts.
- DRUG_EXPOSURE: Medication orders and administrations.
- MEASUREMENT: Lab results and vital signs.
- VISIT_OCCURRENCE: Healthcare encounter records. Each table links to the CONCEPT table, which serves as the central vocabulary reference.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us