Il nuovo Fascicolo Sanitario Elettronico, definito 2.0, è un progetto finanziato dalla missione 6 del PNRR con 1,38 miliardi di euro. La sua gestazione è stata lunga e travagliata e terminata, per ora, con la pubblicazione nella Gazzetta Ufficiale del decreto del 7 settembre 2023. Il FSE 2.0 è dunque legge dello Stato.
Prima però di esprimere un giudizio ripercorriamo velocemente la sua genesi. Il FSE 2.0 nasce con il precedente governo e la progettazione viene affidata al Ministero della Innovazione e la Trasformazione Digitale. Lo staff di Colao e i consulenti che li affiancano decidono di progettare un’infrastruttura centrale in cui raccogliere documenti e dati sanitari strutturati che avrebbe dovuto costituire un Ecosistema dei Dati Sanitari (EDS) su cui sviluppare servizi digitali. Questa infrastruttura, la cui titolarità doveva essere del Ministero della Salute, doveva essere alimentata direttamente dai sistemi informativi delle aziende sanitarie, esautorando le regioni e realizzando una frattura netta rispetto al passato e in contrapposizione con l’ordinamento costituzionale. Il 22 agosto dello scorso anno il Garante della Privacy ha bocciato lo schema di decreto che istituiva il FSE 2.0 e l’EDS, mentre nell’ottobre successivo si insediava il nuovo governo.
La riconversione
Con il cambiamento politico, le regioni trovano una sponda nel Dipartimento della Transizione Digitale (DTD) e vengono prese due importanti decisioni: rivedere l’architettura del FSE 2.0 in chiave federata, analogamente a quanto previsto per il primo FSE; stralciare l’EDS centrale dal decreto di istituzione del FSE 2.0 così da non compromettere il nuovo progetto e rischiare di perdere i fondi del PNRR. L’EDS diverrà, in un prossimo futuro, una federazione regionale di EDS delle singole aziende sanitarie.
Quali sono le novità
L’FSE 2.0 mantiene la stessa impostazione di quello precedente, ossia è una raccolta di documenti sanitari degli assistiti. Vengono ampliati gli ambiti di utilizzo che ora includono anche la prevenzione e la profilassi internazionale, la tipologia di documenti che ne fanno parte, i soggetti che dovranno alimentarlo che ora comprendono anche la sanità privata convenzionata o non con il SSN. Cambiano la struttura dei documenti che ora sono file PDF firmati con, al loro interno, file HL7 CDA con i metadati e i dati strutturati, la modalità di alimentazione che sarà effettuata tramite una componente software, denominata Gateway, sviluppata da Sogei.
Il ruolo delle regioni tra responsabilità e sussidiarietà
Non mancano, come in ogni decreto, gli aspetti poco chiari e forieri di discussioni tra le parti. L’articolo 13 del decreto definisce che “Le regioni e le province autonome sono titolari dei trattamenti di verifica formale e semantica e devono contribuire, utilizzando le soluzioni tecniche rese disponibili da AGENAS e nel rispetto del principio di interoperabilità, all’alimentazione del FSE”. L’articolo decreta che le regioni devono utilizzare il Gateway e che sono responsabili della verifica formale dei documenti. La prima affermazione limita, secondo alcune regioni, la loro autonomia e si configura, di fatto, con una forzatura verso la sussidiarietà dell’uso di una componente software che non è gestita da loro, con tutta una serie di dubbi sull’assunzione di responsabilità. È vero che il codice sorgente del Gateway è accessibile, ma non è chiaro chi potrà fare cosa. Questo tema è al centro di confronto tra le regioni e tra queste e il DTD.
Riuscirà FSE 2.0 a superare i limiti e le criticità del FSE attuale?
Dovrebbe essere la domanda cruciale, al centro dell’attenzione, considerando l’entità degli investimenti previsti. Chi, a vario titolo, è coinvolto o ha responsabilità nel progetto, non ha dubbi e descrive il decreto con toni trionfalistici, l’inizio di una rivoluzione per la sanità italiana. Tra gli addetti ai lavori serpeggiano invece molti dubbi che però, per quieto vivere, non vengono palesati se non all’interno di conversazioni confidenziali.
Il peccato originale di questo progetto è come sono stati affrontati i temi che ne sono alla base: la condivisione e l’uso dei dati sanitari. Ci si è focalizzati soltanto sul primo, a livello esclusivamente tecnico. Non si è fatta alcuna analisi su come utilizzare i dati nella pratica clinica. Non si sono coinvolti gli utenti del fascicolo, prevalentemente medici e infermieri, chiedendo loro cosa gli servisse. Ci si illude che un mero cambiamento tecnologico possa risollevare un progetto che, anche nelle regioni dove è in uso da tempo e popolato con tanti documenti sanitari, non viene realmente utilizzato dai medici nella pratica clinica. Un progetto di questa portata non può essere affrontato e concepito soltanto da tecnici informatici. L’esperienza ci insegna che non basta “dare ai medici i dati” per aiutarli davvero. Né dargliene di più. Immaginare che questi possano aprire e consultare decine o centinaia di documenti per trovare le informazioni che gli occorrono è fuori dalla realtà. I medici chiedono una sintesi della storia clinica del paziente, la possibilità di conoscere rapidamente cosa è rilevante e devono considerare nel valutare e decidere quali azioni intraprendere. A rendere ancora più complessa la problematica, bisogna poi osservare che ciò che è rilevante per un cardiologo è differente da ciò che interessa un endocrinologo, ad esempio.
Tutto ciò richiederebbe una profonda analisi, il coinvolgimento attivo dei professionisti sanitari, la fusione dei dati con la conoscenza scientifica. L’esatto contrario di quanto stiamo facendo.
