OMOP & the OHDSI Network

What is OMOP?

The Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) is a standardized data structure for observational health data. Originally developed by the FDA and now maintained by OHDSI (Observational Health Data Sciences and Informatics), OMOP defines:

• A standard relational database schema (tables, fields, relationships)
• Standard vocabularies for every concept (SNOMED CT, LOINC, RxNorm, ICD-10, CPT, etc., all mapped to OMOP concept IDs)
• Standard analytic tools that run identically across any OMOP formatted dataset

ohdsi.org
ohdsi.org/omop

Why OMOP is important for patient registries

Federated research at scale

The OHDSI network includes over 300 databases in 70+ countries, collectively representing over 800 million participant records in OMOP format. When your registry is in OMOP format, it can participate in federated studies where the same analysis runs simultaneously across all OHDSI network databases, without any individual site sharing raw data.

This means: a natural history analysis of your disease can include participants from academic medical centers worldwide, massively increasing statistical power.

Regulatory use

FDA uses OMOP formatted real world data for regulatory submissions. If your registry aspires to support drug development, OMOP compatibility is increasingly expected.

Standard analytics tools

OHDSI has developed a library of open-source analytics tools that run on any OMOP database:

• ATLAS, Web-based cohort definition, incidence analysis, treatment pathways
• ACHILLES, Data quality and characterization
• HADES, R package library for population level estimation and participant level prediction
• Strategus, Orchestrates large-scale network studies

OMOP core tables relevant to registries

Is OMOP right for your registry?

When OMOP conversion is worthwhile

• You want to participate in federated OHDSI network studies
• You are collecting EHR-sourced data that naturally aligns with clinical data structures
• You have a technical team or academic partner capable of implementing and maintaining OMOP
• Your registry will be large enough to contribute meaningfully to federated analyses

When OMOP may not be necessary

• You are a small registry focused on rare disease natural history with highly disease specific data elements
• Your data is primarily patient-reported and doesn't align naturally with clinical data tables
• You lack technical resources for ETL (Extract, Transform, Load) development
• Your primary goal is within-registry analysis, not federated research

The middle path

Many registries maintain their native schema and create an OMOP export, a periodic conversion of their data to OMOP format for participation in specific studies, without rebuilding their entire infrastructure in OMOP. This is a practical compromise.

Getting started with OMOP

1. Review the OMOP CDM documentation: ohdsi.github.io/CommonDataModel
2. Assess your vocabulary coverage: Use the ATHENA vocabulary browser to check whether your concepts have OMOP standard equivalents, athena.ohdsi.org
3. Use Usagi for vocabulary mapping: OHDSI's Usagi tool helps map source concepts to OMOP standard concepts, github.com/OHDSI/Usagi
4. Run ACHILLES for data quality: After conversion, run ACHILLES to characterize your data and identify quality issues
5. Connect to the OHDSI community: forums.ohdsi.org is an active community with extensive help resources

Key resources

• OHDSI
• OMOP Common Data Model
• ATHENA Vocabulary Browser
• ATLAS, Try the demo
• Book of OHDSI, Free, comprehensive textbook
• OHDSI Community Forums

← Module 7 | Module 9: EHR Integration →