HADES: OHDSI’s Open-Source Engine for Real-World Evidence

Every day, hospitals, insurers and clinics generate an enormous record of how medicines actually perform in ordinary patients: who took what, for how long, and what happened next. Randomised trials remain the gold standard, but they are expensive, slow and often never run for the head-to-head questions doctors care about most. The data to answer many of those questions already exists. The hard part is analysing it in a way that is rigorous, repeatable and trustworthy.

That is the job of HADES, the Health Analytics Data-to-Evidence Suite. Built by the open-science community Observational Health Data Sciences and Informatics (OHDSI), HADES is a free collection of R packages that takes standardised patient data and turns it into estimates, statistics, figures and tables. It quietly powers some of the largest real-world studies published in recent years, and it offers a useful lesson for anyone thinking about how to build trustworthy analytics at scale.

HADES project banner
Image: OHDSI / HADES project (github.com/OHDSI/Hades), Apache License 2.0.

What HADES is, and the data model behind it

According to the official HADES site, the suite was formerly known as the OHDSI Methods Library. It is a set of open-source R packages for large-scale analytics in three broad areas: describing patient populations (characterisation), estimating the causal effect of treatments across populations, and predicting outcomes for individual patients.

HADES does not work on raw hospital exports. It runs against data that has been converted to the OMOP Common Data Model (CDM), a shared format with standardised vocabularies so that a diagnosis or drug code means the same thing whether it came from a US insurance claim or a Spanish primary-care record. The peer-reviewed HADES paper by Martijn Schuemie and colleagues (MEDINFO 2023, published 2024) explains the payoff: because everyone shares the same format, an analysis can be run across a federated network in which patient-level data stays at each site and only aggregated statistics are shared.

Technically, HADES is R code that pushes most of the heavy lifting to the database server. The project lists support for platforms including PostgreSQL, Microsoft SQL Server, Oracle, Amazon Redshift, Google BigQuery, Snowflake, Apache Spark, DuckDB and InterSystems IRIS, with several of them tested in continuous integration (HADES supported platforms). Every package is released under the permissive Apache License 2.0, so organisations can use, modify and redistribute it without royalties.

A tour of the toolbox

The HADES package list runs to more than 30 packages. A few do most of the visible work:

  • CohortMethod runs new-user cohort studies, using large-scale regression to build propensity and outcome models. In plain terms, it compares similar patients who started drug A with those who started drug B.
  • SelfControlledCaseSeries compares each patient with themselves, contrasting periods of exposure with periods without it, which neatly cancels out many fixed personal differences.
  • PatientLevelPrediction builds and evaluates machine-learning models that estimate an individual’s risk of an outcome, with sister packages for deep learning and ensembles.
  • FeatureExtraction automatically generates large sets of patient characteristics (diagnoses, drugs, procedures, demographics) to feed into those models.
  • DatabaseConnector and SqlRender let the same code talk to many database dialects, which is what makes a single study portable across a global network.
  • EmpiricalCalibration, Achilles and DataQualityDashboard measure data quality and the real-world error rate of a study design.
  • Strategus ties it all together. Its documentation describes it as the package for coordinating and executing analytics built from HADES modules: you design a study specification once, execute it against the OMOP CDM at each site, then upload and review the results.

Under the hood, efficiency matters. The Book of OHDSI notes that CohortMethod can compute effect estimates for many exposures, outcomes and analysis settings at once, reusing shared steps such as covariate extraction or a propensity model instead of repeating them, and running work in parallel. A dedicated regression engine, Cyclops, makes it possible to fit models with very large numbers of variables and patients.

Why it is built to be trusted, not just to be fast

Observational studies have a reputation problem: run enough analyses on enough data and something will look significant. HADES is designed around that weakness. The HADES site says the suite supports transparency, reproducibility and measuring how a method actually performs in a given context, followed by empirical calibration of the results.

The idea is simple but powerful. Researchers include dozens of “negative control” questions, pairs of drugs and outcomes where no real effect is expected. If the method still finds “effects” there, that reveals the hidden bias in the study, and the main estimates can be adjusted accordingly. The HADES paper adds that the software itself is kept reliable through continuous integration and a large set of unit tests, and that HADES is used in almost all published OHDSI studies, including some that have directly informed regulatory decisions.

HADES in the real world: the LEGEND-T2DM study

The clearest demonstration is LEGEND-T2DM, published in the Journal of the American College of Cardiology in 2024. Researchers wanted to know how four classes of second-line diabetes drugs compared on heart outcomes, a question no major head-to-head trial was addressing.

Across 10 federated data sources in four countries, all standardised to OMOP, the team identified about 4.7 million patients with type 2 diabetes, including roughly 1.5 million with established cardiovascular disease who started one of the four drug classes after metformin. They used large-scale propensity scores, 100 negative control outcomes for calibration, blinded study diagnostics and a meta-analysis across sites. All results were shared in a public app and all code on GitHub.

The findings were clinically meaningful: SGLT2 inhibitors and GLP-1 receptor agonists were associated with lower risk of major cardiovascular events than DPP-4 inhibitors, which in turn did better than sulfonylureas, while SGLT2 inhibitors and GLP-1 drugs performed comparably to each other. The authors concluded that those two classes should be prioritised as second-line agents for patients with heart disease. That is a trial-sized answer produced without a new trial, and without any patient record leaving its home institution.

The ecosystem around HADES keeps growing. In Europe, the EHDEN Foundation says it maintains a network of more than 100 data partners mapped to the OMOP CDM, the format HADES is built to analyse.

Practical takeaways

  • Standardise first. HADES only pays off once data is in the OMOP CDM. For most organisations, the extract-transform-load work is the real project.
  • Start small and safe. The Eunomia package ships a small synthetic OMOP dataset on an embedded SQLite database, ideal for learning without touching patient data.
  • Plan the hardware. The Book of OHDSI recommends an analytics workstation with at least four cores and 16 GB of memory, plus R and Java.
  • Reuse, don’t rewrite. Validated, tested packages are less error-prone than custom scripts, and Strategus makes multi-site studies repeatable.
  • Bake in calibration. Treat negative controls and study diagnostics as part of the design, not an afterthought.
  • Join the community. OHDSI’s forums and GitHub issue trackers are where questions get answered and network studies get organised.

Conclusion

HADES is not flashy. It has no chatbot and no glossy dashboard at its core. What it offers is rarer: a shared, open, well-tested way to ask hard medical questions of millions of real patient records and get answers that hold up. As health systems sit on ever-larger stores of data, tools that combine scale with built-in scepticism may matter as much as any new algorithm. HADES shows that open source, common standards and honest error measurement can turn routine records into evidence that changes how patients are treated.

Sources