What Is the OMOP Common Data Model? Architecture, ETL, and Healthcare Use Cases

A health system may have the same patient represented across an EHR, laboratory system, pharmacy feed, claims database, research registry, and enterprise data platform.

Bringing those records into one environment does not automatically make them analytically consistent.

A diagnosis may arrive as ICD-10-CM. A medication may use NDC or a local formulary code. Laboratory tests may use LOINC, proprietary identifiers, different units, or locally defined names. Encounter structures can differ between EHRs and claims systems.

The OMOP Common Data Model (OMOP CDM) addresses this problem by standardizing both the structure of observational healthcare data and the clinical concepts used to represent it. The model allows researchers and analytics teams to apply common methods across datasets that originally used different schemas and coding systems.

That makes OMOP valuable for health systems, academic medical centers, clinical research organizations, life sciences companies, payers, and other organizations working with longitudinal healthcare data.

But an OMOP implementation is much more than creating a set of tables.

Its analytical value depends on understanding of source data, OMOP data mapping, standardized vocabularies, ETL design, provenance, observation-period logic, visit reconstruction, and rigorous data-quality validation.

What Is the OMOP Common Data Model?

The OMOP Common Data Model is an open community data standard maintained by Observational Health Data Sciences and Informatics. It organizes observational healthcare data into a standardized, person-centric model so common analytical methods can be applied across different data sources.

As of August 2026, OMOP CDM v5.4 is the current official CDM version identified by OHDSI. OHDSI provides the schema, conventions, standardized vocabularies, ETL guidance, and an ecosystem of analytical and data-quality tools around the model.

OMOP standardization happens at two important levels.

Structural Standardization

Structural standardization determines where information belongs.

Conditions, medications, procedures, measurements, observations, visits, providers, costs, specimens, notes, and other records are represented in defined CDM tables and fields.

Semantic Standardization

Semantic standardization determines what those records mean.

Source concepts are mapped, where possible, to Standard Concepts in the OMOP Standardized Vocabularies. OHDSI describes these vocabularies as an integral and mandatory component of an OMOP CDM instance.

This combination is what makes OMOP more than a normalized database schema.

Two organizations can store a diabetes diagnosis using different source codes, yet map those records to a common standardized clinical meaning for analysis.

Why Do Healthcare Organizations Use OMOP CDM?

Healthcare databases are usually built around the workflows they support.

An EHR supports care delivery. Claims systems support reimbursement. Laboratory systems manage orders and results. Registries capture specialized information. Research databases may create yet another representation.

OMOP is designed around a different goal: standardized analysis of observational healthcare data. OHDSI’s analytical framework centers on three major use cases: characterization, population-level estimation, and patient-level prediction.

Consider researchers studying outcomes for patients with type 2 diabetes across several health systems.

Without standardization, they may have to rewrite cohort logic for each source because diagnoses, drugs, visits, and laboratory results are represented differently.

With properly implemented OMOP databases, much of that source-specific transformation occurs during ETL. Researchers can define analytical logic against common tables and Standard Concepts rather than rebuilding the entire study for every native schema.

OMOP does not eliminate differences in populations or source-data capture. OHDSI specifically warns that standardizing databases does not remove their underlying clinical and population heterogeneity. It creates a common framework for understanding and analyzing those differences.

How Is the OMOP Common Data Model Architected?

OMOP CDM is a person-centric relational model. Clinical events are linked to an individual and typically contain dates or other temporal information that allow longitudinal analysis. The CDM itself is platform-independent and does not require a proprietary database technology.

Its architecture can be understood through several logical areas.

Person and Observation Period

The PERSON table is the central representation of an individual in OMOP. Clinical event tables reference the person through person_id.

When organizations integrate multiple source systems, they therefore need a reliable identity-reconciliation strategy, so records assigned to a PERSON correspond to the intended individual.

OMOP defines the target person-centric structure; it does not prescribe an enterprise master patient index or patient-matching algorithm.

The OBSERVATION_PERIOD table is just as important.

An observation period represents a span in which clinical events are expected to be captured with sufficient reliability that the absence of an event can potentially carry analytical meaning. OHDSI notes that payer enrollment often provides a natural basis for claims observation periods, while observation periods for EHR data generally need to be inferred using documented assumptions.

That matters when a cohort requires, for example, a year of prior observation.

A patient having no diagnosis in the database does not necessarily mean the patient did not have that condition. The care may have occurred outside the organization or outside the observable period.

Incorrect observation-period logic can therefore distort cohort eligibility, incidence, prevalence, baseline characteristics, and time-at-risk calculations.

Visits and Clinical Events

VISIT_OCCURRENCE represents interactions between a patient and the healthcare system.

VISIT_DETAIL can represent lower-level portions of a larger encounter, such as components of an inpatient stay.

Clinical data are then distributed across domain-specific tables.

OMOP table	Typical healthcare information
CONDITION_OCCURRENCE	Diagnoses, signs, symptoms
DRUG_EXPOSURE	Prescriptions, dispensings, administrations
PROCEDURE_OCCURRENCE	Procedures and interventions
DEVICE_EXPOSURE	Medical-device exposures
MEASUREMENT	Laboratory results, vital signs, structured measurements
OBSERVATION	Clinical facts not represented by another appropriate event domain
SPECIMEN	Biological specimens
NOTE	Clinical narrative text
NOTE_NLP	NLP-derived information associated with notes
DEATH	Mortality information

These domain assignments matter.

For example, OHDSI distinguishes a MEASUREMENT from an OBSERVATION based on whether the fact is the result of a standardized test or assessment versus another observed clinical fact.

If data are placed into the wrong domain, standardized analytical logic may fail to retrieve the intended events.

Healthcare System and Cost Data

OMOP also includes tables such as:

• PROVIDER
• CARE_SITE
• LOCATION
• PAYER_PLAN_PERIOD
• COST

These structures allow clinical events to be analyzed alongside healthcare-delivery, coverage, and financial information when those data are present in the source.

How Do OMOP Standardized Vocabularies Work?

The vocabulary layer is central to the OMOP data model.

The CONCEPT table assigns identifiers to concepts, while supporting tables such as VOCABULARY, DOMAIN, CONCEPT_CLASS, CONCEPT_RELATIONSHIP, and CONCEPT_ANCESTOR describe how concepts are classified and related.

OMOP’s vocabulary ecosystem incorporates widely used healthcare terminologies including SNOMED CT, RxNorm, LOINC, ICD coding systems, NDC, and many others. 

Which concepts become Standard Concepts depends on the domain and vocabulary conventions; there is not simply one globally “standard vocabulary” for every clinical domain.

A useful OMOP implementation preserves the distinction between:

Source value → Source concept → Standard Concept

For example, an ICD-10-CM condition code may be retained as the source representation while being mapped to an appropriate Standard Concept for cross-database analysis.

That provenance is important.

If an unexpected result appears later, analysts can trace the standardized record back to the terminology used by the source system rather than losing the original representation.

What Happens When a Source Code Cannot Be Mapped?

An ETL should not assign an incorrect Standard Concept simply to increase mapping coverage.

Where an appropriate Standard Concept cannot be identified, standardized concept fields can use concept_id = 0 according to OMOP conventions while preserving the source information.

For institution-specific terminology not represented in the OMOP vocabulary, OHDSI also supports local custom concepts. 

Custom concept IDs are above 2,000,000,000, are non-standard, and are intended for source-concept fields. They remain local and cannot substitute for Standard Concepts in network research.

This is why OMOP data mapping is not just string matching.

Clinical meaning has to survive the transformation.

How Does the OMOP ETL Process Work?

The OMOP ETL process extracts data from source systems, transforms both its structure and semantics, and loads the standardized results into the CDM.

OHDSI recommends separating ETL design from implementation. 

ETL design requires a detailed understanding of the source data and the CDM, while implementation focuses more heavily on translating that design into efficient, repeatable technical processes.

A production implementation typically follows these stages.

1. Define the Analytical Use Cases

Start by deciding what the OMOP environment needs to support.

Examples include:

• real-world evidence,
• cohort discovery,
• pharmacoepidemiology,
• outcomes research,
• population characterization,
• clinical research,
• patient-level prediction,
• healthcare AI and data science.

The use case determines which source domains require the highest transformation fidelity.

Trying to migrate every source field before defining the analytical objective often increases complexity without ensuring that the resulting CDM can answer the intended research questions.

2. Profile the Source Data

Teams need to understand:

• source tables and relationships,
• code systems,
• null distributions,
• field cardinality,
• date semantics,
• duplicated records,
• historical changes,
• local codes,
• units,
• encounter structures,
• data provenance.

OHDSI’s WhiteRabbit can profile the structure and content of source data in preparation for ETL design. 

Rabbit-In-A-Hat uses that profiling information to help document mappings between source data and OMOP tables and fields; it documents ETL logic rather than generating the ETL code itself.

3. Design Source-to-OMOP Mappings

Teams then define transformation rules such as:

source field → target OMOP field → transformation rule → vocabulary rule → provenance rule

The PERSON and OBSERVATION_PERIOD tables are often addressed early because event tables depend on patient identity and meaningful observational timelines. 

OHDSI’s ETL guidance specifically notes that observation-period logic can be among the most complex and consequential parts of an implementation.

Visit reconstruction can also be challenging.

One source may represent an inpatient hospitalization as a single encounter. Another may produce multiple departmental encounters, claims lines, or service records.

The ETL team must document how those source events become OMOP visits because downstream temporal analyses may depend on the result.

4. Map Terminology to Standard Concepts

Supported source concepts can use mappings supplied through the OMOP Standardized Vocabularies.

Local terminology requires additional mapping work.

OHDSI’s Usagi helps identify candidate Standard Concepts using terminology matching, but mappings still require review from people who understand the source codes and their clinical meaning.

Mapping quality should not be judged only by the percentage of unique codes mapped.

A better implementation also examines:

• record-level mapping coverage,
• high-frequency unmapped concepts,
• clinically important unmapped concepts,
• incorrect target domains,
• mapping precision,
• information loss.

A single unmapped laboratory code used millions of times may matter more analytically than hundreds of rare local codes.

5. Preserve Source Provenance

Standardization should not erase the original data.

Source-value, source-concept, and type-concept fields help retain information about what was recorded and how the standardized event was derived.

This becomes critical during research validation, troubleshooting, and ETL maintenance.

If disease prevalence changes after an EHR conversion, investigators need enough lineage to determine whether the difference came from patient populations, source coding, extraction logic, vocabulary mapping, or OMOP transformation.

6. Build a Repeatable Pipeline

OHDSI explicitly recommends repeatable ETL processes so the conversion can be rerun when source data are refreshed.

Beyond the formal CDM requirements, production environments typically need additional engineering controls such as:

• stable identifier strategy,
• incremental-load management,
• ETL version control,
• vocabulary-version tracking,
• reconciliation reporting,
• error handling,
• automated testing,
• regression testing,
• data lineage,
• source-release tracking.

These are enterprise data-engineering practices rather than universal OMOP specification requirements, but they become important when maintaining a CDM over time.

How Do You Validate an OMOP Implementation?

A pipeline completing without SQL errors does not mean the resulting database is analytically trustworthy.

Validation should occur at several levels.

Structural Validation

Check whether:

• required tables and fields exist,
• required values are populated,
• primary and foreign keys behave correctly,
• records use appropriate domains,
• CDM conventions are followed.

Semantic Validation

Evaluate:

• Standard Concept mapping,
• unmapped high-volume records,
• concept_id 0 usage,
• unexpected domains,
• source-to-standard relationships,
• clinically questionable mappings.

Temporal and Clinical Validation

Check whether timelines make sense.

Examples include:

• visit start and end dates,
• observation periods,
• medication exposure dates,
• laboratory dates,
• procedures relative to visits,
• events occurring after recorded death,
• implausible ages or sequences.

OHDSI emphasizes that data quality should be assessed in the context of conformance, completeness, and plausibility and that problems can originate either in source data or during transformation.

Use OHDSI Data-Quality Tools Carefully

The Data Quality Dashboard (DQD) runs more than 3,500 checks against an OMOP CDM instance. 

OHDSI’s current tooling matrix shows released legacy support for CDM v5.4, while complete feature support for new v5.4-specific additions is still marked as initiated but not yet fully tested and released.

Other OHDSI tools include ACHILLES for broad database characterization and ARES for viewing characterization and DQD results.

Organizations using newer v5.4-specific features should verify current compatibility for each OHDSI tool rather than assuming every new field or table is fully supported.

Planning an OMOP conversion?

Validate the source-to-OMOP architecture, terminology strategy, ETL rules, and data-quality approach before scaling the transformation across an enterprise dataset.

What Are the Main Healthcare Use Cases for OMOP CDM?

Multi-Site Observational Research

A major advantage of a common model is the ability to apply standardized analytical methods across participating databases.

OHDSI network research can operate in a distributed model where data partners execute common analysis locally instead of pooling patient-level information into one shared central database.

This supports reproducibility while allowing participating organizations to maintain control over their data.

Real-World Evidence and Comparative Effectiveness

OHDSI’s population-level estimation methods support use cases such as treatment selection, medical-product safety surveillance, and comparative effectiveness research.

OMOP can provide the standardized data foundation for these analyses.

It does not, however, guarantee valid real-world evidence by itself.

Study design, cohort validity, data fitness, confounding control, measurement error, bias, and statistical methodology still determine whether conclusions are credible.

Cohort Discovery and Phenotyping

Researchers can define populations using combinations of:

• diagnoses,
• medications,
• procedures,
• measurements,
• visits,
• observation time,
• demographic characteristics,
• temporal relationships.

CONCEPT_ANCESTOR supports hierarchical queries that can retrieve descendants of relevant concepts instead of requiring every individual code to be listed manually.

There is an important limitation: OHDSI currently describes high-quality comprehensive hierarchy coverage primarily for the Drug and Condition domains. Procedure, Measurement, and Observation hierarchies remain only partially covered.

Patient-Level Prediction and Machine Learning

OHDSI supports patient-level prediction methods using data represented in OMOP CDM. Its PatientLevelPrediction framework is designed around developing and validating models that predict future outcomes using historical patient information.

The U.S. Office of the National Coordinator for Health IT has also supported work using OMOP-format data as part of efforts to create and evaluate research- and AI-oriented EHR datasets.

However, converting data to OMOP does not automatically make it “AI-ready.”

Missingness, incomplete care capture, biased patient populations, terminology errors, label quality, temporal leakage, and inappropriate feature engineering can still produce unreliable models.

OMOP provides standardization, not automatic model validity.

Large-Scale U.S. Research Programs

The NIH All of Us Research Program provides a practical U.S. example.

Current All of Us documentation states that EHR data, including demographics, visits, diagnoses, procedures, medications, laboratory tests, and vital signs, are transformed into the OMOP structure, with source concepts mapped to standardized concepts.

Its architecture also demonstrates how OMOP and FHIR can coexist. 

Participant-provided information and physical measurements may be transferred using FHIR and then transformed into OMOP, while participating healthcare organizations transform EHR data into OMOP before sending it to the program’s Data and Research Center. 

Wearable data follow a different path rather than being forced into OMOP.

That is an important architectural lesson: not every healthcare data type needs to be forced into one standard.

Build a Research-Ready Data Foundation With CapMinds OMOP & Healthcare Data Engineering Services

Turning healthcare data into a standardized OMOP environment requires more than schema conversion. 

CapMinds provides end-to-end healthcare data engineering and digital health technology services to help health systems, research organizations, payers, and life sciences teams transform fragmented clinical and administrative data into reliable, analytics-ready platforms.

Our healthcare technology teams support the data lifecycle, from source assessment and architecture through integration, transformation, modernization, cloud deployment, and optimization.

CapMinds services associated with OMOP initiatives include:

• OMOP CDM architecture, implementation, and ETL engineering
• Healthcare data mapping and terminology standardization
• EHR, claims, laboratory, pharmacy, and research data integration
• HL7, FHIR, API, and healthcare interoperability services
• Healthcare data platform and warehouse engineering
• Data migration and legacy application modernization
• Cloud-native healthcare architecture and platform engineering
• Healthcare analytics, AI, and machine learning enablement
• Custom digital health software and application development
• Data quality, validation, governance, and integration support
• Healthcare IT consulting, cybersecurity, cloud services, and more

Whether you are building an OMOP research environment, modernizing a healthcare data platform, connecting EHR ecosystems, or preparing standardized data for analytics and AI, CapMinds can support the initiative from architecture through production.

Build a connected, scalable healthcare data foundation with CapMinds.

Discuss Your OMOP Implementation