Il Fascicolo Sanitario Elettronico è un tema che suscita un ampio dibattito tra tecnici e utenti. Pubblico quindi con con piacere un articolo di Stefano Carboni, a cui vanno i miei ringraziamenti, che contiene riflessioni interessanti sul ruolo e l’interoperabilità del FSE rispetto ai sistemi clinici.
Quando, una quindicina di anni fa, iniziarono ad essere operative le prime componenti di quelli che sarebbero diventati i vari Fascicoli Sanitari Elettronici regionali (FSE), apparve evidente come il risultato principale di questi progetti sarebbe stato la realizzazione di sistemi dei quali avrebbero potuto avvalersi in primo luogo i medici di base, ma anche gli operatori della rete socio-sanitaria e pure gli stessi assistiti. Si trattava in tutti i casi di stakeholders del sistema socio-sanitario che non avevano beneficiato, fino a quel momento, del processo di informatizzazione che già da tempo interessava le strutture ospedaliere.
I FSE, quindi, si delineavano come una sorta di secondo pilastro della digitalizzazione della sanità, da affiancare al processo già in corso negli ospedali pubblici e nelle strutture private. In breve tempo apparve chiaro che quanto si stava realizzando era una sorta di “buco nero”: un sistema perfettamente in grado di acquisire tutte le informazioni che arrivavano dai tanti sistemi informativi ospedalieri esistenti, ma dal quale nulla usciva verso chi non era all’interno dell’FSE stesso.
I nuovi sistemi, infatti, coprivano aree precedentemente non toccate dal processo di informatizzazione, ma, invece di risultare un elemento di sintesi, replicavano, anche nel dominio informatico, quella separazione che esisteva nel sistema sanitario, dove Ospedale e Territorio costituivano – ed a volte ancora costituiscono – mondi separati, con non pochi problemi di comunicazione e, soprattutto, di collaborazione.
Parallelamente alla presa di coscienza dell’assurdità di questa dicotomia, è iniziato a trasparire anche il fatto che l’FSE poteva non solo favorire il processo di continuità di cura tra ospedale e territorio, ma anche costituire il framework necessario a permettere ai tanti e diversi attori della rete assistenziale di beneficiare, in modo conforme con la normativa vigente, del patrimonio informativo sul singolo assistito che oggettivamente il Fascicolo stava iniziando a raccogliere.
Grazie alla disponibilità di tante informazioni cliniche relative al singolo paziente si riteneva di poter ottenere un deciso miglioramento nella qualità della cura fornita – obiettivo questo che rappresenta la stella polare verso cui tutte le iniziative di innovazione in ambito socio-sanitario si dovrebbero muovere – garantendo quindi ai sistemi regionali di FSE il conseguimento di un risultato che, per quanto aggiuntivo rispetto a quelli originariamente previsti , diventava probabilmente ancora più importante di quelli per cui questi progetti erano stato immaginati.
Sono allora sufficienti, per valutare lo stato di attivazione dei vari FSE, indicatori quali il numero di cittadini [potenzialmente] coinvolti o il numero di documenti o referti caricati/indicizzati ? Non sarebbe forse opportuno, soprattutto se si vuole misurare anche l’andamento di questo obiettivo aggiuntivo, ma fondamentale per l’efficacia dei FSE, affiancare a quegli indicatori anche altri numeri, in grado di mostrare se questi progetti portano effettivi benefici al processo di assistenza e cura dei pazienti o quantomeno al fatto che vengano utilizzati per tale fine ? Quanti sono, ad esempio, i referti consultati quotidianamente nei vari FSE e che ruolo hanno i “lettori” di questi documenti ? Sono, ad esempio, assistiti o medici di base, medici di pronto soccorso o medici ospedalieri, …. ?
Come fare poi, da un punto di vista operativo, per favorire la realizzazione di questa rivoluzione copernicana che apra il Fascicolo ai sistemi informativi delle strutture sanitarie oltre che a quelli presenti negli stessi studi dei medici di base ? Come ottenere che a fianco dell’attuale flusso informativo, che sostanzialmente si limita a portare all’interno del Fascicolo la documentazione clinica prodotta attraverso i sistemi informativi delle strutture ospedaliere , si sviluppi un flusso di verso opposto, tale da permettere ai care provider che hanno momentaneamente in cura il paziente di disporre, direttamente nei loro sistemi, dell’enorme patrimonio informativo che il FSE sta raccogliendo ? E perché cercare di realizzare questo stravolgimento del sistema, se col FSE questi dati sono già disponibili ?
Questa è la risposta forse più facile, perché ormai nonostante gli smartphone, le app o i programmi disegnati per ottimizzare l’user experience (o forse proprio per questo), anche solo un cambio di release di uno dei moduli di Office fa imbestialire e diventare temporaneamente inefficiente chiunque usi questi strumenti per svolgere il suo lavoro e perché ormai nessuno ha più il tempo per andare a consultare i dati dei suoi pazienti anche su un altro sistema, diverso da quello che utilizza normalmente.
Le strategie per realizzare questa “rivoluzione” possono essere molteplici, ma dal momento che buona parte dei progetti di FSE sono realizzati sulla base di una architettura simile, se non conforme, al profilo IHE-XDS (cross-enterprise document sharing) perché non rifarsi proprio a questo standard per ottenere il risultato ?
L’FSE, ma anche buona parte dei repository all’interno delle varie strutture sanitarie, sono sistemi document-driven: il livello elementare di gestione dell’informazione è il documento clinico (referto, prescrizione, verbale operatorio, scheda di valutazione, ….).
Ogni sistema archivia un insieme di documenti, in formati e di tipologie potenzialmente diverse, abbinati al singolo paziente e classificati sulla base di alcune caratteristiche. Attraverso meccanismi di ricerca (query) incentrati sul paziente e che possono eventualmente includere filtri per tipologia di documento, è possibile realizzare elenchi dei documenti clinici presenti nell’archivio per ogni singolo paziente. È però lasciato all’utente “umano” il compito di aprire e consultare i documenti del paziente che ha in cura per vedere se le informazioni in essi contenute gli sono utili … con un dispendio di tempo non indifferente.
Entrando un po’ più nel dettaglio il profilo IHE XDS permette di registrare in un Registry l’indice dei documenti archiviati in uno o più Repository e relativi ad un particolare paziente nell’ambito di un certo episodio di cura.
Questi documenti possono essere stati prodotti da tanti diversi sistemi Source (laboratorio analisi, sistema di anatomia patologica, cartella cardiologica, sistema di refertazione radiologica, cartella clinica di reparto, sistema di redazione dei verbali operatori, …) che li hanno poi inviati al sistema di gestione dell’archivio (Clinical Document Repository), unitamente ad informazioni (metadati) utili per la loro classificazione. Questi documenti possono quindi essere consultati da distinti sistemi Consumer, sulla base di query che utilizzano i metadati per selezionare i documenti di interesse.
Sistemi Source e Consumer, inoltre, devono avere caratteristiche tali da realizzare una rete di sistemi ritenuti affidabili e soprattutto, perché tutto funzioni in modo corretto, Source e Consumer devono condividere una stessa logica ed uno stesso insieme di riferimento (codifiche) per la catalogazione delle informazioni mediante i metadati: queste logiche sono registrate in un archivio condiviso denominato Affinity Domain.
Sarebbe quindi “sufficiente” che ogni sistema informativo della rete, oltre ad operare come Source, quando alimenta, come in gran parte già adesso accade, il Fascicolo, potesse anche operare come Consumer e, dualmente, che l’infrastruttura di ogni FSE rendesse anche disponibili servizi in grado di processare le richieste che arrivano da parte dei vari Consumer.
Da un punto di vista generale tutto sembra semplice: un medico ospedaliero (o un generico utente abilitato) accede, nel suo applicativo, alla cartella del paziente e da qui è generalmente in grado di consultare – dal repository aziendale (ospedaliero o della struttura privata) – i documenti del paziente, ad esempio i referti precedenti ai quali è autorizzato ad accedere sulla base della normativa sulla privacy. Per rispondere alla richiesta del medico, l’applicativo non fa altro che lanciare una query sul registry e sul repository locale e poi presentare al medico l’elenco dei documenti recuperati e corrispondenti ai criteri di ricerca immessi.
Con lo stesso strumento e con la stessa logica, il medico dovrebbe poter estendere la sua interrogazione all’intero Fascicolo, lanciando una o una batteria di query verso i registry federati (o il super-registry di qualche soluzione regionale) ed ottenendo, anche da questi come già accade per i registry aziendali, una lista di documenti che, attraverso lo stesso visualizzatore presente nel suo applicativo aziendale, gli vengono prima elencati e che poi lui può eventualmente aprire e consultare.
Sulla carta sembra tutto semplice, ma in realtà basta qualche maggior dettaglio per comprendere come il sistema sia tutt’altro che banale: intanto se la query è una semplice ricerca sulla base del paziente, per quanto possa essere scontato come ad esempio il codice fiscale sia sufficiente per identificare il paziente in tutti i sistemi della rete, anche solo il matching anagrafico spesso non è immediato. Il sistema XDS, poi, dovrebbe cercare di incrociare i documenti disponibili con i diritti che ha il richiedente a vederli o anche solo a conoscerne l’esistenza, ad esempio sulla base di una condivisione del significato semantico dei ruoli e, soprattutto, di una condivisa attribuzione di diritti di accesso ai documenti agli utenti o a gruppi di questi utenti.
A livello aziendale, inoltre, già adesso spesso accade, a maggior ragione se l’utente che ha lanciato la query è un utente medico di Direzione Sanitaria (tipologia di utenza che tipicamente ha il diritto di accedere a tutti i dati dei pazienti) che il risultato di una query sui documenti di un paziente risulti una lunga lista di voci; è facile immaginare che se la query fosse lanciata su tutto il Fascicolo regionale (e magari attraverso questo, sugli FSE federati delle altre regioni attive) l’elenco rischierebbe di diventare enorme.
È allora opportuno prevedere meccanismi di filtraggio più specializzati, in modo che la selezione dei documenti possa essere limitata, ad esempio, ai soli referti (ignorando quindi le prescrizioni, i consensi, le ricette, il diario, …) e, magari, a solo quelli prodotti dal laboratorio analisi. La possibilità di realizzare query con filtri su alcuni dei metadati (es. autore del documento, specialità, tipo di documento, data di produzione, evento, …) necessita che questi siano stati valorizzati al momento della archiviazione dei vari documenti sul repository stesso e che questa valorizzazione sia avvenuta in modo conforme ad un sistema di codifica unitario e condiviso.
Solo recentemente sono stati definiti a livello nazionale degli standard da adottare, ad esempio per le tipologie principali di documenti da utilizzare (prescrizione, referto, taccuino, lettera di dimissione, verbale di PS, … , nell’ambito di un più generale documento di condivisione definito AffinityDomainItalia.
Un appropriato utilizzo di questi filtri permetterebbe sicuramente di realizzare un primo livello di selezione tra i documenti disponibili che spesso – soprattutto per i pazienti più critici e quindi con più episodi di cura – possono diventare veramente molto numerosi, ma a volte questa capacità del sistema può dimostrarsi non sufficiente.
Alcune soluzioni software di gestione della coppia repository-registry implementano meccanismi, purtroppo custom, grazie ai quali vengono addirittura elencati, come elementi di classificazione e di potenziale filtro, i singoli test presenti nel referto (ad es. in un referto di laboratorio), così da permetterne una analisi in modalità “machine readable” (avvicinando il sistema a soluzioni completamente data-driven). Questo permette ad esempio di evitare al medico di dover aprire ogni singolo referto di laboratorio di un paziente per capire non solo se il referto del paziente in quella data riportava il valore dei Trigliceridi, ma anche se quel valore era fuori range oppure no.
Queste logiche, attualmente implementate principalmente nell’ambito di sistemi di singole aziende, dove ad esempio tanto il sistema LIS quanto il sistema di repository sono unici, sono difficilmente applicabili quando il raccoglitore (l’FSE) può ad esempio ricevere referti per esami di laboratorio effettuati in strutture diverse e con sistemi LIS diversi, se non si riescono ad implementare in modo standard.
Per superare queste problematiche, allora, ci si può muovere lungo tre direttrici.
Quella più immediata, ma che richiede una rilettura radicale dei sistemi FSE, è quella di superare l’approccio document-driven e passare a sistemi data-driven (impostazione che ad esempio è stata utilizzata per alcune reti di patologia, dove il sistema regionale implementa un modello clinico specifico per la singola patologia e dove la comunicazione non è limitata ai soli documenti, tra l’altro con formati standard condivisi tra i diversi attori, ma anche a dati puntuali che rappresentano specifiche grandezze del modello stesso – es. ROL).
Mantenendosi in un ambito più conservativo, potrebbero esistere comunque due strade: una più tradizionale ed una decisamente più innovativa, ma ancora da validare.
La prima è quella di implementare un sistema ibrido, dove all’interrogazione di un registry in grado di indicare quale sistema sia autore di documenti di un certo tipo per un particolare paziente e di verificare il diritto del richiedente a conoscerne il contenuto, si fa seguire uno scambio di messaggi HL7 nei quali il richiedente invia al sistema cosiddetto filler (il sistema che ha ricoperto il ruolo di SOURCE nella produzione del documento) una domanda di inoltro delle informazioni relative all’esame del quale si desiderano i dati che, a questo punto, possono essere in formato strutturato. Come si prevede nelle architetture tradizionali con messaggistica HL7, il messaggio di risposta arriva al chiamante e genera, sul sistema chiamante, un referto copia di quello originale. In alcune implementazioni (es. sistema NICTIZ/AORTA in Olanda) la copia resta disponibile sul nuovo sistema per un tempo limitato (4-6 settimane), dopo di che viene cancellata.
La seconda soluzione, in linea con le più recenti tendenze della tecnologia ed al momento decisamente sperimentale, prevede invece che i documenti che rientrano nella selezione che il medico ha impostato vengono ulteriormente analizzati e filtrati mediante algoritmi di analisi testuale. In questo modo si potrebbe ottenere una ulteriore riduzione del numero dei documenti da proporre all’utente finale o addirittura, con algoritmi di analisi più avanzati, potrebbero essere presentati all’utente anche i testi estratti dai singoli documenti che risultano pertinenti con la query impostata (es. strumenti quali Google search, Maxxcat, …).
Stefano Carboni