Federated Analytics vs Federated Learning: The Difference
Quick answer
Federated analytics runs SQL-style descriptive and statistical queries — counts, cohort definitions, prevalence, summary statistics — across distributed datasets and returns aggregate results. Federated learning trains machine-learning models across the same distributed datasets and returns updated model weights. Both keep raw records at the custodian; data never leaves the source.
Federated analytics and federated learning are often conflated in vendor decks and procurement documents — but they are architecturally distinct workloads with different inputs, outputs, latency profiles and regulatory implications. Both belong to the broader Federation pattern in which compute moves to data. A biobank that has approved a federated analytics platform has not approved federated model training, and a ministry of health procuring federated learning has not necessarily procured the analytics layer beneath it.
Why this distinction matters now
Two pressures have pushed both patterns into procurement conversations in 2026. The European Health Data Space (EHDS), entering staged application from March 2025 through 2029, requires secondary use of health data to occur in secure processing environments where the data holder retains control of the source records — a constraint that maps onto either federated pattern but eliminates raw export. In parallel, the May 2026 UK Biobank incident — in which approved researchers walked derived data out via a centralised software-as-a-service Trusted Research Environment’s (TRE) normal export workflow — has accelerated scrutiny of any architecture in which sensitive cohorts leave their custodian.
Procurement teams now ask a sharper question: what workload, exactly, am I federating? A federated TRE that supports cohort discovery and summary statistics is not automatically a federated learning platform, and vice versa.
The technical disambiguation
Federated analytics: distributed queries, aggregate answers
Federated analytics is the distributed evolution of the database query. A researcher writes a query — typically SQL, an Observational Medical Outcomes Partnership (OMOP) cohort definition, or a domain-specific language — and a coordinator dispatches it to each participating node. Each node executes the query against its local data, returns an aggregate result (a count, a mean, a histogram bin, a Kaplan-Meier curve), and the coordinator combines those into a single answer. Raw records are never transmitted. Latency is seconds to minutes for descriptive queries, minutes to hours for complex multi-cohort joins.
Typical outputs include cohort size estimates, prevalence and incidence rates, comparative effectiveness summaries, and feasibility assessments for downstream trials. The OHDSI consortium’s network studies — running OMOP cohort definitions across more than a hundred databases globally — are the canonical published example of federated analytics at scale.
Federated learning: distributed training, shared model
Federated learning is the distributed evolution of model training. Rather than a query, the coordinator dispatches a model — initial weights, an architecture and a training recipe. Each node trains on its local data for a defined number of epochs, then returns weight updates (gradients or parameter deltas). The coordinator aggregates those updates, typically via federated averaging (FedAvg) or one of its variants, produces a new global model, and the cycle repeats until convergence. The output is a trained model that has, in effect, seen every node’s data without any node’s data having been moved.
Latency is fundamentally different: training a clinically useful model across distributed nodes typically takes days to weeks. Outputs include disease-risk models, imaging classifiers, NLP models trained on multi-site clinical notes, and increasingly the foundation models that ministries of health are exploring for sovereign clinical AI.
Side-by-side: federated analytics vs federated learning
| Dimension | Federated analytics | Federated learning |
|---|---|---|
| Input dispatched to nodes | A query (SQL, OMOP cohort definition, statistical script) | A model (architecture, initial weights, training recipe) |
| Output returned from nodes | Aggregate statistics (counts, means, histograms, survival curves) | Model weight updates (gradients, parameter deltas) |
| Computation type | Descriptive and inferential statistics, set operations, joins | Iterative gradient-based optimisation |
| Communication rounds | Typically one (query out, result in) | Tens to thousands (per training round) |
| Latency | Seconds to hours | Hours to weeks |
| Primary use cases | Cohort discovery, feasibility, prevalence studies, real-world evidence, comparative effectiveness | Disease-risk models, imaging classifiers, foundation models, predictive analytics |
| Disclosure-control risk | Small-cell counts, query stacking attacks | Gradient inversion, membership inference, model memorisation |
| Regulatory fit | Strong fit for EHDS secondary use, GDPR Article 89, NHS Federated Data Platform feasibility queries | Strong fit for MHRA/EMA/FDA model-development guidance, OECD AI principles, sovereign-AI national strategies |
| Typical governance artefact | Query log, output airlock review, small-cell suppression policy | Model card, training audit trail, gradient-aggregation protocol, privacy budget |
| What the custodian approves | Permitted query templates and aggregation thresholds | Permitted model architectures, training budgets, output disclosure controls |
A worked example: cohort discovery versus model training
Consider a multi-country oncology study spanning Genomics England’s 500K Genome Project, CanPath’s pan-Canadian cohort and Singapore Synapxe’s national health data network. The research question is whether a polygenic risk score combined with longitudinal electronic-health-record (EHR) features can predict five-year colorectal-cancer recurrence.
The workflow splits into two federated workloads. Step one is federated analytics. The researcher dispatches an OMOP cohort definition — adults aged 45–75, incident colorectal-cancer diagnosis 2015–2022, at least three years of follow-up, available germline sequencing. Each node returns cohort size, demographic distribution, missingness profile and a Kaplan-Meier recurrence curve. Within minutes the researcher learns the pooled effective sample is 47,000 patients, follow-up is markedly shorter in Singapore, and two EHR features are missing in over 40% of the Canadian arm. No underlying records have moved.
Only after this feasibility step does step two — federated learning — begin. The researcher dispatches a gradient-boosted survival model with a standardised feature schema and a defined privacy budget. Training runs over several weeks of communication rounds. Each node trains locally and returns weight updates; the coordinator aggregates. The output is a single recurrence-prediction model whose performance can be benchmarked at each node without that node’s records being seen centrally. The Federation pattern (US patent 12,519,781) underwrites both steps: compute moves to data in both cases, but the payload and cadence differ entirely.
Adjacent context: Owkin’s federated learning work — including the MELLODDY consortium with ten pharmaceutical companies and published collaborations with Centre Léon Bérard and Institut Curie — is the most-cited industry reference point for this kind of workload. Owkin demonstrated that clinically useful oncology models can be trained across hospital partners without raw data export. What that work typically does not foreground is the federated analytics layer beneath: every meaningful federated learning project begins with a federated feasibility query, because no team trains a multi-week distributed model on a cohort whose size and quality it has not first verified.
Where the two patterns share infrastructure — and where they diverge
Shared infrastructure
Where they diverge
The divergence is in the airlock policy. A federated analytics output is a small object — a number, a vector, a curve — and the airlock applies small-cell suppression, k-anonymity thresholds and query-stacking detection. A federated learning output is a high-dimensional weight update that can, under known attacks (gradient inversion, membership inference), leak information about individual training examples. The airlock for federated learning must apply differential privacy noise, gradient clipping, secure aggregation and formal privacy budgets accounted across training rounds. A platform that has implemented one airlock has not implemented the other.
Practical next steps for procurement and architecture teams
Three checks separate platforms that genuinely support both workloads from those that support one and claim the other. First, ask the vendor to demonstrate a multi-node OMOP cohort query and a multi-node training run on the same deployment, with full audit logs. Second, ask to see the airlock policy: small-cell rules for analytics and differential-privacy parameters for learning should be distinct, named, version-controlled artefacts. Third, ask which workload the named references run in production — Genomics England, CanPath, Singapore Synapxe, NIH NLM, Boehringer Ingelheim and the Danish National Genome Center are public deployments where the mix can be verified through published outputs.
The heuristic is simpler still: federated analytics answers questions about your data; federated learning produces models trained on it. You almost always need both, procured as distinct capabilities.
Frequently asked questions
Is federated learning a type of federated analytics?
No. They are sibling workloads under the broader Federation pattern. Both move compute to data, but federated analytics dispatches queries and returns aggregate statistics, while federated learning dispatches models and returns weight updates. A platform supporting one does not automatically support the other.
Which is more privacy-preserving by default?
Federated analytics has a smaller and better-understood disclosure surface because outputs are typically aggregate statistics protected by small-cell suppression and k-anonymity. Federated learning outputs are high-dimensional weight updates vulnerable to gradient-inversion and membership-inference attacks unless the airlock applies differential privacy, gradient clipping and secure aggregation. Neither is automatically safer — the airlock policy determines the actual risk.
Can both run on the same federated TRE?
Yes, and they should. A federated Trusted Research Environment deployed at the data custodian provides the shared fabric — identity, harmonisation, audit, output airlock — that both workloads need. The workload-specific machinery (query engines for analytics, training orchestrators and privacy accountants for learning) sits on top of that fabric.
Does federated analytics need a harmonised data model?
For meaningful multi-site queries, yes. OMOP Common Data Model v5.4 is the predominant harmonisation target for EHR-derived federated analytics. Without harmonisation, a cohort query returns answers that cannot be compared across nodes because the same concept is represented differently at each site.
How does federated learning relate to sovereign AI strategies?
Federated learning is the architectural mechanism that lets ministries of health and national biobanks train clinically useful AI models on their own population’s data without exporting that data to a foreign cloud. It is the operational answer to sovereign AI requirements articulated in EHDS, OECD AI principles and national digital-health strategies from Singapore to Canada to the United Kingdom.
What is the regulatory anchor for federated analytics in Europe?
The European Health Data Space Regulation, GDPR Article 89 (processing for research purposes), and national implementations of the Five Safes framework. EHDS in particular mandates that secondary use of health data occurs in secure processing environments where the data holder retains control of the source records — a constraint federated analytics satisfies natively.
If I already run federated analytics, what do I need to add for federated learning?
A training orchestrator that handles model dispatch and weight aggregation, a differential-privacy accountant that tracks the privacy budget across training rounds, an updated airlock policy covering gradient and weight-update disclosure, and governance artefacts — model cards, training audit trails, approved architectures — that the custodian’s data access committee can review. The underlying federated TRE, harmonisation layer and identity fabric typically remain unchanged.