Salute Digitale

Sarà l’Ecosistema dei Dati Sanitari la chiave di volta del Fascicolo Sanitario Elettronico. Tutti i temi ancora sul tappeto.

Approvato il decreto che regola la parte “documentale” del Fascicolo Sanitario Elettronico (FSE) 2.0 il Ministero della Salute, il Dipartimento per la Trasformazione Digitale e le Regioni stanno lavorando alla definizione dell’Ecosistema dei Dati Sanitari (EDS). Tanti sono gli aspetti che devono trovare una risposta e che cercherò di riportare in una serie di articoli, di cui questo è il primo.

Una prima osservazione riguarda il metodo scelto che immagino sia stato anche determinato dalle tempistiche PNRR. Si sono definiti i dati che compongono i file CDA iniettati nei PDF prima di definire quali servizi si vogliono realizzare con l’EDS. Sarebbe stato meglio fare il contrario e cioè determinare quali dati sarebbero stati necessari per sviluppare dei cruscotti o delle funzioni nel EDS. Volendo adoperare un lessico giuridico definire prima i “trattamenti” da cui derivare i dati. Questo approccio avrebbe anche, a mio giudizio, facilitato l’interlocuzione con il Garante che è in corso e sul quale tornerò più avanti.

In termini architetturali la discussione con le Regioni è ancora in corso ma possiamo dire che con molta probabilità l’EDS sarà “federato”, ossia composto da vari EDS regionali. La scelta, a livello di interoperabilità, è caduta su FHIR che molte regioni stanno anche pensando di adoperare per la persistenza dei dati creando repository FHIR, scelta piuttosto rischiosa e non corretta. Qui potete trovare vari articoli in cui spiego le ragioni di questa opinione.

Rimanendo però sull’interoperabilità, la scelta di FHIR che condivido pone la questione di come federare i diversi server in cui saranno disponibili le informazioni (risorse nel concetto di FHIR) dei pazienti. A livello documentale abbiamo la tecnologia ebXML e la presenza dei registry che risolvono il problema. Cosa impiegare nel caso di FHIR? HL7 suggerisce tre possibili strade:

In un ambiente in cui le informazioni rilevanti possono essere distribuite su più server, i sistemi client avranno bisogno di un meccanismo per determinare dove si trovano i dati.
Esistono tre meccanismi principali per il rilevamento:

• Configurazione manuale: I sistemi vengono configurati manualmente per puntare ad altri server (rilevanti) con indicazioni su quali tipi di dati risiedono in quale server, l’indirizzo del server, le informazioni di autenticazione necessarie, o codificate nel software o gestite attraverso i file di configurazione del sistema
• Traversale: I sistemi client dovrebbero iniziare le interrogazioni da un singolo server che gestisce le risorse “primarie” (ad esempio, incontri, referti diagnostici, episodi, ecc. Altre informazioni rilevanti, come diagnosi, osservazioni, condizioni, procedure, ecc. vengono reperite navigando attraverso i riferimenti contenuti nelle risorse primarie
• Registro di sistema: I sistemi client scoprono l’insieme “attuale” di server rilevanti interrogando una posizione centrale per gli endpoint dei server che contengono dati rilevanti

La prima ipotesi non è utilizzabile, la seconda è complessa visto l’elevato numero di risorse che possono essere associate ad ogni paziente, la terza è più fattibile ma comunque non banale da realizzare anche per le elevate numeriche in gioco.

Ritornando all’aspetto privacy c’è il problema di come gestire il diritto all’oscuramento che oggi viene espresso a livello di documenti. È possibile pensare di mantenere questa impostazione dal momento che da ogni documento verranno estratte più risorse FHIR, a patto però di mantenere il legame documento – risorse FHIR.

Rimane poi una questione centrale: quali servizi dovrà esporre l’EDS? Limitarsi ai soli dati o includere delle elaborazioni o delle funzioni? In altre parole la “logica” sarà parte dell’EDS o a carico dei sistemi che lo invocheranno? La risposta è complessa e tenterò di spiegarvela nel prossimo articolo.

1 – Continua