Skip to content
AI360Xpert
Beta

Federated Learning in Healthcare

Hospitals cannot share scans, so federated learning trains one model from many sites by exchanging weight updates instead of patient images.

Hospitals train locally and a server averages their weight updates into one shared model without seeing scans
Hospitals train locally and a server averages their weight updates into one shared model without seeing scans

Why Does This Exist?

A single hospital rarely holds enough diverse scans to train a robust model, but privacy law and trust forbid pooling images centrally. A tumor model trained on one scanner fails on another. Federated learning exists to resolve the bind: data stays inside each hospital, only model updates travel, and a server builds the shared model from those updates. The product is collaboration without a central image lake.

For the model being trained see medical image analysis, and for scanner shift see domain adaptation for vision.

Think of It Like This

Cooks who share recipes, not kitchens

Four cooks cannot share kitchens, so each improves the same recipe at home and mails back only the changed lines. The editor merges the edits into one master recipe and mails it out again. No kitchen is ever photographed. The analogy stops at cooking: model updates can still leak information, so real deployments add clipping, noise, or secure aggregation.

How It Actually Works

A server broadcasts global weights ww. Each site kk trains locally for a few epochs to get wkw_k. The server aggregates with Federated Averaging: w=∑k(nk/n)wkw = \sum_k (n_k / n) w_k, where nkn_k is the site sample count and nn is the total. Here nk/nn_k / n is the influence of site kk. Rounds repeat for tens to hundreds of cycles. Non-IID data, where sites differ in scanners, protocols, and disease mix, slows convergence, so deployments track per-site metrics rather than one pooled number.

Worked example

Three hospitals hold 400, 300, and 300 scans. Their weights for one parameter are 0.50, 0.70, and 0.60. The average is (400×0.50+300×0.70+300×0.60)/1000=(200+210+180)/1000=0.59(400 \times 0.50 + 300 \times 0.70 + 300 \times 0.60) / 1000 = (200 + 210 + 180) / 1000 = 0.59. The largest site pulls hardest, which is correct when its data is representative and dangerous when it carries a scanner artifact, so the server also reviews per-site validation before accepting updates.

Code

This snippet is Federated Averaging in five lines.

import numpy as np

def fedavg(updates: list[np.ndarray], counts: list[int]) -> np.ndarray:    total = float(sum(counts))    agg = sum(w * (n / total) for w, n in zip(updates, counts))    return np.asarray(agg)

w = [np.array([0.5]), np.array([0.7]), np.array([0.6])]print(fedavg(w, [400, 300, 300]).tolist())  # -> [0.59]

Change the counts and the result follows the largest site. That weighting is the whole algorithm plus orchestration.

Watch Out For

One loud site poisons the average

A site with miscalibrated spacing or inverted labels contributes confident wrong gradients every round, and weighting by size amplifies it. The symptom is a global model that degrades after working well. Gate updates with per-site validation, clip update norms, and keep the ability to exclude a site without stopping the federation.

The Quick Version

  • Federated learning moves weight updates, not patient scans.
  • FedAvg weights each site by its sample count each round.
  • Data stays local, which satisfies governance but not all leakage risk.
  • Non-IID scanners and protocols slow convergence and need per-site tracking.
  • Pair averaging with update clipping, validation gates, and audit trails.