In un laboratorio clinico automatizzato il modello predittivo è il pezzo meno vincolato di tutta la catena: i vincoli veri stanno nei protocolli con cui i dati lo raggiungono e lo lasciano. Ho lavorato all’ingegnerizzazione cloud di una pipeline diagnostica per un sistema di Total Laboratory Automation (TLA, automazione totale del laboratorio): sull’architettura dei dati ho speso un ordine di grandezza in più del tempo speso sul modello.

Contesto

Un sistema TLA collega i moduli pre-analitici, gli analizzatori e i moduli post-analitici lungo un binario fisico che movimenta le provette. Il sistema di automazione (LAS, Laboratory Automation System) dialoga con il sistema informativo di laboratorio (LIS, Laboratory Information System) e con gli analizzatori attraverso pochi standard consolidati: CLSI LIS01-A2 per il trasporto a basso livello, CLSI LIS02-A2 — la revisione di ASTM E1394-97 — per il formato dei messaggi orientato ai record, e HL7 v2.x (in particolare il capitolo 13, Clinical Laboratory Automation) per l’integrazione tra LAS e LIS. Sono standard nati per scambiare ordini, stati di provetta e risultati strutturati, non per consegnare il vettore di feature che un modello di apprendimento automatico si aspetta.

Inserire una predizione in questo flusso vuol dire allora due cose: ricavare dai messaggi un input coerente per il modello, e rimettere l’output in un formato che il LIS legga come un risultato qualunque, con la stessa tracciabilità di una misura strumentale.

Architettura

La pipeline ha quattro stadi disaccoppiati: data collecting, pre-processing, post-processing, delivery. Il modello vive solo tra il secondo e il terzo. Il disaccoppiamento non è una scelta estetica: serve a versionare il pre-processing separatamente dal modello, condizione perché lo stesso input grezzo si possa rielaborare quando il modello cambia.

  • Data collecting: i record LIS02-A2 e i messaggi HL7 in arrivo dagli analizzatori e dal middleware vengono normalizzati in uno schema interno stabile. Qui si concentra il grosso del lavoro che non si automatizza: ogni analizzatore implementa lo standard a modo suo (campi opzionali, codifiche locali degli analiti, ordine dei record), e la pipeline deve assorbire queste varianti senza propagarle a valle.
  • Pre-processing: validazione, gestione dei valori mancanti, costruzione del vettore di feature. Lo stadio scrive l’input esatto passato al modello, non solo il risultato: senza l’input persistito una predizione non è riproducibile.
  • Post-processing: l’output del modello (un punteggio con il suo livello di confidenza) viene correlato agli altri risultati della stessa provetta e qualificato. Una predizione senza metadati sulla versione del modello e sulla finestra di confidenza non serve a chi referta.
  • Delivery: il risultato torna verso i sistemi a valle nello stesso formato dei risultati strumentali, così che il LIS non distingua, a livello di trasporto, una misura da una predizione — pur potendole distinguere a livello semantico.

L’infrastruttura è containerizzata con Docker e gira sia in cloud sia on-premise. In molti laboratori il vincolo on-premise non è negoziabile: i dati di un campione non escono dal perimetro dell’ospedale, e l’architettura deve trattare il cloud come una configurazione di deploy, non come una dipendenza.

Il punto critico

Il vincolo che ordina tutta la progettazione è la latenza che il binario concede. In un sistema TLA la provetta è in movimento, e un risultato deve uscire entro la finestra in cui il campione si può ancora indirizzare a valle. Un’inferenza che arriva dopo è inutile quanto un’inferenza sbagliata: il sistema deve degradare in modo prevedibile, cioè portare avanti il flusso fisico anche quando la predizione manca, senza mai bloccare il binario in attesa del modello.

Da qui la regola che ha guidato le scelte implementative: la predizione è un risultato in più, con un proprio budget di tempo, non un passo obbligato della catena. Il delivery è disaccoppiato dall’inferenza tramite una coda; se il modello non risponde entro il budget, il campione viene refertato lo stesso con i soli risultati strumentali, e la predizione tardiva viene scartata o registrata come fuori finestra. Questo sposta una parte della complessità dal modello all’orchestrazione, ed è la parte di lavoro che pesa di più sull’affidabilità percepita del sistema.

Implicazioni

Il fine tuning di un modello di predizione su dataset clinici reali — l’ottimizzazione di sensibilità e specificità — è un problema vero ma circoscritto: si misura su un test set e si itera. Il problema che non si chiude allo stesso modo è il monitoraggio dopo il deploy. La distribuzione dei dati in ingresso si sposta: cambia il parco analizzatori, cambiano i lotti di reagenti, cambia la popolazione di pazienti. Senza una misura continua dello scarto tra la distribuzione di addestramento e quella di esercizio (data drift), le metriche dichiarate al collaudo descrivono un sistema che dopo qualche mese non esiste più. La letteratura sul deployment di modelli in sanità converge qui: validazione esterna e monitoraggio continuo sono requisiti, non opzioni, e la pipeline deve conservare abbastanza contesto da ricostruire a posteriori come si è arrivati a una certa predizione.

C’è poi il vincolo regolatorio. Dal 26 maggio 2022 il Regolamento (UE) 2017/746 (IVDR) è pienamente applicabile, e il software che concorre a una finalità diagnostica può ricadere nella definizione di dispositivo medico-diagnostico in vitro, con la classificazione di rischio dell’Allegato VIII. Non è un dettaglio amministrativo a valle: condiziona l’architettura, perché impone di tracciare la versione del modello e i dati su cui ha operato, e quindi rende la persistenza dell’input e dei metadati una proprietà che dalla pipeline non si può togliere.

Limiti

Niente di tutto questo dice se il modello sia clinicamente utile: integrare bene un modello mediocre dà predizioni mediocri consegnate in modo affidabile. La separazione netta tra qualità del modello e qualità dell’integrazione regge finché il pre-processing è stabile; quando il vettore di feature dipende da scelte che il modello stesso induce, i due piani si intrecciano e il disaccoppiamento qui descritto va rinegoziato. Infine, la robustezza dell’orchestrazione descritta è verificata sui modi di guasto previsti — timeout, messaggi malformati, analizzatore non standard — e non su quelli che un esercizio prolungato farà emergere e che, per definizione, non sono ancora stati osservati.

Il lavoro su INPECO — fine tuning del modello diagnostico e ingegnerizzazione della piattaforma cloud — è documentato nell’insight di noze: https://www.noze.it/insights/inpeco-ai-diagnostica-cloud/.

Immagine di copertina: Analizzatore ematologico clinico con provette di sangue dal tappo viola in rack pronte all’analisi, lettore di codice a barre acceso… — foto di Ptrump16, CC BY-SA 4.0 — https://commons.wikimedia.org/wiki/File:Sysmex_XT-4000i.jpg