The Odyssey of OHDSI: How a Common Language is Rewriting the Story of Human Health

Audio article

Uses the speech voice supplied by your browser or device.

Illustration of a networked constellation representing federated healthcare data collaboration

The Problem Nobody Talks About at Dinner Parties

Let me start with a confession. I have never, in my entire life, heard anyone at a dinner party lean across the cheese board and say, “You know what really keeps me up at night? The structural heterogeneity of observational healthcare databases.”

And yet. And yet.

This is the silent catastrophe of modern medicine. The data exists. Mountains of it. Every time you visit a doctor, fill a prescription, undergo a lab test, or file an insurance claim, your health leaves a digital fingerprint. Electronic Health Records (EHRs) capture the clinical encounter. Claims databases track the financial transaction. Disease registries catalog the epidemiological footprint. Genomic biobanks store the molecular blueprint. The data is there — vast, granular, longitudinal, and in many ways unprecedented in human history.

But here is the maddening truth: none of it can be reliably analyzed together without substantial harmonization.

A diagnosis of Type 2 Diabetes might be recorded as ICD-9 code 250.00 in one hospital’s EHR, ICD-10 code E11.9 in another, a SNOMED CT concept in a third, and a free-text note scribbled by a harried resident in a fourth. The same drug — say, metformin — might appear as an NDC code in a pharmacy dispensing record, an RxNorm concept in a clinical database, or a brand name in a claims file. The same lab value — fasting blood glucose — might use LOINC in one system, local hospital codes in another, and no code at all in a third, where it sits as an unstructured string in a PDF scan of a lab report.

This is not a technical inconvenience. This is a structural failure that has, for decades, prevented us from asking the most important questions in medicine at the scale they deserve. How does this drug actually perform in the real world, outside the sanitized bubble of a clinical trial? What are the long-term safety signals we missed because no one could look across enough patients? Which treatments work best for which subpopulations, and why?

For a long time, the answer was: we simply could not know. Not reliably. Not at scale. Not without spending years and millions of dollars on bespoke data integration projects that produced results no one else could reproduce.

And then, in 2008, something quietly extraordinary happened.

What Is This Thing Called OHDSI?

OHDSI — pronounced, with deliberate poetic resonance, “Odyssey” — stands for the Observational Health Data Sciences and Informatics initiative. It is, at its most reductive, a global open-science collaborative dedicated to extracting reliable evidence from the chaotic, messy, glorious sprawl of real-world health data. But that description is like calling the Library of Alexandria “a place with some scrolls.” It misses the scale, the ambition, and the quiet revolution.

At the heart of OHDSI lies the OMOP Common Data Model — the Observational Medical Outcomes Partnership Common Data Model — which is not merely a data format but a kind of Esperanto for healthcare: a standardized way of describing clinical reality that transcends the proprietary dialects of individual institutions, countries, and data systems.

The OMOP CDM does not make different health databases into one giant database. It creates a common analytical representation of heterogeneous databases. A hospital in Kolkata, an insurer in the United States, and a national database in Europe do not become one database. They remain separate databases whose relevant data are represented through a common schema and vocabulary, allowing standardized analytical programs to operate across them. A researcher can write an analysis against the OMOP CDM and distribute it across many databases, with OHDSI tooling translating the SQL to the target database dialect where necessary. The analysis does not care whether the original data came from Epic or Cerner or a homegrown legacy system. It does not care whether the patient was treated in a public hospital in India or a private clinic in Denmark. The query speaks OMOP. And OMOP speaks everywhere.

As of 2024, the OHDSI network encompasses 544 data sources across 54 countries, representing nearly a billion patient records across distributed databases. That is an extraordinary scale, although it should not be interpreted as nearly a billion unique individuals worldwide — the total includes overlapping populations and duplicate patients represented in more than one database. Not centralized. Not pooled. Not sitting in some monolithic server farm. But standardized, distributed, and analytically accessible.

This is not a database. This is an ecosystem. And ecosystems, as any biologist will tell you, are far more interesting than their individual components.

The Cast of Characters: Who Built This?

Every great story needs its architects, and OHDSI has more than its share of them — though many would bristle at being called architects, preferring the humbler title of “community members.”

The narrative begins with the Observational Medical Outcomes Partnership (OMOP), established in 2008 as a public-private partnership involving the FDA, the Foundation for the National Institutes of Health (FNIH), pharmaceutical companies, academia, and healthcare data partners. The FNIH was central to establishing the partnership. The FDA was a major stakeholder because of post-market safety surveillance, but the collaboration was broader than any single agency. The original mission was narrow but urgent: improve drug safety surveillance by enabling reliable analysis of observational healthcare data. The FDA, responsible for monitoring the safety of drugs after they reach the market, faced a fundamental problem. Clinical trials — the gold standard of medical evidence — are designed to detect common adverse effects in carefully selected populations over relatively short timeframes. They are terrible at detecting rare side effects, long-term consequences, or effects in populations excluded from the trial (the elderly, pregnant women, patients with multiple comorbidities). The FDA needed a way to mine the vast, untapped reservoir of real-world data — but that data was trapped in incompatible formats across dozens of databases.

Enter Patrick Ryan, who would become one of the foundational figures of the OHDSI community. Ryan, then at Janssen Research & Development, recognized that the OMOP project’s technical innovations — the CDM, the standardized vocabularies, the open-source analytics — needed a broader home than a single FDA-industry partnership. The OMOP experiments had proven feasibility. They had shown that disparate EHR and claims data could indeed be mapped into a single model and terminology, allowing statistical analyses to be reused across sites. But the work needed to outlive the original project. It needed to become a living, breathing, evolving standard maintained by a community rather than a committee.

In 2013, the OMOP stakeholders launched OHDSI — Observational Health Data Sciences and Informatics — with its coordinating center at Columbia University in New York. Its first annual meeting followed at Columbia in 2014. The mission expanded dramatically. No longer just drug safety. Now: all of observational health research. Characterization of diseases. Comparative effectiveness of treatments. Patient-level prediction. Population-level effect estimation. Methodological research to improve the reliability of observational studies themselves. And perhaps most importantly: an explicit commitment to open science — its core tools and the evidence generated by its collaborative research intended to be open-source and freely available, subject to the governance constraints of participating data custodians.

In 2024, OHDSI reported 4,294 collaborators across 83 countries. By 2025, the community had grown to more than 4,700 researchers across 88 countries. It includes clinicians who understand the clinical questions, epidemiologists who know how to frame them, biostatisticians who can design the analyses, computer scientists who can build the tools, informaticians who can map the data, patients who can ground the research in lived experience, regulators who can translate findings into policy, and industry partners who can apply evidence to drug development. It is, by design, a deliberately heterogeneous coalition — because the problems it addresses are too complex for any single discipline to solve alone.

Daniel Prieto-Alhambra, a key contributor to OHDSI and a prominent figure in the European arm of the community, describes it with characteristic warmth: “a very inclusive community in which basically anyone is invited to come and join and work with us. You just join the forums, attend one of the calls, and join a working group. It’s an open science community.” This is not corporate speak. This is the operational reality of a movement that runs on shared purpose rather than shared ownership.

When It All Began: A Timeline of Quiet Revolution

The history of OHDSI is not a story of sudden epiphanies or dramatic breakthroughs. It is a story of incremental, painstaking, often invisible work that gradually accumulated into something transformative.

2007–2008: The conceptual foundations of the OMOP CDM begin to take shape, with the formal Observational Medical Outcomes Partnership (OMOP) established in 2008 as a public-private partnership involving the FDA, the Foundation for the National Institutes of Health, pharmaceutical companies, academia, and healthcare data partners. The goal: evaluate methods for active drug safety surveillance using observational data. The central insight: we cannot analyze what we cannot compare, and we cannot compare what we cannot standardize.

2008–2013: The OMOP team develops the first version of the Common Data Model (CDM) and standardized vocabularies. They conduct a series of method evaluation experiments, testing whether observational data could reliably detect known drug safety signals. The results are mixed — observational data has real limitations, and naive analyses can produce misleading results — but the feasibility of standardization is proven. The CDM works. The vocabularies work. The analytics can be reused.

2013: The OMOP stakeholders launch OHDSI — the Observational Health Data Sciences and Informatics initiative — with a coordinating center at Columbia University. The scope expands from drug safety to the full spectrum of observational health research. The open-science ethos is codified. The community begins to grow organically, through word of mouth, through shared need, through the gravitational pull of a genuinely good idea.

2014: OHDSI’s first annual meeting is held at Columbia University. The community begins to coalesce around shared tools and methodologies.

2016: By this point, 52 databases containing about 682 million patient records had been converted to the OMOP CDM, although the total could include duplicate patients represented in more than one database. The federated network model is operational. The first large-scale network studies begin to appear in the literature. The community starts developing its signature software tools: ATLAS for cohort definition and analysis, ACHILLES for data quality assessment, and the methodological frameworks that would later coalesce into HADES (the Health Analytics Data-to-Evidence Suite).

2019: A landmark project demonstrates the power of the OMOP ecosystem for pharmacovigilance. Researchers publish ADEpedia-on-OHDSI, developing an ETL process to transform the FDA’s FAERS (FDA Adverse Event Reporting System) spontaneous reports into OMOP CDM format, enabling combined analysis of post-market safety signals with EHR-derived data. The same year, a validation study of CPRD found that 99.9% of condition records and 89.7% of drug records could be mapped to OMOP, with most unmapped drug records representing devices or over-the-counter products. Some information loss remained, but the model was not just theoretically sound; it was practically robust.

2020: The COVID-19 pandemic arrives, and OHDSI faces its most consequential test. In March 2020, at the beginning of the pandemic, OHDSI hosts a four-day virtual study-a-thon, supported by the European Health Data & Evidence Network (EHDEN), convening more than 330 researchers from 30 countries with access to 37 healthcare databases containing COVID-19 patient data. Fifteen workstream groups tackle urgent research questions. 355 cohort definitions are created, of which 114 are reviewed and validated for use in the study-a-thon studies. Study packages are developed, distributed, executed across the federated network, and reviewed by clinical experts — all within days. The results inform clinicians, health systems, and regulators in real time. The pandemic does not create OHDSI’s value; it reveals it.

2024: The OHDSI network now spans 544 data sources in 54 countries. The OMOP CDM has evolved through multiple versions (currently v5.4 as the practical mainstream version; v6 is in development but not yet recommended for mainstream use), incorporating feedback from real-world implementations. The tool ecosystem has matured. The methodological frameworks have been refined through hundreds of network studies. What began as a narrow FDA-industry experiment has become a global public good.

This timeline is not just a history. It is a case study in how infrastructure — the boring, unglamorous, absolutely critical work of building standards and tools — can, over time, become the foundation for scientific progress at a scale that would otherwise be far harder, slower, or less reproducible.

Where Does This All Happen? The Geography of a Digital Ecosystem

OHDSI is, by design, a distributed network with no physical center — though Columbia University in New York serves as its coordinating hub. The “where” of OHDSI is not a place but a topology: a federated architecture where data remains physically located at its source, while analytical code travels to the data, executes locally, and returns only aggregated, de-identified results.

This is not a trivial architectural choice. It is the solution to one of the most intractable problems in health research: privacy and data governance.

In a traditional research model, if you wanted to study a drug’s safety across ten hospitals, you would need to negotiate data sharing agreements with each institution, extract patient-level data, ship it to a central location, and hope that the combined dataset was analytically coherent. This process takes months or years, costs fortunes, raises profound privacy concerns, and often fails because the data formats are incompatible anyway.

OHDSI flips this model. The data stays where it is. The hospital in Seoul keeps its data in Seoul. The insurance company in São Paulo keeps its data in São Paulo. The research institute in Stockholm keeps its data in Stockholm. What travels is the analysis — a standardized script, written against the OMOP CDM, that can be executed locally at each site. The script runs on the local OMOP database, generates summary statistics, and transmits only those statistics back to the coordinating center.

OHDSI uses a federated research model: the data remain with the data custodian, while standardized analytic code is executed locally and aggregate results are shared. In the standard OHDSI network-study model, patient-level data remain at the source site and only aggregate results are shared. No identifiable information leaves the local firewall.

This is what computer scientists call a federated or distributed analytics architecture, and it is the reason OHDSI can operate at global scale without violating the privacy principles that make health research ethically possible. It is worth distinguishing this from “federated learning,” which specifically refers to distributed machine-learning training in which model updates or parameters are exchanged rather than raw training data. OHDSI may use machine learning and there is research adjacent to federated learning, but calling the entire architecture “federated learning” is technically inaccurate. OHDSI itself describes the network in terms of federated research and aggregate summary statistics.

The geographical reach is genuinely staggering. The 54 countries represented in the OHDSI network span every inhabited continent. The data sources include not only the usual suspects — academic medical centers in the United States and Europe — but also national health systems in Asia, public hospitals in Latin America, insurance databases in the Middle East, and emerging data partnerships in Africa. Each brings its own data culture, its own regulatory environment, its own clinical practices. But once mapped to OMOP, they all speak the same analytical language.

The European dimension deserves special mention. EHDEN — the European Health Data & Evidence Network — is an IMI (Innovative Medicines Initiative) consortium that has built extensively on OHDSI’s foundation, developing the infrastructure for observational health research across Europe using the OMOP CDM federated network model. EHDEN and OHDSI are distinct but deeply complementary. EHDEN focuses on building the European data access network; OHDSI provides the global community, the tools, and the methodological frameworks. Together, they represent one of the most ambitious cross-border health data initiatives in history.

Why Should Anyone Care? The Stakes of Standardization

I want to be direct with you, because this matters.

If you have ever taken a medication, undergone a medical procedure, or wondered whether the treatment your doctor recommended was truly the best option, you have a stake in what OHDSI does. The quality of medical evidence — the evidence that informs clinical guidelines, regulatory decisions, insurance coverage, and ultimately the care you receive — depends on our ability to learn from the real world, not just from carefully controlled experiments.

Clinical trials are indispensable. They are the gold standard for establishing efficacy under ideal conditions. But they are also expensive, slow, and limited in scope. A typical Phase III clinical trial enrolls a few thousand patients, carefully selected to minimize confounding variables, monitored for a few years at most. The real world is messier. Patients have multiple conditions. They take multiple drugs. They stop treatments, switch treatments, miss doses, develop unexpected complications. The effects of a drug in a 65-year-old diabetic smoker with kidney disease who is also taking five other medications may bear little resemblance to its effects in the healthy 45-year-olds who dominated the trial.

This is the domain of real-world evidence (RWE) — evidence derived from observational data collected in the course of routine clinical practice. And real-world evidence is only as good as our ability to analyze it reliably, reproducibly, and at scale.

Before OHDSI, analyzing observational data at scale was essentially bespoke craftsmanship. Each study required custom data extraction, custom coding, custom quality checks, custom analysis scripts. The process was slow, expensive, non-transparent, and — critically — non-reproducible. A study conducted at one hospital could not be replicated at another, because the data formats, coding systems, and analytical approaches were all different. This is not how science, at its best, operates. Science requires reproducibility. It requires that findings be independently verifiable.

OHDSI changes this by making observational research standardized, transparent, and scalable. When a study is conducted across the OHDSI network, the protocol is published, the code is open-source, the cohort definitions are shared, and the results are available for scrutiny. Other researchers can run the same analysis on their own data and compare findings. Regulators can evaluate the evidence with confidence in its methodological rigor. Clinicians can apply the findings knowing they were generated through a transparent, community-vetted process.

The COVID-19 pandemic provided the most dramatic demonstration of why this matters. When the virus emerged, we knew almost nothing about it. Which treatments worked? Which drugs were safe to repurpose? What were the risk factors for severe disease? What were the long-term consequences? These questions needed answers fast — not in the years it would take to run clinical trials, but in weeks and months.

OHDSI’s response was the COVID-19 study-a-thon in March 2020. Over four days, 330 researchers from 30 countries collaborated to define cohorts, develop study packages, and execute analyses across 37 databases. The results informed clinical practice and regulatory decision-making in real time. Without the OMOP CDM, without the standardized analytics, without the federated network, this would have been far harder, slower, or less reproducible. Each institution would have conducted its own analysis in isolation. The results would have taken months to compile, if they could be compiled at all. The pandemic would have been darker for longer.

But the stakes extend far beyond pandemic response. Consider pharmacovigilance — the ongoing monitoring of drug safety after market approval. The FDA receives millions of adverse event reports annually through its FAERS system. FAERS is a spontaneous-reporting system whose data structure and terminology differ substantially from longitudinal EHR data, making direct integration difficult. By converting FAERS data into OMOP CDM format and combining it with EHR-derived signals, OHDSI enables a new kind of pharmacovigilance: one that can detect safety signals faster, with greater statistical power, and with the contextual richness that comes from full patient records rather than isolated adverse event reports.

Consider comparative effectiveness research — determining which of two or more treatments works better for a given condition. In the absence of head-to-head clinical trials (which are rare and expensive), observational data is often the only source of evidence. But observational comparative effectiveness is fraught with confounding: patients who receive Treatment A may differ systematically from those who receive Treatment B in ways that affect outcomes. OHDSI’s methodological frameworks — propensity score matching, negative control analyses, sensitivity analyses — are designed specifically to address these challenges, making observational comparative effectiveness more reliable than it has ever been.

Consider personalized medicine — the dream of tailoring treatments to individual patients based on their unique characteristics. This requires not just understanding what works on average, but what works for whom, under what circumstances. The scale of data needed for this kind of granular analysis is enormous. No single database is sufficient. Only a federated network like OHDSI, spanning hundreds of millions of patient records across diverse populations, can generate the statistical power needed to identify treatment effect heterogeneity — the differences in how treatments work for different subgroups.

In short: OHDSI matters because it transforms observational health data from an inchoate, inaccessible, institutionally fragmented resource into a systematic, analyzable, globally distributed evidence engine. It matters because the questions it enables us to ask — about drug safety, treatment effectiveness, disease natural history, personalized risk — are among the most consequential questions in medicine. And it matters because the alternative — continuing to let our richest source of health evidence remain siloed, incompatible, and analytically inert — is simply unacceptable.

How Does It Actually Work? The Machinery Beneath the Magic

I have been speaking in abstractions. Let me now descend into the machinery, because the how of OHDSI is where the real ingenuity lies. And I promise to make it intelligible, even if you have never written a line of code or mapped a medical code in your life.

The OMOP Common Data Model: A Rosetta Stone for Health Data

At the center of everything is the OMOP Common Data Model (CDM). Think of it as a universal translator, but instead of translating languages, it translates the idiosyncratic dialects of healthcare data into a single, standardized tongue.

The CDM is a relational database schema — a structured way of organizing data into tables and columns — that defines exactly how clinical information should be represented. It is not merely a suggestion. It is a specification. If you want your database to be OMOP-compliant, your data must fit into these tables, using these columns, conforming to these data types, referencing these standardized vocabularies.

The current mainstream version (v5.4) organizes clinical facts into a fixed set of tables, each holding one class of clinical event:

PERSON: One row per person within that database/CDM instance. Demographics. Birth date. Gender. Race. Ethnicity. The foundational identity of the patient in the database.
VISIT_OCCURRENCE: Encounters. Inpatient stays. Outpatient visits. Emergency department visits. Recorded healthcare visits and encounters as captured by the source system.
CONDITION_OCCURRENCE: Diagnoses. The diseases, disorders, and conditions recorded during visits. Mapped to standard concepts — typically SNOMED CT for clinical diagnoses, ICD-10-CM for billing-derived conditions.
DRUG_EXPOSURE: Medications. Dispensed, administered, or prescribed. Mapped to RxNorm for drug ingredients and standardized drug classes.
PROCEDURE_OCCURRENCE: Procedures performed. Mapped to CPT-4, HCPCS, or ICD-10-PCS codes, translated to standard concepts.
MEASUREMENT: Lab results, vitals, and other quantitative findings. Blood pressure. Glucose levels. BMI. Mapped to LOINC and other standard measurement vocabularies.
OBSERVATION: Clinical facts that do not fit neatly into the other domains. Family history. Smoking status. Patient-reported outcomes. Social determinants of health.
DEATH: Date and, where known, cause of death.
Standardized Health System Data Tables: LOCATION, CARE_SITE, PROVIDER — the infrastructure of care delivery.
Standardized Health Economics Data Tables: PAYER_PLAN_PERIOD, VISIT_COST, PROCEDURE_COST, DRUG_COST — the financial dimension of healthcare.
Standardized Derived Elements: COHORT, COHORT_ATTRIBUTE, DRUG_ERA, DOSE_ERA, CONDITION_ERA — pre-computed summaries that make complex analyses more efficient.

Every table, every column, every relationship is explicitly defined. There is no ambiguity about what goes where. This is what computer scientists might call a “strong” information model — one in which the encoding and relationships among concepts are formally specified, not left to interpretation. The 2016 OHDSI paper itself uses this phrase, though it is more rhetoric than a formal computer-science classification.

But structure alone is not enough. The CDM also specifies standardized vocabularies — the actual words, or more precisely the codes, used to describe clinical concepts. OMOP does not invent a single proprietary vocabulary. It designates standard concepts within each domain and uses established terminologies such as SNOMED CT, LOINC, RxNorm, and others, while retaining source vocabularies and mappings for traceability.

When a source database records a diagnosis as “ICD-10-CM E11.9” (Type 2 Diabetes Mellitus without complications), the ETL process maps this to the standard OMOP concept ID for Type 2 Diabetes. When a pharmacy record lists a drug by its NDC code, it is mapped to the standard RxNorm concept. When a lab result uses a local hospital code, it is mapped to LOINC or another appropriate standard vocabulary.

This dual standardization — of structure (how the data is organized) and semantics (what the data means) — is what makes the OMOP CDM powerful. It ensures not just that data from different sources looks the same, but that it means the same thing.

The ETL Process: From Chaos to Coherence

The transformation from source data to OMOP CDM is called ETL — Extract, Transform, Load. It is, in many ways, the most labor-intensive and intellectually demanding part of the entire OHDSI ecosystem.

ETL is not a mechanical process. It is a interpretive act. It requires deep understanding of both the source data and the target model. The ETL developer must know: How does this EHR system represent visits? What coding system does this claims database use for procedures? How are local lab codes mapped to standard concepts? What assumptions can we safely make, and what ambiguities must we resolve?

OHDSI provides tools to support this process. WhiteRabbit scans source data to understand its structure, data types, and content. Rabbit-in-a-Hat helps design the mapping from source tables to OMOP tables. Usagi assists with vocabulary mapping — matching local codes to standard concepts. But these are aids, not automations. The ETL process still requires human judgment, clinical knowledge, and iterative refinement.

A typical ETL project might involve mapping hundreds of thousands of local codes to standard concepts. A large health system might have 450,000+ local codes that need to be mapped to OMOP vocabularies. This is not a weekend project. It is a sustained, collaborative effort that often takes months and requires ongoing maintenance as source systems evolve.

But the payoff is enormous. Once the ETL is complete, the data is no longer trapped in its source system’s proprietary format. It is free. It can be analyzed using any OMOP-compatible tool. It can participate in network studies. It can be compared with data from other institutions, other countries, other continents.

Data Quality: The Achilles Heel and Its Namesake Tool

Garbage in, garbage out. This ancient principle of computing applies with particular force to health data. A beautifully standardized database is worthless if the underlying data is wrong, incomplete, or nonsensical.

OHDSI addresses this through ACHILLES — the Automated Characterization of Health Information at Large-scale Longitudinal Evidence Systems. ACHILLES is a data quality and characterization tool that generates thousands of descriptive statistics on an OMOP CDM dataset and applies a set of data quality rules to flag anomalies.

What does ACHILLES actually check? It looks for the obvious errors: drug exposures with negative quantities, visit end dates that occur before visit start dates, patients with impossible ages. It looks for the subtle errors: unusual distributions of codes that might suggest mapping problems, gaps in data capture that might indicate ETL omissions, implausible combinations of conditions and medications that might signal data corruption. It generates profiles of the database — age distributions, visit counts, top conditions, drug prevalence — that allow researchers to assess whether the data is suitable for a given study.

The companion “Achilles Heel” module applies a starter set of data quality rules and is openly extensible — meaning the community can add new rules as new data quality issues are discovered. In a published evaluation, ACHILLES Heel was applied to 24 real-world datasets from 7 organizations and demonstrated its value in finding ETL errors and omissions. It is not a panacea. It does not guarantee data quality. But it makes data quality visible, measurable, and improvable — which is more than can be said for most health data systems.

The Analytical Toolkit: From Cohorts to Evidence

Once data is standardized and quality-assessed, the real work begins: asking questions and generating evidence. OHDSI provides a comprehensive suite of open-source tools that support the full observational research lifecycle.

ATLAS is the flagship application — a web-based platform that provides a user-friendly interface for common analyses on OMOP CDM data without requiring programming skills. Through ATLAS, researchers can:

Define cohorts — groups of patients who meet specific criteria (e.g., “all patients diagnosed with Type 2 Diabetes who were prescribed metformin within 30 days of diagnosis”).
Perform clinical characterization — describing the baseline characteristics of a cohort (demographics, comorbidities, medications, procedures).
Conduct population-level effect estimation — comparing outcomes between cohorts to estimate treatment effects, with built-in methods for addressing confounding (propensity score matching, stratification, weighting).
Build patient-level prediction models — using machine learning to predict individual patient outcomes based on their characteristics and history.
Explore treatment pathways — visualizing the sequences of treatments that patients receive over time, revealing patterns of clinical practice.

ATLAS connects to the OMOP database through the OHDSI WebAPI — a RESTful service that handles the communication between the web interface and the underlying data. Behind the scenes, queries are translated into SQL, executed against the OMOP CDM, and results returned to the user.

For more advanced and customizable workflows, OHDSI provides HADES — the Health Analytics Data-to-Evidence Suite. HADES is a collection of R packages designed for reproducible and scalable analytics on OMOP CDM databases. It includes packages for cohort definition (Circe), feature extraction (FeatureExtraction), propensity score methods (CohortMethod), self-controlled designs (SelfControlledCaseSeries, SelfControlledCohort), patient-level prediction (PatientLevelPrediction), and many others. HADES is the power user’s toolkit — less user-friendly than ATLAS, but far more flexible and customizable.

All of these tools are open-source. All are freely available. All are continuously developed and improved by the community. This is not a commercial product with a support hotline. It is a public good, maintained by the collective effort of thousands of contributors.

The Federated Network: How Global Studies Actually Run

Let me walk you through how a typical OHDSI network study works, because the mechanics are genuinely elegant.

A researcher — let’s call her Dr. Chen — has a question: “Does Drug X increase the risk of adverse outcome Y compared to Drug Z in patients with condition W?”

Dr. Chen develops a study protocol: the objective, the rationale, the target population, the cohort definitions, the analytical methods. She writes the analysis code using HADES packages, ensuring it is compatible with the OMOP CDM. She posts the proposal to the OHDSI Research Forum, where the community reviews it, suggests modifications, and expresses interest in participating.

Once the protocol is finalized and the code is cross-tested, the study is promoted to an “Active Project.” The study package — the protocol, the code, the cohort definitions — is distributed to all interested data partners in the network.

Each data partner receives the package and runs it on their local OMOP database. The code executes locally, behind the institution’s firewall. No patient-level data leaves the premises. The code generates summary statistics, effect estimates, and diagnostic outputs — all aggregated and de-identified.

The data partners submit their results back to the coordinating center. Dr. Chen receives results from hospitals in Seoul, Berlin, São Paulo, New York, and dozens of other locations. She performs a meta-analysis, combining the site-specific results to generate an overall estimate. She examines heterogeneity — do the results differ systematically across sites, and if so, why? She conducts sensitivity analyses. She prepares the findings for publication.

The entire process is transparent. The protocol is public. The code is open-source. The results are shared with the community. Other researchers can replicate the study on their own data. Regulators can evaluate the methodology. Clinicians can assess the relevance to their practice.

This is how evidence should be generated. Not in isolation. Not behind closed doors. Not as a bespoke craft project. But as a standardized, reproducible, globally distributed scientific process.

The Technologies That Make It Possible

The OHDSI ecosystem rests on a stack of technologies, standards, and intellectual frameworks that deserve explicit acknowledgment. None of them is unique to OHDSI, but their integration is.

Standardized Clinical Terminologies

The OMOP CDM adopts and integrates the major international terminology standards:

SNOMED CT (Systematized Nomenclature of Medicine — Clinical Terms): The most comprehensive clinical terminology in the world, covering diseases, findings, procedures, body structures, and more. SNOMED CT serves as a primary standard for conditions in the OMOP CDM.
RxNorm: A normalized naming system for medications developed by the U.S. National Library of Medicine. RxNorm provides standard names for clinical drugs and links to other drug vocabularies (NDC, ATC, etc.).
LOINC (Logical Observation Identifiers Names and Codes): A major international standard for identifying laboratory and clinical observations. Lab tests, vital signs, and clinical measurements commonly map to LOINC codes.
ICD-9-CM, ICD-10-CM, ICD-10-PCS: The International Classification of Diseases coding systems, widely used for billing and epidemiological reporting. These are mapped to standard concepts but are retained in the CDM for traceability.
CPT-4, HCPCS: Procedure coding systems used primarily in the United States for billing.
ATC (Anatomical Therapeutic Chemical): The WHO drug classification system, used for grouping drugs by therapeutic class.

The OMOP vocabulary system — accessible through the ATHENA tool — integrates all of these terminologies into a single, navigable framework. It provides mappings between them, hierarchical relationships (“is-a” relationships that allow aggregation from specific to general concepts), and concept synonyms. When a researcher searches for “Type 2 Diabetes” in ATLAS, the system knows to include all descendant concepts — all the specific subtypes, complications, and related conditions — ensuring comprehensive cohort capture.

Relational Database Technology

The OMOP CDM is implemented as a relational database, which means it organizes data into tables with predefined relationships. This is not the only way to store health data — graph databases, document stores, and other NoSQL approaches have their advocates — but relational databases have decades of maturity, robust query languages (SQL), and extensive tooling. OHDSI supports multiple database platforms: PostgreSQL, SQL Server, Oracle, Amazon Redshift, Google BigQuery, Snowflake, Databricks. The CDM specification is database-agnostic; the same schema can be implemented on any of these platforms.

The R Programming Language and Statistical Computing

Much of OHDSI’s analytical infrastructure is built in R — a programming language and environment for statistical computing that has become the lingua franca of academic biostatistics and epidemiology. The HADES packages are R packages. The statistical methods — propensity score matching, survival analysis, meta-analysis — are implemented in R. This choice reflects OHDSI’s academic roots and the statistical sophistication of its community. R is not the most user-friendly language for non-programmers, which is why ATLAS provides a graphical interface for common tasks. But for advanced analytics, R remains indispensable.

RESTful APIs and Web Services

The OHDSI WebAPI is built on REST (Representational State Transfer) principles — a standard architectural style for designing networked applications. It allows ATLAS and other client applications to communicate with the OMOP database over HTTP, making it possible to build web-based interfaces for complex database operations. This is the technology that enables a researcher in one country to define a cohort through a web browser and have the query execute on a database in another country.

Open-Source Software Development

Perhaps the most important “technology” enabling OHDSI is not a technology at all, but a methodology: open-source software development. All OHDSI tools — ATLAS, ACHILLES, HADES, WebAPI, the CDM specification itself — are open-source. Their code is publicly available on GitHub. Anyone can inspect it, modify it, contribute to it, or fork it for their own purposes. This is not altruism; it is engineering pragmatism. Open-source development harnesses the collective intelligence of a global community. Bugs are found faster. Features are added by those who need them. The software evolves in response to real-world use rather than product roadmap diktats.

The FHIR Intersection

An emerging area of technological convergence is the relationship between OMOP CDM and FHIR (Fast Healthcare Interoperability Resources) — the HL7 standard for exchanging healthcare data between systems. FHIR is designed for operational interoperability (making different EHR systems talk to each other), while OMOP is designed for analytical interoperability (making different databases analyzable together). They serve different purposes, but they are increasingly complementary. Some implementations use FHIR as an intermediate format: source data is first converted to FHIR, then mapped from FHIR to OMOP. Others maintain dual schemas — OMOP for research analytics, FHIR for operational data exchange. The relationship between FHIR and OMOP is an active area of community discussion and development, reflecting the broader trend toward greater standardization in health data.

What Gets Lost in Translation: Limitations, Trade-offs, and Unresolved Questions

I would be doing you a disservice if I presented OHDSI as a panacea. It is not. It is a powerful tool with real limitations, and understanding those limitations is as important as understanding its capabilities.

The ETL Burden

The transformation from source data to OMOP CDM is labor-intensive, expensive, and error-prone. A large health system might spend months and significant resources on ETL development, only to discover during quality assessment that critical data elements were misinterpreted, codes were mapped incorrectly, or assumptions about the source data proved wrong. The ETL process requires clinical domain expertise, technical skill, and institutional commitment. Not every organization has these resources. This creates a kind of digital divide: well-resourced academic medical centers can participate in OHDSI network studies, while smaller community hospitals and clinics may struggle to map their data at all.

Data Quality Is Not Guaranteed

Standardization does not equal quality. A database can be perfectly OMOP-compliant and still contain garbage. The source data might be incomplete (certain types of visits not captured), inaccurate (coding errors at the point of care), or biased (certain populations systematically underrepresented). ACHILLES and the Data Quality Dashboard can flag obvious problems, but they cannot fix underlying data deficiencies. The principle of “garbage in, garbage out” applies with full force. OMOP makes bad data consistently bad, which is better than inconsistently bad, but it does not make bad data good.

The Loss of Source-Specific Detail

Standardization inevitably involves abstraction. When you map a local hospital’s idiosyncratic coding system to SNOMED CT, you gain interoperability but you may lose nuance. A local code that captures a very specific clinical concept might map to a more general SNOMED concept, losing granularity. A source system that records medication administration in minute-by-minute detail might be compressed into OMOP’s DRUG_EXPOSURE table with start and end dates, losing temporal precision. The OMOP CDM is designed for common analytical use cases, not for preserving every detail of every source system. For most research questions, this trade-off is acceptable. For some, it is not.

Confounding and Causal Inference

Observational data is fundamentally different from experimental data. In a randomized controlled trial, patients are randomly assigned to treatment groups, which (in theory) balances all confounding factors. In observational data, treatment assignment is not random. Patients who receive Drug A may differ from those who receive Drug B in ways that affect outcomes — they may be sicker, older, have more comorbidities, be treated at different types of hospitals. These confounding factors can create spurious associations that look like treatment effects but are actually artifacts of patient selection.

OHDSI’s methodological frameworks — propensity score methods, self-controlled designs, negative control analyses — are sophisticated tools for addressing confounding. But they are not magic. They cannot eliminate bias that is unmeasured or poorly measured. They cannot turn observational data into experimental data. The results of observational studies must always be interpreted with appropriate caution, and the most reliable evidence often comes from triangulating multiple sources: randomized trials, observational studies, mechanistic understanding, and clinical judgment.

The Vocabulary Maintenance Challenge

Clinical knowledge evolves. New diseases are discovered. New drugs are approved. New lab tests are developed. The standardized vocabularies that anchor the OMOP CDM must be continuously updated to reflect these changes. SNOMED CT releases new versions. RxNorm adds new drug concepts. LOINC expands its coverage. Maintaining the OMOP vocabulary system — integrating new vocabulary versions, updating mappings, deprecating obsolete concepts — is a massive, ongoing effort. It requires coordination with vocabulary maintainers, community consensus on how to represent new concepts, and careful management of backward compatibility. This is invisible, unglamorous work, but without it, the entire ecosystem slowly drifts into obsolescence.

Privacy in a Federated World

The federated network model is designed to protect patient privacy by keeping data local and sharing only aggregated results. But aggregation is not always sufficient protection. In small populations or rare conditions, aggregated results might still be re-identifiable. A study that reports “3 patients with condition X at Hospital Y” might, in a small community, be enough to identify those patients. OHDSI addresses this through minimum cell size rules (suppressing results with fewer than a specified number of patients) and other disclosure control mechanisms. But the tension between analytical utility and privacy protection is perpetual and unresolved.

The Governance Question

OHDSI is not governed like a conventional commercial software company. Its community, working groups, Steering Working Group, and Columbia-based coordinating center share responsibility for its direction and infrastructure. The Steering Working Group provides guidance to the coordinating center. Decisions are made through community consensus, working groups, and the rough pragmatic mechanism of “what enough people agree to use.” This has worked remarkably well so far, but as the community grows and commercial interests become more prominent, governance questions will become more acute. Who controls the CDM specification? Who decides which vocabularies to adopt? Who ensures that the open-source tools remain truly open? These are not abstract concerns. They are the questions that will determine whether OHDSI remains a public good or becomes captured by particular interests.

The Bigger Picture: What OHDSI Teaches Us About Knowledge Itself

I want to step back now, because there is something larger here than health data standardization. Something that touches on how we, as a species, generate and share knowledge.

For most of human history, medical knowledge was local. A physician in 18th-century Edinburgh knew what worked for his patients in Edinburgh. He had no systematic way of knowing whether the same treatments worked in Paris or Cairo or Kyoto. The 20th century changed this, somewhat, through the rise of clinical trials and systematic reviews. But even then, the evidence base remained fragmented — different studies, different populations, different methods, different outcomes, synthesized through the heroic but imperfect labor of meta-analysts and guideline committees.

What OHDSI represents is something different. It is an attempt to create a global, distributed, continuously operating evidence generation system — one that does not rely on the episodic, expensive, slow mechanism of individual studies, but on the persistent, standardized, scalable analysis of data that is already being collected in the course of routine care.

This is not just a technical achievement. It is a philosophical one. It embodies a particular vision of how knowledge should work: open rather than proprietary, collaborative rather than competitive, standardized rather than bespoke, distributed rather than centralized. It is, in its deepest structure, an argument about the nature of scientific progress.

Consider the contrast with traditional pharmaceutical research. A drug company conducts a clinical trial, analyzes the data internally, publishes selected results, and keeps the raw data proprietary. The evidence is generated behind closed doors, filtered through commercial interests, and made available only in the form that the company chooses to disclose. This is not a criticism of any particular company; it is the structural logic of a system in which data is a competitive asset.

OHDSI inverts this logic. In the OHDSI model, data remains with its custodians, but the analytical methods, the cohort definitions, the study protocols, and the results are all open. The value is not in hoarding data but in the ability to ask questions across data. The competitive advantage is not in exclusive access but in analytical sophistication, methodological rigor, and the speed with which reliable evidence can be generated.

This is, I would argue, a more robust model for generating medical knowledge in the 21st century. Not because it is perfect — it is not — but because it is more aligned with how knowledge, at its best, advances. Knowledge advances through replication, through criticism, through the cumulative refinement of methods and findings. It does not advance through isolated, non-reproducible studies conducted in secrecy. OHDSI is applying this principle to the domain of observational health research at a scale that was previously far harder, slower, or less reproducible.

And there is a deeper lesson here about infrastructure. We tend to celebrate scientific breakthroughs — the discovery of penicillin, the structure of DNA, the development of mRNA vaccines — while ignoring the infrastructure that makes them possible. But breakthroughs do not happen in a vacuum. They happen in laboratories that are funded, in journals that are curated, in databases that are maintained, in communities that are sustained. The OMOP CDM is infrastructure. ACHILLES is infrastructure. The OHDSI community is infrastructure. They are not exciting in the way that a new drug is exciting. But without them, the new drug cannot be evaluated. Without them, we cannot know whether it works in the real world. Without them, the breakthrough remains a promise rather than a practice.

This is the quiet genius of OHDSI. It is not trying to be exciting. It is trying to be useful. It is trying to build the plumbing through which medical evidence can flow — reliably, reproducibly, at scale, across borders and institutions and data systems. And in doing so, it is demonstrating that the most transformative technologies are often the ones that make other technologies possible.

I think of it sometimes as the Library of Alexandria for the digital age — not a single building, but a distributed network of standardized knowledge, accessible to anyone who learns the language. The Library of Alexandria became a lasting symbol of centralized knowledge and the fragility of its preservation. OHDSI’s federated architecture is, in part, a response to this fragility. By distributing data and standardizing access rather than centralizing storage, it creates a more resilient system — one that can survive the failure of any single node, any single institution, any single country.

But it is more than resilience. It is democracy of a kind. The ability to generate reliable medical evidence has historically been concentrated in wealthy institutions in wealthy countries. OHDSI does not eliminate this inequality — the ETL burden still favors well-resourced organizations — but it reduces it. A researcher in a low-resource setting can, in principle, participate in global network studies using open-source tools and standardized methods. The analytical playing field is leveled, if not perfectly, then meaningfully.

And this, ultimately, is why I find OHDSI compelling beyond its technical merits. It is a practical experiment in open, collaborative, global knowledge production — applied to one of the most consequential domains of human inquiry: understanding what makes us sick and what makes us well. The methods it develops, the standards it maintains, the community it sustains, are not just tools for health research. They are models for how complex, distributed, interdisciplinary problems can be addressed in an age of abundant data and scarce consensus.

The Odyssey, in Homer’s telling, was a journey home — long, perilous, full of strange encounters and hard-won wisdom. The OHDSI Odyssey is a journey toward something else: a world in which the data we already have about human health can be transformed, through standardization and collaboration, into the evidence we need to make better decisions. It is not a journey with a destination. It is a journey that continues, that must continue, as long as we collect health data and care about what it means.

The data is there. Nearly a billion patient records, standardized, distributed, waiting to be asked the right questions. The tools are there. The community is there. The only question that remains is whether we have the patience, the resources, and the collective will to keep building — ETL by ETL, study by study, question by question — toward a world in which medical evidence is not a scarce commodity hoarded by the few, but a public good generated by the many.

That is the Odyssey. And it is far from over.

P.S. For those who wish to explore further, the OHDSI community maintains extensive documentation at ohdsi.org, including the OMOP CDM specifications, the ATHENA vocabulary browser, open-source software repositories, and active community forums. The annual OHDSI symposium — held in rotating locations around the world — is an unparalleled opportunity to meet the people behind the infrastructure and to understand, firsthand, why a common language for health data might be one of the most quietly revolutionary projects of our time.

Search & shortcuts

Quick destinations