The OMOP Common Data Model

Every RWD source Lesson 15.3 covered was originally built for a different purpose than pharmacoepidemiology research — an EHR system was built to run a hospital, a claims database was built to process insurance payments — which means the same clinical concept gets recorded in genuinely incompatible formats across different institutions, countries, and healthcare systems. The OMOP Common Data Model exists specifically to solve that incompatibility, converting heterogeneous source data into one consistent table structure with standardised vocabularies, so the same analytical code can run across databases that were never designed to talk to each other.

This is, in a real sense, exactly the same standardisation principle Module 4 built for MedDRA: without a shared structure and shared vocabulary, the same clinical event recorded differently in a US claims database and a European EHR system can’t be meaningfully compared or combined — exactly the problem MedDRA solves for adverse event terminology, applied here to the entire structure of observational healthcare data. OMOP’s core domains cover the ground a pharmacoepidemiology study actually needs: Person captures demographics; Drug Exposure captures what was taken, when, and at what dose, mapped to RxNorm or ATC codes; Condition Occurrence captures diagnoses mapped to SNOMED CT; Measurement captures lab results mapped to LOINC — the specific domain that makes lab-confirmed adverse event outcomes (exactly the kind of outcome Lesson 15.3 flagged claims data as unable to provide) actually usable in an OMOP-mapped EHR study.

OMOP is maintained by OHDSI — the Observational Health Data Sciences and Informatics community — an open-science network of researchers, regulators, and data holders collaborating on a shared standard rather than a single proprietary system. Its adoption by the major RWE infrastructure Lesson 15.8 covers is a genuine, current, and mandatory feature of the field: EMA’s DARWIN EU mandates OMOP CDM for every participating database in its federated studies. FDA’s Sentinel system is progressively aligning with it. Even the WHO-UMC AI Hub is integrating OMOP mapping directly with VigiBase data, connecting Module 7’s global spontaneous reporting infrastructure with this module’s RWE infrastructure through a shared standard.

OHDSI’s companion toolkit, HADES (Health Analytics and Data-to-Evidence Suite), is a collection of standardised analysis packages — Cohort Diagnostics for phenotype validation, Cohort Method for propensity-score cohort studies, an SCCS package implementing Lesson 15.5’s self-controlled design, Patient Level Prediction for machine learning models, and Evidence Synthesis for meta-analysing results across databases — that together let a study be designed once, as a single piece of analytical code, and run identically across multiple OMOP-mapped databases simultaneously, with each database producing local results that get meta-analysed centrally. This is exactly the workflow DARWIN EU uses for its EMA-commissioned studies, and it’s the specific technical mechanism that makes Lesson 15.8’s federated networks operationally possible rather than a nice idea that never actually works at scale.