PaperlayerView exact revision on arXiv

Source-linked AI summary

Making Cross-Continental Federated Learning Repeatable with FLIP: a Multi-Application Study

Rafael Garcia-Dias, Alexandre Triay Bagur, Chayanin Tangwiriyasakul, Virginia Fernandez, Parhom Esmaeili, Piyalitt Ittichaiwong, Yang Li, Lawrence Adams, Wason Buncharoen, Martin Chapman, Benjamaporn Chayanond, Sadthavud Chunrod, Tanawat Fongsri, Kass Gibson, Supat Plungprasertkul, Supawit Tangpanithandee, Kanyakorn Veerakanjana, Vicky Goh, Michela Antonelli, Joe Zhang, Kongkiat Kespechara, Sebastien Ourselin, M. Jorge Cardoso

arXiv:2609.36001v1cs.LGcs.CVcs.DC

TL;DR

Healthcare FL collaborations face recurring infrastructure and governance work across institutions. FLIP combines reusable services and site-controlled approvals, and the study demonstrates two application types across UK and Thailand sites. The authors present this as an operational contribution, not evidence that federated training outperforms centralised training.

  • Problem

    Healthcare FL requires collaboration across distributed patient data and differing institutional infrastructure, security, and governance processes, while collaborations often rebuild similar infrastructure.

    Source: §1 · p. 1

  • Method

    FLIP combines Central Hub coordination with local Trust Nodes, cohort and imaging access, reusable job types, and site-level approval for federated workflows.

    Source: §1 · p. 2, §2 · p. 3

  • Results

    Two application types—federated fine-tuning and model evaluation—ran across UK and Thailand sites using the same platform architecture without platform-level changes.

    Source: §8 · p. 16

  • Takeaways & Limitations

    The study supports FLIP’s operational use for repeatable cross-site workflows, with project participation approved independently at each site.

    Source: §8 · p. 16

    FLIP’s policy enforcement remains partly hand-coded, and its exported provenance is not hub-attested while hub audit tables have no export route.

    Source: §3.3 · p. 6

Abstract

from arXiv · show

Federated learning (FL) in healthcare remains challenging, as the overhead of rebuilding governance guarantees for every collaboration stops most projects at the proof-of-concept stage. Here we present FLIP (Federated Learning Interoperability Platform), an open-source, multi-application platform that makes FL training and evaluation repeatable. FLIP implements common FL workflows as a set of composable services: cohort queries against per-site structured databases, on-demand DICOM retrieval from institutional PACS, per-site project approval, and reusable FL job types. To demonstrate FLIP, we ran two distinct use cases, federated fine-tuning and federated evaluation, on synthetic chest X-ray cohorts across two client nodes based in the United Kingdom (UK) and Thailand. In FLIP, each institution independently approves its participation in each project and operates its own node under local IT security processes. This study makes an operational rather than an algorithmic claim. It does not compare federated with centralised training; for that question, we refer the reader to existing systematic reviews and meta-analyses. The central result is evidence that such platforms enable international FL collaboration and improve repeatability, auditability, and site-specific governance. We also present a comprehensive comparison of existing platforms to help researchers and operators choose the right platform for their use case.

1 Introduction

Healthcare FL collaborations must work across institutions with different data, infrastructure, security, and governance constraints. FLIP addresses the operational burden with reusable services and demonstrates two distinct applications across UK and Thailand sites.

1 Introduction

  • Distributed patient data, privacy and governance requirements, and institutional differences make healthcare FL difficult to deploy and repeatedly require collaborations to rebuild infrastructure.The introduction links this burden with academic–industry collaborations remaining rare or limited in scope.Source: §1 · p. 1
  • FLIP is an open-source, multi-application platform that operationalises federated projects from cohort discovery and staging through local execution, aggregation, and auditable provenance.Its modular services separate Central Hub coordination from site-level Trust Node execution.Source: §1 · pp. 1–2, Figure 1 · p. 2
  • FLIP’s operational focus responds to the work of connecting sites and meeting their governance requirements, rather than testing whether federation outperforms centralised training.The study reports that comparison was not run.Source: §1 · p. 2
  • Two distinct applications—federated fine-tuning and model evaluation—ran across UK and Thailand sites, with independent site-level approvals.The paper frames this as an operational rather than algorithmic contribution, not a comparison with centralised training.Source: §1 · p. 2

2 FLIP: a Multi-Application Platform

FLIP combines a Central Hub for coordination with Trust Nodes that execute approved work locally. Its query, job-type, and application interfaces support distinct workflows without platform reconfiguration, alongside site-controlled project approval.

2 FLIP: a Multi-Application Platform

  • The Central Hub handles project coordination while each Trust Node runs local data and imaging services, an FL client, and GPU compute within the institution.Trust Nodes poll approved tasks over outbound-only HTTPS, and images never leave the site.Source: §2 · p. 3

2.1 Extensible by Design

  • Cohorts are defined by SQL against each site’s OMOP database, including clinical and imaging criteria, and can resolve to DICOM studies for retrieval.The study query separates training and holdout sets and returns aggregate per-site counts.Source: §2.1 · p. 3, Figure 2 · p. 4
  • Reusable job types provide fixed server-side contracts for supervised training and federated evaluation, while user applications implement the client-side workload.The described training type uses FedAvg; evaluation supports single- or multi-model scoring with automated DeLong significance reporting.Source: §2.1 · p. 3
  • A new application can be deployed by uploading its bundle and selecting a job type, without changing Central Hub or Trust Node code.The study ran fine-tuning and evaluation on the same infrastructure and cohorts without platform reconfiguration.Source: §2.1 · p. 3
  • FLIP’s application catalogue includes complete bundles across imaging and non-imaging use cases, with checks for preprocessing, job-type requirements, and end-to-end execution.The catalogue is tested on both backends as a release gate.Source: §2.1 · pp. 3–4

2.2 Site-Controlled Governance

  • Each institution independently reviews and approves its participation in each project, and the recorded site decision gates execution.The reported study used synthetic data and required no formal ethics review.Source: §2.2 · p. 4

3 Related Platforms

The related-platform comparison distinguishes systems by layer, workflow interface, topology, and demonstrated deployment. It positions FLIP’s contribution as a combination of capabilities while identifying operational trade-offs and limits.

3 Related Platforms

  • FL engines provide training and aggregation, analytics infrastructures execute computations on structured data, and deployed healthcare platforms combine different data, imaging, and governance capabilities.The comparison also distinguishes discovery tiers and notes that analytics infrastructures generally lack on-demand PACS imaging retrieval.Source: §3 · pp. 4–5

3.1 Topology, and What a Central Hub Costs

  • A hub concentrates coordination and creates a single point of failure, while decentralised alternatives offer resilience and avoid privileging one institution.The authors chose a hub for central audit, shared observability, and lower onboarding burden in a two-site federation spanning eight time zones and two legal regimes.Source: §3.1 · p. 5

3.2 Interface Scope

  • FLIP’s portal supports the full project workflow, from cohort query and site approval through job submission and results retrieval, rather than monitoring alone.The described workflow requires no command execution on site infrastructure.Source: §3.2 · p. 5

3.3 What This Work Adds

  • The paper identifies a combination not found in one existing open platform: OMOP imaging cohorts resolved to PACS studies, two-backend support under one contract, and per-site approval that gates execution.The comparison notes individual precedents for components of this combination.Source: §3.3 · p. 6
  • The comparison excludes federated analytics, simulations, imaging repositories without cross-site training, and closed commercial systems from its training-platform scope.The section scores platforms that themselves deliver training.Source: §3.3 · p. 6
  • FLIP’s machine-enforced policy is partly ad hoc, and its exported provenance record is not hub-attested while hub audit tables cannot be exported.Release v0.10.0 adds a site-owned runtime policy that can block cohort operations or raise disclosure thresholds.Source: §3.3 · p. 6
  • Deployment footprint does not equal live training scale: RACOON had 38 sites but reported training across six, while FeTS federated 71 sites over 6,314 cases.The passage also contrasts CODA’s deployment and analytics footprint with its simulated federated-learning demonstration.Source: §3.3 · p. 6
  • Of 107 healthcare FL studies, 78 used custom frameworks and only ten reported real-world deployment in distributed clinical settings.The cited review found a separate seven papers directly addressed healthcare FL governance.Source: §3.3 · p. 7

4 Platform and Framework Comparison

The comparison assesses platforms and frameworks using public code where available, distinguishing code-verified capabilities from publication-based or publicly demonstrated claims. It also documents changes in systems and criteria, and notes limits in search recall and repository-health metrics.

4.1 Identification of comparators

  • Comparators were identified using four searches, explicit eligibility rules, and a platform-level unit of analysis, with running code scored where available.Eligibility requires a reusable system supporting independently governed sites with record-level data remaining local, and excludes simulations, method-only papers, and superseded systems.Source: §4.1 · p. 7, §4 · p. 7
  • 13 of 26 comparators were retrieved by PubMed, 20 of 22 with public repositories by GitHub, 14 by arXiv, and 5 by medRxiv; together, the searches recovered all 26.A citation-tracking pass was still needed to discover GenoMed4All before medRxiv was added; rerunning the released queries reconstructs the final comparator rows.Source: §4.1 · pp. 10–11

4.2 Column criteria

  • 20 of 31 rows have permissive licences, while other entries include copyleft, non-OSI, unlicensed, or deployment terms extending beyond the code.The criteria distinguish capabilities such as project-gating site approval, on-demand PACS retrieval, runtime-enforced policy, and exportable job provenance from superficially similar features.Source: §4.2 · p. 11

4.3 What has changed since publication

  • Substra’s distributed-ledger mode was removed, FEDn’s repository became a client SDK with commercial server images, and OpenFL announced it would soon be archived.FeatureCloud’s source could not verify its self-hosted interface claim, and the table scores its interface as an unverified publication-based claim.Source: §4.3 · p. 11
  • PHT-meDIC’s source verifies persisted per-station approvals and browser-based train creation, execution, and result collection, but its repository has been inactive since January 2024.The source also shows that no site data model is imposed.Source: §4.3 · pp. 11–12
  • FeTS and FL4Health were added through the systematic search, while gLinDA and FedKBP+ were also added; five other candidates were excluded as non-deployable or ineligible.FeTS’s front end has had no commit since October 2023, while gLinDA has had none since February 2025; FedKBP+ is scored from its paper because its code is unavailable.Source: §4.3 · p. 12

4.4 Why several scores are partial

  • Several partial scores reflect narrower implementations: Kaapana stages but does not retrieve PACS images on demand, while Fed-BioMed and Substra approvals are not project-level gates.FLARE’s peer-to-peer workflows still rely on its server for provisioning and scheduling; NEBULA’s runtime checks govern application roles and resource admission, not data access.Source: §4.4 · p. 12
  • FLIP’s approval object gates execution per project and site, but its initial authority originates with hub-created Trust Owners; engine choice is deployment-wide, not per job.FLIP serves NVFlare and Flower through one API, interface, and job abstraction, but changing engines requires recreating the API service.Source: §4.4 · p. 13

4.5 Scores taken on trust

  • FLA3’s runtime-policy score is ◦ because its code checks only one call and later accepts submissions, while a seminar-demonstrated browser workflow earns •⋆ despite absent source code.The demonstrated workflow includes organisation and node management, run monitoring, and a wizard for submitting a training run.Source: §4.5 · p. 13
  • Four comparison rows could not be corroborated against code and are scored from publications, including designs or systems with absent or incomplete public implementations.The passage names GenoMed4All, TrainTracks, INCISIVE, and FLA3; readers are cautioned to treat these scores as reported rather than tested.Source: §4.5 · p. 13
  • APPFLx cannot be self-hosted, and its per-run record lacks data-version, code-hash, and authorising-decision links.Its web application is operated by Argonne, while only its server-side entrypoint is included in the MIT-licensed distribution.Source: §4.5 · p. 14

4.6 Reading the health table

  • Commit counts, stars, and release labels need qualification: repository structure and mirroring affect activity measures, while stars indicate visibility rather than quality or fitness.Kaapana’s zero merged-pull-request count reflects GitHub mirroring despite 206 merge commits in GitLab; MedPerf’s only tagged release is a pre-release, and FLARE’s newest tag is a release candidate, so the table names stable release 2.9.0. Four platforms cannot be scored on these metrics, including GenoMed4All, INCISIVE, TrainTracks, and PADME.Source: §4.6 · p. 14

5 Case Study: Researcher Journey on FLIP

The case study follows a researcher from cohort selection and site approval through local imaging retrieval, federated job execution, and results download. FLIP handles coordination and governance after sites are onboarded, separating recurring project work from one-time site setup.

5 Case Study: Researcher Journey on FLIP

  • Each selected site independently approves participation after aggregate-only cohort counts are returned, then retrieves matching images from PACS into local XNAT.With a simulated PACS server, importing nearly 2,000 studies took approximately 6 minutes per site.Source: §5 · p. 14
  • The researcher uploads the app after image import; FLIP dispatches and monitors the job, then provides model, metrics, evaluation scores, and an audit trail.The fine-tuning job ran 50 global rounds over approximately 11.2 hours; the evaluation job returns per-site, per-model AUROC values and pairwise DeLong tests.Source: §5 · p. 14
  • At an already-onboarded site, the researcher writes one SQL query, adapts and uploads an FL app, and runs it while FLIP handles coordination, data access, governance, scheduling, and aggregation.One-time onboarding separately covers Trust Node installation, security review, OMOP harmonisation, and PACS/XNAT integration.Source: §5 · p. 14

6 UK–Thailand CXR Fine-Tuning

The study demonstrates federated fine-tuning and evaluation on synthetic chest X-ray cohorts at UK and Thailand sites. It also measures synchronous-round latency using telemetry and comparison runs that remove WAN or platform components.

6 UK–Thailand CXR Fine-Tuning

  • Each synthetic site cohort reserved 20% of images for holdout evaluation, leaving approximately 1,900 training and 475 holdout images per site.The UK images used templated text prompts and the Thai images image-conditioned generation; automated quality control rejected 0.5% and 2.5%, respectively.Source: §6 · pp. 14–15
  • Federated fine-tuning trained a new five-class linear head on frozen Ark+ features using FedAvg with selective parameter sharing for 50 global rounds.Only weight differences above the 10% quantile were shared, with absolute truncation at 0.01; each round used five local epochs.Source: §6 · p. 15
  • The shared evaluator calculates per-class site-level AUROC and ranks models using pairwise two-sided DeLong tests with Benjamini–Hochberg FDR correction.The comparison used Pretrained Ark+ and the same model after federated fine-tuning.Source: §6 · p. 15

6.1 System latency measurements

  • A synchronous round is decomposed into download, computation, upload, aggregation, persistence, and inter-round coordination, measured from Central Hub telemetry.Simulator runs removed WAN, TLS, encryption, and polling; a deployed two-client run retained the platform stack but removed WAN.Source: §6.1 · p. 15

7 Results

Federated fine-tuning improved AUROC across most site–class pairings, while the latency results show stable rounds paced primarily by client compute. The study also reports one-time startup costs and a reproducibility path spanning simulation and deployment.

7.2 Latency Results

  • 5.9 s of server-side work represented 0.79% of the stable 745.8±0.7 s round time across rounds 1–49.The 50-round UK–Thailand timing decomposition is available only for the deployed platform, not the simulator.Source: §7.2 · p. 15, Table 5 · p. 16
  • The Thai client’s 737.9±0.7 s turnaround consumed 98.9% of each round, so slower client compute—not network transfer—paced steady state.UK turnaround was 129.8±0.5 s (17.4%); steady-state model transfer was under 0.2 s.Source: §7.2 · p. 15

7.1 Model Performance

  • 6 of 10 site–class pairings improved AUROC after federated fine-tuning, with improvements surviving correction at Q=0.05.Mean AUROC rose from 0.958 to 0.999 at the UK site and from 0.966 to 1.000 at the Thai site; the fine-tuned model reached AUROC ≥0.997 at both sites on this easy synthetic task.Source: §7.1 · p. 15, Table 4 · p. 16

7.2 Latency Results

  • Round 0 took 3,830.0 s, with 3,084 s of excess time dominated by one-time UK initialization rather than distance.The full-checkpoint broadcast to Thailand added a secondary 954 s; initialization is amortized over long runs but can dominate short jobs.Source: §7.2 · p. 16
  • The same application ran without modification in the local simulator and deployed platform, with experiment provenance and reproduction artifacts archived.The archived materials include the source commit, container digests, deployment manifests, cohort SQL, app bundles, random seeds, and configurations.Source: §7.2 · p. 16

8 Discussion and Conclusion

FLIP is presented as an operational platform for repeatable, multi-application federated learning, demonstrated across UK and Thailand sites with independent site approvals. The paper bounds its claims to a synthetic-data proof of concept and identifies broader deployments and real-patient governance as untested.

8 Discussion and Conclusion

  • Two distinct applications—federated fine-tuning and evaluation—ran across UK and Thailand sites through one platform with independent site-level approvals.The study describes its contribution as operational rather than algorithmic.Source: §8 · p. 16
  • The same service architecture, cohort-query mechanism, and job-type system supported both workloads without platform-level changes.Only the SQL query and application files were project-specific; FLIP handled scheduling, data access, aggregation, and provenance.Source: §8 · p. 16
  • Researchers interacted through the Central Hub without site-infrastructure access or remote command execution, while site responsibilities mapped to local operational concerns.Those concerns include cohort definition, imaging access, GPU execution, per-site approval, and audit trails.Source: §8 · p. 17
  • OMOP-definable cohorts are supported when harmonised data are ingested at each site, and matching DICOM series are resolved on demand.Figure 3 shows the FLIP interface with federated training results from the UK–Thailand deployment.Source: §8 · p. 17, Figure 3 · p. 17
  • No centralised comparator was trained, and the synthetic task’s near-ceiling AUROC does not establish that federated training is preferable to pooling.The latency measurements describe one 50-round, two-node job; the paper frames the study as operational, not powered to answer a statistical question.Source: §8 · p. 17
  • The proof of concept exercised FLARE, FedAvg, one institution per country, two applications, and synthetic-data governance; larger federations and real-patient governance remain untested.The deployment also preceded trust-scoped approver identity and declarative runtime policy; hub attestation of provenance remains a design limitation.Source: §8 · p. 17
  • Future work identifies non-IID heterogeneity, real clinical data under approvals, and additional job types such as detection as areas to address.The current job catalogue covers segmentation, classification, evaluation, and synthesis.Source: §8 · p. 18

A Search Strings

The appendix provides the executed search strings and scripts to support rerunning the identification process.

A Search Strings

  • The four search strings are reproduced exactly as executed.PubMed and GitHub queries come from search_protocol.sh, the arXiv query from fetch_arxiv.py, and the medRxiv sweep from fetch_medrxiv.py.Source: A Search Strings · p. 22
  • All three scripts are released so readers can rerun the identification rather than rely on the reported counts alone.Source: A Search Strings · p. 22
  • The reported counts use the 5 September 2026 run; a 10 September rerun differed because of new deposits, not a changed query.Source: A Search Strings · p. 22

A.1 PubMed

The PubMed query combines three concept blocks, with free-text terms in Block A needed to retrieve relevant platform papers.

A.1 PubMed

  • The PubMed query is the conjunction of three concept blocks: A AND B AND C.Source: §A.1 · p. 22
  • Block A’s free-text form is load-bearing because the Federated Learning MeSH descriptor indexes no records dated before 2024.Source: §A.1 · p. 22
  • The phrases “federated evaluation” and “federated benchmarking” retrieve MedPerf, whose title mentions neither federated learning nor a platform.Source: §A.1 · p. 22

Block A: federated computation

Block A pairs a federated-learning subject heading with free-text terms for related federated-computation concepts.

Block A: federated computation

Block B: a system rather than a study

Block B searches for systems and tools that could represent a platform, rather than only studies.

Block B: a system rather than a study

Block C: health setting

The health-setting search and database-specific adaptations build complementary candidate pools; together, the four searches retrieved every comparator.

Block C: health setting

  • The health-setting block searches terms for clinical care, hospitals, patients, medicine, health, imaging, radiology, and multicentre settings.Source: Block C: health setting · p. 23

A.2 GitHub

  • The GitHub strategy uses 18 narrow queries, with name-targeted additions and no star floor, because keyword searches miss repositories without matching tags or descriptions.The code-search API rejects queries with more than five boolean operators.Source: §A.2 · p. 23
  • As a post-fetch liveness filter, the one-contributor floor retains 2,330 of 2,432 repositories returned by the queries and removes 102 that no longer resolve or expose any contributors.Raising the floor to two would additionally remove approximately 2,100 single-maintainer repositories, and would also remove FLA3, which has a single author.Source: §A.2 · p. 23

A.3 arXiv

  • The arXiv query uses the same three-concept conjunction but spells out singular and plural forms because arXiv lacks stemming and wildcards.It returned 1,190 records; a preprint counts only if its metadata includes a public repository link or journal reference.Source: §A.3 · pp. 23–24

A.4 medRxiv

  • The medRxiv search matches two free-text blocks locally across 109,695 records, returning 167 matches; preprints count only with a later journal DOI or public repository.The health-setting block is omitted because medRxiv is itself a health preprint server.Source: §A.4 · p. 24

A.5 What the queries do not retrieve

  • Every comparator was retrieved by at least one of the four searches, without relying on citation tracking.PubMed misses engines, GitHub misses FedKBP+ and gLinDA, and medRxiv recovers GenoMed4All, which the other three miss.Source: §A.5 · p. 25, Table 6 · p. 25
Loading 2609.36001v1…