Federated Learning for Multi-Clinic Dermatology AI: How It Works

Q: What is federated learning in healthcare?

Federated Learning (FL) trains a shared AI model across multiple hospitals or clinics without moving patient data to a central server. Each site trains a local model copy on its own records. Only weight updates travel to a central aggregator, which merges them into an improved global model and redistributes it. Patient images and records never leave the originating institution. This satisfies data governance laws like PHIPA (Ontario) and PIPEDA (federal) in Canada and HIPAA in the US, making FL the standard architecture for privacy-preserving medical AI.

Q: What is federated learning in simple terms?

Federated learning is a method where many computers train the same AI model without sharing the underlying data. Each participant trains a local copy, sends only a summary of what it learned (called gradient updates) to a coordinator, and the coordinator builds a smarter shared model from those summaries. In healthcare, the 'data' is patient records and images. Because only summaries travel, patients' data stays inside the clinic's own network. The end result is an AI model trained on diverse patient populations without anyone handing over sensitive files.

Q: What are the three types of federated learning?

The three main types are: (1) Horizontal FL, where all participants hold the same data features but different patients, the most common setup in healthcare; (2) Vertical FL, where different organizations hold different features about the same patients, such as a hospital and an insurance company; and (3) Federated transfer learning, used when both the patient populations and the feature schemas differ across sites. For a multi-clinic dermatology tool, horizontal FL is the standard choice because all participating clinics capture the same structured image data under the same diagnostic workflow.

Q: What are the downsides of federated learning?

The main downsides are communication overhead, debugging complexity, and slower iteration. Every training round requires all participating clinics to upload gradient updates; a slow clinic delays the whole round. Debugging is harder because you cannot inspect training data or intermediate outputs across sites without special tooling. Iteration cycles are slower than centralized training since experiments cannot be re-run on a single dataset in minutes. Additional engineering is needed when data is unevenly distributed across sites, requiring algorithms like FedProx to prevent model drift. These costs are worthwhile when regulatory compliance or patient data sensitivity makes centralization impossible.

As of November 18, 2025.

At DermaDex we connect Canadian patients to certified dermatologists and build the AI tools those dermatologists trust. When multi-clinic networks evaluate AI tools, the first question is almost always the same: "Our patients' images stay on our servers, right?"

Federated Learning (FL) is the architectural approach designed to make that answer yes. This post explains how FL works, why it is the leading framework for privacy-preserving medical AI, and what the trade-offs are for any organization considering it.

What is federated learning in healthcare?

Short answer: Federated Learning (FL) trains a shared artificial intelligence (AI) model across multiple hospitals or clinics without moving patient data to a central server. Each clinic trains a local copy of the model on its own data. Only model weight updates, not images or records, travel to a central aggregator. The result is a model that has seen diverse patient populations without any single patient's data ever leaving the clinic network. Rieke et al. (2020) describe this as the future of digital health with federated learning, citing FL's ability to satisfy data governance requirements that block conventional centralized training.

For dermatology specifically, this matters because skin images are among the most sensitive categories of personal health data under the Personal Health Information Protection Act (PHIPA) in Ontario and equivalent provincial statutes across Canada.

What is federated learning in simple terms?

Short answer: Think of it like a book club where no one shares their copy of the book. Each clinic reads the book locally and writes down notes about what they learned. Those notes go to a coordinator, who merges everyone's notes into a smarter summary and sends the updated summary back. No one ever sees another clinic's copy. In machine learning (ML) terms: the "book" is patient data, the "notes" are gradient updates to the model weights, and the "coordinator" is a central aggregation server that runs FedAvg or a similar algorithm to merge weight updates.

This framing helps clinical operators explain FL to their privacy officers without requiring a background in distributed systems.

What are the three types of federated learning?

Short answer: The three main types are horizontal FL, vertical FL, and federated transfer learning. Horizontal FL is the most common in healthcare: all clinics hold the same data schema (patient images, labels, demographics) but different patients. Vertical FL applies when two organizations hold different features about the same patients, such as a lab and an insurer. Federated transfer learning handles cases where data schemas and patient populations both differ. For a multi-clinic dermatology tool, horizontal FL is the natural fit because every participating clinic captures the same structured image data under the same diagnostic workflow.

Type	Data overlap	Common healthcare use case
Horizontal FL	Same features, different patients	Multi-clinic image classifiers
Vertical FL	Different features, same patients	Lab + EHR data fusion
Federated transfer learning	Neither features nor patients overlap	Cross-country research consortia

Why not just centralize the data?

Short answer: Centralizing skin image datasets from multiple Canadian clinics creates serious legal exposure under PHIPA (Personal Health Information Protection Act) in Ontario and PIPEDA (Personal Information Protection and Electronic Documents Act) federally, requires patient re-consent at each site, and introduces a single breach target for attackers. Beyond compliance, clinics are generally reluctant to transfer sensitive patient data to a shared repository controlled by a third party. FL sidesteps all three objections: no re-consent required, no central breach surface, no data custody transfer.

The three architectures typically evaluated are:

Central pooling — all images sent to one cloud bucket, one training run. Fastest to prototype, but creates legal and custody problems for regulated Canadian clinics.
Federated learning — local training, gradient aggregation. Privacy-compliant by design.
Split learning — the convolutional neural network (CNN) is split across the clinic and server; activations travel instead of gradients. Lower communication cost in some configurations, but the server sees intermediate activations that can partially reconstruct inputs.

FL offers the best balance of data privacy, model quality, and integration effort for most multi-clinic use cases.

How does federated learning protect against gradient leakage?

Short answer: Raw gradient updates can theoretically be inverted to reconstruct training images, a class of attacks studied since Zhu et al. (2019). The two practical defenses are differential privacy (DP) and secure aggregation. Differential Privacy adds calibrated noise to each clinic's gradient update before it leaves the local server. The noise budget is set so that no single training example can be identified from the gradient, but the aggregate signal across thousands of examples still improves the model. Secure aggregation uses cryptographic protocols so the central server only ever sees the sum of all clinic gradients, never any individual clinic's update.

Applying both a per-clinic DP epsilon budget and a secure aggregation protocol at the aggregator is the approach recommended in the FL healthcare literature. The privacy cost is a small reduction in convergence speed rather than a meaningful loss of model accuracy at production scale.

How does federated learning compare to centralized ML in practice?

Short answer: Federated models reach comparable accuracy to centralized models when the data is independently and identically distributed (IID) across sites. In real multi-clinic deployments the data is non-IID: one clinic may see more Fitzpatrick Type VI patients, another more pediatric cases. Standard FedAvg can struggle with high non-IID skew. FedProx, a variant that adds a proximal regularization term to local objectives, keeps local models from drifting too far from the global model during each communication round and is widely used to address this.

A 2024 systematic review of federated machine learning in healthcare covering 612 studies found that non-IID data distributions are the most commonly reported barrier to FL deployment in clinical settings. For a detailed look at how model architecture can address skin tone diversity, see Why Skin Tone Matters in AI Dermatology Models.

Aspect	Centralized ML	Federated Learning
Data location	Central cloud server	Stays at each clinic
Privacy risk	Single breach exposes all	Breach at one clinic affects only that clinic
PHIPA compliance	Requires explicit data-sharing agreements	Compliant by architecture
Model accuracy (IID data)	Slightly higher	Comparable
Model accuracy (non-IID data)	N/A	Requires FedProx or similar
Setup complexity	Low	Medium
Communication cost	None after data transfer	Per-round gradient sync
Regulatory overhead	High (data transfer agreements)	Low

What are the downsides of federated learning?

Short answer: The three main downsides are communication overhead, debugging difficulty, and slower iteration cycles. Each training round requires synchronized gradient uploads from all participating clinics; a single clinic with a slow connection delays the round for everyone. Debugging a model trained across many clinics is harder than debugging a central training job: you cannot inspect intermediate activations or training curves from individual clinics without additional tooling. Iteration speed is slower because you cannot re-run a training experiment on centralized data in minutes. In a typical multi-clinic FL deployment, a full federated round can take several hours overnight depending on clinic count and data volume.

None of these trade-offs eliminate FL as the right choice when regulatory compliance or patient data sensitivity makes centralization impossible. Building a round-monitoring dashboard and an asynchronous aggregation fallback for slow clinics are standard mitigations in production FL systems. For an overview of how the base model is designed and tested before federation, see Building Our Skin Lesion Classifier: Architecture and Training.

What does a federated training round look like in practice?

Short answer: In a typical FL setup, participating clinics receive an updated global model checkpoint on a recurring schedule. Each clinic's local training job runs for a fixed number of epochs on recently added cases. The resulting gradient delta is clipped, noise-injected under the DP budget, and uploaded to the aggregation server over mutual TLS. The aggregator runs weighted FedAvg (weighted by clinic case volume), publishes the new global checkpoint, and triggers validation against a held-out multi-site test set. If the new checkpoint scores below the previous round on sensitivity for high-risk lesions, the round is rolled back automatically.

This architecture can be implemented so that clinics do not require GPU (graphics processing unit) hardware beyond what runs standard clinical software. A containerized training job that runs on CPU is feasible for most clinic dataset sizes at typical update frequencies.

Sources

Rieke, N. et al. (2020). The future of digital health with federated learning. npj Digital Medicine, 3(119). PubMed PMID 33015372.
Teo, Z.L. et al. (2024). Federated machine learning in healthcare systematic review. Cell Reports Medicine. PubMed PMID 38340728.

Federated Learning for Multi-Clinic Dermatology AI: How It Works and Why It Matters