FL is the default answer for multi-hospital AI, and rightly so. But the distance between an FL paper and an FL pilot is large. These are the four issues that dominate real deployments.
1. The data is non-IID in ways that matter clinically
Different scanners, different protocols, different populations. Naïve FedAvg can converge to a model that is worse than a local model for some sites, a result you must detect and report per-site, not on pooled metrics. Personalisation layers and site-stratified evaluation belong in the plan from day one.
2. Governance takes longer than engineering
Even though raw data never moves, each hospital's DPO will (correctly) ask what the model updates leak. Differential privacy on updates plus a written DPIA answer turns a six-month legal negotiation into a manageable one. Start the governance track in parallel with development, never after it.
3. Orchestration is an infrastructure problem
Hospital IT environments are heterogeneous and locked down. Containerised FL clients with outbound-only connections, automated health checks and remote debugging designed for the case where you can't SSH in, this is where the engineering effort actually goes.
4. Plan the evaluation baseline honestly
The scientifically interesting question is not "does FL work?" but "how close does FL get to the centralised upper bound, and is that clinically sufficient?" Pre-register that comparison in the pilot design; it makes the final review meeting a formality instead of a debate.