[DEDALUS X1.V1] Guida all'Integrazione IT v1.2rev2 FINALEDEDALUS_X1.V1]_Guida_all... ·...

Questo documento contiene informazioni proprietarie e riservate di Dedalus SpA Nessuna parte di questa pubblicazione può essere riprodotta, trasmessa, trascritta, registrata o tradotta in qualsiasi lingua, in qualsiasi forma e con qualsiasi mezzo, elettronico, magnetico, ottico, chimico, fisico o altro. Dedalus si riserva il diritto di correggere questa pubblicazione e di apportare modifiche al suo contenuto senza l'obbligo di informare chiunque di tali revisioni o modifiche. © 2014, Dedalus S.p.A. (01/14). Tutti i diritti riservati

Piattaforma

Guida all’Integrazione

Descrizione Principali Funzionalità

Versione 1.2

BOZZA

Piattaforma X1.V1 –Guida all’Integrazione

Questo documento contiene informazioni proprietarie e riservate di Dedalus SpA Nessuna parte di questa pubblicazione può essere riprodotta, trasmessa, trascritta, registrata o tradotta in qualsiasi lingua, in qualsiasi forma e con qualsiasi mezzo, elettronico, magnetico, ottico, chimico, fisico o altro. Dedalus si riserva il diritto di correggere questa pubblicazione e di apportare modifiche al suo contenuto senza l'obbligo di informare chiunque di tali revisioni o modifiche. © 2014, Dedalus S.p.A. (01/14). Tutti i diritti riservati

Pagina lasciata intenzionalmente bianca

Piattaforma X1.V1 – Guida all’Integrazione

Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati

of 28

Informazioni sul documento

Metadati

Emesso da Dedalus S.p.A. - Via di Collodi, 6/C 50141 Firenze (ITALY)

Tipo Guida all’Integrazione

Diritti di accesso Confidenziale

Lingua Italiano

Titolo Piattaforma X1.V1 - Guida all’Integrazione

Numero TECH_X1.V1-INT_GUIDE_IT_v1.2

Versione 1.2

Stato FINALE

Creato da Fabio Buti

Data di creazione 2013-Ott-28

Redattore/i Dipartimento X1.V1

Confidenzialità

Questo documento è proprietà intellettuale di Dedalus S.p.A., protetto ai sensi e in conformità

con la legislazione vigente in materia di diritto d'autore (Italia, L. n ° 248/2000 e successive

modifiche). Le informazioni contenute in questo documento sono considerate strettamente

confidenziali e non possono essere riprodotte o comunicate a terzi o utilizzate per scopi diversi

da quelli della valutazione stessa, al fine di arrivare alla stipula di un accordo, senza il

preventivo consenso scritto della Società sottoscritta.



of 28

Storia delle revisioni

Ver. Rev. Data Autore(i) Note

1.0 1 2013-Ott-28 A.Olianti Prima bozza

1.0 2 2014-Gen-28 F. Buti Revisione intermedia

1.0 3 2014-Feb-21 F.Monari Aggiunta parte anagrafica e revisione generale

1.0 4 2014-Apr-01 F.Buti Finalizzazione (senza parte MCI)

1.1 1 2014-Apr-02 M.Spallanzani, F.Buti Aggiunta parte MCI fornita da M.Spallanzani

1.1 2 2014-Apr-08 F.Buti Revisione generale

1.1 3 2014-Mag-05 F.Monari Aggiunte e revisione parte anagrafica

1.1 4 2014-Mag-05 F.Buti Revisione intermedia

1.1 5 2014-Ago-08 F.Buti Finalizzazione

1.1 6 2014-Ago-29 F.Buti Revisione template

1.2 1 2014-Ott-27 A.Olianti Rimozione riferimenti a SAML 1.1

1.2 2 2014-Ott-27 F.Buti Finalizzazione



of 28

Sommario

1 Prefazione ............................................................................................................. 6

2 Destinatari ............................................................................................................ 6

3 Documenti Correlati .............................................................................................. 6

4 Acronimi e abbreviazioni ....................................................................................... 7

5 Introduzione all’architettura X1.V1 ...................................................................... 8

5.1 Principali componenti dell’architettura .......................................................................... 9

5.1.1 SSO (Single Sign-On) ................................................................................................. 9

5.1.2 FSE / Dossier ............................................................................................................. 9

5.1.3 ESB .......................................................................................................................... 9

5.1.4 Il Registry (indice dei documenti) ............................................................................... 10

5.1.5 Il Repository dei documenti ....................................................................................... 10

5.1.6 MPI ........................................................................................................................ 11

5.1.7 MCI ........................................................................................................................ 12

6 Funzionalità ........................................................................................................ 12

6.1 Flussi disponibili .......................................................................................................... 12

6.1.1 Flusso di autenticazione WEB services......................................................................... 12

6.1.2 Flusso documentale .................................................................................................. 14

6.1.3 Flusso anagrafico ..................................................................................................... 16

6.1.4 Flusso di gestione delle notifiche ................................................................................ 19

6.1.5 Flusso di gestione delle codifiche ................................................................................ 19

6.2 Flussi d’integrazione: casi d’uso .................................................................................. 21

6.2.1 Caso d’Uso: Inserimento/Recupero di un documento ................................................... 21

6.2.2 Caso d’Uso: Gestione Codifiche ................................................................................. 21

Appendice A – Gestione Errori .................................................................................. 25

Appendice B - Plug-in ............................................................................................... 27



of 28

1 Prefazione

La Guida all’Integrazione descrive, dal punto di vista tecnico-funzionale, la modalità di

integrazione con dati e servizi offerti dalla Piattaforma di Interoperabilità X1.V1 e con le

tecnologie di sicurezza utilizzate per la loro protezione.

La Guida fornisce anche la descrizione delle interfacce esposte per l’accesso al sistema di

archiviazione e di consultazione della Piattaforma.

2 Destinatari

Questa Guida è destinata a coloro che sono coinvolti nelle attività di integrazione di

applicazioni o moduli con la Piattaforma X1V1.

Chi legge questo documento dovrebbe disporre di una conoscenza a livello implementativo

delle specifiche IHE relative ai domini interessati; in particolare del dominio IT Infrastructure.

3 Documenti Correlati

Ai fini dello sviluppo si elencano i documenti contenenti specifiche da considerare.

Documentazione IHE:

• http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf

• http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2a.pdf

• http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf

• http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2x.pdf

• http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf

Documentazione Dedalus:

• Affinity Domain X1.V1 => file: [DEDALUS_X1.V1]_AffinityDomain_IT_v2.0rev4.pdf

• Conformance Statement HL7 => file: [DEDALUS_X1 V1]_MPI _HL7v2 5_Conformance_Statement_IT_v1.1rev3.pdf

• X1.V1 - Java Plugin Adapter

=> file: [DEDALUS_X1.V1]_JavaPluginAdapter_v1.1.pdf

• X1.V1 - Autenticazione

=> file: [DEDALUS_X1.V1]_STS_(SpecTecniche)_IT_v1.1rev3.pdf

documenti complementari:

� Ai fini della installazione/distribuzione della Piattaforma: sia la Guida alla Distribuzione

che la Guida di Installazione.

� Ai fini della configurazione/ottimizzazione delle funzionalità della Piattaforma: la Guida

di Amministrazione

� Ai fini dell’uso della Piattaforma: la Guida Utente

Documentazione su altri standard applicati:

� Specifiche OASIS SAML far riferimento ai documenti: - http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

- https://www.oasis-open.org/committees/download.php/35389/sstc-saml-profiles-errata-2.0-wd-06-diff.pdf



of 28

4 Acronimi e abbreviazioni

Di seguito è riportato il significato degli acronimi e delle abbreviazioni usati in questo

documento.

Termine Significato

ACK General Acknowledgement (messaggio)

CN Common Name

D-MIM Domain Message Information Model

DN Distinguished Name

ESB Enterprise Service Bus

FSE Fascicolo Sanitario Elettronico

HL7 Health Level 7 (Interface Standard)

IdP Identity Provider

IHE Integrating the Healthcare Enterprise

IM Identity Management

IS Information System

JDK Java Development Kit

LDAP Lightweight Directory Access Protocol

MCI Master Code Index

MMG Medici di Medicina Generale

MPI Master Patient Index

OU Organization Unit

PLS Pediatri di Libera Scelta

RDBMS Relational Database Management System

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

TCP/IP Transmission Control Protocol / Internet Protocol

SSO Single Sign-On

STS Security Token Service

WS Web Services

XDS Cross-Enterprise Document Sharing



of 28

5 Introduzione all’architettura X1.V1

L’architettura della Piattaforma si compone di diversi moduli cooperanti e adotta un modello di

comunicazione basato sui servizi.

Essa utilizza funzionalmente il modello architetturale previsto dal profilo d’integrazione IHE

XDS.b. Saranno quindi disponibili tutte la transazione previste da questo profilo. La Piattaforma

realizza, di fatto, i seguenti attori: Document Registry, Document Repository, Document

Consumer (Visualizzatore Dossier). La fruizione dei servizi e delle transazioni è regolata da un

modulo Single Sign-On. E’ infatti previsto un modulo Identity Provider per la gestione degli

utenti e un modulo Service Provider (SP) utilizzato per la gestione dell’accesso ai servizi da

parte degli attori Document Source e Document Consumer.

Di seguito il “Component Diagram” relativo all’infrastruttura della Piattaforma :

Figura 1 – Architettura Applicativa



of 28

5.1 Principali componenti dell’architettura

5.1.1 SSO (Single Sign-On)

La gestione dell’accesso ai servizi costituisce un punto nevralgico di ogni architettura.

Il componente SSO rappresenta un supporto che permette agli applicativi di svincolarsi dalle

logiche di autenticazione. Esso è utilizzabile sia in contesti rivolti alla protezione di moduli Web

che per la gestione di contesti a servizi.

Per integrazioni con attori XDS è previsto che l’utente fruisca dei servizi esposti dalla

Piattaforma attraverso l’invocazione di Web Services protetti da token SAML. Il componente in

oggetto consente di recuperare il token SAML dai dati dell'utente autenticato e utilizzarla per

l'invocazione ai servizi.

Il modulo SSO si basa su specifiche OASIS SAML Web Browser SSO Profile e viene certificato

per l'uso su Apache Tomcat.

NOTA: per maggiori informazioni riguardo alle specifiche OASIS SAML utilizzare i riferimenti citati nel

capitolo 2.

5.1.2 FSE / Dossier

Possiamo definire il Fascicolo Sanitario Elettronico/Dossier come un “indice di oggetti

informativi sanitari firmati digitalmente e creati dalla storia dei contatti dell’assistito con i

diversi attori del Sistema Sanitario Nazionale. Esso è accessibile dal cittadino e dagli operatori

sanitari giuridicamente autorizzati in qualunque luogo ed in qualunque momento nel rispetto

della regolamentazione nazionale e regionale e della tutela della privacy.”

“Il Fascicolo Sanitario Elettronico deve permettere la gestione dei dati clinici sia da un punto di

vista tecnico/informatico, sia dal punto di vista logico sanitario. Esso è uno strumento

informativo condiviso e accessibile da tutti coloro che ne hanno il diritto, strutturato come una

raccolta cronologica di eventi e informazioni longitudinale alla storia clinica del paziente.”

In base a questa definizione la Piattaforma X1.V1 individua quindi nel Fascicolo Sanitario

Elettronico “un’entità concettuale costituita dall'aggregazione logico-funzionale dei tre

componenti rappresentati dall’ESB, dal Registry e dal Repository.”

5.1.3 ESB

Il componente ESB (Enterprise Service Bus) è stato concepito per realizzare le funzionalità

necessarie a supportare comunicazioni sicure tra sistemi clinici e componenti interne alla

Piattaforma X1.V1.

L’ESB consente le seguenti principali funzionalità:

• gestione delle comunicazioni tra le componenti interne alla Piattaforma



of 28

• gestione degli aspetti di sicurezza e controllo degli accessi, mediante verifica e

autorizzazione degli utenti (con il supporto dei sistemi anagrafici sanitari e delle

Certification Authority) all’accesso alle risorse del sistema.

• gestione del tracciamento degli accessi

5.1.4 Il Registry (indice dei documenti)

Il componente Registry è l’indice della Piattaforma X1.V1. Contiene l’insieme dei metadati

relativi ai documenti memorizzati sui Repository e permette di ricercare e recuperare questi

ultimi, conformemente ai diritti di accesso dell’utente richiedente. Il profilo di integrazione

XDS.b prevede la presenza di un solo Registry (vedi figura 2).

5.1.5 Il Repository dei documenti

Il componente Repository è destinato a contenere i documenti informatici ed è normalmente

distribuito a livello aziendale (ASL/AO).

Il profilo di integrazione XDS.b prevede la presenza di uno o più Repository.

Ogni Repository offre le seguenti principali funzionalità:

1. archiviazione di un documento

2. recupero di un documento a partire da un suo riferimento

Figura 2 – Profilo d’Integrazione XDS.b: diagramma Attori/Transazioni



of 28

5.1.6 MPI

Il componente MPI gestisce l’anagrafe di riferimento per la Piattaforma. MPI può operare come

anagrafe di riferimento aziendale (ASL/AO) sia implementando le funzionalità di gestione della

medicina di base sia attraverso l’integrazione con una anagrafe di livello superiore, ad esempio

Repository component is destined to contain the electronic documents and is normally

distributed at corporate level (ASL/AO). l’anagrafe regionale, se presente.

Il modulo espone servizi SOAP per l’integrazione con le anagrafi dipartimentali.

Gli standard supportati sono i seguenti:

HL7 v2.3 XML

HL7 v2.5 XML

HL7 v3 XML

Figura 3 - Integrazione dell’MPI con le anagrafi dipartimentali



of 28

5.1.7 MCI

Il componente MCI (Master Code Index) rappresenta il repository centrale delle codifiche

messo a disposizione dalla Piattaforma. In termini IHE svolge il ruolo di Value Set Repository

(VSR) per le codifiche (Value Set), mentre gli applicativi esterni che devono fruire delle

codifiche, svolgono il ruolo di Value Set Consumer (VSC).

6 Funzionalità

La Piattaforma prevede che tutti i servizi esposti verso gli attori esterni secondo un’architettura

SOA debbano essere protetti usando WS-Security e SAML Assertion. Il componente SSO-Valve

consente di recuperare il token SAML dai dati dell'utente autenticato e utilizzarla per

l'invocazione ai servizi.

Lo scambio di messaggi tra i componenti del sistema, cioè gli attori che collaborano

interattivamente, identificabili dai componenti fisici come i client (Applicativi di Cartella,

Cartella MMG, ADT, etc.) o dai componenti logici come quelli che espongono i servizi applicativi

(Registry, Repository, etc), sarà filtrato dal componente ESB.

6.1 Flussi disponibili

Il modulo ESB espone le interfacce per la gestione e mette a disposizione una serie di funzioni

classificabili nelle seguenti categorie:

• Flusso di autenticazione WEB Services (STS)

• Flusso documentale (Inserimento, Interrogazione, Recupero)

• Flusso anagrafico (Identificazione, Inserimento, Aggiornamento, Interrogazione, Fusione)

• Flusso di gestione delle notifiche

• Flusso di gestione delle codifiche (Recupero codifica, Notifica modifica codifiche)

6.1.1 Flusso di autenticazione WEB services

Un applicativo che intende fruire di un servizio esposto deve necessariamente effettuare una

chiamata verso il modulo di autenticazione STS. Il modulo valida le credenziali fornite

dall’applicativo chiamante sulla modulo centrale che gestisce gli operatori verificando se

l’utente che intende fruire del servizio sia effettivamente censito Di seguito un schema

riassuntivo di questa architettura:



of 28

Figura 4 - Architettura Web Services nello scenario SSO-LDAP

L’applicativo Document Source/Consumer (WS Client), prima di effettuare una chiamata SOAP

verso il Web Service che vuole invocare, richiede l’autenticazione dell’operatore al modulo di

autenticazione. Il componente Identity Provider/STS verifica sul Server OpenLDAP la validità

delle credenziali inserite nel messaggio di richiesta (username e password).

Figura 5 - Diagramma di Flusso: Autenticazione Web Services



of 28

In caso di successo restituisce un’asserzione SAML firmata con chiave privata. Tale asserzione

viene quindi veicolata dal Source/Consumer tramite il SOAP header (WS-Security) ed usata dal

modulo ESB per verificare l’abilitazione dell’operatore ad accedere al servizio invocato.

L’operazione di verifica avviene utilizzando i seguenti step:

1. verifica della firma della SAML Assertion, con la chiave pubblica per controllare

l’autenticità delle identità e del profilo (ruoli) trasmessi

2. verifica che almeno uno dei ruoli associati all’utente sia abilitato all’invocazione del

servizio.

Se tutti i controlli sopraelencati vanno a buon fine il modulo instrada la chiamata verso il WS

che eroga il servizio.

Nel caso in cui i controlli non abbiano esito positivo, ossia che l’utente non risulti validato

sull’anagrafe operatori o che il suo ruolo non permetta di invocare il servizio dell’operazione

richiesta, viene restituito all’applicativo chiamante un messaggio di errore.

L’applicativo chiamante può utilizzare nelle successive chiamate il token SAML firmato fino alla

scadenza dello stesso.

La funzione di autenticazione è la seguente:

� RequestSecurityToken

Tale metodo viene esposto dal modulo Identity provider/STS che effettua il controllo delle

credenziali sull’anagrafe Operatori.

Le funzionalità esposte sono conformi ai seguenti standard:

- WS-Security

- SAML 1.1/SAML 2.0

Per le specifiche complete sull’Autenticazione STS SAML2.0 della Piattaforma far riferimento al

relativo documento menzionato nel paragrafo 3 (“Documenti correlati”).

6.1.2 Flusso documentale



of 28

Figura 6 - Dettaglio della transazione ITI-41

6.1.2.1 Flusso di inserimento

La funzione di sottomissione è la seguente come definito dal profilo di integrazione XDS.b:

� [ITI-41] Provide and Register Document Set-b

Come mostrato nel diagramma precedente il Document Source, che intende pubblicare un

documento sulla Piattaforma, dopo aver recuperato il Token SAML e prima di effettuare

l’invocazione del servizio deve:

1. Creare il documento (Document);

2. Produrre i metadata necessari alla classificazione del documento: DocumentEntry,

SubmissionSet e opzionalmente Folder (Le codifiche da utilizzare all’interno dei

metadata devono essere quelle definite nell’Affinity Domain);

3. Raggruppare tutti gli elementi sopracitati all’interno dell’elemento Submission Request

Una volta svolti i passaggi descritti al punto precedente, il Document Source può effettuare

l’invocazione del servizio.

Per maggiori dettagli relativi a questa funzionalità fare riferimento alla documentazione

contenuta sul TF IHE (‘Provide and Register Document Set-b’ descitta in IHE ITI TF-2b: 3.41).



of 28

6.1.2.2 Flusso di interrogazione

La funzione di interrogazione viene realizzata dalla seguente transazione del profilo XDS.b:

� [ITI-18] Registry Stored Query

Le query sono effettuate verso il Registry secondo lo standard della transazione IHE ‘Registry

Stored Query’. Per maggiori approfondimenti far riferimento a IHE ITI TF-2a: 3.18.

6.1.2.3 Flusso di recupero

La funzione di recupero è garantita dalla seguente transazione IHE:

� [ITI-43] Retrieve Document Set.b

Possono essere recuperati uno o più documenti identificati a seguito di una Stored Query o di

una notifica di disponibilità. I documenti sono recuperati come ‘base64 encoded’.

Per maggiori approfondimenti far riferimento a IHE ITI TF-2b: 3.43.

6.1.3 Flusso anagrafico

Le integrazioni con l’anagrafe della Piattaforma si possono riassumere nei seguenti due insiemi

di servizi:

1) Servizi di richiesta verso l’anagrafe (anagrafe = PIX manager)

2) Servizio di notifica da parte dell’anagrafe di Piattaforma (anagrafe = PIX source)

6.1.3.1 Servizi di richiesta verso il modulo MPI (PIX Manager)

I servizi di richiesta consentono ad una anagrafe esterna di effettuare sul modulo MPI le

seguenti operazioni

� Identificazione pazienti (ricerca in anagrafe piattaforma Piattaforma - Query )

� Servizio di richiesta inserimento in anagrafe Piattaforma (Insert)

� Servizio di richiesta aggiornamento di pazienti presenti in anagrafe (Update)

Gli schemi seguenti descrivono i servizi di richiesta verso il modulo MPI con le versioni HL7

supportate.



of 28

HL7 2.5

HL7 2.3

HL7 3.0

6.1.3.2 Servizi di notifica

Il servizio, una volta sottoscritto, provvede a notificare in modalità ‘push’ le variazioni che si

verificano sull’anagrafe di Piattaforma , in particolare

→ Inserimento di un nuovo paziente

MPI

Anagrafe esterna

ADTÂ04

ACKÂ04

ADTÂ08

ACKÂ08

QRYÂ19

ADRÂ19

Insert

Update

Query

MPI

Anagrafe esterna

PRPA_IN201301UV02 Insert

Update

Query

MCCI_IN000002UV01

PRPA_IN201302UV02

MCCI_IN000002UV01

PRPA_IN201305UV02

PRPA_IN201306UV02

MPI

Insert

Anagrafe esterna

ADTÂ28

ACKÂ28

ADTÂ31

ACKÂ31

QBP^Q22

RSP^Q22

Update

Query



of 28

→ Aggiornamento di una posizione in anagrafe relativamente a

- Dati anagrafici (indirizzo, identificativi della persona…)

- Dati sanitari (medico di assistenza, esenzioni …)

→ Riconduzione di due posizioni in anagrafe (fusione)

Gli schemi seguenti descrivono il servizio di notifica verso le anagrafi esterne con le versioni

HL7 supportate.

HL7 2.5

HL7 2.3

HL7 3.0

Anagrafe

Esterna

Insert

MPI

ADTÂ28

ACKÂ28

ADTÂ31

ACKÂ31

ADTÂ40

ACKÂ40

Update

Merge

Anagrafe

Esterna

Insert

MPI

ADTÂ04

ACKÂ04

ADTÂ08

ACKÂ08

ADTÂ40

ACKÂ40

Update

Merge

Anagrafe

Esterna

Insert

MPI

Update

Merge

PRPA_IN201301UV02

MCCI_IN000002UV01

PRPA_IN201302UV02

MCCI_IN000002UV01

PRPA_IN201304UV02

MCCI_IN000002UV01



of 28

6.1.4 Flusso di gestione delle notifiche

La gestione delle notifiche può avvenire secondo due profili d’integrazione IHE:

� DSUB

� NAV (recentemente deprecato da IHE, ma tuttora reso disponibile dalla Piattaforma)

Il flusso di gestione delle notifiche tramite profilo d’integrazione IHE-NAV si traduce nei

seguenti passi:

1. Un applicativo client pubblica un referto

2. Il Registry, utilizzando il profilo NAV, inoltra una mail al medico dell’assistito per il

quale è stato prodotto il referto.

3. L’applicativo di cartella può così procedere con lo scaricamento del documento dal

Repository e l’acquisizione in cartella.

6.1.5 Flusso di gestione delle codifiche

Il flusso di gestione delle codifiche si basa sul diagramma attori/transazioni mostrato sotto:

Figura 7 – Diagramma Attori/Transazioni

Il modulo MCI (Master Code Index) della Piattaforma svolge il ruolo di Value Set Repository

(VSR) per le codifiche (Value Set).

Gli applicativi esterni che devono fruire delle codifiche, svolgono il ruolo di Value Set

Consumer (VSC).

Più in dettaglio:



of 28

• Sul modulo MCI sono configurati e/o importate le codifiche (Value Set).

Esempi di codifiche che potrebbe avere senso gestire centralmente:

- Reparti, unità operative, centri di costo e dipartimenti;

- prestazioni, con declinazioni aziendali, regionali e nazionali;

- comuni, province, regioni e stati esteri secondo ISO e ISTAT

• Gli applicativi, che hanno il ruolo di Value Set Consumer (VSC) accedono ai Value Set

(VS) facendo delle query verso il modulo MCI, cioè il Value Set Repository (VSR), tramite

la transazione ITI-60

• All’atto della pubblicazione di inserimenti/modifiche/cancellazioni relativi ad un VS,

verranno inviate delle notifiche verso i VSC, che in tal modo potranno recuperare il VS

direttamente da MCI (tramite la transazione IHE ITI-60).

Una notifica viene inviata a un VSC se e solo se tale VSC è abbonato al particolare VS

variato. Un VSC può essere abbonato a più VS contemporaneamente, e riceverà notifiche

distinte per ciascuno di essi.

• Dal punto di vista fisico, MCI non invierà le notifiche direttamente ai VSC, bensì a DSUB

(che svolgerà il ruolo di (transazione IHE ITI-54): sarà compito di DSUB inoltrare le

notifiche ai VSC (transazione IHE ITI-52). In particolare, se abbiamo 5 VSC tutti abbonati

allo stesso VS, MCI invierà una sola notifica a DSUB il quale, sapendo che ci sono 5 VSC

abbonati, provvederà ad inoltrare la notifica a tutti e 5. DSUB sa quali sono i VSC

abbonati (e a quali VS), in base alla configurazione effettuata direttamente tramite la sua

console, e/o tramite apposita sottoscrizione (transazione IHE ITI-53).

Limitazioni e deroghe alle specifiche IHE

La transazione IHE ITI-60 così com’è non è in grado di soddisfare i requisiti che un servizio di

Value Set Repository deve erogare nel contesto della sanità italiana. Per questo il modulo MCI

ha esteso le specifiche di IHE allo scopo di:

• Restituire un insieme di informazioni dinamico e dipendente dal Value Set richiesto.

Esempio: il Value Set dei comuni è caratterizzato da un insieme di informazioni più

esteso di quello base previsto di IHE, e certamente diverso da quello del Value Set dei

Medici MMG.

• Consentire di effettuare ricerche filtrando su una o più delle informazioni che

caratterizzano determinati Value Set. Esempio: per i comuni, si desidera cercare per

data di inizio e fine validità.

A tal fine l’oggetto Concept è stato esteso con un tipo dati (elemento additionalProperties)

che consente di associare a ciascuna istanza un elenco dinamico di terne:

nome chiave / valore codificato / valore testuale

che rappresentano le proprietà peculiari di quel Concept all’interno del Value Set.



of 28

6.2 Flussi d’integrazione: casi d’uso

6.2.1 Caso d’Uso: Inserimento/Recupero di un documento

L’applicativo che si integra con l’architettura deve eseguire le seguenti operazioni per

inserire/recuperare un documento sulla/dalla Piattaforma X1.V1:

I. Autenticazione sul sistema e ricezione del token SAML. (‘RequestSecurityToken’)

II. Utilizzare il Token SAML ricevuto per effettuare le successive chiamate al modulo

Service Provider. Tali chiamate possono essere effettuate verso i servizi offerti dai

seguenti componenti:

a. MPI (invocazione del servizio di identificazione assistiti): dal messaggio HL7 tornato

al client/Source che invoca, viene recuperato l’identificativo dell’assistito (PID valido

all’interno dell’Affinity Domain) che sarà utilizzato nelle successive transazioni;

b. Repository: verso cui per effettuare la sottomissione di un referto CDA2 e dei relativi

metadati previsti dalla transazione IHE ‘[ITI-41] Provide and Register

Document Set-b’. Per la sottomissione del referto è necessario utilizzare il PID

ricavato in precedenza;

c. Registry: verso cui effettuare la ricerca dei documenti che soddisfano specifici

criteri di ricerca utilizzando la transanzione standard ‘[ITI-18] Registry Stored

Query’. Dal messaggio XML ricevuto il Consumer estrae, una volta individuato il

riferimento al documento di interesse, i metadati necessari per effettuare il

recupero del documento sul Repository (documentID e RepositoryOID);

d. Repository: da cui recuperare il documento utilizzando la transazione IHE standard

‘[ITI-43] Retrieve Document Set.b’

6.2.2 Caso d’Uso: Gestione Codifiche

Lo scambio dei cataloghi avverrà solo mediante le transazioni previste nel framework IHE,

ovvero la ITI-60.

In questa transazione, gli attori coinvolti risultano essere due: il Value Set Repository (VSR) e

il Value Set Consumer (VSC).

Come mostrato dalla figura 8, al fine di descrivere completamente le funzionalità previste dal

modello MCI, è necessario introdurre un terzo attore che rappresenta il sistema di gestione

delle notifiche (IHE-DSUB Document Metadata Notification Broker)



of 28

Il Sistema di Notifiche:

In attesa della definizione del sistema di notifiche e specifiche esposto dalla Piattaforma di

interoperabilità, sul quale MCI baserà la propria gestione, si descrivono i requisiti minimi

previsti dall’implementazione:

Le notifiche previste saranno di due tipi:

• Notifica di cambiamento dei Value Set

Questa notifica da parte di MCI si scatena ogni qual volta viene modificato un VS.

Le modifiche avvengono utilizzando le funzioni messe a disposizione da MCI

Tutti i subscriber definiti su MCI per lo specifico VS, verranno notificati.

Questa notifica scatena necessariamente la transazione di recupero da parte dei VSC del

VS notificato secondo le specifiche previste dalla ITI-60.

• Notifica di tracciatura e stato transazione

Deve essere prevista una specifica notifica di tracciamento e logging da parte di tutti i gli

attori chiamati al recupero di un VS, che definisca lo stato finale a conclusione delle

transazioni avvenute da e verso MCI.

Il tracciamento dello stato persisterà su MCI.

6.2.2.1 Strategie di allineamento

Consideriamo differenti strategie di allineamento dei Value Set (VS).

• Allineamento non sollecitato da notifica:

Il consumatore di VS interroga direttamente MCI con le specifiche descritte dall’analisi

funzionale ed ottenere un Value Set.

• Allineamento sollecitato da notifica:

L’Owner del VS, attraverso l’interfaccia del MCI, inserisce, modifica, cancella informazioni

di una specifica entità.

MCI applica le variazioni e provvede a notificare quanto è avvenuto ai sistemi interessati,

i quali le acquisiscono tramite l’utilizzo della transazione ITI-60.

6.2.2.2 Transazioni non sollecitate da notifica

Queste transazioni partono sempre da una richiesta inoltrata dal VSC, nella quale vengono

indicati i cataloghi che il VSR dovrà fornire al VSC.

Nel caso d’uso preso in considerazione viene schematizzata una transazione, dove un attore

con il ruolo di VSC richiedere un VS ad MCI, proprietario dello stesso:



of 28

Nella transazione descritta :

- l’attore deve implementare le logiche necessarie a VSC.

- MCI risulta il proprietario del catalogo che interessa all’attore sottoscritto.

- Il sistema di notifica registra l’esito della comunicazione ad MCI.

Il seguente diagramma di sequenza descrive il comportamento:

Figura 9 – Diagramma di sequenza

L’attore implementa la chiamata secondo le specifiche previste dalla ITI-60 e deve essere in

grado di interpretare le informazioni restituite dal VSR.

La definizione della struttura locale e manutenzione successiva dei VS restituiti da MCI

sull’attore chiamante (VSC) non è prerogativa del sistema descritto.

Il sistema di tracciatura, registra l’avvenuta corretta registrazione della chiamata su MCI che

ne salverà i contenuti per permettere tramite opportuno strumento di back-office di valutarne

la corretta conclusione.

6.2.2.2.1 Transazioni sollecitate da notifica

Il recupero VS da parte di un attore terzo può essere sollecitato da una notifica inviata da MCI

attraverso il sistema di notifiche.

Una volta individuata una modifica di un catalogo di cui MCI è owner, il sistema notifica la

variazione ad MCI che, come proprietario della lista dei sottoscrittori di quel catalogo, allineerà

adeguatamente questi ultimii con la variazione.

Il seguente diagramma di sequenza descrive il comportamento:



of 28

Figura 10 - Diagramma di sequenza



of 28

Appendice A – Gestione Errori

Legenda transazioni:

- P = Provide and Register-b

- SQ = Stored Query

- RS = Retrieve Document Set

- Q = Query Anagrafica

- NA = Notifica Anagrafica

Errore Azione Azioni client Note

201 P,SQ,RS,Q

,NA

Effettuare

nuovamente la

login

INVALID_DATE: Data dell'asserzione

SAML non valida

202 P,SQ,RS,Q

,NA

Tracciatura errore INCOMPATIBLE_ROLES: Ruolo utente

e/o operazione invocata non censito.

203 P,SQ,RS,

Q,NA

Tracciatura errore ABILITAZIONE_MEDIATOR: L’operazione

invocata non è consentita

204 RS Tracciatura errore REPOSITORY_RETRIEVE_MEDIATO:

Repository non trovato

205 SQ Provare a ripetere

la chiamata

OUT_FILTER: Errore generico filtraggio

risultati

206 P,SQ,RS,

Q,NA

Tracciatura errore ROLE_MEDIATOR: Errore generico AG

101 P,SQ,RS Tracciatura errore DOCUMENT_TYPE_MEDIATOR: Non è

possibile stabilire il tipo di documento

102 P,SQ,RS,

Q,NA

Tracciatura errore OPERATION_MEDIATOR: Non è possibile

stabile il tipo di operazione

104 P,SQ,RS Tracciatura errore ROLE_RETRIEVER_COD_FISC_UTENTE:

Non è possibile estrarre il CF dell’utente

105 P,SQ,RS Tracciatura errore ROLE_RETRIEVER_COD_FISC_MMG: Non

è possibile estrarre il CF del MMG

106 P,SQ,RS Avviare

nuovamente il

plug-in

ARIT_SERVICES_NOT_STARTED: Il client

non è avviato correttamente

108 P,SQ,RS,

Q,NA

Provare a ripetere

la chiamata

CUSTOM_CLASS_MEDIATOR:

Errore generico Access Gateway



of 28

Errore IHE Azione Azioni client Note

XDSRegistryNotAvailable P Tentare un nuovo

invio

XDSRegistryError P,SQ Tentare un nuovo

invio (P)

XDSRepositoryError P,RS Tentare un nuovo

invio (P)

XDSUnknownPatientId P Alert client PatientId non presente sul

server.

XDSPatientIdDoesNotMatch P Verifiche la corretta

generazione

tracciato dei

metadata

Questo errore viene

generato quando l'ID

paziente non presenta le

corrette corrispondenza

all’interno dei metadata.

XDSRegistryMetadataError P Verifiche la corretta

generazione

tracciato dei

metadata

XDSDuplicateUniqueIdInRe

gistry

P Verificare la corretta

generazione del

documentID

Identificativo del documento

duplicato



of 28

Appendice B - Plug-in

Per l’integrazione con la Piattaforma è possibile utilizzare appositi Plug-in adapters di tipo .NET

oppure Java.



of 28

Avvertenze

Questo documento contiene informazioni proprietarie e riservate di Dedalus. Nessuna

parte di questa pubblicazione può essere riprodotta, trasmessa, trascritta, registrata

o tradotta in qualsiasi lingua, in qualsiasi forma e con qualsiasi mezzo, elettronico,

magnetico, ottico, chimico, fisico o altro. Dedalus si riserva il diritto di correggere

questa pubblicazione e di apportare modifiche al suo contenuto senza l'obbligo di

informare chiunque di tali revisioni o modifiche. © 2014

Opera con certificazione di qualità UNI EN ISO 9001:2008

Sede Legale

Dedalus S.p.A.

via di Collodi 6/c

50141 FIRENZE

Tel: +39 055 42471

Fax: +39 055 451660

www.dedalus.eu

[DEDALUS X1.V1] Guida all'Integrazione IT v1.2rev2 FINALEDEDALUS_X1.V1]_Guida_all... ·...

Documents

Transcript of [DEDALUS X1.V1] Guida all'Integrazione IT v1.2rev2 FINALEDEDALUS_X1.V1]_Guida_all... ·...