The collaboration problem
Healthcare institutions hold valuable but sensitive data. Centralizing those records may simplify conventional model training, yet it also concentrates governance, privacy, security, and infrastructure risk. The technical question is not only how to train a model, but how to coordinate learning across institutional boundaries.
A federated architecture
Each hospital trains locally against data under its own custody. An orchestration layer coordinates rounds, receives selected model updates, aggregates them, and redistributes a global model. The boundary between data and model parameters must remain explicit in both system design and governance.
Hospital A
Local data
Aggregation
Updates
Hospital B
Local data
Privacy is more than locality
Keeping records local reduces one class of transfer, but does not by itself establish a complete privacy guarantee. Update leakage, participant authentication, secure transport, aggregation policy, differential privacy, auditability, and institutional governance remain part of the system.
| Concern | Hospital node | Coordinator |
|---|---|---|
| Raw clinical data | Retained locally | Not received |
| Training | Local computation | Round coordination |
| Model updates | Produced locally | Aggregated |
| Governance | Institutional controls | Federation policy |
The engineering trade-offs
- Non-IID data can produce uneven local behavior.
- Network and compute constraints affect participation.
- Privacy mechanisms can change utility and resource use.
- Observability must not expose sensitive information.
A federated system is a distributed socio-technical system, not merely an optimization algorithm.
From principle to framework
OpenHealthFL treats orchestration, hospital participants, privacy controls, experiment configuration, and research artifacts as inspectable concerns. The goal is not to claim that federation solves every data problem, but to create a credible architecture for studying collaboration under real constraints.