Qualora ce ne fosse stato ancora bisogno, la pandemia COVID ha ulteriormente dimostrato, come la disponibilità dei dati -completi, omogenei ed affidabili- sia un requisito indispensabile per rendere possibile la cura del paziente durante tutto il suo percorso, per non parlare della prevenzione, della programmazione dei servizi e della ricerca. E questo sia all’interno dell’azienda sanitaria, che nelle reti di collaborazione sul territorio e a livello nazionale.
Scenario, purtroppo, ben lontano dalla realtà, fatta di dati frammentati in contesti diversi e in uno quadro complessivo che potremmo definire “la Babele della sanità digitale”, con i dati che diventano sempre più settoriali e circoscritti ad attività specifiche e registrati secondo tecnologie diverse e con modelli sintattici e semantici diversi, quasi sempre proprietari. In definitiva inutilizzabili per quegli obiettivi di salute del singolo cittadino, gestione dei processi clinico-assistenziali all’interno dell’azienda e sul territorio e supporto alle esigenze complessive del SSN.
Un possibile modello di “Clinical Data Repository” standard e open-source dati già esiste: è stato definito e raffinato fin dagli anni ’90 nel corso di diverse iniziativa di italiane ed europee per essere poi anche formalizzato nello standard internazionale UNI-CEN-ISO 12967:2009 “Health Informatics – Service architecture” ([5]).
Vediamo perché è importante e come è stato già implementato.
Monitoraggio e assistenza a distanza nell’era Covid: così l’ASL di Foggia si è trovata pronta
Le esigenze nella organizzazione dei dati
I dati devono essere disponibili ed organizzati in forma elementare, in modo da essere utilizzabili individualmente da strumenti automatici, e non solo aggregati in documenti, magari PDF crittografati, che sono senz’altro utili per una ispezione visiva e per attestare l’autore dell’atto clinico nel suo complesso, ma non possono essere utilizzati per l’analisi ed il monitoraggio proattivo dell’evoluzione delle condizioni di salute del paziente.
| Questi dati elementari devono essere organizzati e fruibili secondo due coordinate: una paziento-centrica per fornire all’operatore sanitario un quadro completo ed affidabile dello stato del singolo paziente durante l’episodio assistenziale, ed una orientata secondo le esigenze dei vari processi clinico-organizzativi in cui l’esigenza non è l’analisi dettagliata del singolo, ma l’evidenziazione elaborata ed aggregata di informazioni omogenee e coerenti di più pazienti. |  |
Si pensi ad esempio ad una centrale di monitoraggio che deve avere in tempo reale un quadro delle situazione di allarme dei parametri di tutti i pazienti gestiti, alla compilazione di una lista operatoria in cui è necessario conoscere l’eventuale stato di infezione di un paziente, ad una attività di ricerca (manuale o basata sull’intelligenza artificiale) che deve scoprire informazioni e conoscenza analizzando e correlando tutti i dati disponibili.
Il Fascicolo Sanitario Elettronico, anche se realmente e completamente popolato con tuti i dati del paziente (stato ben lontano da quello attuale), per la sua stessa natura di essere basato sul singolo paziente e sui documenti, è senz’altro un utile strumento di consultazione manuale per il medico e per il cittadino, ma non può -da solo- soddisfare a questi requisiti. Occorre che sia affiancato da piattaforme di dati granulari, accessibili individualmente -ovviamente secondo le necessarie autorizzazioni- per poter soddisfare le diverse esigenze.
Questa esigenza emerge anche nelle dichiarazioni del ministro Roberto Speranza che, nella sua audizione di fronte alle commissioni Affari Sociali riunite di Camera e Senato, ha evidenziato l’obiettivo di “registrare il percorso del paziente sin dal primo momento d’interazione con la rete di assistenza, applicando criteri per omogeneizzare e standardizzare la raccolta e il trattamento dei dati sanitari elaborati ed aggregati” e di “un modello unico e una rete nazionale che permettano di gestire gli archivi dei dati disponibili e di raccogliere e organizzare una mole di informazioni che crescerà in modo esponenziale”. Analogamente, nel DL n. 22 del 1 Marzo ([1]), all’art.8.1 fra i compiti del “Comitato interministeriale per la transizione digitale (CITD)” è esplicitamente citato “ b) al fascicolo sanitario elettronico e alla piattaforma dati sanitari”.
La sostenibilità e la rapidità nel raggiungimento di questo obiettivo sono ovviamente requisiti prioritari. Non sono ovviamente ipotizzabili iniziative “ex-novo”, che richiedano anni per la realizzazione, costi ed impatti organizzativi e tecnologici nelle aziende sanitarie, e che siano progettate “una-tantum” all’inizio senza essere in grado di seguire immediatamente l’evoluzione dei contesti organizzativi e delle soluzioni tecnologiche che sono disponibili sempre con maggiore rapidità. Occorre partire dagli scenari adesso esistenti nelle aziende sanitarie e focalizzare la strategia evolutiva sul governo, sulla gestione e sulla condivisione dei dati, che rappresentano l’unico elemento stabile ed invariante nel tempo. In questo senso, già nel 2015, il rapporto del WHO, “The WHO global strategy on people-centered integrated health services”.
La babele degli scenari attuali nelle aziende sanitarie
Troppo spesso, fino adesso, ci si è invece basati sulla sola “interoperabilità tecnologica” delle applicazioni, costruita mediante messaggi e protocolli rigidi e predefiniti, senz’altro validi e necessari per notificare e/o rispondere a specifici eventi, ma assolutamente non sufficienti per fornire un quadro completo ed una usabilità del patrimonio informativo in tutti i casi necessari, sia routinari che di emergenza. Non a caso, già nel 2017, il “Quadro europeo di interoperabilità – Strategia di attuazione” ([2]) indica invece l’accessibilità diretta ai dati come il requisito fondamentale per una reale interoperabilità dei sistemi. Non basta più quindi la semplice comunicazione fra le applicazioni, ma occorre una reale integrazione, coerenza ed accessibilità del patrimonio informativo.
I sistemi informativi delle aziende sanitarie sono in massima parte strutturati secondo architetture “a silos” con applicazioni diverse, debolmente interconnesse fra di loro ed operanti su basi di dati di fornitori diversi, eterogenee dal punto di vista tecnologico e di contenuto informativo e spesso proprietarie e non accessibili dall’esterno. Ai principali “silos” operanti a livello dipartimentale e/o dei principali processi aziendali, va poi aggiunta la miriade di applicazioni, spesso collegate con un dispositivo medico, utilizzate a livello individuale per il supporto a singole attività, come nel caso della telemedicina, ciascuna con la sua base dati scollegata dal resto.
Di conseguenza i dati -clinici ed organizzativi- dei pazienti sono frammentati in contesti diversi (es. cartelle cliniche specialistiche, cartelle ambulatoriali, sistemi dipartimentali, sistemi di supporto alla ricerca, archivi di big-data, etc.). Questo scenario di frammentazione si amplifica inevitabilmente sempre più con:
- l’evoluzione dei modelli assistenziali, in cui il percorso clinico-organizzativo del paziente è gestito da diversi attori anche distribuiti sul territorio ed ognuno con il proprio sistema informatico;
- la crescita delle applicazioni di telemedicina (solo nell’ultimo anno sono state più di 200 le iniziative di telemedicina avviate autonomamente dalle singole aziende sanitarie ([3]));
- l’aumento dell’IoT e delle APP -anche commerciali- gestite autonomamente dai pazienti.
Tutto questo determina un aumento del volume di dati e la Babele cui abbiamo accennato.
In questo scenario, gli studi e i disegni di “integrated care”, “connected care”, “personalized care” che sempre più spesso compaiono nella letteratura e nei convegni come obiettivo e soluzione taumaturgica dei problemi attuali, rimangono solo utopie teoriche, molto belle sulla slide PowerPoint ma praticamente non implementabili (almeno con tempi, costi ed impatti ragionevoli) per il semplice fatto che i dati necessari non ci sono, in quanto sono di proprietà di singole applicazioni e singoli processi, e non sono accessibili se non a prezzo di progetti e sviluppi aggiuntivi per ogni singola transazione.
Le conseguenze della frammentazione
In questa babele, infatti, diventa difficile, se non impossibile:
- dal punto di vista clinico presentare un quadro complessivo dello stato di salute del paziente per assicurare la massima fondatezza delle decisioni cliniche e per attivare quei meccanismi di monitoraggio e quelle segnalazioni di alert riscontrabili dalla correlazione di diverse informazioni (es. co-morbilità, allergie, …)
- dal punto di vista economico e della continuità del percorso di cura assicurare la continuità dei processi, evitando trascrizioni manuali, hand-over verbali o cartacei, pianificare ed ottimizzare le risorse necessarie al controllo di gestione, tanto a livello del singolo centro che in contesti distribuiti e di collaborazione sul territorio nell’ambito della stessa azienda o fra aziende diverse.
- dal punto della protezione dei dati adempiere a tutte le disposizioni del Regolamento, non solo in termini di criteri e livelli uniformi per la sicurezza ed il controllo sugli accessi e sull’utilizzo dei dati personali, ma anche relativamente al diritto dell’interessato all’ottenimento ed alla trasportabilità dei propri dati.
- dal punto di vista della prevenzione e della ricerca disporre di un patrimonio informativo, coerente ed il più ampio possibile, necessario per eseguire -nel rispetto della normativa- analisi statistiche, epidemiologiche e di ricerca.
- dal punto di vista della dipendenza dai fornitori delle diverse applicazioni ai quali bisogna rivolgersi -con i conseguenti oneri in termini di tempi e di costi- ogni qual volta sia necessaria l’acquisizione di dati di interesse, fino a configurare fenomeni di “vendor lock-in” evidenziati anche nel 2017 dalle “Linee guida 8” dell’Autorità Nazionale Anticorruzione ([4])
La strategia di evoluzione e il Clinical Data Repository
In questo contesto, una strategia evolutiva che consenta l’integrazione, il possesso e l’usabilità dei dati deve iniziare dalle singole aziende, tenendo conto di alcuni prerequisiti.
Preservare la possibilità di integrare nel sistema informativo applicazioni diverse
È innanzi tutto necessario preservare la possibilità di integrare nel sistema informativo applicazioni diverse, fornite da fornitori diversi e basate anche su tecnologie diverse, selezionabili senza condizionamenti tecnici e/o commerciali, ma in funzione della sola adeguatezza della soluzione rispetto alle esigenze cliniche ed organizzative ed della convenienza economica.
Non solo per quanto riguarda i costi e la complessità attuativa, non è infatti ipotizzabile l’evoluzione del sistema informativo verso soluzioni monolitiche di un unico fornitore. Le esperienze effettuate in questo senso negli ultimi decenni hanno dimostrato come un unico sistema monolitico (tipo ERP) possa semmai garantire il supporto organizzativo ai processi principali ma non consenta -anche per la molteplicità e la rapidità delle evoluzioni cliniche e tecnologiche e la diversità dei modelli assistenziali- di essere adeguato in tutte le situazioni.
Un approccio non invasivo
Analogamente, è necessario un approccio “non invasivo”, tale cioè da non richiedere modifiche alle applicazioni già esistenti e funzionanti nell’azienda, la cui variazione determinerebbe tempi e costi ulteriori. Approccio al tempo stesso flessibile e graduale, tale cioè da poter essere implementato secondo le priorità, le esigenze e le risorse dell’azienda, consentendo una capitalizzazione continua su quanto man mano realizzato.
Organizzare i dati con un modello open source
Infine, ma forse per primo dal punto di vista strategico, è necessario che il patrimonio informativo aziendale integrato sia organizzato secondo un modello conosciuto dall’azienda e non proprietario (preferibilmente basato su strumenti open-source), in modo da garantire realmente all’azienda la totale proprietà sui propri dati e la possibilità di usare gli stessi (o di concederne l’accesso alle applicazioni) come e quando necessario, senza condizionamenti di sorta -con i conseguenti tempi e costi- rispetto a specifici fornitori.
In definitiva, quindi, una tale strategia per l’integrazione del patrimonio informativo aziendale non deve essere alternativa, ma complementare rispetto alle interazioni dei sistemi per il supporto ai singoli processi.
Alla luce di queste esigenze, si può delineare un approccio in prima istanza simile a quello che viene utilizzato con il datawarehouse nel contesto amministrativo. Ovvero affiancare agli scenari esistenti una base dati, strutturata secondo un opportuno modello, nella quale far confluire periodicamente (se non in tempo reale) i dati sanitari ed organizzativi prodotti dalle diverse applicazioni nel normale supporto alle operatività giornaliere.
Questa base dati (nel seguito “Clinical Data Repository”) dovrà essere strutturata secondo un modello opportuno, incentrato sul paziente e sul suo percorso, trasversalmente rispetto agli episodi assistenziali. Dovrà tener traccia degli episodi, delle prestazioni erogate (con le relative risorse utilizzate) e dei dati clinici, intesi non solo in termini di documenti (anche strutturati e firmati con validità legale), ma soprattutto in termini di dati elementari in grado di essere analizzati, comparati ed associati individualmente secondo le esigenze dello specifico trattamento, anche con l’evidenziazione automatica di allarmi e situazioni di rilevanza per il medico.
Il tutto agendo trasparentemente sulle basi dati delle applicazioni esistenti (mediante strumenti e meccanismi già disponibili e/o implementati una volta soltanto) e lasciando inalterate le funzionalità esistenti ed i loro meccanismi di interazione. Senza quindi determinare costi e conseguenze sulle operatività giornaliere.
A questa struttura completa ed integrata potranno accedere tutte le nuove applicazioni mediante meccanismi pubblici e non proprietari, per recuperare tutte le informazioni necessarie a supporto delle decisioni cliniche, della valutazione dell’efficacia dei trattamenti, delle attività di prevenzione e ricerca ed anche di analisi delle risorse (e quindi dei costi) utilizzate per seguire un paziente nel suo percorso completo. Ulteriore vantaggio di questo approccio è la possibile gradualità nella implementazione. Non modificando le applicazioni ed agendo in parallelo al funzionamento ordinario, è possibile procedere con il popolamento graduale del Repository in momenti successivi, individualmente per le aree di interesse prioritarie dell’azienda.
Il Repository sarà poi collegato con il Fascicolo Sanitario Elettronico, garantendo quindi l’effettivo popolamento di questo con tutti i dati di rilevanza per il paziente.
Infine, definendo a livello regionale e nazionale un modello di riferimento comune per la struttura dati del Repository, sarà possibile mantenere la l’indipendenza tecnologica ed operativa delle singole aziende, assicurando nel contempo la possibilità di trasferire, confrontare ed elaborare -secondo tutti i criteri di sicurezza e protezione necessari- dati coerenti ed omogenei fra i diversi livelli del SSN, in modo da raggiungere quell’obiettivo di “modello unico e rete nazionale che permettano di gestire gli archivi dei dati disponibili e di raccogliere e organizzare una mole di informazioni che crescerà in modo esponenziale” indicato, come in premessa, dal Ministro Speranza.
Solo disponendo di un tale patrimonio informativo, integrato ed accessibile, è possibile organizzare la Babele attuale ed implementare, con tempi, impegni e costi realistici i modelli di cura, assistenza, e collaborazione individuati come essenziali per il sistema sanitario.
Un Clinical Data Repository standard e open-source
A questo proposito, vale ricordare che già prima della emergenza COVID, all’inizio del 2019, era stata avviata l’iniziativa “Community per il governo dei dati” (www.dati-sanita.it), che vede come promotori l’ALTEMS, Alta Scuola di Economia e Management dei Sistemi Sanitari dell’Università Cattolica del Sacro Cuore, il Dipartimento di Ingegneria Informatica, Automatica e Gestionale “A. Ruberti” dell’Università Sapienza, la Fondazione Sicurezza in Sanità, con l’obiettivo di facilitare la collaborazione fra aziende sanitarie, istituzioni ed enti di ricerca nella condivisione di metodologie, esperienze e strumenti software non proprietari per l’integrazione, la protezione, la sicurezza e l’utilizzo dei dati, sia all’interno delle singole aziende sanitarie che nei contesti di collaborazione per la continuità di cura sul territorio.
Nell’ambito di questa iniziativa, il modello del Clinical Data Repository definito nello standard ISO è stato implementato in una logica open-source, per operare nell’ambiente tecnologico dei principali DBMS. Attraverso il sito www.dati-sanita.it, è liberamente disponibile la documentazione dettagliata e gli strumenti software.
A titolo di esempio dell’utilizzo di questo Repository per l’integrazione e l’evoluzione del patrimonio informativo aziendale, anche nelle applicazioni di telemedicina, si può ricordare l’articolo “Monitoraggio e assistenza a distanza nell’era Covid: così l’ASL di Foggia si è trovata pronta”, pubblicato il 20 maggio 2020 su Agenda Digitale ([6])
Note
- https://www.gazzettaufficiale.it/eli/id/2021/03/01/21G00028/sg ↑
- https://ec.europa.eu/isa2/eif_en ↑
- Instant Report COVID-19, settimanali dell’ALTEMS da Marzo 2020, https://altems.unicatt.it/altems-covid-19 ↑
- delibera numero 950 del 13 settembre 2017 ↑
- https://en.wikipedia.org/wiki/Health_Informatics_Service_Architecture ↑
- https://www.agendadigitale.eu/sanita/monitoraggio-e-assistenza-a-distanza-nellera-covid-cosi-lasl-di-foggia-si-e-trovata-pronta/ ↑
