Il tema dell’interoperabilità in Sanità, un tempo argomento di discussione tra gli addetti ai lavori, sta diventando popolare come possibile soluzione all’incomunicabilità che oggi esiste tra i sistemi regionali e che, per esempio, è stato citata come una delle cause (la principale è la complessità logistica, a sua volta aggravata dalla mancanza di dati) che rende difficile immaginare di vaccinare le persone nelle località dove questi trascorreranno le vacanze estive.
Dove e come nascono i dati
I dati nascono o vengono prodotti in forma digitale e, molto spesso, anche in forma strutturata. In un laboratorio di analisi, ad esempio, i risultati degli esami vengono rilevati da apparecchiature diagnostiche automatizzate e quindi trasferiti al sistema informativo del laboratorio (LIS) che li archivia nel proprio database in forma strutturata.
Il LIS aggrega i risultati in un documento chiamato referto, un file che può avere diversi formati, principalmente PDF o HL7 CDA, il formato XML che è impiegato nel Fascicolo Sanitario Elettronico. Questa trasformazione riproduce, in chiave digitale, la rappresentazione delle informazioni che si ottiene con la carta ed è finalizzata a consentirne la lettura da parte dei medici e dei pazienti. Il documento diventa quindi una sorta di “fotografia” o “immagine”.
Il documento digitale
Il paradigma del documento, oltre a essere familiare a chi non è pratico di digitale, ha consentito anche di replicare meccanismi e concetti che erano propri della carta: la firma, che diventa elettronica e che consente di verificare la veridicità del contenuto; l’autore e il custode; la definizione di chi può leggerlo (privacy); tracciarne l’invio o la lettura e così via.
Il documento digitale nasce quindi con lo scopo di essere letto da persone e archiviato.
I flussi dati
Quando è necessario trasferire o acquisire grandi quantità di dati, inerenti più pazienti, si ricorre invece ai flussi dati, insieme strutturati di informazioni che vengono prodotti dai sistemi che gestiscono i processi che li generano e che servono ad alimentare, con varie cadenze, grandi database regionali e centrali, come ad esempio il Nuovo Sistema Informativo Sanitario (NSIS). Il formato di questi flussi è normalmente definito a livello nazionale ma, le singole regioni, possono aggiungere ulteriori informazioni secondo le loro necessità.
È questo, ad esempio, il caso del flusso SDO che contiene le informazioni sull’attività di ricovero degli ospedali, o di quello dell’Anagrafe Vaccinale Nazionale.
Il Fascicolo Sanitario Elettronico
Il Fascicolo sanitario elettronico nasce come Punto Unico di Accesso regionale della documentazione clinica dei pazienti, una sorta di fascicolo virtuale che raccoglie i documenti prodotti dalle aziende sanitarie.
L’FSE è composto da un indice che contiene i riferimenti ai documenti dei pazienti, da un meccanismo per richiedere e reperire i documenti contenuti nell’indice e da un front-end per la loro consultazione, tecnicamente una web app e, in alcuni casi, anche un’app mobile.
L’FSE è uno strumento rivolto ai professionisti sanitari e ai pazienti, il cui accesso avviene tramite credenziali.
Cosa è l’interoperabilità
L’interoperabilità è, in ambito informatico, la capacità di un sistema o di un prodotto informatico di cooperare e di scambiare informazioni o servizi con altri sistemi o prodotti in maniera più o meno completa e priva di errori, con affidabilità e con ottimizzazione delle risorse.
Obiettivo dell’interoperabilità è dunque facilitare l’interazione fra sistemi differenti, nonché lo scambio e il riutilizzo delle informazioni anche fra sistemi informativi non omogenei (sia per software che per hardware).
Il Fascicolo Sanitario Elettronico non è, quindi, una piattaforma o un’infrastruttura di interoperabilità. È uno strumento per aiutare i professionisti sanitari a reperire documenti clinici dei pazienti. Questa funzione è però poco efficiente perché il quadro clinico del paziente è frammentato e descritto in diversi documenti, le capacità di ricerca sono molto limitate e, in genere, i front-end sono molto poveri.
La cecità dei sistemi
La mancanza o la ridotta interoperabilità rende i sistemi informativi “ciechi” delle informazioni che non sono presenti all’interno dei propri archivi o che non sono state ricevute attraverso un processo di alimentazione. È quanto, ad esempio, avviene in un sistema informativo ospedaliero, composto da più applicazioni, dove l’accettazione di un paziente viene notificata, attraverso un messaggio HL7 ADT A01, ai sistemi che ne sono interessati, ad esempio il laboratorio di analisi o la cartella clinica elettronica.
Cosa avviene fuori dalla propria azienda?
Lo scambio di messaggi è però circoscritto all’interno dell’azienda sanitaria e, a volte, non include nemmeno tutti i sistemi. Ma come estendere questo meccanismo, includendo ad esempio app e dispositivi medici dei pazienti, sistemi del territorio o delle cure primarie? La vecchia logica dei messaggi, nata più di venti anni fa, non è più sufficiente.
I dati sono risorse – HL7 FHIR
Il cambio di paradigma sul modo di realizzare l’interoperabilità nasce da una considerazione sul valore dei dati, vere e proprie risorse che forniscono informazioni e poi conoscenza. Il focus si sposta allora dalle applicazioni ai dati che, in questa accezione, diventano risorse e che, come tali, possono essere interrogate da sistemi, da app o dal web, dentro o fuori l’organizzazione dove questi risiedono.
È questo il paradigma alla base di FHIR, acronimo di Fast Healthcare Interoperability Resources, lo standard di nuova generazione promosso da HL7 che combina le migliori caratteristiche di HL7 v2, HL7 v3 e CDA sfruttando i più recenti standard web e applicando una stretta attenzione all’implementabilità.
FHIR definisce un insieme di componenti modulari chiamati “Risorse” che possono essere facilmente utilizzate da sistemi in un’ampia varietà di contesti – applicazioni per telefoni cellulari, comunicazioni cloud, condivisione di dati basati su EHR, comunicazione su server e molto altro ancora.
Il framework di FHIR è strutturato in cinque livelli che descrivono le componenti di base (livelli 1 e 2) e i concetti del mondo sanitario (amministrativo – 3, clinico e finanziario 4, conoscenza e ragionamento clinico – 5).
Le risorse diventano servizi
I sistemi espongono e utilizzano risorse. Un sistema territoriale può, ad esempio, esporre un problema di salute (Problem) e un piano di cura (CarePlan) e utilizzare la risorsa terapie (Medication) di una cartella clinica elettronica.
Le risorse vengono esposte e utilizzate tramite servizi web che forniscono informazioni. Rispetto al passato e al presente, si capovolge l’approccio, passando da una logica di tipo “push”, ossia distribuisco le informazioni, tramite messaggi, quando si verifica un evento, a una logica di tipo “pull”, nel quale accedo alle informazioni quando ne ho bisogno.
Tornando all’esempio di prima, anziché inviare un messaggio ADT A01 quando un paziente viene ricoverato, e poi altri messaggi quando il paziente viene trasferito o dimesso, un ADT basato su FHIR espone una risorsa Patient che i sistemi dipartimentali possono interrogare per ottenere, al bisogno, i dati dei pazienti ricoverati.
Quale percorso intraprendere
Per ottenere l’interoperabilità tra i sistemi sanitari è necessario passare dai documenti e dai flussi dati a infrastrutture, basate su FHIR, concepite per questo scopo. Occorre progettare un ecosistema di risorse che sia inclusivo di tutti i processi e le informazioni che compongono il mondo sanitario. Serve lo sforzo di abbandonare vecchi modelli e iniziare a ragionare in digitale in modo nativo, ossia progettare una sanità “digital by design”, tema che sto affrontando nel mio blog nel quale potete trovare diversi spunti.
