From Challenges and Pitfalls to Recommendations and Opportunities: Implementing Federated Learning in Healthcare

1 Introduction

• Healthcare AI needs multi-centre data, yet privacy, regulatory, legal, ethical, and technological barriers complicate centralized data sharing.The review also identifies privacy risks, generalization issues, communication costs, non-IID data, and needs for standardization and interpretability.Source: §1 · p. 2
• FL keeps data distributed while allowing collaborative training, and prior studies report performance comparable to centralized models and better than single-institution models.The introduction also notes potential for less biased decisions, greater sensitivity to rare cases, and generalization beyond one institution.Source: §1 · p. 2
• Healthcare FL initiatives span academic, clinical, and industrial settings, including mammogram assessment, hospital treatment-response prediction, tumour segmentation, and drug discovery.The cited examples include FeTS, a 30-institution initiative for tumour boundary detection.Source: §1 · p. 2
• The review evaluates recent healthcare FL technologies and offers recommendations for fairer, more reproducible comparisons and higher-quality model development.Its stated contributions include a taxonomized analysis of FL and identification of future research opportunities.Source: §1 · pp. 2–3
• FedAvg training selects clients, runs local mini-batch updates for E epochs, and returns their models to a server for aggregation.The algorithm specifies K clients, a selected-client fraction C, batch size B, and learning rate η.Source: §1 · p. 3

2 Preliminaries

• FL trains a shared model across clients that retain private data locally, while a server aggregates client updates and broadcasts the refined model.The stated goal is minimizing a global objective built from client-local objectives and dataset-weighted contributions.Source: §2 · pp. 3–4
• Centralized FL uses a server to manage training, whereas decentralized FL removes the central server and lets connected clients communicate directly.The traditional process repeats download, local training, update collection, and server aggregation across communication rounds.Source: Figure 1 · p. 4, §2 · p. 4
• Decentralized FL includes peer-to-peer, sequential, and cyclic paradigms; exchanged information can include parameters, gradients, partial parameters, statistics, or logits.The review describes these developments as addressing communication costs, privacy, and multi-task learning.Source: §2 · p. 4
• HFL fits clients with overlapping features but different samples, VFL fits overlapping samples with different features, and FTL addresses little overlap in both spaces.The review identifies HFL as the most prevalent paradigm and notes FTL's relevance to tabular EHR data.Source: §2 · pp. 4–5, Figure 2 · p. 5
• Cross-silo FL involves a limited number of institutional clients, while cross-device FL involves many resource-limited devices such as wearables and IoMT devices.The examples include hospitals and companies for cross-silo settings, and Apple Watches, Raspberry Pi, and Jetson Nano for cross-device settings.Source: §2 · p. 5

3 Method

• The review followed PRISMA guidelines and defined inclusion and exclusion criteria for English-language studies involving FL technologies in healthcare.Two author groups screened studies independently and resolved conflicts through discussion.Source: §3 · p. 5, §3.2 · p. 6, Figure 3 · p. 6

3.1 Literature Search

• The search covered nine databases and Google Scholar, included eligible studies through May 2024, and initially identified 1,149 studies.Search phrases combined FL, healthcare, privacy, medical, biomedical, decentralized learning, and related terms.Source: §3.1 · p. 6

3.2 Study Selection

• 107 studies remained after screening: 43 duplicates and 402 unqualified or irrelevant studies were removed, followed by full-text assessment of 704 studies.A further 597 full-text studies were deemed ineligible.Source: §3.2 · pp. 6–7

4.1 Application and Data

• 67/107 studies focused on classification, and medical imaging was the most frequent data type, used in 55/107 studies.The review also covered segmentation (20/107), detection (8/107), clinical data and EHR (24/107), and histopathology slides (16/107).Source: §4.1 · p. 7

4.2 Topology, Scenario and Framework

• Only 10 studies reported real-world distributed clinical deployments, while 95/107 used centralized FL and 78/107 used custom frameworks.Thirteen studies used open-source frameworks, and 16 did not specify a framework.Source: §4.2 · p. 7

4.3 Data Curation and Partition

• Only 12 studies detailed data standardization and harmonization, while 37 used natural data splits and 17 described their training, testing, or validation sets.HFL predominated (94/107); most studies considered only one type of heterogeneity, and 12 split a holdout cohort for evaluation.Source: §4.3 · p. 7

4.4 Model

• CNNs appeared in 80/107 studies; among 23 studies discussing initialization, most used random initialization and five named pretrained or foundation models.Other approaches included RNNs, MLPs, attention mechanisms, traditional ML algorithms, and large language models for biomedical NLP.Source: §4.4 · pp. 7, 9

4.5 Optimization

• No reviewed studies considered system heterogeneity, and only 15 evaluated generalization to unseen open domains.Nineteen studies addressed communication efficiency; 21/107 reported convergence metrics, none gave a theoretical account of convergence dynamics, two considered temporal data dynamics, and 15 used asynchronous aggregation.Source: §4.5 · p. 9

4.6 Privacy and Security

• Only 41 studies addressed privacy guarantees for exchanging model updates.Common safeguards included DP, HE, SMPC, knowledge distillation, and partial model exchange, while sample sizes and distributions were frequently shared without protection, particularly with FedAvg.Source: §4.6 · p. 9

4.7 Fairness and Incentive

• Only three studies discussed fairness or incentives in healthcare FL, and just one examined both in detail.Fairness concerns equitable model performance among participants, while incentives motivate institutional participation through rewards for contributions such as data or computational resources.Source: §4.7 · p. 9

4.8 Evaluation

• Only 26/107 studies addressed FL-specific evaluation aspects such as communication overhead, scalability, generalization, privacy, fairness, or security.Most used conventional metrics and compared with centralized or local models; one study offered relatively comprehensive multi-dataset benchmarks, seven explored interpretability, 29 released code, and one released a trained model.Source: §4.8 · pp. 9–10

• The section organizes healthcare FL challenges and pitfalls into a taxonomy alongside recommended solutions and opportunities.The discussion follows a best-practice FL workflow.Source: §5 · p. 10

5.1.1 Domination of Simulation Studies

• Only 10 studies incorporated real-world distributed clinical scenarios; most simulated pooled, artificially partitioned data and client-server interactions.Real deployments involve heterogeneous, locale-specific data and more complex requirements for secure protocols and real-time communication; broader deployment remains poorly documented, including how hospital nodes and training rounds are managed.Source: §5.1.1 · p. 10

Recommendations & Opportunities

• Researchers can use simulations for controlled prototyping, but should anticipate deployment challenges and pursue national or international FL collaborations.The recommendations also call for clinician-researcher-engineer collaboration, clinical pilot studies, and engineering attention to interoperability, privacy, security, and network communication overhead.Source: Recommendations & Opportunities · p. 12

5.1.2 Deficiency in FL Frameworks Development and Usage

• Many studies used custom FL frameworks, while existing options may lack healthcare adaptations, communication efficiency, traceability, scalability, or cloud compatibility.Industrial-grade frameworks may impose unnecessary complexity and resource demands for simulation and prototype research.Source: §5.1.2 · pp. 12–13

Recommendations & Opportunities

• Framework selection can match use case: simulator modules support rapid prototyping, healthcare-specific frameworks address medical formats and regulatory needs, and cloud-friendly options can ease computational constraints.The review also recommends model- and data-agnostic support for broad data-science workflows.Source: Recommendations & Opportunities · pp. 13–14
• Frameworks should support secure communication and deployment that integrates with existing IT and data-science infrastructure.The recommendations call for encryption, reliable and flexible deployment, and data-science workflow support.Source: Recommendations & Opportunities · pp. 13–14

5.2.1 Unclear in Data Standardization and Harmonization

• Healthcare data vary in formats, clinical practices, and languages, making standardization, harmonization, and interoperability important before FL.For example, different glucose measurement methods and cut-offs can create hidden heterogeneity across institutions.Source: §5.2.1 · p. 14
• Most simulation studies centrally processed and artificially partitioned data, while only two reviewed studies performed data quality or integrity checks.Frameworks often assume preformatted data; the resulting preparation burden may fall on clinical data managers, and poor imputation or handling of non-random missingness can bias training.Source: §5.2.1 · p. 14

Recommendations & Opportunities

• The recommendations call for standard formats, consistent preprocessing, automated preparation pipelines, and secure access to standardized and interoperable datasets.FHIR and DICOM are suggested for EHR and imaging data, respectively, and OMOP is offered as a common data model example.Source: Recommendations & Opportunities · p. 15

5.2.2 Issues in Data Partition

• Only a few studies used natural data splits, while synthetic partitions may miss complex real-world heterogeneity such as staining, storage, and digitization differences.The review describes natural cohort splits as important for testing robustness across clinical settings.Source: §5.2.2 · p. 16
• Synthetic partitioning often emphasizes quantity skew while overlooking label and feature skew, and 84% of studies did not define client-level train-test partitions.The review recommends including multiple skew types, retaining client-specific test sets, and documenting partitioning choices; natural-split evaluation is also recommended alongside simulations.Source: §5.2.2 · p. 16, Recommendations & Opportunities · pp. 16–17

Recommendations & Opportunities

• The recommendations favor adaptive, domain-informed partitioning that reflects client data distributions and clinical context.This is presented as a way to create more realistic and representative synthetic partitions.Source: Recommendations & Opportunities · pp. 16–17

5.3.1 Inadequate Model Selection and Development

• Complex models, inconsistent selection, underused interpretable alternatives, limited personalization, and scalability costs complicate healthcare FL model development.Complex architectures can challenge reproducibility and generalization; one global model may not suit heterogeneous clients.Source: §5.3.1 · p. 17

Recommendations & Opportunities

• Standardized model-selection protocols, baselines, metrics, and validation can improve reproducibility and comparability across FL applications.The review recommends standards that enable comparison without limiting innovation.Source: Recommendations & Opportunities · p. 18

5.3.2 Negligence in Initialization

• Random initialization may be less optimal under non-IID data, while inconsistent or unreported initialization impedes comparison and can contribute to fairness concerns.Foundation-model or large-dataset pretraining may be infeasible for resource-constrained participants45,97,140.Source: §5.3.2 · pp. 18–19
• Personalized initialization using methods such as model-agnostic meta-learning or partial initialization remains limited in healthcare FL142,143.The review recommends standardizing initialization to support consistent benchmarking while leaving room for advanced approaches141.Source: §5.3.2 · p. 19, Recommendations & Opportunities · p. 19

Recommendations & Opportunities

• Pretraining or foundation models may speed convergence and mitigate data and system heterogeneity, but source–target similarity matters to avoid negative transfer45,97,140.The review also recommends accounting for participant resources, including lightweight pretrained models or hierarchical training45,97,140.Source: Recommendations & Opportunities · p. 19

5.4.1 Heterogeneity Issues

• Quality inconsistencies between imaging data and site-specific EHR data can drop federated-learning accuracy by up to 50%4; statistical heterogeneity also makes simple parameter averaging ineffective and can drift aggregated models from global optima, slowing convergence.Source: §5.4.1 · p. 20
• Different client architectures complicate aggregation; knowledge distillation may require auxiliary public data, raising privacy concerns and computational burden153,154.A lightweight messenger model is described as an alternative100.Source: §5.4.1 · pp. 21–22
• System differences in compute, networks, and resources can affect efficiency and convergence, while local computation and storage for distillation burden resource-limited institutions27,154.The review recommends adaptive frameworks and broader handling of combined data, model, and system heterogeneity.Source: §5.4.1 · p. 22, Recommendations & Opportunities · pp. 22–23

Recommendations & Opportunities

• Recommendations for heterogeneous data include local harmonization, synthesis or augmentation, feature alignment, imputation, bias checks, and client-specific fine-tuning.The review also suggests advanced optimization, disentangled representations, and more comprehensive handling of combined skew types.Source: Recommendations & Opportunities · p. 22

5.4.2 Open Domain Problem

• Only 14% of included studies validated methods on external data, while device or acquisition-protocol shifts can reduce performance on unseen datasets.Recommendations include domain-generalization methods, transfer learning or fine-tuning, ensembles, and synthetic data for open domains.Source: §5.4.2 · p. 23, Recommendations & Opportunities · p. 23

5.4.3 Burdens in Communication

• Client-server communication can be orders of magnitude slower than local computation; many clients, encryption, and large models add overhead.The review describes compression, fewer rounds, decentralized training, distillation, and lightweight models as possible approaches.Source: §5.4.3 · p. 24

Recommendations & Opportunities

• Lightweight models, pruning, LoRA, gradient compression, fewer communication rounds, decentralized training, and distillation are proposed to reduce communication demands.One-Shot FL is cited as requiring a single communication round for effective model training174.Source: Recommendations & Opportunities · pp. 24–25

5.4.4 Plain Convergence Analysis

• Plain reporting of epochs, rounds, and convergence time does not explain convergence dynamics; the review calls for theoretical guarantees and validation on real-world datasets with natural splits.It also recommends optimization suited to data properties and principled communication termination.Source: §5.4.4 · p. 25, Recommendations & Opportunities · pp. 25–26

5.4.5 Temporal Dynamics and Revoke Issues

• Healthcare FL should account for disease timelines and changing data, while efficient revocation methods should remove contributions without substantially degrading model performance.The review identifies machine unlearning as an approach to refine for data revocation182.Source: §5.4.5 · p. 26, Recommendations & Opportunities · p. 27

5.4.6 Synchronization Issues

• Synchronous updates can cause idle time when clients or data are delayed, whereas asynchronous updates accommodate varied availability but may weaken global-model consistency.The review recommends hybrid synchronization and consistency checks, and notes asynchronous FL may suit intermittently connected wearables and IoMT.Source: §5.4.6 · p. 27, Recommendations & Opportunities · pp. 27–28

5.5 Privacy and Security

• 62% of included studies did not encrypt model updates, and shared sample-size or distribution statistics could expose large-data participants to targeted attacks.The statistics were shared alongside updates particularly in FedAvg-based methods.Source: §5.5 · p. 28
• Model-update changes can enable model inversion, membership inference, and poisoning, while memorized updates or data-sharing practices can also leak sensitive information.The cited sharing practices include distributing samples for augmentation or disclosing local data distributions during knowledge transfer.Source: §5.5 · pp. 28–29
• Cryptographic protections include homomorphic encryption on encrypted data and secure multi-party computation across private inputs, but both can impose substantial overhead.HE has storage and computational costs; SMPC adds computational and communication overhead that can bottleneck as participants grow.Source: §5.5 · p. 29
• Less than 5% performance gap from non-DP models was reported for specific healthcare tasks, while differential privacy trades utility against privacy and adds computation.DP adds noise to local updates or gradients; a smaller ϵ strengthens privacy but may reduce performance.Source: §5.5 · pp. 29–30
• Blockchain can combine distributed ledgers, verification, and intrusion detection, but brings cost; swarm learning removes the central aggregator, while peer-to-peer latency may slow training.Swarm learning is described as particularly effective with non-IID data, but its latency can be affected by varying network conditions.Source: §5.5 · pp. 30–31

Recommendations & Opportunities

• Recommendations call for agreed privacy thresholds, protections across clients, servers, and channels, and safeguards when participants join or leave.The recommendations also call for balancing strong privacy guarantees with model accuracy.Source: Recommendations & Opportunities · p. 31
• Researchers should combine theoretical analysis with empirical validation of how privacy budgets, noise levels, and other parameters affect model performance and utility.Source: Recommendations & Opportunities · p. 31

5.6 Fairness and Incentive

• Only one study explored fairness and incentives in healthcare FL [55]; fairness proposals span hospital accuracy, demographic or medical attributes, both levels, and non-participating hospitals.Source: §5.6 · p. 31
• Voluntary federations rely on incentives; hospitals may gain stronger models than local-only ones, and rewards should track contributions such as data quality, volume, and computation.Source: §5.6 · pp. 31–32, Recommendations & Opportunities · p. 32

Recommendations & Opportunities

• Future fairness mechanisms should adapt as provider data distributions and contributions change over time.Source: Recommendations & Opportunities · p. 32
• Incentives can extend beyond money to reputation, advanced computing access, and improved patient outcomes to encourage more diverse institutional participation.Source: Recommendations & Opportunities · p. 32

5.7.1 Gaps in Evaluation Metrics

• 18% included communication efficiency, 12% measured computational costs, and 16% assessed privacy/security, while most studies emphasized conventional predictive metrics.The review calls for evaluating communication cost, resource use, privacy, and security alongside standard model metrics.Source: §5.7.1 · p. 32
• Scalability was insufficiently evaluated, and narrow coverage of data skew and heterogeneity limits conclusions about generalizability and robustness across healthcare institutions.The review says models should be tested across varying types of skew and heterogeneity.Source: §5.7.1 · p. 33

Recommendations & Opportunities

• The proposed evaluation framework combines conventional performance measures with communication efficiency, resource consumption, privacy and security, scalability, and generalizability.The review presents these dimensions as considerations for evaluating future FL research.Source: §5.7.1 · p. 33, Recommendations & Opportunities · p. 34

5.7.2 Insufficient Benchmarking

• Benchmarking remains scarce: studies often cover only one or two data-skew types, standardized datasets are lacking, and the sole standardized benchmark was limited in datasets and FL constraints.That benchmark did not integrate privacy, efficiency, and generalizability.Source: §5.7.2 · pp. 33–34

Recommendations & Opportunities

• Recommended benchmark resources pair natural client splits and documented per-client train/test splits with task baselines, standardized APIs, and framework-agnostic algorithm code.The recommendations also call for clear tasks and evaluation metrics.Source: Recommendations & Opportunities · p. 34

5.7.3 Lack of Interpretability

• Decentralized data and privacy mechanisms complicate bias detection and explanations; tree-based approaches can be domain-specific, while gradient and attention explanations may weakly reflect model decisions.The review also recommends lightweight client-side tools, interpretable aggregation, and privacy-preserving explainability.Source: §5.7.3 · pp. 34–35, Recommendations & Opportunities · p. 35

5.7.4 Poor Documentation and Reproducibility

• 27% released code and none released trained models; incomplete methods, ambiguous update terminology, custom frameworks, and private datasets further impede replication and fair comparison.The review recommends more complete documentation and public evaluation datasets.Source: §5.7.4 · pp. 35–36

Recommendations & Opportunities

• Recommendations include releasing documented code and models, using a methodology checklist and public datasets, extending established frameworks, and balancing transparency with privacy safeguards.The review also proposes documented, modular, privacy-aware pipelines.Source: Recommendations & Opportunities · p. 36

6 Conclusions

• Most healthcare FL studies remain focused on prediction tasks and often lack robust demonstrations of clinically significant outcomes.The review describes the field as being in its relative infancy.Source: §6 · p. 36
• The review examines existing challenges and pitfalls, offers guidance for selecting techniques by application scenario, and identifies open research challenges.Source: §6 · p. 37
• The review highlights standardized methodologies and protocols, alongside open-source code, as priorities for reproducibility and transparency in healthcare FL development.Source: §6 · p. 37