Sviluppare un algoritmo capace di riconoscere una lesione, segmentare un organo o estrarre automaticamente una misurazione da un’immagine diagnostica è un risultato importante. Tuttavia, non significa ancora avere costruito un prodotto utilizzabile in un ospedale, all’interno di una piattaforma medicale o come componente di un dispositivo diagnostico.
Nel medical imaging, la distanza tra un modello sperimentale e una soluzione operativa è spesso molto più ampia di quanto appaia durante le prime fasi del progetto.
Una pipeline AI può funzionare perfettamente su un dataset selezionato, all’interno di un notebook o di un ambiente di sviluppo controllato. Può ricevere una serie di immagini, completare l’inferenza e restituire una segmentazione, una probabilità o un file JSON. Quando la stessa tecnologia deve però entrare in un workflow clinico reale, emergono problemi di natura completamente diversa.
Da dove arrivano le immagini? Come viene identificata la serie corretta? Cosa succede quando uno studio è incompleto? Come si gestiscono più algoritmi contemporaneamente? In quale formato deve essere restituito il risultato? Come viene visualizzato dal medico? Come si può ricostruire, mesi dopo, quale versione del modello abbia prodotto una determinata analisi?
Industrializzare l’AI nel medical imaging significa rispondere a queste domande e trasformare un algoritmo in un sistema affidabile, integrabile, tracciabile e monitorabile.
Un buon modello AI non è ancora un prodotto medicale
Uno degli equivoci più comuni nei progetti di intelligenza artificiale applicata alla radiologia consiste nel far coincidere la qualità dell’algoritmo con la maturità complessiva della soluzione.
Le metriche ottenute durante la validazione del modello sono certamente fondamentali. Sensibilità, specificità, accuratezza, Dice score e capacità di generalizzazione descrivono il comportamento dell’algoritmo rispetto al problema per cui è stato sviluppato. Non descrivono, però, tutto ciò che serve per utilizzare quel modello all’interno di un processo operativo.
Un prodotto deve innanzitutto essere capace di ricevere i dati senza richiedere ogni volta un intervento manuale. Deve comprendere quali immagini elaborare, verificare che siano compatibili, avviare il modello corretto e gestire eventuali anomalie. Deve inoltre restituire l’output in un formato che possa essere archiviato, visualizzato e interpretato dagli altri sistemi coinvolti.
Il modello AI rappresenta quindi un componente centrale, ma rimane soltanto uno dei componenti.
Intorno ad esso devono essere costruiti servizi di integrazione, orchestrazione, sicurezza, visualizzazione e monitoraggio. È questa infrastruttura a determinare se l’algoritmo possa rimanere un proof of concept oppure evolvere in una soluzione realmente adottabile.
Il workflow inizia prima dell’inferenza
Quando si parla di AI nel medical imaging, l’attenzione tende a concentrarsi sulla fase di inferenza. In realtà, una parte significativa della complessità si trova prima ancora che il modello venga eseguito.
Le immagini possono arrivare direttamente da una modalità diagnostica, da un PACS, da un VNA, da un archivio locale o da una piattaforma cloud. A seconda dell’infrastruttura disponibile, l’integrazione può utilizzare i tradizionali servizi DICOM DIMSE oppure le più recenti API DICOMweb.
In entrambi i casi, ricevere uno studio non significa semplicemente copiare una cartella di file.
La struttura informativa DICOM deve essere preservata. Paziente, studio, serie e singole istanze sono collegati attraverso identificativi specifici. Orientamento, spaziatura, frame of reference, transfer syntax, compressione e gestione delle immagini multiframe possono influire direttamente sul risultato dell’elaborazione.
Due studi apparentemente simili possono inoltre essere stati prodotti da dispositivi differenti, con protocolli differenti o con metadati valorizzati in modo non uniforme. Anche piccole variazioni possono avere conseguenze importanti.
Un algoritmo sviluppato per una serie CT assiale con un determinato spessore di strato potrebbe non essere adatto a una ricostruzione differente. Un modello pensato per immagini con contrasto potrebbe generare risultati inaffidabili su acquisizioni senza contrasto. Una serie incompleta potrebbe essere tecnicamente leggibile, ma non sufficiente per l’analisi prevista.
Per questo motivo, il primo livello di una piattaforma AI deve occuparsi non solo del trasporto dei dati, ma anche della loro validazione e normalizzazione.
Capire se uno studio può essere elaborato
Prima di avviare un modello è necessario stabilire se lo studio ricevuto sia effettivamente compatibile con il suo ambito di utilizzo.
Una prima classificazione può essere effettuata attraverso i metadati DICOM. Campi come Modality, Body Part Examined, Study Description, Series Description, Protocol Name e Slice Thickness possono aiutare a identificare il contenuto dello studio e a selezionare la pipeline appropriata.
Nella pratica, però, questi valori non sono sempre affidabili.
Le descrizioni possono cambiare tra ospedali, produttori e installazioni. Lo stesso protocollo può essere nominato in modi differenti, mentre campi teoricamente standardizzati possono essere lasciati vuoti o valorizzati con convenzioni locali.
Una pipeline robusta non dovrebbe quindi dipendere esclusivamente da una singola informazione. È spesso necessario combinare regole deterministiche, mapping configurabili, caratteristiche geometriche delle immagini e, in alcuni casi, ulteriori modelli di classificazione.
Il sistema deve saper riconoscere non soltanto gli studi compatibili, ma anche le condizioni in cui l’elaborazione non dovrebbe essere avviata. Uno studio potrebbe essere incompleto, duplicato, già processato oppure composto da serie non idonee. In altri casi potrebbe essere necessario richiedere una verifica umana.
Questa fase è essenziale perché impedisce al modello di produrre risultati apparentemente validi a partire da input che non rispettano le condizioni previste.
L’orchestrazione è il cuore della piattaforma
Una volta identificato lo studio corretto, entra in gioco l’orchestrazione del workflow AI.
L’orchestratore coordina l’intero processo, dalla preparazione dei dati fino alla restituzione del risultato. Non si limita ad avviare un container o a chiamare un endpoint: deve conoscere lo stato dell’elaborazione, gestire dipendenze, controllare timeout, riconoscere errori temporanei e decidere quando riprovare.
Un singolo studio può richiedere più passaggi consecutivi. Prima dell’inferenza potrebbe essere necessario convertire le immagini, normalizzare i valori, identificare una regione anatomica o ricostruire un volume. Dopo l’esecuzione del modello potrebbero essere necessari controlli di coerenza, calcoli aggiuntivi, conversioni di formato e operazioni di post-processing.
In alcuni casi, più algoritmi devono lavorare sullo stesso studio.
Una prima pipeline può segmentare una struttura anatomica. Una seconda può estrarre misurazioni dalla segmentazione. Una terza può classificare la patologia o generare un modello tridimensionale. Il risultato complessivo dipende quindi dalla corretta esecuzione e combinazione di più componenti.
L’orchestratore deve mantenere il controllo di questa sequenza, sapendo quale passaggio sia stato completato, quale sia fallito e quali output siano stati prodotti.
L’utilizzo di code di messaggi consente di separare la ricezione degli studi dall’elaborazione vera e propria. Questo rende il sistema più resiliente, permette di assorbire picchi di carico e facilita la distribuzione dei job su risorse CPU o GPU differenti.
La containerizzazione dei modelli offre invece isolamento, riproducibilità e una gestione più controllata delle dipendenze. Ogni algoritmo può essere distribuito con il proprio ambiente, senza obbligare l’intera piattaforma a utilizzare le stesse librerie o versioni software.
Dove entra in gioco l’Agentic AI
L’Agentic AI può aggiungere un ulteriore livello di flessibilità all’interno di questo scenario.
In un’architettura tradizionale, ogni passaggio viene definito attraverso regole e workflow prestabiliti. Questo approccio rimane fondamentale nei processi che richiedono determinismo, prevedibilità e tracciabilità. Esistono però attività in cui la sequenza delle operazioni può dipendere dal contesto specifico.
Un agente software può analizzare le informazioni disponibili, selezionare strumenti differenti e coordinare servizi specializzati.
Nel medical imaging, un agente potrebbe verificare la completezza dello studio, identificare la pipeline più appropriata, recuperare informazioni cliniche da un sistema esterno e richiedere l’esecuzione di più modelli. Potrebbe quindi controllare che gli output siano coerenti, preparare una bozza di report e creare un task per la revisione da parte di un operatore.
Il valore dell’approccio agentico non consiste nel sostituire il modello diagnostico o nel delegare a un sistema generativo decisioni cliniche non controllate. Consiste piuttosto nel collegare tra loro componenti diversi e automatizzare attività che oggi richiedono numerosi passaggi manuali.
Questa flessibilità deve comunque essere governata.
Ogni azione compiuta dall’agente dovrebbe essere registrata. Devono essere note le informazioni utilizzate, gli strumenti richiamati e le condizioni che hanno determinato una scelta. Quando vengono impiegati modelli linguistici, è necessario tenere traccia anche delle versioni, dei prompt e delle configurazioni.
L’Agentic AI può quindi diventare un livello di orchestrazione intelligente, ma deve operare all’interno di confini espliciti e controllabili.
Il medico deve poter comprendere e revisionare il risultato
In molti contesti clinici, l’AI non sostituisce l’operatore, ma prepara un risultato che deve essere verificato.
Un algoritmo può evidenziare una regione sospetta, calcolare una misura, segmentare una struttura o proporre una classificazione. Il medico deve però poter confrontare l’output con le immagini originali, valutarne la correttezza ed eventualmente modificarlo.
Per questo motivo, il viewer non è un elemento accessorio della piattaforma.
L’interfaccia deve consentire di visualizzare immagini, segmentazioni, heatmap, misurazioni e modelli tridimensionali nello stesso contesto. Se l’algoritmo produce una maschera, l’utente dovrebbe poterla correggere. Se viene proposta una misura, dovrebbe essere possibile verificarne i riferimenti anatomici. Se viene generata una bozza di report, deve essere chiaro quali informazioni derivino dall’AI e quali siano state approvate dall’operatore.
Il workflow human in the loop permette di mantenere il controllo clinico e, contemporaneamente, raccogliere dati preziosi sul comportamento del sistema.
Le correzioni effettuate dagli utenti possono essere analizzate per identificare errori ricorrenti, protocolli problematici o categorie di casi in cui il modello è meno affidabile. Queste informazioni possono alimentare attività di quality assurance e, attraverso processi controllati, contribuire alla creazione di nuovi dataset e al miglioramento delle versioni successive.
L’interazione tra AI e operatore non rappresenta quindi soltanto una misura di sicurezza. È anche una fonte strutturata di feedback.
Il risultato deve rientrare nel workflow clinico
Uno dei passaggi più delicati nell’industrializzazione dell’AI nel medical imaging riguarda la restituzione del risultato.
Durante lo sviluppo, una segmentazione può essere salvata come file NIfTI, una previsione può essere esportata in JSON e una tabella può essere generata in CSV. Questi formati possono essere perfettamente adeguati per la ricerca o per la comunicazione tra componenti interni, ma non sempre sono utilizzabili dai sistemi clinici.
Per essere realmente integrato, il risultato deve mantenere il legame con le immagini sorgenti e con il contesto dello studio.
Il DICOM Segmentation Object, o DICOM SEG, consente di rappresentare segmentazioni associate alle immagini originali. Oltre alla geometria della maschera, può contenere informazioni sulla struttura segmentata, sul metodo utilizzato e sull’algoritmo che ha prodotto il risultato.
Questo permette di archiviare la segmentazione nel PACS e di visualizzarla in un viewer compatibile, preservando i riferimenti spaziali.
Quando l’algoritmo produce misure, score o osservazioni strutturate, il DICOM Structured Reporting può rappresentare queste informazioni in modo più ricco rispetto a un semplice testo. Misure e risultati possono essere collegati a immagini, coordinate e regioni anatomiche specifiche.
In altri scenari può essere sufficiente generare una DICOM Secondary Capture, ad esempio per archiviare un’immagine derivata o una rappresentazione grafica. Si tratta di una soluzione generalmente semplice da integrare, ma meno strutturata e meno riutilizzabile rispetto a DICOM SEG e DICOM SR.
FHIR può invece essere utilizzato per portare il risultato nel contesto clinico più ampio. Risorse come DiagnosticReport, Observation, ImagingStudy e Task consentono di collegare l’output dell’elaborazione a referti, ordini, workflow applicativi e sistemi informativi.
DICOM e FHIR non svolgono necessariamente la stessa funzione. DICOM rimane centrale per le immagini e le informazioni geometriche, mentre FHIR può facilitare l’integrazione del risultato con il resto dell’ecosistema sanitario.
La scelta del formato non dovrebbe quindi essere effettuata soltanto in base alla comodità dello sviluppatore. Deve dipendere da come il risultato verrà utilizzato, archiviato, visualizzato e scambiato.
Il deployment non è la fine del progetto
Una volta completata l’integrazione e avviato il sistema, inizia una nuova fase: il monitoraggio.
L’infrastruttura deve essere osservabile. È necessario sapere se i servizi siano disponibili, quanto tempo richieda ogni elaborazione, quante risorse vengano utilizzate e se le code stiano crescendo. Errori di rete, indisponibilità temporanee del PACS o problemi nell’accesso alla GPU devono essere rilevati prima che compromettano il workflow.
Accanto al monitoraggio tecnico deve esistere un monitoraggio operativo.
La piattaforma dovrebbe mostrare quanti studi siano stati ricevuti, quanti siano stati elaborati correttamente e quanti siano stati rifiutati. È utile conoscere la durata media dei job, il numero di retry, la distribuzione per modalità e le cause più frequenti di errore.
Il livello più complesso riguarda però il comportamento del modello nel tempo.
Un algoritmo validato su una determinata popolazione può incontrare difficoltà quando viene utilizzato in un nuovo ospedale, su dispositivi differenti o con protocolli di acquisizione diversi. Anche un aggiornamento software della modalità o una modifica nell’algoritmo di ricostruzione può alterare la distribuzione degli input.
Per questo motivo è importante osservare la qualità delle immagini ricevute, la distribuzione dei risultati, il livello di confidenza e le correzioni effettuate dagli operatori. Variazioni significative possono indicare la presenza di data drift o performance drift.
Monitorare un modello non significa necessariamente conoscere subito la verità clinica per ogni singolo caso. Significa costruire indicatori che permettano di riconoscere cambiamenti e anomalie prima che diventino problemi sistematici.
Versioning e audit rendono il sistema riproducibile
Ogni risultato prodotto dalla piattaforma dovrebbe poter essere ricostruito.
Non basta conoscere il nome dell’algoritmo. È necessario sapere quale versione del modello sia stata utilizzata, con quale configurazione, quali operazioni di preprocessing siano state applicate e quale versione del software abbia gestito il workflow.
Anche il post-processing può cambiare il risultato finale. Soglie, regole di filtraggio, conversioni geometriche e terminologie utilizzate devono quindi essere versionate insieme al modello.
Nel caso dell’Agentic AI, la tracciabilità deve includere anche le istruzioni fornite al sistema, gli strumenti utilizzati e le decisioni prese durante l’esecuzione.
Un audit log completo permette di comprendere chi abbia avviato un processo, da quale sistema sia arrivato lo studio, quali controlli siano stati effettuati, quali errori si siano verificati e chi abbia revisionato il risultato.
Queste informazioni sono fondamentali durante le attività di validazione, manutenzione e quality assurance. Diventano ancora più importanti quando il modello viene aggiornato, perché consentono di confrontare il comportamento di versioni differenti sugli stessi dati.
La riproducibilità non è soltanto un requisito tecnico. È ciò che permette di spiegare come sia stato ottenuto un risultato e di investigare in modo strutturato eventuali anomalie.
Sicurezza: le immagini sono dati, ma anche input software
I file di medical imaging devono essere trattati come input provenienti da sistemi esterni.
Un oggetto DICOM può contenere sequenze complesse, dati compressi, campi privati e strutture prodotte da implementazioni differenti. Le librerie utilizzate per leggere, decodificare e convertire questi dati fanno parte della superficie di attacco della piattaforma.
Una soluzione industrializzata deve quindi validare gli input, applicare limiti alle dimensioni, utilizzare timeout e isolare i processi più esposti. Le dipendenze, in particolare quelle native, devono essere monitorate e aggiornate.
Anche i modelli AI dovrebbero essere eseguiti in ambienti separati, con accesso limitato ai dati e ai servizi strettamente necessari.
Il collegamento con PACS, VNA e sistemi ospedalieri deve seguire lo stesso principio. Ogni componente dovrebbe poter eseguire soltanto le operazioni richieste dal proprio ruolo, evitando accessi estesi o credenziali condivise.
A questo si aggiungono cifratura, controllo degli accessi, gestione dei secret, segregazione degli ambienti e registrazione degli eventi.
La sicurezza non può essere aggiunta soltanto al termine del progetto. Deve essere integrata nell’architettura fin dalle prime fasi.
Una possibile architettura per l’AI nel medical imaging
Una piattaforma completa può essere suddivisa in diversi livelli, ciascuno con responsabilità chiare.
Alla base si trovano le modalità diagnostiche, il PACS, il VNA, il RIS e gli altri sistemi clinici. Il livello di integrazione riceve immagini e informazioni attraverso DICOM, DICOMweb, HL7, FHIR o API proprietarie.
Gli studi vengono quindi validati, classificati e inviati all’orchestratore. Quest’ultimo coordina i job, gestisce le priorità e seleziona i modelli disponibili.
L’inferenza viene eseguita da servizi isolati, spesso containerizzati, che possono utilizzare risorse CPU o GPU. Gli output vengono raccolti da un livello di gestione dei risultati, responsabile della conversione in DICOM SEG, DICOM SR, Secondary Capture, FHIR o altri formati.
Il viewer permette la visualizzazione e la revisione clinica, mentre i sistemi di monitoraggio raccolgono metriche, log, versioni e informazioni di audit.
Modalità / PACS / VNA / RIS / EHR
|
v
Integration & DICOM Gateway
|
v
Workflow Orchestrator
|
v
AI Execution Services
|
v
Results Management
|
v
Viewer e validazione clinica
|
v
Monitoring, audit e governance
La separazione tra questi livelli rende l’architettura più modulare.
Un nuovo modello può essere aggiunto senza modificare necessariamente il gateway DICOM o il viewer. Allo stesso modo, l’integrazione con un nuovo PACS può essere gestita senza intervenire sull’algoritmo.
Questa modularità è ciò che permette alla piattaforma di evolvere nel tempo senza trasformarsi in un insieme fragile di integrazioni ad hoc.
Costruire tutto internamente o utilizzare componenti esistenti?
Le aziende che sviluppano algoritmi AI si trovano spesso davanti a una decisione strategica: costruire internamente l’intera piattaforma oppure integrare tecnologie già disponibili.
Realizzare da zero tutti i componenti richiede competenze che vanno molto oltre il machine learning. Servono conoscenze di DICOM e PACS, sviluppo backend, infrastrutture cloud e on-premise, visualizzazione medicale, cybersecurity, interoperabilità e gestione operativa dei modelli.
Il rischio è che una parte significativa delle risorse venga assorbita da attività infrastrutturali, distogliendo l’attenzione dall’algoritmo e dal valore clinico specifico del progetto.
Dall’altra parte, piattaforme eccessivamente standardizzate possono risultare difficili da adattare a dispositivi proprietari, workflow specialistici o processi clinici particolari.
L’approccio più efficace è spesso ibrido.
I componenti consolidati possono essere riutilizzati per la connettività, la visualizzazione e l’orchestrazione di base. Gli elementi realmente distintivi, come il modello, il workflow specialistico o l’interazione con uno specifico dispositivo, possono invece essere sviluppati su misura.
L’obiettivo non dovrebbe essere costruire tutto internamente, ma mantenere il controllo sui componenti strategici ed evitare dipendenze che limitino l’evoluzione del prodotto.
Dal proof of concept a un sistema realmente utilizzabile
Le prestazioni del modello rimangono un elemento fondamentale, ma non sono sufficienti a determinare il successo di una soluzione AI nel medical imaging.
Un sistema utilizzabile deve essere capace di integrarsi con l’infrastruttura esistente, gestire dati reali, affrontare errori e variazioni, restituire risultati interoperabili e supportare il lavoro dell’operatore.
Deve inoltre essere osservabile, aggiornabile e tracciabile.
Il vero passaggio dal prototipo al prodotto avviene quando l’algoritmo smette di essere una pipeline isolata e diventa parte di un workflow più ampio.
Il vantaggio competitivo non consiste quindi soltanto nel possedere un modello accurato. Consiste nella capacità di distribuirlo, integrarlo, monitorarlo e farlo evolvere all’interno di processi clinici e tecnologici reali.
Nel medical imaging, l’algoritmo è soltanto l’inizio.
Come D/Vision Lab supporta l’industrializzazione dell’AI medicale
D/Vision Lab affianca aziende medtech, produttori di dispositivi e sviluppatori di algoritmi nella trasformazione di prototipi e modelli AI in piattaforme software integrate.
Il lavoro può partire dalla connettività DICOM e dall’integrazione con PACS e VNA, per arrivare all’orchestrazione delle pipeline, alla containerizzazione dei modelli e allo sviluppo di interfacce web per la visualizzazione 2D e 3D.
Particolare attenzione viene dedicata alla gestione dei risultati, che possono essere convertiti in oggetti DICOM strutturati, integrati tramite FHIR o resi disponibili all’interno di viewer e workflow human in the loop.
A seconda del progetto, l’architettura può essere distribuita in cloud, on-premise o attraverso un modello ibrido, mantenendo separati i componenti di integrazione, inferenza, visualizzazione e monitoraggio.
L’obiettivo non è semplicemente eseguire un algoritmo.
È costruire intorno ad esso l’infrastruttura necessaria perché possa diventare un componente affidabile, scalabile e interoperabile di un ecosistema medicale reale.
