Fed-BioMed: Open, Transparent and Trusted Federated Learning for Real-world Healthcare Applications

TL;DR

Fed-BioMed is presented: a research and development initiative aiming at translating federated learning (FL) into real-world medical research applications and describes the design space, targeted users, domain constraints, and how these factors affect the current and future software architecture.

Abstract

The real-world implementation of federated learning is complex and requires research and development actions at the crossroad between different domains ranging from data science, to software programming, networking, and security. While today several FL libraries are proposed to data scientists and users, most of these frameworks are not designed to find seamless application in medical use-cases, due to the specific challenges and requirements of working with medical data and hospital infrastructures. Moreover, governance, design principles, and security assumptions of these frameworks are generally not clearly illustrated, thus preventing the adoption in sensitive applications. Motivated by the current technological landscape of FL in healthcare, in this document we present Fed-BioMed: a research and development initiative aiming at translating federated learning (FL) into real-world medical research applications. We describe our design space, targeted users, domain constraints, and how these factors affect our current and future software architecture.

Figures (4)

• Figure 1: Workflow of an FL experiment from the point of view of a clinical data provider. The shaded area represents Fed-BioMed's design space in terms of functionalities and targeted usage.
• Figure 2: High-level architecture and design pillars of Fed-BioMed: node-side governance and control, interoperability with medical data standards and infrastructure, researcher interactivity, and data privacy and security. Fed-BioMed is composed of three components: the researcher, a data scientist responsible for designing and steering the training of the ML model; the nodes, i.e. the clinical data providers; and the network, responsible for brokering all communication between the researcher and nodes. Each component has been designed following the Fed-BioMed requirements (Section 2), and the figure highlights which requirement affects the architectural subcomponents.
• Figure 3: Prototypical FL training workflow in Fed-BioMed. Icons indicate the steps where the design was influenced by a particular requirement. First the nodes mark their dataset as available for federated training, while the researcher defines and obtains approval for a TrainingPlan. Then the researcher may launch multiple experiments, and within each experiment interactively launch multiple rounds of training. In each round, data are loaded locally on the nodes and the researcher-defined training routine is executed. Communication of model parameters and metadata always happens through the Network component.
• Figure 4: a) Pixel intensity distribution grouped by clinical site. Prostate images exhibit significant differences between sites, especially in the case of Site 2. b) Breakdown of FL experiment wallclock runtime. FL introduces a significant overhead in our case, likely attributable to the relatively small number of samples seen by the model in each FL round. c) Distribution of Dice scores for centralized (CL) and federated (FL) models, combining all cross-validation folds. The performance of the two models has a statistically significant difference, but with a small effect size. The figure shows boxplots inside the violin plots. The top bottom of each boxplot depict the 3rd and 1st quartile of each measure. The white line and the red x indicate the median and mean values, respectively. The whiskers depict the extremal observations still within 1.5 times the interquartile range. d) Clockwise from top left: an example raw image, the ground truth segmentation, the FL model prediction and the CL model prediction.