Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
2
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
3
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
4
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
5
Modello Architetturale Definire i servizi di supporto all’interoperabilità, i protocolli applicativi e il formato dei dati di interscambio ARCHITETTURA LOGICA Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania Ogni Ente ha la possibilità di collegarsi al sistema di connettività : mediante il nodo aggregatore; · mediante un supporto di cooperazione offerto da un altro Ente; · direttamente.
6
Modello Architetturale Federazione di NAG e NDOM elementi atomici 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. scalabile È 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. Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania
7
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
8
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,…) CUP Regionale Un esempio del modello
9
Modello Architetturale Protocolli di comunicazione tra i nodi (2/3) Reindirizzamento della richiesta di prenotazione Es.: 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 Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania
10
Modello Architetturale (8) Protocolli di comunicazione tra i nodi (3/3) Accesso diretto ad un NDOM ! 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) Sistema Pubblico Interoperabilità e Cooperazione applicativa in Campania
11
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 Sistema CUP: Funzionalità fase 1
12
Funzionalità di sistema: Analisi di robustezza Individuazione delle criticità Non devono presentarsi situazioni in cui le variazioni delle informazioni contenute nel sistema non siano a conoscenza dell’operatore preposto L’analisi di robustezza è stata effettuata sulla base delle considerazioni: 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
13
Un esempio di funzionalità: il processo di Prenotazione di una prestazione CUP Regionale
14
Interazione tra un operatore ed un Ente coinvolto nel processo di prenotazione di una prestazione: sequence diagram
15
I campi coinvolti nella Prenotazione di una prestazione NomeTipoLungDescrizioneValore HL7 2.3.1 idCupN9Identificativo del sistema che effettua la richiesta MSH.3 idOperatoreAN20Identificativo dell’operat ore che effettua la richiesta MSH.4 DataOraN12La data e l’ora della richiesta Formato: AAAAMMGGH HMI MSH.7 tipoEsenzioneN2Identificativo dell’esenzi one dell’assisti to (significati vo nel SSN) 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 CUP Regionale
Presentazioni simili
