Federated Learning for Healthcare: Training Without Data Sharing

Federated learning addresses a fundamental constraint in healthcare AI: the most valuable training data for clinical models is distributed across institutions that cannot share it. Hospital A cannot send its patient records to Hospital B. No institution can aggregate data across a national health system without satisfying an array of HIPAA, state privacy law, and institutional review board requirements that make central aggregation practically impossible for most use cases. Federated learning sidesteps this by training the model locally at each institution and sharing only gradient updates, not the underlying data.

How Federated Learning Works in Practice

In a standard federated learning setup, a central server distributes a model architecture and initial weights to participating institutions. Each institution trains the model on its local data and computes gradient updates. The gradient updates are sent to the central aggregator, which combines them -- typically using FedAvg or a variant -- and distributes updated global weights back to the institutions. This cycle repeats until the global model converges. The patient data never leaves the institution. The aggregator sees gradients, not patients.

NVIDIA FLARE (Federated Learning Application Runtime Environment) is the most widely adopted framework for healthcare federated learning. PySyft provides an alternative with stronger privacy cryptography primitives. Both provide the coordination infrastructure for gradient aggregation, but neither solves the compliance architecture problem -- which is the set of legal, contractual, and technical controls that must surround the federated training process.

The Gradient Privacy Problem

The assumption that gradient sharing is privacy-safe has been challenged by research demonstrating gradient inversion attacks: given a gradient update from a model trained on a small local dataset, an adversary can reconstruct the training inputs with high fidelity. For healthcare data, gradient updates from a model trained on patient records can be inverted to reveal patient attributes including diagnoses, demographics, and clinical measurements. This is a PHI disclosure risk even though the underlying data was never transmitted.

The primary engineering countermeasure is differential privacy applied at gradient computation. Differential privacy adds calibrated noise to gradient updates such that the presence or absence of any individual training record cannot be detected from the gradient. The formal privacy guarantee is expressed as the epsilon-delta parameters of the DP mechanism. Smaller epsilon provides stronger privacy at a cost to model utility. The healthcare use case requires explicit decisions about what epsilon value is acceptable given the sensitivity of the data and the clinical importance of model performance.

Secure Aggregation

Differential privacy protects individual records from reconstruction via gradients but does not protect against a malicious or compromised aggregator that observes individual institution gradients. Secure aggregation protocols address this: using cryptographic masking, the aggregator receives only the sum of gradient updates across institutions, not the individual institution contributions. The aggregator performs the FedAvg update without seeing any individual participant's gradient. This is particularly relevant in multi-institution consortia where the aggregator may be a neutral third party that no single institution fully trusts.

The HIPAA BAA Structure for Federated Deployments

The HIPAA question for federated learning -- whether gradient sharing constitutes a disclosure of PHI -- has not been definitively resolved by HHS guidance. The conservative compliance position treats the federated training infrastructure, including the aggregation server and any orchestration services, as a business associate that requires a BAA with each participating covered entity. The BAA structure must cover the aggregation service, the model distribution mechanism, and any cloud infrastructure that handles the federated training traffic.

Real-World Deployment Considerations

Multi-institutional federated learning deployments in healthcare face practical challenges beyond the compliance architecture. Data heterogeneity -- different institutions use different EHR systems, coding standards, and clinical workflows -- means that local training datasets may have incompatible feature spaces and label distributions. Non-IID data distributions reduce convergence speed and final model quality. Institutional compute capacity varies significantly. These practical constraints require federated learning configurations that account for heterogeneous participation rather than assuming symmetric institutions. The compliance architecture must hold under these asymmetric conditions.