PROGETTO ESECUTIVO DI DETTAGLIO

Gara per l’acquisizione di beni e servizi relativi al Sistema Informativo Sanitario e Socio-Sanitario della Regione Marche

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:	5.3
Data:	22 maggio 2015	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.

INDICE

1 INTRODUZIONE 7

1.1 Scopo del documento 7

1.2 Documenti di riferimento 7

1.3 Approccio 7

1.4 Acronimi 7

1.5 Struttura del documento 10

2 CONTESTO DI RIFERIMENTO 10

3 GENERALITA’ 12

3.1 Standard tecnici 12

3.2 Linguaggio comune 12

3.3 Web Services 12

3.4 WSDL (Web Service Description Language) 13

3.5 Schemi XSD 13

3.6 Messaggistica HL7 utilizzata 13

3.7 Cross-Enterprise Document Sharing - XDS (IHE) 14

3.8 Protocollo di trasporto utilizzato 14

4 SERVIZI ESPOSTI DALL’INFRASTRUTTURA 16

4.1 Servizio di Autenticazione, Profilazione e Autorizzazione (categoria “funzioni di controllo accessi e sicurezza”) 21

4.1.1 Servizio di Autenticazione 22

4.1.2 Servizio di Profilazione 22

4.1.3 Servizio di Autorizzazione 23

4.2 Servizi Anagrafici (categoria “funzioni di identificazione”) 25

4.2.1 Servizio di Ricerca anagrafica 30

4.2.2 Servizio di Censimento di nuova anagrafica 31

4.2.3 Servizio di Aggiornamento di una anagrafica 32

4.2.4 Servizio di Unificazione di anagrafiche 33

4.2.5 Servizio di Notifica eventi ai nodi cooperanti 34

4.2.6 Servizio di Aggiornamento cataloghi centralizzati 35

4.2.7 Servizio di Notifica variazione catalogo 36

4.2.8 Descrizione dati anagrafici 37

4.2.9 Descrizione dati dei cataloghi 40

4.2.10 Futura implementazione di interfacce con tecnologia HL7 V3 52

4.3 Servizi di Alimentazione Dati e Documenti (categorie “funzioni di alimentazione” e “funzioni

indicizzazione documenti”) 54

4.3.1 Servizio di Firma Digitale Remota 55

4.3.2 Servizio di Verifica Remota Firma Digitale 59

4.3.3 Servizio di Ricezione Documento su Repository Documentale/FSE 61

4.3.4 Servizio di modifica dei metadati “locali” 64

4.3.5 Servizio di Ricezione Dati di Laboratorio Urgenti (non “firmati”) 65

4.3.6 Servizio di indicizzazione documenti su Registry Regionale FSE 65

4.4 Servizi di Consultazione dati e documenti (categoria “funzioni di ricerca e recupero

documenti”) 67

4.4.1 Servizio di Ricerca Documenti su FSE 68

4.4.2 Servizio di Retrieve Documento da FSE 69

4.4.3 Servizio di Ricerca su Repository Locale (firmato e non – dati) 70

4.4.4 Servizio di Retrieve Documento da Repository Locale (firmato e non - dati) 71

4.4.5 Servizio di Recupero Risultati Precedenti di Laboratorio 72

4.6 Servizi di gestione del Consenso (categoria “funzioni di gestione del consenso”) 73

4.6.1.1 Servizio Chiamata Applicativa di Contesto 74

4.6.1.2 Servizi web (ws) 77

4.6.1.2.1 Aggiorna consenso singolo 77

4.6.1.2.2 Oscura oggetto 79

4.6.1.2.3 Annulla oscuramento 80

4.6.1.2.4 Ricerca consensi 81

4.6.1.2.5 Acquisisci visibilità 81

4.7 Ulteriori servizi previsti 82

4.7.1 Servizi di gestione degli eventi 82

4.7.2 Servizio di alimentazione del Polo di Conservazione Regionale 85

5 SPECIFICHE TECNICHE 87

5.1 Servizio di Autenticazione e Profilazione 87

5.1.1 Servizio di Autenticazione 87

5.1.2 Servizio di Profilazione 87

5.1.2.1 Implementazione 87

5.1.2.2 Messaggi d’errore 87

5.1.2.3 Esempi di Request e Response del Servizio 89

5.1.2.4 Flusso di gestione Ruoli / Utenti 95

5.1.2.4.1 Gestione Utenti 95

5.1.2.4.2 Gestione Ruoli 95

5.1.2.4.3 Gestione associazione Ruoli / Utenti 95

5.1.2.5 Principi generali dei Servizi di Alimentazione 95

5.1.2.5.1 Request 96

5.1.2.5.2 Response 96

5.1.2.5.3 Query Continuation 97

5.1.2.5.4 Gestione Utenti 97

5.1.2.5.5 Gestione Ruoli 100

5.1.2.5.6 Gestione Associazioni Utenti/Ruoli 100

5.1.3 Servizio di Autorizzazione 101

5.1.4 Servizio di Autorizzazione 101

5.1.4.1 Funzionalità della Policy 102

5.1.4.1.1 Excpected Action 103

5.1.4.2 Fase della Policy 104

5.1.4.2.1 Excpected Action 104

5.1.4.3 Advise 105

5.1.4.3.1 Excpected Action 106

5.1.4.4 Obbligations 107

5.1.4.4.1 Excpected Action 108

5.1.4.5 Policy Attuali 109

5.1.4.5.1 Auth matrix 109

5.1.4.5.2 Profile 110

5.1.4.6 Servizi e Policy 111

5.1.4.7 Appendici 112

5.1.4.7.1 Standard XACML attributes 112

5.1.4.7.2 Standard RTI 114

5.2 Servizi Anagrafici e cataloghi 115

5.2.1 Note tecniche generali 115

5.2.2 Servizio di Ricerca anagrafica 117

5.2.3 Servizio di Censimento anagrafica 127

5.2.4 Servizio di Aggiornamento di una anagrafica 130

5.2.5 Servizio di Unificazione anagrafica 134

5.2.6 Servizio di Notifica variazioni anagrafica 137

5.2.7 Servizio di Aggiornamento catalogo 138

5.2.8 Servizio di Notifica variazione catalogo 139

5.3 Servizi di Alimentazione Dati e Documenti (categorie “funzioni di alimentazione” e “funzioni

indicizzazione documenti”) 142

5.3.1 Servizio di Firma Digitale Remota 142

5.3.2 Servizio di Verifica Remota Firma Digitale 143

5.3.3 Servizio di Ricezione Documento su Repository Documentale/FSE 144

5.3.4 Servizio di modifica dei metadati “locali” 144

5.3.5 Servizio di Ricezione Dati di Laboratorio Urgenti (non “firmati”) 144

5.3.6 Servizio di indicizzazione documenti su Registry Regionale FSE 145

5.4 Servizi di Consultazione dati e documenti (categoria “funzioni di ricerca e recupero

documenti”) 145

5.4.1 Servizio di Ricerca Documenti su FSE 145

5.4.2 Servizio di Retrieve Documento da FSE 147

5.4.3 Servizio di Ricerca su Repository Locale (firmato e non – dati) 147

5.4.4 Servizio di Retrieve Documento da Repository Locale (firmato e non - dati) 148

5.5 Servizio di gestione del Consenso 148

5.6 Ulteriori servizi previsti 150

5.6.1 Servizi di gestione degli eventi 150

5.6.1.1 Transazioni previste. 150

5.6.1.1.1 – ITI-52 Document Metadata Subscribe 150

5.6.1.1.2 – ITI-53 Document Metadata Notify (Push-style) 152

5.6.1.1.3 – ITI 69 Create/Destroy Pull Point 152

5.6.1.1.4 –ITI-70 Notification Pull: (Pull-style) 153

5.6.1.2 Messaggi di esempio 153

5.6.1.2.1 Messaggio di sottoscrizione (SubScribe Request Message) 153

5.6.1.2.2 Messaggio di creazione PullPoint 155

5.6.2 Servizio di alimentazione del Polo di Conservazione Regionale 156

6 ALLEGATI 157

1 INTRODUZIONE

1.1 Scopo del documento

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.

1.2 Documenti di riferimento

Questo documento costituisce un allegato al Progetto Esecutivo – EXA del Lotto 1.

1.3 Approccio

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.

1.4 Acronimi

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.

1.5 Struttura del documento

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’

3.1 Standard tecnici

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

3.2 Linguaggio comune

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

3.3 Web Services

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.

3.5 Schemi XSD

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

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".

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

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.2 “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 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)

Una descrizione preliminare del servizio è contenuta nel capitolo 4.7.2 “Servizio di alimentazione del Polo di Conservazione Regionale”. Verrà dettagliata a valle dell’attività di analisi e definizione esatta del contenuto informativo dei messaggi che dovranno essere trasmessi al Polo.

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 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”.

Si riporta in seguito un elenco dei cataloghi individuati e resi disponibili. Va considerato che inizialmente i cataloghi con “fonte ISTAT” verranno reperiti dalla piattaforma ARCA di ASUR Marche, in attesa di definire con Regione Marche una eventuale fonte alternativa di gestione del dato proveniente da ISTAT.

SISTEMA ALIMENTANTE ASR-EMPI (Fonte del catalogo)	CATALOGO
MEF- SistemaTS1 (da file FMED)	OPERATORI FSE (MMG/PLS/Convenzionati/Dipendenti ed eventuali altri operatori FSE registrati sulla piattaforma TS )
AREAS-DWH	PRODOTTI (FARMACI, DISPOSITIVI MEDICI e NOMENCLATORI PROTESICA) FARMACI (da Farmadati) OPERATORI FSE ISTITUTI
ARCA	SPECIALIZZAZIONI MMG/PLS
ISTAT	STATI CIVILI
ARCA	RUOLI NUCLEO FAMILIARE
ARCA	MOTIVI ESENZIONE

1 Si precisa che è disponibile il catalogo OPERATORI FSE da fonte SistemaTS, tuttavia il progetto Lotto 1 prevede una diversa fonte dati del catalogo ovvero il DWH regionale.

SISTEMA ALIMENTANTE ASR-EMPI (Fonte del catalogo)	CATALOGO
ISTAT	COMUNI E STATI ESTERI
ISTAT	NAZIONALITA
ISTAT	PROFESSIONI
ISTAT	CONDIZIONI PROFESSIONALI
ARCA	TITOLI DI STUDIO
ARCA	DISTRETTI
ARCA	REGIONI
ARCA	ASL
ARCA	AMBITI SCELTA
ARCA	ABBINAMENTO COMUNI-DISTRETTI
ARCA	ABBINAMENTO COMUNI-ASL
ARCA	ABBINAMENTO COMUNI-AMBITI SCELTA
CUP	CATALOGO PRESTAZIONI2

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.

2 Si precisa che il catalogo PRESTAZIONI in realtà è scomposto in 3 distinti dizionari : PRESTAZIONI, ABBINAMENTO BRANCHE-PRESTAZIONI, ABBINAMENTO PRESTAZIONI-ESENZIONI.

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 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.3 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 :

: 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: ApplicativoVerticale 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)

b) nessun soggetto in quanto non esiste una referenza in ASR-EMPI che soddisfa i criteri di selezione inviati.

DATI SCAMBIATI: Si faccia riferimento al paragrafo 4.2.8 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 con localizzazione italiana fornita da HL7 Italia; 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.

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, 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 trasmette ad ASR-EMPI i dati di profilo del soggetto; il servizio restituisce un messaggio di ricezione del censimento di nuova anagrafica e registra il soggetto su ASR-EMPI (o ne identifica uno già esistente) calcolandone il relativo codice unico regionale (GUIDFSE). Successivamente il sistema ASR-EMPI provvede a restituire il GUIDFSE ad ApplicativoVerticale tramite il servizio di notifica variazioni anagrafiche (NotificaDati), predisponendo la notifica anche per gli altri nodi cooperanti.

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.

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; 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).

STANDARD: Lo standard di riferimento del servizio di Aggiornamento di una Anagrafica in ASR-EMPI è HL7

2.5 XML con localizzazione italiana fornita da HL7 Italia; occorre produrre la compilazione di un Messaggio di variazione anagrafica del tipo ADT^A31.

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

DESCRIZIONE: un utente di ApplicativoVerticale 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 viene poi notificata ad ASR- EMPI.

FLUSSO: ApplicativoVerticale attiva il servizio di unificazione anagrafica trasmettendo 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).

STANDARD: Lo standard di riferimento del servizio di Aggiornamento di una Anagrafica in ASR-EMPI è HL7

2.5 XML con localizzazione italiana fornita da HL7 Italia; occorre produrre la compilazione di un Messaggio di variazione anagrafica del tipo ADT^A40.

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 anagrafica in ASR-EMPI sopra descritto.

Figura 15: sequence diagram – unificazione anagrafica su ASR-EMPI

4.2.5 Servizio di Notifica eventi ai nodi cooperanti

DESCRIZIONE: il sistema ASR-EMPI provvede a notificare agli altri “nodi” cooperanti le movimentazioni anagrafiche recepite sulla propria piattaforma.

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 interessati a ricevere tale notifica. I “nodi” riceventi tratteranno l’informazione ricevuta secondo le proprie politiche locali di gestione anagrafica.

STANDARD: Lo standard di riferimento del servizio di Notifica variazioni Anagrafiche in ASR-EMPI è HL7

2.5 XML con localizzazione italiana fornita da HL7 Italia; 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.

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 16: sequence diagram – notifica dati 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.9 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 17: 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.

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 18: sequence diagram – notifica di variazione catalogo da ASR-EMPI

4.2.8 Descrizione dati anagrafici

Vengono riportati a seguire i dati anagrafici gestiti da ASR-EMPI e inviati nei messaggi supportati dalla presente versione del protocollo di integrazione, associati al campo (segmento e sequenza) del messaggio HL7 di riferimento.

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

Nome campo	Descrizione	Caratteristiche	Dimensioname nto	Riferimento a segmento HL7
CHIAVE IDENTIFICATIVA	Chiave identificativa unica regionale del profilo anagrafico (GUIDFSE)	Obbligatorio	Alfanumerico (16)	PID 3
COGNOME	Cognome	Obbligatorio	Alfanumerico (50)	PID 5.1
NOME	Nome	Obbligatorio	Alfanumerico (50)	PID 5.2
SESSO	Sesso Assume i valori M o F	Obbligatorio	Alfanumerico (1)	PID 8
DATA NASCITA	Data di nascita	Obbligatorio	Data [YYYYMMGG]	PID 7
COMUNE NASCITA	codice ISTAT del comune di nascita (concatenazione di provincia nascita e comune nascita, rif. CATALOGO COMUNI E STATI ESTERI)	Obbligatorio	Numerico (6)	PID 11.9
CODICE FISCALE	Codice Fiscale	Obbligatorio	Alfanumerico (16)	PID 3.1
DATA DECESSO	Data decesso	Facoltativo	Data	PID 29

Nome campo	Descrizione	Caratteristiche	Dimensioname nto	Riferimento a segmento HL7
			[YYYYMMGG]
SCADENZA ASSISTENZA	Data Scadenza tessera sanitaria	Facoltativo	Data [YYYYMMGG]	PID 3.8
NAZIONALITA’	Codice nazionalità (rif. CATALOGO NAZIONALITA)	Obbligatorio	Alfanumerico (3)	PID 26
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)	PID 11.9
RESIDENZA LOCALITA’	Località di residenza	Facoltativo	Alfanumerico (50)	PID 11.2
RESIDENZA INDIRIZZO	Indirizzo di residenza	Facoltativo	Alfanumerico (50)	PID 11.1
RESIDENZA CAP	CAP	Facoltativo	Alfanumerico (5)	PID 11.5
RESIDENZA REGIONE	Codice Regione (rif. CATALOGO REGIONI)	Facoltativo	Numerico (3)	PID 11.8
RESIDENZA PROVINCIA	Sigla Provincia	Facoltativo	Alfanumerico (2)	PID 11.4
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)	PID 11.9
DOMICILIO LOCALITA’	Località di domicilio		Alfanumerico (50)	PID 11.2
DOMICILIO INDIRIZZO	Indirizzo di domicilio		Alfanumerico (50)	PID 11.1
DOMICILIO CAP	CAP		Alfanumerico (5)	PID 11.5
DOMICILIO REGIONE	Codice Regione di assistenza sanitaria (rif. CATALOGO REGIONI)		Numerico(3)	PID 11.8
DOMICILIO PROVINCIA	Sigla Provincia		Alfanumerico (2)	PID 11.4
ASL ASSISTENZA	Codice ASL di assistenza sanitaria (rif. CATALOGO ASL)	Obbligatorio	Numerico (4)	PD1 3
ASL RESIDENZA	Codice ASL di residenza (rif. CATALOGO ASL)	Obbligatorio	Numerico (4)	PD1 3
RECAPITI TELEFONICI	Telefono 1	Facoltativo	Alfanumerico (20)	PID 13
RECAPITI TELEFONICI	Telefono 2	Facoltativo	Alfanumerico (20)	PID 13
STATO CIVILE	Codice dello stato civile (rif. CATALOGO STATI CIVILI)	Facoltativo	Numerico (2)	PID 16

Nome campo	Descrizione	Caratteristiche	Dimensioname nto	Riferimento a segmento HL7
PROFESSIONE	Professione (rif. CATALOGO PROFESSIONI)	Facoltativo	Numerico (5)	NK1 10
TITOLO STUDIO	Titolo di studio (rif. CATALOGO TITOLI DI STUDIO)	Facoltativo	Numerico (2)	PID 5.6
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)	PID 32
TESSERA TEAM	PIN (per paziente straniero)	Tutti Facoltativi; o tutti compilati o nessuno	Alfanumerico (20)	PID 3.1
	CIN (Card IdentificationNumber)		Alfanumerico (20)	PID 3.1
	Istituzione (Codice)		Alfanumerico (10)	PID 3.4.1
	Istituzione (Descrizione)		Alfanumerico (21)	PID 3.4.1
	Nazione		Alfanumerico (2)	PID 3.6.1
	Data scadenza TEAM		Data [YYYYMMGG]	PID 3.8
DATI STP	Codice STP	Tutti Facoltativi; o tutti compilati o nessuno	Alfanumerico (16)	PID 3.1
	Data rilascio del codice STP		Data [YYYYMMGG]	PID 3.7
	Indicazione di indigenza		Alfanumerico (1)	PD1 1
DATI NUCLEO FAMIGLIARE	Codice nucleo famigliare	Tutti Facoltativi; o tutti compilati o nessuno	Alfanumerico (20)	NK1 33
DATI NUCLEO FAMIGLIARE	Ruolo all’interno del nucleo famigliare (rif. CATALOGO RUOLI NUCLEO FAMILIARE)		Numerico (2)	NK1 3
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)	PV1 7.1 / ROL 3
	Codice fiscale medico base		Alfanumerico (16)	PV1 7.1
	Cognome medico base		Alfanumerico (50)	PV1 7.2

Nome campo	Descrizione	Caratteristiche	Dimensioname nto	Riferimento a segmento HL7
	Nome medico base		Alfanumerico (50)	PV1 7.3
	Codice della tipologia del medico di base (identifica se MMG o PLS) (rif. CATALOGO TIPI MEDICO)		Numerico (2)	ROL 3
	Data scelta del medico di base		Data [YYYYMMGG]	ROL 4
	Data revoca dal medico di base		Data [YYYYMMGG]	ROL 5
DATI ESENZIONE PATOLOGIA e/o REDDITO	Codici ISTAT dell’esenzione (rif. CATALOGO MOTIVI ESENZIONE)	Facoltativo	Alfanumerico (15)	PV1 20.1
DATI ESENZIONE PATOLOGIA e/o REDDITO	Data di scadenza del motivo esenzione	Facoltativo	Data [YYYYMMGG]	PV1 20.2
NODO COLLEGATO	Codice nodo inviante; la codifica viene stabilita in accordo fra Fornitori della piattaforma ASR- EMPI e nodo cooperante	Obbligatorio	Alfanumerico (8)	MSH-3

4.2.9 Descrizione dati dei cataloghi

Vengono riportati a seguire i dati dei cataloghi centralizzati gestiti da ASR-EMPI e inviati nei messaggi supportati dalla presente versione del protocollo di integrazione, associati al campo (segmento e sequenza) del messaggio HL7 di riferimento.

Tali dati sono comuni a tutti i servizi di gestione cataloghi supportati dalla piattaforma, per questo motivo vengono descritti una tantum in questo paragrafo.

Catalogo	OPERATORI FSE da fonte SistemaTS (codice catalogo = MEF_MEDICI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
CODICE_FISCALE	Codice fiscale del medico	Facoltativo	Alfanumerico (16)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
CODICE_REGIONE	Codice Regione	Facoltativo	Alfanumerico (3)
CODICE_ENTE	Codice ASL/AO di competenza	Facoltativo	Alfanumerico (3)
TIPO_SPECIALIZZA ZIONE	Tipo specializzazione. I valori possibili sono: A specialista ambulatoriale (ex SUMAI); B medico consulente; C specialista di struttura privata accreditata; D dipendente dei servizi territoriali ASL; F medico di medicina generale; G guardia medica; H ospedaliero;	Facoltativo	Alfanumerico (1)

Catalogo	OPERATORI FSE da fonte SistemaTS (codice catalogo = MEF_MEDICI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
	I medico INAIL; P pediatra di libera scelta; T guardia medica turistica; U medico di azienda ospedaliero- universitaria; X altro (tirocinanti, specializzandi, etc.); Z altra specializzazione.
DATA_INIZIO_ATTI VITA	Data inizio attività nella ASL/AO	Facoltativo	Data [YYYYMMGG]
CODICE_STRUTTUR A	Codice della struttura presso cui si svolge l’attività	Facoltativo	Alfanumerico (10)
CODICE_MEDICO	Codice identificativo del medico	Facoltativo	Alfanumerico (10)
STRUTTURA_DESC	Struttura presso cui si svolge l’attività	Facoltativo	Alfanumerico (50)
STRUTTURA_INDIR XXXX	Indirizzo studio medico/struttura (comprensivo di numero civico)	Facoltativo	Alfanumerico (50)
STRUTTURA_CAP	CAP studio medico/struttura	Facoltativo	Alfanumerico (5)
DATA_FINE_ATTIVI TA	Data fine attività nella ASL/AO	Facoltativo	Data [YYYYMMGG]
CODICE_FINE_ATTI VITA	Codice fine validità. I valori possibili sono: 0 aperto; 1 fine attività; 2 decesso; 3 annullamento posizione; 4 aggiornamento; 5 chiuso da batch; 99 altro.	Facoltativo	Numerico (3)
CODICE_RAGGRUP PAMENTO	Codice raggruppamento – medicina di gruppo	Facoltativo	Alfanumerico (16)
STRUTTURA_COMU NE_DESC	Comune ubicazione studio medico/struttura	Facoltativo	Alfanumerico (45)
STRUTTURA_PROVI NCIA_SIGLA	Sigla provincia ubicazione studio medico/struttura	Facoltativo	Alfanumerico (2)
COGNOME	Cognome del medico	Facoltativo	Alfanumerico (40)
NOME	Nome del medico	Facoltativo	Alfanumerico (40)
SESSO	Sesso del medico	Facoltativo	Alfanumerico (1)
DATA_NASCITA	Data di nascita del medico	Facoltativo	Data [YYYYMMGG]
COMUNE_NASCITA_ CATASTO	Codice catastale Comune o Stato estero di nascita del medico	Facoltativo	Alfanumerico (4)

Catalogo

OPERATORI FSE da fonte DWH (codice catalogo = PE_DIPENDENTE_CDC)

Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
PF_NOME	Nome del dipendente	Facoltativo	Alfanumerico (50)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
PF_COGNOME	Cognome del dipendente	Facoltativo	Alfanumerico (50)
SR_AZ	Azienda di appartenenza	Facoltativo	Alfanumerico (2)
PF_CFIS	Codice fiscale del dipendente	Facoltativo	Alfanumerico (50)
COD_INTERNO_DIP ENDENTE	Matricola del dipendente	Facoltativo	Alfanumerico (20)
COD_CDC	Codice centro di costo di appartenenza	Facoltativo	Alfanumerico (30)
DESC_CDC	Descrizione del CDC	Facoltativo	Alfanumerico (500)
TIPOLOGIA_CDC	Indica se centro di costo principale o secondario	Facoltativo	Alfanumerico (50)
PERC_CDC	Valore percentuale (da 0 a 100) di associazione del dipendente al cdc corrente	Facoltativo	Numerico (15)
IQ_CODICE	Codice tipologia rapporto. I valori possibili sono descritti assieme a quelli della relativa descrizione (colonna IQ_DESC)	Facoltativo	Alfanumerico (20)
IQ_DESC	Descrizione tipologia del rapporto. Di seguito i possibili valori associati al relativo codice (colonna IQ_CODICE) :	Facoltativo	Alfanumerico (80)
	TT_C001SENZA VINCOLO ORARIO
	TT_C002CONTRATTO A ORE
	TT_C100CONVENZIONE 100 ORE MENSILI
	TT_C120CONVENZIONE 120 ORE MENSILI
	TT_ER EREDE
	TT_IP INCARICO PROVVISORIO
	TT_OP ORARIO PIENO HH. 36
	TT_P001PART-TIME 50% HH.18
	TT_P002IR 50% HH.19
	TT_P003PART-TIME 97,22% HH.35
COD_QUALIFICA	Codice della qualifica. I valori possibili sono descritti assieme a quelli della relativa descrizione (colonna DESC_QUALIFICA)	Facoltativo	Alfanumerico (20)
DESC_QUALIFICA	Descrizione della qualifica. Di seguito i possibili valori associati al relativo codice (colonna COD_QUALIFICA) :	Facoltativo	Alfanumerico (80)
	ASVARI - ASSIMILATI VARI
	BOR - BORSISTA FANO

Catalogo	OPERATORI FSE da fonte DWH (codice catalogo = PE_DIPENDENTE_CDC)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
	BSTUDI - BORSA DI STUDIO
	COLPAR - COLLABORAZIONE PARASUBORDINATA
	COMCON - COMMISSARI CONCORSI
	CONUVA - NUCLEO DI VALUTAZIONE
	XXXXXX - DIRETTORE AMMINISTRATIVO
	XXXXXX - DIRETTORE GENERALE
	XXXXXX - DIRETTORE SANITARIO
	LAVOCC - LAVORO OCCASIONALE
COD_RUOLO	Codice del ruolo. I valori possibili sono descritti assieme a quelli della relativa descrizione (colonna DESC_RUOLO)	Facoltativo	Alfanumerico (20)
DESC_RUOLO	Descrizione del ruolo. Di seguito i possibili valori associati al relativo codice (colonna COD_RUOLO) :	Facoltativo	Alfanumerico (80)
	01 - SANITARIO
	01 - RUOLO SANITARIO
	02 - EMERGENZA SANITARIA TERRITORIALE
	02 - RUOLO PROFESSIONALE
	03 - RUOLO TECNICO
	04 - RUOLO AMMINISTRATIVO
	05 - RUOLO RELIGIOSO
	05 - BORSISTA
	88 - PENITENZIARIA LEGGE 740/1970
TIPO_RAPPORTO	Codice del tipo rapporto. I valori possibili sono :	Facoltativo	Alfanumerico (10)
	HR01- Xxxxxxxxxx
	XX00 - Medici e pediatri di libera scelta
	HR03 - Guardia medica
	HR04 - Specialisti ambulatoriale
	HR05 - Medicina dei servizi
	HR06 - Collaboratori coordinati
	HR08 - Universitari
COD_SEDE_SERVIZ IO	Codice della sede di servizio del dipendente	Facoltativo	Alfanumerico (30)
COD_NATURA_RAP P	Codice della natura del rapporto. I valori possibili sono descritti assieme a quelli della relativa descrizione (colonna DESC_NATURA_RAPP)	Facoltativo	Alfanumerico (20)
DESC_NATURA_RAP	Descrizione della natura del	Facoltativo	Alfanumerico (80)

Catalogo	OPERATORI FSE da fonte DWH (codice catalogo = PE_DIPENDENTE_CDC)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
P	rapporto. Di seguito i possibili valori associati al relativo codice (colonna COD_NATURA_RAPP) : 001 - A TEMPO DETER.-inc. art.15-septies D.lgs229/99 006 - A TEMPO DETERMINATO 008 - A TEMPO DETER.-INTERINO /POSTO VAC 009 - A TEMPO DETER.- STRAORDINARIO 010 - A TEMPO DETER.-SUPPLENTE 019 - A TEMPO INDETER. IND DI SOSTITUZIONE 020 - COMANDATO IN ENTRATA 021 - COMANDATO IN USCITA 022 - A TEMPO INDETER. CON INC. QUINQUENNALE 023 - A TEMPO INDETER. CON INC. SETTENNALE
COD_TIPO_DIP	Codice tipo dipendente. . I valori possibili sono descritti assieme a quelli della relativa descrizione (colonna DESC_TIPO_DIP)	Facoltativo	Alfanumerico (20)
DESC_TIPO_DIP	Descrizione tipo dipendente. Di seguito i possibili valori associati al relativo codice (colonna COD_TIPO_DIP) : BO - BORSISTA EM - MEDICO DI EMERGENZA TERRITORIALE GM - MEDICO DI CONTINUITA' ASSISTENZIALE GN - MEDICO DI ASSISTENZA TERR. PROGR. GT - MEDICO DI GUARDIA TURISTICA ME - MEDICO DI MEDICINA GENERALE MS - MEDICO DELLA MEDICINA DEI SERVIZI OD - MEDICO ODONTOIATRA PE - MEDICO PEDIATRA SP - MEDICO SPECIALISTA AMBULATORIALE	Facoltativo	Alfanumerico (80)
VALORE_ PT	Valore percentuale del part time	Facoltativo	Alfanumerico (50)
VT_DESC	Descrizione del tipo di part time	Facoltativo	Alfanumerico (60)
COD_ DISCIPLINA	Codice della disciplina	Facoltativo	Alfanumerico (50)
DESC_DISCIPLINA	Descrizione delle disciplina	Facoltativo	Alfanumerico

Catalogo	OPERATORI FSE da fonte DWH (codice catalogo = PE_DIPENDENTE_CDC)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
			(500)
COD_UN_ORGANIZ ZATIVA	Codice dell’unità organizzativa	Facoltativo	Alfanumerico (50)
DESC_UN_ORGANIZ ZATIVA	Descrizione dell’unità organizzativa	Facoltativo	Alfanumerico (500)
COD_REPARTO	Codice del reparto	Facoltativo	Alfanumerico (50)
DESC_REPARTO	Descrizione del reparto	Facoltativo	Alfanumerico (500)
DESC_INCARICO	Descrizione incarico economico	Facoltativo	Alfanumerico (50)
COD_INCARICO	Codice incarico economico	Facoltativo	Alfanumerico (500)
DATA_ABILITAZION E	Data abilitazione del rapporto di lavoro	Facoltativo	Data [GG/MM/YYYY]
DATA_CESSAZIONE	Data cessazione	Facoltativo	Data [GG/MM/YYYY]
COD_RAPP_SPEC	Tipo specializzazione (valori in definizione)	Facoltativo	Alfanumerico (1)

Catalogo	ISTITUTI – STS11 da fonte DWH (codice catalogo = ISTITUTO)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
CODISTIT	Codice istituto	Facoltativo	Alfanumerico (8)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
CODREG	Codice regione	Facoltativo	Alfanumerico (3)
CODAZ	Codice azienda	Facoltativo	Alfanumerico (3)
CODREGTERR	Codice regione territoriale	Facoltativo	Alfanumerico (3)
CODUSLTERR	Codice USL	Facoltativo	Alfanumerico (3)
DESCRIZ	Descrizione istituto	Facoltativo	Alfanumerico (254)
PUBPRI	Pubblico/privato	Facoltativo	Alfanumerico (10)
CODISTMOB	Codice per mobilità	Facoltativo	Alfanumerico (8)
RAGGRUPPAMENTOI ST	Raggruppamento	Facoltativo	Alfanumerico (150)
CLASSEISTITUTO	Classe	Facoltativo	Alfanumerico (254)

Catalogo	PRODOTTI da fonte DWH (codice catalogo = PRODOTTO)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
COD_PRODOTTO	Codice della referenza	Facoltativo	Alfanumerico (50)	MFI 1 codice

DESCR_PRODOTTO	Denominazione del prodotto	Facoltativo	Alfanumerico (251)	catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
AT_COD	Codice ATC	Facoltativo	Alfanumerico (7)
AP_CND	Codice Cnd	Facoltativo	Alfanumerico (50)
MINSAN10	Minsan10 o AIC	Facoltativo	Alfanumerico (50)
COD_CONTO_C	Codice conto civile	Facoltativo	Alfanumerico (500)
DESC_CONTO_C	Descrizione conto civile	Facoltativo	Alfanumerico (50)
COD_CONTO_G	Codice conto gestionale	Facoltativo	Alfanumerico (500)
DESC_CONTO_G	Descrizione conto gestionale	Facoltativo	Alfanumerico (50)

Catalogo	FARMACI da fonte DWH (codice catalogo = FARMADATA)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
CODICE_FARMACO	Codice della referenza	Facoltativo	Alfanumerico (13)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
CODICE_MINSAN10	Codice Minsan10	Facoltativo	Alfanumerico (13)
CODICE_EAN	Codice EAN	Facoltativo	Alfanumerico (13)
CODICE_EMEA	Codice EMEA	Facoltativo	Alfanumerico (20)
CODICE_ARTICOLO_ PROD	Codice articolo del produttore	Facoltativo	Alfanumerico (13)
DESCRIZIONE1	Denominazione della referenza	Facoltativo	Alfanumerico (40)
DESCRIZIONE2	Descrizione estesa	Facoltativo	Alfanumerico (40)
TIPO_CLASSE_MERC	Tipo classe merceologica	Facoltativo	Alfanumerico (2)
DATA_COMMERCIAL IZZAZIONE	Data commercializzazione	Facoltativo	Data [GG/MM/YYYY]
COD_DITTA_PROD	Codice ditta produttrice	Facoltativo	Alfanumerico (4)
DESC_DITTA_PROD	Descrizione ditta produttrice	Facoltativo	Alfanumerico (30)
FORMA_FARMACEUT ICA	Forma farmaceutica	Facoltativo	Alfanumerico (2)
COD_VIA_SOMMINI STRAZ	Codice via somministrazione	Facoltativo	Alfanumerico (3)
QTA_FORMA_FARM	Quantità forma farmaceutica	Facoltativo	Numerico (22)
UNITA_MIS_FORMA _FARM	Unità di misura della forma farmaceutica	Facoltativo	Alfanumerico (1)
QTA_POSOLOGICA	Quantità posologica	Facoltativo	Numerico (22)
UNITA_MIS_POSOL OGICA	Unità di misura posologica	Facoltativo	Alfanumerico (1)
USO	Uso	Facoltativo	Alfanumerico (1)
CODICE_ATC	Codice ATC	Facoltativo	Alfanumerico (7)
PRINCIPIO_ATTIVO	Principio attivo	Facoltativo	Alfanumerico (6)

DATA_ESAURIMENT O	Data esaurimento	Facoltativo	Data [GG/MM/YYYY]
GRUPPO_MERCEOLO GICO	Gruppo merceologico	Facoltativo	Alfanumerico (4)

Catalogo	SPECIALIZZAZIONI MMG/PLS da fonte ASUR (codice catalogo = ARCA_SPECIALITA_MEDICO )
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
SPECIALITA_ID	Codice della referenza, contiene le specializzazioni dei medici di base gestiti sulla piattaforma ARCA- ASUR	Obbligatorio	Numerico (3)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfabetico (200)

Catalogo	STATI CIVILI da fonte ASUR (codice catalogo = ARCA_STATI_CIVILI )
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
STATO_CIVILE	Codice della referenza	Obbligatorio	Numerico (2)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfanumerico (16)

Catalogo	RUOLI NUCLEO FAMILIARE da fonte ASUR (codice catalogo = ARCA_NUCLEI_RUOLI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
NUCLEO_RUOLO	Codice della referenza	Obbligatorio	Alfabetico (2)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfabetico (40)
NUCLEO_CAPO	Identifica la funzione di “capofamiglia” associata al ruolo	Facoltativo	Numerico (22)

Catalogo	MOTIVI ESENZIONE da fonte ASUR (codice catalogo = ARCA_MOTIVI_ESENZIONE)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
MOTIVO_ID	Codice della referenza	Obbligatorio	Alfabetico (2)	MFI 1 codice catalogo
ESENZIONE_TIPO_I D	Tipo esenzione	Obbligatorio	Alfabetico (22)	MFI 1 codice catalogo

DESCRIZIONE

Descrizione della referenza

Obbligatorio

Alfabetico (40)

Ripetizioni del segmento MFE dove :

MFE 4 nome campo + valore

ISTAT

Codice ISTAT del motivo di esenzione

Obbligatorio

Alfabetico (15)

Catalogo	COMUNI E STATI ESTERI da fonte ASUR (codice catalogo = ARCA_COMUNI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
PROVINCIA	Codice della referenza, corrisponde alla concatenazione di provincia e comune	Obbligatorio	Numerico (3)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
COMUNE		Obbligatorio	Numerico (3)
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfabetico (30)
REGIONE	Codice regione di riferimento	Obbligatorio	Numerico (3)
PROVINCIA_SIGLA	Sigla della provincia	Obbligatorio	Alfabetico (3)
CAP	Codice avviamento postale	Obbligatorio	Alfanumerico (5)
CODICE_CATASTO	Codice catasto	Obbligatorio	Alfabetico (4)
SOPPRESSIONE_DA TA	Data soppressione del codice ISTAT	Facoltativo	Data [YYYYMMGG]
FUSIONE_PROVINCI A	Codice ISTAT di fusione, corrisponde alla concatenazione di provincia e comune	Facoltativo	Numerico (3)
FUSIONE_COMUNE		Facoltativo	Numerico (3)
VALIDITA_INIZIO_ DATA	Data inizio validità del codice ISTAT	Facoltativo	Data [YYYYMMGG]

Catalogo	NAZIONALITA’ da fonte ASUR (codice catalogo = ARCA_STATI_ESTERI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
STATO_ESTERO	Codice ISTAT della referenza	Obbligatorio	Alfabetico (3)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfabetico (30)

Catalogo	PROFESSIONI da fonte ASUR (codice catalogo = ARCA_PROFESSIONI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
PROFESSIONE	Codice della referenza	Obbligatorio	Numerico (5)	MFI 1 codice catalogo Ripetizioni del segmento MFE
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfabetico (30)	MFI 1 codice catalogo Ripetizioni del segmento MFE

dove :

MFE 4 nome campo + valore

Catalogo	CONDIZIONI PROFESSIONALI da fonte ASUR (codice catalogo = ARCA_PROFESSIONI_CONDIZIONI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
PROFESSIONE_CON DIZIONE	Codice della referenza	Obbligatorio	Numerico (2)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfabetico (30)

Catalogo	TITOLI DI STUDIO da fonte ASUR (codice catalogo = ARCA_TITOLI_STUDIO)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
TITOLO_STUDIO	Codice della referenza	Obbligatorio	Numerico (2)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfabetico (30)

Catalogo	DISTRETTI da fonte ASUR (codice catalogo = ARCA_DISTRETTI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
REGIONE	Codice della regione di riferimento	Obbligatorio	Numerico (3)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DISTRETTO	Codice della referenza	Obbligatorio	Numerico (4)
AREA_VASTA	Area Vasta di riferimento del distretto	Obbligatorio	Alfabetico (20)

Catalogo

REGIONI da fonte ASUR (codice catalogo = ARCA_REGIONI)

Nome Campo

Descrizione

Caratteristiche

Dimensionamen to

Riferimento a segmento HL7

REGIONE

Codice della referenza;

come da definizione delle Linee guida nazionali FSE (rif. Schema

Obbligatorio

Numerico (3)

MFI 1 codice catalogo

	DPCM attuativo, art. 22 e Allegato Disciplinare Tecnico art. 6.2)			Ripetizioni del segmento MFE dove :
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfabetico (30)	Ripetizioni del segmento MFE dove :
				MFE 4 nome campo + valore

Catalogo	ASL da fonte ASUR (codice catalogo = ARCA_ENTI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
REGIONE	Codice della referenza, corrisponde alla concatenazione di regione ed ente;	Obbligatorio	Numerico (3)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
ENTE		Obbligatorio	Numerico (4)
	come da definizione delle Linee guida nazionali FSE (rif. Schema DPCM attuativo, art. 22 e Allegato Disciplinare Tecnico art. 6.2)
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfabetico (30)

Catalogo	AMBITI SCELTA da fonte ASUR (codice catalogo = ARCA_AMBITI_SCELTA)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
AMBITO_SCELTA	Codice della referenza	Obbligatorio	Numerico (4)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DESCRIZIONE	Descrizione della referenza	Obbligatorio	Alfabetico (30)

Catalogo	ABBINAMENTO COMUNI-ASL e COMUNI-DISTRETTI da fonte ASUR (codice catalogo = ARCA_COMUNI_DISTRETTI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
PROVINCIA	Codice del comune della referenza, corrisponde alla concatenazione di provincia e comune	Obbligatorio	Numerico (3)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
COMUNE		Obbligatorio	Numerico (3)
REGIONE	Codice dell’ente della referenza, corrisponde alla concatenazione di regione ed ente	Obbligatorio	Numerico (3)
ENTE		Obbligatorio	Numerico (4)
DISTRETTO	Codice distretto della referenza	Obbligatorio	Numerico (4)

Catalogo	ABBINAMENTO COMUNI-AMBITI SCELTA da fonte ASUR (codice catalogo = ARCA_COMUNI_AMBITI_SCELTA)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7

PROVINCIA	Codice del comune della referenza, corrisponde alla concatenazione di provincia e comune	Obbligatorio	Numerico (3)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove :
COMUNE		Obbligatorio	Numerico (3)
AMBITO_SCELTA	Codice dell’ambito di scelta della referenza	Obbligatorio	Numerico (4)
				MFE 4 nome campo + valore

Catalogo	PRESTAZIONI da fonte CUP (codice catalogo = DI_V_PRESTAZIONI)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
COD_PRST	Codice della referenza	Obbligatorio	Numerico (12)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DESC_PRST	Descrizione della referenza	Obbligatorio	Alfabetico (120)
DM	Corrispondente codice della prestazione su Decreto Ministeriale di riferimento	Obbligatorio	Alfanumerico (8)

Catalogo	ABBINAMENTO BRANCHE-PRESTAZIONI da fonte CUP (codice catalogo = DI_V_BRANCHE_PRST)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
COD_PRST	Codice prestazione della referenza	Obbligatorio	Numerico (12)	MFI 1 codice catalogo Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DESC_PRST	Descrizione prestazione della referenza	Obbligatorio	Alfabetico (120)
COD_BRANCA	Codice branca della referenza	Obbligatorio	Numerico (6)
DESC_BRANCA	Descrizione branca della referenza	Obbligatorio	Alfabetico (120)

Catalogo	ABBINAMENTO PRESTAZIONI-ESENZIONI da fonte CUP (codice catalogo = DI_V_ESENZIONI_DM)
Nome Campo	Descrizione	Caratteristiche	Dimensionamen to	Riferimento a segmento HL7
DM	Codice della prestazione su Decreto Ministeriale di riferimento	Obbligatorio	Alfanumerico (8)	MFI 1 codice catalogo
	Classe di esenzione abbinata alla prestazione			MFI 1 codice catalogo
COD_ESENZIONE	Classe di esenzione abbinata alla prestazione	Obbligatorio	Alfanumerico (15)	Ripetizioni del segmento MFE dove : MFE 4 nome campo + valore
DESC_ESENZIONE	Descrizione dell’esenzione abbinata alla prestazione	Obbligatorio	Alfabetico (120)

4.2.10 Futura implementazione di interfacce con tecnologia HL7 V3

Si riporta in seguito una tabella relativa all’elenco dei servizi in tecnologia HL7 V3 che verranno realizzati nel corso del progetto e resi disponibili alle iterazioni successive ; tali servizi saranno gestiti con la stessa modalità di trasporto prevista dalle interfacce precedentemente descritte.

Interfacciaprevista per ASR-EMPI / processo gestito		Scenari HL7 V3 rif. HL7Italia- PRPA_Patient_Topic-v1.2-S.doc del 08/02/2011	Servizi HL7 V3 da realizzare
		Richiesta di censimento di un nuovo
		paziente (PRPA_IN201311UV
		PRPA_IN201312UV-PRPA_IN101313UV)	UpdateDaArca()
Aggiornamento	ASR-
EMPI da Asur		Richiesta di cambiamento dei dati anagrafici
		di paziente (PRPA_IN201314UV
		PRPA_IN201315UV-PRPA_IN201316UV)	UpdateDaArca()
		[riconciliazione anagrafica] Non previsto	Da definire
		Richiesta di censimento di un nuovo
		paziente (PRPA_IN201311UV
		PRPA_IN201312UV-PRPA_IN101313UV)	UpdateDaAsx()
Aggiornamento	ASR-	Richiesta di cambiamento dei dati anagrafici
EMPI da Asx		di paziente (PRPA_IN201314UV
		PRPA_IN201315UV-PRPA_IN201316UV)	UpdateDaAsx()
		[riconciliazione anagrafica] Non previsto	Da definire
		Notifica di censimento di nuovo paziente
		(PRPA_IN201301UV)	SendVariazioni()
		Notifica di cambiamento dati anagrafici e
Sincronizzazione ARCA e MPI Locali da ASR- EMPI		dati sanitari di un paziente (PRPA_IN201302UV)	SendVariazioni()
Sincronizzazione ARCA e 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 un
Ricerca anagrafica su ASR-EMPI		paziente individuato da codice (PRPA_IN201307UV PRPA_IN201308UV)	GetAnagrafica()
		identificativo
		Interrogazione identificativi alternativi di un paziente (PRPA_IN201309UV PRPA_IN201310UV)	FindAnagrafica() GetAnagraficaStorica()

Riferimenti alla documentazione Standard HL7 v 3

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

4.3 Servizi di Alimentazione Dati e Documenti (categorie “funzioni di alimentazione” e “funzioni indicizzazione documenti”)

Gestione consenso

Profilazione

Verifica permessi FSE

<<include>>

Firma remota

<<include>>

Utente

Autenticazione

<<include>>

Archivia documento

ApplicativoVerticale

Repository

Indicizza metadati

Versamento

<<include>> Pol

Registry

<<include>>

Log

Invia notifica

<<include>>

RicercaAnagrafica

Figura 19: 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 un documento elettronico in esso prodotto, 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).

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

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	Obbligatorio
activityDateTime	Data ora produzione del Documento (TXA-4) nel formato yyyy-MM-ddTHH:mm:ss	Obbligatorio
originatorCodeName
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
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()

Figura 20: sequence diagram – Firma digitale remota

4.3.2 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: di seguito sono descritti i tipi dei parametri utilizzati dai web services del Modulo Documentale. 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 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 è necessaria 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	Obbligatorio
activityDateTime	Data ora produzione del Documento (TXA-4) nel formato yyyy-MM-ddTHH:mm:ss	Obbligatorio
originatorCodeName

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 “LA” (documento firmato digitalmente)
documentConfidentiality
content	Contenuto del documento	Obbligatorio
conclusion
pathology
outcome
text

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

Figura 21: sequence diagram – Verifica firma remota

4.3.3 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), 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 (vedi par. 4.7.2).

FLUSSO: una volta autenticato, l’utente potrà procedere alla firma digitale del documento (se trattasi di documento non firmato) e alla sottomissione dello stesso; 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 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: la mappatura dei metadati da trasmettere sui nomi nel messaggio ed in taluni casi i valori da utilizzare è in fase di definizione; vengono invece riportati sotto le descrizioni dati richiesti con la regola di obbligatorietà relativa.

Nome Campo	Descrizione	Caratteristiche
	ID Paziente a livello regionale (GUIDFSE)	Obbligatorio/Facoltativo*
	ID Paziente a livello locale (MPI Locale)	Obbligatorio/Facoltativo*
	Codice fiscale	Obbligatorio
	Regime dell’episodio clinico a cui è collegato il documento (I per regimi per Interni E per pronto soccorso O per regimi ambulatoriali)	Obbligatorio
	ID Episodio
	Tipo Episodio
	ID Richiesta su Order Placer (per referti collegati a richieste di esame, id richiesta su sistema che ha generato la richiesta stessa)
	ID Richiesta su Order Filler (per referti collegati a richieste di esame, id richiesta su sistema che eseguito la richiesta stessa ed ha prodotto il documento)	Obbligatorio
	struttura (reparto, unità ecc..) richiedente (codifica regionale)
	struttura (reparto, unità ecc..) erogante (codifica regionale)
	tipo di documento: Referto Laboratorio Analisi Prescrizione Specialistica Prescrizione Farmaceutica Stato Prescrizione

	Lettera di Dimissione Verbale di Pronto Soccorso Prescrizione Riabilitativa Prescrizione di Ricovero Prescrizione Presidi Ausili Prescrizione Richiesta di Trasporto Referto Radiologia Referto Ambulatoriale Referto Anatomia Patologica
	Formato del documento: “CDA2_XSL_C” se CDA2 contenuto in mime multipart firmato CAdES CDA2_XSL se CDA2 contenuto in mime non firmato PDF_C se PDF firmato CAdES PDF_P se formato PDF firmato PadES PDF se PDF non firmato CDA2 se CDA2 “puro” non firmato CDA2_C se CDA2 “puro” firmato CAdES	Obbligatorio
	Data ora produzione del Documento	Obbligatorio
	Medico refertante con id su anagrafe e/o codice fiscale
	UniqueID: chiave univoca ed invariante nel tempo del documento sull’applicativo d’origine	Obbligatorio
	Parent UniqueID: chiave univoca ed invariante nel tempo del documento da sostituire sull’applicativo d’origine	Obbligatorio (se è una sostituzione)
	Stato documento: DO – documento validato LA – Legalmente Valido (firmato digitalmente)	Obbligatorio

* 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): Facoltativo ID Paziente a livello locale (MPI Locale): Obbligatorio

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.

1 :

2 : Ri

tit

4 : Ritorno toke

5 : Firma

Servizio di firma offerto dal Repository

8 : Ritorna documento firmato()

9 :

)

10 : Verifica asserzioni identità e 11 ()

)

fica Policy()

14 : Invio documento()

rsamento()

16 : ACK archiviazione()

17 : ACK archiviazione()

13 : Veri

2 : Ritorna policy(

: Recupera Policy

15 : Ve

ruolo()

tà e token attributo(

- con token identi

Invio documento

n di attributo() locale()

3 : Invio tok

torno token iden

ale

ativa alla firma loc firma remota()

Altern 6 : Richiesta

)

à()

en identità()

Invio credenziali(

Polo Conservazione

Servizi Firma Remota

Repository

Policy Manager

Access Gateway

Attribute Autority

FedCohesion

Client Application

Figura 22: sequence diagram – Archiviazione repository aziendale

4.3.4 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.5 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. Il CDA2 con i risultati viene sostituito al precedente relativo allo stesso “caso” nel Repository con informazione che non è firmato.

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.

ApplicativoVerticale(LIS)

Access Gateway

Repository Locale

via Dati - CDA2 non firma

1 : In to()

3 : Token non valido()

2 : Valida token() 4 : Valida Policy()

a()

5 : Autorizzazione negat

6 : Archivia CDA2 con risultati()

Figura 23: sequence diagram – Archiviazione Dati Laboratorio “urgenti” (non firmati)

4.3.6 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 il paziente ha dato il consenso alla costituzione del FSE, 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:

- verificare il valore di consenso alla alimentazione del fascicolo del paziente a cui si riferisce lo specifico documento, in modo da condizionare l’indicizzazione del documento;

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

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

Figura 24: sequence diagram – Indicizzazione su Registry Regionale FSE

4.4 Servizi di Consultazione dati e documenti (categoria “funzioni di ricerca e recupero documenti”)

System

Ricerca documento

<<include>>

Autenticazione e Profilazione

<<include>>

Autorizzazione

Verifica consenso

<<include>>

Recupero documento

Repository

Registry

Utente

ApplicativoVerticale

Figura 25: Caso d’uso – Ricerca e recupero documento

CASO D’USO: la figura sopra riportata illustra il caso d’uso della consultazione di dati e documenti, articolata nei servizi di ricerca e recupero.

Per quanto attiene la ricerca, questa viene effettuata per trovare tutti i documenti che corrispondono ai criteri di interesse, grazie al registry regionale che è il modulo che espone un servizio di ricerca. La ricerca effettuata ritornerà un insieme di documenti non solo in base ai criteri di interesse richiesti, ma anche in base ad un insieme di filtri, dovuti all’integrazione con gli altri moduli precedentemente descritti, tra cui: ruolo dell’utente, contesto della richiesta, consensi conferiti (alla costituzione e alla consultazione, ecc.). Di conseguenza il numero di risultati fornito al richiedente potrebbe essere inferiore al numero di risultati effettivamente trovati su registry (si pensi ad es. all’ipotesi di oscuramento dell’oscuramento).

Per quanto riguarda la fase di recupero vero e proprio, i dati ottenuti dal registry vengono utilizzati per accedere al repository in cui è archiviato il documento ed ottenere, tramite il servizio di recupero, il documento di interesse. L’applicativo Verticale interessato si fa quindi carico del rendering sia dei risultati della ricerca che del singolo documento recuperato.

ATTORI: di seguito l’elenco degli attori previsti:

Nome	Descrizione
Utente	Utente del sistema FSE a livello regionale o aziendale (cittadini, MMG/PLS o medici specialisti ospedalieri)
ApplicativoVerticale	Identifica qualsiasi sistema applicativo in uso presso le Aziende Sanitarie e Ospedaliere marchigiane (ad es. sistemi LIS, RIS, dipartimentali ecc.) o presso i MMG/PLS (applicatvo di cartella) 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)

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 26: 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.

Client Application

Access Gateway

Repository

Audit Logger

menti richiesta()

Da "servizio di ricerca documenti"

1 : Lista docu

2 : Visualizzazione documenti()

3 : Richiesta documento()

4 : Verifica asserzioni di identità e autorizzativa()

5 : Log dell'accesso al documento()

to()

6 : Recupero documen

7 :

Documento recuperato()

8 : Documento richiesto()

Figura 27: 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: la lista esatta dei paramatri di ricerca e dei metadati restituiti dipende dagli approfondimenti in corso (definizione metadati). Tra i parametri di ricerca disponibili si ipotizza al momento che saranno comunque utilizzati:

- anagrafica (id paziente),

- data produzione documento,

- 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.

Client

Access Gateway

Repository (Registry Locale)

1 : Ricerca documenti()

2 : Validazione token()

3 : Token non valido()

4 : Validazione policy()

5 : Autorizzazione negata() 6

7 : Esecuzione query()

8 : Ritorna elenco document ID e metadati locali()

Figura 28: 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: parametri di input: paziente, data risultato (intervallo di date), codice risultato

STANDARD: Lo standard di riferimento è XML

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

8 : Ritorna risultati e data()

5 : Autorizzazione n

Repository (Registry Locale)

Access Gateway

Client

7 : Esecuzione query()

Figura 29: 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 30: 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 31: 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	Nome	Descrizione
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.
desc			Testo che descrive l’oggetto e che viene visualizzato nell’interfaccia per contestualizzare l’operazione.
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 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

Parametro		Nome	Descrizione
GUI	ws	Nome	Descrizione
			• 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.
	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.
usr	utente	Utente connesso	Codice identificativo dell’utente che sta effettuando l’operazione (username).
	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.

ApplicativoVerticale

FedCohesion

Attribute Autority

Access Gateway

Gestore Consenso

: Invio credenziali()

2 : Ritorno token identità()

3 : Invio token identità()

4 : Ritorno token attributo - ruolo()

5 : Richiama consenso - token identità + token attributo()

6 : Verifica asserzioni di identità e ruolo()

8 : Visualizza interfaccia consenso()

Figura 32: sequence diagram – Accesso al consenso da applicativo (es. portale)

4.6.1.2 Servizi web (ws)

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)

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

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

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

18 : Ver

7 : Ritorno policy()

ento consenso()

ifica Policy() 19 : Aggiornam

20 : ACK Aggiornamento consenso()

21 : ACK Aggiornamento consenso()

Figura 33: sequence diagram – Recupero e aggiornamento consenso

4.6.1.2.2 Oscura oggetto

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.

4.6.1.2.3 Annulla oscuramento

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.

4.6.1.2.4 Ricerca consensi

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

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

• 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

• Data di riferimento

STANDARD: XML

SCENARIO DI ESEMPIO: si veda il diagramma di sequenza illustrato al par. 4.4.1.

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 34 – 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.

Document Metadata Notification Recipient

E’ l’attore che riceve la notifica di un evento una volta che le regole contenute nella sottoscrizione sono state validate dal broker (per quel ricevente).

Nell’affinity Domain XDS è sempre associato al Document Consumer.

In un contesto di interoperabilità più esteso è quell’attore che risponde alla ricezione di una notifica.

Document Metadata Notification Broker

Il notification broker è un modulo che contempla le seguenti funzionalità:

a) Riceve le transazioni di sottoscrizione o cancellazione (di sottoscrizione) da parte del Document Metadata Subscriber.

b) Tiene traccia di tutte le sottoscrizioni e dei tempi di validità delle stesse.

c) Invia le notifiche ai sottoscrittori del dominio di interesse in base ai filtri associati alle sottoscrizioni, notifica queste informazioni di pubblicazione ai destinatari sottoscritti (Notification Recipient).

Notification Pull Point

E’ l’attore che memorizza le notifiche mirate ad un Document Metadata Notification Recipient specifico (che non può essere direttamente notificato ad esempio in modalità Push-style).

Questo attore fornisce le notifiche al Notification Puller per la loro distribuzione quando sollecitato da un Recipient.

Notification Puller

Un modulo del sistema che si basa sui paradigmi della notifica di tipo Pull-style.

Ha la funzione di creare o distruggere una risorsa di Pull-point per la memorizzazione delle notifiche da inviare ai sottoscrittori. Quando viene sollecitato invia la notifica al Notification Pull Point.

DATI SCAMBIATI: Sono di seguito descritti i principali concetti al servizio:

Subscription (Sottoscrizione)

La sottoscrizione è la modalità con cui un attore interessato alla ricezione di messaggi (destinatario) decide di “abbonarsi”.

La richiesta di sottoscrizione viene effettuata verso il modulo Notification Broker che si occupa del dispatching dei messaggi. Il terzo attore di questo sistema è il Publisher, cioè il mittente.

L’architettura descritta realizza il classico modello publish/subscribe che permette di disaccoppiare il flusso tra il mittente e i destinatari.

Broker/Dispacher

Il broker ha il compito di inviare ogni messaggio ricevuto dal un Publisher a tutti gli attori sottoscritti interessati a quel messaggio. La modalità di sottoscrizione consente ai Subscriber (vedi sotto) di definire nel modo più specifico possibile a quali messaggi sono interessati.

Publisher

Si definisce Publisher un modulo il cui scopo è quello di pubblicare le informazioni al Notification Broker in grado di notificarle previa verifica delle sottoscrizioni.

Subscriber

E’ un elemento del sistema deputato ad effettuare le richieste di sottoscrizione e/o cancellazione al Broker per se stesso oppure per conto di un possibile destinatario della notifica.

La richiesta di sottoscrizione può contenere una serie di filtri/parametri per determinare le modalità di notifica applicate.

Notification Recipient

E’ l’elemento del sistema che riceve le notifiche dal Broker. A fronte di una notifica il ricevente eseguirà di conseguenza le attività preposte (es. recupero documenti dal Repository, recupero informazioni sul Registry).

Pull Point resource

E’ la risorsa gestita dall’attore Pull Point che memorizza la notifica verso i riceventi.

Policy:

Il sistema DSUB previsto all’interno della piattaforma consente di gestire alcune policy di autorizzazione relative all’invio di una notifica da parte del Broker verso un attore del sistema(Notification Recipient) oppure prima di renderla disponibile sul Pull Point.

Le policy attualmente previste sono le seguenti:

• AuthMatrixPolicy

Controlla i permessi in base al ruolo dell’utente, al tipo di documento e al livello di confidenzialità. La policy è verificata se le informazioni specificate:

o Ruolo

o Tipo Documento

o Livello di Confidenzialità

vanno a soddisfare le condizioni indicate nella matrice delle autorizzazioni utilizzata dal modulo Access Gateway di piattaforma per la gestione degli accessi ai documenti.

• OutPatientPolicy

Controlla il contentTypeCode dei metadati relativi al documento inserito. La policy è verificata se il contentTypeCode è contenuto in una lista configurabile tra quelli che ne consentono la notifica. Questo policy consente di gestire l’invio di notifiche in base al regime di degenza e sarà utilizzata per la gestione del ritorno referti ai medici di medicina generale consentendo la notifica relativa ai soli eventi di outPatient.

• InPatientPolicy

Come la policy descritta in precedenza controlla il contentTypeCode dei metadati relativi al documento inserito.

La policy consente di gestire l’invio di notifiche in base al regime di degenza consentendo lanotifica relativa ai soli eventi di tipo inPatient.

STANDARD: Il modulo DSUB è sviluppato sulla base delle indicazioni previste dal TechnicalFramework IHE di riferimento. Tutte le transazioni, gli attori ed i profili sono compatibili con le specifiche descritte nei seguenti TF:

- “IHE_ITI_Suppl_DSUB.pdf”

- “IHE_ITI_Suppl_DSUB_Rev2-0_PC_2013-06-03.pdf”

Lo standard di riferimento è OASIS WS-BaseNotification nello specifico i riferimenti:

- WS-BaseNotification 1.3 OASIS Standard

- WS-BrokeredNotification 1.3 OASIS Standard

4.7.2 Servizio di alimentazione del Polo di Conservazione Regionale

DESCRIZIONE: consente l’alimentazione del Polo di Conservazione da parte dei repository aziendali.

FLUSSO: Questa transazione consente a repository legacy non integrati con il Polo di Conservazione, di alimentare tale polo con i documenti che soddisfano ai criteri per essere conservati legalmente, senza implementare un’interfaccia avanzata compatibile con le specifiche regionali. Lo strato software del Repository offerto nell’ambito dell’infrastruttura FSE, metterà a disposizione un’interfaccia basata su tabelle

che alimentate con i metadati e documenti presenti nei repository legacy, attiveranno l’invio al Polo di Conservazione.

DATI SCAMBIATI: Metadati e documenti come da specifica del polo di conservazione regionale.

STANDARD: SQL

SCENARIO DI ESEMPIO: si veda il par. 4.3.3.

5 SPECIFICHE TECNICHE

5.1 Servizio di Autenticazione e Profilazione

5.1.1 Servizio di Autenticazione

[A cura di RM]

5.1.2 Servizio di Profilazione

Il wsdl relativo al servizio di WS per la richiesta di attributi è contenuto nell’allegato

“ServizioAttributeManager.wsdl”

5.1.2.1 Implementazione

I web services utilizzano il WSDL del paragrafo precedente.

L'attributo che specifica il ruolo è: urn:it:regione:marche:aa:claim:role.

<saml:Attribute Name="urn:it:regione:marche:aa:claim:role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="ruolo">

<saml:AttributeValue>[role]</saml:AttributeValue>

</saml:Attribute>

Il token rilasciato sarà firmato utilizzando una chiave privata e la verifica del token di Fed Cohesion da parte dell'Attribute Authority viene effettuata utilizzando la chiave pubblica contenuta nella firma.

L’applicazione verifica la firma del token di FedCohesion e verifica che la SAML Assertion stessa non sia scaduta. Effettuati questi controlli l'Attribute Authority controlla che il soggetto (NameID) specificato nell’AttributeQuery coincida con quello dell’asserzione.

Se i controlli non sono soddisfatti saranno restituite le eccezioni specificate nel paragrafo successivo.

5.1.2.2 Messaggi d’errore

Il componente gestisce due tipologie d’errore che si differenziano in base alla pertinenza.

Errori di pertinenza della parte server, ovvero scatenati dal componente stesso (“Receiver”) ed errori dovuti alla parte client (“Sender”), quindi potenzialmente dovuti ad una richiesta SOAP errata da parte di chi richiama il servizio.

Di seguito l’elenco degli errori gestiti cosi classificati, con la relativa descrizione:

Errori Sender
Codice	Messaggio d’errore	Descrizione
1000	Incorrect assertion	L’asserzione nell’header della SOAP message è mal formata o non presente
1001	Not valid assertion	L’asserzione nell’header della SOAP message non è valida
1002	Not valid Certificate	Il certificato fornito nell’asserzione dell’header del SOAP message non è valido
1003	User: XX doesn't have selected role: YY	L’utente specificato nell’assezione dell’header del SOAP message non ha il ruolo specificato tra gli attributi
1004	Not valid Assertion signature	Durante la validazione dell’asserzione si verifica che la firma dell’asserzione stessa non è valida
1005	Cannot validate with given credentials on Assertion	L’asserzione pur essendo formalmente corretta non contiene credenziali valide
1006	SOAP Message Header does not contain Security	La request SOAP non contiene la parte della security nell’header
1007	Attribute Query must have a Subject	La request SOAP non contiene il soggetto nella parte del body
1008	Attribute query must have a Subject and a NameID Element inside	La request SOAP non contiene il tag BaseID nella parte del body
1009	Attribute Query must have a Subject and a NameID Element inside with an subject	La request SOAP ha il tag BaseID nella parte del body, ma all’interno del tag stesso non è presente niente
1010	Attribute Query must have the same subject as on Assertion	La request SOAP ha il tag BaseID nella parte del body, ma all’interno del tag stesso è presente un soggetto differente dall’assertion
1011	Attribute Query must have a BaseID tag and no more than one	La request SOAP ha più tag BaseID nella parte del body
1012	Attribute Name in tag Attribute must contain 'urn:it:regione:marche:aa:claim:role' value;	L’attributo Name nel tag “Attribute” deve contenere necessariamente il valore 'urn:it:regione:marche:aa:claim:role'
1013	Attribute NameFormat in tag Attribute must contain 'urn:oasis:names:tc:SAML:2.0:attrname- format:uri'	L’attributo NameFormat nel tag “Attribute” deve contenere necessariamente il valore 'urn:oasis:names:tc:SAML:2.0:attrname-format:uri'
1014	Attribute FriendlyName in tag Attribute must contain 'ruolo' value;	L’attributo FriendlyName nel tag “Attribute” deve contenere necessariamente il valore 'ruolo'
1015	SAML Assertion is expired	L’asserzione presente nel messaggio è scaduta

Errori Receiver
Codice	Messaggio d’errore	Descrizione

2000	Internal Server error	Non è possible creare una Response dato l’Enveloper della request
2001	Internal Server Error	Problemi nella creazione della Response
2002	Internal Server Error	Problemi nel della Response durante la sua creazione
2003	Internal Server Error	Problemi nella creazione della FaultResponse

5.1.2.3 Esempi di Request e Response del Servizio

Esempio di Request

<?xml version="1.0" encoding="utf-8"?>

<soapenv:Envelope xmlns:soapenv="xxxx://xxx.x0.xxx/0000/00/xxxx-xxxxxxxx">

<soapenv:Header xmlns:wsa="xxxx://xxx.x0.xxx/0000/00/xxxxxxxxxx">

<wsse:Security xmlns:wsse="xxxx://xxxx.xxxxx- xxxx.xxx/xxx/0000/00/xxxxx-000000-xxx-xxxxxxxxxx-xxxxxx-0.0.xxx" soapenv:mustUnderstand="true">

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="xxxx://xxx.x0.xxx/0000/XXXXxxxxx" ID="urn:uuid:82F4B450D92AAB7DE51415966508537" IssueInstant="2014-11- 14T12:01:48.533Z" Version="2.0">

<saml2:Issuer>x1v1-sts</saml2:Issuer>

<ds:Signature xmlns:ds="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="xxxx://xxx.x0.xxx/0000/00/xxx-xxx-x00x#"/>

<ds:SignatureMethod Algorithm="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#xxx-xxx0"/>

<ds:Reference URI="#urn:uuid:82F4B450D92AAB7DE51415966508537">

<ds:Transforms>

<ds:Transform Algorithm="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#xxxxxxxxx-xxxxxxxxx"/>

<ds:Transform Algorithm="xxxx://xxx.x0.xxx/0000/00/xxx-xxx-x00x#">

<ec:InclusiveNamespaces xmlns:ec="xxxx://xxx.x0.xxx/0000/00/xxx-xxx-x00x#" PrefixList="xs"/>

</ds:Transform>

</ds:Transforms>

<ds:DigestMethod Algorithm="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#xxx0"/>

<ds:DigestValue>eZqmGkKpihsiFFG6JkEbuko9obo=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue> Np1B+hidhClbvRyjdw2rE5BpaSpyp/TM7UTJjWw=</ds:SignatureValue>

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate> C34cBoRHM=</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</ds:Signature>

<saml2:Subject>

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid- format:emailAddress">NLDSRG65B23D612T</saml2:NameID>

<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key">

<saml2:SubjectConfirmationData xmlns:xsi="xxxx://xxx.x0.xxx/0000/XXXXxxxxx-xxxxxxxx" NotBefore="2014-11- 14T12:01:48.533Z" NotOnOrAfter="2014-11-14T12:06:48.533Z"

xsi:type="saml2:KeyInfoConfirmationDataType">

<ds:KeyInfo xmlns:ds="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#">

<ds:X509Data>

<ds:X509Certificate>

XMJyuC34cBoRHM=</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</saml2:SubjectConfirmationData>

</saml2:SubjectConfirmation>

</saml2:Subject>

<saml2:Conditions NotBefore="2014-11-14T12:01:48.533Z" NotOnOrAfter="2014-11-14T12:06:48.533Z">

<saml2:AudienceRestriction>

<saml2:Audience>xxxx://xx.xxxxxxx.xx/xxxxXxxxxxxx/xxxxxxxx/XxxxxxxxXxxxxxxxxx

_Service</saml2:Audience>

</saml2:AudienceRestriction>

</saml2:Conditions>

<saml2:AuthnStatement AuthnInstant="2014-11- 14T12:01:48.539Z">

<saml2:AuthnContext>

<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</ saml2:AuthnContextClassRef>

</saml2:AuthnContext>

</saml2:AuthnStatement>

<saml2:AttributeStatement>

<saml2:Attribute Name="xxxx://xxx0.xxx/xxxxxx/xxxxxxxxx" NameFormat="xxxx://xxx0.xxx/xxxxxx/xxxxxxxxx">

<saml2:AttributeValue xmlns:xsi="xxxx://xxx.x0.xxx/0000/XXXXxxxxx-xxxxxxxx" xsi:type="xs:string">Xxxxxx</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute Name="xxxx://xxx0.xxx/xxxxxx/xxxxxxxx" NameFormat="xxxx://xxx0.xxx/xxxxxx/xxxxxxxx">

<saml2:AttributeValue xmlns:xsi="xxxx://xxx.x0.xxx/0000/XXXXxxxxx-xxxxxxxx" xsi:type="xs:string">Naldoni</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute Name="xxxx://xxx0.xxx/xxxxxx/xxxxxxXxxxxxx" NameFormat="xxxx://xxx0.xxx/xxxxxx/xxxxxxXxxxxxx">

<saml2:AttributeValue xmlns:xsi="xxxx://xxx.x0.xxx/0000/XXXXxxxxx-xxxxxxxx" xsi:type="xs:string">NLDSRG65B23D612T</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute Name="xxxx://xxx0.xxx/xxxxxx/xxxx" NameFormat="xxxx://xxx0.xxx/xxxxxx/xxxx">

<saml2:AttributeValue xmlns:xsi="xxxx://xxx.x0.xxx/0000/XXXXxxxxx-xxxxxxxx" xsi:type="xs:string">ME,OP,UsersAdmins</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute

Name="xxxx://xxx0.xxx/xxxxxx/xxxxxxxxxxxx" NameFormat="xxxx://xxx0.xxx/xxxxxx/xxxxxxxxxxxx">

<saml2:AttributeValue xmlns:xsi="xxxx://xxx.x0.xxx/0000/XXXXxxxxx-xxxxxxxx" xsi:type="xs:string">bf568051-26ad-437c-a4b2-420ad1c8c6bb.DD- AX1V1MDB.localdomain</saml2:AttributeValue>

</saml2:Attribute>

</saml2:AttributeStatement>

</saml2:Assertion>

</wsse:Security>

</soapenv:Header>

<soapenv:Body>

<samlp:AttributeQuery xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="void" Version="2.0">

<saml:Subject>

<saml:NameID>NLDSRG65B23D612T</saml:NameID>

</saml:Subject>

<saml:Attribute Name="urn:it:regione:marche:aa:claim:role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="ruolo">

<saml:AttributeValue>ME</saml:AttributeValue>

</saml:Attribute>

</samlp:AttributeQuery>

</soapenv:Body>

</soapenv:Envelope>

Esempio di Response:

<?xml version="1.0" encoding="UTF-8"?>

<env:Envelope xmlns:env="xxxx://xxx.x0.xxx/0000/00/xxxx-xxxxxxxx">

<env:Header/>

<env:Body>

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Version="2.0">

<saml2p:Status>

<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

<saml2p:StatusMessage>OK</saml2p:StatusMessage>

</saml2p:Status>

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="assertion_2.16.840.1.113883.2.9.2.50101_630844F9EB74B99EFF14159664194401"

IssueInstant="2014-11-14T12:00:19.441Z" Version="2.0">

<saml2:Issuer>https://@public.web.x1v1@/attributeauthority/services/issue</sa ml2:Issuer>

<ds:Signature xmlns:ds="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="xxxx://xxx.x0.xxx/0000/00/xxx-xxx-x00x#"/>

<ds:SignatureMethod Algorithm="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#xxx-xxx0"/>

<ds:Reference URI="#assertion_2.16.840.1.113883.2.9.2.50101_630844F9EB74B99EFF1415966419440 1">

<ds:Transforms>

<ds:Transform Algorithm="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#xxxxxxxxx-xxxxxxxxx"/>

<ds:Transform Algorithm="xxxx://xxx.x0.xxx/0000/00/xxx-xxx-x00x#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="xxxx://xxx.x0.xxx/0000/00/xxxxxxx#xxx0"/>

<ds:DigestValue>58B74CpGl/EHr17T4wzcY6c2Tjg=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue> FGFEo=</ds:SignatureValue>

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certificate> RPRpK7kMEeXMJyuC34cBoRHM=</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</ds:Signature>

<saml2:Subject>

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid- format:x509SubjectName">NLDSRG65B23D612T</saml2:NameID>

<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>

</saml2:Subject>

<saml2:Conditions NotBefore="2014-11-14T12:00:19.441Z" NotOnOrAfter="2014-11-14T12:01:19.446Z"/>

<saml2:AuthnStatement AuthnInstant="2014-11- 14T12:00:19.442Z">

<saml2:AuthnContext>

<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:InternetPr otocolPassword</saml2:AuthnContextClassRef>

<saml2:AuthenticatingAuthority>https://@public.web.x1v1@/attributeauthority/s ervices/issue</saml2:AuthenticatingAuthority>

</saml2:AuthnContext>

</saml2:AuthnStatement>

<saml2:AttributeStatement>

<saml2:Attribute FriendlyName="ruolo" Name="urn:it:regione:marche:aa:claim:role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

<saml2:AttributeValue>ME</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute FriendlyName="codiceRegione" Name="urn:it:regione:marche:aa:claim:codiceRegione" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

<saml2:AttributeValue>110</saml2:AttributeValue>

</saml2:Attribute>

<saml2:Attribute FriendlyName="codiceStrutturaSanitaria" Name="urn:it:regione:marche:aa:claim:codiceStrutturaSanitaria " NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">

<saml2:AttributeValue>1234</saml2:AttributeValue>

</saml2:Attribute>

</saml2:AttributeStatement>

</saml2:Assertion>

</saml2p:Response>

</env:Body>

</env:Envelope>

5.1.2.4 Flusso di gestione Ruoli / Utenti

Il componente Attribute Authority consente la gestione degli utenti e dei ruoli offrendo le interfacce applicative (web services) e una GUI web di gestione che consentono il popolamento dei 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.

Per gli operatori sarà possibile effettuare le seguenti operazioni: inserimento, cancellazione e interrogazione. Per i ruoli sarà possibile effettuare le operazioni di inserimento, cancellazione e interrogazione.

Per le associazioni ruolo/utente sarà possibile solo creare ed eliminare associazioni ed interrogare gli utenti associati ad un ruolo.

Nei paragrafi successivi saranno descritti in dettaglio i servizi esposti dal modulo.

5.1.2.4.1 Gestione Utenti

Il servizio prevede la possibilità di (tra parentesi i parametri da passare):

1. Inserire un utente completo di tutti gli attributi definiti al capitolo Errore. L'origine riferimento non è stata trovata. (ID utente, Cognome, Nome, Codice Fiscale, codice regione, Codice struttura sanitaria).

2. Ricercare un utente utilizzando come parametro di ricerca l'ID_Utente, il Codice Fiscale, e Nome e Cognome. Il servizio restituisce oltre agli attributi dell'utente anche ruolo associato.

3. Eliminare un utente passando l'identificativo dello stesso (ID_Utente). Consegue che saranno eliminate tutte la associazioni ruolo/utente.

5.1.2.4.2 Gestione Ruoli

Il servizio prevede la possibilità di (tra parentesi i parametri da passare):

1. Inserire un nuovo ruolo (ID_Ruolo e descrizione);

2. Eliminare un ruolo esistente (ID_Ruolo). L'eliminazione del ruolo comporta la rimozione delle associazioni ruolo/utente relative a quest'ultimo;

3. Ricercare un ruolo in base alla sua codifica o alla sua descrizione (ID Ruolo o Descrizione).

5.1.2.4.3 Gestione associazione Ruoli / Utenti

Il servizio prevede la possibilità di (tra parentesi i parametri da passare):

1. Ricercare tutti gi utenti associati ad un ruolo (ID_Ruolo);

2. Creare una nuova associazioni ruolo/utente (ID_Ruolo e ID_Utente);

3. Eliminare le associazioni ruolo/utente esistenti (ID_Ruolo e ID_Utente);

5.1.2.5 Principi generali dei Servizi di Alimentazione

I servizi sono fruibili con il protocollo SOAP 1.2.

Tutte le transazioni devono avere un identificativo univoco, specificato nell'elemento <transactionId>. Questo identificativo viene tornato nel messaggio di risposta del server nello stesso elemento.

Per la gestione dei tre flussi relativi sono stati creati tre WSDL uno per ogni servizio:

• "attributeAuthorityUserProvisioning.wsdl" per il servizio di gestione degli utenti;

• "attributeAuthorityRoleProvisioning.wsdl" per il servizio di gestione dei ruoli;

• "attributeAuthorityAssociationProvisioning.wsdl" per il servizio di gestione delle associazioni ruoli/utenti.

5.1.2.5.1 Request

L'elemento root del messaggio è sempre: <AttributeAuthorityProvisioningRequest>. Il namespace è: "urn:eu:dedalus:x1v1:aa:provisioning".

L'elemento root ha come figli:

• <transactionId> : l'id della transazione, che deve essere univoco per ogni transazione e può avere opzionalmente uno di questi tre elementi:

• <Read> : per tutti i servizi di lettura (utenti, ruoli, associazioni)

• <Create> : per tutti i servizi di insert (utenti, ruoli, associazioni)

• <Delete> : per tutti i servizi di cancellazioni (utenti, ruoli, associazioni)

Ognuno degli elementi sopraelencati ha come figlio l'elemento <parameters>, che a sua volta include una lista di elementi <parameter>.

L'elemento <parameter> deve essere valorizzato e deve avere l'attributo @name, che specifica il tipo di parametro. Se non viene valorizzato viene assunto che il valore sia null.

In base al tipo di servizio che si sta invocando (user | role | association) e al tipo di operazione (read | delete

| create) i parametri variano.

Nei paragrafi successivi il dettaglio per la valorizzazione dei parametri per i flussi specifici relativi alla gestione di utenti, ruoli e associazioni ruoli/utenti.

5.1.2.5.2 Response

Il server restituisce per tutti i servizi un messaggio con l'elemento root:

<AttributeAuthorityProvisioningResponse>.

Questo elemento ha come figli:

• <transactionId> : l'id della transazione, uguale a quello del messaggio di Request.

e opzionalmente uno di questi tre elementi:

• <ReadResponse> : per tutti i servizi di lettura (utenti, ruoli, associazioni)

• <CreateResponse> : per tutti i servizi di insert (utenti, ruoli, associazioni)

• <DeleteResponse> : per tutti i servizi di cancellazioni (utenti, ruoli, associazioni) Ognuno di questi tre elementi contiene l'attributo status, che può assumere i due valori:

• success

• failure

In caso di status = failure sarà presente l'elemento <errorList> contenente una lista di <error>, con codice e dettaglio dell'errore o degli errori, come di seguito.

<ns0:errorList>

<ns0:error>

<ns0:code>INTEGER</ns0:code>

<ns0:detail>STRING</ns0:detail>

</ns0:error>

<ns0:error>

<ns0:code>INTEGER</ns0:code>

<ns0:detail>STRING</ns0:detail>

</ns0:error>

</ns0:errorList>

5.1.2.5.3 Query Continuation

Per le operazioni di Read il server restituisce massimo 100 risultati alla volta. Per gestire le interrogazioni (Read) viene utilizzato l'elemento <queryContinuation>.

Questo elemento serve per informare il client del totale dei risultati, e, se è necessario, continuare la query di ricerca con una nuova chiamata per ottenere i risultati rimanenti.

Per ottenere le successive "pagine" il client deve eseguire altre chiamate impostando l'elemento

<queryContinuationId> e valorizzandolo con l'id ottenuto dal server in //queryContinuation/@id.

L'elemento <currentQuantity> indica il set di risultati tornati attualmente, mentre l'elemento < totalResult>

indica il totale.

Quando <currentQuantity> è uguale a <totalResult> significa che tutti i risultati sono stati ritornati dal server.

<ns0:queryContinuation id="identificativo univoco">

<ns0:currentQuantity>INTEGER</ns0:currentQuantity>

<ns0:totalResult>INTEGER</ns0:totalResult>

</ns0:queryContinuation>

5.1.2.5.4 Gestione Utenti

5.1.2.5.4.1 Create

REQUEST

La SOAP action da utilizzare è: "urn:eu.dedalus:x1v1:aa:provisioning:user:create".

Parametri

Parametri obbligatori:

• urn:it:regione:marche:aa:claim:nameId (ID_Utente)

Parametri opzionali:

• urn:it:regione:marche:aa:claim:codiceRegionale

• urn:it:regione:marche:aa:claim:codiceStrutturaSanitaria

• urn:it:regione:marche:aa:claim:nome

• urn:it:regione:marche:aa:claim:cognome

• urn:it:regione:marche:aa:claim:codice Fiscale

Esempio:

<ns0:AttributeAuthorityProvisioningRequest>

<ns0:transactionId>STRING</ns0:transactionId>

<ns0:Create>

<ns0:parameters>

<ns0:parameter name="urn:it:regione:marche:aa:claim:nameId">NameId<ns0:parameter>

<ns0:parameter name="urn:it:regione:marche:aa:claim:nome">Xxxxxxx<ns0:parameter>

<ns0:parameter name=" urn:it:regione:marche:aa:claim:cognome">Xxxxxxxx<ns0:parameter>

</ns0:parameters>

</ns0:Create>

</ns0:AttributeAuthorityProvisioningRequest>

RESPONSE

La SOAP action è: "urn:eu.dedalus:x1v1:aa:provisioning:user:createResponse".

Esempio

<ns0:AttributeAuthorityProvisioningResponse>

<ns0:transactionId>STRING</ns0:transactionId>

<ns0:CreateResponse status="success" />

</ns0:AttributeAuthorityProvisioningResponse>

5.1.2.5.4.2 Read

REQUEST:

La SOAP action da utilizzare è: "urn:eu.dedalus:x1v1:aa:provisioning:user:read".

Parametri

Alcuni parametri sono usabili singolarmente e sono:

• urn:it:regione:marche:aa:claim:nameId

• urn:it:regione:marche:aa:claim:codiceFiscale

I seguenti parametri devono essere utilizzati solamente in coppia:

• urn:it:regione:marche:aa:claim:nome

• urn:it:regione:marche:aa:claim:cognome

È anche possibile utilizzare tutti i parametri di ricerca, per avere ricerche più mirate e performanti.

Esempio

<ns0:AttributeAuthorityProvisioningRequest>

<ns0:transactionId>STRING1</ns0:transactionId>

<ns0:Read>

<ns0:parameters>

<ns0:parameter name="nome claim attribute authority">valore di query</ns0:parameter>

</ns0:parameters>

</ns0:Read>

</ns0:AttributeAuthorityProvisioningRequest>

RESPONSE:

Nel messaggio di risposta è contenuto l'elemento <ReadResponse/users>, che contiene una lista di elementi <user>, che rappresentano gli utenti.