3. Modello architetturale

Questa sezione presenta le possibili topologie architetturali dei sistemi di FSE, a livello sia regionale che nazionale, ed i principali servizi infrastrutturali che ciascun sistema regionale deve offrire.

La topologia dell’architettura a livello regionale ha lo scopo di indicare le modalità di gestione delle informazioni sanitarie di competenza di ciascun dominio regionale, mentre quella a livello nazionale si pone l’obiettivo di indicare le modalità di interoperabilità dei sistemi regionali di FSE.

I servizi infrastrutturali offrono funzionalità di base abilitanti alla realizzazione di diversi casi d’uso, sia regionali che sovra-regionali.

3.1 Topologia dell’architettura a livello regionale

Ciascuna Regione o Provincia Autonoma ha più di un modello a disposizione per realizzare l’infrastruttura del sistema di FSE regionale. La scelta di un modello rispetto ad un altro è fondamentalmente legata al tipo di strutturazione organizzativa all’interno dei singoli domini regionali (ad esempio il numero di Aziende Sanitarie) e dal modello di informatizzazione adottato dalle Aziende Sanitarie.

I modelli che possono essere adottati sono essenzialmente due:

  1. Modello a repository distribuito e registry centralizzato.
  2. Modello a repository e registry centralizzati[1].

 

1.1.1  Modello a repository distribuito e registry centralizzato

Il presente modello, mostrato in Figura 11, prevede che i documenti che alimentano il FSE siano memorizzati in repository distribuiti nella rete regionale, tipicamente all’interno dei domini informatici delle Aziende Sanitarie (nodi aziendali), anche se ciò non è vincolante.

Un nodo centrale (nodo regionale) ospita il sistema che indicizza i documenti del FSE (registry). Il repository che memorizza dati e documenti caricati direttamente dal cittadino e che costituiscono il taccuino del cittadino può essere collocato su un nodo centrale, anche se questa scelta non è vincolante. Il registry è l’elemento funzionale che memorizza i metadati associati al documento o al dato indicizzato. Tra i metadati è presente l’informazione che indica dove è recuperabile il documento e gli attributi che consentono di classificarlo e di applicare regole di filtro sulla ricerca del documento stesso. Il registry indicizza sia i documenti e i dati alimentati in modo continuativo dal Servizio Sanitario Regionale, che i documenti e i dati contenuti nel taccuino.

Figura 11. Distribuzione del dato nel modello a registry centrale e repository distribuito
Figura 11. Distribuzione del dato nel modello a registry centrale e repository distribuito

 

Un elemento importante riguarda la certificazione dell’anagrafica dell’assistito da parte del sistema. Ciò è realizzato ai sensi di quanto previsto dall’art. 22, comma 1 del DPCM attuativo, il quale prevede che il FSE deve garantire l’allineamento dei dati identificativi degli assistiti con i dati contenuti nell’Anagrafe Nazionale degli Assistiti (ANA) e, nelle more dell’istituzione dell’ANA, nelle anagrafi sanitarie regionali, allineate con l’ Anagrafe Nazionale della Popolazione Residente (ANPR).

Si precisa che non è oggetto del presente documento dettagliare le modalità di colloquio fra registry e repository essendo facoltà di ogni singola Regione o Provincia Autonoma definire al proprio interno le regole di interoperabilità dei propri applicativi. Si precisa inoltre che molte Regioni che hanno realizzato il modello a repository distribuiti e registry centralizzato hanno adottato un modello implementativo in cui i repository logicamente distinti sono comunque fisicamente in hosting in un datacenter centrale, tipicamente regionale. Questo approccio non è in contrasto con il modello proposto e va incontro alle indicazioni nazionali di razionalizzazione dei datacenter regionali.

 

3.1.2  Modello a repository e registry centralizzati

Il modello a repository e registry centralizzati prevede che il registry e il repository siano localizzati in un nodo centrale, come mostrato in Figura 12.

Figura 12. Distribuzione del dato nel modello a registry e repository centralizzati
Figura 12. Distribuzione del dato nel modello a registry e repository centralizzati

 

In generale, valgono le considerazioni riportate nella descrizione del modello a repository distribuito e registry centralizzato. Questo modello è applicabile nelle Regioni e Province Autonome in cui è presente un’unica azienda sanitaria.

3.2   Topologia dell’architettura a livello nazionale

A prescindere dalla topologia dell’architettura interna di ciascun sistema di FSE regionale, l’interoperabilità dei sistemi territoriali di FSE può essere assicurata da una condivisione della topologia architetturale su base nazionale, la cui scelta impatta sulla realizzazione dei singoli sistemi territoriali in quanto ciascuna Regione o Provincia Autonoma deve predisporre specifici servizi da esporre verso l’esterno del proprio dominio.

La topologia architetturale su base nazionale, per sua natura, è fondata su un modello federato, come mostrato in Figura 13. La realizzazione del sistema di FSE a livello nazionale si basa sulla cooperazione dei nodi regionali che ospitano l’infrastruttura tecnologica che realizza il sistema regionale di FSE. Tutti i nodi regionali cooperano secondo una gerarchia paritetica esponendo ed invocando i servizi realizzati dagli altri nodi necessari alla condivisione del contenuto informativo del FSE a livello nazionale.

I nodi regionali prevedono la presenza di tutte le componenti infrastrutturali del FSE e sono in grado di garantire tutte le funzionalità necessarie alla gestione, ricerca e consultazione dei dati e documenti di propria competenza (ossia relativi ai propri assistiti), ovunque essi siano disponibili, e alla comunicazione con gli altri nodi regionali.

In particolare, il modello prevede che la Regione di Assistenza (RDA) di un assistito ha l’onere di mantenere la gestione dei riferimenti ai documenti riguardanti i suoi assistiti, anche se tali documenti sono prodotti e conservati in altri domini regionali. Pertanto, i sistemi di FSE devono essere in grado di trasmettere e ricevere i metadati relativi ai documenti trattati e prodotti durante il percorso di cura di un assistito. In questo scenario di funzionamento, ogni dominio regionale deve identificare la RDA di un paziente e comunicare con il sistema di quest’ultima. La gestione dei metadati da parte della RDA permette di velocizzare la costruzione dell’indice dei documenti presenti nel FSE. In questo modo, per effettuare la ricerca dei documenti di un dato paziente, occorre interrogare unicamente il nodo regionale del sistema della RDA del paziente.

Figura 13. Topologia dell’architettura dei sistemi di FSE a livello nazionale
Figura 13. Topologia dell’architettura dei sistemi di FSE a livello nazionale

 

Il modello architetturale prevede l’adozione del Sistema Pubblico di Connettività per le comunicazioni interregionali. Conseguentemente, per ogni nodo regionale è previsto il collegamento mediante una Porta di Dominio con gli altri sistemi regionali di FSE.

In aggiunta alle funzionalità offerte dai sistemi regionali, è possibile prevedere che specifiche funzioni trasversali su base nazionale (terminologie, elenco dei ruoli, policy, certificati digitali, servizi di discovery service, ecc.) siano offerte da una piattaforma centralizzata a livello nazionale.

3.3 Servizi infrastrutturali

Il sistema infrastrutturale di FSE adottato da ciascuna Regione o Provincia Autonoma deve realizzare almeno i seguenti servizi infrastrutturali:

  1. Indicizzazione dei documenti e dati che costituiscono il FSE.
  2. Ricerca dei documenti e dati del FSE di propria competenza.
  3. Recupero dal FSE dei documenti e dati di propria competenza.
  4. Verifica delle politiche di accesso ai servizi e ai documenti e dati.
  5. Interoperabilità con altri sistemi regionali, che include la realizzazione del servizio per la comunicazione dei metadati di cui al cap. 6.3.3 del disciplinare tecnico allegato al DPCM attuativo.
  6. Tracciamento delle operazioni.
  7. Business continuity e disaster ricovery.
  8. Conservazione di dati e documenti digitali.

I servizi di tipo applicativo che devono essere realizzati e resi disponibili dai sistemi regionali sono descritti nelle prossime sezioni.

3.3.1 Servizio per l’indicizzazione dei documenti e dati

Il servizio di indicizzazione ha l’obiettivo di memorizzare nel registry del nodo regionale una serie di metadati che descrivono i documenti e dati prodotti nelle strutture sanitarie, generati dai medici o dagli operatori o professionisti sanitari oppure condivisi dagli assistiti. Il servizio deve consentire anche l’aggiornamento dei metadati che descrivono i documenti e dati già memorizzati nei registry. Tale aggiornamento deve essere effettuato in maniera tale da non eliminare definitivamente i metadati precedentemente memorizzati.

L’elenco minimale dei metadati da memorizzare da parte di ciascun sistema regionale, sia che essi siano relativi a documenti o dati memorizzati nel dominio regionale a cui il sistema fa riferimento, sia che essi siano memorizzati in altri domini regionali, è indicato in Tabella 4, in conformità con quanto stabilito nel paragrafo 6.2 del disciplinare tecnico allegato al DPCM attuativo.
 

Tipo metadato

Descrizione

Tipologia

Indica il tipo di dato/documento (referto di laboratorio, profilo sanitario sintetico, ecc.) ed è rappresentato da un codice LOINC.

Stato

Indica lo stato corrente del dato/documento (approvato, obsoleto, aggiornato, ecc.).

Identificativo documento o dato aggiornato

Elemento da memorizzare solo nel caso in cui il documento/dato a cui i metadati fanno riferimento aggiorna un precedente documento/dato presente nel FSE. In tal caso, l’elemento deve contenere il riferimento al documento o dato aggiornato, secondo la struttura presentata all’ultima riga.

Data

Indica la data di creazione del dato/documento.

Identificativo del paziente

Rappresenta il codice fiscale del paziente a cui il dato/documento fa riferimento.

Fonte

Indica se il dato/documento è stato caricato nel FSE da un operatore sanitario o socio-sanitario oppure dall’assistito (nel taccuino personale).

Riferimento

Rappresenta un puntatore al dato/documento ed è suddiviso in:

  • Identificativo regionale – codice per l’identificazione della Regione o Provincia Autonoma contenente il dato/documento.
  • Identificativo della struttura sanitaria – codice per l’identificazione della struttura sanitaria contenente il dato/documento.
  • Identificativo del dato/documento – identificativo unico e persistente.
 

Tabella 4. Elenco dei metadati da memorizzare nei registry per ciascun documento o dato

Si sottolinea che ogni sistema regionale può prevedere altri metadati atti a descrivere ulteriormente i documenti o i dati pertinenti agli assistiti.

3.3.2  Servizio per la ricerca dei documenti e dati

Il servizio per la ricerca dei documenti e dati deve consentire il recupero dei metadati di indicizzazione dei documenti e dati di interesse sulla base di opportuni criteri di ricerca, in linea con le tipologie di metadati riportate in Tabella 4.

3.3.3  Servizio per il recupero dei documenti e dati

Il servizio per il recupero deve consentire il reperimento di un documento o dato di interesse a partire dal riferimento ad esso, ottenuto dopo aver interagito con il servizio di ricerca. In particolare, l’interazione con il servizio di ricerca è condizione necessaria per l’accesso al presente servizio.

3.3.4  Servizio per la verifica delle politiche di accesso

Il servizio per l’applicazione di politiche di accesso ha lo scopo di verificare i privilegi degli utenti che intendono accedere ai servizi e ai dati e documenti offerti dal sistema regionale del FSE. In generale, l’accesso a tali servizi è disciplinato da opportune politiche di accesso basate su scelte regionali conformi alle regole nazionali indicate al cap. 4.2 del disciplinare tecnico allegato al DPCM attuativo sul FSE. Allo scopo di consentire al presente servizio di verificare i privilegi dell’utente, tutte le richieste di accesso ai servizi offerti dal sistema regionale devono contenere opportune attestazioni certificanti opportuni attributi, dipendenti dai casi d’uso e dai servizi. Il presente servizio analizza tali attestazioni e, in caso di successo, concede all’utente l’accesso al servizio; in caso contrario, l’accesso viene negato.

Le politiche di accesso operano sui seguenti elementi fondamentali:

  • Il ruolo dell’utente che richiede l’accesso.
  • Il contesto operativo.
  • Il consenso informato manifestato dall’assistito (o dal tutore o dal genitore).
  • I criteri di visibilità e di oscuramento indicati dall’assistito (o dal tutore o dal genitore).

Ciascun sistema regionale di FSE può far riferimento a ruoli e contesti definiti localmente. Tuttavia, in caso di interazione con altri sistemi regionali di FSE, questi ultimi devono essere mappati con ruoli e contesti condivisi su scala nazionale, indicati in

Tabella 5 e in Tabella 6.

3.3.5  Servizi per l’interoperabilità con gli altri sistemi regionali di FSE

I servizi per l’interoperabilità con gli altri sistemi regionali di FSE sono descritti in dettaglio nella sezione 6.

3.3.6  Servizi per il tracciamento delle operazioni

Ciascuna operazione effettuata dai servizi del sistema regionale deve essere debitamente tracciata mediante servizi di audit log o similari, che consentano di ricostruire la sequenza delle attività svolte, con riferimento ai seguenti dati minimi, laddove pertinenti:

  • Identificativo dell’utente che ha richiesto l’operazione.
  • Identificativo dell’organizzazione (Regione/P.A., struttura sanitaria, ecc.) in cui è stata effettuata l’operazione.
  • Identificativo del sistema informatico che ha eseguito l’operazione.
  • Tipologia dell’operazione.
  • Contesto operativo.
  • Dati o documenti oggetto della richiesta.
  • Istante di tempo.
  • Esito dell’operazione (riuscita, fallita).

3.3.7 Servizi per la business continuity ed il disaster recovery

Ai sensi dell’art. 24, comma 10 del DPCM attuativo sul FSE, il sistema infrastrutturale di FSE deve garantire servizi per la continuità delle operazioni indispensabili per le funzioni offerte ed il ritorno alla normale operatività mediante opportuni piani di continuità operativa e di disaster recovery, come disciplinato all’art. 50 bis del CAD.

Le macro funzioni descritte nella sezione 1 che fanno riferimento ai servizi per la business continuity ed il disaster recovery sono mostrate in Figura 14.

3.3.8 Servizi per la conservazione dei documenti e dati

Ciascun sistema regionale di FSE deve prevedere servizi per la conservazione dei documenti e dati, così come descritto nella sezione 9.

Le macro funzioni descritte nella sezione 1 che fanno riferimento ai servizi per la conservazione dei documenti e dati sono mostrate in Figura 14.

Figura 14. Macro funzioni relative ai servizi per business continuity, disaster recovery e conservazione
Figura 14. Macro funzioni relative ai servizi per business continuity, disaster recovery e conservazione

3.4 Accordi di collaborazione

Nel principio dell’ottimizzazione e razionalizzazione della spesa informatica, le Regioni e le Province Autonome, possono, anche mediante la definizione di appositi accordi di collaborazione, realizzare infrastrutture tecnologiche per il FSE condivise a livello sovra-regionale, ovvero avvalersi, anche mediante riuso, ai sensi del decreto legislativo 7 marzo 2005, n. 82, delle infrastrutture tecnologiche per il FSE a tale fine già realizzate da altre regioni o dei servizi da queste erogate, ovvero partecipare alla definizione, realizzazione e utilizzo dell’infrastruttura nazionale per l’interoperabilità per il FSE conformemente ai criteri stabiliti dai decreti di cui al comma 7 del D.L. 179/2012 e ss.mm.ii., resa disponibile dall'Agenzia per l’Italia digitale.

La volontà di realizzare accordi di collaborazione o di servirsi dell’infrastruttura nazionale per l’interoperabilità deve essere esplicitata dettagliatamente nella presentazione dei piani di progetto, illustrandone i modi e i servizi richiesti nella sezione dedicata del documento “Linee guida per la presentazione dei piani di progetto regionali per il FSE”.


[1] Questo modello è applicabile in ottemperanza alle linee Guida del Garante sul tema di memorizzazione di dati e documenti e loro titolarità.

Last update: 06/02/2018