Federated Learning in Pathology

Training one model across several hospitals by moving the model to the data instead of the data to the model — the standard answer to the multi-institution problem, and one that trades a governance cost for an engineering one rather than removing it.

Training one model across several hospitals by moving the model to the data instead of the data to the model — the standard answer to the multi-institution problem, and one that trades a governance cost for an engineering one rather than removing it.

What it is

Every institution has too few cases and cannot send its slides anywhere. Federated learning is the architectural answer: each site trains locally on its own data, and only model weights or gradients are exchanged with a coordinating server, which averages them into a shared model. No slide and no patient record leaves the hospital.

That is the pitch, and it is a real one. Two things about it are less often said.

It does not remove the governance problem, it relocates it. A data-sharing agreement is still needed — for model exchange rather than image exchange — and someone still has to be satisfied that weights trained on identifiable data are not themselves disclosive. What changes is that the conversation is about a smaller and more defensible object, not that there is no conversation.

It is an engineering commitment at every site, not just yours. Each participating hospital needs compute, a maintained environment, and someone to keep it running for the duration. The sites that most need to be in a study — small ones, ones with unusual case mix — are the ones least able to carry that.

The technical problem that makes it hard is the same one this wiki keeps meeting

Federated averaging assumes each site’s data is roughly a sample from the same distribution. In pathology it is emphatically not: sites differ in scanner, stain protocol, case mix and population. This is the non-IID problem, and it is Scanner and Stain Variability wearing different clothes. A naively averaged model can be worse than any of the local models it was built from.

So the interesting federated pathology work is mostly about that, and it splits into recognisable strategies: harmonising appearance before training (federated stain normalisation), transferring style between sites so each sees a wider distribution, or changing what is exchanged altogether — one MICCAI 2025 entry sends distilled synthetic data rather than weights.

Entry points

These are pointers taken from Awesome-AI4DigitalPathology, not appraisals — none has been read here, and nothing in this page claims a result from any of them. They are recorded because knowing where a line of work starts is most of the cost of entering it.

• HistoFL — federated WSI classification and survival prediction, from the Mahmood Lab, and the most-cited starting point. Paper · Code
• FLamby — a cross-silo federated benchmark, including FedCamelyon16; the natural place to test a method before proposing a real collaboration. Paper · Code
• HistoFS — non-IID WSI classification via federated style transfer, CVPR 2025. Paper · Code
• FedStain / BottleGAN — federated stain normalisation, which is the direct federated analogue of Stain Normalisation. Paper · Code
• PathFL — federated segmentation across centres, Med Image Anal 2025. Paper · Code
• FedWSIDD — federated WSI classification by dataset distillation, MICCAI 2025: exchange synthetic data rather than weights. Paper
• Two independent reviews exist, in Journal of Medical Imaging 12(6) and in a 2024 Elsevier review, which is the cheapest way in for someone deciding whether to bother.

Why it matters for my work

It is the named answer to this wiki’s second-largest recorded gap. wiki/index.md records that no project here has an external test set, and External Validation is the page that keeps turning up in Open Questions across the estate. PinkKidney is explicitly one external cohort away from a publishable claim. Federated learning is the standard route to a multi-institution result when the slides cannot move — so it belongs in the same conversation as AIDA Data Hub, and the two are genuinely different options rather than competitors:

Route	What it costs	What you get
AIDA Data Hub	A PhD-holding applicant and an institutional signature	Someone else’s annotated cohort, immediately, no partner needed
Federated learning	A partner institution, compute at each site, and a sustained engineering commitment	A model trained on your case mix and theirs, and a genuinely multi-centre claim

The honest reading for this group today is that the AIDA route is far cheaper and should be exhausted first. Federated learning is what the question becomes after someone wants a multi-centre model rather than a multi-centre test.

A local precedent already exists in miniature. PinkKidney spans three scanners and has tooling to detect and correct the resulting batch structure — batch_effect_prescreen.py, ComBat correction, a validated synthetic two-site test. That is the non-IID problem at within-institution scale, and the same machinery is what a federated setup would need pointed across sites instead of scanners. Whether three scanners in one department is a useful rehearsal for three hospitals is untested but cheap to think about.

How it connects

External Validation — the gap this addresses, and the reason the topic is here at all.

Scanner and Stain Variability — the non-IID problem is this page’s phenomenon distributed across institutions; it is what makes federated averaging hard rather than routine.

AIDA Data Hub — the cheaper alternative for getting an outside cohort, and the one to try first.

PinkKidney — the local multi-scanner precedent, with batch-effect tooling already built.

Stain Normalisation — federated variants exist precisely because harmonising appearance is a precondition for averaging models across sites.

De-identification — the governance conversation does not disappear, it changes object. What can be inferred from shared weights is a different question from what can be inferred from shared slides, and this wiki has no page on it.

Coverage Bias — sites that cannot afford to participate are missing from the federation, and their absence is patterned rather than random.

Open questions

• Does anyone here want a multi-centre model, as opposed to a multi-centre test set? These need completely different things, and nothing in this wiki records which is wanted. Until that is answered this page is background reading.
• Is there a plausible partner institution? Federated learning has a hard prerequisite that no amount of engineering removes.
• What can actually be inferred from shared model weights, and would an institutional office here accept the argument? Unexamined, and it is the question that decides feasibility. [unverified]
• Would FLamby’s FedCamelyon16 be a worthwhile afternoon — enough to know whether the machinery is tolerable before any real conversation? It needs no partner and no patient data.
• Is PinkKidney’s three-scanner batch structure a usable rehearsal for cross-site non-IID? Untested.