Piattaforma. Guida all Integrazione. Descrizione Principali Funzionalità. Versione 1.2 BOZZA

Transcript

1 Piattaforma Guida all Integrazione Descrizione Principali Funzionalità Versione 1.2 BOZZA 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

2 Piattaforma X1.V1 Guida all Integrazione Pagina lasciata intenzionalmente bianca 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

3 Informazioni sul documento Metadati Emesso da Tipo Diritti di accesso Lingua Titolo Numero Dedalus S.p.A. - Via di Collodi, 6/C Firenze (ITALY) Guida all Integrazione Confidenziale Italiano Piattaforma X1.V1 - Guida all Integrazione TECH_X1.V1-INT_GUIDE_IT_v1.2 Versione 1.2 Stato Creato da Data di creazione Redattore/i FINALE Fabio Buti 2013-Ott-28 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. Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 3 of 28

4 Storia delle revisioni Ver. Rev. Data Autore(i) Note Ott-28 A.Olianti Prima bozza Gen-28 F. Buti Revisione intermedia Feb-21 F.Monari Aggiunta parte anagrafica e revisione generale Apr-01 F.Buti Finalizzazione (senza parte MCI) Apr-02 M.Spallanzani, F.Buti Aggiunta parte MCI fornita da M.Spallanzani Apr-08 F.Buti Revisione generale Mag-05 F.Monari Aggiunte e revisione parte anagrafica Mag-05 F.Buti Revisione intermedia Ago-08 F.Buti Finalizzazione Ago-29 F.Buti Revisione template Ott-27 A.Olianti Rimozione riferimenti a SAML Ott-27 F.Buti Finalizzazione Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 4 of 28

5 Sommario 1 Prefazione Destinatari Documenti Correlati Acronimi e abbreviazioni Introduzione all architettura X1.V Principali componenti dell architettura SSO (Single Sign-On) FSE / Dossier ESB Il Registry (indice dei documenti) Il Repository dei documenti MPI MCI Funzionalità Flussi disponibili Flusso di autenticazione WEB services Flusso documentale Flusso anagrafico Flusso di gestione delle notifiche Flusso di gestione delle codifiche Flussi d integrazione: casi d uso Caso d Uso: Inserimento/Recupero di un documento Caso d Uso: Gestione Codifiche Appendice A Gestione Errori Appendice B - Plug-in Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 5 of 28

6 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: 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: Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 6 of 28

7 4 Acronimi e abbreviazioni Di seguito è riportato il significato degli acronimi e delle abbreviazioni usati in questo documento. Termine ACK CN D-MIM DN ESB FSE HL7 IdP IHE IM IS JDK LDAP MCI MMG MPI OU PLS RDBMS SOA SOAP TCP/IP SSO STS WS XDS Significato General Acknowledgement (messaggio) Common Name Domain Message Information Model Distinguished Name Enterprise Service Bus Fascicolo Sanitario Elettronico Health Level 7 (Interface Standard) Identity Provider Integrating the Healthcare Enterprise Identity Management Information System Java Development Kit Lightweight Directory Access Protocol Master Code Index Medici di Medicina Generale Master Patient Index Organization Unit Pediatri di Libera Scelta Relational Database Management System Service Oriented Architecture Simple Object Access Protocol Transmission Control Protocol / Internet Protocol Single Sign-On Security Token Service Web Services Cross-Enterprise Document Sharing Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 7 of 28

8 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 Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 8 of 28

9 5.1 Principali componenti dell architettura 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 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 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 Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 9 of 28

10 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 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) 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 Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 10 of 28

11 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 Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 11 of 28

12 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) 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: Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 12 of 28

13 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 Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 13 of 28

14 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 ) Flusso documentale Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 14 of 28

15 Figura 6 - Dettaglio della transazione ITI 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). Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 15 of 28

16 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: 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: 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) 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. Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 16 of 28

17 HL7 2.5 Anagrafe esterna ADT^A28 ACK^A28 Insert MPI ADT^A31 ACK^A31 Update QBP^Q22 RSP^Q22 Query HL7 2.3 Anagrafe esterna ADT^A04 ACK^A04 Insert MPI ADT^A08 ACK^A08 Update QRY^A19 ADR^A19 Query HL7 3.0 Anagrafe esterna PRPA_IN201301UV02 MCCI_IN000002UV01 Insert MPI PRPA_IN201302UV02 MCCI_IN000002UV01 Update PRPA_IN201305UV02 PRPA_IN201306UV02 Query 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 Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 17 of 28

18 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 MPI ADT^A28 ACK^A28 Insert Anagrafe Esterna ADT^A31 ACK^A31 Update ADT^A40 ACK^A40 Merge HL7 2.3 MPI Anagrafe Esterna ADT^A04 ACK^A04 ADT^A08 ACK^A08 Insert Update ADT^A40 ACK^A40 Merge HL7 3.0 MPI Anagrafe Esterna PRPA_IN201301UV02 MCCI_IN000002UV01 PRPA_IN201302UV02 MCCI_IN000002UV01 Insert Update PRPA_IN201304UV02 MCCI_IN000002UV01 Merge Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 18 of 28

19 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 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: Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 19 of 28

20 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. Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 20 of 28

21 6.2 Flussi d integrazione: casi d uso 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 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) Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 21 of 28

22 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 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 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: Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 22 of 28

23 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 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: Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 23 of 28

24 Figura 10 - Diagramma di sequenza Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 24 of 28

25 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 202 P,SQ,RS,Q,NA 203 P,SQ,RS, Q,NA Effettuare nuovamente la login Tracciatura errore Tracciatura errore INVALID_DATE: Data dell'asserzione SAML non valida INCOMPATIBLE_ROLES: Ruolo utente e/o operazione invocata non censito. 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 Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 25 of 28

26 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 XDSRegistryMetadataError P Verifiche la corretta generazione tracciato dei metadata Verifiche la corretta generazione tracciato dei metadata Questo errore viene generato quando l'id paziente non presenta le corrette corrispondenza all interno dei metadata. XDSDuplicateUniqueIdInRe gistry P Verificare la corretta generazione del documentid Identificativo del documento duplicato Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 26 of 28

27 Appendice B - Plug-in Per l integrazione con la Piattaforma è possibile utilizzare appositi Plug-in adapters di tipo.net oppure Java. Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 27 of 28

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 Opera con certificazione di qualità UNI EN ISO 9001:2008 Sede Legale Dedalus S.p.A. via di Collodi 6/c FIRENZE Tel: Fax: Copyright 2014, Dedalus S.p.A. Tutti i diritti riservati Page 28 of 28