Bisogna ripensare il paradigma dei sistemi informativi sanitari, lo stesso da quarant’anni, per superare i limiti e i problemi che oggi sono presenti.
L’esigenza di condividere dati nacque a fine degli anni settanta quando negli ospedali si diffusero i primi sistemi informativi, ciascuno dei quali operava su uno specifico dominio applicativo.
Nel tempo, sino ai giorni nostri, il paradigma non è cambiato. Il tentativo di introdurre gli ERP non ha avuto successo per la ampia varietà di funzioni e processi che sono presenti in una organizzazione sanitaria. In un ospedale o in una ASL sono presenti decine di sistemi informativi che, in qualche caso, superano le centinaia.
Ogni sistema opera su uno specifico dominio applicativo. L’architettura, una volta monolitica, è oggi ripartita su più livelli e la logica applicativa è organizzata in servizi o micro servizi. I dati sono perlopiù gestiti con database relazionali, con formati proprietari. Per accedervi è necessario conoscere a fondo la struttura fisica del DB, spesso formato da centinaia di tabelle, le relazioni e i vincoli esistenti. Ancora più complicato è scrivere su questi database. Ciò determina di fatto il “lock-in” del fornitore; l’azienda sanitaria deve, per accedere ai propri dati, rivolgersi al produttore del software che realizza query, report ed estrazione sulla base delle richieste che riceve. La presenza di datawarehouse aziendali sistematizza questo processo sia pure con forti rigidità.
Ogni sistema gestisce quindi i dati su cui opera; alcuni di essi sono però comuni con altre applicazioni, con un certo livello di duplicazione. Ad esempio i dati di un ricovero sono all’interno del sistema ADT ma, alcuni di questi, sono di interesse per molte altre applicazioni che, a loro volta, li memorizzano nei loro DB. Ecco dunque la necessità di condividere queste informazioni tra più sistemi attraverso lo scambio di messaggi (HL7 versione 2) o esponendo i dati come “risorse” (HL7 FHIR), ossia lavorare per realizzare l’interoperabilità tra i sistemi. Chiunque ha esperienza in questo ambito sa come sia complicato e faticoso “far parlare” due sistemi, malgrado gli standard e i profili IHE, per non parlare poi della gestione.
I dati sono quindi frammentati e in parte duplicati in più sistemi. Se devo cambiare un sistema devo migrare i dati dal vecchio al nuovo, operazione molto complessa, rischiosa e spesso poco efficace. Per facilitare l’accesso e la condivisione dei dati clinici si fa ricorso a repository che possono archiviare documenti (Document Repository), dati (Data Repository) o entrambi. Il Clinical Data Repository (CDR) viene alimentato dai sistemi che producono dati e contiene un sottoinsieme di informazioni dei DB di ogni sistema, replicandoli.
Il formato dati dei CDR può essere proprietario o, più di recente, HL7 FHIR. In questo blog ho scritto diversi articoli in cui ho evidenziato i limiti di questo approccio (ad esempio qui).
La domanda che dobbiamo farci è se, l’attuale paradigma – app centrico – sia la sola possibilità che abbiamo per realizzare i sistemi informativi della sanità. Quali alternative ci sono? Come possiamo evitare la frammentazione dei dati, il lock-in dei fornitori, l’onere dell’interoperabilità?
La risposta è utilizzare openEHR per l’archiviazione dei dati, realizzando una piattaforma dati centralizzata, aperta, indipendente dai fornitori. Mettere i dati “fuori dalle applicazioni”, rendendoli facilmente accessibili alle aziende sanitarie e ai fornitori, realizzando nel vero senso del termine un ecosistema di dati sanitari.
Vediamo quali benefici è possibile ottenere:
- I dati, essendo fuori dalle applicazioni, non devono essere migrati quando si cambia un sistema;
- I dati sono accessibili con AQL, il linguaggio di interrogazione di openEHR che non richiede, a differenza di SQL, la conoscenza della struttura fisica del DB;
- Non ci sono duplicazioni di dati;
- Non serve un Clinical Data Repository esterno, il DB openEHR contiene tutti i dati;
- Non serve l’interoperabilità, le applicazioni accedono ai dati in modo diretto;
- Avendo un solo DB è più facile presidiare i dati, tutelare la privacy e regolarne l’accesso;
- Avere una struttura dati standard, aperta, consente maggiore concorrenza tra i produttori e la possibilità di scegliere soluzioni specifiche di startup e piccole imprese, favorendo così l’innovazione.
Sono queste le ragioni che stanno determinando il successo e la diffusione di openEHR specialmente in Nord Europa, Asia, Australia. L’ultimo esempio è il Karolinska Institutet di Stoccolma, il più grande e prestigioso ospedale in Europa, che ha scelto openEHR per realizzare la propria piattaforma dati su cui costruire il nuovo sistema informativo.
Prevengo una possibile obiezione: in Italia non ci sono soluzioni basate su openEHR, come posso impostare un capitolato o una richiesta di offerta con questa specifica? Anche in Nord Europa non c’erano sistemi basati su openEHR, i produttori si sono dovuti adeguare alle richieste dei committenti e così si è sviluppato il mercato. Se c’è una domanda, l’offerta si comporta di conseguenza.
C’è poi da dire che l’approccio data centrico non è esclusivo, non si realizza d’improvviso. Si può iniziare con i nuovi sistemi e, nel tempo, convergere su questo paradigma. Qualche pioniere c’è anche in Italia, alcune amministrazioni stanno iniziando ad adoperare openEHR …