The traditional way to answer a question across many hospitals was to copy their data into one place. That approach is getting harder every year. Data protection law, health-specific localisation rules, hospital governance and plain institutional caution all push the same way: the data stays where it is.
Federated analytics flips the model. Instead of bringing data to the analysis, you send the analysis to the data, run it locally at each site, and combine only the results.
How OHDSI does it
The OHDSI community is one of the largest working examples. The Book of OHDSI describes a network of more than 100 databases standardised to the OMOP CDM, collectively representing over a billion patient records at the time of writing1. A study becomes a network study when it runs across multiple CDMs at different institutions1.
The rules are strict and simple. Each site runs the same study package against its own CDM. A local analyst reviews the outputs before anything leaves, and minimum cell counts suppress small numbers. Only aggregate results such as summary statistics, estimates and diagnostics are shared. In the book's words, OHDSI network studies do not share patient-level data, and patient-level data from different sites is never pooled centrally1.
Why it works: standardise first
Federation only works if the same code means the same thing everywhere. That is why OHDSI insists on the CDM and its standardised vocabularies. The book is explicit about the design shift this requires: you are building a study package to run at sites whose data you will never see, so concept sets must be exhaustive rather than tuned to your own data, and code must be parameterised for different database platforms1.
The same discipline shows up in cohort definitions: definitions are portable, versioned artefacts, not local SQL.
Federation moves the hard work from data transfer agreements to data standardisation. That's a better trade: standardisation compounds, while every transfer agreement starts from zero.
The operational reality
The book is candid that network studies take real coordination. Site start-up can involve ethics approvals, database permissions, configuring an analysis environment, reviewing study code and getting dependencies installed within local IT constraints1. Data quality varies between sites, and study leads may review quality reports or run checks to understand variation1. It also notes that much of the process has been manual, with the community working to systematise it1.
In practice, the technical parts are rarely what slows a network down. Governance, trust and site capacity are. Architecture can help by making each site's job as small and predictable as possible.
Where regulation is heading
Europe. The European Health Data Space regulation, Regulation (EU) 2025/327, was published in March 2025 and sets up a framework for secondary use of health data for purposes such as research, innovation and public health3. Commentary notes that secondary use of personal electronic health data is to take place within secure processing environments, with health data access bodies handling permits34. Check the regulation for application dates, which are phased.
The Gulf. The UAE's health data law restricts storing and processing health data outside the country unless an exception applies, with research among the circumstances commentary describes5; I cover the detail in UAE health data localisation. Saudi Arabia's transfer rules add their own conditions, as in Saudi PDPL and cross-border AI.
Different regimes, same direction: analysis has to go to the data, or to a controlled environment, rather than data going wherever analysts happen to be.
The architecture I use
- A standard node. Each site gets the same deployable stack: an OMOP CDM, vocabularies, data quality tooling as in OMOP data quality checks, and an analysis runtime. Infrastructure as code makes new sites predictable.
- Signed, reviewed study packages. Analyses arrive as versioned packages, reviewed and approved before they run, never as ad hoc queries.
- Output controls at the edge. Minimum cell counts, automated disclosure checks and a human review step before results leave the site.
- A coordination layer that never sees patient data: study registry, package distribution, results collection and audit trail.
- Monitoring of the network itself: which sites are current on CDM and vocabulary versions, data quality status, and study participation.
And AI?
Federated approaches extend to model development: training or evaluating models site by site and sharing parameters or metrics rather than data. The same principles apply, with more care, because model outputs can leak information in ways summary statistics usually don't. At minimum, I'd use federation for external validation: testing a model built at one site against many others before anyone claims it generalises. That is where a lot of clinical AI falls short, and a network makes it routine.
How I can help
I design federated health data platforms and OMOP networks, from the standard site node to governance and results pipelines, for research groups, health systems and life sciences companies in the US, Europe and the Gulf. See healthcare data architecture, or analyse your challenge and bring the result to a call.
- 1
- 2
- 3
- 4
- 5Health data transfers outside the UAEAl Tamimi & Company · 29 Jun 2021