Module 8 · Part 2 · Data Architecture
OMOP & the OHDSI Network
Understand the OMOP Common Data Model and the OHDSI network, and evaluate whether converting your registry to OMOP is right for your goals.
Patient Registries 101 · Dr. Danielle Boyce · EpilepsyLive
What is OMOP?
- The Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) is a standardized data structure for observational health data.
- 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
Federated research at scale
- The OHDSI network includes over 300 databases in 70+ countries , collectively representing over 800 million participant records in OMOP format.
- 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.
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
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 in…
Getting started with OMOP
- Review the OMOP CDM documentation: ohdsi.github.io/CommonDataModel
- Assess your vocabulary coverage: Use the ATHENA vocabulary browser to check whether your concepts have OMOP standard equivalents, athena.ohdsi.org
- Use Usagi for vocabulary mapping: OHDSI's Usagi tool helps map source concepts to OMOP standard concepts, github.com/OHDSI/Usagi
- Run ACHILLES for data quality: After conversion, run ACHILLES to characterize your data and identify quality issues
- 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
Key resources (cont.)
- ← Module 7 | Module 9: EHR Integration →