médical IA

Training a patient-record model without ever pooling the data: federated learning tested on 122,251 ICU stays

Published on August 11, 2026 · 12 min read

Michael Burkhart, Brett Beaulieu-Jones, and colleagues test a concrete question: can you train a patient-record "foundation model" without ever gathering several hospitals' data in one place? Across 122,251 ICU stays from three independent health systems and twelve prediction tasks, their generative event models transfer far better between hospitals than conventional models (a 0.025-point AUC penalty versus 0.079), and federated learning nearly matches centralized training. But the most useful finding is counterintuitive: pooling the data yields only a modest gain over purely local training, and that advantage fades as each hospital accumulates its own data.

The context

A patient-record foundation model is a model pretrained on vast amounts of health data, meant to produce reusable representations for many clinical tasks — predicting deterioration, mortality, readmission — without starting from scratch each time. Borrowed from the success of large language models, the idea runs into two well-known obstacles in healthcare.

The first is data siloing. Patient records live in separate hospital information systems, protected by medical confidentiality and strict regulation (GDPR in Europe, HIPAA in the United States). Physically pooling several hospitals' data to train a single model is legally heavy, sometimes impossible. The second is performance drop on transfer: a model trained in one hospital often works markedly worse in another, because populations, coding habits, equipment, and prescribing practices differ. This is the population-bias failure mode, ubiquitous in health AI.

Federated learning offers an elegant way out: instead of moving the data to the model, you move the model to the data. Each hospital trains locally, then shares only the learned parameters — never the records themselves. A central server aggregates these updates and returns an improved model. The promise is twofold: benefit from the combined size of several centers while keeping data at home. The question is whether it truly works, and above all whether it is worth the trouble. That is exactly what this work puts to the test.

The method

The authors assemble 122,251 ICU stays from three independent health systems, harmonized to the Common Longitudinal ICU Data Format (CLIF), a shared format maintained by an academic critical-care consortium. This harmonization is the precondition: without a shared vocabulary, comparing hospitals is like comparing different languages.

The core of the approach is the generative event model (GEM). The principle: a patient's history is broken into a sequence of "tokens" — each lab test, each medication, each vital sign becomes a discrete symbol, exactly as text is broken into words. The model then learns, language-model style, to predict the next event from the previous ones. By learning to "narrate" a patient's trajectory, it builds internal representations that can then be plugged into specific tasks. Here, twelve post-24-hour prediction tasks: using a stay's first 24 hours to anticipate later events or outcomes.

The experimental trick is the comparison of four training regimes, a genuine matrix. Within-site: train and test in the same hospital (the reference). Cross-site: train in one hospital and test in another — a direct measure of transportability. Centralized: pool all data as if barriers did not exist (the theoretical ceiling). Federated: train without ever pooling the data, via two classic algorithms — FedAvg (Federated Averaging: each site trains locally, the server averages the weights, and the cycle repeats over several "communication rounds") and FedAvgM, its variant with server-side momentum to stabilize aggregation.

The comparator is LightGBM, a gradient-boosted decision-tree model — the solid, hard-to-beat baseline for clinical tabular data. Performance is reported in ROC-AUC (area under the ROC curve: the probability the model ranks a positive case above a negative one) and PR-AUC (area under the precision-recall curve), the latter being more honest when the event to predict is rare — as most serious ICU outcomes are.

The results

First finding: the generative event models achieve the highest mean ROC-AUC, both within-site and cross-site. Above all, they are far more transportable. When you move the model from one hospital to another, its performance drops — the "cross-site penalty." For the GEM, that mean penalty is 0.025 ROC-AUC and 0.027 PR-AUC; for LightGBM it climbs to 0.079 and 0.089. In other words, the boosted tree loses roughly three times more when changing institutions. The generative model handles the relocation far better.

Second finding: federated learning works. FedAvg and FedAvgM approach the performance of centralized training — the one that sees all the data — and most of the gains are captured within 5 to 10 communication rounds, making the procedure cheap in network exchange. You thus get almost the benefit of pooling without ever moving data out of the hospital.

Third finding, the most interesting: this pooling benefit is modest. Centralized multi-site training is only slightly better than purely local training. And its advantage concentrates where you would expect — when a hospital has little local data — then shrinks as it accumulates its own records. Honest clinical translation: for a large center that already has tens of thousands of stays, fetching the neighbors' data would add almost nothing. The measurement difficulty is worth flagging: a 0.025-point AUC penalty is small, but its real impact — how many patients better or worse classified — depends entirely on the task and the event's frequency, two things the abstract does not break out.

What is good

A matrix experimental design, rare and clean. Explicitly comparing within-site, cross-site, centralized, and federated isolates what each piece contributes — transportability on one side, the pooling gain on the other. Many papers merely announce "federated works"; this one takes apart the mechanism and says where the benefit is, and where it is not.

A quantified, specific transportability. The 0.025-versus-0.079 result is not vague praise: it is a direct measure, on real data, of robustness to changing hospitals. Showing that a tokenized generative model transfers three times better than a solid boosted tree is a concrete contribution, useful to anyone who must deploy a model beyond its home center.

The honesty of a negative result. Against the prevailing mood ("more data is always better"), the authors publish that pooling helps only modestly, and less and less. Naming the real bottleneck — learning genuinely transportable representations — rather than overselling the federated apparatus is exactly the stance one expects from serious work.

What is less good

A thin practical benefit for a heavy apparatus. Federated learning is technically appealing, but if the multi-site advantage is small and fades with local accumulation, the cost/benefit of the whole infrastructure (coordination, communication rounds, cross-hospital governance) becomes questionable for large centers. The paper shows this honestly, but the consequence — federated learning mainly helps small institutions — sharply tempers the enthusiasm.

The core problem stays open. The cross-site penalty is not zero, and the authors themselves name the real challenge: producing representations that transport across heterogeneous systems. This is unresolved population bias. As long as moving a model costs performance, the promise of a universal patient-record foundation model remains a direction, not an achievement.

A deliberately narrow scope, and a privacy claim asserted but not stress-tested. The study is retrospective, limited to ICU care, to three systems, and to purely ML metrics (ROC-AUC, PR-AUC) with no clinical translation — no calibration, no net benefit, no number-needed-to-treat, no prospective bedside test. Finally, the federated privacy argument is presented as a given: yet "the data does not move" does not mean "nothing leaks." Shared parameters can, in some cases, leak information about patients (inference attacks, gradient leakage). The paper does not tackle this front, which must be addressed before any deployment.

What it changes

For the research community, this work shifts the right question. We no longer only ask "can we train without pooling the data?" — the answer is yes, and at low network cost — but "can we learn representations that genuinely transport from one system to another?" The tokenized generative model, paired with federation, becomes a credible building block for that research, with a reusable comparator and evaluation matrix.

For clinicians and data governance, the message is indirect but strong: it is possible to capture most of the benefit of a multi-center model without ever centralizing records. That is a serious argument for regulatory compliance and hospital data sovereignty. Nothing is deployable at the bedside today, but the direction matters for the IT departments and ethics committees that arbitrate these choices.

For patients and the public, two takeaways. First, your ICU data can help improve models without leaving the hospital where you are treated — a concrete answer to fears about sharing. Second, the intuition "the more hospitals share, the better" needs nuance: beyond a certain local volume, other centers' contribution becomes marginal. Raw size is not everything; what counts is a model's ability to stay good when you move it to a new context.