Quando entriamo in un laboratorio ospedaliero per la prima volta la cosa che colpisce non è il disordine ma è il potenziale.
Strumenti di produttori diversi, generazioni diverse, software diversi, analizzatori che lavorano in parallelo, ciascuno con il proprio linguaggio, la propria interfaccia, il proprio modo di restituire i dati. Qualcuno ha già automatizzato una parte del flusso, qualcun altro a pochi metri di distanza trascrive ancora manualmente i risultati da uno schermo all'altro.
La prima cosa che pensiamo non è "che caos" ma è: "potremmo semplificare tantissimo la vita a chi lavora qui dentro". E quasi sempre, guardandoci intorno, la seconda cosa che pensiamo è: gli strumenti per farlo esistono già oppure li abbiamo già costruiti per qualche altra struttura.
Cos'è un middleware di laboratorio e perché conta davvero
Prima di parlare di ostacoli vale la pena spiegare cosa fa concretamente un middleware in un contesto di laboratorio clinico, non perché sia complicato, ma perché spesso il termine tecnico oscura il beneficio umano.
Un middleware di laboratorio è un software che si posiziona tra gli strumenti analitici e il sistema informativo ospedaliero. Il suo compito è connettere, tradurre, validare, approfondire, allertare e centralizzare.
In pratica, significa:
che un tecnico non deve più copiare manualmente i risultati da un sistema all'altro;
che i dati di strumenti diversi arrivano in un formato coerente e tracciabile;
che le regole di validazione, quelle che definiscono quando un risultato è accettabile o quando richiede un secondo controllo, vengono applicate automaticamente e in modo uniforme;
che il flusso di lavoro diventa misurabile: si può sapere dove si creano i colli di bottiglia, quanto tempo passa tra il prelievo e il referto, quante anomalie vengono intercettate in automatico.
che, nel nostro caso, alert, segnalazioni, identificazione della propagazione dei contagi e analisi epidemiologiche avvengono già con le informazioni aggregate da tutti gli strumenti collegati
Nessuna di queste cose è futuristica, nessuna richiede intelligenza artificiale, blockchain o altri ingredienti da comunicato stampa. È integrazione, automazione di processo e interoperabilità. Un processo concreto che include solo quello che serve, robusto e basato sugli standard.
Eppure, in molti laboratori italiani, questa interoperabilità non c'è ancora, non perché sia impossibile o perché manchino le competenze, ma per ragioni che hanno poco a che fare con la tecnologia.
Il paradosso: la soluzione esiste già
Quando entriamo in un laboratorio e vediamo dieci strumenti analitici, spesso ne conosciamo già otto, abbiamo già implementato i driver necessari e in altri contesti sono già integrati. La configurazione richiede giorni, non anni, perché abbiamo già visto quella stessa combinazione funzionare altrove.
Sappiamo che il tecnico che ogni mattina apre tre schermate diverse per raccogliere dati, potrebbe non farlo più, o che quella procedura manuale di trascrizione fonte di errori, di tempo perso e di frustrazione silenziosa, potrebbe essere eliminata in tempi relativamente brevi.
E tuttavia, molto spesso, non possiamo intervenire. Non perché il personale non voglia ma perché il middleware non rientra in un bando specifico o perché la priorità in quel momento è un altro sistema oppure perché non è chiaro chi debba "firmare" quel tipo di progetto o perché il beneficio atteso è difficile da tradurre in una metrica che compaia in un documento di gara.
Il limite non è tecnico, è che certi progetti faticano a trovare uno spazio amministrativo chiaro, anche quando il beneficio operativo sarebbe immediato e documentabile
Cosa aiuterebbe davvero
Bandi più specifici per interoperabilità e middleware.
Oggi molte gare pubbliche nel settore sanitario premiano la visibilità: nuovi dispositivi, nuovi reparti, nuovi edifici. Le integrazioni software raramente compaiono nelle foto inaugurali di un ospedale, eppure spesso sono ciò che determina quanto fluido sarà il lavoro quotidiano per i prossimi dieci anni. Riconoscere questo tipo di progetto come categoria a sé con criteri di valutazione adeguati cambierebbe molto.
KPI legati al tempo operativo risparmiato.
Se i capitolati di gara includessero metriche come "riduzione delle attività manuali di trascrizione" o "tempo medio tra accettazione e validazione del risultato", i progetti di integrazione diventerebbero immediatamente più valutabili e giustificabili. Il beneficio esiste: serve solo un modo condiviso per misurarlo.
Approcci incrementali invece di mega-progetti.
Uno dei motivi per cui molte integrazioni restano ferme è che vengono concepite come interventi totali, da pianificare, approvare e implementare in blocco. Un modello pilota che coinvolge un singolo reparto, per poi misurarne i risultati ed estenderlo in altri, ridurrebbe il rischio percepito e permetterebbe di raccogliere evidenze concrete in tempi brevi.
Valorizzazione delle competenze "invisibili".
Il personale IT ospedaliero, gli ingegneri clinici, i referenti informatici dei laboratori sono spesso le figure che conoscono meglio sia il problema tecnico che il contesto operativo. Coinvolgerli nelle fasi di progettazione e non solo di implementazione, porta a soluzioni più robuste e a una adozione più rapida.
A chi lo dobbiamo?
Chi lavora nel software sanitario vive spesso una sensazione strana: sapere che un problema potrebbe essere risolto, avere gli strumenti per farlo, e non avere ancora il percorso organizzativo per farlo davvero.
Non è una condizione unica di questo settore, ma in questo ha un peso specifico diverso perché dietro ogni flusso di lavoro ottimizzato, ogni procedura manuale eliminata, ogni ora restituita a un tecnico o a un biologo, c'è qualcosa che non si vede nei bilanci ma che conta molto: la qualità del lavoro delle persone che ogni giorno tengono in piedi i laboratori clinici di questo paese.
La tecnologia, quasi sempre, non è il problema, il problema è costruire i contesti in cui quella tecnologia può davvero essere usata.
