Il Fascicolo Sanitario Elettronico (FSE) italiano nasce, con il DPCM 29 settembre 2015 n. 178, come sistema federato a documenti firmati: ogni Regione conserva i propri repository e un’infrastruttura nazionale instrada le richieste, senza centralizzare i dati clinici. Il regolamento è uscito nella Gazzetta Ufficiale, Serie Generale n. 263 dell’11 novembre 2015, e attua l’articolo 12 del DL 18 ottobre 2012 n. 179 (convertito dalla L. 221/2012).

Contesto

L’articolo 12 del DL 179/2012 aveva introdotto il FSE nell’ordinamento, ma rimandava a un regolamento le regole operative. Il DPCM 178/2015 è il primo testo che entra nel merito di contenuti, consensi, accessi e interoperabilità. La scelta di fondo era già implicita nell’architettura che alcune Regioni avevano costruito e nelle specifiche tecniche pubblicate da AgID nel maggio 2015: il FSE è un sistema a documenti, non un database clinico unificato.

Da qui discende tutto il resto. Un sistema a documenti condivide referti, lettere di dimissione e profili sintetici come oggetti completi e firmati, non come campi atomici interrogabili. La conseguenza tecnica è una sola: l’unità di scambio, di indicizzazione e di controllo degli accessi è il documento.

Architettura

Il DPCM conferma il modello federato. Ai sensi dell’articolo 3 il FSE è istituito da ciascuna Regione e Provincia autonoma, che ne gestisce contenuti e funzionamento. A livello nazionale nasce l’Infrastruttura Nazionale per l’Interoperabilità (INI), affidata al Ministero dell’Economia e delle Finanze e realizzata tramite Sogei, che deve garantire l’interoperabilità tra i FSE regionali quando un assistito viene curato fuori dalla Regione di residenza.

INI non duplica i FSE: ne fa da gateway. I documenti restano nei repository regionali; INI si occupa di localizzazione e instradamento tra Regione di assistenza e Regione di residenza.

Sul piano dei profili, le specifiche tecniche AgID per l’interoperabilità tra i sistemi regionali di FSE (versione di riferimento del 2015) adottano lo stack IHE:

  • Document Registry — il registro regionale dei metadati dei documenti;
  • Document Repository — l’archivio fisico, di norma presso gli erogatori;
  • Document Consumer — il client che interroga e recupera;
  • profilo XDS.b per la condivisione documentale dentro la Regione;
  • profilo XCA (Cross-Community Access) per la comunicazione tra FSE regionali attraverso INI.

I documenti del nucleo minimo seguono i profili HL7 CDA R2 italiani definiti con HL7 Italia. Il trasporto è SOAP/WSDL conforme ai profili IHE, in TLS.

Contenuti e consenso

L’articolo 2 distingue un nucleo minimo nazionale obbligatorio (dati identificativi e amministrativi, referti, verbali di pronto soccorso, lettere di dimissione, profilo sanitario sintetico, dossier farmaceutico, consenso o diniego alla donazione di organi e tessuti) e dati integrativi rimessi alla scelta dell’assistito (prescrizioni, prenotazioni, cartella clinica, certificati, taccuino personale).

Sul consenso il regolamento separa le finalità (articolo 8). Per la cura serve un consenso generale all’alimentazione del fascicolo, revocabile; il professionista accede secondo necessità, dentro il rapporto di cura. Studio e ricerca richiedono un consenso specifico e lavorano su dati pseudonimizzati o anonimi. Programmazione e governo del sistema accedono in forma anonima o, dove giustificato, pseudonima. L’assistito mantiene il diritto di oscurare singoli documenti — un opt-out a grana documentale che riprende le Linee guida del Garante del 16 luglio 2009.

Anche qui la grana del controllo è il documento. L’oscuramento agisce su un referto intero, non su un dato al suo interno, perché il referto è l’oggetto atomico del sistema.

Punto critico

Il limite del modello a documenti è semantico, prima ancora che normativo. Lo scambio regge finché il caso d’uso è la consultazione: aprire una lettera di dimissione, leggere un referto, recuperare il profilo sintetico. Per questi scenari un documento CDA R2 firmato e conservato a norma basta e avanza.

Le cose si complicano quando si vuole interrogare il contenuto. CDA R2 ammette livelli di strutturazione diversi: dal documento a corpo narrativo (testo libero, scritto per un lettore umano) fino alle entries codificate e leggibili da una macchina. Nella pratica gran parte dei documenti regionali si ferma ai livelli più bassi, con il corpo clinico in forma narrativa. Il regolamento e gli allegati impongono la struttura CDA, non la codifica semantica dei contenuti: terminologie come SNOMED CT o LOINC restano usate in modo parziale e disomogeneo tra erogatori.

La conseguenza si misura. Una query come “tutti i pazienti con un certo valore di laboratorio fuori soglia” non gira su un repository XDS che indicizza i metadati dei documenti (tipo, autore, data, paziente) e non il loro contenuto clinico. Il sistema sa che esiste un referto di laboratorio per un assistito; non sa, in modo interrogabile e affidabile, cosa contiene. Il DPCM 178 dà interoperabilità di trasporto e di indice, e si ferma prima del significato.

Implicazioni

Per chi scrive software clinico che dialoga con il FSE, questo fissa il perimetro. Pubblicare nel FSE vuol dire produrre CDA R2 conforme ai profili italiani, firmarlo, registrarne i metadati nel Registry regionale, esporlo via XDS.b. Consumare vuol dire interrogare il Registry per i metadati, recuperare il documento dal Repository e poi — è questo il punto — fare il parsing del contenuto a valle, perché il sistema non lo restituisce già strutturato.

Il supporto alle decisioni e gli usi secondari dei dati (ricerca, sorveglianza, valutazione) si scontrano con lo stesso onere: devono ricavare la struttura da documenti scritti per essere letti, non interrogati. Finché il livello documentale resta narrativo, l’analitica sul FSE è un lavoro di estrazione, non la lettura diretta di campi.

Limiti

Il DPCM 178 chiude una fase normativa aperta da anni e dà una base coerente alla consultazione tra Regioni. I suoi vincoli sono quelli del paradigma che ha scelto.

  • L’adozione effettiva varia molto tra Regioni: alcune sono avanti, altre in ritardo strutturale.
  • La completezza dipende dalla capacità degli erogatori di produrre CDA R2 conforme: tra dichiarato e alimentato il divario è ampio.
  • La codifica semantica nei fatti è facoltativa, e questo frena ogni uso del FSE che vada oltre la lettura del documento.

Il modello a documenti firmati regge bene se l’obiettivo è integrità, non ripudiabilità e conservazione a norma. I casi d’uso che chiedono il dato granulare cresceranno: resta da vedere se si coprono estendendo questo impianto o affiancandogli un livello orientato alle risorse. In ambito HL7 quella direzione si discute già, con il lavoro su FHIR.

Immagine di copertina: Schema dell’architettura del fascicolo sanitario elettronico austriaco ELGA: piu document registry federati in alto, document… — diagramma di Sebastian19781, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:20120217_structure_of_the_Austrian_electronic_health_records_(ELGA).jpg