Federated learning

In one line

Federated learning inverts the usual pipeline: instead of pooling sensitive data centrally, each site trains locally and shares only model updates, which a coordinator averages into a global model.

The problem it solves

The best medical AI needs lots of diverse data — but the data sits in separate hospitals that, rightly, can't pool patient records: privacy law, data-sharing agreements, and trust all block it. Federated learning resolves the tension: the model goes to the data instead of the data coming to the model. Each site keeps its records; only what the model learned is shared.

How a training round works

1. The server sends the current model weights to each participating site.
2. Each site trains a few steps on its own local data.
3. Sites return their weight updates (not data) to the server.
4. The server aggregates them — classically by averaging (FedAvg) — and repeats.

Over many rounds, the global model improves as if it had seen everyone's data — without anyone exposing a record.

The refinements that make it real

The basic loop leaks more than you'd think, so production systems add:

• Secure aggregation — the server combines updates without being able to inspect any single site's contribution.
• Differential privacy noise — guards against reconstructing training examples from the updates.
• Non-IID handling — every hospital's case mix is different (the central practical challenge); naïve averaging can stall or skew, so weighting and personalisation help.

Privacy is an architecture, not a guarantee

The crucial caveat: federated learning reduces data exposure but isn't private by itself — updates can leak information without the protections above. It's a privacy architecture to be combined with DP, encryption, governance and consent — not a checkbox.

Where it shows up in digital health

• Multi-hospital imaging models where data-sharing agreements are impossible.
• Rare-disease research that needs cases pooled across borders.
• On-device models trained across phones/wearables without uploading raw signals.
• For India-scale, multi-institution research under DPDP, this pattern is one to watch.

Common pitfalls

• Assuming it's automatically private — add secure aggregation + DP, or updates can leak.
• Ignoring non-IID skew — different case mixes can degrade or bias the global model.
• Underestimating the engineering — orchestration, stragglers, and version drift across sites are real operational costs.

Key takeaways

• Federated learning trains a shared model by exchanging updates, not data.
• A round = distribute weights → local train → return updates → aggregate (FedAvg) → repeat.
• It's a privacy architecture — pair with differential privacy, secure aggregation, governance.
• Ideal where data can't move but a shared model is valuable (imaging, rare disease, devices).