PROGETTO ESECUTIVO DI DETTAGLIO
Gara per l’acquisizione di beni e servizi relativi al Sistema Informativo Sanitario e Socio-Sanitario della Regione March
LOTTO 1 – Anagrafe Sanitaria Regionale, infrastruttura Data Center,infrastruttura Fascicolo Sanitario Elettronico, Tessera Sanitaria
PROGETTO ESECUTIVO DI DETTAGLIO
Componenti Applicative
Interfacce applicative
Presentato dal RTI:
Codice documento: | 12CE2179CEIN1 | Ver: | 11 |
Data: | 10 ottobre 2018 | Tutti i diritti riservati | |
Storia delle principali revisioni
Versione | Status | Data | Descrizione Modifica |
Ver. 1 | DEF | 21/07/2014 | Prima versione rilasciata |
Ver. 2 | DEF | 26/09/2014 | Seconda versione rilasciata. Adeguamento in base ai rilievi pervenuti con lett. prot. N. 0556326 del 30/07/2014, lett. prot. N. 0581922 del 08/08/2014, lett. prot. N. 0601299 del 27/08/2014. In particolare sono state apportate modifiche ai seguenti paragrafi: - Par. 2.3.6: aggiornamento e revisione testo (esempio messaggio MFN) - Par. 2.3.7: aggiornamento e revisione testo - Par. 2.3.8: aggiornamento e revisione tabella e testi (riferimenti documentazione HL7 v.2.5) - Par. 2.3.9: inserimento nuovo paragrafo “Futura implementazione di interfacce con tecnologia HL7 V3” - Par. 2.4.1: revisione sezione “note tecniche” - Par. 2.4.2: revisione sezione “note tecniche” - Allegati: aggiornamento allegati |
Ver. 3 | DEF | 23/10/2014 | Terza versione rilasciata. Adeguamento in base ai rilievi pervenuti con lett. prot. N. 0718815 del 08/10/2014. In particolare sono state apportate modifiche ai seguenti paragrafi: - Par. 2: inserimento elenco di riepilogo delle interfacce previste da capitolato e mappatura con i servizi previsti nel presente documento - Par. 2.2: integrazione del paragrafo con i servizi di profilazione del policy manager - Par. 2.4.1: aggiornamento del paragrafo con il servizio di marca temporale - Par. 2.4.4: Integrazione servizio di modifica dei metadati locali - Par. 2.4.6: Esplicitazione servizio di indicizzazione su Registry Regionale FSE - Par. 2.7: Inserimento paragrafo di definizione degli ulteriori servizi previsti. In particolare: Servizi di gestione degli eventi (par. 2.7.1) e Servizio di alimentazione del Polo di Conservazione Regionale (par. 2.7.2) - Par. 3: esplicitazione elenco servizi (wsdl ecc.); predisposizione Allegato sul servizio di Stampa Contrassegno; inserimento specifiche del servizio di autenticazione regionale FedCohesion. |
Ver. 4 | DEF | 20/11/2014 | Quarta versione rilasciata. Adeguamento in base ai rilievi pervenuti per le vie brevi e con lett. prot. N. 791906 del 05/11/2014. In particolare sono state apportate modifiche ai seguenti paragrafi: - Par. 2.4.3: Aggiunto nell’elenco dei dati scambiati il campo “Codice Fiscale” e prevista la gestione facoltativa o obbligatoria degli id Regionali/Locali in base alla tipologia del sistema inviante. - Par. 2.5.1: inserito riferimento alla estensione dei metadati - Par. 2.5.3: inserito riferimento alla estensione dei metadati |
Ver. 5 | DEF | 06/02/2015 | Quinta versione rilasciata. Adeguamento del formato in base al documento “IN2 – Interfacce applicative dematerializzata – modello V1” e aggiornamento dei contenuti. In particolare: - inserimento dei capitoli 2 e 3 “Contesto di riferimento” e “Generalità” - aggiornamento dei contenuti (descrizioni, diagrammi) dei servizi del cap. 4 “Servizi esposti dall’infrastruttura” - inserimento del cap. 5 “Specifiche tecniche” e aggiornamento delle specifiche associate ai singoli servizi - aggiornamento degli allegati al documento. |
Ver. 5.2 | DEF | 12/02/2015 | Quinta versione rilasciata. Correzione per errore materiale alla premessa del cap. 4. |
Ver. 5.3 | DEF | 22/05/2015 | Quinta versione rilasciata. Aggiornamento dei servizi di firma digitale remota e verifica remota firma digitale. In particolare: - par. 4.3.1 e par. 4.3.2: aggiornamento parametri alla sezione “dati scambiati” - par. 5.3.1 e par. 5.3.2: aggiornamento ai servizi wsdl allegati e integrazione degli esempi xml di chiamata e risposta. |
Ver. 5.4 | DEF | 18/02/2016 | Quinta versione rilasciata. Aggiornamento dei servizi anagrafici e di catalogo e dei servizi di firma e consenso, in particolare: - par. 4, aggiornamento della sezione “Servizi dell’Anagrafe Regionale Sanitaria” - creazione di due sottoparagrafi al par. 4.5.2 e inserimento di un nuovo par. 4.2.5.2 “notifica di utilizzo anagrafica”; - par. 4.2.8: aggiornamento descrizione dei dati anagrafici nei messaggi HL7 - par. 4.2.8: note sulla gestione del paziente anonimo - par. 4.2.9: inserimento dei riferimenti al documento allegato “IN1 – Allegato Cataloghi ASR-EMPI” - par. 4.3.1: aggiornamento con servizio firma multipla - par. 0.0.0.0: aggiornamento tabella parametri interfaccia/ws - par. 4.6.1.2.1: aggiornamento parametri di chiamata ws - par. 4.6.1.2.4: aggiornamento parametri di chiamata ws - par. 4.6.1.2.5: aggiornamento parametri di chiamata ws - par. 4.6.1.2.6: inserimento ws “copia consensi” - par. 5.3.1: aggiornamento con servizio firma multipla - par. 5.5: aggiornamento specifiche su parametri di chiamata generici, parametri ws “aggiorna consenso singolo”, “acquisisci visibilità”, “ricerca consensi”; inserimento es. ws “copia consensi” - par. 6: aggiornamento con allegato “IN1 – Allegato Cataloghi ASR- EMPI”, aggiornamento specifiche wsdl/xml di firma multipla e consenso |
Ver. 5.5 | DEF | 30/06/2016 | Quinta versione rilasciata. Aggiornamento degli allegati: - Allegato Integrazione ASR-EMPI – RIS (file doc) - Allegato Cataloghi ASR-EMPI (file doc) |
Ver. 6 | DEF | 13/10/2016 | Sesta versione rilasciata. Aggiornamento dei servizi previsti dai rilasci di II iterazione. In particolare: |
- par. 3.6 : inseriti riferimenti alle specifiche HL7 V3 - par. 4.1.2: inserimento specifica per il servizio di autenticazione applicativa STS - par. 4.1.4: inserimento specifica per il servizio di Provisioning (Attibute Autority) - par. 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.2.5, 4.2.8: inseriti riferimenti alla messaggistica realizzata con standard HL7 V3 - par. 4.2.10: modificato titolo e contenuto del paragrafo – tavola sinottica servizi – standard HL7 - par. 4.3.1: modificato descrizione del Tipo UserInfo -- modificato descrizione del Tipo Document – modificato descrzione del Tipo SignerInfo - par. 4.3.2: eliminata ripetizione descrizione dati scambiati - par. 4.3.3: eliminata ripetizione descrizione dati scambiati - par. 4.3.5: modificato descrizione Flusso - par. 4.3.7: modificato descrizione dati scambiati - par. 4.4.3: modificato descrizione Flusso e dati scambiati - par. 4.4.5: modificato descrizione Flusso, dati scambiati e standard - par. 0.0.0.0: aggiornamento specifiche parametri di chiamata ws - par. 4.6.1.2.7: inserimento nuovo ws – creazione CDA consenso - par. 4.6.1.2.8: inserimento nuovo ws – registra documento firmato - par. 4.7.2: inserimento specifica per il servizio di Gestione Audit Logger - par. 4.7.3: inserimento specifica per il servizio di stampa contrassegno - par. 5.1.2: inserimento specifica per il servizio di autenticazione applicativa STS - par. 5.1.4: inserimento specifica per il servizio di Provisioning dell’AA - par. 5.2.2, 5.2.3, 5.2.4, 5.2.5, 5.2.6: inserite specifiche servizi con standard HL7 V3 - par. 5.3.1: modificate Note Tecniche e parametri di input - par. 5.3.2: modificato Note Tecniche e parametri di input - par. 5.3.5: modificato Note Tecniche - par. 5.3.7: inserite Note Tecniche e parametri - par. 5.4.3: modificato Note Tecniche - par. 5.4.5 inserito Note Tecniche e parametri - par. 5.5: aggiornamento specifiche servizi consenso - par. 5.6.2: inserimento specifica per il servizio di Gestione Audit Logger - par. 6: aggiornamento allegati | |||
Ver. 7 | DEF | 18/10/2016 | Settima versione rilasciata. Modificato: - Modificato par. 4.3.3 Servizio di Ricezione Documento su Repository Documentale/FSE - Modificata fig. 23 sequence diagram – Archiviazione repository aziendale - Inserita fig. 24 sequence diagram – Archiviazione repository con - Modificato par. 4.3.8 Servizio di Stampa Contrassegno - Modificato par. 5.3.8 Servizio di Stampa Contrassegno - Aggiornato par. 6: allegati |
Ver. 8 | DEF | 9/11/2016 | Sono stati aggiunti i seguenti paragrafi: - 4.6.1.3 Gestione dell’oscuramento - 4.6.1.3.1 Oscuramento a posteriori |
- 4.6.1.3.2 Oscuramento a priori - 4.6.1.3.3 Oscuramento forzato | |||
05/12/2016 | Modificato : - par. 4 : aggiornato il riferimento all’allegato cataloghi - par. 4.2 : modifiche ai processi di gestione ASR-EMPI a seguito degli incontri del 6/10/16, 13/10/16, 4/11/16, ovvero : - vincoli di propagazione dei profili non certificati ASR - vincoli di gestione del censimento anagrafico - vincoli di gestione delle unificazioni anagrafiche - par. 4.2.10 : aggiunta tabella di comparazione degli scenari HL7 v3 con i servizi rilasciati dal progetto - par. 5.2 : aggiuti specifiche tecniche di dettaglio dei servizi HL7 v3 (escluse notifiche) | ||
Ver. 9 | DEF | 19/12/2016 | Sono stati aggiunti i seguenti paragrafi 4.1.5 Servizio di popolamento massivo dell’Attribute Autority. 4.8 Adeguamento Repository Aziendali preesistenti alle logiche del FSE. |
Ver. 10 | DEF | 21/04/2017 | Modificati paragrafi 4.3.3 Servizio di Ricezione Documento su Repository Documentale/FSE: cambiata descrizione regole di indicizzazione su FSE Regionale ed aggiornate le regole e la descrizione rispetto all’obbligatorietà degli identificativi anagrafici ed al loro recupero dall’Anagrafe Regionale. 4.3.6 Servizio di indicizzazione documenti su Registry Regionale FSE: cambiata descrizione regole di indicizzazione su FSE Regionale |
Ver. 10.1 | DEF | 31/05/2017 | Revisione dei paragrafi 4 e 5 relativi ai servizi ASR-EMPI : - par. 4.2.8 : aggiunto servizio di Anonimizzazione - par. 4.2.9 : aggiunto servizio di Deanonimizzazione - par. 4.2.10 e 4.2.12 : aggiunte indicazioni relative ai servizi di Anonimizzazione / Deanonimizzazione - rinumerazione dei paragrafi interni al capitolo 4.2 per effetto dei paragrafi aggiunti e sopra indicati - par. 5.2.6 : modificate indicazioni per HL7 v3 - par. 5.2.9 e 5.2.10 : aggiunte specifiche tecniche WS / XML per servizi di anonimizzazione e deanonimizzazione Aggiornamento dell’Allegato Cataloghi ASR-EMPI (file doc) |
Ver. 10.2 | DEF | 08/09/2017 | Revisone delle specifiche di integrazione con i webservices del Modulo Gestione Consenso per tracciare il consenso orale e strutturare i dati del dichiarante: - par 0.0.0.0: aggiunte informazioni sui dati accessori scambiati |
- par 4.6.1.2.1: modificate informazioni sui dati accessori scambiati - cap. 5.5: esempio di chiamata del web service “aggiorna consenso singolo” - aggiornato allegato esempiChiamata_mgcws.txt | |||
Ver 10.3 | DEF | 23.10.2017 | Modifica alle descrizioni dei servizi di Firma Digitale nei paragrafi 4.3.1 e 5.3.1. Aggiunti i paragrafi relativi alla firma digitale “reiterata”: 4.3.2 e 5.3.2 |
Ver 11 | DEF | 10.10.2018 | Modifica alla tabella dei parametri del capitolo 4.6.1.1. Modifica al capitolo 4.6.1.2.4 Ricerca consensi: aggiunta nuovi parametri per integrazione con INI Modifica al capitolo 4.6.1.2.7 Creazione CDA: aggiunta nuovi parametri per integrazione con INI Modifica al capitolo 5.5: aggiunta nuovi parametri per integrazione con INI |
Ver 12 | DEF | 25/03/2020 | Inserito il nuovo paragrafo 3.9 che definisce le logiche e le regole per la creazione del documento secondo il nuovo formato (PDF con iniettato il CDA2 tutto firmato PADES. Deprecato il paragrafo “4.1.2. Servizio di Autenticazione Applicativa STS (Securety Token Service)” a favore della nuova modalità di autenticazione descritta nel nuovo paragrafo 3.10 |
Var 13 | DEF | 24/05/2022 | Introdotto servizio invio |
INDICE
1.2 Documenti di riferimento 12
1.5 Struttura del documento 15
3.4 WSDL (Web Service Description Language) 18
3.6 Messaggistica HL7 utilizzata 18
3.7 Cross-Enterprise Document Sharing - XDS (IHE) 19
3.8 Protocollo di trasporto utilizzato 20
3.10 Asserzione firmata con certificato 20
4 SERVIZI ESPOSTI DALL’INFRASTRUTTURA 21
4.1 Servizio di Autenticazione, Profilazione e Autorizzazione (categoria “funzioni di controllo accessi e sicurezza”) 25
4.1.1 Servizio di Autenticazione 26
4.1.2 Servizio di Autenticazione Applicativa STS (Securety Token Service). 26
4.1.3 Servizio di Profilazione 26
4.1.4 Servizio di Provisioning Attribute Authority 28
4.1.5 Servizio di popolamento massivo Attribute Authority 28
4.1.6 Servizio di Autorizzazione 29
4.2 Servizi Anagrafici (categoria “funzioni di identificazione”) 30
4.2.1 Servizio di Ricerca anagrafica 35
4.2.2 Servizio di Censimento di nuova anagrafica 37
4.2.3 Servizio di Aggiornamento di una anagrafica 38
4.2.4 Servizio di Unificazione di anagrafiche 39
4.2.4.1 Unificazione anagrafica da ARCA 39
4.2.4.2 Unificazione anagrafica da altro LocalMPI 40
4.2.5 Servizio di Notifica eventi ai nodi cooperanti 42
4.2.5.1 Notifica di censimento, variazione, unificazione 42
4.2.5.2 Notifica di utilizzo anagrafica 44
4.2.6 Servizio di Aggiornamento cataloghi centralizzati 45
4.2.7 Servizio di Notifica variazione catalogo 46
4.2.8 Servizio di Anonimizzazione 47
4.2.9 Servizio di Deanonimizzazione 48
4.2.10 Descrizione dati anagrafici 48
4.2.11 Descrizione dati dei cataloghi 56
4.2.12 Tavola sinottica servizi – standard HL7 56
4.3 Servizi di Alimentazione Dati e Documenti (categorie “funzioni di alimentazione” e “funzioni
4.3.1 Servizio di Firma Digitale Remota 61
4.3.2 Servizio di Firma Digitale Remota “reiterata” 65
4.3.3 Servizio di Verifica Remota Firma Digitale 69
4.3.4 Servizio di Ricezione Documento su Repository Documentale/FSE 70
4.3.5 Servizio di modifica dei metadati “locali” 73
4.3.6 Servizio di Ricezione Dati di Laboratorio Urgenti (non “firmati”) 73
4.3.7 Servizio di indicizzazione documenti su Registry Regionale FSE 74
4.3.8 Servizio di Marca Temporale 75
4.3.9 Servizio di Stampa Contrassegno 76
4.3.10 Servizio di Invio Credenziali OTP via SMS o ArubaCall 76
4.4 Servizi di Consultazione dati e documenti (categoria “funzioni di ricerca e recupero
4.4.1 Servizio di Ricerca Documenti su FSE 77
4.4.2 Servizio di Retrieve Documento da FSE 78
4.4.3 Servizio di Ricerca su Repository Locale (firmato e non – dati) 79
4.4.4 Servizio di Retrieve Documento da Repository Locale (firmato e non - dati) 80
4.4.5 Servizio di Recupero Risultati Precedenti di Laboratorio 81
4.6 Servizi di gestione del Consenso (categoria “funzioni di gestione del consenso”) 82
4.6.1.1 Servizio Chiamata Applicativa di Contesto 83
4.6.1.2.1 Aggiorna consenso singolo 88
4.6.1.2.3 Annulla oscuramento 91
4.6.1.2.5 Acquisisci visibilità 93
4.6.1.2.8 Registra Documento Firmato 95
4.6.1.3 Gestione dell’oscuramento 95
4.6.1.3.1 Oscuramento a posteriori 96
4.6.1.3.2 Oscuramento a priori 96
4.6.1.3.3 Oscuramento forzato 97
4.7 Ulteriori servizi previsti 97
4.7.1 Servizi di gestione degli eventi 97
4.7.2 Servizi di Audit Logger – Audit Retrive– Servizio di recupero Accessi 100
4.7.3 Servizio di stampa contrassegno 101
4.8 Repository Aziendali – Integrazione con FSE 101
4.8.1 Adeguamento Repository Aziendali preesistenti al FSE 101
5 SPECIFICHE TECNICHE 103
5.1 Servizio di Autenticazione e Profilazione 103
5.1.1 Servizio di Autenticazione 103
5.1.2 Servizio di Autenticazione Applicativa STS (Securety Token Service). 103
5.1.2.1 Request 103
5.1.2.2 Response 104
5.1.2.3 Messaggi di errore 105
5.1.2.4 Esempi SOAP v1.1 106
5.1.3 Servizio di Profilazione 111
5.1.3.1 Implementazione 111
5.1.3.2 Messaggi d’errore 112
5.1.3.3 Esempi di Request e Response del Servizio 113
5.1.4 APIs gestione Operatori / Ruoli 119
5.1.4.1 Gestione operatori 119
5.1.4.1.1 Inserimento nuovo operatore 119
5.1.4.1.2 Ricerca 120
5.1.4.1.3 Cancellazione 121
5.1.4.2 Gestione ruoli 122
5.1.4.2.1 Inserimento nuovo ruolo 122
5.1.4.2.2 Richiesta elenco ruoli 123
5.1.4.2.3 Cancellazione 123
5.1.4.3 Gestione associazione ruoli/operatori 123
5.1.4.3.1 Associazione di un ruolo ad un operatore 123
5.1.4.3.2 Eliminare un’associazione ruolo/operatore esistente 123
5.1.5 Servizio di Autorizzazione 123
5.1.5.1 Funzionalità della Policy 124
5.1.5.1.1 Excpected Action 125
5.1.5.2 Fase della Policy 126
5.1.5.2.1 Excpected Action 127
5.1.5.3 Advise 128
5.1.5.3.1 Excpected Action 128
5.1.5.4 Obbligations 130
5.1.5.4.1 Excpected Action 130
5.1.5.5 Policy Attuali 131
5.1.5.5.1 Auth matrix 131
5.1.5.5.2 Profile 132
5.1.5.6 Servizi e Policy 133
5.1.5.7 Appendici 134
5.1.5.7.1 Standard XACML attributes 134
5.1.5.7.2 Standard RTI 137
5.2 Servizi Anagrafici e cataloghi 138
5.2.1 Note tecniche generali 138
5.2.2 Servizio di Ricerca anagrafica 139
5.2.2.1 Standard HL7 V2.5 139
5.2.2.2 Standard HL7 V3 149
5.2.3 Servizio di Censimento anagrafica 154
5.2.3.1 Standard HL7 V2.5 154
5.2.3.2 Standard HL7 V3 158
5.2.4 Servizio di Aggiornamento di una anagrafica 160
5.2.4.1 Standard HL7 V2.5 160
5.2.4.2 Standard HL7 V3 164
5.2.5 Servizio di Unificazione anagrafica 166
5.2.5.1 Standard HL7 V2.5 166
5.2.5.2 Standard HL7 V3 170
5.2.6 Servizio di Notifica variazioni anagrafica 172
5.2.6.1 Standard HL7 V2.5 172
5.2.6.2 Standard HL7 V3 173
5.2.7 Servizio di Aggiornamento catalogo 173
5.2.8 Servizio di Notifica variazione catalogo 175
5.2.9 Servizi di Anonimizzazione 177
5.2.10 Servizi di Deanonimizzazione 179
5.3 Servizi di Alimentazione Dati e Documenti (categorie “funzioni di alimentazione” e “funzioni
indicizzazione documenti”) 180
5.3.1 Servizio di Firma Digitale Remota 180
5.3.2 Servizio di Firma Digitale Remota “reiterata” 181
5.3.3 Servizio di Verifica Remota Firma Digitale 182
5.3.4 Servizio di Ricezione Documento su Repository Documentale/FSE 183
5.3.5 Servizio di modifica dei metadati “locali” 183
5.3.6 Servizio di Ricezione Dati di Laboratorio Urgenti (non “firmati”) 184
5.3.7 Servizio di indicizzazione documenti su Registry Regionale FSE 184
5.3.8 Servizio di Marca Temporale 184
5.3.9 Servizio di Stampa Contrassegno 185
5.3.10 Servizio di Invio Credenziali di firma OTP via SMS o ARUBACALL 186
5.4 Servizi di Consultazione dati e documenti (categoria “funzioni di ricerca e recupero
documenti”) 186
5.4.1 Servizio di Ricerca Documenti su FSE 186
5.4.2 Servizio di Retrieve Documento da FSE 189
5.4.3 Servizio di Ricerca su Repository Locale (firmato e non – dati) 189
5.4.4 Servizio di Retrieve Documento da Repository Locale (firmato e non - dati) 189
5.4.5 Servizio di Recupero Risultati Precedenti di Laboratorio 189
5.5 Servizio di gestione del Consenso 190
5.6 Ulteriori servizi previsti 196
5.6.1 Servizi di gestione degli eventi 196
5.6.1.1 Transazioni previste. 196
5.6.1.1.1 – ITI-52 Document Metadata Subscribe 196
5.6.1.1.2 – ITI-53 Document Metadata Notify (Push-style) 197
5.6.1.1.3 – ITI 69 Create/Destroy Pull Point 198
5.6.1.1.4 –ITI-70 Notification Pull: (Pull-style) 198
5.6.1.2 Messaggi di esempio 199
5.6.1.2.1 Messaggio di sottoscrizione (SubScribe Request Message) 199
5.6.1.2.2 Messaggio di creazione PullPoint 201
5.6.2 Servizio di Audit Logger – Audit Retrive – Servizio di recupero Accessi 201
5.6.2.1 Filtri di ricerca supportati 204
5.6.2.1.1 Date 204
5.6.2.1.2 Address 204
5.6.2.1.3 Identity 205
5.6.2.1.4 Object Type 205
5.6.2.1.5 Outcome 205
5.6.2.1.6 Participant 205
5.6.2.1.7 PatientId 205
5.6.2.1.8 Role 205
5.6.2.1.9 Source 205
5.6.2.1.10 Subtype 206
5.6.2.1.11 Type 206
5.6.2.2 Lingua del testo human-readable: il parametro language 206
5.6.2.3 Risorsa AuditEvent 207
5.6.3 Servizio di Stampa Contrassegno 209
6 ALLEGATI 210
1 INTRODUZIONE
Il presente documento presenta il dettaglio delle interfacce che verranno esposte a livello di servizi da parte della architettura del Fascicolo Sanitario FSE.
Le interfacce saranno esposte a livello regionale sia nell’ambito del Lotto 1 – Infrastruttura FSE, sia da parte di Regione Marche per quanto concerne i servizi di autenticazione FedCohesion.
Questo documento costituisce un allegato al Progetto Esecutivo – EXA del Lotto 1.
Per dare coerenza e continuità con quanto riportato nel documento di approfondimento dell’analisi dei processi, la descrizione delle singole interfacce verrà fatta riportando i riportati i casi d’uso, le tipologie di flussi informativi scambiati, i riferimenti alle relative specifiche tecniche e gli eventuali scenari di esempio.
Il presente documento è articolato in due sezioni: la prima riporta le specifiche di carattere generale e utili alla comprensione del contesto di riferimento, la seconda contenente le specifiche tecniche da implementare.
La tabella successiva riporta gli acronimi più diffusi nel documento, con l’intento di semplificarne la lettura.
AgID | Agenzia per l'Italia Digitale | MEF | Ministero dell'Economia e delle Finanze |
AO | Azienda Ospedaliera | MEV | Manutenzione Evolutiva |
ASL | Azienda Sanitaria Locale | MMG | Medici di Medicina Generale |
BMG | Banda Minima Garantita | MPLS | Multi Protocol Label Switching |
BPM | Business Process Management | NAV | Notification of AVailabledocuments |
CA | CertificationAuthority | NOC | Network Operation Center |
CDP | Capitolato Descrittivo Prestazionale | NOP | New Object Point |
CMS | Content Management System | OTP | One Time Password |
CNIPA | Centro Nazionale per l'Informatica nella PA | OTRS | Opensource Ticket Request System |
CNS | Carta Nazionale dei Servizi | PEC | Posta Elettronica Certificata |
CR | Control Room | PLS | Pediatri di Libera Scelta |
CUP | Centro Unico di Prenotazione | PSR | Piano di Sviluppo Regionale |
DBMS | Data Base Management System | QoS | Quality of Service |
DCM | Data Center Master | R&D | Research& Development |
DCRM | Data Center Regione Marche | RM | Regione Marche |
DP | Data Processing | RSS | Really Simple Syndication |
ESB | Enterprise Service Bus | RTI | Raggruppamento Temporaneo di Imprese |
FC | Fiber Channel | RUP | RationalUnifiedProcess |
FCoE | Fiber Channel over Ethernet | SAML | Security Assertion Markup Language |
FSE | Fascicolo Sanitario Elettronico | SAN | Storage Area Network |
GBE | Giga Bit Etrhernet | SDH | Synchronous Digital Hierarchy |
GSB | Government Service Bus | SEO | Search EngineOptimization |
HA | High Availability | SIP | Session InitiationProtocol |
HD | Help Desk | SLA | Service Level Agreement |
HL7 | Health Level 7 | SOAP | Simple Object Access Protocol |
HSM | Hardware Security Module | SSO | Single Sign On |
HW | Hardware | SW | Software |
ICT | Information and Communication Technology | TLC | Telecomunicazioni |
IHE | Integrating the Healthcare Enterprise | TS | Tessera Sanitaria |
IM | Insiel Mercato | UPS | UninterruptiblePower Supply |
IT | Information Technology | URP | Ufficio Relazioni con il Pubblico |
ITIL | Information Technology Infrastructure Library | VPN | Virtual Private Network |
KME | Knowledge Management Environment | XDS | Cross-Enterprise DocumentSharing |
KVM | Keyboard Video Mouse | XML | eXtensible Markup Language |
LRA | Local RegistrationAuthority | XP | eXtreme Programming |
MGC | Modulo del Consenso |
APPROFONDIMENTI
BPM: Business Process Management
(Wikipedia) insieme di attività necessarie per definire, ottimizzare, monitorare e integrare i processi aziendali, al fine di creare un processo orientato a rendere efficiente ed efficace il business dell’azienda.
ESB: Enterprise Service Bus
(Wikipedia) infrastruttura software che fornisce servizi di supporto (servizi di orchestration, sicurezza, messaggistica, routing intelligente e trasformazioni) ad architetture SOA complesse
HL7: Health Level 7
(HL7-Italia) associazione non profit internazionale che si occupa di gestire standard per la sanità. HL7 è riferito anche ad alcuni degli specifici standard creati da questa associazione (es. XX0 x0.x, v3.0, CDA, ecc.). Fondata nel 1987 e riconosciuta dall'American National Standards Institute nel 1994, riunisce organizzazioni affiliate da oltre 40 paesi
IHE: Integrating the Healthcare Enterprise
(IHE – Italia) gruppo di lavoro internazionale che lavora in sinergia con le associazioni legate alla sanità (ACR, NEMA, EAR, ECR, SIRM, ecc.) e promuove l'uso di standard già definiti in ambito medicale. IHE non si occupa di come sono fatti i componenti, ma di come possono collegarsi ed interoperare fra loro. A tale fine cerca di armonizzare l'uso degli standard esistenti (DICOM, XX0, XXX, ecc.), e propone ogni anno un connect-a-thon fra le aziende per verificare l'interoperabilità
SOA: Service Oriented Architecture
(Wikipedia) architettura software adatta a supportare l'uso di servizi Web per garantire l'interoperabilità tra diversi sistemi così da consentire l'utilizzo delle singole applicazioni come componenti del processo di business e soddisfare le richieste degli utenti in modo integrato e trasparente.
SAR: Servizio Accoglienza Regionale
Il SAR è il sistema che consente di raccogliere tutte le prescrizioni dematerializzate inviate dai medici prescrittori delle Aziende (specialisti ambulatoriali e ospedalieri, etc.) e di renderle disponibili ai sistemi che, se abilitati, possono accedere alla ricetta stessa (CUP, accettazioni, farmacie, etc.).
Il SAR, inoltre, è in stretta relazione con il sistema Ministeriale (SAC), cui trasmette le prescrizioni secondo i regolamenti previsti.
NAV: Notification of Available documents
(IHE-Wiki) NAV definisce un meccanismo per la notifica point-to-point tra sistemi o utenti dell’ambito di un Affinity Domain XDS. Tali notifiche possono essere utilizzate per attivare azioni diverse da parte delle applicazioni che aderiscono ai profili XDS e NAV. Il profilo NAV prevede l’uso di SMTP e degli standard correlati per l’invio delle notifiche e XML Digital Signature Core per creare l’intestazione dei documenti oggetto della notifica stessa.
OTP: One Time Password
(Wikipedia) Una One-Time Password è una password che è valida solo per una singola sessione di accesso o una transazione. Essa evita una serie di carenze associate all'uso della tradizionale password tra cui la minore vulnerabilità agli “attacchi con replica”: se un potenziale intruso riesce ad intercettare una OTP che è stata già utilizzata per accedere a un servizio o eseguire una transazione, non sarà in grado di riutilizzarla in quanto non più valida. D'altra parte, una OTP non può essere memorizzata da una persona e richiede una tecnologia supplementare per poter essere utilizzata.
SAML: Security Assertion Markup Language
(CNIPA, OASIS) Lo standard OASIS Security Assertion Markup Language ha l’obiettivo di fornire una sintassi basata su XML e le relative regole di interpretazione per lo scambio di informazioni di sicurezza tra entità interagenti online. Tali informazioni sono costituite da asserzioni scambiate tra asserting party (le entità che le emettono) e relying party (le entità che le richiedono e che possono farne uso per gli scopi di autenticazione e autorizzazione).
Come suggerisce il nome, XXXX consente ad entità business di fare asserzioni concernenti identità, attributi e diritti di un soggetto (spesso un essere umano) nei confronti di altre entità, ad es. altre applicazioni o altre società.
SOAP: Simple Object Access Protocol
(W3Schools) SOAP è un protocollo leggero per lo scambio di messaggi tra componenti software. Questo protocollo è stato pensato per le applicazioni che necessitano di comunicare su HTTP e che, per loro natura, girano su sistemi operativi diversi, con tecnologie diverse e basati su linguaggi di programmazione differenti.
SSO: Single Sign On
(Wikipedia, Microsoft) Per Single sign-on si intende la proprietà di un sistema di controllo d'accesso che consente ad un utente di effettuare un'unica autenticazione valida per più sistemi software o risorse informatiche alle quali è abilitato.
Si parla di sistema basato su SSO quando le richieste di autenticazione non vengono direttamente gestite dal sistema stesso ma vengono ridirette verso un altro sistema di autenticazione che ha precedentemente certificato le credenziali dell’utente connesso, senza quindi avere la necessità di richiedere nuovamente le credenziali per l’accesso.
XDS: Cross-Enterprise Document Sharing
(IHE Wiki) XDS è il profilo di IHE che definisce le specifiche per la gestione (registrazione, distribuzione e accesso) e lo scambio di documenti clinici tra strutture sanitarie diverse.
UML: Unified Modeling Language
(OMG) UML è un linguaggio di modellazione general-purpose nel campo del software engineering, progettato per fornire una rappresentazione visuale di un sistema software.
UML consente di specificare, visualizzare e documentare modelli di sistemi software, incluso il disegno architetturale, in modo tale da rispettare e verificarne i requisiti.
SAC: Servizio Accoglienza Centrale
Il SAC è il Sistema di Accoglienza Centrale curato dal Ministero dell'Economia e delle Finanze (MEF) per il tramite di SOGEI che consente la trasmissione telematica dei dati previsti dall'art. 50.
Il SAC garantisce la circolarità nazionale delle ricette dematerializzate, affinché per es. una ricetta specialistica o una ricetta farmaceutica non siano erogate due volte in due regioni distinte.
Il presente documento è articolato principalmente in due sezioni, di cui la prima, principalmente costituita dai par. 2, 3 e 4, è rivolta ad un’utenza generica costituita da esperti di dominio e di business, che non hanno necessariamente competenze specifiche informatiche.
Il successivo par. 5 contiene invece le specifiche tecniche relative ai servizi che saranno esposti per il processo di dematerializzata, ed è una sezione principalmente rivolta a tecnici sviluppatori e programmatori con conoscenze delle specifiche tecniche utilizzate.
2 CONTESTO DI RIFERIMENTO
Il Fascicolo Sanitario elettronico (FSE) è definito come “l’insieme dei dati e documenti digitali di tipo sanitario e sociosanitario generati da eventi clinici presenti e trascorsi, riguardanti l'assistito” (rif. D.L. n. 179/2012, art. 12, co.1, conv. con L. n. 221/2012).
Il FSE pertanto ➜ consiste nell’insieme dei dati e documenti digitali di tipo sanitario e socio-sanitario riferiti al paziente, generati da eventi clinici presenti e trascorsi, ➜ viene realizzato dalle Regioni previo consenso dell’assistito, che ne autorizza l’accesso ai vari professionisti, ➜ copre l'intera vita del malato ed è costantemente aggiornato dai soggetti che lo prendono in cura.
Oltre al fine primario di supportare i processi prevenzione, diagnosi, cura e riabilitazione dell’assistito, il FSE viene istituito con l’obiettivo di supportare, in prospettiva, le attività di studio e ricerca scientifica in campo
medico, biomedico ed epidemiologico e quelle di programmazione sanitaria, verifica delle qualità delle cure e valutazione dell’assistenza sanitaria (rif. D.L. n. 179/2012, art. 12, co.2, conv. con L. n. 221/2012).
Dal secondo semestre 2008, a partire dai lavori del Tavolo della Sanità Elettronica – TSE, è stato elaborato un quadro normativo unitario per l’implementazione del FSE, necessario alla definizione di un modello di riferimento nazionale e che valorizzasse allo stesso tempo i risultati raggiunti a tutti i livelli del SSN. Tra le principali normative e documentazione di riferimento si richiamano:
- Linee guida in tema di Fascicolo sanitario elettronico (Fse) e di dossier sanitario emesse dal Garante Privacy, 16 luglio 2009
- Linee guida nazionali in tema di Fascicolo sanitario elettronico emesse dal Ministero della Salute, 11 novembre 2010
- D.L. 18 ottobre 2012, n.179, “Ulteriori misure urgenti per la crescita del Paese”, convertito con l. 17 dicembre 2012, n. 221
- D.L. 21 giugno 2013, n. 69, “Disposizioni urgenti per il rilancio dell’economia” convertito con l. 9 agosto 2013, n. 98
- Linee guida per la presentazione dei piani di progetto regionali per il FSE, emesse da Ministero della Salute e Agenzia per l’Italia Digitale, 31 marzo 2014.
La Regione Marche, con il “Piano regionale per gli interventi informatici nella sanità 2012-2014”, si è posta l’obiettivo di far convergere due percorsi di investimento avviati negli ultimi anni, il primo volto alla riduzione del digital divide del territorio - al fine di favorire l’accessibilità ai servizi sanitari e assistenziali, il secondo orientato alla realizzazione di progetti trasversali strategici per la creazione di infrastrutture a supporto dei sistemi sanitari specialistici e di Fascicolo.
Nell’ambito di tale piano, la Regione ha indetto la procedura di gara “Acquisizione di beni e servizi relativamente al sistema informativo sanitario e socio-sanitario della Regione Marche – Lotti 1, 2, 3 e 4”, ponendo le basi per:
- la realizzazione e il funzionamento dell’infrastruttura e dei sistemi applicativi necessari all’istituzione del Fascicolo Sanitario Elettronico per i cittadini della Regione Marche;
- la realizzazione dei sistemi applicativi per la gestione delle strutture territoriali, ivi incluse le cartelle cliniche dei Medici di Medicina Generale/ Pediatri di Libera Scelta con le funzionalità per l’utilizzo del FSE;
- il popolamento del FSE, nel corso del triennio, con: referti di laboratorio, referti di diagnostica per immagine, patient summary e referti redatti a seguito di visite specialistiche.
L’insieme dei beni e servizi acquisiti con procedura di gara, secondo la suddivisione in 4 lotti, è riportato nella figura seguente.
Figura 1: Acquisizione di beni e servizi relativamente al sistema informativo sanitario e socio-sanitario della Regione Marche – Articolazione in Lotti
Il presente documento illustra le modalità di applicazione e le specifiche delle interfacce che verranno esposte a livello di servizi da parte della architettura del Fascicolo Sanitario FSE per l’utilizzo da parte di tutti i fruitori FSE.
3 GENERALITA’
Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali organismi internazionali quali il World Wide Web Consortium (W3C) per la famiglia di protocolli XML, per SOAP, per WSDL, per le architetture Web, e per le architetture e le tecnologie Web Services, OASIS per il protocollo ebXML, le specifiche UDDI, e l’architettura Web Services.
Il web service esposto è stato realizzato seguendo le specifiche Basic Profile 1.0 dettate dall’organizzazione mondiale WS-I (Web Service Interoperability Organization) al fine di aumentare il grado di interoperabilità tra servizi Web. Ciò garantisce il corretto funzionamento tra le diverse implementazioni su differenti piattaforme. A tal fine, i servizi web sono stati validati rispetto alle specifiche WSI Simple SOAP Binding Profile 1.0 (WS-I SSBP) generato sul WS-I Basic Profile, e WS-I Attachments Profile 1.0 (WS-I AP).
L’adozione di un linguaggio comune prevede l’utilizzo dei seguenti standard per la rappresentazione dei:
▪ Dati: Extensible Markup Language (XML) e Simple Object Access Protocol (SOAP) v 1.1 with attachments;
▪ Servizi applicativi: Lightweight Directory Access Protocol (LDAP), Universal Description, Discovery and Integration (UDDI), e Web Service Definition Language (WSDL).
Lo strumento tecnologico per memorizzare i documenti che definiscono sintassi e semantica dei dati è individuabile in un Repository XML, mentre per quelli che definiscono la sintassi e la semantica dei servizi si individua un Registro dei Servizi (di tipo LDAP o UDDI).
Il sistema di gestione del canale di interscambio e cooperazione mette quindi a disposizione i servizi per l’accesso controllato alla consultazione, alla modifica, all’inserimento ed alla cancellazione degli archivi disponibili
Gli standard utilizzati per l’utilizzo del modello web services sono:
▪ uso del linguaggio XML per la rappresentazione dei dati;
▪ uso del protocollo SOAP per il formato dei messaggi scambiati tra i domini;
▪ uso del linguaggio WSDL per la definizione delle chiamate ai Web Services.
Ogni nuovo servizio è implementato utilizzando linguaggi e tecnologie differenti, per le quali è poi generata un’interfaccia WSDL e altre componenti che producono il livello di disaccoppiamento necessario per renderlo accessibile attraverso la rete mediante protocollo HTTP (o HTTPS) e linguaggio XML.
In particolare, tra le informazioni specifiche di ciascun servizio sono incluse le descrizioni delle interfacce applicative dei servizi stessi (tramite metalinguaggio WSDL). Il richiedente del servizio trova nelle descrizioni pubblicate tutto quanto necessario per formulare richieste di servizio al fornitore del servizio specifico.
La descrizione WSDL del servizio permette, inoltre, (attraverso uno specifico elemento di descrizione) di specificare i possibili profili di collaborazione disponibili per l’accesso a quel dato servizio (notifica o richiesta servizi sincrona e asincrona) tramite i profili base disponibili nel metalinguaggio WSDL.
3.4 WSDL (Web Service Description Language)
WSDL è un linguaggio per la descrizione di Web Service, promosso dal W3C e basato su XML Schema.
Le componenti e la filosofia con la quale WSDL è stato realizzato possono essere riassunti con lo schema illustrato di seguito, dove è possibile identificare le cinque entità fondamentali che compongono questo linguaggio:
types: un tipo di dato generico utilizzato nel resto della descrizione; message: un messaggio trasmesso;
portType: un servizio espresso in termini di operazioni (operation) messe a disposizione;
port: ridefinizione delle operation di una portType istanziate all’interno di particolare tecnologia di comunicazione;
service: i Web Service realmente fruibili come insieme di port.
In questo modo WSDL mette a disposizione due tipi di descrizione del servizio, posizionati su due livelli di astrazione diversi:
▪ astratta (abstract view) che descrive un servizio sulla base delle operazioni che questo mette a disposizione;
▪ concreta (concrete view), che specializza, tramite un'operazione detta di binding, le operation, su cui si basa anche la visione concreta.
Questa distinzione permette, a livello di linguaggio, di collocare le operation stesse in un preciso contesto applicativo ottenuto dalla definizione del protocollo utilizzato per la comunicazione. Anche attualmente WSDL mette a disposizione gli schemi di definizione di binding per il trasporto delle informazioni su canale SOAP e https.
Lo Schema XSD (XML Schema Definition) rappresenta un modo per definire una sintassi per la validazione di un documento XML. La sintassi è definita in linguaggio XML.
Al fine di una corretta gestione dei documenti, il file XML deve essere scritto utilizzando l'insieme di caratteri UNICODE ISO 10646 e codificato con la codifica UTF-8 o, in alternativa, per sistemi operativi che non supportano questo standard, con la codifica ISO 8859-1 Latin 1.
Gli sviluppatori di software devono effettuare l’operazione di validazione dei file XML contenenti i dati della ricetta secondo quanto descritto nello schema XSD, prima di inviare il file in via telematica.
Tuti i tag descritti nello schema XSD devono essere presenti nei file XML ed i singoli campi devono rispettate le regole formali e/o i valori possibili per ognuno di loro.
3.6 Messaggistica HL7 utilizzata
Lo standard di riferimento dei Servizi di gestione Anagrafica e Cataloghi della piattaforma ASR-EMPI è HL7.
Riferimenti alla documentazione Standard HL7 v 2
I servizi previsti dal progetto sono rilasciati con standard HL7 V 2.5 XML (trasformazione in XML secondo le "EncodingRule" dello Standard (Riferimento XML_Encoding_Rules_for_HL7_v2_Messages) e, dove esistente, con localizzazione italiana fornita da HL7 Italia.
Per qualunque indicazione tecnica si faccia riferimento allo standard; si riporta in seguito un elenco dei documenti di riferimento HL7 liberamente scaricabili dai siti istituzionali di XX0.xxx (xxxx://xxx.xx0.xxx/xxxxx.xxx) e XX0.xx (xxxx://xxx.xx0xxxxxx.xx/xxxx/00).
Documento | Descrizione |
HL7 Standard Version 2.5- Capitolo 2 | Regole generali composizione messaggi |
HL7 Standard Version 2.5- Capitolo 3 | Descrizione eventi , messaggi e segmenti ADT |
Compilazione segmenti - indicazioni HL7 Italia (localizzazione italiana - xxx.xx0xxxxxx.xx) | Specifiche Patient Administration V2itTC Release Maggio_2008 Specifiche Data types - Documento di Localizzazione Data Types HL7 Versione 2.5 V2.0 Maggio 2013 |
HL7 Standard Version 2.5 – Capitolo 7 | Descrizione segmento OBX |
HL7 Standard Version 2.5 – Capitolo 8 | Master Files |
HL7 Standard Version 2.5 – Capitolo 15 | Descrizione segmenti ROL e STF |
Il RTI è in ogni caso disponibile a fornire ulteriori allegati tecnici di dettaglio, ovvero i documenti "HL7 per APC" e "HL7 per APC Dizionari".
Riferimenti alla documentazione Standard HL7 v 3
I servizi di movimentazione anagrafica sono altresì rilasciati con standard HL7 V 3 e localizzazione italiana fornita da HL7 Italia.
Per qualunque indicazione tecnica si faccia riferimento allo standard; si riporta in seguito un elenco dei documenti di riferimento HL7 liberamente scaricabili dai siti istituzionali di XX0.xxx (xxxx://xxx.xx0.xxx/xxxxx.xxx) e XX0.xx (xxxx://xxx.xx0xxxxxx.xx/xxxx/00).
Documento | Descrizione |
HL7 Standard Versione 3 - indicazioni HL7 Italia (localizzazione italiana - xxx.xx0xxxxxx.xx) | HL7Italia-PRPA_Patient_Topic-v1.2-S.pdfdel 08/02/2011 |
HL7 Standard Versione 3 - indicazioni HL7 Xxxxxx (xxxxxxxxxxxxxx xxxxxxxx - xxx.xx0xxxxxx.xx) | Xxxxxxxxxx_XXXX_Xxxxxx_Xxxxx_X0xx_XX_Xxxx0000[0].x xx x 0.0 del 25/09/2008 |
3.7 Cross-Enterprise Document Sharing - XDS (IHE)
Profilo sviluppato da IHE che detta le linee guida per lo scambio di documentazione clinica tra aziende o strutture sanitarie diverse. Nella versione XDS.b vengono adottati degli standard in revisioni più recenti (ebXML 3.0, SOAP v1.2, MTOM/XOP) e su di esso si fondano le basi di molti altri profili IHE in corso di definizione, tra cui XCA (Cross-Community Access). In questo profilo si assume che ogni organizzazione appartenga ad uno o più Affinity Domain, ciascuno consistente in un insieme di organizzazioni sanitarie che sottoscrivono delle policies e condividono una infrastruttura tecnologica con lo scopo di scambiarsi tra loro documenti clinici. Le policies oggetto degli accordi riguardano aspetti quali l'identificazione dei pazienti, il
controllo degli accessi, l'ottenimento del consenso alla trattazione dei dati, ma anche il formato, il contenuto, la struttura, l'organizzazione e la rappresentazione delle informazioni cliniche.
La documentazione è pubblica ed articolata nei seguenti volumi:
- Vol. 1 (ITI TF-1): Integration Profiles (rev 10.1 added 2013-10-25)
- Vol. 2: Transactions – diviso nei seguenti sotto-volumi:
o Volume 2a (ITI TF-2a): Transactions ITI-I through ITI-28.
o Volume 2b: (ITI TF-2b): Transactions (cont'd) ITI-29 through ITI-64.
o Volume 2x (ITI TF-2x): Appendices A through W and Glossary
- Vol. 3 (ITI TF-3): contiene Section 4 Cross-Transaction Specifications and Section 5 IHE Content Specifications
3.8 Protocollo di trasporto utilizzato
Tutti i servizi descritti sotto, se non esplicitamente indicato, saranno esposti come web services su protocollo SOAP over HTTP per scambio messaggi in formato XML.
Documentazione sugli standard utilizzati:
• Specifiche OASIS SAML - far riferimento ai documenti:
- xxxx://xxxx.xxxxx-xxxx.xxx/xxxxxxxx/xxxx/x0.0/xxxx-xxxxxxxx-0.0-xx.xxx
- xxxxx://xxx.xxxxx-xxxx.xxx/xxxxxxxxxx/xxxxxxxx.xxx/00000/xxxx-xxxx-xxxxxxxx-xxxxxx-0.0-xx-00-xxxx.xxx
• Specifiche XML:
- Specifiche XML 1.0 (RFC 3076) – xxxx://xxxxx.xxxx.xxx/xxxx/xxx0000
Regione Marche ha deciso di uniformare la modalità e il formato dei documenti che i vari source producono e inviano all’infrastruttura del FSE, secondo le linee guida fornite da HL7 Italia.
Il formato che Regione Marche ha deciso di adottare è il PDF con iniettato il CDA2 del documento, il tutto firmato PADES.
Ogni source pertanto dovrà creare il CDA2 del proprio referto (LIS, RIS, LDO, PS, AMB, ecc), otterere da questo CDA2 il PDF al cui interno sarà iniettato e presente il CDA2 da cui è nato e poi firmare il PDF in modalità PADES.
Per la definizione del formato del CDA2 di ogni singolo referto, fare riferimento ai documenti specifici delle linee guida che si possono trovare al seguente indirizzo:
xxxx://xxx.xx0xxxxxx.xx/xx0xxxxxx_X0/xx0xx_xxxxxxxxxxxx
Per la “costruzione” del PDF con iniettato il CDA2, fare riferimento al documento di specifice allegate
(HL7Italia-ProfiloFirmaCDAInPDF-DSTU.pdf)
3.10 Asserzione firmata con certificato
Regione Marche ha introdotto una nuova modalità di autenticazione per l’accesso all’infrastruttura del Fascicolo Sanitario Elettronico, per le seguenti fase:
• riversamento di un documento da parte di un qualunque Document Source
• indicizzazione dei documenti da parte dei Repository Legacy delle aziende.
In entrambi i casi sopra indicati, il Document Source o il Repository Legacy, devono auto-generare un’asserzione standard SAML 2.0 e firmarla con un certificato che viene fornito dalla CA di Regione Marche.
Questa asserzione firmata dovrà essere inserita nelle transazioni ITI-41 e ITI-42 e sarà compito del Policy Manager, verificare attraverso la propria chiave privata, la chiave pubblica del certifcato con cui è stata firmata l’asserzione, consentendo pertanto al Document Source e/o al Repository Legacy, di procedere con la transazione richiesta.
Il documento di riferimento che norma questa nuova direttiva, contenente anche l’allegato delle specifiche tecniche è un allegato diqute speficihe (ASSERZIONEAPPLICATIVA.pdf).
4 SERVIZI ESPOSTI DALL’INFRASTRUTTURA
L’infrastruttura FSE provvederà ad esporre dei servizi di cooperazione per consentire ai soggetti esterni di interagire con essa.
Rispetto alle interfacce previste dal Capitolato di gara e relativi allegati (allegato 1.2 “Specifiche funzionali dei servizi FSE, ASR, TS e Portale”), si riporta di seguito l’elenco, con indicazione dei riferimenti alle specifiche contenute nel presente documento.
Servizi per il consolidamento documentale
1. Acquisizione documento
Il servizio è stato previsto e specificato al par. 4.3.3 “Servizio di Ricezione Documento su Repository Documentale/FSE”.
2. Gestione versioning
Il servizio di gestione versioning utilizza lo stesso servizio previsto per l’acquisizione documento di Ricezione Documento su Repository, specificato al par. 4.3.3. Tuttavia, in caso di versioning sarà richiesto come obbligatorio il dato “ParentDocument” che corrisponde allo “UniqueID” del documento che viene sostituito (chiave univoca ed invariante nel tempo del documento e). Il servizio di versioning in questo caso fa riferimento alla “sostituzione”, in linea con transazione “Provide and Register Document Set –b” (ITI-15) di IHE che utilizza la voce RPLC (“replace”).
3. Firma e time stamp
Il servizio di firma è stato previsto e specificato ai par. 4.3.1 “Servizio di Firma Digitale Remota” e 4.3.3 “Servizio di Verifica Remota Firma Digitale”. Il servizio di time stamp è ricompreso nel servizio di firma, quando viene richiesto da un opportuno parametro.
4. Modifica metadati
Il servizio è stato previsto e trattato nel capitolo 4.3.4 “Servizio di modifica dei metadati “locali”.
5. Consolidamento e pubblicazione nel FSE
Dall’analisi dei casi d’uso finora condotta il servizio di consolidamento e pubblicazione coincide con la sua firma, così come la pubblicazione (invio) a repository ne è immediata conseguenza. Si rimanda ai par. 4.3.1, 4.3.2 e 4.3.3, 4.3.4 che descrivono rispettivamente i servizi di firma e di archiviazione documento esposti dall’infrastruttura FSE. Relativamente ai servizi di indicizzazione, esposti ad uso degli ulteriori repository aziendali, si rimanda al par. 4.3.6 “Servizio di indicizzazione dei documenti su Registry Regionale FSE”.
6. Conservazione (attraverso integrazione Polo)
Integrazione con il Polo di Conservazione Regionale come da specifiche da richiedere a Regione Marche.
7. Ricerca
Il servizio è stato previsto e specificato ai par. 4.4.3 “Servizio di Ricerca su Repository Locale” e 4.4.4 “Servizio di Retrieve Documento da Repository Locale (firmato e non – dati).
8. Gestione autorizzazioni Repository
Il servizio è stato previsto e specificato al par. 4.1 “Servizio di Autenticazione, Profilazione e Autorizzazione”.
9. Gestione strutture aggregative
La creazione di raggruppamenti logica dei documenti è attualmente ottenibile valorizzando opportunamente i metadati previsti dall’affinity domain. L’attività di definizione degli affinity domain prevista all’interno del progetto esecutivo è pertanto propedeutica all’analisi degli aspetti legati alla gestione delle strutture aggregative.
10. Stampa contrassegno
Il servizio è stato previsto e specificato in allegato al presente documento (Allegato “Servizio Stampa Contrassegno”).
11. Documenti MMG/PLS
Il servizio è stato previsto e specificato al par. 4.3.3 “Servizio di Ricezione Documento su Repository Documentale/FSE”.
Servizi del Fascicolo Regionale
12. Autenticazione
Le specifiche del servizio di autenticazione offerto dal Framework regionale FedCohesion sono riportate in allegato al presente documento (documento “Manuale di integrazione Cohesion”).
13. Gestione eventi
Il servizio è stato previsto e specificato al par. 4.7.1 “Servizi di gestione degli eventi” e relativi sotto paragrafi.
14. Gestione accesso
Il servizio è stato previsto e specificato al par. 4.1 “Servizio di Autenticazione, Profilazione e Autorizzazione”.
15. Ricerca FSE
Il servizio è stato previsto e specificato ai par. 4.4.1 “Servizio di Ricerca Documenti su FSE” e 4.4.2 “Servizio di Retrieve Documento da FSE”.
16. Consultazione valori
Il servizio è stato previsto e specificato al par. 4.4.5 “Servizio di Recupero Risultati Precedenti di Laboratorio”.
17. Documentazione del cittadino
Il servizio è stato previsto e specificato al par. 4.3.3 “Servizio di Ricezione Documento su Repository Documentale/FSE”.
18. Servizio di gestione delle federazioni
Nell’ambito della fornitura sarà possibile eseguire operazioni una tantum di creazione di una nuova federazione, unione ad una federazione, abbandono o rimozione di una nuova federazione attraverso configurazioni specifiche. La sottoposizione di query federate per l’interoperabilità con altri fascicoli regionali sarà invece sviluppata in modo conforme alle specifiche AgID quando queste avranno raggiunto un livello di dettaglio necessario. L’attuale versione delle specifiche è raggiungibile dal seguente link:
xxxx://xxx.xxxx.xxx.xx/xxxxx/xxxxxxx/xxxxx/xxxxxxxxx_xxxxxxxxx/xxxxxxxxxx_xxxxxxxx_xxx_xxxxxxxxxxxxxxxx a_tra_i_sistemi_regionalidi_fse-_versione_definitiva.pdf.
Servizi dell’Anagrafe Regionale Sanitaria
Prima di dettagliare i Servizi Anagrafici è necessario puntualizzare che la piattaforma ASR-EMPI prevede un opportuno sistema di configurazione dei “nodi cooperanti” con relativa mappatura delle categorie di informazioni sensibili / non sensibili da essi fruibili e trattabili.
Infatti, anche se potenzialmente lo standard HL7 lo consentirebbe, il sistema prevede che nei messaggi non transitino assieme i dati anagrafici e i dati sensibili, in ottemperanza alle vigenti normative in materia di trattamento dati; i dati sensibili transiteranno unicamente nei messaggi da/verso i nodi opportunamente configurati per gestirli (es. le esenzioni potrebbero transitare nei messaggi da/verso ASUR Marche in quanto il nodo stesso è fonte di questo dato, ma non da/verso altri nodi non deputati a gestire dati sanitari come ad es. i Servizi Sociali).
Per ogni “nodo” cooperante la piattaforma ASR-EMPI consente quindi la configurazione dei relativi “datamart” disponibili. Il livello minimo di risposta prevede comunque il ritorno del codice identificativo regionale e dei cosiddetti Tratti Anagrafici del cittadino.
Si riporta in seguito lo schema dei possibili datamart abilitabili e dei dati di dettaglio in essi contenuti.
Datamart ASR-EMPI | Dati contenuti |
Tratti Anagrafici | DATI ANAGRAFICI (Cognome, Nome, Sesso, Data Nascita) COMUNE NASCITA CODICE FISCALE NAZIONALITA' DECESSO |
Residenza | INDIRIZZO RESIDENZA LOCALITA’ RESIDENZA COMUNE RESIDENZA CAP REGIONE PROVINCIA |
Domicilio | INDIRIZZO DOMICILIO LOCALITA’ DOMICILIO COMUNE DOMICILIO CAP REGIONE PROVINCIA |
Telefono | RECAPITI TELEFONICI (max 2) |
Attributi | STATO CIVILE PROFESSIONE TITOLO DI STUDIO |
Assistenza | ASL RESIDENZA ASL ASSISTENZA TESSERA SANITARIA SCADENZA TESSERA SANITARIA |
Medico | Ultimo MEDICO DI BASE (MMG/PLS) scelto |
DATA DECORRENZA SCELTA DATA REVOCA | |
Esenzioni [DATI SENSIBILI] | ESENZIONI PER PATOLOGIA (Codici e relativa scadenza) ESENZIONE PER REDDITO (ultima rilevata) |
TEAM | Dati supportati dalla carta TEAM rilasciata da MEF / SistemaTS (PIN, CIN, Istituzione, Nazione, Data scadenza) |
STP | Ultimo CODICE STP rilevato DATA RILASCIO INDIGENZA |
19. Ricerca anagrafica assistito multimodale
L’anagrafe sanitaria regionale ASR-EMPI espone un servizio di interrogazione che prevede le seguenti modalità di ricerca :
o Codici identificativi (Codice Identificativo Regionale o Codice identificativo Locale del nodo richiedente)
o Codice Fiscale
o Cognome e Nome, Sesso, Data Nascita, Comune di Nascita
o Cognome e Nome [opzionali Sesso, Data Nascita, Comune Nascita o Comune Residenza]
o Cognome/Nome con funzione like%
o Codice STP/ENI
I criteri di selezione sopra riportati possono essere eventualmente integrati da una “data/periodo di riferimento” per dare profondità storica alla ricerca.
Il servizio è stato previsto e specificato al par. 4.2.1 “Servizio di Ricerca Anagrafica”.
20. Aggiornamento/Censimento anagrafica
Il servizio è stato previsto e specificato ai par. 4.2.2 “Servizio di Censimento di nuova anagrafica” e par. 4.2.3 “Aggiornamento di una anagrafica”.
21. Ricerca anagrafica generalizzata (cataloghi)
La piattaforma regionale ASR-EMPI si occuperà di reperire dalle fonti opportune una serie di cataloghi regionali e di renderli fruibili a livello centralizzato mediante appositi servizi di notifica delle variazioni occorse agli stessi.
Il servizio è stato previsto e specificato ai parr. 4.2.6 e 4.2.7 “Aggiornamento cataloghi centralizzati” e “Notifica variazione catalogo”.
I cataloghi gestiti dal sistema sono identificati e descritti in apposito allegato a questo documento denominato IN1_Interfacce_Applicative_Allegato_Cataloghi_ASR-EMPI. Va considerato che in via temporanea i cataloghi con “fonte ISTAT” verranno reperiti dalla piattaforma ARCA di ASUR Marche, in attesa che Regione Marche definisca un “gestore” regionale istituzionale del dato proveniente da ISTAT.
22. Popolamento iniziale/ Riallineamento archivio anagrafico
Il servizio è stato previsto e specificato al par. 4.2.4 “Servizio di Unificazione di anagrafiche”.
23. Retrieve variazioni da ultima notifica ricevuta
Il servizio è stato previsto e specificato al par. 4.2.5 “Servizio di Notifica eventi ai nodi cooperanti”.
Come evidenziato negli altri documenti, quali quelli relativi alla stessa infrastruttura, sono messi a disposizione servizi strettamente legati al Fascicolo Sanitario Elettronico e altri più legati ad una gestione dei “referti digitali” in senso più generale. L’insieme delle specifiche previste dal progetto sono raggruppate in base alle funzioni
previste dalle Linee Guida FSE. Sono infine descritti gli ulteriori servizi previsti nell’ambito del presente progetto e previsti in aderenza alla documentazione di gara ovvero emersi in fase di analisi.
4.1 Servizio di Autenticazione, Profilazione e Autorizzazione (categoria
“funzioni di controllo accessi e sicurezza”)
Attribute Autority
FedCohesion
Profilazione
Policy Manager
Autenticazione
<<include>>
Verifica permessi FSE
<<include>>
<<extend>>
Utente
Utilizzo applicativo
ApplicativoVerticale
Figura 2: Caso d’uso – Autenticazione, profilazione e autorizzazione
CASO D’USO: I servizi di autenticazione e profilazione sono offerti da Regione Marche a tutti i client che intendono usufruire dei servizi FSE. Il caso d’uso sopra rappresentato prevede che ciascun utente, per l’interazione del proprio ApplicativoVerticale con il FSE, deve provvedere in maniera sequenziale alla richiesta di un token di identità e del token contenente uno o più ruoli associati all’utente. In tale ambito, saranno esposti a livello regionale i servizi di autenticazione, profilazione e autorizzazione all’utilizzo dei servizi FSE.
ATTORI: di seguito l’elenco degli attori previsti:
Nome | Descrizione |
Utente | Utente del sistema FSE a livello regionale o aziendale (MMG/PLS, medico specialista, operatore, ecc.) |
FedCohesion | Identity Provider a livello regionale |
Attribute Autority | Modulo deputato al rilascio del token contenente il ruolo utente ai fini dell’utilizzo dei servizi FSE |
Policy Manager | Modulo di verifica delle policy (permessi) associati ai ruoli dell’utente |
ApplicativoVerticale | Identifica qualsiasi sistema applicativo in uso presso le Aziende Sanitarie e Ospedaliere marchigiane (ad es. sistemi LIS, RIS, ecc.) e deputato ad interagire con i servizi esposti dal FSE |
4.1.1 Servizio di Autenticazione
[A cura di RM]
4.1.2 Servizio di Autenticazione Applicativa STS (Securety Token Service).
DESCRIZIONE: Il componente STS rappresenta I’Identity Provider proprietario dell’infrastruttura del FSE dedicato al rilascio delle asserzioni di accesso a livello applicativo. A differenza di FedCohesion, tale componente può essere utilizzato solo per processi e servizi specifici che non usufruiscono dell’interazione di un utente e questa modalità di identificazione deve essere concordata e autorizzata dalla stazione appaltante.
Il componente STS è un Identity Provider completo per il rilascio dell’asserzione di identità e ruolo e può essere usato per:
• Invocare i servizi dell ESB XValue protetti da WS-Security
• Eseguire autenticazione sulle applicazioni web XValue
Il componente STS deve necessariamente essere usato come un token, non deve essere pertanto modificato in alcun modo, infatti un’alterazione anche minima ne invalida la XML Signature, rendendolo non valido.
FLUSSO: Il Client invoca il servizio STS per ottenere la SAML Assertion necessaria all’invocazione di specifici servizi protetti da questa tipo di asserzione applicativa.
In dettaglio il flusso operativo previsto è il seguente:
AV = ApplicativoVerticale
STS = Identity Provider di Piattaforma applicativa
1. AV esegue una richiesta di Asserzione Applicativa
2. STS esegue dei controlli formali sulla richiesta ricevuta.
3. STS esegue una query su LDAP / AD per prendere gli attributi dell'utente / ruolo. 4. STS crea un token SAML
5. STS restituisce il token a AV
DATI SCAMBIATI:
Trattandosi di asserzioni applicative, i dati scambiati sono standard e saranno concordati ogni volta con l’attore che ne richiede l’utlizzo.
STANDARD: Lo standard di riferimento è quello illustrato nel paragrafo 3.8 (Protocollo di trasporto utilizzato)
SCENARIO DI ESEMPIO: per lo scenario di esempio si veda quanto riportato al par. 4.3.3.
4.1.3 Servizio di Profilazione
DESCRIZIONE: Il componente Attribute Authority rappresenta l'authority a cui è deputata la funzione di certificazione dei ruoli posseduti dagli utenti.
In particolare, una volta ottenuta l’asserzione SAML con l’identità del richiedente fornita da FedCohesion, il sistema richiedente utilizzerà tale asserzione per effettuare la profilazione dell’utente. In ambito FSE, i ruoli sono necessari per accedere alle risorse esposte dall’infrastruttura FSE; nell’ambito del presente processo, i permessi associati ai ruoli forniti dall’Attribute Autority per l’espletamento del processo dematerializzata saranno gestiti dai rispettivi ApplicativoVerticale.
L’ApplicativoVerticale una volta ottenuto il token da FedCohesion per il riconoscimento dell’utente potrà procedere secondo due alternative:
a) fornire il token contenente l’identità dell’utente senza specifica di ruolo e ricevere dall’Attribute Autority tutti i ruoli disponibili per quell’identità;
b) fornire il token contenente l’identità dell’utente con specifica del ruolo; in questo caso l’Attribute Auotrity verifica l'appartenenza dell’identità al ruolo indicato e restituisce l’asserzione con le informazioni verificate.
FLUSSO: Il client dopo avere recuperato la SAML Assertion dal sistema Fed Cohesion effettua un invocazione al servizio di Attribute Authority inserendo nel SOAP Header (WS-Security) la SAML Assertion e nel SOAP Body un messaggio AttributeQuery ottenendo come risposta una SAML Assertion contenente gli attributi specificati nella richiesta.
In dettaglio il flusso operativo previsto è il seguente:
AV = ApplicativoVerticale AA = Attribute Authority
1. AV esegue una richiesta di AttributeQuery
2. AA esegue controlli di sicurezza sull'asserzione
3. AA controlla se la richiesta è per uno specifico ruolo
4. AA esegue una query su LDAP / AD per prendere gli attributi dell'utente.
5. AA crea un token SAML
6. AA restituisce il token a AV
DATI SCAMBIATI: Si riportano di seguito i dati gestiti dall’Attribute Authority: UTENTI
• ID_Utente (il medesimo di Fed Cohesion e riportato sul NameID sull'asserzione SAML rilasciata, valorizzato con il codice fiscale)
• Cognome
• Nome
• Codice fiscale
• Codice regione
• Codice struttura sanitaria RUOLI
• ID_Ruolo
• Descrizione
Il componente offre un web service che si occupa di rilasciare gli attributi di identità relativi ad un utente. Gli attributi considerati in ogni asserzione SAML sono i seguenti:
• ID_Utente
• ID_Ruolo
• Cognome
• Nome
• Codice Fiscale
• codiceRegione
• codiceStrutturaSanitaria
A valle di una richiesta contenente nel SOAP Header l'asserzione SAML, che certifica l'identità, e nel SOAP Body un messaggio di tipo AttributeQuery, il componente rilascia una nuova asserzione contenente gli attributi relativi ai ruoli dell'operatore.
STANDARD: Lo standard di riferimento è quello illustrato nel paragrafo 3.8 (Protocollo di trasporto utilizzato)
SCENARIO DI ESEMPIO:
Si riporta di seguito il diagramma di sequenza relativo al caso a) sopra descritto.
Figura 3: sequence diagram - autenticazione e profilazione
4.1.4 Servizio di Provisioning Attribute Authority
DESCRIZIONE: Il componente Attribute Authority consente la gestione degli utenti e dei ruoli offrendo le interfacce di provisioning che consentono il popolamento da fonte esterna di utenti, ruoli e l'associazione degli stessi agli utenti presenti su Fed Cohesion.
Le operazioni disponibili per la gestione dell'operatore, del ruolo e dell'associazione sono atomiche.
FLUSSO: Invocazione dei servizi REST da parte degli di attori terzi che vogliono popolare l’Attribute Authority.
DATI SCAMBIATI: Per gli operatori sarà possibile effettuare le seguenti operazioni: inserimento, cancellazione e interrogazione/ricerca.
Per i ruoli sarà possibile effettuare le operazioni di inserimento, cancellazione e interrogazione/ricerca.
Per le associazioni ruolo/utente sarà possibile solo creare ed eliminare associazioni ed interrogare gli utenti associati ad un ruolo.
STANDARD: Lo standard di riferimento è quello illustrato nel paragrafo 3.8 (Protocollo di trasporto utilizzato)
4.1.5 Servizio di popolamento massivo Attribute Authority
DESCRIZIONE: Oltre al servizio di popolamento tramite le interfacce di Provisioning invocabili da fonte esterna, viene reso disponibile una procedura batch che consente il caricamento massivo di utenti secondo un determinato formato record, da lanciare in fase di start-up.
FLUSSO: Inserimento massivo degli utenti a seguito della predisposizione di un tracciato file (excel e/o CSV).
DATI SCAMBIATI: Il tracciato file (excel e/o CSV) necessario per il caricamento massivo degli utenti deve avere la seguente struttura.
Colonna | Valore |
Ruolo | CODICE RUOLO TABELLA 3.1.1.1.1 AFFINITY DOMAIN (MEDICO – MMG/PLS – OPERATORE_MGC) |
CodiceFiscale | Codice Fiscale |
Cognome | Cognome |
Nome | Nome |
Sesso | Sesso |
CodiceRegione | 110 |
CodiceStrutturaSanitaria | CodiceStrutturaSanitaria (201, 901, 902, 903) |
STANDARD: Lo standard di riferimento è quello illustrato nel paragrafo 3.8 (Protocollo di trasporto utilizzato)
4.1.6 Servizio di Autorizzazione
DESCRIZIONE: Il componente Policy Manager contiene le regole per l'accesso e la fruizione dei servizi. Oltre a contenere tali regole si occupa della applicazione e della verifiche delle stesse in funzione delle richieste ricevute. Il componente è conforme allo standard XACML ed invocato, dal modulo PEP dell'ESB, copre le funzionalità previste dai moduli logici XACML PAP e PDP.
Di seguito un dettaglio relativo ai componenti appena citati:
• PDP - (Policy Decision Point) è il modulo che di occupa di analizzare la richiesta di autorizzazione XACML inviata dal PEP e di autorizzare una transazione in base alle "policy" XACML contenute nel modulo PAP.
• PAP - Policy Administration Point - è il modulo che contiene le policy XACML e ne consente il governo e la gestione.
FLUSSO: Per maggiore comprensione dello standard XACML viene di seguito fornita una descrizione del componente PEP che si occupa di intercettare le richieste ai servizi e valutare se questa può essere soddisfatta interagendo con i componenti PDP e PAP sopradescritti.
PDP:
Il modulo PDP espone un servizio per la ricezione di invocazioni XACML Request da parte del modulo PEP. La Request XACML contiene i seguenti elementi:
• Subject - definisce e identifica l'attore che richiede una risorsa;
• Resource - definisce la risorsa alla quale si intende accedere;
• Action - definisce l'azione che si vuole intrapredere sulla risorsa.
Il modulo PDP risponde con un messaggio contenente il risultato della decisione che può essere "Permit" o "Deny" per un decisione finale (o "Intermediate" per una comunicazione intermedia).
PAP:
Il modulo PAP contiene le policy XACML e ne consente la gestione attraverso interfacce a servizi.
Il componente Policy Manager utilizza la versione XACML 3.0 di seguito viene riportata l'implementazione e le attuali regole con cui viene gestita la comunicazione tra il PEP e la componente PDP. Vengono fornite le indicazione con le quali viene generata un XACML Request da parte del PEP e come deve essere modellata una policy sul PAP per consentire il corretto ingaggio da parte del PEP.
DATI SCAMBIATI: i messaggi tra i moduli PEP e PDP consentono di verificare la policy. I servizi esposti dal PAP contengono le policy XACML che saranno conservate nel modulo. Si riportano di seguito la lista dei requisiti per la gestione di un policy XACML.
• Funzionalità della policy
• Fase della policy
• Advice
• Obbligations
Nel capitolo 5.1.3 vengono descritti nel dettaglio i requisiti sopra indicati che interessano gli attori PEP, PDP, PAP e le modalità creazione definizione e utilizzo delle policy.
STANDARD: Lo standard di riferimento è costituito dai messaggi standard OASIS xacml-2.0. Come protocollo di trasporto è prevista l’esposizione di Web Services su protocollo HTTP o HTTPS per scambio messaggi in formato XML.
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo al caso della verifica dei permessi necessari all’archiviazione di un documento nel repository. Nel caso d’uso, per maggiore semplicità, sono stati volutamente tralasciati i servizi di autenticazione e profilazione, per i quali si rimanda al par. 4.1.2.
ApplicativoVerticale
Access Gateway
Policy Manager
Repository
- con token identità e
1 : Invio documento token attributo()
2 : Verifica asserzioni identità e ruolo()
4 :
3
: Recupera Policy()
Ritorna policy()
5 :
Verifica Policy()
6 : Invio documento()
Figura 4: sequence diagram – Indicizzazione su Registry Regionale FSE
4.2 Servizi Anagrafici (categoria “funzioni di identificazione”)
CASO D’USO SERVIZI ANAGRAFICI
Figura 5: Caso d’uso – Servizi Anagrafici
Il diagramma sopra riportato evidenzia l’insieme dei principali casi d’uso relativi ai servizi anagrafici che saranno esposti dall’infrastruttura FSE.
ATTORI: di seguito l’elenco degli attori previsti:
Nome | Descrizione |
LocalMPI | Identifica un generico sistema anagrafico che si interfaccia ad ASR-EMPI come “nodo” sottordinato; nella fattispecie potranno essere nodi di ASR- EMPI le anagrafi locali di riferimento delle seguenti Aziende Sanitarie e/o Servizi di livello regionale : - Azienda Sanitaria Unica Regionale Marche (ASUR) - Azienda Ospedaliero Universitaria Ospedali Riuniti di Ancona - Azienda Ospedaliera Ospedali Riuniti Marche Nord - Istituto Nazionale di Riposo e Cura per Anziani V.E.II (INRCA) - Servizio Regionale Politiche sociali e sport - CUP Regionale - RIS/LIS Regionale - Sistemi di prescrizione dei medici - … (altro previsto dal progetto Lotto 1) . |
ApplicativoVerticale | Identifica qualsiasi sistema applicativo in uso presso le Aziende Sanitarie marchigiane (ad es. sistemi di gestione ADT, PS, eccetera) ed i Servizi Regionali le cui anagrafi di riferimento interoperano con ASR-EMPI |
Sistema Nazionale | Identifica i sistemi a carattere nazionale che interoperano con ASR-EMPI e che si pongono a livello sovraordinato rispetto la stessa, nella fattispecie: - Sistema TS predisposto dal MEF - Sistema INA-SAIA (ora ANPR) predisposto dal Ministero dell’Interno. |
IRUW | Identifica il sistema regionale Indice Regionale Unico del Welfare, come sistema sovraordinato ad ASR-EMPI. |
FSE | Identifica la piattaforma regionale di gestione del Fascicolo Sanitario Elettronico |
In seguito si riportano le specializzazioni dei casi d’uso riferiti a servizi descritti n questo documento.
1) CASO D’USO SERVIZIO DI RICERCA ANAGRAFICA
Figura 6: Caso d’uso – Servizio di ricerca anagrafica
2) CASO D’USO SERVIZIO DI CENSIMENTO ANAGRAFICA
Figura 7: Caso d’uso – Servizio di Censimento Anagrafica
3) CASO D’USO SERVIZIO DI VARIAZIONE ANAGRAFICA
Figura 8: Caso d’uso – Servizio di Variazione Anagrafica
4) CASO D’USO SERVIZIO DI UNIFICAZIONE ANAGRAFICA
Figura 9: Caso d’uso – Servizio di Unificazione Anagrafica
5) CASO D’USO SERVIZIO DI NOTIFICA AGGIORNAMENTI ANAGRAFICA
Figura 10: Caso d’uso – Servizio di Notifica aggiornamenti Anagrafica
CASO D’USO GESTIONE CATALOGHI CENTRALIZZATI
Figura 11: Caso d’uso – Gestione cataloghi centralizzati
Il diagramma sopra riportato evidenzia l’insieme dei principali casi d’uso relativi alla gestione dei cataloghi centralizzati che saranno esposti dall’infrastruttura FSE.
ATTORI: di seguito l’elenco degli attori previsti:
Nome | Descrizione |
FonteCatalogo | Identifica un sistema di gestione del catalogo, che sarà il sistema alimentante per la piattaforma di distribuzione dei cataloghi prevista in ASR-EMPI |
ConsumerCatalogo | Identifica un qualsiasi sistema nell’ambito FSE o cooperante con la piattaforma FSE nel suo complesso, che pertanto necessita di ricevere gli aggiornamenti dei cataloghi centralizzati da ASR-EMPI |
4.2.1 Servizio di Ricerca anagrafica
DESCRIZIONE: un utente effettua una ricerca anagrafica tramite ApplicativoVerticale sulla LocalMPI di riferimento (RicercaAnagrafica) e non trova il soggetto da referenziare, sia perché la ricerca ha prodotto un risultato nullo, sia perché la ricerca ha prodotto un elenco di soggetti non utilizzabili. ApplicativoVerticale propone all’utente di continuare la ricerca su ASR-EMPI (RicercaAnagraficaSup), tale ricerca può ottenere o una lista di soggetti rispondenti ai criteri di selezione tra i quali scegliere il prescelto, oppure nessun risultato.
FLUSSO: LocalMPI attiva il servizio di ricerca su ASR-EMPI passando la propria identificazione come sistema cooperante (ID-NODO) ed inviando i criteri di selezione del soggetto; il servizio restituisce :
a) uno o più soggetti associati al rispettivo identificativo regionale (GUIDFSE); le anagrafiche selezionate devono rispondere ai criteri di “certificazione ASR” ovvero devono possedere una certificazione MEF e/o una certificazione ASUR. E’ possibile derogare alla regola della “certificazione ASR” (e quindi
ritornare anche posizioni non certificate) qualora LocalMPI sia autorizzato tramite opportuna configurazione su ASR-EMPI a ricevere dati non certificati (ad es. nel caso dei sistemi Verticali Regionali)
b) nessun soggetto in quanto non esiste una referenza in ASR-EMPI che soddisfa i criteri di selezione inviati; in questo caso :
1) se il filtro di ricerca non è codice fiscale, la ricerca non restituisce risultati
2) se il filtro di ricerca è per codice fiscale, si attiva automaticamente da ASR-EMPI la query su SistemaTS; qualora venga identificata la posizione anagrafica su SistemaTS verrà restituita la posizione trovata, diversamente la ricerca non restituirà risultati.
DATI SCAMBIATI: Si faccia riferimento al paragrafo 4.2.10 di questo documento per la descrizione dei dati anagrafici gestiti da ASR-EMPI e inviati nei messaggi supportati dalla presente versione del protocollo di integrazione.
STANDARD: Lo standard di riferimento del servizio di Ricerca Anagrafica in ASR-EMPI è HL7 2.5 XML o HL7 V3 con localizzazione italiana fornita da HL7 Italia laddove prevista;
in caso di implementazione dei servizi con standard HL7 V 2.5 occorre produrre la compilazione di un Messaggio di Query che può essere un QBP^Q22 oppure un QRY^A19, a scelta del fruitore del servizio.
in caso di implementazione dei servizi con standard HL7 V 3 occorre produrre la compilazione di un Messaggio di Query aderente ad una interazione fra PRPA_IN201305UV, PRPA_IN201306UV, PRPA_IN201307UV, PRPA_IN201308UV,PRPA_IN201309UV, PRPA_IN201310UV, in base ai criteri di
selezione che si vogliono adottare.
Per approfondimenti tecnici sullo standard HL7 si faccia riferimento al paragrafo 3.6 di questo documento.
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo al caso a) sopra descritto.
Figura 12: sequence diagram – ricerca anagrafica su ASR-EMPI
4.2.2 Servizio di Censimento di nuova anagrafica
DESCRIZIONE: un utente di ApplicativoVerticale decide di inserire un nuovo soggetto sull’anagrafe di riferimento LocalMPI, a seguito di una ricerca anagrafica fallita o per esigenze specifiche; tale inserimento viene poi notificato ad ASR-EMPI per il censimento a livello regionale.
FLUSSO: ApplicativoVerticale attiva il servizio di censimento di nuova anagrafica e LocalMPI di riferimento trasmette ad ASR-EMPI i dati di profilo del soggetto; il servizio restituisce un messaggio di ricezione del censimento di nuova anagrafica. ASR-EMPI verifica se esiste già un GUIDFSE con stessi dati (criterio di riconduzione per stesso codice fiscale), nel qual caso la posizione non viene recepita; tale posizione anagrafica resterà quindi censita solo nel sistema inviante senza GUIDFSE, potrà essere unificata alla posizione correttamente registrata e in possesso di un GUIDFSE oppure potrà essere utilizzata per la registrazione del CDR aziendale ma non ai fini del fascicolo.
In caso di nuova posizione anagrafica, ASR-EMPI registra le informazioni calcolandone il relativo codice unico regionale (GUIDFSE) restituendolo al nodo proponente. Per le proposte di nuove anagrafiche prive di certificazioni ASR-EMPI ricerca su SistemaTS il codice fiscale della nuova posizione, riportando la certificazione MEF in caso di esito positivo. Successivamente il sistema ASR-EMPI provvede a restituire la posizione certificata (variazione anagrafica) a LocalMPI.
Il sistema ASR-EMPI provvede inoltre a predisporre i dati per la notifica ai nodi cooperanti (Notifica dati) configurati a riceverla, nelle modalità previste dal servizio di notifica.
DATI SCAMBIATI: Si faccia riferimento al paragrafo 4.2.10 di questo documento per la descrizione dei dati anagrafici gestiti da ASR-EMPI e inviati nei messaggi supportati dalla presente versione del protocollo di integrazione.
STANDARD: Lo standard di riferimento del servizio di Censimento nuova Anagrafica in ASR-EMPI è HL7 2.5 XML con localizzazione italiana fornita da HL7 Italia; occorre produrre la compilazione di un Messaggio di inserimento anagrafico del tipo ADT^A28 per inviare il nuovo profilo ad ASR-EMPI e la gestione della ricezione di un messaggio analogo per ricevere da ASR-EMPI la chiave regionale (GUIDFSE) assegnata al nuovo profilo.
STANDARD: Lo standard di riferimento del servizio di Censimento nuova Anagrafica in ASR-EMPI è HL7 2.5 XML o HL7 V3 con localizzazione italiana fornita da HL7 Italia laddove prevista;
in caso di implementazione dei servizi con standard HL7 V 2.5 occorre produrre la compilazione di un Messaggio di inserimento anagrafico del tipo ADT^A28 per inviare il nuovo profilo ad ASR-EMPI e la gestione della ricezione di un messaggio analogo per ricevere da ASR-EMPI la chiave regionale (GUIDFSE) assegnata al nuovo profilo;
in caso di implementazione dei servizi con standard HL7 V 3 occorre produrre la compilazione di un Messaggio di richiesta di censimento di un nuovo paziente aderente ad una interazione fra XXXX_XX000000XX XXXX_XX000000XX-XXXX_XX000000XX.
Per approfondimenti tecnici sullo standard HL7 si faccia riferimento al paragrafo 3.6 di questo documento.
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo al caso di registrazione nuova posizione in ASR-EMPI sopra descritto.
Figura 13: sequence diagram – censimento anagrafico su ASR-EMPI
4.2.3 Servizio di Aggiornamento di una anagrafica
DESCRIZIONE: un utente di ApplicativoVerticale decide di modificare i dati anagrafici sulla propria anagrafe di riferimento a seguito di una ricerca anagrafica o per esigenze specifiche. E’ resposanbilità del LocalMPI non inviare ad ASR-EMPi variazioni di dati certificati : le richieste non generano errore ma non vengono recepite su ASR-EMPI. Tale variazione viene poi notificata ad ASR-EMPI.
FLUSSO: ApplicativoVerticale attiva il servizio di aggiornamento di una anagrafica e trasmette ad ASR-EMPI i dati di profilo del soggetto ed il relativo GUIDFSE; il servizio restituisce un messaggio di ricezione della variazione anagrafica e registra i dati modificati su ASR-EMPI secondo opportune regole di “certificazione” e protezione del dato (in generale il risultato atteso è di ottenere il CF certificato da SistemaTS, la residenza certificata da fonte comunale, i dati sanitari certificati da ASUR Marche). I dati non protetti da certificazioni (es. il numero di telefono) possono essere raccolti da qualunque nodo cooperante ed aggiornati su ASR-EMPI.
Successivamente il sistema ASR-EMPI provvede ad aggiornare l’archivio storico delle movimentazioni anagrafiche del profilo e a predisporre i dati per la notifica ai nodi cooperanti (Notifica dati) configurati a riceverla, nelle modalità previste dal servizio di notifica.
DATI SCAMBIATI: Si faccia riferimento al paragrafo 4.2.10 di questo documento per la descrizione dei dati anagrafici gestiti da ASR-EMPI e inviati nei messaggi supportati dalla presente versione del protocollo di integrazione.
STANDARD: Lo standard di riferimento del servizio di Aggiornamento di una Anagrafica in ASR-EMPI è HL7
2.5 XML o HL7 V3 con localizzazione italiana fornita da HL7 Italia laddove prevista;
in caso di implementazione dei servizi con standard HL7 V 2.5 occorre produrre la compilazione di un Messaggio di variazione anagrafica del tipo ADT^A31.
in caso di implementazione dei servizi con standard HL7 V 3 occorre produrre la compilazione di un Messaggio di richiesta di cambiamento dei dati anagrafici di paziente aderente ad una interazione fra XXXX_XX000000XX XXXX_XX000000XX-XXXX_XX000000XX.
Per approfondimenti tecnici sullo standard HL7 si faccia riferimento al paragrafo 3.6 di questo documento.
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo al caso di variazione anagrafica in ASR-EMPI sopra descritto.
Figura 14: sequence diagram – variazione anagrafica su ASR-EMPI
4.2.4 Servizio di Unificazione di anagrafiche
4.2.4.1 Unificazione anagrafica da ARCA
DESCRIZIONE: un utente di ApplicativoVerticale (ARCA) a seguito di una ricerca anagrafica rileva nella propria anagrafe di riferimento la presenza di due o più profili anagrafici riferiti allo stesso cittadino e definisce quale sia il profilo corretto unificando di conseguenza i restanti profili. Tale unificazione, se riferita a profili con GUIDFSE valorizzato e diverso, viene poi notificata ad ASR-EMPI.
FLUSSO: ApplicativoVerticale (ARCA) attiva il servizio di unificazione anagrafica registrandone l’esito su LocalMPI (ARCA) e, nei casi previsti, trasmette ad ASR-EMPI il GUIDFSE della posizione corretta ed il GUIDFSE del profilo da unificare; il servizio restituisce un messaggio di ricezione dell’unificazione anagrafica e la riproduce su ASR-EMPI secondo opportune regole. I profili unificati non verranno cancellati da ASR-EMPI ma solo resi “non attivi” e mantenuti con i propri dati storici.Successivamente il sistema ASR-EMPI provvede
ad aggiornare l’archivio storico delle movimentazioni anagrafiche dei profili unificati e a predisporre i dati per la notifica ai nodi cooperanti (Notifica dati) configurati a riceverla, nelle modalità previste dal servizio di notifica.
DATI SCAMBIATI: Si faccia riferimento al paragrafo 4.2.10 di questo documento per la descrizione dei dati anagrafici gestiti da ASR-EMPI e inviati nei messaggi supportati dalla presente versione del protocollo di integrazione.
STANDARD: Lo standard di riferimento del servizio di Unificazione di Anagrafiche in ASR-EMPI è HL7 2.5 XML o HL7 V3 con localizzazione italiana fornita da HL7 Italia laddove prevista;
in caso di implementazione dei servizi con standard HL7 V 2.5 occorre produrre la compilazione di un Messaggio di Unificazione Anagrafica del tipo ADT^A40.
in caso di implementazione dei servizi con standard HL7 V 3 occorre produrre la compilazione di un Messaggio di notifica di riconciliazione di posizioni anagrafiche pazienti aderente all’interazione PRPA_IN201304UV02.
Per approfondimenti tecnici sullo standard HL7 si faccia riferimento al paragrafo 3.6 di questo documento.
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo al caso di unificazione anagrafiche con GUIDFSE diversi da LocalMPI=ARCA sopra descritto.
Figura 15: sequence diagram – unificazione anagrafica da LocalMPI = ARCA
4.2.4.2 Unificazione anagrafica da altro LocalMPI
DESCRIZIONE: un utente di ApplicativoVerticale (diverso da ARCA) a seguito di una ricerca anagrafica rileva nella propria anagrafe di riferimento la presenza di due o più profili anagrafici riferiti allo stesso cittadino, definendone quale sia il profilo corretto.
I profili identificati possono rientrare nelle seguenti casistiche :
1) Profili unificabili tramite funzione applicativa di LocalMPI - i profili anagrafici hanno una delle seguenti caratteristiche:
• GUIDFSE valorizzato ed indentico per tutte le posizioni
• GUIDFSE non valorizzato per tutte le posizioni
• GUIDFSE valorizzato per la posizione corretta e non valorizzato per la posizione da unificare.
L’utente procede all’unificazione anagrafica utilizzando l’apposita funzione di ApplicativoVerticale. Tali movimentazioni non verranno notificate ad ASR-EMPI.
2) Profili unificabili tramite piattaforma applicativa di ASR-EMPI – i profili anagrafici hanno una delle seguenti caratteristiche :
• GUIDFSE valorizzato e diverso per tutte le posizioni
• Il profilo da unificare è stato generato dal LocalMPi di riferimento dell’utente, ed è altresì privo di certificazioni ASR (ovvero non è certificato MEF e/o ASUR).
Per procedere all’unificazione l’utente si autentica alla piattaforma applicativa di ASR-EMPI ed utilizza la specifica funzione prevista.
FLUSSO: Nel caso 1) ApplicativoVerticale (diverso da ARCA) procede alla unificazione anagrafica registrandone l’esito su LocalMPI.
Nel caso 2) ApplicativoVerticale (ovvero la funzione applicativa della piattafomra ASR-EMPI) procede alla unificazione anagrafica registrandone l’esito su ASR-EMPI. I profili unificati non verranno cancellati da ASR- EMPI ma solo resi “non attivi” e mantenuti con i propri dati storici. Successivamente il sistema ASR-EMPI provvede ad aggiornare l’archivio storico delle movimentazioni anagrafiche dei profili unificati e a predisporre i dati per la notifica ai nodi cooperanti (Notifica dati) configurati a riceverla, nelle modalità previste dal servizio di notifica.
DATI SCAMBIATI: Non vi sono scambi di dati nello scenario descritto.
STANDARD: Non applicabile.
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo al caso di unificazione anagrafica in ASR-EMPI sopra descritto (caso 2).
Figura 16: sequence diagram – unificazione anagrafica da ASR-EMPI (caso 2)
4.2.5 Servizio di Notifica eventi ai nodi cooperanti
4.2.5.1 Notifica di censimento, variazione, unificazione
DESCRIZIONE: il sistema ASR-EMPI provvede a notificare agli altri “nodi” cooperanti le movimentazioni anagrafiche recepite sulla propria piattaforma. La piattaforma applicativa di ASR-EMPI consente di configurare in modo “selettivo” le notifiche verso i vari nodi, in base all’autorizzazione definita da Regione Marche a ricevere tali notifiche. Inoltre, sempre tramite configurazione applicativa delle regole di cooperazione relative ad ogni nodo di ASR-EMPI, è possibile limitare le notifiche alle sole anagrafiche certificate piuttosto che a tutte. Si riporta uno schema delle possibili configurazioni.
Tipologia di configurazione dei nodi cooperanti su ASR-EMPI | Cosa riceve il nodo cooperante |
Un nodo riceve tutte le movimentazioni anagrafiche effettuate dagli altri nodi | - Censimento, variazione, merge - Anagrafiche certificate ASR e non certificate |
Un nodo riceve le movimentazioni anagrafiche effettuate dagli altri nodi di posizioni che ha già trattato | - Variazioni, merge se Local-ID del nodo ricevente è presente in XREF abbinato al GUIDFSE - Anagrafiche certificate ASR (MEF e/o ASUR) e non certificate |
Un nodo riceve le movimentazioni anagrafiche effettuate dagli altri nodi di posizioni che ha già trattato, purchè certificate | - Variazioni, merge se Local-ID del nodo ricevente è presente in XREF abbinato al GUIDFSE |
- Anagrafiche ASUR) | certificate | ASR | (MEF | e/o |
FLUSSO: un servizio automatico temporizzato della piattaforma ASR-EMPI invia la movimentazione anagrafica recepita da un “nodo” cooperante (sia a livello regionale che a livello nazionale) agli altri “nodi” regionali configurati a ricevere tale notifica. Qualora il sistema rilevi la mancata ricezione della notifica ad uno o più nodi riceventi, è previsto il reinvio automatico sempre tramite un servizio temporizzato. Tale servizio distingue le modalità di reinvio in base alla tipologia di messaggio da reinoltrare :
- Censimento, con priorità rispetto gli altri eventi, tentativo di reinoltro ogni 60 minuti
- Altre notifiche, tentativo di reinoltro ogni giorno alle ore 18:00 .
Il sistema effettuerà tante reiterazioni del tentativo di reinvio per una settimana a far data dalla creazione del messaggio di notifica. In caso di fallimento della reiterazione, è possibile attivare una notifica (ad es. anche via mail) per ogni singolo nodo cooperante che informa della situazione.
I “nodi” riceventi tratteranno l’informazione ricevuta secondo le proprie politiche locali di gestione anagrafica.
DATI SCAMBIATI: Si faccia riferimento al paragrafo 4.2.10 di questo documento per la descrizione dei dati anagrafici gestiti da ASR-EMPI e inviati nei messaggi supportati dalla presente versione del protocollo di integrazione.
STANDARD: Lo standard di riferimento del servizio di Notifica variazioni Anagrafiche in ASR-EMPI è HL7 2.5 XML o HL7 V3 con localizzazione italiana fornita da HL7 Italia laddove prevista;
in caso di implementazione dei servizi con standard HL7 V 2.5 i nodi riceventi devono poter recepire i seguenti messaggi:
• tipo ADT^A28 per il censimento di nuova anagrafica
• tipo ADT^A31 per la variazione di una anagrafica
• tipo ADT^A40 per l’unificazione di due anagrafiche;
in caso di implementazione dei servizi con standard HL7 V 3 i nodi riceventi devono poter recepire i seguenti messaggi:
• notifica di censimento di nuovo paziente (interazione PRPA_IN201301UV)
• notifica di cambiamento dati anagrafici e dati sanitari di un paziente (interazione PRPA_IN201302UV)
• notifica di riconciliazione di posizioni anagrafiche pazienti (interazione PRPA_IN201304UV02). Per approfondimenti tecnici sullo standard HL7 si faccia riferimento al paragrafo 3.6 di questo documento.
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo ad un generico caso di movimentazione anagrafica in ASR-EMPI.
Figura 17: sequence diagram – notifica dati da ASR-EMPI
4.2.5.2 Notifica di utilizzo anagrafica
DESCRIZIONE: un nodo cooperante di ASR-EMPI, che rappresenta una Funzione di livello regionale (ad es. RIS regionale) e con una propria LocalMPI, usa una anagrafica (anche senza modificarne il contenuto informativo) nello svolgimento dell’attività per una determinata Azienda Sanitaria, senza collaborare con l’Anagrafe Locale dell’Azienda. Il Verticale Regionale notifica quindi l’utilizzo dell’anagrafica ad ASR-EMPI che a sua volta si fa carico di verificare che essa esista nella LocalMPI dell’Azienda Sanitaria e, in caso negativo, inviare il relativo censimento alla LocalMPI dell’Azienda Sanitaria. Ciò consente di mantenere consistente l’informazione anagrafica nei Flussi operativi fra Verticale Regionale e LocalMPI delle Aziende Sanitarie per cui svolge attività.
FLUSSO: il Verticale Regionale inoltra ad ASR-EMPI una Notifica di utilizzo per informare che sta usando una Anagrafica per una certa Azienda Sanitaria. ASR-EMPI interpreta il messaggio ricevuto unicamente per assicurarsi che quella Anagrafica esista in quella Azienda ( consultando il proprio XREFS ) e, nel caso non esista, inoltra una richiesta di censimento all’Azienda Sanitaria affinchè registri quel profilo sulla propria LocalMPI. Il nodo ricevente tratterà l’informazione ricevuta secondo le proprie politiche locali di gestione anagrafica.
DATI SCAMBIATI: Si faccia riferimento al paragrafo 4.2.10 di questo documento per la descrizione dei dati anagrafici gestiti da ASR-EMPI e inviati nei messaggi supportati dalla presente versione del protocollo di integrazione.
STANDARD: Lo standard di riferimento del servizio di di Notifica utilizzo Anagrafica in ASR-EMPI è HL7 2.5 XML o HL7 V3 con localizzazione italiana fornita da HL7 Italia laddove prevista;
in caso di implementazione dei servizi con standard HL7 V 2.5 i nodi cooperanti devono poter gestire un Messaggio di tipo ADT^A31;
in caso di implementazione dei servizi con standard HL7 V 3 i nodi cooperanti devono poter gestire un Messaggio aderente all’interazione PRPA_IN201302UV (non esistendo nella implementazione HL7 V3 una interazione dedicata, si è ricondotto alla “Notifica di cambiamento dati anagrafici e dati sanitari di un paziente”).
Per approfondimenti tecnici sullo standard HL7 si faccia riferimento al paragrafo 3.6 di questo documento.
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo ad un caso di ricezione in ASR-EMPI della notifica di utilizzo anagrafica inviata da Verticale Regionale.
Figura 18: sequence diagram – notifica di utilizzo anagrafica mediata da ASR-EMPI
4.2.6 Servizio di Aggiornamento cataloghi centralizzati
DESCRIZIONE: un sistema della piattaforma FSE o con essa cooperante (FonteCatalogo) che è la fonte di gestione dei dati del catalogo, invia ad ASR-EMPI le notifiche di inserimento, variazione, cancellazione logica, riattivazione di una o più referenze appartenenti al catalogo gestito.
FLUSSO: ASR-EMPI riceve la notifica di variazione catalogo da FonteCatalogo (AggiornaCatalogo) e provvede ad aggiornare il relativo dizionario centralizzato di riferimento.
DATI SCAMBIATI: Si faccia riferimento al paragrafo 4.2.11 di questo documento per la descrizione dei dati dei cataloghi centralizzati gestiti da ASR-EMPI e inviati nei messaggi supportati dalla presente versione del protocollo di integrazione.
STANDARD: Lo standard di riferimento del servizio di Aggiornamento Catalogo in ASR-EMPI è HL7 2.5 XML; ASR-EMPI recepisce l'inserimento, l'aggiornamento, la cancellazione logica o la riattivazione di una referenza nei Cataloghi mediante un messaggio HL7di tipo MFN^M13.
Per approfondimenti tecnici sullo standard HL7 si faccia riferimento al paragrafo 3.6 di questo documento.
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo alla ricezione di modifica di un catalogo.
Figura 19: sequence diagram – notifica di aggiornamento catalogo ad ASR-EMPI
4.2.7 Servizio di Notifica variazione catalogo
DESCRIZIONE: un sistema della piattaforma FSE o con essa cooperante (ConsumerCatalogo) riceve da ASR-EMPI le notifiche di inserimento, variazione, cancellazione logica, riattivazione di una o più referenze appartenenti ad un catalogo centralizzato.
FLUSSO: ConsumerCatalogo riceve la notifica di variazione catalogo da ASR-EMPI (NotificaCatalogo) e provvede ad aggiornare il relativo dizionario locale di riferimento. In caso di inserimento, ConsumerCatalogo ritorna ad ASR-EMPI la chiave identificativa della propria referenza locale. Qualora ASR-EMPI rilevi la mancata ricezione della notifica ad uno o più nodi riceventi, è previsto il reinvio automatico sempre tramite un servizio temporizzato con tentativo di reinoltro ogni giorno dalle ore 18:00 . Il sistema effettuerà tante reiterazioni del tentativo di reinvio per una settimana a far data dalla creazione del messaggio di notifica. In caso di fallimento della reiterazione, è possibile attivare una notifica (ad es. anche via mail) per ogni singolo nodo cooperante che informa della situazione.
DATI SCAMBIATI: Si faccia riferimento al paragrafo 4.2.11 di questo documento per la descrizione dei dati dei cataloghi centralizzati gestiti da ASR-EMPI e inviati nei messaggi supportati dalla presente versione del protocollo di integrazione.
STANDARD: Lo standard di riferimento del servizio di Notifica Variazione Catalogo in ASR-EMPI è HL7 2.5 XML; ASR-EMPI comunica l'inserimento, l'aggiornamento, la cancellazione logica o la riattivazione di una referenza nei Cataloghi mediante un messaggio HL7di tipo MFN^M13.
Per approfondimenti tecnici sullo standard HL7 si faccia riferimento al paragrafo 3.6 di questo documento.
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo al caso di variazione in modifica di un catalogo.
Figura 20: sequence diagram – notifica di variazione catalogo da ASR-EMPI
4.2.8 Servizio di Anonimizzazione
DESCRIZIONE: un nodo cooperante con ASR-EMPI richiede l’anonimizzazione di un profilo anagrafico (o di una lista di profili) identificato dal relativo GUIDFSE (o lista di GUIDFSE), ed ottiene di ritorno il relativo codice univoco di anonimizzazione (ID-Anonimizzazione) quando previsto.
FLUSSO: ASR-EMPI riceve da un nodo cooperante la richiesta di anonimizzazione con due possibili finalità:
- Richiesta puntuale del codice univoco di anonimizzazione (ID-Anonimizzazione) di un singolo profilo o di una lista di profili anagrafici
- Attivazione dell’anonimizzazione di un profilo anagrafico, ovvero manifestazione della volontà di rendere anonimo il profilo per le successive transazioni di Query e Notifiche fra ASR-EMPI e il nodo richiedente.
DATI SCAMBIATI: Occorre distinguere per le due modalità previste di anonimizzazione :
- In caso di richiesta puntuale di anonimizzazione, i dati scambiati sono unicamenti il GUIDFSE e il relativo ID-Anonimizzazione
- In caso di attivazione dell’anonimizzazione per le successive transazioni di query e notifiche, saranno oscurati in dette transazioni i dati GUIDFSE, Cognome, Nome, Codice Fiscale.
Si faccia riferimento al paragrafo 4.2.10 di questo documento per la descrizione dei dati anagrafici gestiti da ASR-EMPI e inviati nei servizi supportati dalla presente versione del protocollo di integrazione.
STANDARD: I servizi forniti sono servizi XML proprietari di ASR-EMPI : AnonimizzazioneEncode è il servizio da utilizzare per la richiesta puntuale di anonimizzazione, AnonimizzazioneON è il servizio da utilizzare per l’attivazione dell’anonimizzazione per le successive transazioni di query e notifiche fra il nodo richiedente e ASR-EMPI.
SCENARIO DI ESEMPIO: Non applicabile.
4.2.9 Servizio di Deanonimizzazione
DESCRIZIONE: un nodo cooperante con ASR-EMPI disattiva la transazione anonimizzata per uno o più profili precedentemente attivata, oppure richiede la deanonimizzazione puntuale di un profilo anagrafico (o di una lista di profili) che in questo caso verrà sottoposta al vaglio degli Amministratori ASR-EMPI.
FLUSSO: ASR-EMPI riceve da un nodo cooperante la richiesta di deanonimizzazione in due possibili modalità:
- Richiesta puntuale di deanonimizzazione di un singolo profilo o di una lista di profili anagrafici; in questo caso gli Amministratori ASR-EMPI possono avvalersi dei seguenti reports per gestire le richieste pervenute :
o ANONIMIZZAZIONE DECODE REPORT (ELENCO RICHIESTE) : elenco delle richieste di deanonimizzazione pervenute tramite il servizio AnonimizzazioneDecode
o ANONIMIZZAZIONE DECODE REPORT (DEANONIMIZZAZIONE) : l'Amministratore digita come filtro un ID-richiesta ed il report effettua la relativa deanonimizzazione, ovvero si ottiene un report con i dati in chiaro (trasformazione di un elenco di ID-Anonimizzati nei corrispondenti GUIDFSE, Cognome, Nome, CF).
- Disattivazione dell’anonimizzazione di un profilo anagrafico, ovvero manifestazione della volontà di riportare in chiaro i dati del profilo per le successive transazioni di Query e Notifiche fra ASR-EMPI e il nodo richiedente.
DATI SCAMBIATI: Occorre distinguere per le due modalità previste di anonimizzazione :
- In caso di richiesta puntuale di deanonimizzazione, i dati scambiati sono unicamenti il GUIDFSE e il relativo codice univoco assegnato alla richiesta che verrà sottoposta agli amministratori ASR-EMPI;
- In caso di disattivazione dell’anonimizzazione per le successive transazioni di query e notifiche, saranno riportati in chiaro in dette transazioni i dati GUIDFSE, Cognome, Nome, Codice Fiscale.
Si faccia riferimento al paragrafo 4.2.10 di questo documento per la descrizione dei dati anagrafici gestiti da ASR-EMPI e inviati nei servizi supportati dalla presente versione del protocollo di integrazione.
STANDARD: I servizi forniti sono servizi XML proprietari di ASR-EMPI : AnonimizzazioneDecode è il servizio da utilizzare per la richiesta puntuale di deanonimizzazione, AnonimizzazioneOFF è il servizio da utilizzare per la disattivazione dell’anonimizzazione nelle successive transazioni di query e notifiche fra il nodo richiedente e ASR-EMPI.
SCENARIO DI ESEMPIO: Non applicabile.
4.2.10 Descrizione dati anagrafici
Vengono riportati nella prima tabella a seguire i dati anagrafici gestiti da ASR-EMPI e inviati nei messaggi supportati dal protocollo di integrazione HL7.
Tali dati sono comuni a tutti i servizi anagrafici supportati dalla piattaforma, per questo motivo vengono descritti una tantum in questo paragrafo.
Si evidenziano con sfondo colorato i dati identificativi e amministrativi dell’assistito necessari per la gestione del FSE regionale che sono rappresentati nelle Linee guida (rif. Schema DPCM attuativo, art. 22 e Allegato Disciplinare Tecnico art. 3).
Nella tabella “Localizzazione HL7” la colonna “Riferimento a segmento HL7 V2.5” riporta la localizzazione dell’informazione anagrafica all’interno dei messaggi strutturati secondo lo standard HL7 V2.5, la colonna “Riferimento a TAG HL7 V3” riporta la localizzazione dell’informazione anagrafica all’interno dei messaggi strutturati secondo lo standard HL7 V3.
Dati anagrafici gestiti da ASR-EMPI | |||
Nome campo | Descrizione | Caratteristiche | Dimensionamento |
CHIAVE IDENTIFICATIVA | Chiave identificativa unica regionale del profilo anagrafico (GUIDFSE) | Obbligatorio se registrato in ASR | Alfanumerico (16) |
COGNOME | Cognome | Obbligatorio | Alfanumerico (50) |
NOME | Nome | Obbligatorio | Alfanumerico (50) |
SESSO | Sesso Assume i valori M o F | Obbligatorio | Alfanumerico (1) |
DATA NASCITA | Data di nascita | Obbligatorio | Data [YYYYMMGG] |
COMUNE NASCITA | codice ISTAT del comune di nascita (concatenazione di provincia nascita e comune nascita, rif. CATALOGO COMUNI E STATI ESTERI) | Obbligatorio | Numerico (6) |
CODICE FISCALE | Codice Fiscale | Obbligatorio (vedi note relative) | Alfanumerico (16) |
DATA DECESSO | Data decesso | Facoltativo | Data [YYYYMMGG] |
SCADENZA ASSISTENZA | Data Scadenza tessera sanitaria | Facoltativo | Data [YYYYMMGG] |
NAZIONALITA’ | Codice nazionalità (rif. CATALOGO NAZIONALITA) | Obbligatorio | Alfanumerico (3) |
RESIDENZA COMUNE | Codice ISTAT del comune o stato estero di residenza (concatenazione provincia comune di residenza, rif. CATALOGO COMUNI E STATI ESTERI) | Obbligatorio | Numerico (6) |
RESIDENZA LOCALITA’ | Località di residenza | Facoltativo | Alfanumerico (50) |
RESIDENZA INDIRIZZO | Indirizzo di residenza | Facoltativo | Alfanumerico (50) |
RESIDENZA CAP | CAP | Facoltativo | Alfanumerico (5) |
RESIDENZA REGIONE | Codice Regione (rif. CATALOGO REGIONI) | Facoltativo | Numerico (3) |
RESIDENZA PROVINCIA | Sigla Provincia | Facoltativo | Alfanumerico (2) |
DOMICILIO COMUNE | codice ISTAT del comune di domicilio sanitario (concatenazione provincia comune di domicilio, rif. CATALOGO COMUNI E STATI ESTERI) | Tutti Facoltativi; o tutti compilati o nessuno (la località rimane comunque sempre facoltativa) | Numerico (6) |
DOMICILIO LOCALITA’ | Località di domicilio | Alfanumerico (50) | |
DOMICILIO INDIRIZZO | Indirizzo di domicilio | Alfanumerico (50) | |
DOMICILIO CAP | CAP | Alfanumerico (5) | |
DOMICILIO REGIONE | Codice Regione di assistenza sanitaria (rif. CATALOGO REGIONI) | Numerico(3) | |
DOMICILIO PROVINCIA | Sigla Provincia | Alfanumerico (2) | |
Dati anagrafici gestiti da ASR-EMPI | |||
Nome campo | Descrizione | Caratteristiche | Dimensionamento |
ASL ASSISTENZA | Codice ASL di assistenza sanitaria (rif. CATALOGO ASL) | Obbligatorio | Numerico (4) |
ASL RESIDENZA | Codice ASL di residenza (rif. CATALOGO ASL) | Obbligatorio | Numerico (4) |
RECAPITI TELEFONICI | Telefono 1 | Facoltativo | Alfanumerico (20) |
Telefono 2 | Facoltativo | Alfanumerico (20) | |
STATO CIVILE | Codice dello stato civile (rif. CATALOGO STATI CIVILI) | Facoltativo | Numerico (2) |
PROFESSIONE | Professione (rif. CATALOGO PROFESSIONI) | Facoltativo | Numerico (5) |
TITOLO STUDIO | Titolo di studio (rif. CATALOGO TITOLI DI STUDIO) | Facoltativo | Numerico (2) |
CERTIFICAZIONE ANAGRAFICA | Indicazione della certificazione del dato, può assumere i seguenti valori : ASL = dati sanitari certificati da ASUR COM = dati residenza certificati da INA- SAIA (ANPR) MEF = codice fiscale e dati che lo compongono certificati da SistemaTS | Facoltativo | Alfanumerico (3) |
TESSERA TEAM | PIN (per paziente straniero) | Tutti Facoltativi; o tutti compilati o nessuno | Alfanumerico (20) |
CIN (Card IdentificationNumber) | Alfanumerico (20) | ||
Istituzione (Codice) | Alfanumerico (10) | ||
Istituzione (Descrizione) | Alfanumerico (21) | ||
Nazione | Alfanumerico (2) | ||
Data scadenza TEAM | Data [YYYYMMGG] | ||
DATI STP | Codice STP | Tutti Facoltativi; o tutti compilati o nessuno | Alfanumerico (16) |
Data rilascio del codice STP | Data [YYYYMMGG] | ||
Indicazione di indigenza | Alfanumerico (1) | ||
DATI NUCLEO FAMIGLIARE | Codice nucleo famigliare | Tutti Facoltativi; o tutti compilati o nessuno | Alfanumerico (20) |
Ruolo all’interno del nucleo famigliare (rif. CATALOGO RUOLI NUCLEO FAMILIARE) | Numerico (2) | ||
DATI MEDICO SCELTO | Codice regionale medico base (chiave interna derivata da ARCA-ASUR) | Tutti Facoltativi; o tutti compilati o nessuno (la data di revoca rimane sempre comunque facoltativa) | Alfanumerico (16) |
Codice fiscale medico base | Alfanumerico (16) | ||
Cognome medico base | Alfanumerico (50) | ||
Nome medico base | Alfanumerico (50) | ||
Codice della tipologia del medico di base (identifica se MMG o PLS) | Numerico (2) | ||
Dati anagrafici gestiti da ASR-EMPI | |||
Nome campo | Descrizione | Caratteristiche | Dimensionamento |
(rif. CATALOGO TIPI MEDICO) | |||
Data scelta del medico di base | Data [YYYYMMGG] | ||
Data revoca dal medico di base | Data [YYYYMMGG] | ||
DATI ESENZIONE PATOLOGIA e/o REDDITO | Codici ISTAT dell’esenzione (rif. CATALOGO MOTIVI ESENZIONE) | Facoltativo | Alfanumerico (15) |
Data di scadenza del motivo esenzione | Facoltativo | Data [YYYYMMGG] | |
NODO COLLEGATO | Codice nodo inviante; la codifica viene stabilita in accordo fra Fornitori della piattaforma ASR-EMPI e nodo cooperante | Obbligatorio | Alfanumerico (8) |
Nel caso di Notifica Utilizzo di anagrafica, il nodo inviante deve anche informare ASR-EMPI a quale altro nodo notificare l’eventuale successivo censimento mediante la stringa “NOT+SIGLA” dove SIGLA identifica il nodo ricevente (esempio: NOT-ARCA) | Facoltativo | Alfanumerico (8) | |
Localizzazione HL7 | ||||||
Nome campo | Sottodefiniz ioni | Riferimento a segmento XX0 X0.0 | Riferimento a TAG HL7 V3 | |||
Class | Valu e Attri bute | Find Attribute | ||||
CHIAVE IDENTIFICATIVA | GUIDFSE di ASR-EMPI | PID | 3 | xxXxxxxXXx.xx | exten sion | root='APC' |
Local-ID su nodo integrato | root='...' | |||||
COGNOME | PID | 5.1 | xxxxxxXxxxxxxXxxx.xxxxx.xxxxxx | |||
NOME | PID | 5.2 | livingSubjectName.value.given | code | ||
SESSO | PID | 8 | administrativeGenderCode | value | ||
DATA NASCITA | PID | 7 | birthTime | |||
COMUNE NASCITA | codice ISTAT | PID | 11.9 | livingSubjectBirthPlaceAddress.v xxxx.xxxxxxx | ||
descrizione | livingSubjectBirthPlaceAddress.v xxxx.xxxx | |||||
sigla provincia | livingSubjectBirthPlaceAddress.v alue.county | |||||
CODICE FISCALE | PID | 3.1 | xxXxxxxXXx.xx | exten sion | root='2.16.840.1.113 883.2.9.4.3.2' | |
DATA DECESSO | PID | 29 | deceasedTime | value | ||
Localizzazione HL7 | |||||
Nome campo | Sottodefiniz ioni | Riferimento a segmento XX0 X0.0 | Riferimento a TAG HL7 V3 | ||
Class | Valu e Attri bute | Find Attribute | |||
SCADENZA ASSISTENZA | PID 3.8 | asOtherIDs.effectiveTime.high | value | ||
NAZIONALITA’ | Codice | PID 26 | asCitizen.politicalNation | code | |
Descrizione | name | ||||
RESIDENZA COMUNE | Codice Stato | PID 11.9 | xxxx.xxxxxxx | use='H' | |
Codice ISTAT comune | addr.censusTrack | ||||
Descrizione comune | xxxx.xxxx | ||||
RESIDENZA LOCALITA’ | PID 11.2 | ||||
RESIDENZA INDIRIZZO | PID 11.1 | addr.streetAddressLine | use='H' | ||
RESIDENZA CAP | PID 11.5 | addr.postalCode | use='H' | ||
RESIDENZA REGIONE | PID 11.8 | ||||
RESIDENZA PROVINCIA | PID 11.4 | addr.county | use='H' | ||
DOMICILIO COMUNE | Codice Stato | PID 11.9 | xxxx.xxxxxxx | use='HP' | |
Codice ISTAT comune | addr.censusTrack | ||||
Descrizione comune | xxxx.xxxx | ||||
DOMICILIO LOCALITA’ | PID 11.2 | ||||
DOMICILIO INDIRIZZO | PID 11.1 | addr.censusTrack | use='HP' | ||
DOMICILIO CAP | PID 11.5 | addr.postalCode | use='HP' | ||
DOMICILIO REGIONE | PID 11.8 | ||||
DOMICILIO PROVINCIA | PID 11.4 | addr.county | use='HP' | ||
ASL ASSISTENZA | PD1 3 | ||||
ASL RESIDENZA | PD1 3 | ||||
RECAPITI TELEFONICI | Telefono 1 | PID 13 | Telecom | value | use='H' |
Telefono 2 | PID 13 | Telecom | value | use='HP' | |
Localizzazione HL7 | |||||
Nome campo | Sottodefiniz ioni | Riferimento a segmento XX0 X0.0 | Riferimento a TAG HL7 V3 | ||
Class | Valu e Attri bute | Find Attribute | |||
STATO CIVILE | PID 16 | maritalStatusCode | code | codeSystem='2.16.84 0.1.113883.5.2' | |
PROFESSIONE | NK1 10 | ||||
TITOLO STUDIO | PID 5.6 | ||||
CERTIFICAZIONE ANAGRAFICA | PID 32 | asOtherIDs.statusCode | code | ||
TESSERA TEAM | PIN (per paziente straniero) | PID 3.1 | |||
CIN (Card Identification Number) | PID 3.1 | ||||
Istituzione (Codice) | PID 3.4.1 | ||||
Istituzione (Descrizione) | PID 3.4.1 | ||||
Nazione | PID 3.6.1 | ||||
Data scadenza TEAM | PID 3.8 | ||||
DATI STP | Codice STP | PID 3.1 | xxXxxxxXXx.xx | exten sion | root='STP' |
Data rilascio del codice STP | PID 3.7 | asOtherIDs.effectiveTime.low | value | ||
Indicazione di indigenza | PD1 1 | ||||
Data scadenza STP | asOtherIDs.effectiveTime.high | value | |||
DATI NUCLEO FAMIGLIARE | Codice | NK1 33 | |||
Ruolo | NK1 3 | ||||
DATI MEDICO SCELTO | Codice regionale medico base | PV1 7.1 / ROL 3 | |||
Codice fiscale medico base | PV1 7.1 | careProvision.performer.xxxxxxx xXxxxxxxx.xx | exten sion | root='2.16.840.1.113 883.2.9.4.3.2' | |
Localizzazione HL7 | |||||
Nome campo | Sottodefiniz ioni | Riferimento a segmento XX0 X0.0 | Riferimento a TAG HL7 V3 | ||
Class | Valu e Attri bute | Find Attribute | |||
Cognome medico base | PV1 7.2 | careProvision.performer.assigne xXxxxxxxx.xxxx | |||
Nome medico base | PV1 7.3 | ||||
Codice della tipologia del medico di base (identifica se MMG o PLS) | ROL 3 | ||||
Data scelta del medico di base | ROL 4 | careProvision.performer.assigne dProvider.low | value | ||
Data revoca dal medico di base | ROL 5 | careProvision.performer.xxxxxxx xXxxxxxxx.high | value | ||
DATI ESENZIONE PATOLOGIA e/o REDDITO | Codici ISTAT dell’esenzion e | PV1 20.1 | coverageRecord.component.poli cyOrProgram.code | code | |
Descrizione del motivo esenzione | coverageRecord.component.poli cyOrProgram.definition.coverag eDefinition.text | ||||
Data di rilascio del motivo esenzione | coverageRecord.component.poli cyOrProgram.effectiveTime.low | value | |||
Data di scadenza del motivo esenzione | PV1 20.2 | coverageRecord.component.poli cyOrProgram.effectiveTime.high | value | ||
NODO COLLEGATO | Codice nodo inviante | MSH-3 | <hl7:Creator> della busta soap | ||
Nel caso di Notifica Utilizzo di anagrafica, il nodo inviante deve anche informare ASR-EMPI a quale altro nodo | EVN 4 | ||||
Localizzazione HL7 | |||||
Nome campo | Sottodefiniz ioni | Riferimento a segmento XX0 X0.0 | Riferimento a TAG HL7 V3 | ||
Class | Valu e Attri bute | Find Attribute | |||
notificare l’eventuale successivo censimento mediante la stringa “NOT+SIGLA ” dove SIGLA identifica il nodo ricevente (esempio: NOT-ARCA) | |||||
Note sulla gestione del PAZIENTE ANONIMO
In caso di censimento di un paziente ANONIMO si possono registrare dati fittizi compilando un dataset ridotto
così identificato: COGNOME, NOME, SESSO, DATA_NASCITA, COMUNE_NASCITA,
COMUNE_RESIDENZA [N.B. il CODICE FISCALE non deve essere valorizzato]. Ovvero :
NOME=ANOMINO, COGNOME=#progressivo, SESSO=M/F, DATA NASCITA=fittizia (es. 1/1/1900), COMUNE-NASCITA=999888, COMUNE-RESIDENZA=999888.
Alla posizione anagrafica verrà assegnata quindi una chiave identificativa nell’anagrafica aziendale di riferimento.
Nel caso di una successiva variazione anagrafica (con i dati effettivi del paziente), le informazioni aggiornate vengono recepite da ASX di riferimento e propagata ai dipartimentali aziendali interessati alla ricezione della modifica, parimenti ASX procede al censimento su ASR.
Note sulla obbligatorietà del CODICE FISCALE
In alcuni casi non è prevista l’esistenza del codice fiscale (es. STP, ENI, nuovi nati in attesa di attribuzione) o non è possibile raccogliere il dato in fase di identificazione anagrafica (es. pazienti in PS non riconoscibili). Limitatemente a queste casistiche è tollerata l’assenza del codice fiscale.
ASR-EMPI restituirà il GUIDFSE solo nei seguenti casi:
- STP / ENI certificati da ASUR;
- nuovi nati in attesa di attribuzione, con i 5 tratti fondamentali (nome, cognmome, data nascita, sesso, comune di nascita) valorizzati correttamente solo se certificati ASUR.
Note sulla ANONIMIZZAZIONE / DEANONIMIZZAZIONE del profilo anagrafico
In caso di anonimizzazione del profilo anagrafico, vengono utilizzati da ASR-EMPI anche i seguenti codici univoci debitamente ed appositamente generati quando previsti dai relativi servizi :
- ID-Anonimizzazione = stringa alfanumerica di 16 caratteri composta da “ID”+14 caratteri del codice univoco di anonimizzazione;
- ID-Richiesta = numerico di 16 cifre;
- GUIDFSE anonimizzato = ID-Anonimizzazione
- Cognome anonimizzato = “CO”+14 caratteri del codice univoco di anonimizzazione;
- Nome anonimizzato = “NO”+14 caratteri del codice univoco di anonimizzazione;
- Codice Fiscale anonimizzato = “CF”+14 caratteri del codice univoco di anonimizzazione.
4.2.11 Descrizione dati dei cataloghi
Per la descrizione dei cataloghi si rimanda a quanto contenuto nel relativo documento allegato.
4.2.12 Tavola sinottica servizi – standard HL7
Si riporta in seguito una tabella riepilogativa dei servizi rilasciati dal progetto e relativi riferimenti allo standard HL7.
Tali servizi sono gestiti con la stessa modalità di trasporto indipendentemente dallo stadard di riferimento.
Servizi del progetto | Standard HL7 V3 | Standard HL7 V2 |
Servizio di ricerca anagrafica | XXXX_XX000000XX XXXX_XX000000XX PRPA_IN201307UV PRPA_IN201308UV PRPA_IN201309UV PRPA_IN201310UV | QRY^A19 ADR^A19 |
Servizio di censimento nuova anagrafica | PRPA_IN201311UV PRPA_IN201312UV- PRPA_IN101313UV | ADT^A28 |
Servizio di aggiornamento di una anagrafica | PRPA_IN201314UV PRPA_IN201315UV- PRPA_IN201316UV | ADT^A31 |
Notifica eventi ai nodi cooperanti (censimento) | PRPA_IN201301UV | ADT^A28 |
Notifica eventi ai nodi cooperanti (variazione, utilizzo di una anagrafica) | PRPA_IN201302UV PRPA_IN201303UV | ADT^A31 |
Servizio di unificazione di anagrafiche | PRPA_IN201304UV02 | ADT^A40 |
Servizio di aggiornamento cataloghi centralizzati | Non previsto | MFN^M13 |
Notifica di variazione catalogo | Non previsto | MFN^M13 |
Servizio di anonimizzazione | Non previsti da HL7. I servizi forniti sono servizi XML proprietari di ASR- EMPI e sostituiscono in toto gli analoghi precedentemente forniti dall’impianto IRUW regionale. | |
Servizio di deanonimizzazione | ||
Approfondimenti relativi alla tecnologia HL7 V3
Per la tecnologia HL7 V3 si riporta in seguito un approfondimento sugli scenari previsti dallo standard :
Interfaccia ASR-EMPI gestito | prevista per / processo | Scenari HL7 V3 rif. PRPA_Patient_Topic-v1.2-S 08/02/2011 | HL7Italia- .doc del | Servizi HL7 V3 rif. capitolato | |
Richiesta | di | censimento di un nuovo | |||
paziente (PRPA_IN201311UV | |||||
Aggiornamento XXX-XXXX | XXXX_XX000000XX-XXXX_XX000000XX) | UpdateDaArca() | |||
da Xxxx | |||||
Xxxxxxxxx di cambiamento dei dati | |||||
anagrafici di paziente (PRPA_IN201314UV | |||||
PRPA_IN201315UV-PRPA_IN201316UV) | UpdateDaArca() | ||||
Richiesta di censimento di un nuovo | |||||
Aggiornamento ASR-EMPI da Asx / Verticale Regionale | paziente (PRPA_IN201311UV PRPA_IN201312UV-PRPA_IN101313UV) | UpdateDaAsx() | |||
Richiesta di cambiamento dei dati anagrafici di paziente (PRPA_IN201314UV | |||||
PRPA_IN201315UV-PRPA_IN201316UV) | UpdateDaAsx() | ||||
Non esistendo nella implementazione HL7 | |||||
Notifica anagrafica | di | utilizzo | V3 una interazione dedicata, si è ricondotto alla “Notifica di cambiamento dati anagrafici e dati sanitari di un paziente | ||
(PRPA_IN201302UV)” | SendVariazioni() | ||||
Notifica di censimento di nuovo paziente | |||||
(PRPA_IN201301UV) | SendVariazioni() | ||||
Notifica di cambiamento dati anagrafici e | |||||
dati sanitari di un paziente | |||||
Sincronizzazione ARCA e | (PRPA_IN201302UV) | SendVariazioni() | |||
MPI Locali da ASR-EMPI | Notifica di riconciliazione | di | posizioni | ||
anagrafiche | pazienti | ||||
(PRPA_IN201304UV02) | ConciliaDati() | ||||
Notifica di annullamento di posizioni | |||||
anagrafiche pazienti (PRPA_IN201303UV) | SendVariazioni() | ||||
Ricerca paziente per tratti anagrafici acquisiti (PRPA_IN201305UV PRPA_IN201306UV) | FindAnagrafica() GetAnagraficaStorica() | ||||
Interrogazione dati anagrafici completi di | |||||
Ricerca anagrafica su ASR-EMPI | un paziente individuato da codice identificativo (PRPA_IN201307UV | GetAnagrafica() | |||
PRPA_IN201308UV) | |||||
Interrogazione identificativi alternativi di un paziente (PRPA_IN201309UV PRPA_IN201310UV) | FindAnagrafica() GetAnagraficaStorica() | ||||
In seguito la tavola sinottica che confronta gli scenari dello standard HL7 v3 con i servizi implementati dal progetto :
Servizi del progetto | Descrizione Servizio | WS implementati | Scenari HL7 V3 rif. HL7Italia- PRPA_Patient_Topic-v1.2- S.doc del 08/02/2011 |
Ricerca | Ricerca paziente per tratti anagrafici acquisiti | AssistitiElencoRequest | PRPA_IN201305UV PRPA_IN201306UV |
Ricerca | Interrogazione dati anagrafici completi di un paziente individuato da codice identificativo | AssistitoRequest | PRPA_IN201307UV PRPA_IN201308UV |
Ricerca | Interrogazione identificativi alternativi di un paziente | AssistitoRequest | PRPA_IN201309UV PRPA_IN201310UV |
Ricerca | Ricerca delle Variazioni occorse su un profilo Anagrafico in un Periodo di Riferimento | VariazioniElencoRequest | PRPA_IN201307UV |
Censimento | Richiesta di censimento di un nuovo paziente | AssistitoSet | PRPA_IN201311UV PRPA_IN201312UV- PRPA_IN101313UV |
Modifica | Richiesta di cambiamento dei dati anagrafici di paziente | AssistitoSet | PRPA_IN201314UV PRPA_IN201315UV- PRPA_IN201316UV |
Unificazione | Richiesta di unificazione di due profili Anagrafici | AssistitoSet | non previsto |
Notifica di Censimento | Notifica di censimento di nuovo paziente | AssistitoSet | PRPA_IN201301UV |
Notifica di variazione | Notifica di cambiamento dati anagrafici e dati sanitari di un paziente | AssistitoSet | PRPA_IN201302UV |
Notifica di Unificazione | Notifica di riconciliazione di posizioni anagrafiche pazienti | AssistitoSet | PRPA_IN201304UV02 |
Notifica di Cancellazione | Notifica di annullamento di posizioni anagrafiche pazienti | AssistitoSet | PRPA_IN201303UV |
Approfondimenti relativi ai servizi di anonimizzazione / deanonimizzazione
Per quanto concerne i servizi di anonimizzazione / deanonimizzazione si faccia riferimento al seguente schema :
Servizi del progetto | Descrizione Servizio | WS implementati |
Anonimizzazione | Restituzione di un ID-Anonimizzato (o di una lista) a fronte di un GUIDFSE (o di una lista di GUIDFSE) | AnonimizzazioneEncode |
Anonimizzazione | Attivazione dell’anonimizzazione di un profilo anagrafico; si usa per manifestare la volontà di rendere anonimo il profilo per le | AnonimizzazioneOn |
successive transazioni di Query e Notifiche fra ASR-EMPI e il nodo richiedente | ||
Deanonimizzazione | Richiesta di deanonimizzazione di un ID- Anonimizzato (o di una lista) | AnonimizzazioneDecode |
Deanonimizzazione | Disattivazione dell’anonimizzazione di un profilo anagrafico; si usa per manifestare la volontà di riportare in chiaro i dati del profilo per le successive transazioni di Query e Notifiche fra ASR-EMPI e il nodo richiedente | AnonimizzazioneOff |
Inoltre ASR-EMPI offre ai propri amministratori i seguenti reports :
• ANONIMIZZAZIONE DECODE REPORT (ELENCO RICHIESTE) : elenco delle richieste di deanonimizzazione pervenute tramite il servizio AnonimizzazioneDecode .
• ANONIMIZZAZIONE DECODE REPORT (DEANONIMIZZAZIONE) : l'amministratore parte da ID- richiesta ed effettua la relative deanonimizzazione, ovvero ottiene un report con I dati in chiaro (trasformazione di un elenco di ID-Anonimizzati nei corrispondenti GUIDFSE, Cognome, Nome, CF).
Gestione consenso
CA
Profilazione
Verifica permessi FSE
<<include>>
Firma remota
<<include>>
Utente
Autenticazione
<<include>>
<<include>>
<<include>>
Archivia documento
ApplicativoVerticale
Repository
Indicizza metadati
Versamento
<<include>> Pol
Registry
<<include>>
Log
Invia notifica
<<include>>
RicercaAnagrafica
Figura 21: Caso d’uso – Alimentazione Dati e Documenti
o Conservazione
CASO D’USO: la figura sopra riportata illustra il caso d’uso dell’archiviazione di un documento, indipendentemente da chi sia il Document Producer (MMG o gestionale aziendale) e da quale sia il repository di riferimento (nodo regionale o locale). L’archiviazione di un documento è possibile solo previa autenticazione e verifica delle autorizzazioni dell’utente; l’indicizzazione del documento nel registry regionale, che ne comporta l’inserimento nel FSE, è possibile solo se il cittadino ha espresso un consenso positivo alla costituzione e all’alimentazione del suo fascicolo.
Le attività di archiviazione comprendono:
- la verifica che l’utente abbia l’autorizzazione per richiedere l’archiviazione
- i servizi di firma: firma remota e verifica firma (servizi esposti dal repository)
- il versamento del documento al polo di conservazione regionale (a cura del repository regionale o aziendale)
- l’indicizzazione del documento nel registry in base al consenso positivo alla costituzione e alimentazione espressa dal cittadino
I servizi di indicizzazione comprendono:
- la ricerca anagrafica
- il log dell’operazione effettuata
- l’eventuale notifica sulla disponibilità del documento ad attori interessati.
ATTORI: di seguito l’elenco degli attori previsti:
Nome | Descrizione |
Utente | Utente del sistema FSE a livello regionale o aziendale (MMG/PLS, medico specialista, operatore, ecc.) |
ApplicativoVerticale | Identifica qualsiasi sistema applicativo in uso presso le Aziende Sanitarie e Ospedaliere marchigiane (ad es. sistemi LIS, RIS, ecc.) e deputato ad interagire con il repository aziendale o FSE |
Repository | Sistema per l’archiviazione documentale di livello regionale (FSE) o aziendale (CDR) |
Registry | Sistema per l’indicizzazione dei documenti presenti sul Repository regionale (FSE) o aziendale (CDR) |
Polo Conservazione | Sistema regionale di conservazione documentale |
4.3.1 Servizio di Firma Digitale Remota
DESCRIZIONE: consente ad un sistema verticale la firma di uno o più documenti elettronici in esso prodotti, in modo trasparente rispetto alla Certification Autority prevista. E' un servizio disponibile sia sul dominio regionale che sui domini locali sullo strato di software messo a disposizione dal Repository e si frappone fra il consumer ed il servizio della CA corrispondente. La chiamata al servizio di firma è tendenzialmente propedeutica all’archiviazione del documento nel repository (l’archiviazione tipicamente è evento implicito conseguente ma non sincrono con la firma digitale).
Nota importante: la chiamata multipla (più documenti in firma in una sola transazione) può essere utilizzata solo per un numero limitato di documenti, tendenzialmente qualche decina ma dipendentemente anche dalla dimensione dei documenti stessi.
FLUSSO: l’utente può procedere alla firma digitale del documento che prevede l’invio del documento nella request del servizio. Il Servizio di Firma Remota verificherà le credenziali e la presenza dei dati obbligatori; in caso positivo, verrà girata una chiamata al “servizio” messo a disposizione dalla CA (attualmente servizio ARUBA). Se vengono firmati più documenti in una chiamata (firma multipla), tali passi saranno eseguiti èer ognuno dei documenti passati. In particolare, il Modulo Documentale di cui il Repository Aziendale è parte integrante, rende disponibile una funzionalità remota di firma digitale e marcatura temporale, basata sull’utilizzo in back end di servizi o librerie di firma messi a disposizione dalla Certification Autority aziendale.
Il servizio esposto dal modulo documentale realizza le seguenti operazioni:
- firma di un documento con l’utilizzo dei certificati/servizi messi a disposizione dalla Certification Autority ed eventuale marcatura temporale se richiesta.
- Restituzione del documento firmato e “marcato” al chiamante.
Si precisa che se il formato del documento trasmesso è un pdf, il servizio restituisce un pdf firmato che ha in aggiunta la dicitura “documento firmato da ecc….” in fondo al documento, che è necessaria per la stampa.
Se si tratta di una busta MIME con XML-CDA2 + XSL, il foglio di stile (XSL) prodotto dal source deve già prevedere il fatto che se nel CDA2 viene valorizzato il LegalAutenticator, viene aggiunta la medesima scritta in fondo al PDF quando si facesse la renderizzazione. Sarà il servizio di firma che valorizzerà il LegalAutenticator nel CDA2 e restituirà la busta firmata p7m.
Per maggiori informazioni sul formato dell’imbustamento restituito, si faccia riferimento alle specifiche del servizio della CA.
DATI SCAMBIATI: Di seguito sono descritti i tipi dei parametri utilizzati dai web services del Modulo Documentale raggruppati in campi relativi all’utente, parametri di chiamata, ecc. Per la struttura degli argomenti della chiamata che si compongono dei tipi di parametri di seguito descritti si faccia riferimento al par. 5.3.1.
Descrizione del tipo UserInfo
Nome Campo | Descrizione | Caratteristiche |
username | User assegnato al sistema chiamante | Obbligatorio |
rolCode | Valorizzare con “2” | Obbligatorio |
password | Password assegnata al sistema chiamante | Obbligatorio |
lang | Lingua del documento (mettere it) |
Descrizione del tipo Params
Nome Campo | Descrizione | Caratteristiche |
Patient | Di tipo Patient e contiene le informazioni del Paziente | Obbligatorio |
Encounter | Di tipo Encounter e contiene le informazioni sull'episodio | |
Prescription | Di tipo Prescription e contiene le prescrizioni associate all'evento | |
Document | Di tipo Document e contiene i metadati del documento e il documento | Obbligatorio |
Descrizione del tipo Patient
Nome Campo | Descrizione | Caratteristiche |
mpi | ID anagrafe aziendale (MPI Locale) | Obbligatorio |
familyName | ||
givenName | ||
sex | ||
birth Date | ||
countryBirthPlace | ||
fiscalCode | ||
primaryLanguage |
Descrizione del tipo Encounter
Per il servizio di Firma non è necessario nessuna delle sue componenti
Nome Campo | Descrizione | Caratteristiche |
patientClass |
visitNumber | ||
pendingLocation | ||
altrenateVisitId |
Descrizione del tipo Prescription
Per il servizio di Firma non è necessario nessuna delle sue componenti
Nome Campo | Descrizione | Caratteristiche |
placerGroupNumber | ||
timingQuantity | ||
transactionDateTime | ||
enteringOrganization | ||
universalServiceIdentifier | ||
relevantClinicalInfo | ||
placerField1 | ||
placerField2 | ||
reasonForStudy | ||
procedureCode | ||
resultHandling |
Descrizione del tipo Document
Nome Campo | Descrizione | Caratteristiche |
documentType | Tipologia del documento (TXA-2) Referto - Referto SchedaOperatoria - Scheda operatoria LetteraDimissione - Lettera di dimissione VerbalePS - Verbale di pronto soccorso Ecc. | Obbligatorio |
documentContentPresentation | Formato del documento (TXA-3): CDA2_XSL_PKCS7 se CDA2 contenuto in mime firmato secondo le specifiche di seguito riportate CDA2_XSL se CDA2 contenuto in mime non firmato secondo le specifiche di seguito riportate PDF_PKCS7 se formato PDF firmato CAdES PDF_ADOBE se formato PDF firmato PadES PDF se formato PDF non firmato CDA2 se CDA2 “puro” CDA2_PKCS7 se CDA2 “puro” firmato CAdES OOXML ODF TXT | Obbligatorio |
XML DOC HTML XLS GIF JPG BMP TIF EPS SVG MP3 WAV MPG MPEG AVI WMV EXE SMTP/MIME | ||
activityDateTime | Data ora produzione del Documento (TXA-4) nel formato yyyy-MM-ddTHH:mm:ss | Obbligatorio |
originatorCodeName | Obbligatorio | |
applicationOwner | Nome dell'applicativo (da concordare) assieme all’uniqueDocumentNumber identifica in maniera univoca il documento | Obbligatorio |
uniqueDocumentNumber | Chiave univoca ed invariante nel tempo del documento sull’applicativo d’origine | Obbligatorio |
parentDocumentNumber | Chiave univoca sull’applicativo d’origine del documento padre | |
placerOrderNumber | ||
fillerOrderNumber | ||
documentCompletionStatus | Valorizzare con “DO” (documento validato) | |
documentConfidentiality | ||
content | Contenuto del documento | Obbligatorio |
conclusion | ||
pathology | ||
outcome | ||
text |
Descrizione del tipo SignerInfo
Nome Campo | Descrizione | Caratteristiche |
signer | Utente con certificato di firma presente nel sistema CA | Obbligatorio |
Pin | Password utente associato al certificato di firma presente nel sistema CA | Obbligatorio |
OTP | Token generato/ottenuto all’atto di firma | Obbligatorio |
signType | CAdES PAdES XAdES | Obbligatorio |
customerInfo | Descrizione utente Cognome + Nome dell'utente che firma |
STANDARD: XML
SCENARIO DI ESEMPIO:
Si riporta di seguito il diagramma di sequenza relativo al caso del servizio di firma remota sopra descritto.
ApplicativoVerticale
Repository
CA Service
rvizio di firma con invio d
1 : Chiama Se ocumento()
2 : Verifica credenziali()
3 : Chiama servizio CA Aruba con invio documento()
: K
O: credenziali non valid
4 e()
5 : Firma digitale remota()
6 : Ritorna documento firmato()
7
Figura 22: sequence diagram – Firma digitale remota
4.3.2 Servizio di Firma Digitale Remota “reiterata”
DESCRIZIONE: consente, in modo trasparente rispetto alla Certification Autority prevista, ad un sistema verticale la firma di un numero elevato di documenti elettronici in esso prodotti in un’unica sessione aperta con il servizio di firma. E' un servizio disponibile sia sul dominio regionale che sui domini locali sullo strato di software messo a disposizione dal Repository e si frappone fra il consumer ed il servizio della CA corrispondente. La chiamata al servizio di firma è tendenzialmente propedeutica all’archiviazione del documento nel repository (l’archiviazione tipicamente è evento implicito conseguente ma non sincrono con la firma digitale).
FLUSSO: valgono le stesse informazioni contenute nel capitolo 4.3.1, con alcune peculiarità; in questo caso al servizio possono essere fatte più chiamate consecutive ciascuna relativa ad un singolo documento o a più documenti, condividendo fra una chiamata e l’altra un id di sessione; questo consente ad esempio a fronte di una richiesta di credenziali (es token) all’utente, di firmare un numero elevato di documenti; c’è un parametro in più da passare che indica se si tratta della prima chiamata di una sequenza, se è una intermedia o se è l’ultima in modo da dare l’informazione al servizio di quando aprire o chiudere la sessione.
.
DATI SCAMBIATI: Di seguito sono descritti i tipi dei parametri utilizzati dai web services del Modulo Documentale raggruppati in campi relativi all’utente, parametri di chiamata, ecc. Per la struttura degli
argomenti della chiamata che si compongono dei tipi di parametri di seguito descritti si faccia riferimento al par. 5.3.2.
Descrizione del tipo UserInfo
Nome Campo | Descrizione | Caratteristiche |
username | User assegnato al sistema chiamante | Obbligatorio |
rolCode | Valorizzare con “2” | Obbligatorio |
password | Password assegnata al sistema chiamante | Obbligatorio |
lang | Lingua del documento (mettere it) |
Descrizione del tipo Params
Nome Campo | Descrizione | Caratteristiche |
Patient | Di tipo Patient e contiene le informazioni del Paziente | Obbligatorio |
Encounter | Di tipo Encounter e contiene le informazioni sull'episodio | |
Prescription | Di tipo Prescription e contiene le prescrizioni associate all'evento | |
Document | Di tipo Document e contiene i metadati del documento e il documento | Obbligatorio |
Descrizione del tipo Patient
Nome Campo | Descrizione | Caratteristiche |
mpi | ID anagrafe aziendale (MPI Locale) | Obbligatorio |
familyName | ||
givenName | ||
sex | ||
birth Date | ||
countryBirthPlace | ||
fiscalCode | ||
primaryLanguage |
Descrizione del tipo Encounter
Per il servizio di Firma non è necessario nessuna delle sue componenti
Nome Campo | Descrizione | Caratteristiche |
patientClass | ||
visitNumber | ||
pendingLocation | ||
altrenateVisitId |
Descrizione del tipo Prescription
Per il servizio di Firma non è necessario nessuna delle sue componenti
Nome Campo | Descrizione | Caratteristiche |
placerGroupNumber | ||
timingQuantity | ||
transactionDateTime | ||
enteringOrganization | ||
universalServiceIdentifier | ||
relevantClinicalInfo | ||
placerField1 | ||
placerField2 | ||
reasonForStudy | ||
procedureCode | ||
resultHandling |
Descrizione del tipo Document
Nome Campo | Descrizione | Caratteristiche |
documentType | Tipologia del documento (TXA-2) Referto - Referto SchedaOperatoria - Scheda operatoria LetteraDimissione - Lettera di dimissione VerbalePS - Verbale di pronto soccorso Ecc. | Obbligatorio |
documentContentPresentation | Formato del documento (TXA-3): CDA2_XSL_PKCS7 se CDA2 contenuto in mime firmato secondo le specifiche di seguito riportate CDA2_XSL se CDA2 contenuto in mime non firmato secondo le specifiche di seguito riportate PDF_PKCS7 se formato PDF firmato CAdES PDF_ADOBE se formato PDF firmato PadES PDF se formato PDF non firmato CDA2 se CDA2 “puro” CDA2_PKCS7 se CDA2 “puro” firmato CAdES OOXML ODF TXT EMAIL XML DOC HTML XLS | Obbligatorio |
GIF JPG BMP TIF EPS SVG MP3 WAV MPG MPEG AVI WMV EXE SMTP/MIME | ||
activityDateTime | Data ora produzione del Documento (TXA-4) nel formato yyyy-MM-ddTHH:mm:ss | Obbligatorio |
originatorCodeName | Obbligatorio | |
applicationOwner | Nome dell'applicativo (da concordare) assieme all’uniqueDocumentNumber identifica in maniera univoca il documento | Obbligatorio |
uniqueDocumentNumber | Chiave univoca ed invariante nel tempo del documento sull’applicativo d’origine | Obbligatorio |
parentDocumentNumber | Chiave univoca sull’applicativo d’origine del documento padre | |
placerOrderNumber | ||
fillerOrderNumber | ||
documentCompletionStatus | Valorizzare con “DO” (documento validato) | |
documentConfidentiality | ||
content | Contenuto del documento | Obbligatorio |
conclusion | ||
pathology | ||
outcome | ||
text |
Descrizione del tipo SignerInfo
Nome Campo | Descrizione | Caratteristiche |
signer | Utente con certificato di firma presente nel sistema CA | Obbligatorio |
Pin | Password utente associato al certificato di firma presente nel sistema CA | Obbligatorio |
OTP | Token generato/ottenuto all’atto di firma | Obbligatorio |
signType | CAdES PAdES XAdES | Obbligatorio |
customerInfo | Descrizione utente Cognome + Nome dell'utente che firma | |
sequencePhase | Indica se si tratta della prima chiamata di una sequenza, una intermedia o l’ultima; i valori sono SEQ_START, SEQ_CONTINUE, SEQ_END | Obbligatorio |
sessionID | Identifica l’id di sessione restituito alla prima chiamata e che va’ riportato nella chiamate successive fino all’ultima. | Obbligatorio se sequencePhase vale SEQ_CONTINUE o SEQ_END |
STANDARD: XML
4.3.3 Servizio di Verifica Remota Firma Digitale
DESCRIZIONE: consente ad un sistema la verifica della validità della firma di un documento firmato elettronicamente, in modo trasparente rispetto alla Certification Autority prevista. E' un servizio disponibile sia sul dominio regionale che sui domini locali sullo strato di software messo a disposizione dal Repository e si frappone fra il consumer ed il servizio della CA corrispondente.
FLUSSO: l’utente può procedere alla verifica firma digitale del documento che prevede l’invio del documento nella request del servizio. I Servizio di Verifica Firma Remota verificherà le credenziali e la presenza dei dati obbligatori; in caso positivo, verrà girata una chiamata al “servizio” messo a disposizione dalla CA (attualmente servizio ARUBA). In particolare, il Modulo Documentale di cui il Repository Aziendale è parte integrante, rende disponibile una funzionalità remota di Verifica Firma Digitale, basata sull’utilizzo in back end di servizi o librerie di firma messi a disposizione dalla Certification Autority aziendale.
Il servizio esposto dal modulo documentale realizza le seguenti operazioni:
- firma di un documento con l’utilizzo dei certificati/servizi messi a disposizione dalla Certification Autority.
- Restituzione del documento firmato al chiamante.
DATI SCAMBIATI: I dati scambiati sono gli stessi del servizio di Firma Remota Digitale descritti al paragrafo precedente. Ovviamente ci si aspetta che il documento passato sia firmato digitalmente.
STANDARD: XML
SCENARIO DI ESEMPIO:
Si riporta di seguito il diagramma di sequenza relativo al caso di verifica firma sopra descritto.
ApplicativoVerticale
Repository
CA Service
1 : Chiama Servizio di Verifica Firma remota con invio documento()
2 : Verifica credenziali()
O: credenziali non valid
3 : Chiama servizio CA Aruba con invio documento()
: K
4 e()
5 : Verifica firma remota()
6 : Restituisce risultato verifica()
7
Figura 23: sequence diagram – Verifica firma remota
4.3.4 Servizio di Ricezione Documento su Repository Documentale/FSE
DESCRIZIONE: permette l’archiviazione di un documento nuovo o sostitutivo nel Repository Aziendale o regionale (FSE) ovvero il salvataggio del documento nel Repository locale/regionale con i relativi “metadati” (di carattere locale o regionale). Se il paziente ha dato il consenso alla costituzione del FSE (ovvero, nel caso di documento sostitutivo, se il documento da sostituire è indicizzato nell’FSE) e valgono alcune condizioni specifiche e configurabili sui valori di alcuni metadati, il Repository (Aziendale o Regionale) provvede all’inserimento dei METADATI FSE corrispondenti nel Registry Centrale FSE (vedi servizio di Indicizzazione, par. 4.3.6). Il documento è altresì versato nel Polo di Conservazione regionale.
Ogni Azienda ha la possibilità di configurare le “condizioni specifiche” che guidano l’indicizzazione orientandola in base al document Type, al Format Code ed al valore del metadato “Registra il documento solo su Repository” di cui doc. RM-Lotto1_Affinity_Domain.3.3
FLUSSO con autenticazione/autorizzazione utente (Cohesion + Attribute Authority):
l’utente potrà procedere alla firma digitale del documento (se trattasi di documento non firmato) e una volta autenticato, alla sottomissione dello stesso; l’Access Gateway provvederà a verificare la validità dei 2 token (Cohesion e Attribute Authority) e delle policy, ovvero accerterà che l’utente abbia un profilo autorizzato ad eseguire l’operazione richiesta. Il documento, se verificati con successo i metadati trasmessi, anche sfruttando un servizio di ricerca su ASR, sarà quindi archiviato nel Repository locale o regionale assieme ai relativi metadati, e, se il paziente ha dato il consenso alla costituzione dell’FSE, sarà avviato il servizio di Indicizzazione.
In particolare, questa transazione consente ad un qualsiasi ApplicativoVerticale (Document Source) di trasmettere ed archiviare un documento elettronico firmato sul Repository di competenza (regionale od aziendale). Viene risposto un acknowledge con il risultato dell’operazione (successo od insuccesso) ed eventuale eccezione.
In caso di archiviazione di un documento sostitutivo, i METADATI del documento sostituito vengono resi Obsoleti.
FLUSSO con autenticazione/autorizzazione applicativa (STS FSE):
l’utente potrà procedere alla firma digitale del documento (se trattasi di documento non firmato) e successivamente procedere alla sottomissione dello stesso utilizzando un asserzione applicativa standard con la quale viene identifico l’attore generico che esegue questa operazione; l’Access Gateway provvederà comunque a verificare la validità del token applicativo (STS FSE) e delle policy, ovvero accerterà che anche l’utente/attore generico abbia un profilo autorizzato ad eseguire l’operazione richiesta. Il documento, se
verificati con successo i metadati trasmessi, anche sfruttando un servizio di ricerca su ASR, sarà quindi archiviato nel Repository locale o regionale assieme ai relativi metadati, e, se il paziente ha dato il consenso alla costituzione dell’FSE, sarà avviato il servizio di Indicizzazione.
In particolare, questa transazione consente ad un qualsiasi ApplicativoVerticale (Document Source) di trasmettere ed archiviare un documento elettronico firmato sul Repository di competenza (regionale od aziendale). Viene risposto un acknowledge con il risultato dell’operazione (successo od insuccesso) ed eventuale eccezione.
In caso di archiviazione di un documento sostitutivo, i METADATI del documento sostituito vengono resi Obsoleti.
DATI SCAMBIATI: per il set di dati da trasmettere e le regole di compilazione, si veda i documenti relativi all’Affinity Domain definito per Regione Marche.
Nota aggiuntiva: gli identificativi anagrafici sono da considerarsi obbligatori o facoltativi in base alla tipologia del sistema inviante:
a) Sistema esterno al dominio aziendale dove risiede il CDR ( Es. cartella medico convenzionato ):
ID Paziente a livello regionale (GUIDFSE): Obbligatorio ID Paziente a livello locale (MPI Locale): Facoltativo
b) Sistema interno al dominio aziendale dove risiede il CDR ( Es. dipartimentale generico ):
ID Paziente a livello regionale (GUIDFSE): Obbligatorio se manca l’MPI locale ID Paziente a livello locale (MPI Locale): Obbligatorio se manca il GUIDFSE
Il Repository in ogni caso, con l’identificativo o gli identificativi anagrafici ricevuti, fa una chiamata all’ASRMPI regionale per verificare la validità dell’anagrafica ed eventualmente recuperare l’identificativo mancante, salvando quindi uno od entrambi (se presenti) sui METADATI “locali” e passandoli eventualmente al Registry FSE.
Come già specificato, il servizio di gestione versioning utilizza lo stesso servizio previsto per l’acquisizione documento di Ricezione Documento su Repository. Tuttavia, in caso di versioning sarà richiesto come obbligatorio il dato “ParentDocument” che corrisponde allo “UniqueID” del documento che viene sostituito (chiave univoca ed invariante nel tempo del documento). Il servizio di versioning in questo caso fa riferimento alla “sostituzione”, in linea con transazione “Provide and Register Document Set –b” (ITI-15) di IHE che utilizza la voce RPLC (“replace”).
STANDARD: IHE XDS-b, ebRIM, ebRS
SCENARIO DI ESEMPIO:
Si riporta di seguito il diagramma di sequenza relativo al caso di archiviazione in un repository aziendale utilizzando l’autenticazione/autorizzazione utente (Cohesion + Attribute Authority):
Figura 24: sequence diagram – Archiviazione repository aziendale
Si riporta di seguito il diagramma di sequenza relativo al caso di archiviazione in un repository aziendale utilizzando l’autenticazione/autorizzazione applicativa (STS FSE):
Figura 25: sequence diagram – Archiviazione repository con asserzione applicativa
4.3.5 Servizio di modifica dei metadati “locali”
DESCRIZIONE: allo stato di redazione del presente documento non sono emersi in fase di analisi casi d’uso specifici in merito al servizio di modifica dei metadati locali. Si rimanda pertanto alla descrizione dell’interfaccia standard al momento prevista.
FLUSSO: Questa transazione consente di modificare i valori di alcuni metadati secondo regole che verranno definite nel seguito; in ogni caso metadati che non sono presenti sul Registry Regionale. Viene risposto un acknowledge con il risultato dell’operazione (successo od insuccesso) ed eventuale eccezione.
DATI SCAMBIATI: La mappatura dei metadati da trasmettere sui nomi nel messaggio ed in taluni casi i valori da utilizzare è in fase di definizione (vedere 2.4.3).
STANDARD: IHE XDS, ebRIM, ebRS
SCENARIO DI ESEMPIO: n.d.
4.3.6 Servizio di Ricezione Dati di Laboratorio Urgenti (non “firmati”)
DESCRIZIONE: permette la memorizzazione e l’aggiornamento sul Repository Aziendale dei risultati urgenti validati di laboratorio che non hanno ancora dato vita ad un referto firmato digitalmente. Questo servizio viene utilizzato dal LIS per comunicare i risultati di laboratorio in caso di regime di urgenza
FLUSSO: una volta autenticato, l’utente procede alla validazione dei risultati che in automatico, se si tratta di un regime di urgenza, il sistema di laboratorio trasmette all’ Access Gateway; quest’ultimo provvederà a verificare la validità del token e delle policy, ovvero accerterà che l’utente abbia un profilo autorizzato ad
eseguire l’operazione richiesta. I risultati, contenuti comunque in un CDA2 con lo stesso schema dei Referti Firmati, verranno trasmessi al Repository Locale.
DATI SCAMBIATI: per i dati scambiati si rimanda al par. 4.3.3.
STANDARD: IHE XDS-b, ebRIM, ebRS
SCENARIO DI ESEMPIO:
Si riporta di seguito il diagramma di sequenza relativo al caso di archiviazione del referto LIS sopra descritto. Il caso di aggiornamento è analogo ma comporta la sovrascrittura del CDA precedente.
1 : In
to()
3 : Token non valido()
5 : Autorizzaz
xxx Xxxx - XXX0 non firma
Access Gateway
ApplicativoVerticale(LIS)
Repository Local
Figura 26: sequence diagram – Archiviazione Dati Laboratorio “urgenti” (non firmati)
4.3.7 Servizio di indicizzazione documenti su Registry Regionale FSE
DESCRIZIONE: nell’ambito dell’architettura proposta, il servizio di indicizzazione è compreso nel servizio di archiviazione di un documento nuovo o sostitutivo nel Repository Aziendale o regionale (FSE). In particolare, se valgono le condizioni già espresse nel capitolo 4.3.3, il Repository (Aziendale o Regionale) provvede all’inserimento dei METADATI FSE corrispondenti nel Registry Centrale FSE. Il servizio di indicizzazione è anche utilizzato dai Repository LEGACY per indicizzare sul Registry Regionale i documenti salvati sul proprio Repository e renderli visibili e consultabili a livello di FSE.
FLUSSO: all’atto dell’archiviazione di un documento nel repository aziendale o regionale, se il paziente ha dato il Consenso alla costituzione dell’FSE, i METADATI FSE saranno inviati al Registry Regionale per l’indicizzazione. A valle della validazione dell’identificativo paziente, il Registry provvederà ad archiviare i METADATI ricevuti e ad attivare il processo di notifica della presenza di un nuovo documento verso i soggetti interessati.
Analogamente, in caso di Repository legacy, quest’ultimo dovrà essere in grado di applicare le regole di indicizzazione previste (tra cui, in primis, tramite integrazione con il Modulo Gestione Consenso, il consenso all’alimentazione fornito dal paziente) ed indicizzare sul Registry Regionale i documenti memorizzati su Repository mediante transazione IHE XDS Register Document Set-b.
DATI SCAMBIATI: per i dati scambiati si rimanda al par. 4.3.3.
STANDARD: IHE XDS-b, ebRIM, ebRS
SCENARIO DI ESEMPIO:
Si riporta di seguito il diagramma di sequenza relativo al caso di indicizzazione sopra descritto. Nel caso d’uso, per maggiore semplicità, sono stati volutamente tralasciati i servizi di autenticazione, profilazione e verifica delle asserzioni e ruoli, per i quali si rimanda ai diagrammi riportati ai parr. 4.1.2, 4.1.3 e 4.3.3.
1 : Invio documento - con tok
attributo()
Si suppone competata la fase di autenticazione e profilazione
2 : Verifica asserzioni identità
3 : Verifica Policy()
Invio documento(
7 : Consenso recuperato()
8 : Verifica
11 : Registr
()
12 : Indicizzazione metadati()
i
15 : Verif
do e attivo()
16 : Inserime
17 : Accodamento notifica NAV()
zazione()
ACK archiviazione()
: ACK archiviazione()
19 :
18 : ACK indiciz
ica ID assistito vali nto riga di log()
grafica()
torno posizione ana
14 : Ri
13 :
Recupero anagraf
ca()
a chiave GUIDFSE
one anagrafica()
10 : Ritorno posizi
9 : Ricerca a
consenso() nagrafica()
consenso()
6 : Recupero
4 :
5 : Versamento()
)
e ruolo()
en identità e token
Polo Conservazione
ASR-EMPI
Audit Logger
Repository
Registry
Gestione consenso
Access Gateway
Client Application
20
Figura 27: sequence diagram – Indicizzazione su Registry Regionale FSE
4.3.8 Servizio di Marca Temporale
DESCRIZIONE: consente ad un sistema verticale l’apposizione della marca temporale in maniera indipendente o contestuale ai servizi di firma esposti, in modo trasparente rispetto alla Certification Autority prevista. E' un servizio disponibile sia sul dominio regionale che sui domini locali sullo strato di software messo a disposizione dal Repository e si frappone fra il consumer ed il servizio della CA corrispondente. La chiamata al servizio è tendenzialmente propedeutica all’archiviazione del documento nel repository.
FLUSSO: l’utente può procedere all’apposizione della marca temporale contestualmente alla firma digitale del documento invocando appositi parametri al momento dell’invocazione della request del servizio. In alternativa, qualora l’utente disponga già di un documeto firmato o di altri servizi di firma, può procedere all’apposizione
della marca temporale invocando uno specifico richiesto. Il servizio di marca verificherà le credenziali e la presenza dei dati obbligatori; in caso positivo, verrà girata una chiamata al “servizio” messo a disposizione dalla CA (attualmente servizio ARUBA). In particolare, il Modulo Documentale di cui il Repository Aziendale è parte integrante, rende disponibile una funzionalità remota di firma digitale e marcatura temporale, ovvero di sola marcatura temporale, basata sull’utilizzo in back end di servizi o librerie di firma messi a disposizione dalla Certification Autority aziendale.
Il servizio esposto dal modulo documentale realizza le seguenti operazioni:
- Firma e marcatura temporale:
o firma di un documento e marcatura temporale (se richiesta) con l’utilizzo dei certificati/servizi messi a disposizione dalla Certification Autority;
o Restituzione del documento firmato e “marcato” al chiamante.
- Marcatura temporale:
o marca temporale di un documento con l’utilizzo dei certificati/servizi messi a disposizione dalla Certification Autority;
o Restituzione del documento “marcato” al chiamante.
DATI SCAMBIATI: Nel caso in cui oltre a firmare il documento si voglia anche marcare contestualmente viene invocato il servizio di firma remota come da paragrafo 4.3.1, con le seguenti specificità aggiuntive:
• valorizzando in modo specifico il parametro signType nel seguente modo:
Nome Campo | Descrizione | Caratteristiche |
signType | CAdES_T PAdES_T XAdES_T | Obbligatorio |
• aggiungendo nel signType il parametro markType valorizzandolo con TSD.
Nel caso del servizio di marca temporale “pura”, la struttura della chiamata è esattamente la stessa della firma con marca, ma si deve chiamare un metodo diverso (non il SIGN ma il MARK).
4.3.9 Servizio di Stampa Contrassegno
DESCRIZIONE: consente ad un sistema verticale l’apposizione del contrassegno sul documento da stampare e l’upload del documento con contrassegno utile alla successiva verifica. Il contrassegno “conterrà” il riferimento all’endpoin che consente successivamente di recuperarlo per verifocare la corrispondenzaa del contrassegno.
FLUSSO: l’utente può procedere all’apposizione timbro digitale al momento della stampa del documento.
DATI SCAMBIATI: il primo metodo da invocare è stampCreate; il set di dati da inviare è lo stesso del metodo di firma remota descritto al paragrafo 4.3.1, con la differenza che nel tag <content> va messo il documento pdf di cui creare il contrassegno. Tale metodo risponderà con il documento con contrassegno + un id generato dal server. Il secondo metodo da chiamare è stampUpload ed ha la stessa struttura di request ma nel campo content va messo il documento restituito dalla chiamata precedente e come id documento va passato l’id ottenuto dalla chiamate precedente..
4.3.10 Servizio di Invio Credenziali OTP via SMS o ArubaCall
DESCRIZIONE: consente ad un sistema verticale il recupero della OTP per la firma dei documenti.
FLUSSO: l’utente può richiedere la ricezione delle proprie credenziali OTP via SMS o ArubaCall.
DATI SCAMBIATI: il metodo da invocare è sendCredential; il set di dati da inviare prevede obbligatoriamente le componenti UserInfo e SignerInfo descritte al paragrafo sulla Firma Digitale Remota, cui si aggiunge il parametro authType
Nome Campo | Descrizione | Caratteristiche |
authType | SMS ARUBACALL | Obbligatorio |
Per la struttura degli argomenti della chiamata che si compongono dei tipi di parametri descritti si faccia riferimento al par. 5.3.10.
4.4 Servizi di Consultazione dati e documenti (categoria “funzioni di ricerca e recupero documenti”)
4.4.1 Servizio di Ricerca Documenti su FSE
DESCRIZIONE: consente la ricerca nel Registry di uno o più documenti rispondenti ai criteri di selezione forniti dall’utente.
FLUSSO: una volta autenticato, l’utente potrà selezionare la funzionalità di ricerca e fornire in particolare i parametri per la selezione dei documenti (nel caso specifico dei METADATI) rispondenti ai criteri desiderati. L’Access Gateway provvederà a verificare la validità del token e delle policy, ovvero accerterà che l’utente abbia un profilo autorizzato ad eseguire l’operazione richiesta. A questo punto dovrà essere verificato il consenso sulla base di operatore e contesto; se il risultato è positivo, il Registry provvederà ad eseguire la query di ricerca dei documenti che soddisfano i suddetti criteri e restituirà l’elenco dei documenti identificati, ciascuno con il proprio identificativo unico, che sarà utilizzato per una eventuale procedura di recupero del suo contenuto (vedi par. 4.4.2).
DATI SCAMBIATI: Le stored query sono messaggi di interrogazione prestabiliti, cioè in base al tipi di query che si utilizza è possibile recuperare diverse informazioni dal registry.
Ogni query si differenzia per id e per i parametri di ricerca; questi possono essere:
Patient id, intervallo di tempo, tipo di documento, autore, document source, modifiche a un folder in un intervallo temporale, identificativo dei documenti, intervallo temporale di un sottomissione.
La richiesta di query deve contenere:
1. un riferimento valido a una query predefinita contenuta nel registry
2. i parametri della query. i parametri vengono matchati con quelli definiti nella query contenuta nel registry.
STANDARD: IHE XDS, ebRIM, ebRS
xxxx://xxx.xxx.xxx/xxxxxxxxXxxxx/Xxxxxxxxx/XXX/XXX_XXX_XX_Xxx0x.xxx capitolo 3.18.
xxxx://xxxx.xxxxx-xxxx.xxx/xxxxxx/x0.0/xxxxx/xxxxxx-xx-0.0-xx.xxx capitolo 6
SCENARIO DI ESEMPIO:
Si riporta di seguito il diagramma di sequenza relativo al caso ricerca del documento.
Client FedCohesion Application
Attribute Autority
Access Gateway Policy Manager
Gestione Consenso
Registry
ASR-EMPI
1 : Invio credenziali()
2 : rno token identità()
3 : Invio token identità()
4 : Ritorno token di attributo - ruoli()
5 : Richiesta lista documenti()
6 : Verifica asserzioni di identità e ruolo()
7 : Recupero policy() 8 : Ritorno policy()
9 : Ricerca anagrafica()
10 : Ritorno posizione anagrafica() 11 : Recupero consenso()
12 : Consenso recuperato() 13 : Verifica policy()
14 : Recupero lista documenti()
15 : Lista documenti recuperata()
16 : Applicazione policy di visibilità()
17 : Generazione asserzioni autorizzative()
18 : Lista documenti richiesta()
Rito
Figura 28: sequence diagram – Ricerca documenti FSE
4.4.2 Servizio di Retrieve Documento da FSE
DESCRIZIONE: consente il recupero dal repository FSE di un documento selezionato dalla lista di documenti estratta attraverso il servizio di ricerca (par. 4.4.1).
FLUSSO: l’utente, dopo avere eseguito la procedura di ricerca documento (par. 4.4.1), potrà selezionare il documento desiderato dall’elenco fornito precedentemente dal Registry. L’ Access Gateway provvederà a verificare la validità del token e delle policy, ovvero accerterà che l’utente abbia un profilo autorizzato ad accedere al documento richiesto. A questo punto, (in funzione dei diritti di accesso relativi al profilo assegnato all’utente), il documento sarà richiesto al Repository FSE tramite il suo identificativo unico e fornito all’utente.
Questa transazione consente di recuperare un documento del Repository FSE, ad un Document Source che ha già ottenuto lo uniqueId del documento tramite una notifica o mediante chiamata al “Servizio di Ricerca Documenti su FSE” già descritto. La risposta contiene uno stato di ritorno (successo od insuccesso), il documento se è stato trovato ed eventualmente un’eccezione in caso di insuccesso.
DATI SCAMBIATI: in input è previsto lo uniqueId del documento; in output il documento stesso. Si vedano comunque la documentazione IHE e le note tecniche, più gli esempi di messaggi per maggiori dettagli.
STANDARD: IHE XDS-b descritto nei seguenti Volumi pubblici di IHE: xxxx://xxx.xxx.xxx/xxxxxxxxXxxxx/Xxxxxxxxx/XXX/XXX_XXX_XX_Xxx0x.xxx capitolo 3.43.
SCENARIO DI ESEMPIO:
Si riporta di seguito il diagramma di sequenza relativo al caso di retrieve del documento sopra descritto. Il servizio di retrieve è originato dal servizio di ricerca, che nella rappresentazione che segue, per maggiore semplicità, è stato volutamente tralasciato.
Audit Logger
Client Application
Access Gateway
Repository
menti richiesta()
Da "servizio di ricerca documenti"
1 : Lista docu
2 : Visualizzazione documenti()
3 : Richiesta documento()
Figura 29: sequence diagram – Retrieve documento da FSE
4.4.3 Servizio di Ricerca su Repository Locale (firmato e non – dati)
DESCRIZIONE: consente la ricerca nel Repository Aziendale di uno o più documenti rispondenti ai criteri di selezione forniti dall’utente. Nel solo caso di Laboratorio sarà consentito il recupero di risultati urgenti non firmati.
FLUSSO: Questa transazione consente di fare un ricerca di documenti sul Repository Aziendale ottenendo in risposta un elenco di uniqueId dei documenti trovati con i corrispondenti attributi “locali”. Inoltre è restituito uno stato di ritorno (successo od insuccesso) con eventualmente un’eccezione.
DATI SCAMBIATI: I parametri di ricerca disponibili si ipotizza al momento che saranno comunque utilizzati:
- anagrafica (id paziente): può essere in alternativa l’ID Paziente a livello regionale (GUIDFSE) o l’ID Paziente a livello locale (MPI Locale):
- stato del documento.
La risposta conterrà una lista dell'intero set di metadati dei documenti individuati.
STANDARD: IHE XDS-b descritto nei seguenti Volumi pubblici di IHE: xxxx://xxx.xxx.xxx/xxxxxxxxXxxxx/Xxxxxxxxx/XXX/XXX_XXX_XX_Xxx0x.xxx capitolo 3.18.
SCENARIO DI ESEMPIO:
Si riporta di seguito il diagramma di sequenza relativo al caso di ricerca del documento sopra descritto. Per semplicità di rappresentazione, non sono volutamente riportate le fasi di autenticazione e autorizzazione preliminari alla presente sequenza.
Repository (Registry Locale)
1 : Ricerca documenti()
3 : Token non valid )
5 : Autorizzazione n ata()
eg
o(
Client
Access Gateway
2 : Validazione token()
4 : Valida
Figura 30: sequence diagram – Ricerca su Repository Locale (firmato e non – dati)
4.4.4 Servizio di Retrieve Documento da Repository Locale (firmato e non - dati)
DESCRIZIONE: consente il recupero dal repository locale di un documento selezionato dalla lista di documenti estratta attraverso il servizio di ricerca (par. 4.4.3).
FLUSSO: il servizio è lo stesso descritto al par. 4.4.2; ciò che cambia è il contesto nel quale viene usato; in questo caso infatti l’utilizzatore è tipicamente un ApplicativoVerticale che in ambito “locale” deve reperire un documento del quale ha avuto lo uniqueId tramite il servizio di ricerca descritto al capitolo 4.4.3.
DATI SCAMBIATI: Si veda il par. 4.4.2.
STANDARD: IHE XDS-b descritto nei seguenti Volumi pubblici di IHE: xxxx://xxx.xxx.xxx/xxxxxxxxXxxxx/Xxxxxxxxx/XXX/XXX_XXX_XX_Xxx0x.xxx capitolo 3.43.
SCENARIO DI ESEMPIO: Si veda il par. 4.4.2.
4.4.5 Servizio di Recupero Risultati Precedenti di Laboratorio
DESCRIZIONE: consente la ricerca nel Repository Aziendale dei risultati di laboratorio precedenti di un paziente, trasversalmente ai referti digitali firmati.
FLUSSO: questo servizio viene utilizzato tipicamente dai software di reparto per accedere ai dati precedenti di laboratorio si fini di valutazioni di appropriatezza delle richieste di esame da registrare. In particolare una volta autenticato, l’utente potrà selezionare la funzionalità di ricerca e fornire i parametri per la selezione dei risultati basandosi sul set di METADATI locali. L’Access Gateway provvederà a verificare la validità del token e delle policy, ovvero accerterà che l’utente abbia un profilo autorizzato ad eseguire l’operazione richiesta. Il Repository provvederà ad eseguire la query di ricerca dei risultati che soddisfano i suddetti criteri e restituirà l’elenco dei risultati estratti identificati e le date a cui si riferiscono. La ricerca sarà effettuata sui risultati che sono stati estratti da referti firmati digitalmente, precedentemente confluiti sul repository. Al termine, in funzione dei diritti di accesso ai documenti, l’utente è in grado di visualizzare l’elenco dei risultati presenti nel Repositori locale, rispondenti ai criteri di ricerca da lui inseriti.
DATI SCAMBIATI: il servizio viene richiesto specificando i seguenti parametri:
- GUIDFSE o LocalMPI (obbligatorio)
- data inizio / fine (data minima non anteriore a 2 anni) o in alternativa:
- specifica di un determinato esame (codice di esame), per estrazione del dato in tutta la storia del paziente.
STANDARD: Lo standard di riferimento è JSON
SCENARIO DI ESEMPIO:
Si riporta di seguito il diagramma di sequenza relativo al caso sopra descritto. Per semplicità di rappresentazione, non sono volutamente riportate le fasi di autenticazione e autorizzazione preliminari alla presente sequenza.
1 : Ricerca risultati per anagrafica e range di data()
2 : Validazione token()
3 : Token non valid )
4 : Validazione policy()
ata()
6
8 : Ritorna risultati e data()
9
5 : Autorizzazione n
eg
o(
Repository (Registry Locale)
Access Gateway
Client
7 : Esecuzione query()
Figura 31: sequence diagram – Recupero Risultati Precedenti di Laboratorio
4.6 Servizi di gestione del Consenso (categoria “funzioni di gestione del consenso”)
System
Autenticazione
e profilazione Autorizzazione
<<include>>
Utente
ApplicativoVerticale
<<include>>
Gestione consenso
Verifica consenso
Repository
Access Gateway
Figura 32: Caso d’uso – Gestione consenso
CASO D’USO: la figura sopra riportata illustra il caso d’uso della gestione del consenso. La gestione del consenso suppone due tipologie principali del servizio, la prima legata alla gestione del consenso da parte del cittadino/operatore (inserimento, aggiornamento, revoca, oscuramento ecc.), la seconda legata all’operatività dei servizi di archiviazione, ricerca e recupero dei documenti nel FSE da parte di ciascun applicativo che interagisce con tale sistema. Le tipologie di consenso che possono essere gestite sono relative ai consensi generici (consenso all’istituzione del fascicolo, o alla consultazione generica di dati e documenti – tipo oggetto
c.d. “anagrafica”) ovvero a livello di singolo documento (da rendere ad es., consultabile o oscurabile). Il Gestore Consenso permette di essere utilizzato:
• via interfaccia applicativa: in maniera stand alone o attraverso un software terzo (es. portale) che si occupa di veicolare i servizi di autenticazione, profilazione ecc..
• via webservice o chiamata http: un software terzo può invocare i servizi del modulo per leggere e scrivere consensi, applicare regole di oscuramento, ottenere informazioni di visibilità e altro, in modo completamente trasparente all’utente.
Nel primo caso, si ipotizza che il sistema possa essere accessibile all’utente cittadino, che attraverso meccanismi di autenticazione e profilazione gestiti dal portale o eventualmente un software terzo, accederà ai propri consensi, ovvero all’operatore/medico, che a seguito di autenticazione, effettuerà una ricerca anagrafica e apporterà modifiche ai consensi del cittadino.
Nel caso di verifica dei consensi tramite ws, è ipotizzato al momento che la chiamata possa essere effettuata da:
- il Repository, per l’eventuale indicizzazione del documento sul Registry a seguito dell’archiviazione;
- dall’Access Gateway, per il ritorno dell’elenco dei documenti da recuperare in fase di ricerca dei documenti sul FSE.
ATTORI: di seguito l’elenco degli attori previsti:
Nome | Descrizione |
Utente | Utente del sistema FSE a livello regionale o aziendale (cittadini, MMG/PLS, medici specialisti o operatori CUP, ecc.) che accede direttamente al modulo del consenso o tramite il portale. |
ApplicativoVerticale | Identifica qualsiasi sistema applicativo in uso presso le Aziende Sanitarie e Ospedaliere marchigiane (ad es. sistemi LIS, RIS, ecc.) e deputato ad interagire con il sistema del consenso per la registrazione dei vari consensi |
Repository | Sistema per l’archiviazione documentale di livello regionale (FSE) o aziendale (CDR). Verifica i consensi prima di avviare la chiamata al FSE per l’archiviazione. |
Access Gateway | Punto unico di accesso ai servizi del FSE, verifica le policy di consenso definite dall’utente nell’ambito del servizio di ricerca di documenti FSE. |
4.6.1.1 Servizio Chiamata Applicativa di Contesto
DESCRIZIONE: permette di inserire o modificare un singolo consenso legato ad un oggetto
FLUSSO: Il MGC può essere attivato chiamando una pagina web da altro applicativo.
Il contenuto della pagina è il seguente:
• un riferimento all’oggetto di cui si sta registrando il consenso: nel contesto presente anagrafica oppure id documento. Tipo di oggetto e codice sono sempre presenti, in più viene aggiunta l’eventuale descrizione passata dal chiamante
• l’elenco dei consensi previsto nel contesto di chiamata (definito dalla coppia [applicativo chiamante, funzione di chiamata]). Questo elenco è configurabile e può essere diverso a seconda dell’applicativo, della funzionalità e anche dell’unità organizzativa dell’utente connesso
• i pulsanti che permettono di salvare o annullare le modifiche apportate
DATI SCAMBIATI: di seguito i parametri per il funzionamento:
L’attivazione del modulo avviene tramite una chiamata del tipo:
http://[server]:[port]/MGC_Web/xxxxxxxxxxx.xx?app=CUP&fun=Prenotazione&usr=pippo&o1=123456&to1=E PISODIO&paziente=11111&o2=11111&to2=ANAGRAFICA&autore=unorg1&desc=Episodio%20del%2012/0 5/2012%20del%20paziente%20Mario%20Rossi%2C%20nato%20il%2001/01/1950%20a%20Udine%20%28 UD%29
Tale chiamata dà origine alla schermata della figura sottostante.
Figura 33: Esempio di interfaccia del MGC
La tabella che segue illustra il significato dei parametri utilizzati sia nella chiamata da interfaccia, che nei vai web services descritti nei capitoli successivi.
Parametro | Nome | Descrizione | |
GUI | ws | ||
app | applicativo | Applicativo chiamante | Codice che identifica univocamente l’applicativo chiamante, va concordato apriori e configurato nel MGC. Ad es. “CUP”, “PORTALE”, “CARTELLA_MMG” ecc. |
attore | Xxxxxx | Xxxxxx che identifica l’ente/struttura dell’utente che sta effettuando l’operazione. Ad esempio, “ASUR”. | |
autore | autore | Autore | Codice che identifica l’ente/struttura dell’utente che ha creato l’oggetto. Viene identificato solo per i nuovi oggetti - documenti (serve ad applicare la regola per cui chi ha creato il documento lo può sempre visionare, indipendentemente dai consensi espressi). |
dataRiferim ento | Data di riferimento | Data in relazione alla quale effettuare l’operazione richiesta. Si utilizza principalmente per la ricerca dei consensi, validi a tale data. Ove prevista, se non valorizzata si lavora in base alla data corrente. | |
datiAccesso ri/idDatoAcc essorio | Dati accessori- tipologia del dato | Dati aggiuntivi da legare al consenso. Nel contesto della Regione Marche vengono utilizzati i seguenti dati accessori: - Per i dati strutturati del dichiarante, se diverso dall’interessato: o 2: cognome o 3: nome o 4: data di nascita o 5: luogo di nascita o 6: codice fiscale o 7: indirizzo di residenza o 8: civico di residenza o 9: comune di residenza o 10: cap di residenza o 11: provincia di residenza | |
datiAccesso ri/valoreDat oAccessorio | Dati accessori- valore del dato | ||
Parametro | Nome | Descrizione | |
GUI | ws | ||
- Tipolgia 20: consenso raccolto oralmente. Valore: 0 (o non presente)=NO, 1=SI | |||
datiAnagrafi ca/cognome | Cognome del soggetto | Dati anagrafici del soggetto di cui creare il cda dei consensi | |
datiAnagrafi ca/nome | Nome del soggetto | ||
datiAnagrafi ca/codiceFis cale | Codice fiscale del soggetto | ||
datiAnagrafi ca/sesso | Sesso del soggetto | ||
datiAnagrafi ca/dataDiNa scita | Data di nascita del soggetto | ||
datiAnagrafi ca/luogoDiN ascita | Luogo di nascita del soggetto | ||
datiAnagrafi ca/indirizzo DiResidenz a | Indirizzo di residenza del soggetto | ||
datiAnagrafi ca/civicoDiR esidenza | Numero civico dell’indirizzo di residenza del soggetto | ||
datiAnagrafi ca/comuneD iResidenza | comune (testuale) dell’indirizzo di residenza del soggetto | ||
datiAnagrafi ca/provincia DiResidenz a | Provincia dell’indirizzo di residenza del soggetto | ||
datiAnagrafi ca/capDiRe sidenza | cap dell’indirizzo di residenza del soggetto | ||
desc | Testo che descrive l’oggetto e che viene visualizzato nell’interfaccia per contestualizzare l’operazione. | ||
dichiarante | Dichiarante | Valore che indica da chi è stato raccolto il consenso, va specificato se non si tratta dell’interessato. Valori possibili: 1- Interessato 2- Tutore 3- Amministratore di sostegno 4- Esercente la potestà genitoriale 5- Legale rappresentante | |
documentoB ase64 | Documento firmato digitalmente | Documento da archiviare, codificato in base64 | |
Firmatario | Firmatario | Codice fiscale dell’utente che ha firmato digitalmente il documento | |
fun | funzioneChi amante | Funzioanlità chiamante | Funzionalità da cui è invocato il modulo. Assieme all’applicativo chiamante definisce il “contesto” (che deve essere configurato), cui sono associati il numero e la tipologia |
Parametro | Nome | Descrizione | |
GUI | ws | ||
di consensi da gestire e le eventuali regole da applicare. Ad esempio: “Prenotazione”, “Accettazione”…. Per i webservices può non essere specificata, in quanto il contesto sarà definito dalla coppia applicazione-nome ws. | |||
To1 | tipoOggetto | Tipologia di oggetto | Tipologia di oggetto cui si riferisce il consenso trattato. Nel contesto del FSE Regione Marche si prevede l’utilizzo di due tipi di oggetti: • ANAGRAFICA, per registrare i consensi generici espressi dal cittadino • DOCUMENTO, per registrare gli oscuramenti dei singoli documenti |
o1 | idOggetto | Identificativo univoco oggetto | Chiave univoca che identifica l’oggetto cui si riferisce il consenso. Nel contesto del FSE Regione marche saranno:: • GUIDFSE, per gli oggetti di tipo ANAGRAFICA • uniqueId (identificativo del documento nel FSE), per gli oggetti di tipo DOCUMENTO |
o2 | idOggettoPa dre | Identificativo univoco oggetto padre | Xxxxxx univoca che identifica l’oggetto che può esser considerato “padre” dell’oggetto cui sono relativi i consensi. Serve per sfruttare caratteristiche di ereditarietà dei consensi. Ad esempio, ogni DOCUMENTO avrà come oggetto padre l’ANAGRAFICA cui si riferisce; in tal modo, in assenza di specifici consensi per il singolo documento, si applicheranno quelli generici espressi dal cittadino. |
To2 | tipoOggetto Padre | Tipologia di oggetto padre | Tipologia dell’oggetto padre (in questo contesto sarà sempre ANAGRAFICA). |
Paziente | idPaziente | Identificativo univoco paziente | GUIDFSE del cittadino cui si riferisce l’oggetto (sia se è di tipo DOCUMENTO che se è di tipo ANAGRAFICA; in questo secondo caso l’idOggetto e l’idPaziente coincidono). |
tipoOscura mento | Oscuramento | Campo utilizzato solo per registrare un oscuramento “coatto”, cioè provocato da applicativi terzi e senza l’esplicita scelta del cittadino (ad esempio, per le situazioni che legge prevede di tutelare con anonimato). Codice che identifica la tipologia di oscuramento (ad esempio, PREST_CRITICHE=prestazioni critiche). | |
infoOscura mento | Info_oscuramento | Il campo serve a registrare note testuali aggiuntive che motivino l’oscuramento (e che rimarranno a solo livello DB, senza la possibilità, per la privacy, di visualizzarle da interfaccia). | |
Modificabile | Modificabile | SI/NO. Ove utilizzato, prevede di esplicitare il fatto che il consenso gestito/l’oscuramento imposto possa essere ritenuto modificabile o meno. | |
Propagazion e | Propagazione | SI/NO. Ove utilizzato (in aggiornamento consensi) specifica se i consensi trattati vadano propagati anche all’oggetto padre. | |
idDisclosure | Identificativo informativa | Identificativo, nel formato [codifica regione^id sequenziale], dell’informativa che è stata proposta al dichiarante | |
requestorId | Identificativo richiedente | Identificativo anagrafico (GUIDFSE) di chi richiede l’attività sul consenso, che può essere l’interessato oppure il suo genitore/tutore/rappresentante legale | |
Parametro | Nome | Descrizione | |
GUI | ws | ||
struttura | Struttura cui afferisce l’utente | Codifica HSP.11 - HSP.11bis - STS.11 - RIA.11, ovvero codifica ISTAT della Azienda (ASL) o codifica Tabella 5.4-3 del AffinityDomainItalia_Versione 2.1. Es. 110037 | |
subjectRole | Ruolo dell’utente | Ruolo dell’utente che affettua la richiesta, secondo il dizionario definito nella Tabella 5.4-1 del AffinityDomainItalia_Versione 2.1 per la codifica dei ruoli | |
tipoConsens o | Tipologia di consenso | Codice che identifica il tipo di consenso su cui lavorare. I codici vanno concordati a priori e configurato nel MGC. Ad esempio: FSERM_ATT1= Consenso all’attivazione del fascicolo sanitario elettronico. | |
Token | Token di autenticazione | E’ il token di autenticazione dell’utente; viene passato ad alcuni webservices dall’applicativo chiamante, in modo che possa essere verificato e salvato su database | |
uniqueId | Idnetificativo univoco documento | Codice univoco del documento invitao, assegnato dal Document producer | |
usr | utente | Utente connesso | Codice identificativo dell’utente che sta effettuando l’operazione (username). |
usaToken | Inserimento del token nel file contenete il CDA dei consensi | Se impostato a SI prevede la memorizzazione del token di autenticazione all’interno della busta MIME che contiene il file CDA dei consensi | |
Archivia | Impostazione di invio a repository del CDA | Indica se inviare o meno a repository il documneto CDA generato | |
valoreConse nso | Valore del consenso | Per l’aggiornamento dei consensi, serve a specificare il valore da impostare (SI/NO/ND). | |
Nota: l’insieme dei parametri sopra descritti avrà senso e potrà essere utilizzato solo per i ws che li richiedono.
STANDARD: chiamata http
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo all’accesso del cittadino ai propri consensi.
Figura 34: sequence diagram – Accesso al consenso da applicativo (es. portale)
Si riporta di seguito l’elenco dei servizi disponibili, con i relativi parametri e comportamenti previsti. Nei capitoli successivi verranno date le specifiche tecniche di invocazione.
4.6.1.2.1 Aggiorna consenso singolo
DESCRIZIONE: permette di inserire o modificare un singolo consenso legato ad un oggetto
FLUSSO: l’utente di applicativo verticale inserisce o modifica un consenso utilizzando l’interfaccia di tale applicativo. L’applicativo, poi, invia l’informazione al MGC tramite il servizio “aggiornaConsensoSingolo”, ricevendo, l’ACK dell’operazione eseguita.
DATI SCAMBIATI: di seguito i parametri per il funzionamento:
• Applicativo chiamante: se null 🡪 errore
• Funzionalità chiamante: se null, la funzionalità considerata è aggiorna_consenso_singolo
• Utente connesso: se null 🡪 errore
• Attore (tipicamente unità organizzativa)
• Tipologia di oggetto (valore eventualmente da transcodificare): se null🡪 errore
• Identificativo univoco oggetto: se null 🡪 errore
• Identificativo univoco paziente: se null 🡪 errore
• Tipologia di oggetto padre: (valore eventualmente da transcodificare) viene considerato solo per nuovi oggetti, anche null
• Identificativo univoco oggetto padre: viene considerato solo per nuovi oggetti, anche null
• Autore: viene considerato solo per nuovi oggetti
• Tipologia di consenso: (valore eventualmente da transcodificare) se null 🡪 errore
• Valore del consenso (valore eventualmente da transcodificare)
• Modificabile : SI oppure NO. Se non valorizzato: per i nuovi oggetti verrà impostato per default a SI, per gli oggetti esistenti non verrà modificato il valore attuale
• Propagazione: SI oppure NO (in caso di valore SI la modifica verrà propagata anche all’oggetto padre)
• Token: in base alla ocnfigurazione predisposta per l’applicativo chiamante, può essere obbligatorio
• Dichiarante: va indicato se è diverso dall’interessato; in caso contrario è opzionale
• Dati accessori: questa sezione va replicata una volta per ogni dato accessorio da inviare
o id: dovrà essere valorizzato con il codice del tipo di dato accessorio, come specificato nella tabella di pagina 79
o valore: dovrà essere valorizzato con il valore del dato accessorio, come specificato nella tabella di pagina 79
STANDARD: XML
SCENARIO DI ESEMPIO: Si riporta di seguito il diagramma di sequenza relativo al caso di aggiornamento consenso.
ApplicativoVerticale
FedCohesion
Attribute Autority
Access Gateway
Policy Manager
Gestore Consenso
: Invio credenziali()
1
R
2 : itorno token identità()
3 : Invio token identità()
4 : Ritorno token attributo - ruolo()
5 : Recupero consenso - token identità + token attributo()
6 : Verifica
asserzioni di identità
e ruolo()
10 : Recuper
cy()
y()
a Policy()
o consenso()
7 : Recupero poli
In caso di primo inserimento verrebbe restituito un consenso nullo
8 : Ritorno Polic
9 : Verific
: Ritorno consens
izzazione e scelta
mento consenso - t
12
13 : Visual
14 : Aggiorna
o()
11 : Ritorno
nuovo consenso()
oken identità + toke
consenso()
n attributo()
ca asserzioni di ident
()
15 : Verifi
16 : Recupero policy
ità e ruolo()
1
18 : Ver
7 : Ritorno policy()
ento consenso()
ifica Policy() 19 : Aggiornam
20 : ACK Aggiornamento consenso()
21 : ACK Aggiornamento consenso()
Figura 35: sequence diagram – Recupero e aggiornamento consenso
DESCRIZIONE: permette ad un applicativo di oscurare un oggetto nel MGC, cioè impostare a NO tutti i consensi legati alla visibilità dello stesso. Tale oscuramento deve avvenire in modo automatico e non essere più modificabile dall’operatore umano.
FLUSSO: è il caso di oscuramento di prestazioni e documenti che sono soggette alla legge per la tutela dell’anonimato. L’applicativo verticale rileva una situazione da tutelare tramite anonimato (tale rilevamento può essere automatico e basato su configurazioni oppure lasciato a segnalazione dell’utente umano); come conseguenza registra l’oscuramento dei relativi documenti. Tale oscuramento deve avvenire in modo automatico e non essere più modificabile dall’operatore umano.
DATI SCAMBIATI: di seguito i parametri per il funzionamento:
• Applicativo chiamante: se null 🡪 errore
• Funzionalità chiamante: se null, la funzionalità considerata è oscura_oggetto
• Utente connesso: se null 🡪 errore
• Attore (tipicamente unità organizzativa)
• Tipologia di oggetto (valore eventualmente da transcodificare): se null🡪 errore
• Identificativo univoco oggetto: se null 🡪 errore
• Identificativo univoco paziente: se null 🡪 errore
• Tipologia di consenso: (valore eventualmente da transcodificare) in caso di oscuramento globale, avrà valore null. In caso contrario l’oscuramento verrà applicato al solo tipo di consenso indicato
• Oscuramento: valore eventualmente da transcodificare, viene valorizzato nel caso in cui sia necessario oscurare un oggetto per motivi noti all’applicativo chiamante
• Info_oscuramento: note testuali relative all’oscuramento
• Modificabile: indica se l’oscuramento possa essere rimosso a scelta dell’interessato oppure no (il default è NO)
STANDARD: XML
SCENARIO DI ESEMPIO: N.D.
DESCRIZIONE: permette ad un applicativo di rimuovere o annullare un oscuramento applicato in precedenza ad un oggetto per una particolare motivazione.
FLUSSO: l’utente di applicativo verticale, una volta autenticato, procede al recupero dei precedenti consensi forniti. L’applicativo verticale rileva che non esiste più una situazione da tutelare tramite anonimato (tale rilevamento può essere automatico e basato su configurazioni oppure lasciato a segnalazione dell’utente umano); come conseguenza annulla l’oscuramento dei relativi documenti. Il sistema ritorna l’ACK dell’operazione eseguita.
DATI SCAMBIATI: di seguito i parametri per il funzionamento:
• Applicativo chiamante: se null 🡪 errore
• Funzionalità chiamante: se null, la funzionalità considerata è annulla_oscuramento
• Utente connesso: se null 🡪 errore
• Attore (tipicamente unità organizzativa)
• Tipologia di oggetto (valore eventualmente da transcodificare): se null🡪 errore
• Identificativo univoco oggetto: se null 🡪 errore
• Identificativo univoco paziente: se null 🡪 errore
• Tipo_oscuramento: se null🡪 errore
STANDARD: XML
SCENARIO DI ESEMPIO: N.D.
DESCRIZIONE: permette ad un applicativo di ottenere dal MGC uno o più consensi legati ad un oggetto, eventualmente sfruttando regole di ereditarietà
FLUSSO: l’utente di applicativo verticale, una volta autenticato, procede al recupero dei diversi consensi legati a un oggetto. Il sistema restituisce:
• Il consenso richiesto, valido alla data specificata (o a quella attuale, se nessuna data indicata), nel caso in cui la richiesta indichi un specifico tipo di consenso
• Tutti i consensi dell’oggetto validi alla data specificata (o a quella attuale, se nessuna data indicata), nel caso in cui la richiesta NON indichi un specifico tipo di consenso
DATI SCAMBIATI: di seguito i parametri per il funzionamento:
• Applicativo chiamante: se null 🡪 errore
• Funzionalità chiamante: se null, la funzionalità considerata è ricerca_consensi
• Utente connesso: se null 🡪 errore
• Attore (tipicamente unità organizzativa)
• Tipologia di oggetto (valore eventualmente da transcodificare): se null🡪 errore
• Identificativo univoco oggetto: se null 🡪 errore
• Identificativo univoco paziente: se null 🡪 errore
• Tipologia di consenso: (valore eventualmente da transcodificare) in caso di ricerca generica, avrà valore null. In caso contrario la ricerca sarà limitata al tipo di consenso indicato
• Data di riferimento: data alla quale il consenso deve risultare valido (cioè non scaduto). Se null, il sistema la interpreta come la data odierna
• Tipologia di oggetto padre: (valore eventualmente da transcodificare) , anche null
• Identificativo univoco oggetto padre, anche null
• Token: in base alla configurazione predisposta per l’applicativo chiamante, può essere obbligatorio
• subjectRole: ruolo dell’utente
• struttura: codifica della struttura cui afferisce l’utente
• requestorId: GUIDFSE dell’interessato o del genitore/tutore/rappresentante legakle che richiede la ricerca
• Dichiarante: indicato se è diverso dall’interessato
• Dati accessori: questa sezione viene replicata una volta per ogni dato accessorio registrato
o id: sarà valorizzato con il codice del tipo di dato accessorio, come specificato nella tabella di pagina 79
o valore: sarà valorizzato con il valore del dato accessorio, come specificato nella tabella di pagina 79
o descr: sarà valoirzzato ocn la decsrizione estesa del dato accessorio
STANDARD: XML
SCENARIO DI ESEMPIO: si veda il par. 4.6.1.2.1, in quanto il diagramma lì descritto vale anche per la tipologia di consenso in oggetto, presa sia singolarmente che complessivamente.
4.6.1.2.5 Acquisisci visibilità
DESCRIZIONE: permette ad un applicativo esterno di sapere se un dato attore può o meno vedere un dato oggetto, sia in base al consenso espresso dall’interessato, sia in base ad eventuali oscuramenti applicati.
FLUSSO: l’applicativo verticale necessita di sapere se l’utente connesso può o meno avere accesso ad un dato oggetto, quindi chiede al MGC la visibilità di tale oggetto per la struttura dell’utente.
DATI SCAMBIATI: di seguito i parametri per il funzionamento:
• Applicativo chiamante: se null 🡪 errore
• Funzionalità chiamante: se null, la funzionalità considerata è get_visibilita
• Utente connesso
• Attore: se null 🡪 errore
• Data di riferimento
I dati che seguono possono essere indicati così oppure raggruppati all’interno di un tag <oggetto> ripetibile. Questa seconda modalità è consigliata ovunque si voglia effettuare un’unica chiamata al servizio per acquisire la visibilità di più oggetti.
• Tipologia di oggetto (valore eventualmente da transcodificare): se null🡪 errore
• Identificativo univoco oggetto: se null 🡪 errore
• Identificativo univoco paziente: se null 🡪 errore
• Tipologia di oggetto padre (valore eventualmente da transcodificare)
• Identificativo univoco oggetto padre
STANDARD: XML
SCENARIO DI ESEMPIO: si veda il diagramma di sequenza illustrato al par. 4.4.1.
DESCRIZIONE: permette ad un applicativo esterno di copiare i consensi di un oggetto su un altro (tipicamente dall’oggetto padre al figlio), limitatamente ad un contesto e inserendo il secondo oggetto se non censito. Nel contesto di Regione Marche, viene utilizzato dal verticale per propagare i consensi registrati in relazione all’episodio su ogni documento che ne scaturisce
FLUSSO: l’applicativo verticale necessita di propagare i consensi registrati in relazione all’episodio su ogni documento che ne scaturisce
DATI SCAMBIATI: di seguito i parametri per il funzionamento:
• Applicativo chiamante: se null 🡪 errore
• Funzione: può esser null solo se il tipo di consenso non lo è. Se è indicata la funzione, i consensi copiato saranno tutti e soli quelli previsti dal contesto applicativo-funzione
• Utente connesso: se null 🡪 errore
• Attore (tipicamente unità organizzativa)
• Tipologia di oggetto padre(valore eventualmente da transcodificare): se null🡪 errore
• Identificativo univoco oggetto padre: se null 🡪 errore
• Identificativo univoco paziente: se null 🡪 errore
• Tipologia di oggetto figlio: (valore eventualmente da transcodificare): se null🡪 errore
• Identificativo univoco oggetto figlio: se null🡪 errore
• Autore: dell’oggetto figlio, viene considerato solo per nuovi oggetti
• Tipologia di consenso: (valore eventualmente da transcodificare) può esser null solo se la funzione non lo è. Se è indicato il tipo di consenso, verrà copiato solo quello
STANDARD: XML
SCENARIO DI ESEMPIO: N.D.
DESCRIZIONE: permette ad un applicativo esterno di richiedere la creazione di un documento di consenso in formato CDA (imbustato con foglio di stile e pdf). Nel contesto di Regione Marche, viene utilizzato dal verticale per ottenere il CDA da far firmare all’utente, dopo aver registrato o aggiornato i consensi del cittadino.
FLUSSO: l’applicativo verticale invoca il ws
DATI SCAMBIATI: di seguito i parametri per il funzionamento:
• Applicativo chiamante: se null 🡪 errore
• Utente connesso: se null 🡪 errore
• Identificativo univoco paziente: se null 🡪 errore
• Identificativo univoco oggetto: se null🡪 errore
• Tipologia di oggetto: se null🡪 errore
• Token: in base alla configurazione predisposta per l’applicativo chiamante, può essere obbligatorio
• datiAnagrafici: tutti i sotto-tag vanno valorizzati
o cognome
o nome
o codiceFiscale
o sesso (MAS, FEM, NDF)
o dataDiNascita (YYYY-MM-DD)
o luogoDiNascita (testuale)
o indirizzoDiResidenza
o civicoDiResidenza
o comuneDiResidenza
o provinciaDiResidenza
o capDiResidenza
• usaToken: se SI implica la generazione di una busta MIME che contenga, oltre al CDA, allo stylesheet e al pdf corrispondente, anche il token dell’utente connesso
• archivia: se SI implica l’invio del file generato al repository
• subjectRole: ruolo dell’utente
• struttura: codifica della struttura cui afferisce l’utente
• requestorId: GUIDFSE dell’interessato o del genitore/tutore/rappresentante legakle che richiede la ricerca
• idDisclosure: identificativo dell’informativa, obbligatorio in caso di archiviazione del documento
STANDARD: XML
SCENARIO DI ESEMPIO: N.D.
4.6.1.2.8 Registra Documento Firmato
DESCRIZIONE: permette ad un applicativo esterno di archiviare nel database del Modulo Gestione Consenso un documneto di consenso firmato digitalmente. Nel contesto di Regione Marche, viene utilizzato dal verticale per archiviare i documenti firmati, in modo che poi sia il MGC a versionarli e archiviarli nel repository regionale.
FLUSSO: l’applicativo verticale invoca il ws passandogli un documneto firmato da archiviare
DATI SCAMBIATI: di seguito i parametri per il funzionamento:
• Applicativo chiamante: se null 🡪 errore
• Utente connesso: se null 🡪 errore
• Identificativo univoco paziente: se null 🡪 errore
• Identificativo univoco oggetto: se null🡪 errore
• Tipologia di oggetto: se null🡪 errore
• Token: in base alla configurazione predisposta per l’applicativo chiamante, può essere obbligatorio
• uniqueId: se null🡪 errore
• firmatario: se null🡪 errore
• documentoBase64: se null🡪 errore
STANDARD: XML
SCENARIO DI ESEMPIO: N.D.
4.6.1.3 Gestione dell’oscuramento
Il cittadino per oscurare tutti i propri documenti ad uno o più enti che possono accedere al FSE deve semplicemente impostare a NO i consensi alla consultazione del suo FSE e lo potrà fare tramite il portale del cittadino o tramite un operatore abilitato (ad esempio il medico di base).
Invece l’oscuramento di un singolo documento può avvenire:
• A posteriori, ovvero dopo la creazione ed archiviazione del documento nel FSE
• A priori, ovvero prima che venga prodotto il documento (solitamente all’atto della prestazione o prenotazione)
• In modo forzato, per garantire la tutela delle situazioni super-sensibili
E’ evidente che la modalità “A posteriori” può essere attivata sia dai verticali che richiamano il modulo che da Portale
La modalità “Oscuramento forzato”, descritta in coda al paragrafo, viene attivata esclusivamente su iniziativa dai verticali che richiamano il modulo
Di seguito si descrive quali webservices utilizzare per comunicare le tre tipologie di oscuramento descritte
4.6.1.3.1 Oscuramento a posteriori
Questa situazione si presenta, ad esempio, nella consultazione dei referti su portale del cittadino. L’applicativo chiamante deve invocare il ws ricercaConsensi passando come oggetto il documento e come oggetto padre l’anagrafica. Se non viene restituito alcun consenso, significa che il cittadino non ha mai espresso un consenso relativo al FSE, pertanto l’oscuramento non ha senso (e, di fatto, non è possibile vedere i referti da portale).
In caso contrario, i consensi relativi alla consultazione del documento da gestire sono:
- FSERM_MMG_PLS: Consenso alla consultazione del FSE da parte del proprio medico di medicina generale/pediatra di libera scelta
- FSERM_MMG_PLS_1: Consenso alla consultazione del FSE da parte di ogni sostituto del proprio medico di medicina generale/pediatra di libera scelta
- FSERM_MMG_PLS_2: Consenso alla consultazione del FSE da parte dei medici associati al proprio medico di medicina generale/pediatra di libera scelta
- FSERM_OP_ASUR: Consenso alla consultazione del FSE da parte degli operatori del Sistema Sanitario della Regione Marche, limitatamente ai dati trattati nell'ambito delle proprie competenze, afferenti all'Azienda Sanitaria Unica Regionale-ASUR
- FSERM_OP_AOOR: Consenso alla consultazione del FSE da parte degli operatori del Sistema Sanitario della Regione Marche, limitatamente ai dati trattati nell'ambito delle proprie competenze, afferenti all'Azienda ospedaliero - universitaria 'Ospedali Riuniti di Ancona'
- FSERM_OP_AOSS: Consenso alla consultazione del FSE da parte degli operatori del Sistema Sanitario della Regione Marche, limitatamente ai dati trattati nell'ambito delle proprie competenze, afferenti all'Azienda ospedaliera 'Ospedali Riuniti Marche Nord'
- FSERM_OP_INRCA: Consenso alla consultazione del FSE da parte degli operatori del Sistema Sanitario della Regione Marche, limitatamente ai dati trattati nell'ambito delle proprie competenze, afferenti all'Istituto di ricovero e cura a carattere scientifico-INRCA Ancona'
Per ognuno di questi consensi va utilizzato poi il ws aggiornaConsensoSingolo in passando come oggetto il documento.
4.6.1.3.2 Oscuramento a priori
Questa situazione si verifica, ad esempio, quando il cittadino si presenta per una prestazione e chiede che i referti che ne scaturiranno siano oscurati nel suo FSE. In tal caso sono possibili due diversi utilizzi dei ws del Modulo Gestione Consenso, una in due fasi ed una in fase unica.
4.6.1.3.2.1 Modalità in due fasi
La prima fase di lavoro si ha quando viene prenotata oppure effettuata la prestazione. Il verticale deve effettuare la ricerca dei consensi del cittadino tramite il ws ricercaConsensi. Se il consenso all’attivazione e alimentazione del FSE non risulta espresso oppure è negativo, non ha senso prevedere alcun oscuramento. In caso contrario il verticale può registrare la volontà di oscuramento con il ws aggiornaConsensoSingolo (uno per ognuno dei consensi alla consultazione del capitolo precedente), usando come oggetto “transitorio” un episodio univocamente identificato. Le modalità e le regole di identificazione saranno opportunamente definite e adeguatamente pubblicate
La seconda fase di lavoro si ha nel momento in cui vengono prodotti i referti legati all’episodio in questione. In tale momento l’oscuramento va propagato dall’episodio ai documenti invocando il ws copiaConsensi una volta per ogni documento, usando l’episodio come oggetto padre.
Nel caso in cui venga prodotta una nuova versione del documento, va nuovamente invocato il ws di
copiaConsensi, ma indicando la nuova versione come oggetto e la versione precedente come oggetto padre.
4.6.1.3.2.2 Modalità fase unica
In questa modalità la registrazione della richiesta di oscuramento rimane sul verticale non viene propagata al Modulo Gestione Consenso. Nel momento in cui c’è la produzione di un documento, il verticale deve quindi verificare che il cittadino abbia espresso consenso positivo all’attivazione e alimentazione del suo FSE, tramite il ws ricercaConsensi. In caso negativo, non serve fare nulla; in caso affermativo, tutti i consensi alla consultazione (elencati nel capitolo 4.6.1.3.1) vanno impostati a NO con il ws aggiornaConsensoSingolo, passando come oggetto il documento e come oggetto padre l’anagrafica.
Nel caso in cui venga prodotta una nuova versione del documento, va nuovamente invocato il ws di
copiaConsensi, ma indicando la nuova versione come oggetto e la versione precedente come oggetto padre.
Questa situazione si verifica se all’atto della creazione del documento si rileva che contenga informazioni talmente sensibili da essere tutelate con l’anonimato. Questa circostanza sarà gestita dal verticale che recepisce l’esigenza e che, conseguentemente, utilizzerà il ws oscuraOggetto, passando come oggetto il documento.
4.7 Ulteriori servizi previsti
4.7.1 Servizi di gestione degli eventi
DESCRIZIONE: Il servizio di gestione eventi è orchestrato e strutturati secondo le logiche del protocollo di integrazione DSUB. Lo scopo del profilo di integrazione DSUB (Document Metadata Subscription) è condividere con gli attori e con i sistemi che afferiscono ad un’infrastruttura XDS la disponibilità di un nuovo documento. La modalità di integrazione definita dal profilo prevede la creazione di un sistema modulare di notifica e sottoscrizione applicabile agli attori previsti nel dominio.
La logica DSUB permetterà la gestione delle sottoscrizioni, del contenuto delle notifiche e della modalità di distribuzione della notifica stessa ai sottoscrittori del sistema. La notifica non contiene il documento, ma solo i riferimenti alle informazioni specificate sui metadati e i riferimenti al documento stesso.
La sottoscrizione ad un “topic” di interesse potrà avvenire con due modalità:
• WS (Web Services) autenticati secondo le modalità definite dalla piattaforma X1.V1 (WS Authentication) .
Questa modalità prevede che il contenuto applicativo del messaggio sia coerente con quanto previsto dallo standard. In aggiunta è prevista la gestione di un elemento opzionale SubscriptionPolicy per consentire la corretta gestione delle policy da associare ad una sottoscrizione.
• GUI (Graphic User Interface) protetta da SSO (Single Sign On) X1.V1. Questa modalità sarà destinata agli amministratori del sistema che potranno modificare ed eliminare tutte le sottoscrizioni comprese quelle effettuate con la modalità a servizi definite al punto precedente. L’amministratore potrà definire nuove sottoscrizioni indicando il destinatario, la modalità di invio e le policy alle quali è soggetta la notifica.
Le modalità di invio della notifica sono sostanzialmente due:
a) Metodo Push Style:
Alla pubblicazione di un documento il componente DSUB verifica che siano soddisfatti gli specifici criteri definiti all’atto della sottoscrizione da parte di un attore (Document Metadata Subscriber: vedi definizione nel paragrafo “Concetti principali”) e procede con l’invio di una notifica relativa alla disponibilità di un documento. Lo scopo del Subscriber è quello di sottoscrivere se stesso o un ricevente alla ricezione di notifiche. La notifica sarà inviata utilizzando la modalità Push a fronte della registrazione di un documento sul Registry XDS di piattaforma.
L’invio della notifica ai Riceventi viene gestita dal componente Broker (Document Metadata Notification Broker) che si occupa delle operazioni di dispaching.
Tuttavia la modalità Push non permette la schedulazione delle attività di recupero notifiche che avvengono in modo disomogeneo ogni qual volta viene registrato un documento su XDS.
A fronte di questa considerazione è previsto un metodo Pull.
b) Metodo Pull-Style:
Per svincolarsi dalle limitazioni del metodo Push-Style, un attore che intende fruire delle notifiche (Notification Puller) può procedere con la creazione di un una risorsa definita Pull-Point che è in grado di memorizzare le notifiche generate dal Notification Broker per uno specifico Ricevente.
Il notification Pull Point, a fronte di una transazione sollecitata dal notification puller, (quindi sotto una precisa request) è in grado di rispondere adeguatamente con l’invio della notifica al Ricevente preposto alla sua ricezione.
FLUSSO: Il seguente schema descrive le relazioni fra gli attori e le transazioni previste dai profili IHE le cui specifiche di dettaglio sono riportate nel seguito.
Figura 36 – Schema transazioni e attori DSUB
Document Metadata Subscriber
Un attore in grado di creare e annullare le sottoscrizioni per se stesso oppure per un ricevente (Document Metadata Recipient). All’interno del profilo XDS quindi al Subscriber è sempre associato un Consumer.
Document Metadata Publisher
Un modulo in grado di eseguire la transazione di pubblicazione verso il Broker relativamente agli eventi definiti. All’interno dell’affinity domain XDS un publisher è associato al Document Registry XDS.