La sanità è, per sua natura, un contesto di elevata eterogeneità di sistemi informativi e di dati. In un’azienda sanitaria possono essere presenti sino a cento differenti applicazioni o sistemi informativi. Ciascuno di essi è un’isola auto-consistente composta da uno o più database. Ogni sistema che gestisce o tratta informazioni sui pazienti possiede, ad esempio, una propria anagrafica, degli archivi sulle codifiche e i dati strutturati, nonché una serie di archivi con i dati che l’applicazione gestisce o a cui si riferisce.
A differenza di altri settori, in cui il concetto di ERP si è affermato nel tempo riducendo così il numero e l’eterogeneità dei sistemi informativi e delle basi dati, questo paradigma non ha avuto successo nella sanità per le seguenti ragioni:
- Il numero, l’ampiezza funzionale e la varietà dei processi presenti in un’azienda sanitaria – amministrativi, gestionali, logistici, sanitari, clinici, diagnostici, assistenziali, etc..
- La forte verticalizzazione e specializzazione dei diversi domini applicativi che richiedono competenze e soluzioni dedicate
- I meccanismi di procurement in sanità che spesso privilegiano la sostituzione di singole aree applicative
- La difficoltà di mettere in esercizio grandi sistemi informativi con logica “big bang” piuttosto che di sostituzione modulare di singole applicazioni
In un’azienda sanitaria sono dunque presenti sistemi di diversi fornitori, molto eterogenei per architettura, tecnologie, funzioni. La frammentazione e l‘eterogeneità sono presenti non soltanto nelle aziende sanitarie, ma negli stessi portafogli di soluzioni dei fornitori. I più grandi di essi, che coprono quasi tutte le aree applicative di un’azienda sanitaria, hanno un’offerta composta da una grande varietà di applicazioni.
La conseguenza di questa situazione è che, all’interno delle aziende sanitarie, sono presenti una grande quantità di dati duplicati, a partire da quelli anagrafici. I dati di laboratorio, ad esempio, sono spesso presenti, oltre che nel LIS, anche nella cartella clinica elettronica, dove vengono duplicati.
A cosa serve l’interoperabilità
La frammentazione e la duplicazione di dati determinano due problemi:
- La necessità di reintrodurre nelle applicazioni dati già presenti in altre;
- La possibilità di incongruenze o errori, ad esempio dati diversi in due database, o dati associati erroneamente a un paziente
Sin dai primi anni Ottanta l’attenzione della comunità dei fornitori di soluzioni IT si è focalizzata sul primo aspetto. La definizione dello standard HL7 versione 2 ha consentito lo scambio di messaggi, al verificarsi di determinati eventi, per trasmettere dati dal sistema dove questi sono originati (producer) verso altri sistemi che li adoperano (consumer). Un esempio sono i messaggi ADT che il sistema di accettazione ospedaliero invia a tutti i sistemi diagnostici e clinici per consentire loro di aggiornare le proprie anagrafiche e di consentire agli utenti di selezionare un paziente senza dover reintrodurre i dati.
Tramite integrazioni punto a punto o, sempre più spesso, mediante Enterprise Service Bus, le applicazioni si scambiano dati attraverso messaggi. Ma cosa invece succede sul fronte della duplicazione dei dati? Poco o nulla.
Interoperable by design
Le applicazioni di nuova concezione, anche se basate su architetture a servizi o a micro-servizi, continuano ad essere progettate in modo tradizionale, ossia come isole auto-consistenti. Possiedono quindi, all’interno del loro database, un’anagrafe pazienti, una serie di tabelle con le codifiche, archivi con i dati operativi necessari. L’interoperabilità è vista come un “problema esterno”, una funzione da delegare ad un layer dedicato a questo scopo.
Per affrontare in modo efficace il tema dell’integrazione, è necessario adottare una progettazione “interoperable by design”, in cui occorre passare da un approccio basato sui dati a quello sulle “risorse”.
In altre parole, anziché definire nel database dell’applicazione la struttura ad esempio dell’anagrafica pazienti, bisogna progettare il software perché possa utilizzare una risorsa in grado di restituire le informazioni (il subset) dell’anagrafica pazienti. Questa risorsa potrà essere esterna o, se mancante, interna. È questa la logica che è alla base di FHIR, il nuovo standard di interoperabilità promosso da HL7.
Dati o documenti?
A partire dalla definizione di HL7 CDA, allo scambio di messaggi con dati strutturati e non, si è affiancata la trasmissione di documenti, in formato XML, così da condividere referti e certificati. A differenza dei primi che sono basati su sintassi e strutture ben strutturate, la maggior parte dei documenti HL7 CDA oggi un uso contengono nel corpo (“body”) dei file PDF.
In questo modo viene meno uno degli obiettivi principali dell’interoperabilità, ossia la possibilità di due o più sistemi di utilizzare le informazioni che si scambiano. Il Fascicolo Sanitario Elettronico (FSE), ad esempio, è un’infrastruttura che permette ai medici di accedere e leggere dei documenti clinici e, solo in alcuni casi, ad altri sistemi informativi. Il FSE della Lombardia non consente, ad esempio, ai medici di medicina generale di poter “importare” nella propria cartella clinica elettronica il referto di laboratorio di un loro assistito, azione che invece riesce ai loro colleghi dell’Emilia-Romagna o della provincia di Trento.
La spiegazione di questo comportamento risiede nel formato del corpo del CDA e nel come vengono riportati i risultati di laboratorio.
I differenti livelli di interoperabilità
Per realizzare l’interoperabilità tra sistemi è necessario lavorare su differenti livelli:
- L’interoperabilità tecnica o tecnologica, ossia i protocolli hardware e software con cui effettuare lo scambio di informazioni
- L’interoperabilità sintattica, con cui specificare la struttura e il significato delle informazioni, normalmente definita con standard come HL7, DICOM
- L’interoperabilità semantica, con cui definire il significato delle informazioni, normalmente attraverso sistemi di codifica come ICD, SNOMED, ATC, etc..
- L’interoperabilità organizzativa, con cui definire gli scenari, i casi d’uso, i processi che sono oggetto di scambio e condivisione tra utenti e aziende sanitarie, come ad esempio espresso dai profili di integrazione di IHE.
Quest’ultimo aspetto è, in base alla mia esperienza, il più trascurato. Spesso ci si concentra sui primi due – tre, senza analizzare in dettaglio i processi da cui nascono le informazioni. Si realizzano così integrazioni che sono tecnicamente perfette ma che diffondono dati poco attendibili, con l’effetto di propagare dati poco accurati su più sistemi. Un esempio classico sono le anagrafiche dei pazienti che, prodotte da più sistemi, contengono dati inesatti o duplicati (“anagrafiche sporche”) e che è uno dei problemi più rilevante delle aziende sanitarie.
Conclusioni
L’interoperabilità è alla base della sanità digitale e richiede, di conseguenza, una forte attenzione. I produttori di software sanitario devono progettare le proprie soluzioni con un approccio “interoperable by design”, mentre i responsabili dei sistemi informativi delle aziende sanitarie devono dedicare tempo e risorse a questo scopo. Un’efficace interoperabilità è una condizione necessaria per valorizzare e utilizzare il proprio patrimonio informativo.
Può essere utile ricorrere a consulenti o ad aziende terze rispetto ai fornitori che producono i sistemi informativi, così da evitare possibili conflitti di interesse o situazioni di “lock-in”.
