Federated Learning’s Hidden Prerequisite

Digital. Clean. Curated. De-identified. The part nobody budgets for.

Federated learning is an elegant answer that was proposed to address privacy concerns with the health data sharing problem. The technical concept is clean: keep the patient data inside each hospital, train models locally, and share only what the model learned. If hospitals can’t trust a third party with raw patient records — and there are enough cautionary tales to know that caution is common sense, not paranoia — then don’t ask them to. As a response to the politics and ethics of health data privacy, federated learning is the right answer.

So why, after more than a decade, are so few federated learning projects making it into real clinical settings? A recent systematic review of 612 healthcare federated learning studies found that only 5.2% reported real-world application. If you’ve ever tried to stand one of these systems up in practice, the answer is probably familiar.

Federated learning doesn’t eliminate the work of preparing healthcare data. It distributes that work to every participating institution. That’s the prerequisite hiding in plain sight.

Let me walk through what that means, because the gap isn’t theoretical. I’ve spent years on the wrong side of it.

Mayo Clinic Platform_Connect is one one of the most credible federated learning deployments, with partners that now span four continents. Look closely at who those partners are, though, and a pattern jumps out: they are all major institutions, each with serious data infrastructure already in place. That isn’t incidental to the network’s success — it’s the price of admission.

In a post on the Mayo Clinic Platform website, John Halamka describes the requirement plainly: “Each partner in Connect brings its own collection of clean, curated, de-identified data.”

Do read that sentence twice.

Federated learning is often discussed as a solution to the privacy concerns of health data sharing. What gets less attention is what participating institutions are expected to bring before collaboration can even begin. Before a hospital can contribute to, or benefit from, a federated network, it first has to produce the very thing healthcare has struggled with for decades: data that is clean, curated, de-identified and usable.

So who pays to create it?

That’s not a rhetorical question. Curating data to that standard takes engineering staff, clinical informaticists, a common data model mapped from source systems, and governance that doesn’t lapse the moment funding ends. It’s months of work at best, years in practice.

And notice which organizations are least likely to meet those requirements: rural hospitals, district clinics, and under-resourced health systems — the very institutions whose participation is needed to build more representative models that work in the real world.

Harmonization is the work, not the setup

I spent years building health data platforms and shipping AI products, and the hardest part was never the model. It was the data modeling — deciding what a concept actually meant before any algorithm could reason over it. That sounds abstract until you live it. At one site, “admission date” meant the moment a bed was assigned; at another, it meant when the order was placed. Medication records showed up as prescriptions at one end of the workflow and as administered doses at the other — the same drug, an entirely different clinical meaning depending on where you caught it. Now multiply that across every variable in a record, and then across every institution in a federation, and you start to see the shape of the problem.

This isn’t an edge case I’m cherry-picking. In a 2021 study, a team built a 30-day readmission model at Vanderbilt and tried to validate it at Dartmouth-Hitchcock — two well-resourced academic medical centers in the US, exactly the kind you’d expect to interoperate cleanly. Inconsistent data definitions turned out to be the primary barrier to portability of models. And the clinical notes everyone assumes will rescue you from structured-data ambiguity? No more consistent than the fields they were meant to clarify. If Vanderbilt can’t hand a model to Dartmouth without the data getting in the way, federated training across dozens of global institutions doesn’t dissolve that problem — it multiplies it.

“Can’t agentic AI just solve this?”

This is the question I get a lot, and it deserves a real answer. AI-assisted data harmonization isn’t new. We’ve had tools for years that help identify likely mappings, standardize concepts across systems, and reduce the manual effort involved in preparing data for analysis. Agentic systems are the newest and most capable version of that lineage, and modern models are genuinely good at semantic mapping.The tooling is real, and when it’s supervised correctly, so are the results.

But here’s where I push back on the magic-bullet version of the story. The challenge isn’t simply getting a hospital’s data harmonized once so it can participate in a federated network. The challenge is keeping it harmonized over time. Systems get upgraded. Documentation habits drift. New workflows appear. New edge cases surface. A field that meant one thing when the mapping was created can gradually come to mean something slightly different.

That matters because a local model can only learn from the data it is given. When the meaning of the data changes, retraining doesn’t solve the problem. It simply learns from the new interpretation. The work is making sure the underlying concepts still mean what everyone thinks they mean.

And the failure mode is quiet, which is exactly what makes it dangerous. A wrong variable mapping doesn’t crash a pipeline. It trains a model that looks fine on the dashboard, passes internal validation, and then fails in deployment months later, in ways that trace painfully back to a confident mapping decision nobody questioned at the time. That’s why every health AI company I work with still ends up with clinicians reviewing the mappings, the adjudications, and the evaluation criteria. The work is tedious because it has to be. This is not a problem you can fully automate and forget.

Beyond the model: the deployment layer

Even institutions that clear the data modeling bar face a third layer the federated learning conversation rarely discusses: operational deployment.

Compute — local or cloud — capable of running model training. Staff with the skills to build pipelines, manage model execution, and catch failures: data engineers, clinical informaticists, ML engineers, often all three, sustained over time as the model evolves. Governance frameworks that define who reviews what, when, and with what authority.

In most health systems globally, one or more of these is missing. Dedicated people are doing extraordinary work in resource-constrained settings, but individual effort cannot substitute for institutional infrastructure. The gap is structural.

The 5.2% won’t move until the work federated learning quietly assumes — digital infrastructure, harmonized data, and sustained governance — actually gets done. New tools will help. Better automation will help. I’ve spent enough time working with these systems to be optimistic about how much faster that work can become.

But acceleration isn’t substitution. Federated learning can work. Preparing the data is often harder than the federated learning itself.

I write on topics hiding in plain sight, at the intersection of medicine and technology. This is one of them.