Project Extension

"I trained on four hospitals I was never allowed to visit. They sent me their lessons, never their patients, and one constraint at a time I learned to be trusted with the wards."

A Simulated Federation, Rehearsing for Hospitals It Has Never Seen

A case study read passively teaches the shape of a system; a case study rebuilt teaches the price of each promise it makes. The eight sections before this one walked federated medical AI as a finished artifact, naming the mechanism behind each constraint and the chapters that own it. This section inverts that posture. It gives you a staged construction plan in which you begin with a centralized baseline that no clinical setting would permit but every honest evaluation requires, then add one real-world constraint per stage, measuring what the constraint cost you before moving on. Each stage draws on a specific earlier section, so the project doubles as a guided tour back through the chapter and the book: when you average local models you are applying the FedAvg of Section 37.4 and Chapter 14, when you add the proximal term you are applying Section 37.5, when you clip and add noise you are applying the differential privacy of Section 37.3 and Chapter 35, and when you mask the updates you are applying the secure aggregation of Section 37.6. The discipline that makes the project worth its time is the one Section 1.1 opened with: add a constraint only when the setting forces it, and prove with a number what it cost.

1. The Centralized Baseline You Are Not Allowed to Ship Beginner

Every honest federated project begins, paradoxically, with the centralized model it exists to avoid. The reason is measurement, not deviance. The centralized model, trained on all sites' data pooled in one place, is the statistical upper bound: it is what you could achieve if privacy and data-residency law did not exist, and every federated number you later report is a gap below it. Without that reference you cannot say whether your federation lost half a point of AUROC to the constraints or ten. So your first artifact is a single process that pools a public medical-style dataset, trains one classifier, and records its global AUROC, its accuracy, and, critically, its accuracy on each cohort you will later split into separate hospitals. You build it knowing you will never deploy it, because in a real clinical setting the pooling step in line one is precisely the thing the law forbids.

The code below is that baseline and its first scale-out move compressed to one dependency-light file. It builds a synthetic two-class dataset, induces non-IID skew by giving each virtual hospital a contiguous slice of the score-ordered data so that disease prevalence ranges from rare to common across sites, trains the pooled baseline, then trains the same model with FedAvg in which each site optimizes only its own records and the server averages the weights (Section 37.4). It reports the federated global AUROC against the pooled baseline and, because skew is the villain of this chapter, the per-site accuracy disparity that motivates every later stage.

import numpy as np

rng = np.random.default_rng(7)
N, d, K = 6000, 12, 4          # examples, features, virtual hospitals
w_star = rng.standard_normal(d)
X = rng.standard_normal((N, d))
logits = X @ w_star
p = 1.0 / (1.0 + np.exp(-logits))
y = (rng.random(N) < p).astype(float)

# Induce non-IID skew: sort by score, give each site a contiguous slice so the
# positive-class prevalence differs sharply from one virtual hospital to the next.
order = np.argsort(logits)
shards = np.array_split(order, K)

def sigmoid(z):
    return 1.0 / (1.0 + np.exp(-z))

def fit(Xs, ys, w0, epochs=200, lr=0.5):   # local logistic-regression training
    w = w0.copy(); n = len(ys)
    for _ in range(epochs):
        g = Xs.T @ (sigmoid(Xs @ w) - ys) / n
        w -= lr * g
    return w

def auroc(scores, labels):                 # rank-based AUROC, no sklearn
    o = np.argsort(scores); ranks = np.empty(len(scores))
    ranks[o] = np.arange(1, len(scores) + 1)
    pos = labels == 1; npos = pos.sum(); nneg = len(labels) - npos
    return (ranks[pos].sum() - npos * (npos + 1) / 2) / (npos * nneg)

def acc(scores, labels):
    return float(((scores > 0.5) == (labels == 1)).mean())

# Pooled (centralized) baseline: one machine sees all data. The upper bound.
w_pool = fit(X, y, np.zeros(d)); s_pool = sigmoid(X @ w_pool)

# FedAvg: each site trains locally on ITS shard, the server averages weights
# (size-weighted), broadcasts, repeats. Data never leaves the site.
w_glob = np.zeros(d)
for rnd in range(15):                       # 15 communication rounds
    locals_ = [fit(X[s], y[s], w_glob, epochs=20) for s in shards]
    sizes = np.array([len(s) for s in shards], float)
    w_glob = np.average(locals_, axis=0, weights=sizes / sizes.sum())
s_fed = sigmoid(X @ w_glob)
site_acc = [acc(sigmoid(X[s] @ w_glob), y[s]) for s in shards]

print("sites K                :", K)
print("site pos-prevalence    :", [f"{y[s].mean():.2f}" for s in shards])
print("pooled  AUROC / acc    :", f"{auroc(s_pool, y):.4f} / {acc(s_pool, y):.4f}")
print("FedAvg  AUROC / acc    :", f"{auroc(s_fed, y):.4f} / {acc(s_fed, y):.4f}")
print("AUROC gap (pool-fed)   :", f"{auroc(s_pool, y) - auroc(s_fed, y):.4f}")
print("per-site acc           :", [f"{a:.3f}" for a in site_acc])
print("per-site disparity     :", f"{max(site_acc) - min(site_acc):.4f}")

sites K                : 4
site pos-prevalence    : ['0.08', '0.33', '0.63', '0.93']
pooled  AUROC / acc    : 0.8752 / 0.7865
FedAvg  AUROC / acc    : 0.8752 / 0.7858
AUROC gap (pool-fed)   : 0.0000
per-site acc           : ['0.916', '0.665', '0.633', '0.930']
per-site disparity     : 0.2973

2. Staging the Constraints, Milestone by Milestone Intermediate

With the baseline in hand, you add the real-world constraints one stage at a time, in the order of Figure 37.9.1, never advancing until the current stage hits its milestone. The discipline of one-constraint-at-a-time matters because each constraint trades accuracy for something else (fairness, privacy, confidentiality, safety), and isolating it lets you price that trade exactly: when AUROC drops or disparity moves, exactly one thing changed and you know which section's mechanism to credit or blame. Table 37.9.1 is the project plan. Each row names the stage, the real-world pressure that forces it, the section that supplies the mechanism, and the measurable milestone that tells you the stage is done.

The milestones are quantitative on purpose. "Added privacy" is not a milestone; "the model trains to within a stated accuracy under a measured privacy budget of $\varepsilon \le 8$" is. Stages 1 and 2 are accuracy-and-fairness stages, judged against the centralized upper bound and the per-site disparity of Output 37.9.1. Stage 3 is the privacy stage, where clipping each site's update to a norm bound and adding calibrated Gaussian noise (Section 37.3) spends a quantifiable privacy budget that the milestone caps. Stage 4 is the confidentiality stage, where secure aggregation (Section 37.6) lets the server learn the summed update while learning nothing about any single site's term. Stage 5 is the operations stage, where per-site monitoring (Section 37.7) must catch a deliberately injected distribution shift at one hospital. Stage 6 closes the loop with the release gate of Section 37.8: a model that fails a fairness floor or a calibration check is blocked before it ever reaches a ward, no matter how strong its aggregate AUROC.

3. The Numbers Your Project Must Hit Intermediate

A federated medical project lives or dies by whether its milestones are targets you compute rather than feelings, so each stage gets a number defined in advance. The accuracy milestone is a gap below the centralized upper bound: with pooled ranking quality $\text{AUROC}_{\text{pool}}$ and federated quality $\text{AUROC}_{\text{fed}}$, you require

which Output 37.9.1 already meets at a gap of $0.000$ for FedAvg. The fairness milestone is a cap on the spread of a per-site metric. Writing $a_k$ for the global model's accuracy (or sensitivity) at site $k$, the disparity is

and the Stage-2 target is to cut the baseline $\Delta = 0.297$ by at least a third, which is what the FedProx proximal term of Section 37.5 buys by keeping each site's local solution close to the shared model. The privacy milestone is an explicit budget: a run satisfies $(\varepsilon, \delta)$-differential privacy when, for adjacent datasets differing in one patient and any output set $S$,

and your milestone fixes a $\delta$ (commonly $\delta \approx 1/N$) and caps $\varepsilon \le 8$, the loose-but-defensible range Section 37.3 and Chapter 35 discuss. Finally, the cost you trade all of this against is communication, and for synchronous FedAvg it is essentially

that is, the number of rounds $R$ times the number of sites $K$ times twice the model size $|\theta|$ (download the global model, upload the local one). This single product is why the chapter cares so much about rounds: differential privacy and FedProx both tend to need more rounds $R$ to reach the same accuracy, so each privacy or fairness gain shows up directly as more bytes on the wire. Compute these four targets before you build, so each milestone is a prediction you test rather than a result you rationalize.

# pip install "flwr[simulation]"
import flwr as fl

# A client wraps ONE virtual hospital; train()/evaluate() touch only its shard.
class Hospital(fl.client.NumPyClient):
    def get_parameters(self, config): ...
    def fit(self, params, config):      # local epochs on THIS site's data only
        ...
        return new_params, num_examples, {}
    def evaluate(self, params, config):
        ...
        return loss, num_examples, {"auroc": site_auroc}

strategy = fl.server.strategy.FedProx(proximal_mu=0.1)   # swap FedAvg -> FedProx
fl.simulation.start_simulation(                          # K clients, one machine
    client_fn=lambda cid: Hospital(cid),
    num_clients=4, config=fl.server.ServerConfig(num_rounds=15), strategy=strategy)

4. Extension Challenges Worth the Federation Advanced

Once the six stages hit their milestones you have a working privacy-preserving federation, and the project becomes a platform for the harder questions the chapter only gestured at. Each extension below adds one capability that a real cross-hospital deployment needs, and each reaches into a different part of the book, so finishing them turns the capstone from a pipeline into a system. Add SCAFFOLD, the control-variate method that corrects the client-drift FedProx only dampens, and measure how many fewer communication rounds $R$ it needs to reach the same disparity target, which shows up directly in the communication cost $C = R \times K \times 2|\theta|$. Personalize per site by splitting the model into a shared backbone and a site-local head, then quantify how much of the $0.297$ disparity in Output 37.9.1 a per-site head removes that a single global model cannot, the natural answer to the aggregate-passes-while-a-site-fails problem of Stage 1.

Two further extensions test the federation against an adversary rather than mere heterogeneity, and they connect the project to the reliability material of Part VII. Introduce a Byzantine site that sends corrupted or poisoned updates, then defend the aggregation with a robust rule (coordinate-wise median, trimmed mean, or Krum) in place of the plain weighted average, and measure how much corruption the defended federation tolerates before its AUROC collapses, the robust-aggregation idea from Chapter 35. Then compose the defenses: run robust aggregation under secure aggregation and differential privacy at once, and report the combined cost, because in a real federation these constraints are not optional alternatives but simultaneous requirements. Each extension is a small, bounded change to a working system, which is exactly the posture in which distributed-systems concepts are learned best: against a baseline you can measure, in a federation you already understand.

5. Chapter Summary and What You Built Beginner

This section closes Chapter 37, so it is worth stating the through-line the whole chapter built. We began with the problem definition (Section 37.1): train a clinically useful model across hospitals that may not move their patient data, under privacy, heterogeneity, and safety constraints that a centralized project never faces. From there the chapter walked the federation constraint by constraint, and every constraint was the same move applied to a different requirement: distribute the training while pinning the data, then pay a measured price to keep the result private, fair, confidential, and safe. The multi-hospital data setting (Section 37.2) established the non-IID reality that makes a single global model insufficient, and the privacy constraints (Section 37.3) established why raw updates cannot be shared in the clear. The federated learning setup (Section 37.4) applied the FedAvg of Chapter 14 to train without moving data, and the data-heterogeneity treatment (Section 37.5) added FedProx to keep skewed sites from pulling the shared model apart. Secure aggregation (Section 37.6) hid each site's update from the server, monitoring across sites (Section 37.7) watched for the drift that federation makes invisible by default, and safety and responsibility (Section 37.8) gated the release on fairness and calibration, not aggregate accuracy alone. The chapter is, end to end, one distributed system that distributes the training and the intelligence while the data stays exactly where it was collected.