Running Multi-Site Observational Studies Without Moving Data
To run a multi-site observational study without moving data, you invert the traditional workflow: instead of pooling patient records into a central repository, each participating site harmonises its data to a common data model, the analysis code travels to every site, executes locally against the source data, and only aggregate results — counts, coefficients, summary statistics — return to the coordinating centre. This pattern, known as a federated network study, is how the Observational Health Data Sciences and Informatics (OHDSI) community has run analyses across hundreds of millions of patient records, and it is the execution model a federated Trusted Research Environment (TRE) industrialises.
Why this matters now
Two forces have made data movement the weakest link in multi-site research. The first is regulatory. The European Health Data Space (EHDS), Regulation (EU) 2025/327, requires that secondary use of electronic health data happens inside secure processing environments, and cross-border transfer of identifiable records remains constrained under the General Data Protection Regulation (GDPR) — particularly for transfers outside the European Economic Area following the Schrems II judgment. The second is trust. In May 2026, the UK Biobank incident demonstrated that even approved researchers operating inside a centralised platform’s normal workflow can walk data out of the front door — no policy was breached, but the architecture permitted bulk egress. Data custodians have read the lesson: a study design that never asks for a copy of the data is dramatically easier to approve than one that does.
For researchers, this shifts the practical question from “how do I get the data?” to “how do I get my analysis to the data?” The good news is that the methodology is mature. The OHDSI network has published large-scale evidence this way for years — the LEGEND-HTN study of antihypertensive treatments (Suchard et al., The Lancet, 2019) analysed roughly 4.9 million patients across nine databases on three continents without pooling a single record — and the United States Food and Drug Administration’s Sentinel Initiative has run distributed safety queries across insurer databases on the same principle for over a decade.
The federation principle: compute moves, data stays
A federated network study rests on one architectural rule: federation means the computation moves to the data, never the inverse. Each custodian retains physical and legal control of its records; what circulates between sites is code and aggregate outputs. Because the data never leaves the source, each site’s existing legal basis for holding the data continues to apply, and the study avoids creating a new central honeypot that must itself be governed, secured, and eventually deleted.
It is worth distinguishing two related patterns. Federated analytics runs a statistical query at each site and combines the aggregate answers; federated learning trains a shared machine-learning model by exchanging parameter updates rather than records. Most observational studies — incidence, prevalence, comparative effectiveness, safety surveillance — need only the former. The distinction, and when each applies, is covered in more depth in our guide to federated analytics versus federated learning.
A practical framework: six steps to a federated network study
1. Write a protocol that assumes distribution
Design the study as you would any observational analysis — pre-specify the research question, cohort definitions, exposures, outcomes, and statistical methods, following the STROBE reporting guideline for observational studies. Then add the federated elements: which sites participate, what minimum cohort size each site must contribute, and precisely what leaves each site (aggregate tables, model coefficients, diagnostics — never row-level data). Register the protocol publicly where the field expects it, for instance the EU PAS Register for post-authorisation studies or the OHDSI study repository.
2. Harmonise every site to a common data model
Distributed code can only run identically everywhere if every site’s data looks structurally identical. The de facto standard for observational research is the Observational Medical Outcomes Partnership (OMOP) Common Data Model, currently version 5.4, maintained by OHDSI. Each site maps its local records — electronic health records, claims, registry data — into OMOP’s standardised tables and vocabularies (SNOMED CT for conditions, RxNorm for drugs, LOINC for measurements). This step is typically the longest in the critical path; our primer on the OMOP Common Data Model explains the mapping process and how AI-assisted tooling compresses it.
3. Package the analysis so it is portable and inspectable
The analysis must run unmodified at every site, which in practice means containerised code or standardised analytics packages (the OHDSI HADES R libraries are the reference example) pinned to specific versions. Portability is also a governance feature: because the same artefact runs everywhere, each site’s information-governance team can inspect exactly what will execute against their data before approving it.
4. Execute locally inside secure environments
Each site runs the study package against its OMOP instance inside its own secure perimeter. In a federated Trusted Research Environment this step is orchestrated rather than manual: the platform distributes the approved container to every node, schedules execution, and captures logs — so a twenty-site study does not require twenty separate email threads and twenty local analysts running scripts by hand. The federated TRE architecture exists precisely to turn this coordination burden into infrastructure.
5. Apply disclosure control before results leave any site
Aggregate outputs can still leak information — a count of three patients with a rare condition in a small hospital is close to an identification. Every result leaving a site should pass statistical disclosure control: small-cell suppression (commonly suppressing counts below 5 or 10), rounding, and review of model outputs. In mature deployments this is automated as an airlock — a checkpoint every output must clear before egress — rather than a manual review queue.
6. Combine, interpret, and report network heterogeneity
The coordinating centre meta-analyses the site-level estimates, examines between-site heterogeneity (a genuine scientific finding in itself, not merely noise), and reports results with the same rigour as a pooled study — plus a transparent account of which sites contributed to which analyses and why any were excluded. Publish the full study package alongside the paper: because the entire analysis is a versioned artefact, a federated study can achieve a standard of reproducibility that pooled designs struggle to match — any future site can join the network, run the identical package, and extend the evidence base without renegotiating access to anyone else’s data.
Pooled study versus federated network study
| Dimension | Centralised pooled study | Federated network study |
|---|---|---|
| Data location | Copied to a central repository | Remains at each custodian — data never leaves the source |
| Legal basis | New transfer agreements per site; cross-border transfer risk | Each site’s existing basis applies; no transfer of record-level data |
| Approval timeline | Months to years — custodians must approve egress of full records | Weeks to months — custodians approve code execution and aggregate outputs |
| What moves | Patient-level records | Analysis code inbound; aggregates outbound |
| Breach surface | Central honeypot holding all sites’ data | No central copy exists to breach |
| Harmonisation | Performed centrally after pooling | Performed locally to a common data model (OMOP CDM) |
| Reproducibility | Depends on central environment | Versioned, containerised package runs identically at every site |
The model in production: national-scale federation
This is not a laboratory pattern. The OHDSI community routinely runs network studies spanning dozens of databases, and national programmes have adopted federation as policy: Genomics England operates Lifebit’s federated platform so that approved researchers analyse genomic and clinical data in place rather than downloading it, and Singapore’s Ministry of Health has taken the same architectural position for its national health-data assets. Canada’s CanPath cohort likewise supports federated analysis across provincial holdings, where pooling across jurisdictions would be legally fraught. In each case the observational-study workflow described above is the daily operating model, not an exception.
Common pitfalls and how to avoid them
Four failure modes account for most delayed or degraded network studies. First, semantic drift: two sites both “on OMOP” can still map the same clinical concept differently, so run cohort diagnostics and characterisation checks at every site before the main analysis, and treat unexplained between-site variation as a mapping question first and a biological question second. Second, under-specified outputs: if the protocol does not enumerate exactly what leaves each site, governance reviews stall — enumerate every table and figure in advance. Third, code that assumes one site’s quirks: hard-coded paths, locale-dependent date handling, or vocabulary versions that differ across nodes; containerisation and a dry run against a synthetic OMOP instance catch most of this. Fourth, treating disclosure control as an afterthought: retrofitting small-cell suppression after results have been circulated is a reportable incident, not a fix — build the airlock into the workflow from day one.
What to do next
If you are planning a multi-site observational study, start with three questions. Which common data model will all sites converge on, and how far is each site from it today? What is the complete list of artefacts that will cross each site’s boundary, in both directions? And who operates the orchestration — a coordinating analyst emailing scripts, or a federated TRE that distributes, executes, and airlocks automatically? The first two questions define your protocol; the third defines whether the study scales past a handful of sites. Reviewing the OHDSI network-study methodology and the architecture of a Trusted Research Environment is the fastest way to ground those decisions in working precedent.
Frequently asked questions
What is a federated network study?
A federated network study is a multi-site observational study in which the analysis code is distributed to each participating site, runs locally against data harmonised to a common data model, and only aggregate results are returned and combined. Patient-level data never moves between institutions.
Do all sites need to use the same common data model?
Yes, in practice. Distributed code can only execute identically everywhere if the data structures and vocabularies match, which is why the OMOP Common Data Model (v5.4) is the standard substrate for federated observational research. Sites on different models must either map to a shared one or maintain per-site query translations, which undermines reproducibility.
Is a federated study as statistically rigorous as a pooled study?
For most observational designs, yes. Site-level estimates are combined by meta-analysis, and methods research from the OHDSI community — including the LEGEND studies published in The Lancet — shows federated designs produce reliable evidence at a scale pooling rarely achieves, because more custodians are willing to participate when data never leaves the source.
How does GDPR affect multi-site observational studies?
GDPR restricts transfers of identifiable health data, especially across borders, and requires a lawful basis plus safeguards under Article 89 for research processing. Federated designs simplify compliance because record-level data is never transferred — each custodian processes its own data locally and only anonymous aggregates cross the boundary.
What outputs are safe to release from each site?
Aggregate tables, model coefficients, and diagnostics that have passed statistical disclosure control — typically small-cell suppression below a threshold such as 5 or 10, plus rounding and review for indirect identification. Automated airlocks apply these rules consistently before any output leaves a site.
How long does it take to set up a federated observational study?
The critical path is usually harmonisation: a site already on OMOP CDM can join a study in weeks, while a site starting from raw EHR extracts may need months, though AI-assisted mapping tooling has compressed this substantially. Governance approval is typically faster than for pooled designs because no data egress is requested.
Can federated studies include machine learning, not just statistics?
Yes. Federated learning trains models by exchanging parameter updates instead of records, extending the same data-stays-local principle to model development. Most observational studies, however, need only federated analytics — distributed queries returning aggregates — which is simpler to govern and review.