Il Piano per l’adozione del Fascicolo Sanitario Elettronico (FSE 2.0), illustrato alla Conferenza Stato-Regioni nell’informativa del 2 marzo 2022, fissa un obiettivo tecnico preciso: passare da un fascicolo fatto di documenti firmati a uno fatto di dati interrogabili. A cambiare è il modello di interoperabilità, non i portali regionali.

Contesto

Il FSE di prima generazione, avviato in Italia dal 2012, nasce con un’architettura document-centric: i contenuti clinici sono documenti HL7 CDA R2 firmati digitalmente, indicizzati e condivisi con il profilo IHE XDS.b, e l’Infrastruttura Nazionale per l’Interoperabilità (INI), gestita da Sogei, fa da raccordo fra i fascicoli regionali. Il DPCM 178/2015 ne ha fissato il quadro normativo e i contenuti minimi.

Il limite strutturale di questo modello è noto: l’unità atomica è il documento. Un referto di laboratorio in CDA R2 lo legge una persona e lo archivia un sistema, ma il singolo valore — la glicemia, la creatininemia — fuori dal documento che lo contiene non è un dato indirizzabile. Ricostruire l’andamento di un singolo parametro su anni di referti vuol dire, in concreto, fare il parsing di documenti eterogenei prodotti da gestionali diversi.

A questo si aggiunge il Regolamento (UE) 2016/679 (GDPR), che impone una base giuridica per ogni trattamento di dati sanitari: il riuso secondario — ricerca, programmazione, farmacovigilanza — richiede estratti pseudonimizzati che il modello a documenti rende laboriosi da produrre.

Il problema che FSE 2.0 prova a risolvere

Al 2022 il FSE è istituito in tutte le Regioni, ma l’adozione è disomogenea: contenuti diversi da Regione a Regione, alimentazione non uniforme da parte degli erogatori, uso effettivo ridotto da parte di assistiti e professionisti. L’informativa del 2 marzo 2022 imputa parte di questa disomogeneità all’architettura stessa e indica le direttrici della seconda generazione:

  • allineamento dei contenuti a un nucleo minimo nazionale comune;
  • alimentazione retroattiva dei dati a partire dal 2020;
  • estensione ai dati di telemedicina, esami specialistici ambulatoriali, prescrizioni, esenzioni, vaccinazioni e taccuino dell’assistito;
  • adozione di HL7 FHIR come formato di scambio, affiancato a CDA R2 per i documenti legacy;
  • una nuova architettura con Gateway FSE nazionale ed Ecosistema Dati Sanitari (EDS) in ogni Regione.

La copertura finanziaria arriva dal PNRR, Missione 6 Salute, Componente 2, Investimento 1.3, che destina 1,38 miliardi di euro al rafforzamento dell’infrastruttura tecnologica e degli strumenti per raccogliere ed elaborare i dati sanitari.

Architettura target

Il modello del Piano introduce due livelli distinti.

Ecosistema Dati Sanitari regionale. Ogni Regione consolida in un’unica piattaforma i propri dati sanitari — documenti clinici, flussi del Nuovo Sistema Informativo Sanitario (NSIS), dati di telemonitoraggio, vaccinazioni. L’EDS è il punto in cui i dati confluiscono e da cui partono il fascicolo regionale e i flussi verso il livello nazionale. Qui il dato strutturato viene estratto dai documenti e reso indirizzabile.

Gateway FSE nazionale. Gestito da Sogei, estende il ruolo dell’INI: oltre all’interoperabilità fra Regioni, espone servizi nazionali di catalogo e identificazione dei documenti e si appoggia alle infrastrutture MEF/Sogei già esistenti (Anagrafe Nazionale Assistiti, Ricetta Elettronica, Anagrafe Vaccinale, Tessera Sanitaria), consumate come servizi.

Sui formati, CDA R2 resta per i documenti già prodotti e per la compatibilità, mentre FHIR R4 è il formato dei nuovi contenuti a dati: patient summary, referti, dati di telemonitoraggio, allergie, vaccinazioni. Le Implementation Guide italiane FHIR sono in costruzione a cura di HL7 Italia e degli enti coinvolti; al 2022 sono in fase di definizione, non ancora pubblicate come specifiche stabili.

Il punto critico

Fra CDA R2 e FHIR la differenza non è solo sintattica — entrambi usano XML, FHIR aggiunge JSON. È un cambio di granularità. In CDA il modello è il documento; in FHIR il modello è la risorsa: Patient, Observation, Condition, MedicationRequest, Immunization sono entità autonome, ciascuna con la propria identità e referenziabile via RESTful API. Una Observation FHIR è un singolo fatto clinico che si interroga, si indicizza e si aggrega senza ri-parsare il documento di provenienza.

Il costo di questa granularità ricade sull’EDS regionale, che deve produrre le risorse FHIR. Le strade sono tre, con compromessi diversi:

  • estrarre FHIR dai CDA esistenti: si eredita la qualità e le ambiguità dei documenti di partenza e si dipende dalla codifica che i gestionali hanno effettivamente usato;
  • produrre FHIR nativo alla fonte: serve aggiornare le cartelle cliniche dei singoli erogatori e rimettere mano ai capitolati verso i vendor;
  • doppio binario, con CDA e FHIR generati in parallelo durante la transizione: raddoppia la superficie da mantenere e verificare.

In tutte e tre, la qualità del risultato dipende dalla codifica con terminologie controllate — LOINC per gli esami di laboratorio, SNOMED CT dove adottato, le anagrafiche del farmaco. Una risorsa FHIR sintatticamente valida ma con codici locali non mappati è interoperabile solo in apparenza: passa la validazione strutturale, ma fra Regioni non è confrontabile. Il vincolo vero sta nella semantica sottostante, che era già il punto debole del CDA italiano.

Implicazioni

Il riuso secondario diventa tecnicamente trattabile. Su una base FHIR codificata, produrre coorti pseudonimizzate per studi osservazionali o farmacovigilanza si riduce a una query: non serve più un progetto di estrazione documentale. Il Piano prevede esplicitamente di abilitare le finalità di ricerca e programmazione sull’EDS regionale.

C’è poi il livello europeo. Il 3 maggio 2022 la Commissione Europea ha pubblicato la proposta di Regolamento sull’European Health Data Space (EHDS), COM(2022) 197 final, che distingue primary use (cura) e secondary use (ricerca, statistiche, policy) dei dati sanitari e chiederà infrastrutture nazionali compatibili. Un livello dati regionale codificato in FHIR è la precondizione tecnica per quella compatibilità, anche se a questa data il percorso legislativo dell’EHDS è appena avviato.

Limiti

La scala dell’intervento condiziona i tempi. Ventuno fascicoli regionali con architetture e vendor diversi, centinaia di aziende sanitarie con cartelle eterogenee, decine di migliaia di medici di medicina generale e pediatri con gestionali indipendenti, oltre trenta flussi informativi da riallineare: la sfida tecnica è inseparabile da quella contrattuale e organizzativa, perché ogni Regione deve riscrivere capitolati e convenzioni.

Le milestone PNRR — l’85% dei medici di medicina generale che alimentano il FSE entro giugno 2025, l’implementazione in tutte le Regioni entro il 2026 — sono condizione per l’erogazione dei fondi NextGenerationEU, legati a risultati misurabili e non alla spesa. Restano da pubblicare gli atti attuativi: l’aggiornamento del DPCM 178/2015, le Linee guida tecniche FSE 2.0 di AgID, le Implementation Guide FHIR italiane. Finché le IG non sono stabili, alcune scelte di codifica restano aperte, e con esse l’effettiva confrontabilità dei dati fra Regioni — che è poi la misura concreta del passaggio da archivio a base dati.

Immagine di copertina: Ingresso principale del Policlinico Universitario Agostino Gemelli a Roma, grande ospedale italiano — foto di Sergio D’Afflitto, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:2013-06-18_Roma_Policlinico_Gemelli.jpg