Un modello di machine learning addestrato su immagini radiologiche o cartelle cliniche non diventa software clinico perché raggiunge una buona accuratezza su un test set: lo diventa quando attraversa tre confini distinti — quello dei sistemi informativi dell’ospedale, quello giuridico sulla residenza del dato, quello regolatorio sull’immissione in commercio. Ciascuno vincola l’architettura di calcolo a modo suo, e quasi sempre tira da una parte diversa da quella che sceglieresti guardando solo i numeri del modello.

Contesto

In un progetto di supporto alle decisioni cliniche lo schema ricorre sempre uguale, facile da raccontare e faticoso da costruire: un modello riceve dati strutturati o immagini dai sistemi dell’ospedale, produce una stima (un punteggio di rischio, una segmentazione, una classificazione), e quella stima torna a un operatore sanitario che la usa o la scarta. Il modello è la parte che capiamo meglio di tutta la catena. I guai cominciano ai bordi: come i dati entrano, dove vengono elaborati, in che forma escono, con quali garanzie documentali.

L’integrazione la dettano due standard che esistono già. Per i dati clinici strutturati il riferimento è HL7 FHIR (Fast Healthcare Interoperability Resources), la cui Release 4 è uscita nel 2019 con una prima parte di contenuto marcato come normativo — fra cui le risorse Patient e Observation. FHIR R4 espone i dati come risorse REST in JSON o XML: chi conosce le API web ha già in mano l’integrazione, ma il problema semantico resta dov’era. Una Observation con il codice LOINC sbagliato è sintatticamente valida e clinicamente inutile. Per le immagini il riferimento resta DICOM (Digital Imaging and Communications in Medicine), con DICOMweb a esporre le stesse primitive su HTTP. Un modello di computer vision in produzione mangia quasi sempre pixel DICOM, non file PNG.

Architettura

La decisione che pesa di più non è quale rete neurale scegliere, ma dove gira l’inferenza rispetto al perimetro dei dati. Nei progetti reali tornano tre configurazioni.

Inferenza on-premise: il modello gira dentro l’infrastruttura dell’ospedale. I dati clinici non escono dal perimetro. Il costo è operativo — aggiornare i modelli, monitorare le prestazioni, gestire l’hardware su decine di siti diversi diventa un problema di distribuzione del software, non di data science.

Inferenza su cloud, con i dati che attraversano il confine: il modello vive su infrastruttura gestita e i dati clinici ci transitano. Il ciclo di vita del modello si semplifica parecchio — un solo punto di aggiornamento, monitoraggio centralizzato — ma il problema si sposta dal piano tecnico a quello giuridico e contrattuale.

Addestramento distribuito senza centralizzare i dati: il federated learning porta il modello verso i dati invece del contrario. Ogni sito addestra in locale, si aggregano solo i parametri (o i loro aggiornamenti). Kaissis e colleghi, su Nature Machine Intelligence a giugno 2020, descrivono nel dettaglio come questa famiglia di tecniche si applica all’imaging medico, e quanto costa: overhead di comunicazione, eterogeneità dei modelli locali, superficie d’attacco aperta dagli aggiornamenti malevoli. La centralizzazione che eviti sul dato grezzo ti ritorna, attenuata, sui gradienti.

Nessuna delle tre è gratis. La scelta è un compromesso fra costo operativo, esposizione del dato e complessità di validazione.

Punto critico

Il vincolo che fissa l’architettura più di ogni altro è la residenza e il trattamento del dato sanitario. Per il GDPR i dati sulla salute sono categoria particolare ai sensi dell’articolo 9: trattamento vietato di default, con un insieme ristretto di deroghe. Vuol dire che “spostiamo l’inferenza sul cloud” non è una decisione di ingegneria. È una decisione che richiede una base giuridica, una valutazione d’impatto e — quando il fornitore di calcolo è terzo — un accordo che qualifichi i ruoli di titolare e responsabile del trattamento.

Sul piano tecnico questo significa disegnare il diagramma di flusso dei dati prima del modello, non dopo. Dove il dato sta in chiaro, dove è cifrato, chi tiene le chiavi, in quale giurisdizione risiede il calcolo: dalle risposte dipende se l’architettura cloud sia anche solo proponibile. Un classificatore eccellente servito da un’infrastruttura che non regge l’analisi di conformità resta un prototipo, non un classificatore in produzione.

Implicazioni

Sul fronte regolatorio, un software che produce stime usate per decisioni cliniche tende a rientrare nella definizione di dispositivo medico (SaMD, Software as a Medical Device). Il 12 gennaio 2021 la FDA statunitense ha pubblicato il suo primo Artificial Intelligence/Machine Learning-Based Software as a Medical Device Action Plan, in risposta ai commenti raccolti sul discussion paper del 2019. Il punto che tocca l’architettura è la nozione di predetermined change control plan: un dispositivo a base ML che si aggiorna nel tempo apre la questione di come autorizzare a priori una classe di modifiche al modello senza ri-sottomettere ogni nuova versione. È un problema architetturale prima che burocratico — vincola come versioni, tracci e congeli i modelli.

In pratica le tre componenti — integrazione FHIR/DICOM, residenza del dato, percorso regolatorio — vanno progettate insieme. Un modello addestrato sui dati di un solo ospedale, validato su quella distribuzione, raramente regge il passaggio a siti con apparecchiature, protocolli e popolazioni diverse. La generalizzazione fra centri è il muro contro cui la maggior parte dei progetti va a sbattere, e quasi mai per colpa del modello: è un problema di dati e di confini.

Limiti

Tutto questo descrive vincoli, non soluzioni. La scelta fra on-premise, cloud e federato dipende da fattori che cambiano per ogni progetto: numero di siti, sensibilità del dato, frequenza con cui si aggiorna il modello, vincoli di latenza, budget operativo. Il federated learning riduce l’esposizione del dato grezzo ma non la azzera, e introduce una complessità di coordinamento che su pochi siti non si ripaga. Il riferimento normativo qui è EU/US a inizio 2021; un progetto reale deve verificare il quadro applicabile alla propria giurisdizione e alla data corrente, perché a quel momento sia la prassi FDA sia quella europea sull’AI in sanità erano in piena evoluzione.

Su come questa trasversalità fra Digital Health, AI e architetture cloud si traduce in una linea di business strutturata si veda l’insight di noze: https://www.noze.it/insights/consolidamento-ai-cloud/.

Immagine di copertina: Sala server con armadi rack allineati e cablaggio strutturato, infrastruttura di calcolo per inferenza on-premise — foto di Carl Lender, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Server_Room_(22397102849).jpg