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
Page 3 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.
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 4 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 5 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 6 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 7 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 8 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 9 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 10 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 11 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 12 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:
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 13 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 14 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 15 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).
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 16 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.
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 17 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^A04
ACK^A04
ADT^A08
ACK^A08
QRY^A19
ADR^A19
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^A28
ACK^A28
ADT^A31
ACK^A31
QBP^Q22
RSP^Q22
Update
Query
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 18 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^A28
ACK^A28
ADT^A31
ACK^A31
ADT^A40
ACK^A40
Update
Merge
Anagrafe
Esterna
Insert
MPI
ADT^A04
ACK^A04
ADT^A08
ACK^A08
ADT^A40
ACK^A40
Update
Merge
Anagrafe
Esterna
Insert
MPI
Update
Merge
PRPA_IN201301UV02
MCCI_IN000002UV01
PRPA_IN201302UV02
MCCI_IN000002UV01
PRPA_IN201304UV02
MCCI_IN000002UV01
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 19 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:
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 20 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.
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 21 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)
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 22 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:
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 23 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:
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 24 of 28
Figura 10 - Diagramma di sequenza
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 25 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 26 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
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 27 of 28
Appendice B - Plug-in
Per l’integrazione con la Piattaforma è possibile utilizzare appositi Plug-in adapters di tipo .NET
oppure Java.
Piattaforma X1.V1 – Guida all’Integrazione
Copyright © 2014, Dedalus S.p.A. Tutti i diritti riservati
Page 28 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