Federated Meta-Analysis vs Federated Regression

Federated meta-analysis and federated regression are the two main ways to run statistics across sites that cannot pool their records. Meta-analysis fits a model separately at each site and combines the site-level estimates afterwards, while federated regression fits one model across all sites at once by exchanging aggregate quantities such as gradients or cross-product matrices. For linear models, and for iterative fits of generalized linear models, federated regression reproduces the result you would get from pooling individual-level data; meta-analysis only approximates it, and the approximation weakens when sites are small or outcomes are rare.
Why the choice matters now
Multi-site health research is moving away from copying records into a central warehouse. The European Health Data Space regulation routes secondary use through secure processing environments rather than bulk transfer, and national programs increasingly expect analysis to happen where the data is held. The May 2026 UK Biobank incident sharpened the point: approved researchers were able to move data out through the normal workflow of a centralized platform, which showed that access policy alone does not stop records from leaving. Once you accept that records stay put, the statistical question becomes practical. How do you get a pooled answer without pooled data?
The answer determines more than precision. It shapes how many rounds of communication each analysis needs, how much work falls on each site’s output checking, what you can say about between-site heterogeneity, and whether a reviewer will accept the result as equivalent to a conventional individual participant data (IPD) analysis. Choosing the wrong method can leave a study underpowered, biased toward large sites, or stuck in weeks of back-and-forth approvals.
How each method works
Federated meta-analysis
In a federated meta-analysis, every site runs the same analysis script locally and returns a small set of summary results: typically a coefficient estimate and its standard error for each parameter of interest. A coordinating analyst then combines those estimates. The two standard approaches are fixed-effect inverse-variance weighting, which assumes every site estimates the same true effect, and random-effects models such as the DerSimonian and Laird method, which allow the true effect to vary between sites and estimate that variation.
This is the pattern behind many observational network studies. It needs only one round trip per site, the outputs are low-dimensional and easy to review, and it maps directly onto the way systematic reviewers already think about combining evidence. It also tolerates sites that use slightly different local software, provided the model specification is identical.
Federated regression
Federated regression treats all sites as partitions of one dataset. For ordinary least squares, the sufficient statistics are the cross-product matrix of the predictors and the cross-product of predictors with the outcome. Each site computes its own contribution, the contributions are summed, and the pooled coefficients follow exactly. No iteration is needed.
For logistic, Poisson, or Cox models there is no closed form, so the fit proceeds iteratively. At each step of a Newton-Raphson or similar algorithm, sites return their local gradient and Hessian (the first and second derivatives of the log-likelihood) evaluated at the current coefficients. The coordinator sums them, updates the coefficients, and sends the new values back. After convergence, usually within a handful of iterations, the estimates match what a pooled IPD analysis would produce, up to numerical tolerance. Published implementations include the DataSHIELD framework, used in several European cohort consortia, and the GLORE approach to distributed logistic regression. One-shot methods also exist that approximate the pooled likelihood in a single round, trading a little accuracy for fewer exchanges.
Meta-analysis vs federated regression: a side-by-side comparison
| Dimension | Federated meta-analysis | Federated regression |
|---|---|---|
| What sites return | Site-level estimates and standard errors | Aggregate statistics: cross-products, gradients, Hessians |
| Communication rounds | One per analysis | One for linear models; several iterations for GLMs and survival models |
| Equivalence to pooled IPD | Approximate; close when sites are large and effects homogeneous | Exact for linear models; converges to pooled estimate for iterative fits |
| Small sites and rare outcomes | Weak: local models may fail to converge or produce unstable estimates | Strong: every event contributes to one likelihood |
| Between-site heterogeneity | Estimated directly through random-effects models | Must be modeled explicitly with site terms or mixed models |
| Covariate adjustment | Limited by local sample size at each site | Uses the full combined sample, so richer models are feasible |
| Disclosure review burden | Low: a few numbers per site | Higher: repeated intermediate outputs need automated checking |
| Site availability | Sites can run asynchronously | All sites must respond at each iteration |
The federation angle: where the method meets the architecture
Both methods assume that each site can run approved code against its own data and release only aggregate results. That assumption is the definition of a federated Trusted Research Environment (TRE). In a federated TRE, compute travels to the data, the individual-level records stay inside the custodian’s infrastructure, and every output passes an automated airlock before anyone outside can see it. The records themselves are never exported. Put simply, data never leaves the source.
The architecture matters most for federated regression, because the method generates many intermediate outputs. A manual output-checking process that works for one table per study breaks down when a logistic model needs six iterations across twelve sites. Lifebit’s federated TRE handles this with an automated airlock that applies statistical disclosure control rules to each release, so iterative algorithms can run without a human queue at every step. Our guide to output checking and statistical disclosure control in TREs covers the rules in more detail.
Harmonization is the other dependency. Neither method works if sites code the same variable differently. A site that records smoking status as three categories and another that records pack-years will produce estimates that cannot be combined, however elegant the statistics. Mapping each site to a common data model such as the OMOP Common Data Model before analysis is what makes a single analysis script portable. Lifebit automates much of that mapping, which is why federated regression becomes practical at network scale rather than only in carefully curated pilots.
It also helps to separate federated statistics from federated machine learning. Federated regression fits a classical, interpretable model with standard errors and confidence intervals. Federated learning trains larger predictive models, often neural networks, through repeated rounds of local training and parameter averaging. They share infrastructure but answer different questions; our article on federated analytics vs federated learning draws the line.
A practical framework for choosing
Most teams can decide with four questions, asked in order.
- Is the outcome rare or are some sites small? If any site has few events, local models may not converge, and meta-analysis will either drop those sites or give them unstable weights. Choose federated regression.
- Is heterogeneity between sites a research question in itself? If you want to report how much the effect varies across hospitals or countries, a random-effects meta-analysis gives you that directly. Federated regression can do it too, but only if you specify site-level terms or a mixed model.
- Can every site respond within the same working window? Iterative fitting needs all sites online at each step. If some custodians run analyses only on a weekly schedule, one-round meta-analysis is far easier to operate.
- How many covariates do you need? Adjusting for many confounders is often impossible within a single small site. Federated regression uses the combined sample, which supports the fuller model that reviewers expect.
Many studies use both. A common pattern is to run federated regression for the primary analysis, because it matches the pooled IPD result, and then run a site-stratified meta-analysis as a sensitivity check that exposes any site behaving differently from the rest.
Real-world practice
The Observational Health Data Sciences and Informatics (OHDSI) community has published many network studies in which each data partner runs a standardized analysis package against data mapped to the OMOP Common Data Model and shares only aggregate results, which are then combined. DataSHIELD, developed in the European cohort research community, takes the other route: researchers issue commands that run on each cohort’s server and return non-disclosive aggregates, and its regression functions iterate across servers to produce pooled estimates. Both show that the methods are mature. What varies between programs is the surrounding infrastructure: how quickly code can be deployed, how outputs are checked, and whether data has been harmonized well enough for one script to run everywhere.
National genomics and biobank programs face the same choice at larger scale. Lifebit’s work with custodians such as Genomics England and CanPath is built on the same principle: analysis goes to the data, and only checked aggregates come back. For a worked view of how multi-site observational designs run on that pattern, see running multi-site observational studies without moving data.
Common pitfalls and objections
“Meta-analysis is good enough”
Often it is, when sites are large and effects are consistent. The problem appears in exactly the studies where federation adds the most value: rare diseases, subgroups, and safety signals. Inverse-variance weighting of unstable local estimates can bias the pooled result, and sites with zero events in one arm contribute nothing without continuity corrections that introduce their own distortions.
“Federated regression leaks more information”
Intermediate gradients and Hessians do carry information, and with very small sites or saturated models they can reveal individual values. The response is controls, not avoidance: minimum cell sizes, limits on model complexity relative to site size, and automated checks on every iteration. These controls belong in the TRE, not in each researcher’s goodwill.
Misaligned model specifications
In meta-analysis, a site that silently uses a different reference category or a different covariate coding produces an estimate that looks valid and is wrong. Ship one versioned analysis package to every site, and verify that each site’s data conforms to the common model before running it.
Ignoring site effects in pooled models
Federated regression that treats all records as one population can hide systematic differences between sites. Include site indicators or random intercepts when sites differ in case mix, coding practice, or care pathways.
What to do next
Start with the analysis plan, not the platform. Write down the primary model, the expected number of events per site, and whether heterogeneity is an outcome you need to report. That determines the method. Then check the infrastructure against the method: can your environment deploy one versioned script to every site, harmonize variables to a common model, and check iterative outputs automatically? If it can, federated regression gives you pooled-quality estimates with no pooled data. If it cannot yet, a well-specified meta-analysis is a sound first step while the rest is built. For the architectural foundation, see Lifebit’s overview of the federated Trusted Research Environment.
Frequently asked questions
Does federated regression give exactly the same answer as pooling the data?
For linear regression, yes, because the summed cross-product matrices are sufficient statistics. For logistic, Poisson, and Cox models fitted iteratively, the federated estimate converges to the pooled estimate within numerical tolerance. One-shot approximation methods are close but not exact.
When is federated meta-analysis the better choice?
When every site is large, outcomes are common, sites cannot all respond in the same working window, or between-site variation is itself something you need to estimate and report. It is also simpler to review because each site releases only a few numbers.
Can intermediate results in federated regression identify individuals?
They can in edge cases, such as very small sites or models with many parameters relative to the sample. Minimum-count thresholds, limits on model complexity, and automated disclosure checks on each iteration reduce that risk to an acceptable level.
Do I need harmonized data for either method?
Yes. Both methods assume every site defines variables the same way. Mapping sites to a common data model such as OMOP before analysis is what allows one script to run everywhere and produce combinable results.
Is federated regression the same as federated learning?
No. Federated regression fits classical statistical models with interpretable coefficients and standard errors. Federated learning usually trains larger predictive models through repeated local training and parameter averaging. They can share the same infrastructure but serve different purposes.
How many iterations does a federated logistic regression usually need?
Newton-Raphson typically converges in a small number of iterations for well-specified models, often fewer than ten. Each iteration requires every site to return its local gradient and Hessian, so operational latency matters more than compute.
