I processi di interoperabilità fra i differenti sistemi di FSE a livello nazionale sono realizzati mediante l’INI, che si pone come mediatore per le comunicazioni tra i diversi sistemi regionali, secondo un modello architetturale con topologia a stella e definita nel “Documento di progetto dell’Infrastruttura Nazionale per l’Interoperabilità dei Fascicoli Sanitari Elettronici (art. 12 - comma 15-ter – D.L. 179/2012)” emanato con circolare AgID n.4 del 1 agosto 2017 e richiamata nel DM 4 agosto 2017 “Modalità tecnica e servizi telematici resi disponibili dall’Infrastruttura nazionale per l’interoperabilità del Fascicolo Sanitario Elettronico (FSE) di cui all’art.12, comma 15-ter del Decreto-Legge 18 ottobre 2012, n.179, convertito con modificazioni dalla Legge 17 dicembre 2012, n.221” emanato dal MEF di concerto con il Ministero della Salute.

Inoltre, i processi sono modellati in conformità a quanto definito nei Gruppi Tematici sul FSE, istituiti presso il Tavolo tecnico di monitoraggio e indirizzo FSE (articolo 26 DPCM 178/2015), cui si rimanda a quanto definito nei deliverable risultanti per le regole, le politiche e le modalità di interazione con il FSE.

La modellazione e la realizzazione dei processi e dei servizi di interoperabilità prevede l’adozione del profilo IHE XDS.b. Si sottolinea, infatti, che il cittadino assistito dal sistema sanitario nazionale, la cui anagrafica quindi è presente nel Sistema TS e a tendere nel sistema ANA, ha una sola RDA. Dal punto di vista architetturale ciò si traduce nella presenza di un unico Registry di riferimento per uno specifico cittadino (Registry gestito dalla sua RDA). In questo scenario in cui il sistema anagrafico di riferimento, per quel che riguarda i processi interregionali, è sovra regionale, il sistema di FSE di una regione diversa da quella di assistenza si configura come un consumer (tramite l’INI) all’interno dello stesso Affinity Domain[1] . In particolare l’INI, ponendosi come mediatore tra tutti i sistemi dell’Affinity Domain, fornisce i servizi per l’interoperabilità e l’interconnessione tra tutti i sistemi di FSE, come rappresentato in Figura 1.

Un altro principio di interoperabilità importante riguarda la scelta di applicare processi di verifica delle policy su dati certificati da sistemi autoritativi e di veicolare dati certificati mediante asserzioni firmate. Dal punto di vista tecnologico si prevede l’uso dello standard SAML 2.0, come descritto di seguito e rappresentato sinteticamente in Figura 2 e Figura 3.
 

Allo scopo di semplificare i processi di interoperabilità del FSE, l’INI consente, in maniera trasparente ai sistemi regionali di FSE, l’identificazione del paziente tramite il sistema ANA e l’inoltro verso il corretto sistema regionale di FSE della richiesta ricevuta. Pertanto, il sistema regionale di FSE che necessita di effettuare una richiesta di interoperabilità inoltra la richiesta all’INI senza preoccuparsi di individuare la RDA del paziente.

I dati “certificati” che sono veicolati dai servizi di interoperabilità sono trasportati da asserzioni firmate dall’Ente autoritativo. In particolare sono previsti tre differenti asserzioni:

Asserzione di Identificazione: certifica gli identificativi anagrafici (la lista dei codici fiscali) associati ad un assistito; viene rilasciata dall’INI, mediante interazione con l’ANA, in risposta alle richieste di servizi di interoperabilità nel caso in cui al paziente sono associati più codici fiscali.

Asserzione di Attributo: certifica i dati relativi all’utente del sistema di FSE regionale che effettua la richiesta, il contesto operativo e il tipo di attività che si vuole effettuare; è rilasciata e firmata dalla regione che richiede un servizio di interoperabilità (o dall’INI per il processo di trasferimento dell’indice). L’INI utilizza questa asserzione per ottenere il codice fiscale del paziente da validare e effettuare eventuali verifiche di autorizzazione, inoltre la regione che riceve la richiesta di servizio da parte di INI può utilizzare questa asserzione per effettuare ulteriori verifiche. La regione RCD utilizza questa asserzione anche per tracciare le informazioni per l’audit.

Asserzione di Informativa: certifica i dati relativi all’utente del sistema di FSE regionale che effettua la richiesta di comunicazione o recupero informativa e modulistica di acquisizione consensi e revoche; l’asserzione è rilasciata e firmata dalla regione. L’INI utilizza questa asserzione per verificare l’autorizzazione dell’operatore alla richiesta di inoltro/recupero della informativa e della modulistica.

Le asserzioni in formato SAML 2.0 sono trasportate nell’header del messaggio SOAP v1.2 sfruttando le specifiche WS-Security. Il contenuto informativo di tutto il portafoglio di asserzioni viene valutato, congiuntamente allo strato di business della richiesta di servizio, per l’applicazione delle politiche di accesso al documento. Si precisa che, come da standard SAML 2.0, nel caso in cui la richiesta venga effettuata dalla RDA dell’assistito, l’INI risponde inviando l’asserzione di identificazione dell’assistito nell’header del messaggio di risposta unicamente nel caso in cui all’assistito sono associati più codici fiscali.

Di seguito si riportano sinteticamente le attività svolte dai diversi attori che partecipano ad un processo di interoperabilità.

● RDE ha il compito di:

○ autenticare ed autorizzare l’operatore che accede al FSE (secondo le policy di RDE e di interoperabilità);

○ identificare anagraficamente il cittadino, anche se non assistito dalla RDE, mediante l’nterazione con l’ANA mediata dall’INI;

○ invocare il servizio di interoperabilità tramite l’INI e visualizzare il risultato.

● RDA ha il compito di:

○ autenticare ed autorizzare l’Ente richiedente;

○ autorizzare l’utente richiedente (secondo le policy di interoperabilità e di RDA);

○ implementare i servizi di interoperabilità invocato dall’INI per conto della RDE;

○ implementare i servizi di interoperabilità invocati dall’INI;

○ le politiche di accesso sono applicate sui dati contenuti nella asserzione di attributo.

● INI ha il compito di:

○ verificare che la richiesta sia valida;

○ validare il codice fiscale dell’assitito indicato mediante interazione con ANA;

○ verificare i consensi alla alimentazione e alla consultazione dell’assistito per il codice fiscale indicato;

○ verificare la RDA sanitaria per il codice fiscale indicato mediante interazione con ANA;

○ inoltrare la richiesta al sistema regionale di pertinenza una volta ricevuta la richiesta per la fruizione di un servizio di interoperabilità da parte di una regione richiedente;

○ richiedere alla RPDA il trasferimento dell’indice di un paziente;

○ implementare i servizi per la gestione dei consensi;

○ implementare i servizi per la gestione delle informative e della modulistica per l’acquisizione dei consensi e revoche.

Nel prossimo paragrafo si riportano, schematicamente, i sequence diagram relativi ai casi d’uso di interoperabilità identificati nelle specifiche tecniche.

[1] Secondo la terminologia IHE, un Affinity Domain consiste in un gruppo di organizzazioni che hanno concordato di cooperare utilizzando un insieme di politiche e una infrastruttura comune.