Federated Learning in sanità: Flower, FATE, OpenFL e i framework open source

AIHealth

Piattaforma clinica on-premise con LLM locali, RAG su dati FHIR/DICOM, supporto alla diagnosi, follow-up remoto. Architettura progettata per il percorso MDR.

Scopri AIHealth →

Digital Health

Sviluppo di software medicale conforme agli standard normativi CE e MDR. Sistemi di supporto alle decisioni cliniche, integrazione AI nei flussi di lavoro clinici.

Scopri →

Il problema: dati sanitari distribuiti e non condivisibili

L’addestramento di modelli di AI in medicina richiede grandi volumi di dati. Ma i dati sanitari sono distribuiti tra centri (ospedali, laboratori, reparti) e difficili da centralizzare per motivi tecnici, organizzativi, normativi (GDPR art. 9, HIPAA, normative nazionali sui dati di cura). Il paradosso: l’AI medica ha bisogno di dati multi-centrici; i sistemi sanitari non possono condividerli.

Una risposta a questo paradosso è il Federated Learning (FL) — termine coniato da H. Brendan McMahan et al. (Google, 2016-2017) nel paper “Communication-Efficient Learning of Deep Networks from Decentralized Data” (FedAvg, 2017). L’idea base: invece di portare i dati al modello, portare il modello ai dati.

Come funziona

Il workflow tipico:

1. Un server coordinatore distribuisce un modello iniziale a N client (ciascuno un centro sanitario con dati locali)
2. Ogni client esegue training locale per un numero di epoche sul proprio dataset
3. Ogni client invia al server i pesi aggiornati (non i dati)
4. Il server aggrega i pesi (media pesata, tipicamente FedAvg) per produrre un nuovo modello globale
5. Il processo si ripete per R round fino a convergenza

I dati individuali non lasciano mai il centro. Il server vede solo aggregati di pesi — che possono essere ulteriormente protetti con Secure Aggregation (crittografia) e Differential Privacy (rumore aggiunto).

L’articolo seminale in medicina

Rieke, Hancox, Li et al. (2020), pubblicato in npj Digital Medicine con il titolo “The future of digital health with federated learning”, è l’articolo di riferimento che stabilisce il FL come paradigma credibile per l’AI clinica multicentrica. Gli autori — Nicola Rieke (NVIDIA), Jonny Hancox (NVIDIA), Wenqi Li (NVIDIA), e collaboratori da KCL, Penn, UCLA — articolano use case e sfide.

Applicazioni tipiche:

• Segmentazione di tumori cerebrali addestrata su volumi RM di 20 ospedali senza condividerli
• Triage radiografico per COVID-19 con modelli addestrati su dataset di più nazioni
• Rilevazione di fratture ossee addestrata su centinaia di ospedali
• Analitica clinica su cartelle cliniche di più sistemi sanitari

Framework open source

L’ecosistema dei framework FL al settembre 2021:

Flower (flwr.org)

Sviluppato da Daniel J. Beutel, Taner Topal, Akhil Mathur, Nicholas Lane e altri al Cambridge University e collaboratori. Pubblicato come open source nel 2020 (arXiv preprint “Flower: A Friendly Federated Learning Research Framework”, Beutel et al. 2020). Licenza Apache 2.0. Caratteristiche:

• Framework-agnostic — supporta PyTorch, TensorFlow, JAX, scikit-learn
• Strategy pluggable — FedAvg di default, ma facilmente sostituibile con FedProx, FedOpt, custom
• Linguaggi client: Python, Android (Kotlin), iOS (Swift)
• Scalabilità da simulazioni a centinaia di client reali

FATE (fate.fedai.org)

Sviluppato da WeBank (Cina) a partire dal 2019. Uno dei primi framework FL production-grade. Licenza Apache 2.0. Caratteristiche:

• Orientato alle pipeline industriali (FinTech, healthcare)
• Supporta vertical FL (dati dello stesso paziente distribuiti tra istituti per tipologia — genomica in un centro, clinico in un altro) oltre al classico horizontal FL
• Secure computation integrata
• Installazione complessa ma feature-rich

PySyft (openmined.org)

Sviluppato dalla community OpenMined, attivo dal 2017. Licenza Apache 2.0. Caratteristiche:

• Focus sulla privacy: differential privacy, secure multi-party computation (SMPC), homomorphic encryption
• Tensori remoti — un pattern di programmazione che fa sembrare i tensori distribuiti come locali
• PySyft 0.x maturo, v1.0+ in sviluppo

TensorFlow Federated (TFF)

Sviluppato da Google dal 2019. Licenza Apache 2.0. Parte dell’ecosistema TensorFlow. Limite: lega-dipendente da TF2 stack, meno popolare per medicina che usa prevalentemente PyTorch.

OpenFL (openfl.io)

Sviluppato da Intel e rilasciato nel marzo 2021. Licenza Apache 2.0. Pensato per contesti enterprise con supporto SGX. Usato nel progetto Federated Tumor Segmentation (FeTS) della University of Pennsylvania — una delle prime evaluation FL a scala di BraTS data.

NVIDIA Clara Train FL

Parte dello stack Clara (commerciale ma con componenti open source). Molto usato in sanità per deployment NVIDIA-based.

Primi casi medici su larga scala

Al 2021, alcuni progetti sanitari FL di rilievo:

• EXAM (EMR CXR AI Model) — progetto NVIDIA con 20 ospedali di 5 continenti, febbraio-aprile 2021, per predizione di severità e mortalità COVID-19 da radiografia toracica + cartella. Pubblicato in Nature Medicine 2021, dimostra che FL produce modelli più generalizzabili di singoli centri
• Federated Tumor Segmentation (FeTS) Challenge 2021 — prima challenge federata per segmentazione di tumori cerebrali, con OpenFL come infrastruttura, coordinata da University of Pennsylvania (Spyridon Bakas)
• MELLODDY — consorzio EU IMI, drug discovery federata, 2019-2022, 10 società farmaceutiche senza condividere dati proprietari
• ACR AI-LAB — American College of Radiology piattaforma FL per imaging diagnostico

Vantaggi e sfide

Vantaggi per la sanità

• Compliance GDPR/HIPAA: dati non escono dal centro
• Accesso a dati più grandi: modelli addestrati su 10-100x più dati di quanti un singolo centro potrebbe accedere
• Generalizzazione: modelli che funzionano su popolazioni diverse
• Minor bias dataset-specifico: la diversità multi-sito migliora la robustezza

Sfide tecniche

• Non-IID data: i dati tra ospedali non sono indipendenti e identicamente distribuiti (scanner diversi, protocolli diversi, popolazioni diverse); convergenza di FedAvg può degradare
• Ottimizzatori federati: FedProx, FedOpt, SCAFFOLD, FedNova affrontano il problema non-IID
• Communication overhead: trasferire pesi di modelli grandi tra client e server costa banda
• Privacy attacks: l’inversione dei gradienti può ricostruire dati di training; DP e SecAgg sono contromisure ma con trade-off di accuracy
• Sicurezza bizantina: client malevoli possono avvelenare il training
• Heterogeneity client: client con risorse computazionali diverse (ospedale grande vs. piccolo)

Sfide organizzative

• Governance multi-parte: chi possiede il modello aggregato, chi decide la strategia, chi pubblica
• Data harmonization preliminare: i dati devono essere omogenei in formato (FHIR, DICOM standardizzato, ontologie concettuali comuni)
• Coordinamento: partire un progetto FL richiede allineamento legale, etico, tecnico tra decine di partner
• Certificazione: un modello FL prodotto da N ospedali come dispositivo medico ha responsabilità regolatorie distribuite

GDPR e FL

Il rapporto tra FL e GDPR è articolato. FL è allineato con i principi del GDPR (minimizzazione, privacy by design) ma non è una tecnologia che elimina automaticamente gli obblighi:

• I dati locali dei centri restano soggetti a GDPR
• I pesi aggregati potrebbero contenere informazione residua sui dati (secondo alcuni attacchi noti); il loro trasferimento richiede valutazione
• La DPIA (Data Protection Impact Assessment) è sempre necessaria
• Servono accordi tra titolari (DPA) per il modello cooperativo

Il European Data Protection Board e il Garante italiano stanno producendo linee guida su FL — non ancora definitive al 2021.

Nel contesto italiano ed europeo

Al 2021 la partecipazione italiana a progetti FL è ancora sperimentale:

• Alcuni IRCCS partecipano a consorzi EU IMI con componenti FL
• Università e Politecnici italiani fanno ricerca su protocolli FL
• Progetti EU — Horizon 2020 e Horizon Europe includono bandi su federated health data analytics
• Il tema EHDS, in discussione a livello UE, include accenni a FL come possibile meccanismo di secondary use compliant

Prospettive

Le direzioni attese nei prossimi anni:

• MONAI Federated — il consorzio MONAI sta discutendo l’integrazione FL in un sotto-progetto dedicato
• Regolatori che accolgono FL — FDA ha già linee guida preliminari sull’uso di FL per modelli AI/ML; EU MDR dovrà articolare il tema
• Standardizzazione dei protocolli di aggregazione — verso interoperabilità tra framework FL
• Cross-device vs. cross-silo — la sanità è tipicamente cross-silo (pochi client, molti dati ciascuno); molti sviluppi recenti sono focalizzati qui
• Fairness and bias auditing in FL — come assicurare che modelli FL non abbiano bias specifici di singoli siti
• Synthetic data sharing come complemento — generare dati sintetici simili a quelli reali come alternativa/complemento al FL

Il FL al 2021 è nella fase “early adoption production” in sanità: i primi deployment reali producono risultati misurabili, gli strumenti open source sono maturi, ma l’adozione sistemica richiede ancora anni di infrastruttura organizzativa, regolatoria, culturale. La traiettoria è solida e il tema sarà centrale nel dibattito sui dati sanitari europei dei prossimi anni.

Riferimenti: McMahan et al., “Communication-Efficient Learning of Deep Networks from Decentralized Data” (2017). Rieke et al., “The future of digital health with federated learning”, npj Digital Medicine (2020). Flower (flower.dev). FATE (fate.fedai.org), WeBank. PySyft (OpenMined). TensorFlow Federated (Google). OpenFL (Intel, 2021). EXAM Study, Nature Medicine 2021. MELLODDY, IMI.