L’interoperabilità accompagna la storia dell’informatica sanitaria sin dagli anni ottanta. Oggi però esiste un’alternativa, un modello che permette di superare questo concetto.
L’interoperabilità accompagna la storia dell’informatica sanitaria sin dagli anni ottanta. L’esigenza di scambiare dati tra sistemi si sviluppò ben presto e, con essa, nacquero i primi standard. La versione 2 di HL7 fu definita nel 1989 seguita dalla versione 3 nel 2005 e, sei anni dopo, nel 2011, dalle specifiche FHIR. Tre standard molto diversi tra loro in un arco di ventidue anni. Per completare il quadro dobbiamo anche menzionare DICOM, la cui storia inizia nel 1980 e da IHE fondata nel 1998.
Perché serve l’interoperabilità
La ragione di essere dell’interoperabilità risiede nel fatto che i sistemi sanitari possiedono e operano una propria base dati, di norma sviluppata su database relazionali SQL e, più di recente, su DB non relazionali. Ogni database contiene tutto ciò di cui hanno bisogno le applicazioni, dall’ anagrafe dei pazienti, alle codifiche, ai dati operazionali. L’insieme dati e applicazioni è auto-consistente in modo che possa funzionare senza la necessità di altro. Ogni sistema svolge una specifica funzione e, per coprire tutte le esigenze di un ospedale o di un ambito territoriale, sono necessari tanti sistemi. Tanto per dare qualche numero parliamo di decine o anche centinaia di sistemi diversi. In alcuni casi esistono insiemi di sistemi dello stesso produttore che condividono la stessa base dati e che formano degli ERP. A causa però dell’elevata eterogeneità funzionale della sanità non esiste, anche all’estero, alcun ERP che da solo copre tutte le esigenze di un ospedale o di un ambito territoriale.
Ogni base dati possiede una propria struttura, a volte molto articolata e complessa. Non è raro avere DB con centinaia di tabelle, spesso dai nomi poco comprensibili e migliaia di relazioni. Le tabelle, a loro volta, definiscono la struttura dei dati. Spesso più sistemi gestiscono gli stessi dati (ad esempio diagnosi o misure) che però hanno strutture diverse anche quando magari utilizzano le stesse codifiche.
Per evitare di dover inserire gli stessi dati in più sistemi si è pensato di scambiare, ossia condividere questi dati da parte del sistema dove essi originano che assume quindi il ruolo di “master” con gli altri sistemi che se ne servono – “slave”. Ad esempio il sistema di laboratorio – LIS – condivide i suoi risultati con la cartella clinica elettronica, il sistema trasfusionale, etc.. La condivisione può avvenire mediante l’invio di messaggi (HL7 v.2 e 3) che vengono generati al verificarsi di particolari eventi (trigger), con una logica di broadcasting o esponendo i dati come “risorse” (FHIR). Lo scambio riguarda un sottoinsieme dei dati secondo la logica di Pareto 80/20. Tornando all’esempio del laboratorio condivido gli esami, i risultati, le unità di misura ma non le metodiche, i reagenti utilizzati, le verifiche e altri dati che sono specifici e importanti per il laboratorio ma non per altri sistemi.
Il repository, la casa comune dei dati
Per superare la frammentazione dei dati che sono distribuiti e in parte replicati su più sistemi è nato il concetto di repository (Data Repository), una base dati centrale che contiene un sottoinsieme dei dati più significativi prodotti dai sistemi più importanti. Il repository viene alimentato utilizzando lo stesso modello di interoperabilità in uso (messaggi, risorse o entrambi).
Il repository determina quindi una duplicazione dei dati con cui viene alimentato, aspetto che ha un impatto sulla privacy e le regole di accesso. La sua struttura può essere proprietaria o essere basata su uno standard (FHIR, openEHR, OMOP).
Costi e complessità dell’interoperabilità
Far interoperare i sistemi è molto complesso e costoso. Malgrado gli standard e i profili di integrazione con i relativi Connectathon, per far comunicare due sistemi bisogna impiegare tempo e risorse per studiare i casi d’uso, comprendere come i due fornitori hanno interpretato le specifiche e come valorizzano i campi previsti, sviluppare le eventuali modifiche e trasformazioni, fare i test, rilasciare in produzione il tutto. Ma non basta. Una volta messa in esercizio, l’integrazione ha bisogno di essere monitorata costantemente e di interventi manuali qualora qualcosa “vada storto”, ad esempio un messaggio si sia perso. Se moltiplicate tutto questo per il numero di integrazioni presenti, di solito diverse decine, potete rendervi conto di quanto lavoro sia necessario per mantenere attivo e funzionante tutto ciò che, è bene rimarcare, è di vitale importanza per poter adoperare i sistemi.
Scelta obbligata?
Malgrado si sia sempre fatto così bisogna però chiedersi se esista un’alternativa, un modello che possa superare il concetto di interoperabilità. La risposta è affermativa e consiste nel separare i dati dalle applicazioni, centralizzandoli. Ma come strutturare i dati? La scelta più logica è ricorrere ad uno standard come openEHR. Una base dati comune dove ogni sistema legge e scrive i dati di cui ha bisogno, senza flussi di dati tra uno e l’altro, duplicazioni, perdita di informazioni.
Una base dati completa che “vive” indipendentemente dal ciclo di vita delle applicazioni, senza la necessità di dover migrare i dati ogni qual volta che si cambia sistema. Aperta, accessibile, longitudinale, dove tutti i fornitori possono operare.
Una strada possibile?
Ma quali implicazioni o complicazioni ci sono per i fornitori? Cosa comporta abbandonare il modello dati proprietario interno alle applicazioni? Da un punto di vista tecnico niente di problematico. Si tratta di studiare openEHR e di adottare, quando possibile, gli archetipi disponibili ed eventualmente i template. Uno sforzo che si ripaga in breve tempo. In altre parole, piuttosto che inventarsi ogni volta una propria struttura, basarsi su un modello dati standard, aperto. Voglio precisare che per compiere questa scelta non è necessario che tutti la facciano; si può adottare openEHR anche se il resto dell’offerta rimane sul modello dati tradizionale proprietario e che non è in antitesi con gli standard che oggi adoperiamo. La scelta è a livello di layer dati.
C’è però uno svantaggio e un vantaggio: si perde il lock-in sui clienti che diventano così liberi di utilizzare i dati, in proprio o con altri; si realizzano applicazioni che possono funzionare anche in ambiti di terzi (purché basati su openEHR) in Italia e all’estero. C’è infine un ulteriore aspetto che può rappresentare un vantaggio o uno svantaggio: si riduce e in prospettiva si elimina l’onore dell’interoperabilità che può rappresentare un business o un problema.
Non è un caso se openEHR sta diventando il modello di persistenza dati che molti stati, regioni e aziende sanitarie hanno scelto per i loro sistemi informativi del futuro. Esaminandolo con attenzione è un modello win-win per tutti, clienti e fornitori.
Ricordo a tutti che, nell’ambito dell’Accademia di Salute Digitale, abbiamo pianificato dei corsi per comprendere gli aspetti innovativi e meno conosciuti dell’innovazione. Tra questi c’è openEHR, lo standard per gestire i dati clinici che si sta affermando sempre più nel mondo e che viene scelto dai più importanti e prestigiosi ospedali europei. Se volete saperne di più iscrivetevi e partecipate, non si paga nulla!
Il corso openEHR
Un’occasione per conoscere openEHR e comprendere perché sta diventando lo standard di riferimento per la persistenza dei dati clinici. Il webinar è articolato in due sessioni:
Martedì 26 novembre ore 18-19
- Introduzione e breve storia di openEHR
- Architettura e modello di riferimento
- Gli archetipi
- I template
- Il linguaggio AQL
Per accedere al webinar è necessario registrarsi qui.
Giovedì 28 novembre ore 18-19
- Modello dati aperto per evitare il lock-in dei fornitori
- Uso di openEHR nello sviluppo delle soluzioni cliniche
- openEHR, FHIR e OMOP, tre standard diversi ma complementari
- Programmazione low-code in openEHR, esempi pratici
Per accedere al webinar è necessario registrarsi qui.
Vi aspetto!