Il sistema di Cooperazione applicativa per la Rete delle Anagrafi

Transcript

1 Regione Toscana Giunta Regionale Servizio IITR Il sistema di Cooperazione applicativa per la Rete delle Anagrafi Pubblicazione degli Eventi Anagrafici Ver. 1.0 Draft. 1

2 DOCUMENTO: Pubblicazione degli eventi anagrafici. Emesso da: EMISSIONE VERIFICA APPROVAZIONE Nome firma Verificato da: Approvato da: Approvato da: LISTA DI DISTRIBUZIONE Giancarlo Galardi, Angelo Marcotulli, Sarima Gianetti, Patrizia Parigi, lista PO AGGIORNAMENTI Versione Data Paragrafi Modificati Motivo Modifica /08/2003 Prima stesura Gestione eventi ver.1.0 2

3 Sommario 1 Introduzione Scopo e applicabilità Documenti di riferimento e documenti applicabili... 5 Documenti di riferimento... 5 Documenti applicabili Glossario... 6 Acronimi... 6 Definizioni Descrizione generale Identificazione degli Eventi Applicativi Comune Tipi di Evento pubblicati Azienda Sanitaria Locale...14 Tipi di evento pubblicati Tipi di evento ricevuti Amministrazione Regionale Tipi di evento pubblicati Tipi di evento ricevuti Cooperazione Applicativa tra Domini basata su eventi Cooperazione fra Comuni, Regione Toscana e A.S.L Comunicazione Evento Comunicazione Nascita (uc.1) Comunicazione Morte (uc.2) Trasferimento o Variazione Dati Anagrafici (uc.3) Comunicazione Iscrizione AIRE (uc. 4) Formalizzazione degli Eventi Classi di eventi Allegati I Package definiti Package saia-ancitel-giada Package Pubblicazione Esempio di descrizione dei messaggi associati agli eventi (XML) Rappresentazione grafica degli elementi del messaggio (con intestazione espansa) Rappresentazione grafica degli elementi XML v DTD degli eventi descritti Nascita 31 Morte 32 VariazioneDatiAnagrafici CambioIndirizzo Emigrazione Immigrazione

4 IscrizioneAIRE Indice delle Tabelle Tabella 1 Tipi corrispondenti alla classe SaiaEvent

5 1 Introduzione 1.1 Scopo e applicabilità Il presente documento ha l'obiettivo di documentare i servizi ed i protocolli che sono stati implementati per realizzare la cooperazione applicativa nell ambito del progetto Rete delle Anagrafi in relazione al SAIA (Sistema di accesso e interscambio Anagrafico) ed al progetto GIADA (Gestione Integrata dell Anagrafe Degli Assistiti Sociosanitari della Regione Toscana). Il sistema realizzato consente l'interoperabilità tra tutti i soggetti coinvolti, ed in particolare fra Comuni, A.S.L. e RTRT, garantendo l'interscambio dei dati. Il documento è rivolto agli specialisti tecnici della Regione Toscana, delle Amministrazioni Regionali e Comunali, delle A.S.L., del Ministero per l innovazione e le Teconologie, e di tutti i soggetti istituzionali che intendono cooperare e garantire l'interscambio dei dati fra soggetti su scala nazionale. 1.2 Documenti di riferimento e documenti applicabili Documenti di riferimento Documenti applicabili Interoperabilità CI Modello Porte di dominio (Regione Toscana) Servizio di Cooperazione Applicativa basato su Eventi (AIPA) Modello delle Porte di Dominio di Comune, INPS, Ministero di Grazia e Giustizia, Camera di Commercio (INPS) GIADA: Specifiche requisiti e modello architetturale Regione Toscana: CART Infrastruttura per la cooperazione applicativa 5

6 1.3 Glossario Acronimi SAIA: Sistema di accesso e interscambio Anagrafico GIADA: Gestione Integrata dell Anagrafe Degli Assistiti Sociosanitari della Regione Toscana ASL: Azienda Sanitaria Locale AIRE: Anagrafe degli Italiani Residenti all Estero DTD: Document Type Definition G.E.: Gestore Eventi P&S: Publish and Subscribe RUPA: Rete Unitaria della Pubblica Amministrazione UML: Unified Modelling Language VPN: Virtual Private Network. XML: extensible Markup Language Definizioni Ente: ente locale coinvolto nel progetto di Rete Anagrafi, si assume che l Ente disponga di un DB-server con base dati normalizzata come da specifiche del predetto progetto. Classe: nella programmazione ad oggetti, è la definizione di un insieme di oggetti (vd) simili, dei loro attributi (caratteristiche comuni) e/o dei metodi (vd), cioè delle funzioni/procedure che possono essere loro applicate. La classe e' quindi un'astrazione che include una struttura di dati con (opzionale) una serie di procedure (i metodi) che creano, accedono e modificano la stessa. Dominio: insieme di risorse hardware e software che appartengono ad un organizzazione/ ente. DTD: Document Type Definition, documento per la definizione di tipi di dati. E' la definizione formale della struttura di un documento e specifica come i marcatori devono essere interpretati dall'applicazione di presentazione del documento. Evento: qualsiasi azione o avvenimento, spesso generato dall'utente, a cui un programma è in grado di rispondere, per esempio, la pressione di tasti o pulsanti e i movimenti del mouse. Vedi anche programmazione guidata dagli eventi. 6

7 Metodo: nella programmazione ad oggetti, è una procedura/funzione definita come parte di una classe ed applicabile ad ogni oggetto della classe. Una classe (e quindi un oggetto ad essa appartenente) può avere più di un metodo. Un metodo può essere applicato solo sui dati conosciuti per quell'oggetto, ed assicura l'integrità dei dati fra l'insieme degli oggetti in un'applicazione. Middleware: ambienti operativi che filtrano il sistema di trasporto ed i protocolli utilizzati. Oggetto: nella programmazione ad oggetti, è una specifica istanza di una particolare classe, a cui possono essere applicati i metodi di quella classe. Contiene i valori reali degli attributi. Porta Applicativa: insieme delle funzioni/servizi che il Dominio intende rendere disponibili (esportare) ad altri Domini. Porta Delegata: svolge le funzioni di cliente di un Dominio nei confronti delle Porte Applicative di altri Domini (importare). Porta di Dominio: insieme delle porte di un Dominio (Porta Applicativa, Porta Delegata, eventuali Porta di Pubblicazione e Porta di Sottoscrizione, Porta di Trasmissione e Porta di Ricezione). Proxy (gateway applicativo): Nodo di Internet (o di una LAN, ecc..) compreso di software di gestione che si interpone fra l'host dell'utente e il resto della rete per la gestione del traffico. Generalmente fornisce un controllo dell'accesso alla rete stessa, impedendo l'ingresso delle richieste non autorizzate e può fornire funzioni come il caching di documenti. Use-case: rappresentazione delle modalità di utilizzo del sistema da parte degli attori coinvolti (servizi richiesti e offerti dai domini). Possono essere descritti sotto forma di scenario di interazione fra gli utilizzatori e il sistema. UML: linguaggio standard per rappresentare, costruire e documentare un sistema software modellato a oggetti. XML: metalinguaggio, ovvero linguaggio utilizzato per creare altri linguaggi, basato su marcatori. L XML è uno standard W3C per la rappresentazione di informazioni in modo strutturato. XML aiuta lo sviluppatore nel descrivere e fornire strutture dati da e per ogni applicazione in modo standard e consistente. 7

8 2 Descrizione generale. I Comuni devono comunicare, come stabilito da diverse norme, ad altri Enti le variazioni dei dati delle persone fisiche memorizzate nelle loro anagrafi. Occorre pertanto gestire in modo efficace ed efficiente le funzionalità che consentono l'interscambio di informazioni fra i diversi soggetti e in particolare nell ambito dell Integrazione Anagrafe, è necessario garantire l'interscambio dei dati tra i soggetti aderenti ai progetti SAIA/GIADA/ANCITEL cioè Comuni, ASL e la RTRT e che le informazioni di competenza dei diversi Enti siano mantenute allineate e coerenti. Si assume che gli Enti siano connessi direttamente o indirettamente alla Rete Unitaria delle Pubbliche Amministrazioni (RUPA), ovvero ad una rete privata virtuale (VPN) basata sull'interoperabilità fra le diverse reti a cui gi Enti sono fisicamente connessi. Un Ente sarà fisicamente connesso, ad esempio, alla rete della propria regione o del proprio comune o provincia o ad altra rete, purché questa rete garantisca l'interoperabilità con tutte le altre reti cui sono connessi gli altri Enti. Il modello prodotto, descritto formalmente in questo documento, è stato costruito utilizzando il linguaggio di modellazione standard UML ed i relativi strumenti di sviluppo. L uso di questo linguaggio di modellazione consente la specifica delle interfacce tra i domini in modo indipendente dalla particolare realizzazione di ciascuno, e non implica, pertanto, l'adozione di alcuna tecnologia predefinita, né per quanto riguarda i servizi di cooperazione della VPN, né tanto più all interno dei domini. Il modello realizzato risulta applicabile anche nel caso in cui si renda necessaria la cooperazione con altre istanze amministrative (I.N.P.S., Prefetture, Camere di Commercio, ecc.). Il sistema nel suo complesso è schematizzato nel seguente diagramma: 8

9 L adozione di un modello di cooperazione applicativa basata su eventi (comunemente noto anche come modello basato su un servizio di Publish&Subscribe) implica l esistenza di un Broker (P&S Broker) che realizza le seguenti funzioni: - consente ai domini applicativi di pubblicare eventi relativi ad argomenti definiti; - consente ai domini applicativi di registrarsi come destinatari degli eventi relativi ad uno o più argomenti pubblicati; - quando un evento relativo ad un certo argomento viene pubblicato (cioè comunicato da uno dei domini applicativi al Broker), il Broker provvede a notificare l evento a tutti i domini applicativi che sono registrati come destinatari per l argomento. Il Broker (o più in generale il sottosistema di comunicazione) deve essere realizzato in modo tale da garantire la consegna certa degli eventi. Più precisamente, per ogni evento pubblicato deve essere garantito che tutti i domini sottoscrittori di eventi di quel tipo lo ricevano una ed una sola volta. Il Broker realizza quindi la funzione di smistamento degli eventi tra i domini applicativi connessi, fornendo garanzia della correttezza e della continuità del servizio. Questo modello di cooperazione consente quindi di integrare i diversi domini applicativi mantenendo un basso livello di accoppiamento in quanto ciascun dominio non ha necessità di alcuna conoscenza preventiva dell esistenza e delle necessità degli altri. Dovranno solamente essere predefiniti i tipi degli eventi (gli argomenti) su cui si basa la 9

10 cooperazione. Il numero (e potenzialmente anche il tipo) dei domini applicativi potrà quindi variare dinamicamente nel tempo senza ripercussioni sui domini connessi. Come illustrato nel diagramma, i domini applicativi che dovranno essere integrati nel sistema sono: I comuni della regione, o più precisamente i sistemi anagrafici dei comuni. Ciascun comune dovrà pubblicare eventi relativi alle persone fisiche residenti nel proprio territorio (nascite, morti, trasferimenti). Tali eventi saranno notificati alle A.S.L. che li useranno per gestire opportunamente l associazione tra l Assistito (la persona fisica vista nel contesto del sistema sanitario) ed il medico di base curante. Le A.S.L. della regione. Ciascuna A.S.L. riceverà notifica degli eventi anagrafici. Se l evento è relativo ad un comune di cui l A.S.L. è competente per territorio utilizzerà le informazioni associate all evento per attivare gli opportuni processi di gestione. Inoltre a seguito di propri processi interni (quale ad esempio la richiesta di un assistito di essere associato ad un medico di base) l A.S.L. pubblicherà eventi opportuni: esistenza di un nuovo assistito, cancellazione di un assistito dalla propria anagrafe, e informazioni relative alla scelta del medico. Ciascuna A.S.L. riceverà inoltre notifica di eventi pubblicati da altre A.S.L., in particolare quelli relativi all esistenza di un nuovo assistito, ed utilizzerà tali informazioni per cancellare l assistito dalla propria anagrafe se presente. L Amministrazione Regionale riceverà notifiche degli eventi pubblicati sia dai comuni che dalle A.S.L. e potrà utilizzare le informazioni associate per realizzare funzioni di controllo e statistiche. I domini applicativi non sono direttamente connessi con il servizio di P&S. Come specificato nei requisiti architetturali dell AIPA, la connessione avviene mediante opportune Porte di Sottoscrizione e di Pubblicazione. Queste porte di comunicazione interfacciano una Porta Applicativa del dominio che interfaccia il dominio con i servizi esterni. L architettura di ciascun dominio può quindi essere schematizzata come nel seguente diagramma: 10

11 In questo documento, quando non diversamente specificato, riferimenti al dominio applicativo in termini di requisiti e funzionalità si intendono applicati alle Porte e non alle applicazioni locali. Al più alto livello di astrazione possiamo quindi modellare il sistema come nel diagramma che segue, in cui i domini applicativi sopraccitati vengono visti come gli Attori che interagiscono con il sistema. 11

12 3 Identificazione degli Eventi Applicativi Per ciascuno dei domini applicativi (o Attori) identificati analizziamo in questo capitolo quali sono i tipi di Evento Applicativo (o Evento) pubblicati e ricevuti. In aderenza ai requisiti AIPA gli eventi applicativi sono suddivisi in due classi principali: 1. Eventi relativi alle Persone Fisiche; 2. Eventi relativi a dati di gestione sanitaria. Il progetto Rete Anagrafi si occupa principalmente di pubblicare gli eventi relativi alle persone fisiche, nel seguito del documento verrà quindi approfondito solamente questo tipo di Eventi. 12

13 3.1 Comune Tipi di Evento pubblicati I tipi di Evento ricevuti dai Comuni non vengono descritti in questo documento perché esulano dal contesto del progetto Integrazione Anagrafi che, in questa fase, si interessa della pubblicazione verso la Regione Toscana. L architettura da utilizzare permette in ogni caso ulteriori sviluppi in tal senso. Ciascun Comune pubblica i seguenti Eventi: 1. Nascita: a seguito di una nascita il nuovo nato viene registrato come residente nel comune, viene pubblicato l evento Nascita. 2. Morte: a seguito della morte di un cittadino residente nel comune, viene pubblicato l evento Morte. 3. VariazioneDatiAnagrafici:: a seguito di qualunque variazione dei dati anagrafici relativi al cittadino residente nel comune, viene pubblicato l evento VariazioneDatiAnagrafici. 4. CambioIndirizzo: a seguito del cambio di residenza del cittadino residente nel comune interno al territorio comunale, viene pubblicato l evento CambioIndirizzo. Si noti che questo evento potrebbe essere considerato come un caso particolare di variazione dei dati anagrafici, ma viene considerato come un evento a sé stante per la particolare rilevanza che ha in questo contesto. 5. Emigrazione: a seguito del cambio di residenza di un cittadino residente nel comune uscente dal territorio comunale, viene pubblicato l evento Emigrazione. 6. Immigrazione: a seguito dell ottenimento della residenza da parte di un cittadino proveniente da altro comune Italiano o Stato Estero, viene pubblicato l evento Immigrazione. 1. IscrizioneAIRE: a seguito della richiesta di un cittadino italiano residente all estero di inscrizione nell apposito albo (AIRE), viene pubblicato l evento IscrizioneAIRE. 13

14 3.2 Azienda Sanitaria Locale Tipi di evento pubblicati I tipi di Evento pubblicati dalle A.S.L. non vengono descritti in questo documento perché esulano dal contesto del progetto Integrazione Anagrafi. Tipi di evento ricevuti Ciascuna A.S.L. si registra come ricevente dei seguenti tipi di Evento: Eventi di classe PersoneFisiche (e quindi pubblicati dai Comuni e da Regione): 1. Nascita 2. Morte 3. Emigrazione 4. Immigrazione 5. Cambio Indirizzo 6. VariazioneDatiAnagrafici 7. IscrizioneAIRE Eventi di classe DatiSociosanitari (e quindi pubblicati da altre A.S.L.): 1. NuovoAssistito 2. SceltaMedico 3. RevocaMedico. Nota: NuovoAssistito, SceltaMedico e RevocaMedico non verranno ulteriormente analizzati in quanto la gestione del messaggio ricevuto non è di pertinenza del progetto IA. 14

15 3.3 Amministrazione Regionale Tipi di evento pubblicati I tipi di Evento pubblicati dalla Regione non vengono descritti in questo documento perché esulano dal contesto del progetto Integrazione Anagrafi. Tipi di evento ricevuti L Amministrazione Regionale si registra come ricevente dei seguenti tipi di evento: Eventi di classe PersoneFisiche (e quindi pubblicati dai Comuni): 1. Nascita 2. Morte 3. Emigrazione 4. Immigrazione 5. Cambio Indirizzo 6. VariazioneDatiAnagrafici 7. Congedo 8. IscrizioneAIRE 9. CancellazioneAIRE Nota: l evento Congedo sarà tralasciato in questa trattazione poiché non presente nel tracciato della base dati normalizzata, si prevede la sua introduzione nella futura versione. Eventi di classe DatiSociosanitari (e quindi pubblicati da A.S.L.): 1. NuovoAssistibile 2. NuovoAssistito 3. SceltaMedico 4. RevocaMedico 15

16 5. Cancellazione 6. SospensioneAssitenzaSanitaria 7. FineSospensioneAssitenzaSanitaria. 4 Cooperazione Applicativa tra Domini basata su eventi 4.1 Cooperazione fra Comuni, Regione Toscana e A.S.L. Sono riportati di seguito gli use-cases relativi alla descrizione degli eventi di scambio messaggi tra Comuni, RTRT e A.S.L.. Comunicazione Evento In questo use-case viene analizzata la consegna di un messaggio associato ad un generico evento; viene utilizzato dagli altri use-cases per eventi specifici. Comunicazione evento Precondizioni Il verificarsi di un evento, eventualmente generato dall applicativo. Avere già creato un oggetto di una classe derivata dalla classe Evento corrispondente all evento che si vuole comunicare. Flusso principale Il generatore dell evento prepara la lista di distribuzione includendo i destinatari a cui deve essere comunicato l evento. Normalmente il sottoscrittore principale per eventi relativi alle Persone Fisiche è la RTRT. Successivamente predispone l inoltro della comunicazione nella seguente modalità: recupera lo handle all oggetto GestoreEventi 16

17 trasmette al GestoreEventi i dati <Evento, listadestinatari>. A sua volta, il GestoreEventi procede come di seguito esposto: trasmette l Evento ricevuto ai destinatari presenti in listadestinatari comunica al mittente l avvenuta trasmissione. Eccezioni (E1) I malfunzionamenti legati alla non disponibilità in linea dei ServiziDiRete oppure all improvvisa interruzione della comunicazione per errori di sistema o di rete devono essere gestiti dagli applicativi che utilizzano i servizi definiti sulle porte di dominio. In generale, il verificarsi di queste situazioni provoca l interruzione dello use-case. Comunicazione Nascita (uc.1) Precondizioni 1. Il processo di registrazione del nuovo nato come residente nel comune deve essere stato completato ed i dati anagrafici del nuovo nato devono essere registrati nel sistema anagrafico del comune e nella relativa base dati normalizzata. Flusso principale 1. Il comune rileva la registrazione del nuovo nato come residente nel proprio territorio (effettuando interrogazioni periodiche del proprio sistema anagrafico). A seguito di questa rilevazione provvede a raccogliere i dati rilevanti e costruisce il messaggio che viene pubblicato come evento Nascita. 2. L ASL competente per territorio (quella in cui il comune pubblicante è inserito) riceve la notifica dell evento Nascita. Verifica se il nuovo nato è già presente nella propria anagrafe (i genitori, o persone da loro incaricate, potrebbero avere già effettuato la richiesta di assegnazione del medico per il nuovo nato). Se già presente, utilizza i dati anagrafici associati all evento per verificare la correttezza, ed eventualmente correggere, i dati anagrafici del nuovo nato. Se non presente, registra il nuovo nato come Assistibile nel proprio anagrafe e pubblica l evento NuovoAssistibile. 17

18 3. La Regione riceve la notifica dell evento Nascita. Provvede a registrare i dati di tale evento in un proprio sistema informativo per renderli disponibile a propri eventuali processi (ad esempio di controllo e rilevazione statistica) non rilevanti in questo contesto. 4. La Regione riceve la notifica dell evento NuovoAssistibile. Provvede a registrare i dati di tale evento in un proprio sistema informativo per renderli disponibile a propri eventuali processi (ad esempio di controllo e rilevazione statistica) non rilevanti in questo contesto. Eccezioni 1. Nessuna Comunicazione Morte (uc.2) Precondizioni 1. Il processo di registrazione del decesso di un cittadino residente nel comune o AIRE deve essere stato completato ed i dati anagrafici del decesso devono essere registrati nel sistema anagrafico del comune e nella relativa base dati normalizzata. Flusso principale 1. Il comune rileva la registrazione del decesso di un cittadino residente nel proprio territorio o AIRE (presumibilmente effettuando interrogazioni periodiche del proprio sistema anagrafico). A seguito di questa rilevazione provvede a raccogliere i dati rilevanti e costruisce il messaggio che viene pubblicato come evento Morte. 2. Tutte le A.S.L. ricevono la notifica dell evento Morte. Si noti, infatti, che a seguito di domiciliazione in una A.S.L. diversa da quella in cui il comune di residenza del cittadino è inserito, l evento può essere di interesse per qualunque A.S.L.. Ciascuna A.S.L. ricerca l assistito nel proprio anagrafe. Se presente, procede quindi a cancellare l assistito dal proprio anagrafe. Poi provvede a raccogliere i dati rilevanti e costruisce il messaggio che viene pubblicato come evento Cancellazione. 18

19 Si noti che a causa di inconsistenze pregresse, l assistito potrebbe essere cancellato da più A.S.L.. 3. La Regione riceve la notifica dell evento Morte. Provvede a registrare i dati di tale evento in un proprio sistema informativo per renderli disponibile a propri eventuali processi (ad esempio di controllo e rilevazione statistica) non rilevanti in questo contesto. 4. La Regione riceve la notifica dell evento Cancellazione. Provvede a registrare i dati di tale evento in un proprio sistema informativo per renderli disponibile a propri eventuali processi (ad esempio di controllo e rilevazione statistica) non rilevanti in questo contesto. Trasferimento o Variazione Dati Anagrafici (uc.3) Precondizioni 1. Il processo di registrazione del trasferimento o di variazione dei dati anagrafici del cittadino deve essere stato completato ed i dati anagrafici relativi devono essere registrati nel sistema anagrafico del comune. Flusso principale 1. Il comune rileva la registrazione di un trasferimento o della variazione dei dati anagrafici di un cittadino nel proprio territorio effettuando interrogazioni periodiche del proprio sistema anagrafico (base dati normalizzata). La rilevazione può essere di quattro tipi: a. cambio di indirizzo di un cittadino già residente che rimane all interno del territorio comunale; 19

20 b. cambio di residenza di un cittadino residente nel comune che si trasferisce in altro comune italiano o stato estero; c. acquisizione della residenza nel comune di un cittadino proveniente da altro comune italiano o stato estero; d. variazione di uno o più dati anagrafici (esclusa la residenza) del cittadino. A seguito di questa rilevazione il comune provvede a raccogliere i dati rilevanti e costruisce il messaggio che viene pubblicato come evento del seguente tipo: - nel primo caso CambioIndirizzo; - nel secondo caso Emigrazione; - nel terzo caso Immigrazione; - nel quarto caso VariazioneDatiAnagrafici. 2. L A.S.L. competente per territorio (quella in cui il comune pubblicante è inserito) o quella in cui l assistito è domiciliato riceve la notifica dell evento. Si noti che, come nel caso di morte, se l informazione relativa alla domiciliazione non è gestita da tutti i Comuni, per identificare la A.S.L. di domiciliazione è necessario che l evento sia ricevuto da tutte le A.S.L., ciascuna delle quali provvederà a verificare se il cittadino è registrato come assistito nel proprio anagrafe. In funzione del tipo dell evento procede come segue: CambioIndirizzo: aggiorna nel proprio anagrafe i dati di residenza dell assistito. VariazioneDatiAnagrafici: aggiorna nel proprio anagrafe i dati relativi all assistito, modificando i dati variati. Immigrazione: se il cittadino è già presente nel proprio anagrafe (può essere un immigrazione da un comune inserito nel territorio dell A.S.L., oppure il cittadino può già avere già fatto richiesta del medico) aggiorna nel proprio anagrafe i dati di residenza dell assistito; altrimenti registra il cittadino nel proprio anagrafe come cittadino assistibile e pubblica l evento NuovoAssistibile. Emigrazione: se il comune di nuova residenza è inserito nel territorio di competenza della A.S.L. aggiorna nel proprio anagrafe i dati di residenza dell assistito; se il comune di nuova residenza non è nel territorio di competenza della A.S.L. (vale anche nel caso di emigrazione all estero di 20

21 un cittadino straniero) verifica se l assistito è registrato nel proprio anagrafe (potrebbe già essere stato cancellato a seguito della ricezione dell evento NuovoAssistito da altra A.S.L.). Se è presente cancella l assistito dal proprio anagrafe e pubblica l evento Cancellazione, altrimenti ignora l evento La Regione riceve la notifica dell evento di trasferimento (CambioIndirizzo, VariazioneDatiAnagrafici, Emigrazione o Immigrazione) dal comune. Provvede a registrare i dati di tale evento in un proprio sistema informativo per renderli disponibile a propri eventuali processi (ad esempio di controllo e rilevazione statistica) non rilevanti in questo contesto. 5. La Regione riceve la notifica dell evento NuovoAsssitibile o SospensioneAssistenzaSanitaria dalla A.S.L.. Provvede a registrare i dati di tale evento in un proprio sistema informativo per renderli disponibile a propri eventuali processi (ad esempio di controllo e rilevazione statistica) non rilevanti in questo contesto. Eccezioni 1. Nel caso di CambioIndirizzo, VariazioneDatiAnagrafici, se l A.S.L. rileva che il cittadino oggetto dell evento non è nel proprio anagrafe, registra il cittadino nel proprio anagrafe come cittadino assistibile e pubblica l evento NuovoAssistibile. Comunicazione Iscrizione AIRE (uc. 4) Precondizioni 1. Un cittadino italiano residente all estero, pur mantenendo la propria effettiva residenza all estero, ha facoltà di scegliere un comune italiano come proprio comune di residenza. In seguito a questa richiesta il cittadino viene iscritto nel registro AIRE del comune. Flusso principale 1. Il comune rileva l evento di iscrizione di un cittadino nel registro AIRE. A seguito di questa rilevazione pubblica l evento IscrizioneAIRE. 21

22 2. L A.S.L. competente per territorio (quella in cui il comune pubblicante è inserito) riceve la notifica dell evento IscrizioneAIRE. Verifica se il cittadino è già presente nella propria anagrafe. Se già presente utilizza i dati anagrafici associati all evento per verificare la correttezza, ed eventualmente correggere, i dati anagrafici del cittadino. Se non presente, registra il cittadino come Assistibile nel proprio anagrafe e pubblica l evento NuovoAssistibile. Si deve notare che una A.S.L. può decidere di ignorare l evento IscrizioneAIRE in quanto nella maggior parte dei casi il cittadino residente all estero non farà richiesta di assistenza sanitaria. 3. La Regione riceve la notifica dell evento IscrizioneAIRE. Provvede a registrare i dati di tale evento in un proprio sistema informativo per renderli disponibile a propri eventuali processi (ad esempio di controllo e rilevazione statistica) non rilevanti in questo contesto. 4. La Regione riceve la notifica dell evento NuovoAssistibile. Provvede a registrare i dati di tale evento in un proprio sistema informativo per renderli disponibile a propri eventuali processi (ad esempio di controllo e rilevazione statistica) non rilevanti in questo contesto. Eccezioni 1. Nessuna. 5 22

23 5 Formalizzazione degli Eventi Per la formalizzazione del contenuto degli eventi si utilizzerà la rappresentazione XML. Tale formalismo risulta particolarmente indicato per la codifica dei messaggi. Un messaggio XML contiene, oltre ai dati, anche le informazioni utili alla loro interpretazione ed elaborazione. La tecnologia mette a disposizione strumenti per la costruzione, interpretazione e verifica del formato. Inoltre il formato XML, attraverso script e motori di traduzione (XSLT), può agevolmente essere convertito in altre forme. Quanto detto rende questa rappresentazione estremamente duttile ed efficace specie in contesti distribuiti anche eterogenei. Il messaggio potrà eventualmente essere sicurizzato attraverso logiche di autenticazione e/o cifratura. Un messaggio XML è diviso in una parte corpo, contenente informazioni inerenti la tipologia dell evento di contenuto strettamente applicativo, ed una parte intestazione associata alla sua natura di evento. 5.1 Classi di eventi Sono previste le seguenti classi di eventi: - Eventi relativi alle Persone Fisiche, conformi alle specifiche SAIA/ANCITEL; - Eventi relativi a dati di gestione sanitaria. Ogni Classe raggruppa tutti gli eventi che appartengono ad uno stesso processo logico di notifica. Gli eventi applicativi apparterranno ad una determinata classe e saranno identificati da un tipo, ad esempio appartengono alla Classe SaiaEvent gli eventi di tipo: Nascita, Morte, VariazioneDatiAnagrafici. Le classi di eventi che riguardano DatiSocioSanitari, come NuovoAssitibile e SceltaMedico, sono ulteriormente classificabili in termini di tipo, per la loro descrizione si rimanda al documento Analisi dei requisiti GIADA V. 1-1 [AnalisiRequisitiV1.1.pdf], quindi nel seguito non verranno più utilizzati. Questa classificazione dà la possibilità all applicazione di contestualizzare il trattamento degli eventi. E cioè possibile pensare ad uno sviluppo dell applicazione per componenti, dove ogni componente opera in un contesto specifico al quale sono associate una o più classi di eventi. Nella tabella che segue sono descritte le associazioni classe/tipo da adottare per la pubblicazione degli eventi relativi alle persone fisiche. 23

24 Tipi di Evento Tipo Classe Integrazione Anagrafi Nascita Evento Persone Fisiche SaiaEvent Morte Evento Persone Fisiche SaiaEvent Immigrazione ComunicazioneVariazione SaiaEvent DatiAnagrafici Emigrazione ComunicazioneVariazione SaiaEvent DatiAnagrafici Cambio Indirizzo ComunicazioneVariazione SaiaEvent DatiAnagrafici Iscrizione AIRE Comunicazione AIRE SaiaEvent Tabella 1 Tipi corrispondenti alla classe SaiaEvent 6 24

25 6 Allegati 6.1 I Package definiti Il package saia-ancitel-giada si occuperà della generazione e pubblicazione dei messaggi da inviare, si baserà sui dati forniti periodicamente dalla coda di eventi anagrafici gestita da IA. Il package Pubblicazione contiene le interfacce delle porte da utilizzare per la pubblicazione dei messaggi ai relativi sottoscrittori. Il package applicazione rappresenta la parte che interroga la base dati normalizzata al fine di reperire: - gli eventi conformi SAIA/ANCITEL/GIADA da pubblicare per un dato intervallo di tempo; - le informazioni anagrafiche dei cittadini per la generazione del corpo del messaggio. 25

26 Package saia-ancitel-giada 26

27 Package Pubblicazione 27

28 6.2 Esempio di descrizione dei messaggi associati agli eventi (XML) Rappresentazione grafica degli elementi del messaggio (con intestazione espansa) 28

29 Rappresentazione grafica degli elementi XML NuovoIndirizzoResidenza NuovoIndirizzoResidenza DescrizioneFrazione DescrizioneVia NumeroCivico Esponente Colore Interno Piano Scala NuovoIndirizzoResidenza Immigrazione DataEvento Provenienza LocalitaProvenienza ProtocolloAtto CambioIndirizzo CambioIndirizzo CambioIndirizzo DataVariazione Protocollo VecchiDatiAnagrafici <<attribute>> <<attribute>> VecchiDatiAnagrafici CodiceComune CodiceIdentificativo CodiceFiscale FlagCFvalido Nome Cognome DataNascita ComuneNascita LocalitaNascita CittadinanzaStraniera ComuneResidenza NazioneResidenzaEstera LocalitaResidenzaEstera IndirizzoResidenzaEstera CittadinanzaItaliana Sesso : ENUMERATION : ENUMERATION EmigratoA Emigrazione LocalitaEstera NuovoIndirizzoEstero DataEvento ProtocolloAtto Emigrazione DatiAnagrafici <<attribute>> <<attribute>> Nascita Emigrazione DatiAnagrafici CodiceComune CodiceIdentificativo CodiceFiscale FlagCFvalido Nome Cognome DataNascita ComuneNascita LocalitaNascita CittadinanzaStraniera ComuneResidenza NazioneResidenzaEstera LocalitaResidenzaEstera IndirizzoResidenzaEstera CittadinanzaItaliana Sesso Nascita DatiAnagrafici ProtocolloAtto ProtocolloAnno ProtocolloParte ProtocolloSerie Immigrazione DatiAnagrafici : ENUMERATION : ENUMERATION DatiAnagrafici DatiAnagrafici DatiAnagrafici IndirizzoResidenza DatiAnagrafici <<attribute>> <<attribute>> Morte IscrizioneAIRE DataEvento Protocollo IscrizioneAIRE Morte DataMorte ComuneMorte LocalitaMorte ProtocolloAtto ProtocolloAnno ProtocolloParte ProtocolloSerie NumeroFamiglia IscrittoAire ResidenteNascita IndirizzoResidenza IndirizzoResidenza DescrizioneFrazione DescrizioneVia NumeroCivico Esponente Colore Interno Piano Scala : ENUMERATION : ENUMERATION IndirizzoResidenza NuoviDatiAnagrafici VecchiDatiAnagrafici VariazioneDatiAnagrafici RetEmigratoA RetLocalitaEstera RetDataEmigrazione RetProvenienza RetLocalitaProvenienza RetDataImmigrazione RetDataMorte RetMortoA RetLocalitaMorte RetDataCongedo RetDataIscrizioneAIRE RetResidenzaAIRE RetLocalitaAIRE RetDataCancellazioneAIRE DataVariazione Protocollo NuoviDatiAnagrafici <<attribute>> <<attribute>> VariazioneDatiAnagrafici VariazioneDatiAnagrafici NuoviDatiAnagrafici CodiceComune CodiceIdentificativo CodiceFiscale FlagCFvalido Nome Cognome DataNascita ComuneNascita LocalitaNascita CittadinanzaStraniera ComuneResidenza NazioneResidenzaEstera LocalitaResidenzaEstera IndirizzoResidenzaEstera CittadinanzaItaliana Sesso : ENUMERATION : ENUMERATION 29

30 6.3 DTD degli eventi descritti <?xml version="1.0" encoding="utf-8"?> <!-- IndirizzoResidenza --> <!ELEMENT IndirizzoResidenza (DescrizioneFrazione, DescrizioneVia, NumeroCivico, Esponente, Colore, Interno, Piano, Scala)> <!ELEMENT DescrizioneFrazione (#PCDATA)> <!ELEMENT DescrizioneVia (#PCDATA)> <!ELEMENT NumeroCivico (#PCDATA)> <!ELEMENT Esponente (#PCDATA)> <!ELEMENT Colore (#PCDATA)> <!ELEMENT Interno (#PCDATA)> <!ELEMENT Piano (#PCDATA)> <!ELEMENT Scala (#PCDATA)> <!-- Nuovo IndirizzoResidenza aggiunto per completezza del DTD --> <!ELEMENT NuovoIndirizzoResidenza (DescrizioneFrazione, DescrizioneVia, NumeroCivico, Esponente, Colore, Interno, Piano, Scala)> <!-- Nuovo IndirizzoResidenza Fine --> <!-- DatiAnagrafici --> <!ELEMENT DatiAnagrafici (CodiceComune, CodiceIdentificativo, CodiceFiscale, FlagCFvalido, Nome, Cognome, DataNascita, ComuneNascita, LocalitaNascita, CittadinanzaStraniera, ComuneResidenza, IndirizzoResidenza, NazioneResidenzaEstera, LocalitaResidenzaEstera, IndirizzoResidenzaEstera)> <!ATTLIST DatiAnagrafici Sesso (M F) #REQUIRED CittadinanzaItaliana (S N) #IMPLIED > <!ELEMENT CodiceComune (#PCDATA)> <!ELEMENT CodiceIdentificativo (#PCDATA)> <!ELEMENT CodiceFiscale (#PCDATA)> <!ELEMENT FlagCFvalido (#PCDATA)> <!ELEMENT Nome (#PCDATA)> <!ELEMENT Cognome (#PCDATA)> <!ELEMENT DataNascita (#PCDATA)> <!ELEMENT ComuneNascita (#PCDATA)> <!ELEMENT LocalitaNascita (#PCDATA)> <!ELEMENT CittadinanzaStraniera (#PCDATA)> 30

31 <!ELEMENT ComuneResidenza (#PCDATA)> <!ELEMENT NazioneResidenzaEstera (#PCDATA)> <!ELEMENT LocalitaResidenzaEstera (#PCDATA)> <!ELEMENT IndirizzoResidenzaEstera (#PCDATA)> <!-- VecchiDatiAnagrafici aggiunto per completezza del DTD --> <!ELEMENT VecchiDatiAnagrafici (CodiceComune, CodiceIdentificativo, CodiceFiscale, FlagCFvalido, Nome, Cognome, DataNascita, ComuneNascita, LocalitaNascita, CittadinanzaStraniera, ComuneResidenza, IndirizzoResidenza, NazioneResidenzaEstera, LocalitaResidenzaEstera, IndirizzoResidenzaEstera)> <!ATTLIST VecchiDatiAnagrafici Sesso (M F) #REQUIRED CittadinanzaItaliana (S N) #IMPLIED > <!-- NuoviDatiAnagrafici aggiunto per completezza del DTD --> <!ELEMENT NuoviDatiAnagrafici (CodiceComune, CodiceIdentificativo, CodiceFiscale, FlagCFvalido, Nome, Cognome, DataNascita, ComuneNascita, LocalitaNascita, CittadinanzaStraniera, ComuneResidenza, IndirizzoResidenza, NazioneResidenzaEstera, LocalitaResidenzaEstera, IndirizzoResidenzaEstera)> <!ATTLIST NuoviDatiAnagrafici Sesso (M F) #REQUIRED CittadinanzaItaliana (S N) #IMPLIED > Nascita <!ELEMENT Nascita (DatiAnagrafici, ProtocolloAtto, ProtocolloAnno, ProtocolloParte, ProtocolloSerie)> <!ELEMENT ProtocolloAtto (#PCDATA)> <!ELEMENT ProtocolloAnno (#PCDATA)> <!ELEMENT ProtocolloParte (#PCDATA)> <!ELEMENT ProtocolloSerie (#PCDATA)> <!-- Nascita Fine! --> 31

32 Morte <!ELEMENT Morte (DatiAnagrafici, DataMorte, ComuneMorte, LocalitaMorte, ProtocolloAtto, ProtocolloAnno, ProtocolloParte, ProtocolloSerie, NumeroFamiglia)> <!ATTLIST Morte ResidenteNascita (S N) #IMPLIED IscrittoAire (S N) #IMPLIED > <!ELEMENT DataMorte (#PCDATA)> <!ELEMENT ComuneMorte (#PCDATA)> <!ELEMENT LocalitaMorte (#PCDATA)> <!ELEMENT NumeroFamiglia (#PCDATA)> VariazioneDatiAnagrafici <!ELEMENT VariazioneDatiAnagrafici (VecchiDatiAnagrafici, NuoviDatiAnagrafici, RetEmigratoA, RetLocalitaEstera, RetDataEmigrazione, RetProvenienza, RetLocalitaProvenienza, RetDataImmigrazione, RetDataMorte, RetMortoA, RetLocalitaMorte, RetDataCongedo, RetDataIscrizioneAIRE, RetResidenzaAIRE, RetLocalitaAIRE, RetDataCancellazioneAIRE, DataVariazione, Protocollo)> <!ELEMENT RetEmigratoA (#PCDATA)> <!ELEMENT RetLocalitaEstera (#PCDATA)> <!ELEMENT RetDataEmigrazione (#PCDATA)> <!ELEMENT RetProvenienza (#PCDATA)> <!ELEMENT RetLocalitaProvenienza (#PCDATA)> <!ELEMENT RetDataImmigrazione (#PCDATA)> <!ELEMENT RetDataMorte (#PCDATA)> <!ELEMENT RetMortoA (#PCDATA)> <!ELEMENT RetLocalitaMorte (#PCDATA)> <!ELEMENT RetDataCongedo (#PCDATA)> <!ELEMENT RetDataIscrizioneAIRE (#PCDATA)> <!ELEMENT RetResidenzaAIRE (#PCDATA)> <!ELEMENT RetLocalitaAIRE (#PCDATA)> <!ELEMENT RetDataCancellazioneAIRE (#PCDATA)> <!ELEMENT DataVariazione (#PCDATA)> <!ELEMENT Protocollo (#PCDATA)> 32

33 CambioIndirizzo <!ELEMENT CambioIndirizzo (DatiAnagrafici, NuovoIndirizzoResidenza, DataVariazione, Protocollo)> Emigrazione <!ELEMENT Emigrazione (DatiAnagrafici, EmigratoA, LocalitaEstera, NuovoIndirizzoResidenza, NuovoIndirizzoEstero, DataEvento, ProtocolloAtto)> <!ELEMENT EmigratoA (#PCDATA)> <!ELEMENT LocalitaEstera (#PCDATA)> <!ELEMENT NuovoIndirizzoEstero (#PCDATA)> <!ELEMENT DataEvento (#PCDATA)> Immigrazione <!ELEMENT Immigrazione (DatiAnagrafici, DataEvento, Provenienza, LocalitaProvenienza, ProtocolloAtto)> <!ELEMENT Provenienza (#PCDATA)> <!ELEMENT LocalitaProvenienza (#PCDATA)> IscrizioneAIRE <!ELEMENT IscrizioneAIRE (DatiAnagrafici, DataEvento, Protocollo)> 33