sistema pubblico interoperabilità e cooperazione applicativa in campania

Requisiti Funzionali del SistemaRequisiti 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 (Requisiti Funzionali del Sistema (22))

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à)


Requisiti non Funzionali del SistemaRequisiti 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


Modello ArchitetturaleModello Architetturale

Definire i servizi di supporto all’interoperabilità, i protocolli applicativi e il formato dei dati di interscambio

ARCHITETTURA LOGICA


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.

Modello Architetturale Modello Architetturale

Federazione di NAG e NDOMFederazione 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 atomicielementi atomici di questo modello architetturale) sia altri nodi aggregatori.

È proprio grazie a questo modello scalabilescalabile che è possibile preservare e rispettare le autonomie dei sistemi preesistenti, requisito fondamentale per la messa in opera 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 modelloCUP 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,…)

CUP Regionale Un esempio del modelloCUP Regionale Un esempio del modello

Modello Architetturale 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


Modello Architetturale Modello Architetturale (8)(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)


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 RegionaleCUP Regionale

Sistema CUP: Funzionalità fase 1

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


Un esempio di funzionalità: il processo di Prenotazione di una prestazione



Interazione tra un operatore ed un Ente

coinvolto nel processo di prenotazione di una prestazione: sequence

diagram

I campi coinvolti nella Prenotazione di una prestazione

Nome Tipo Lung Descrizione Valore HL7 2.3.1

idCup N 9 Identificativo del sistema che effettua la richiesta

MSH.3

idOperatore AN 20 Identificativo dell’operatore che effettua la richiesta

MSH.4

DataOra N 12 La data e l’ora della richiesta

Formato:AAAAMMGGH

HMIMSH.7

tipoEsenzione N 2 Identificativo dell’esenzione dell’assistito (significativo 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


sistema pubblico interoperabilità e cooperazione applicativa in campania

Documents