Mattone 9 Realizzazione del Patient File

Transcript

1 Mattone 9 Realizzazione del Patient File Architettura di Cooperazione Roma 19 Giugno 2007 Nolan, Norton Italia

2 Definizione del Fascicolo Sanitario Personale (FaSP) Non qualsiasi raccolta strutturata di documenti clinici relativi ad un soggetto, disponibile presso un singolo dominio organizzativo, bensì l insieme delle componenti organizzative e tecnologiche (basi di dati, indici, servizi di ricerca ed accesso, ecc.) che consentono l aggregazione delle informazioni di pertinenza di un utente, ovunque generate e disponibili. 1

3 Definizione del Fascicolo Sanitario Personale (FaSP) Accesso opportunamente protetto alle informazioni che costituiscono la storia clinica del paziente presupposto fondamentale per assicurare la continuità dei processi di cura ed evitare il ripetersi di prestazioni o indagini cliniche non necessarie 2

4 Definizione del Fascicolo Sanitario Personale (FaSP) Risalire in modo tempestivo nel corso di un processo di diagnosi e cura ai documenti clinici relativi ad un paziente problema complesso poiché tali informazioni sono distribuite su sistemi diversi e non integrati 3

5 Architettura del Fascicolo Sanitario Personale (FaSP) entità derivante dall integrazione dei sistemi esistenti, assumendo come presupposto fondamentale l adozione di modalità di progettazione il più possibile compatibili con assetti organizzativi e tecnologici diversificati Obiettivi allestire un livello di servizio funzionalmente omogeneo ed esteso ai diversi domini partecipanti (regioni, aziende sanitarie, sistemi dipartimentali), preservandone l indipendenza e l autonomia. 4

6 Modello adottato FEDERAZIONE DEI SISTEMI tutti i sistemi sono posti in posizione paritetica, e non vi sono sistemi centralizzati che ne accorpino le funzionalità, fatta eccezione per i servizi di supporto alla cooperazione Far dialogare sistemi diversi senza alterarne le modalità di funzionamento di base Ogni componente, pur conservando la propria logica applicativa, dev essere dotato di funzionalità in grado di trasformare le funzioni proprie in servizi erogabili ad altri sistemi secondo modalità e standard predefiniti 5

7 Modello federativo Integrazione dei sistemi gestionali (ad esempio il repository referti o il sistema ADT) Notifica al FaSP (alla sua componente denominata IBIS: Info Broker Individuale Sanitario) degli aggiornamenti, con registrazione dei soli riferimenti all evento, la cui memorizzazione completa rimane a carico del sistema gestionale 6

8 La notifica dell evento al FaSP Sistema Dipartimentale Invio Evento Gestore Eventi Consegna Evento FaSP (IBIS) 7

9 Modello di tipo federativo Le informazioni sull evento memorizzate sul registro del FaSP (IBIS) consistono dunque solo in dati sulla titolarità del documento clinico (id_utente), di riferimento temporale, di tipologia dell evento, e di puntamento/accesso ai dati applicativi del sistema gestionale/dipartimentale (metadati). Non è compito del FaSP centralizzare fisicamente le informazioni sanitarie esistenti in Azienda, ma solo di evidenziarne l esistenza rendendole accessibili. 8

10 Requisiti dell architettura flessibile, capace di integrare sistemi eterogenei; non intrusiva, caratterizzata dal minimo impatto sui sistemi dipartimentali in esercizio; federata, basata sull integrazione, anche a diversi livelli, di sistemi distribuiti, attraverso la cooperazione applicativa; scalabile, capace di integrare modelli tecnologicamente ed organizzativamente eterogenei attraverso la definizione di regole/protocolli condivisi di cooperazione, come nel caso dell integrazione di sistemi distribuiti fino al livello aziendale con sistemi accentrati sul livello regionale; estendibile, in grado di arricchirsi dinamicamente di nuovi contenuti informativi mediante l integrazione di nuovi sistemi dipartimentali; configurabile, capace di fornire dinamicamente nuove e diverse prospettive di ricerca e consultazione. 9

11 Componenti: sistemi dipartimentali - repository Si tratta dei sistemi informativi verticali (sottodomini) a supporto del processo di erogazione delle prestazioni socio sanitarie e/o di gestione del paziente/dell episodio di cura (Laboratori; Radiologia; ADT; Cartella Clinica di Reparto; Pronto Soccorso; Anagrafe Sanitaria; ecc.). Ad essi è demandata l archiviazione/conservazione del documento clinico e la sua produzione in seguito ad una richiesta di accesso. In alcune situazioni specifiche queste funzioni possono essere delegate ad un repository, che può anche adempiere a funzionalità di concentrazione dell informazione proveniente da sottodomini aziendali differenti. Ai sistemi dipartimentali è affidata la responsabilità di notificare gli eventi e, a richiesta dell utente, di estrarre ed eventualmente presentare le informazioni applicative di dettaglio. 10

12 Componenti: Porta Di Dominio (PDD) E l interfaccia standard per la cooperazione applicativa e l integrazione tra i sistemi dei diversi sottodomini e tra i diversi domini. E strutturata secondo gli standard CNIPA per il Sistema Pubblico di Connettività e Cooperazione. Gestisce l intero processo di scambio di messaggi tra sottodomini e domini, implementando sia il livello tecnologico sia il livello organizzativo. 11

13 Componenti: Gestore Eventi E un broker di messaggi, ovvero un sistema per l erogazione di servizi di acquisizione/raccolta e distribuzione/smistamento di informazioni, costituite nella fattispecie da notifiche di eventi contenenti i riferimenti alla titolarità del dato (id_utente), alla collocazione del documento clinico completo e/o gli altri dati ritenuti necessari per una più approfondita classificazione/indicizzazione al fine di agevolare la ricerca o pre-costituire percorsi di accesso (ad esempio per quadri clinici rilevanti) Per tutti gli eventi, l informazione è contenuta in un involucro standard (la busta di e-government), che contiene solo i dati essenziali legati all origine, all eventuale destinazione, all istante di generazione e alla tipologia dell evento. Le informazioni applicative costituiscono degli allegati e possono variare sia per formato sia per numero in funzione della specifica tipologia dell evento. 12

14 Componenti: IBIS - InfoBroker Individuale Sanitario (registro degli eventi) E un archivio degli eventi organizzato per cartelle individuali intestate agli assistiti Ha come contenuti i dati acquisiti attraverso le notifiche di evento e dunque senz altro le informazioni necessarie a definire la titolarità del dato (id utente), la collocazione del documento completo, la tipologia ed il riferimento temporale dell evento, il sistema di origine, ecc. Si tratta dell elemento centrale dell infrastruttura di dominio. A questo sistema viene attribuita la responsabilità della registrazione storica dei riferimenti agli eventi sanitari relativi ad un assistito. Attraverso la consultazione del Registro, l operatore autorizzato può venire a conoscenza dell esistenza e della localizzazione della documentazione clinica. 13

15 Componenti: Access Gateway E il sistema che rende disponibili i servizi di ricerca e di accesso all informazione attraverso le componenti descritte E il punto di accesso degli utenti all infrastruttura. Attraverso interfaccia WEB o applicativa (WS) rende accessibile il registro degli eventi, e si fa carico di raccogliere gli eventi clinici, aggregandoli e fornendoli al richiedente. 14

16 La struttura informativa dei registri <<reference>> M2 M1 Metamodello (ebrim) <<istanceof>> ebrim UML 2 Profile <<istanceof>> HL7-RCMR IHE-XDS HL7v3 datatype IBIS metadata model Istanza ebxml Registry 15

17 La struttura informativa dei registri 16

18 IBIS/AG Interfacce sistemi Clinici Interface Backend Intefacce sistemi clinici Intefacce Backend 17

19 Il modello complessivo Permette una crescita modulare del sistema (chi non ha un nodo puo appoggiarsi provvisoriamente ad un nodo esistente) Separa routing delle informazioni ed applicazioni (resistenza all obsolescenza) Il Sistema è intrinsecamente resistente ai guasti (se un nodo cade viene sostituito automaticamente da un altro nodo funzionate) Da TSE: Strategia architetturale v1.0 18

20 Sicurezza La gestione della sicurezza deve basarsi essenzialmente sull accertamento dell identit identità e sulla definizione del ruolo dell utente rispetto al servizio. Dato che la realizzazione del Fascicolo richiede l adozione di un architettura di federazione di sistemi e domini, è auspicabile la scelta di soluzioni che: 1. preservino l autonomia dei diversi attori nella definizione delle politiche di accesso 2. deleghino ai soli domini istituzionalmente competenti la produzione delle attestazioni relative a identità e ruolo degli operatori 19

21 Sicurezza Si tratta dunque di realizzare un sistema di sicurezza federato, in cui i diversi domini che cooperano nel richiedere ed erogare servizi sono autonomi nel definire le loro politiche di accesso e concorrono nel produrre ed assemblare le informazioni di certificazione di identità e di ruolo necessarie per consentire l acceso sicuro ai servizi. Un protocollo coerente con i requisiti esposti è SAML (security assertion mark up language) 20

22 Sicurezza Il protocollo si base sui concetti di: 1. certificazione di identità, cui è preposto un servizio abilitato a rilasciare asserzioni di identità (es.: si tratta del sig. X); 2. certificazione di attributo, di ruolo o di qualifica (cui è preposto un servizio abilitato a rilasciare asserzioni di attributo (es.: il sig. X è MMG dell ASL Y). Le certificazione di identità e di attributo costituiscono il profilo dell utente 21

23 Sicurezza Altra funzione fondamentale è quella del Gestore delle politiche di accesso, cui è preposto una componente incaricata di definire le regole per l autorizzazione all accesso al servizio. (es.: al referto può accedere solo il MMG del paziente) Il gestore delle politiche di accesso definisce il profilo del servizio 22

24 Sicurezza Dal confronto tra il profilo dell utente ed il profilo del servizio derivano le asserzioni di autorizzazione (accesso o diniego all accesso). Ad ogni dipartimentale vengono notificate le informazioni relative all autenticazione (identità) e qualifica (ruolo) dell utente operatore. Tali informazioni vengono trasmesse come Asserzioni (documenti XML, firmati e strutturati secondo lo standard SAML). Tutte le asserzioni viaggiano in una componente specifica del messaggio telematico definita portafoglio delle asserzioni. 23

25 Sicurezza 24

26 Aggiunta di un evento/documento al Fascicolo 25

27 Ricerca di eventi/documenti nel Fascicolo 26