Federated Learning for Medical Applications: A Taxonomy, Current Trends, Challenges, and Future Research Directions

In plain words

Hospitals and clinics hold data that could train useful AI models, but patient records are sensitive and privacy rules make them hard to share. Federated learning (FL) turns the usual flow around: the model travels to where the data sits, each site trains on its own records, and only model updates are sent back to be combined.

This paper is a review of how FL is used in medicine. It explains the main ways to split data among sites, shows how FL is combined with blockchain, Internet of Things devices and edge computing, and walks through example studies, several of them on cancer imaging. It also compares open-source FL software and lists the problems that remain: uneven data across hospitals, slow or unreliable networks, attacks on the shared model, and unclear rules. It does not propose a new method, so it is best read as a map of the field.

TL;DR

A survey of federated learning for medical applications, with a focus on tools for cancer diagnosis. It gives a taxonomy of FL setups, reviews FL combined with blockchain, IoT and edge computing, collects application studies, compares nine open-source FL frameworks, and lists challenges and open problems. The authors ran no experiments, so every number on this card comes from studies they cite. Use it to find the landscape and the open questions, not as an implementation reference.

Problem

Medical AI needs large, varied datasets, but patient data is sensitive and regulated. The paper names GDPR and similar US and EU rules as restrictions on collecting and moving such data §I. It argues that central training, which gathers data on one server, raises privacy concerns and practical limits such as latency and bandwidth §I. Edge computing moves processing closer to the data source §I §III.C.

The paper's question is whether FL, where data stays at its source and only model parameters move, can support diagnostic tools in medicine §I.A. Its scope is FL combined with other technologies, with a focus on the global cancer burden §I.A. The research questions are listed as RQ1 to RQ8 in §I.A.

Method

The paper is a narrative survey. Section numbers follow the IEEE numbering in the source (I to VIII). It is organised as follows:

1. Concepts and frameworks §II. It describes the classical FL loop and FedAvg §II fig. 2, and the three data-split frameworks: horizontal §II.A, vertical §II.B and federated transfer learning §II.C. Figure 3 sketches clients drawn from mobile, hospital and home healthcare fig. 3.
2. FL with other technologies §III. Blockchain §III.A, IoT-based monitoring §III.B and edge computing §III.C fig. 4.
3. Practical applications §IV. COVID-19 detection §IV.A, elderly activity recognition §IV.B and cancer and other diagnostic uses §IV.C. Figures 5 and 6 show global cancer incidence and mortality estimates for 2020 fig. 5 fig. 6.
4. Open-source software §V tab. IV.
5. Challenges §VI: communication §VI.A, statistical §VI.B, computational §VI.C, and security and privacy §VI.D.
6. Open problems §VII: hyperparameter optimisation, security, communication, heterogeneity, incentives, foundation models, FL with generative LLMs, image generative models, contrastive learning on unlabelled data, benchmarking and regulation §VII.A to §VII.K.

The three FL setups are defined by how data is split across clients:

• Horizontal FL §II.A: clients share the same feature space and hold different patients. The paper's example is a prediction task for autism spectrum disorder run across four institutions §II.A.
• Vertical FL §II.B: clients hold different features of overlapping people. The example is a hospital (treatment history) and an insurer (bills and claims) that combine data for a shared analysis without exchanging raw records §II.B.
• Federated transfer learning §II.C: a pretrained model carries knowledge across tasks when both samples and features differ. The example is FedHealth, which learns activity recognition first and then transfers to Parkinson's disease §II.C.

The classical loop the paper describes is shown below. The paper gives no aggregation formula, so the weighting is left open.

# Classical FL round, as described by the survey  [§II] [fig. 2]
# Input:  global_model; clients (all available clients)
# Output: updated global_model

def federated_round(global_model, clients):
    # Server selects participants, randomly or by a selection rule  [§II]
    chosen = select_clients(clients)

    # Local parameters from each chosen client  [§II] [fig. 2]
    local_models = []
    for client in chosen:
        # Client trains on its own local data only  [§II]
        local_model = client.train(copy(global_model))
        local_models.append(local_model)

    # Server aggregates the local parameters  [§II]
    # The paper gives no weighting rule for the aggregation.
    return aggregate(local_models)

# Outer loop  [§II]
# The survey runs rounds until convergence or a fixed number of iterations.

def train_federated(global_model, clients, num_rounds):
    # Convergence check is not stated; this uses a fixed budget
    for round_index in range(num_rounds):
        global_model = federated_round(global_model, clients)
    return global_model

Taxonomy figure: Figure 1 gives the taxonomy of topics covered fig. 1.

Hyperparameters

The paper proposes no model and trains nothing, so it sets no hyperparameters. The values below are not stated for the surveyed approach as a whole. Numbers for individual cited studies are in Results.

Results

Author-reported, and not reproduced. The paper runs no experiments of its own; the numbers below are as the survey reports them from the cited studies. Setups differ across rows, so the rows are not directly comparable.

Other reported setups without a headline number: EXAM used data from 20 global institutes §IV.A; a US study predicted acute kidney injury in 4,029 adults at five New York City hospitals §IV.A; PolypGen has 3,762 polyp frames from more than 300 patients at six centres §IV.C.

Framework comparison, the survey's own assessment, not tested here tab. IV:

Paper vs code

No official code. The paper proposes no method, and its source has no repository link for its own work; it only links framework homepages, a GPT-JT blog post and the FeTS site. A GitHub search was not run, because a survey with no method has nothing to implement. The paper's source, which gives no github link at all, was checked for this.

Pitfalls

• Numbers are second-hand. The survey reports results from cited studies and does not check them. Setups, datasets and metrics vary, so do not compare rows across studies.
• Internal contradictions in the survey.
  • The pancreas paragraph gives the five-year survival figure as a value in years ("less than nine years") §IV.C. This looks like a unit error. The card does not use the figure.
  • The breast cancer paragraph calls breast cancer the third leading cause of mortality §IV.C. The mortality figure ranks breast fifth, after lung, colorectum, liver and stomach fig. 6.
  • The PySyft subsection says the framework uses differential privacy, then says it provides no DP mechanism §V.E.
• Unclear result. The Li et al. brain-tumour paragraph calls one model "decentralized" and says one converged at 300 epochs and the other at about 600. The per-epoch times are then given as 205.70 s and 65.45 s plus overhead §IV.C. It is not clear which setting each number belongs to. Look up the original study before using them.
• Blog source. The claim that GPT-JT (six billion parameters) outperforms models with larger parameter counts rests on a company blog post, not a peer-reviewed study §VII.F.
• Framework comparison is a judgement. Table IV records the survey's own reading of each project's documentation. It was not checked by running the frameworks. The text also says PaddleFL uses differentially private SGD, which the table does not show §V.H.
• Missing mechanics. The survey does not give the FedAvg weighting, the number of clients or rounds, or any training setting. Its own text says FedAvg lacks convergence guarantees for non-iid data in the convex case §II.
• Dataset caveats. For KvasirCapsule (4,741,504 frames) the survey says the data is not split by hospital and does not say which hospital each video came from, so it cannot be used as-is for a multi-centre setup §IV.C. The survey says no FL work on small bowel disease exists §IV.C.
• Selection is not described. The paper has no methodology section and does not say how studies were chosen for review.

Lineage

• Builds on: FedAvg, introduced by Google and used as the classical aggregation algorithm §II. The paper describes it but does not give its update rule.
• Compared against: Table II lists 13 earlier FL surveys, covering general FL, mobile edge computing, smart cities and healthcare tab. II. The authors say these mostly focus on non-medical FL, with few covering the medical setting §I.A.
• Superseded by: not stated.