🤖 machine learning

Inclusive Federated Learning Through Compliance-Weighted Noise Allocation in Healthcare AI

This paper proposes a compliance-weighted federated learning framework that adapts differential privacy noise allocation to institutional compliance scores, enabling lower-compliance healthcare institutions to participate in collaborative AI training without degrading overall model performance or incurring utility penalties.

Original authors: Santhosh Parampottupadam, Melih Coşğun, Sarthak Pati, Maximilian Zenk, Saikat Roy, Dimitrios Bounias, Benjamin Hamm, Sinem Sav, Ralf Floca, Klaus Maier-Hein

Published 2026-07-15

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Santhosh Parampottupadam, Melih Coşğun, Sarthak Pati, Maximilian Zenk, Saikat Roy, Dimitrios Bounias, Benjamin Hamm, Sinem Sav, Ralf Floca, Klaus Maier-Hein

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine a massive, global cooking competition where chefs from 16 different kitchens are trying to create the perfect recipe for a new dish. The catch? No one is allowed to leave their own kitchen. They can't bring their secret ingredients (patient data) to a central table. Instead, they have to send only their notes on how they adjusted the recipe to a head chef (the server) who mixes them all together to make a better global recipe.

This is Federated Learning. It's great for privacy, but there's a problem: some kitchens are super organized with top-tier security locks and strict rules (high compliance), while others are a bit more chaotic, maybe using older locks or having messy logs (lower compliance).

In the old way of doing things, the head chef treated everyone exactly the same. They added a giant, heavy "noise" blanket over every single chef's notes to hide the secrets. This was like putting a thick, fuzzy blanket over a chef who was already wearing a high-tech invisibility cloak. It made the good chefs' notes hard to read, ruining the final recipe. Meanwhile, the messy kitchens got the same blanket, which wasn't enough to hide their secrets properly. The result? The best chefs were held back, and the messy ones were still risky.

The Paper's Big Idea: The "Compliance Score" Noise
The authors of this paper suggest a smarter way. They built a digital "report card" tool that checks how secure and rule-abiding each kitchen is.

High Score: If a kitchen has great locks, encryption, and follows all the rules (like HIPAA or GDPR), they get a light, thin noise blanket. Their notes stay clear, and the recipe stays delicious.
Low Score: If a kitchen is a bit messy or has weaker security, they get a thick, heavy noise blanket. This protects the secrets better, even if it makes their notes a bit fuzzier.

This is called Compliance-Weighted Noise Allocation. It's like giving a VIP pass to the organized chefs so they don't get weighed down, while giving the extra protection the chaotic chefs need to join the party safely.

What They Actually Found (The Simulation)
The researchers tested this idea using two famous "practice" datasets: one for spotting pneumonia in chest X-rays (PneumoniaMNIST, with 5,856 images) and one for breast ultrasound scans (BreastMNIST, with 780 images). They simulated 16 clients (kitchens) and ran the recipe-making process 50 times.

Here is what the numbers say:

The "Inclusivity" Win: When they let the 12 "messy" kitchens join the 4 "organized" ones using this new smart noise system, the final recipe actually got better in most cases, but not all. On the breast scan data, adding the messy kitchens improved accuracy by +4.5 to +6.8 percentage points for some methods (like FedMedian and FedAvg). However, for one method (FedAdam), accuracy actually dropped by 4.1 percentage points. The authors note that because they only ran a few test trials, none of these individual improvements were statistically significant on their own. The overall trend was positive, but the results varied depending on which "mixing strategy" the chefs used.
The "Fairness" Win: When they compared their smart noise system to the old "one-size-fits-all" heavy blanket, the results were about the same in terms of accuracy (a tiny difference of +0.1 percentage points). This suggests that the new system doesn't hurt performance just to be fair; it just shifts the noise around where it's needed.
The "Messy Data" Test: They even simulated a scenario where 12 kitchens sent in bad, degraded photos (cropped, noisy, low contrast). The system gave these kitchens a low score and a heavy noise blanket. The result? The system didn't magically fix the bad photos, but it didn't let them ruin the whole recipe either. The accuracy stayed stable, proving the system can handle bad data without crashing.

What the Paper Explicitly Rules Out (The "Not" List)
It is crucial to understand what this paper does not claim, because the authors are very careful:

It is NOT a magic shield against hackers. The paper explicitly states that this system does not protect the raw notes while they are traveling from the kitchen to the head chef. If a hacker intercepts the message, they can still see it. The paper says this is a "transport-layer" problem that needs a different solution (like secure encryption tunnels) to be fixed.
It is NOT a guarantee for every single patient. The privacy math (the "epsilon" number) only applies to the aggregator dataset (the small pile of practice images the head chef used to tune the noise). It does not provide a formal mathematical guarantee that you can't figure out what a specific patient's data was just by looking at the final recipe. The authors admit that getting that level of protection would require combining their system with other complex technologies they haven't tested yet.
It is NOT a solved problem for real hospitals yet. The authors emphasize that these results are based on simulations using public, low-resolution benchmark data. They explicitly state that before this can be used in real hospitals with full-resolution images, it needs much more testing, more seeds (random trials), and validation on real clinical data.

How Sure Are They?
The authors are measured and cautious. They don't call this a "breakthrough" that solves everything.

They suggest that this method allows more hospitals to join without ruining the AI model.
They show through simulation that the math works and the accuracy holds up in most scenarios, though results depend heavily on the specific mixing strategy used.
They admit that the privacy numbers (like an epsilon of ~1434 for the breast dataset) are huge and not yet "clinically actionable" on their own. They are proof-of-concept numbers, not final safety certificates.

The Bottom Line
This paper proposes a clever way to let hospitals with different security levels work together. Instead of forcing everyone to wear the same heavy armor (which slows down the fast ones and leaves the slow ones vulnerable), it gives everyone armor that fits their specific needs. The simulations suggest this makes the team stronger and the final AI model smarter in most cases, but the authors warn that we are still in the "practice kitchen" phase. Before this can be used to diagnose real patients, we need to move from these low-resolution practice images to real, high-definition hospital data and add more layers of security to protect the messages in transit.

Technical Summary: Inclusive Federated Learning Through Compliance-Weighted Noise Allocation in Healthcare AI

Problem Statement

Federated Learning (FL) offers a pathway for collaborative clinical AI development without centralizing patient data. However, widespread adoption in healthcare is hindered by institutional heterogeneity, including disparities in regulatory compliance, resource availability, and data security postures. Standard Differential Privacy (DP) mechanisms typically apply a uniform noise scale to all clients. This approach creates a "binary exclusion" dilemma: either apply a high noise scale to protect the least compliant sites (degrading model utility for well-resourced, compliant institutions) or exclude non-compliant sites entirely (sacrificing data diversity and equity). Furthermore, client-side DP often requires specialized hardware that resource-constrained clinics lack. The paper addresses the need for an FL framework that balances privacy, utility, and inclusivity by adapting privacy mechanisms to institutional compliance levels.

Methodology

The authors propose a compliance-aware FL framework that integrates adaptive Differential Privacy at the server side. The methodology consists of three core components:

Compliance Scoring Tool:
- A web-based tool was developed to quantify institutional readiness based on healthcare and security standards (HIPAA, GDPR, NIST, ISO, HL7/FHIR).
- Eligibility Gate: Mandatory prerequisites (e.g., legal adherence, encryption, patient consent) determine if a site can participate.
- Modulating Factors: For eligible sites, a compliance score ( $S_c \in [0, 1]$ ) is calculated as a weighted average of factors such as data quality, local training quality, audit logs, and network security.
- Noise Mapping: The score maps to a client-specific Gaussian noise scale ( $\sigma_i$ ) using a linear interpolation:
  $\sigma_i = \sigma_{min} + (1 - S_c)(\sigma_{max} - \sigma_{min})$
  Where $\sigma_{min} = 0.4$ and $\sigma_{max} = 1.0$ . Highly compliant sites receive lower noise ( $\sigma \approx 0.4$ ), while lower-compliance sites receive higher noise ( $\sigma \approx 1.0$ ).
Adaptive Server-Side DP-SGD:
- Unlike client-side DP, the DP mechanism is executed at the aggregator (server).
- The server maintains a small, held-out aggregator dataset (stratified random slice of the source data).
- In each round, the server receives raw client weights, creates a private working copy, and performs one epoch of DP-SGD on the aggregator dataset using the client-specific noise scale $\sigma_i$ derived from their compliance score.
- The resulting noisy weights are then aggregated using standard FL strategies (FedAvg, FedMedian, FedYogi, FedProx, FedAdam).
Privacy Accounting:
- The framework provides a formal $(\epsilon, \delta)$ bound on the aggregator dataset under a semi-honest aggregator threat model.
- The bound is computed via sequential composition of subsampled Gaussian mechanisms across 50 rounds and 16 clients using the Opacus accountant.
- The authors explicitly note that formal client-level DP requires composition with Secure Multi-Party Computation (SMPC), which is identified as future work.

Experimental Setup

Datasets: PneumoniaMNIST (5,856 samples) and BreastMNIST (780 samples).
Configuration: 16 simulated clients, 50 FL rounds, batch size 32, ResNet-18 architecture.
Experiments:
- Experiment 1: 4 compliant + 12 non-compliant clients (compliance-weighted DP).
- Experiment 4: 4 compliant clients only (baseline).
- Experiment 6: 16 clients with uniform DP (traditional approach).
- Data Quality Experiment: 12 clients with intentionally degraded data (simulating low compliance) vs. 4 trusted clients.
Metrics: Accuracy, Precision, Recall, F1-score, and cumulative privacy budget ( $\epsilon$ ).

Key Results

Inclusivity vs. Utility: Including 12 lower-compliance clients (Experiment 1) alongside 4 compliant ones generally improved or maintained model performance compared to a compliant-only baseline (Experiment 4).
- On BreastMNIST, gains ranged from +1.6 to +6.8 percentage points (pp) across strategies (FedAvg, FedMedian, FedProx, FedYogi), though FedAdam showed a decrease (-4.1 pp). The pooled mean gain was +2.8 pp.
- Statistical significance was not reached for individual strategies at $n=5$ seeds, but the trend favored inclusion.
Mechanism Efficiency: When comparing compliance-weighted DP (Experiment 1) against uniform DP (Experiment 6) at the same mean noise scale, the results showed utility equivalence (pooled difference +0.1 pp). This indicates that the governance flexibility of compliance-based noise allocation carries no utility penalty compared to uniform noise.
Aggregation Strategy Sensitivity:
- FedMedian: In the released reference implementation (per-client noise), FedMedian proved the most robust strategy, effectively filtering out outliers caused by high-noise clients. This contrasts with legacy post-aggregation pipelines where it underperformed.
- Adaptive Optimizers (FedYogi/FedAdam): These showed high sensitivity to heterogeneous noise levels, sometimes degrading performance in high-noise, mixed-compliance settings.
Privacy Budget: The cumulative privacy budget for the aggregator dataset was high ( $\epsilon \approx 1434$ for BreastMNIST, $\epsilon \approx 513$ for PneumoniaMNIST at $\delta=10^{-5}$ ) due to the small aggregator slice size and dense sampling. The authors note this is a design artifact of the benchmark setup and that structural changes (larger aggregator slices) are needed for clinically meaningful budgets.

Claims and Significance

The paper positions its contributions as follows:

Framework for Inclusivity: The primary contribution is a mechanism that allows lower-compliance institutions to participate in FL without degrading global model performance. By allocating noise proportional to compliance, the framework avoids penalizing well-compliant sites while still protecting the system.
Governance Tool: The authors introduce the first research tool for quantifying FL compliance, aligned with major healthcare standards. It allows Principal Investigators (PIs) to audit and justify noise allocation decisions.
Zero Utility Cost for Governance: The study demonstrates that adapting noise to compliance scores does not incur a utility penalty compared to uniform noise allocation when the mean noise level is matched.
Modest Privacy Claims: The authors are explicit about the scope of their privacy guarantees. They do not claim formal client-level $(\epsilon, \delta)$ DP for raw client data. The formal guarantee applies strictly to the aggregator dataset. Protection of raw client updates in transit against a malicious aggregator is acknowledged as a limitation requiring future integration with Secure Aggregation (SMPC).
Clinical Relevance: The framework is presented as a step toward equitable AI, enabling rare disease studies and diverse population modeling by including sites that would otherwise be excluded due to resource or compliance constraints. However, the authors emphasize that further validation on full-resolution clinical datasets and larger seed counts is required before clinical deployment.

In summary, the paper proposes a pragmatic, governance-driven approach to Differential Privacy in Federated Learning that prioritizes inclusivity and auditability, demonstrating that adaptive noise allocation can support diverse clinical federations without sacrificing model utility, provided the aggregation strategy is robust to heterogeneous noise.