Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania
Requisiti Funzionali del Sistema
Obiettivo: realizzare un ambiente distribuito nel quale tutti gli Enti Regionali possano
interagire prescindendo dalle piattaforme e dai linguaggi utilizzati
1. Meccanismi di integrazione ed interoperabilità
•
Servizi di indicizzazione e ricerca
•
Servizi di pubblicazione
•
Servizi di presentazione
2. Meccanismi per la gestione della sicurezza
•
Servizi di autenticazione e autorizzazione
- Identificazione ed autenticazione tra Enti
- controllo degli accessi (autorizzazione)
- auditing e monitoring (tracciabilità)
Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania
Requisiti Funzionali del Sistema (2)
3. Meccanismi per offrire qualità differenti dello stesso servizio
4. Meccanismi per la gestione dell’accesso da dispositivi eterogenei
•
Servizi orientati a tecnologie wired e wireless (Multicanalità)
Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania
Requisiti non Funzionali del Sistema
•
Apertura e Scalabilità
•
Personalizzazione dei servizi
•
Affidabilità e disponibilità dei servizi
Nello sviluppo di una architettura per l’interoperabilità si devono,
inoltre, tener presente anche requisiti di tipo organizzativo:
•
Sviluppo ed attuazione di un piano di gestione dei servizi nel
•
rispetto delle autonomie
•
rispetto della normativa vigente
Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania
Modello Architetturale
Definire i servizi di supporto all’interoperabilità, i protocolli applicativi e il
formato dei dati di interscambio
Ogni Ente ha la possibilità
di collegarsi al sistema di
connettività :
• mediante
aggregatore;
il
nodo
•· mediante un supporto di
cooperazione offerto da un
altro Ente;
•· direttamente.
ARCHITETTURA LOGICA
Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania
Modello Architetturale
Federazione di NAG e NDOM
La federazione di servizi, strutturabile a
livelli, consente l’accesso ai servizi terminali
sottostanti ma anche ai nodi aggregatori dei
livelli sottostanti, dato che ad un nodo si
possono
iscrivere
sia
servizi
base
(considerati gli elementi atomici di questo
modello architetturale) sia altri nodi
aggregatori.
È proprio grazie a questo modello scalabile
che è possibile preservare e rispettare le
autonomie dei sistemi preesistenti, requisito
fondamentale per la messa in opera del
modello.
CUP Regionale Un esempio del modello
Una particolarizzazione del modello SPICCA: Sistema CUP Regionale
Il livello di aggregazione/intermediazione viene assolto dal nodo
regionale che si preoccupa di effettuare l’aggregazione dei servizi erogati
dagli enti partecipanti ed esporre un’interfaccia unica per l’accesso al
sistema CUP
CUP Regionale Un esempio del modello
Particolarizzazione del modello SPICCA: Sistema CUP Regionale
I singoli Enti o nodi erogatori si preoccupano di esporre i servizi
resi da loro disponibili nell’ambito del Sistema. Tali servizi devono
essere resi omogenei e standardizzati in modo da ottenere identiche
funzionalità.
La differenziazione tra gli Enti coinvolti è data dalle proprie basi
informative (agenda delle prestazioni erogabili, anagrafe assistiti,
medi di base,…)
Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania
Modello Architetturale
Protocolli di comunicazione tra i nodi (2/3)
Es.: in una richiesta di prenotazione di una
prestazione sanitaria, è possibile che un
nodo che non ha più disponibilità possa
automaticamente inoltrare la richiesta ad
un altro nodo erogatore.
Il Nodo di dominio che inoltra la richiesta
del servizio trova un altro Nodo di dominio
che è disponibile ad erogare il servizio
Reindirizzamento della richiesta di
prenotazione
Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania
Modello Architetturale (8)
Protocolli di comunicazione tra i nodi (3/3)
Ogni servizio è realizzato in modo tale da
poter essere utilizzato anche direttamente,
senza cioè dover passare attraverso la
piattaforma di accesso !
L’accesso diretto deve inoltre avvenire da una
rete sicura, realizzata mediante meccanismi di
rete privata o mediante protocolli sicuri come
l’SSL (Secure Socket Layer)
Accesso diretto ad un NDOM
CUP Regionale
Sistema CUP: Funzionalità fase 1
Il Sistema CUP
Regionale si realizza
mediante l’espletazione
di due fasi; in
particolare, nella prima
fase è stato individuato
un set minimo di
funzionalità per la
prenotazione,
visualizzazione,
cancellazione delle
prestazioni e
consultazione anagrafe
assistiti e medici di
base
CUP Regionale
Funzionalità di sistema: Analisi di robustezza
L’analisi di robustezza è stata effettuata sulla base delle considerazioni:
• Individuazione delle criticità
• Non devono presentarsi situazioni in cui le variazioni delle informazioni
contenute nel sistema non siano a conoscenza dell’operatore preposto
Dall’analisi svolta si evince la necessità di definire un :
• protocollo funzionale
• protocollo di comportamento
L’applicazione di tali protocolli garantisce il raggiungimento della
robustezza del Sistema
CUP Regionale
Un esempio di funzionalità: il processo di Prenotazione di una prestazione
CUP Regionale
Interazione tra un
operatore ed un Ente
coinvolto nel processo
di prenotazione di una
prestazione: sequence
diagram
CUP Regionale
I campi coinvolti nella Prenotazione di una prestazione
Nome
idCup
idOperatore
Tipo
Lung
N
9
AN
20
Descrizione
Valore
HL7 2.3.1
Identificativo del
sistema
che
effettua la
richiesta
MSH.3
Identificativo
dell’operat
ore che
effettua la
richiesta
MSH.4
DataOra
N
12
La data e l’ora
della
richiesta
tipoEsenzione
N
2
Identificativo
dell’esenzi
one
dell’assisti
to
(significati
vo nel
SSN)
Formato:
AAAAMMGGH
HMI
MSH.7
PV1.2
Nell’ambito della definizione
dei tracciati delle informazioni
si è provveduto a:
• Individuare i campi necessari
• Dimensionare in modo
opportuno i campi individuati
• Rendere compatibili i campi
con lo standard internazionale
HL7