LA GIUNTA REGIONALE - ausl.vda.it · entro il 2012 del Fascicolo Sanitario Elettronico al fine...

1

LA GIUNTA REGIONALE

• visto il decreto legislativo n. 82 in data 7 marzo 2005 e successive modifiche e integrazioni, recante “Codice dell’Amministrazione digitale”;

• richiamata la legge regionale 25 gennaio 2000, n. 5 e successive modificazioni;

• richiamato il Piano regionale per la salute e il benessere sociale 2006-2008 approvato con Legge regionale n. 13 in data 20 giugno 2006, che prevede tra gli obiettivi l’estensione della rete dei sistemi informativi sanitari e sociali regionali, al fine di favorire l’accesso ai servizi da parte del cittadino e di sostenere i processi di programmazione e di controllo delle risorse umane, economiche e tecnologiche in ambito sanitario e sociale;

• visto il regolamento regionale n. 2 in data 24 luglio 2006, recante “Trattamento dei dati sensibili e giudiziari di competenza dell’Amministrazione regionale, dell’Azienda regionale sanitaria U.S.L. della Valle d’Aosta e degli enti dipendenti dalla Regione”, redatto ai sensi degli articoli 20 e 21 del decreto legislativo 30 giugno 2003, n. 196;

• visto il documento di architettura del Fascicolo Sanitario Elettronico approvato dal Tavolo Sanità Elettronica delle Regioni e delle Province Autonome che individua a livello nazionale la soluzione dell’architettura federata;

• richiamate le “Linee guida in tema di Fascicolo sanitario elettronico (Fse) e di dossier sanitario” approvate dal Garante per la protezione dei dati personali in data 16 luglio 2009;

• richiamata la deliberazione della Giunta regionale n. 1125, in data 24 aprile 2009, concernente l’approvazione, ai sensi dell'art. 7 della l.r. 5/2000, del contratto di programma fra la Regione autonoma Valle d'Aosta e l'azienda U.S.L. della Valle d'Aosta, per l'anno 2009, per la definizione dell'attività, della gestione, degli investimenti, degli obiettivi, dei risultati sanitari, di salute e gestionali, necessari in rapporto ai livelli essenziali di assistenza sanitaria da assicurare con le risorse finanziarie assegnate;

• richiamata la deliberazione della Giunta regionale n. 1459, in data 28 maggio 2010, concernente l’approvazione, ai sensi dell'art. 7 della l.r. 5/2000, del contratto di programma fra la Regione autonoma Valle d'Aosta e l'azienda U.S.L. della Valle d'Aosta, per l'anno 2010, per la definizione dell'attività, della gestione, degli investimenti, degli obiettivi, dei risultati sanitari, di salute e gestionali, necessari in rapporto ai livelli essenziali di assistenza sanitaria da assicurare con le risorse finanziarie assegnate;

• richiamata la deliberazione della Giunta regionale n. 1976, in data 17 luglio 2009, concernente l’affido dell’incarico di collaborazione tecnica, ai sensi della l.r. 18/1998, alla società Altran Italia S.p.A. di Roma, per la definizione di linee guida volte alla costituzione del Fascicolo Sanitario Elettronico (FSE) e alla progettazione di un’infrastruttura di cooperazione applicativa per la gestione dei debiti informativi socio-sanitari;

• visto il Piano e-government 2012 che prevede tra gli obiettivi prioritari la costituzione entro il 2012 del Fascicolo Sanitario Elettronico al fine migliorare il rapporto costo-qualità dei servizi erogati e di limitare sprechi ed inefficienze del Servizio Sanitario Regionale;

• richiamata la deliberazione della Giunta regionale n. 1682 in data 18 giugno 2010, concernente l’approvazione alla presentazione del Piano Pluriennale e-Government e Società dell’Informazione in Valle d’Aosta 2010-2013 al Consiglio regionale;

2

• considerato che il Fascicolo Sanitario Elettronico è un archivio informatico evoluto, che consente l’informatizzazione del processo di raccolta e gestione, secondo la logica del “fascicolo paziente”, di tutte le informazioni cliniche del cittadino consultabile per via telematica, in qualsiasi istante e da qualsiasi luogo, da chi sia autorizzato a farlo e limitatamente a quella parte per cui l’autorizzazione gli è stata conferita;

• evidenziato che la realizzazione del suddetto sistema informativo permette, come beneficio ulteriore rispetto alle sue finalità prime, la valorizzazione delle risorse economiche e umane utilizzate nel corso degli ultimi anni per lo sviluppo delle infrastrutture telematiche ad alta velocità, i progetti di collegamento tra ospedale e territorio e le integrazioni dei diversi sistemi informativi “verticali” in uso presso l’Azienda U.S.L. e le altre strutture accreditate e convenzionate con il S.S.R.;

• preso atto che in data 23 aprile 2010 la società Altran Italia S.p.a. ha consegnato il documento contenente le linee guida volte alla costituzione del Fascicolo sanitario ed il progetto per la realizzazione dell’infrastruttura per cooperazione applicativa e che gli stessi sono stati approvati, per quanto di competenza, dalla Direzione sistemi informativi del Dipartimento innovazione e tecnologia e dal Servizio risorse;

• atteso che la realizzazione del Fascicolo Sanitario Elettronico deve essere supportata da un adeguato sviluppo dell’infrastruttura di cooperazione applicativa, in una prima fase, tra i sistemi dell’Azienda U.S.L. e dell’Amministrazione regionale e, in una seconda fase, tra i sistemi della Regione e delle altre Regioni e dell’Amministrazione centrale;

• rilevato che, ai fini dell’accesso al Fascicolo Sanitario Elettronico, si prevede in ambito nazionale l’utilizzo di una carta a microprocessore personale conforme alle regole tecniche e di sicurezza previste dagli standard della Carta Nazionale dei Servizi;

• preso atto delle diverse alternative concernenti l’evoluzione della carta a microprocessore denominata “Carte Vallée” verso prestazioni conformi alla Tessera sanitaria e alla Carta Nazionale dei Servizi, analizzate nell’ambito del Gruppo di Lavoro costituito con lettera prot. n. 5586/SG in data 1° dicembre 2009 ed approvate con deliberazione di Giunta regionale n. 1309 del 14 maggio 2010, intesa quale strumento per l’acceso, da parte dei cittadini, alle informazioni sanitarie e in senso più ampio al Fascicolo Sanitario Elettronico personale;

• ritenuto di dovere approvare le linee guida, in allegato alla presente proposta di deliberazione, al fine di fornire all’Azienda U.S.L. tutte le indicazioni necessarie per pervenire entro il 2012 alla realizzazione del Fascicolo sanitario elettronico, qui riassunte:

o l’FSE viene costruito attraverso un modello federato, in cui si disaccoppiano i servizi di distribuzione (routing) delle informazioni sanitarie del paziente rispetto alle applicazioni che hanno generato le medesime, con l’intendimento di realizzare efficaci usi delle informazioni clinica con un minimo impatto sui sistemi clinici e sull’attività medica;

o l’FSE è costituito da informazioni cliniche che nascono e vengono mantenute, in linea generale, dall'ente/organizzazione che le ha prodotte e queste non vengono copiate o spostate in altri sistemi. L’organizzazione che ha prodotto i dati resta il solo ed unico responsabile per gli aggiornamenti e deve garantire l'affidabilità e la sicurezza dell’FSE medesimo.

3

o l’architettura federata e il principio precedente porta con sé la necessità di predisporre un’infrastruttura di cooperazione applicativa basata sulle regole del Sistema Pubblico di Connettività e Cooperazione di cui al D. Lgs 42/2005 e ss.mm.ii, in cui i sistemi cooperano esponendo servizi secondo la specifica SpCoop definita dal CNIPA (“Specifiche e requisiti funzionali del SPCoop”) ed ogni evento di tipo medico/clinico viene tracciato presso un apposito registro (Infobroker Individuale Sanitario-IBIS);

• ritenuto di stabilire nei confronti dell’Azienda U.S.L. della Valle d’Aosta il seguente cronoprogramma di scadenze per l’applicazione delle suddette linee guida:

o entro il 31 marzo 2011 la predisposizione di un apposito progetto volto all’applicazione delle suddette linee guida e contenente, tra l’altro, le specifiche tecniche dei componenti architetturali, i sistemi informativi e i relativi documenti sanitari interessati, le funzionalità di sicurezza e privacy, i casi d’uso, le modalità di accesso e il dettaglio dei costi e dei tempi di realizzazione del Fascicolo Sanitario Elettronico;

o entro il 30 giugno 2011 la realizzazione dell’infrastruttura di cooperazione applicativa conforme alle specifiche SPCoop di cui al Dlgs 42/2005 così come modificato dal D. Lgs. 159/2006;

o entro il 30 giugno 2012 il collaudo e la messa in opera del sistema definito in progetto;

• richiamata la propria deliberazione n. 3702 in data 18 dicembre 2009 concernente l'approvazione del bilancio di gestione per il triennio 2010/2012 con attribuzione alle strutture dirigenziali di quote di bilancio e degli obiettivi gestionali correlati, del bilancio di cassa per l’anno 2010 e di disposizioni applicative;

• visto il parere favorevole rilasciato dal Capo del Servizio risorse del Dipartimento sanità, salute e politiche sociali e dal Direttore della Direzione sistemi informativi del Dipartimento innovazione e tecnologia, ai sensi del combinato disposto degli articoli 13, comma 1, lettera e) e 59, comma 2, della legge regionale n. 45/1995 sulla legittimità della presente proposta di deliberazione;

• su proposta dell’Assessore alla Sanità, Salute e Politiche sociali Albert Lanièce, di concerto con il Presidente della Regione Augusto Rollandin;

• ad unanimità di voti favorevoli,

DELIBERA

1. di approvare le allegate linee guida all’Azienda U.S.L. della Valle d’Aosta per la costituzione del Fascicolo Sanitario Elettronico, che costituiscono parte integrante e sostanziale della presente deliberazione;

2. di dare atto che i costi derivanti dalle attività previste per la progettazione e la realizzazione del Fascicolo Sanitario Elettronico da parte dell’Azienda U.S.L. della

4

Valle d’Aosta trovano copertura nell’ambito degli interventi previsti dal finanziamento annuale trasferito all’Azienda U.S.L. della Valle d’Aosta per la realizzazione del sistema informativo aziendale;

3. di stabilire che il monitoraggio relativo all’applicazione delle linee guida venga eseguito dal Servizio risorse, sentito, per le parti di competenza, il Dipartimento innovazione e tecnologia;

4. di stabilire che la presente deliberazione sia trasmessa a cura del Servizio risorse all'Azienda U.S.L. della Valle d'Aosta per i provvedimenti di competenza.

§

Definizione delle Linee Guida per il Fascicolo Sanitario Elettronico Pagina 1 di 38 per Regione Autonoma Valle D’Aosta

Definizione delle Linee Guida per il Fascicolo Sanitario Elettronico della Regione Autonoma

Valle D’Aosta

13/08/2010 2209

Definizione delle Linee Guida per il Fascicolo Sani tario Elettronico Pagina 2 di 38 per Regione Autonoma Valle D’Aosta

sfioraso

Testo inserito


Indice 1. Obiettivi e contesto di riferimento ............................................................................................... 7

2. La situazione attuale ..................................................................................................................... 9

3. La Sanità Elettronica .................................................................................................................. 10

4. Il Fascicolo Sanitario Elettronico ............................................................................................... 11

5. Obiettivi dell’infrastruttura per la Sanità Elettronica ................................................................. 12 6. Gli strati tecnologici della Sanità Elettronica ............................................................................ 13 7. I componenti principali dell’infrastruttura di base per la Sanità Elettronica ............................. 15 8. Struttura e funzionamento di IBSE ............................................................................................ 17

8.1 L’infoBroker IBIS ............................................................................................................... 18

8.2 Alcuni casi d’uso di IBSE ................................................................................................... 20 8.2.1 Creazione Eventi Clinici .............................................................................................. 21 8.2.2 Richiesta dell’informazione clinica di un paziente ...................................................... 22

8.3 L’Event Broker .................................................................................................................... 24

8.4 Sicurezza e privacy .............................................................................................................. 24

9. Architettura Funzionale.............................................................................................................. 26

10. Conclusioni ............................................................................................................................. 37


Glossario CNIPA Centro Nazionale per l’Informatica nella

Pubblica Amministrazione RAVDA Regione Autonoma Valle D’Aosta USL Unità Sanitaria Locale ASL Azienda Sanitaria Locale FSE Fascicolo Sanitario Elettronico ICT Information and Communications Technologies SOA Service Oriented Architecture B2B Business To Business SOAP Simple Object Access Protocol HTTP Hypertext Transfer Protocol W3C World Wide Web Consortium XML Extensible Markup Language RPC Remote Procedure Call WSDL Web Services Description Language URI Universal Resource Identifier URL Universal Resource Locator UDDI Universal Description, Discovery and

Integration API Application Program Interface SPC Sistema Pubblico di Connettività SPCOOP Sistema Pubblico di Cooperazione SIL Sistema Informativo Locale PDD Porta Di Dominio SSL Secure Sockets Layer XSD XML (Extensible Markup Language) Schema

Documentation SICA Servizi infrastrutturali di interoperabilità,

cooperazione ed accesso JMS Java Messaging Services LDAP Light Directory Access Protocol HTTPS Hypertext Transfer Protocol Secure WSI Web Services Interoperability J2EE Java 2 Enterprise Edition JNDI Java Naming and Directory Interface JMX Java Management eXtentions EJB Enterprise JavaBeans MDB Message Driven Bean DBMS DataBase Management System JDBC Java Database Connectivity SSR Servizio Sanitario Regionale EHR Electronic Health Records IBSE Infrastruttura di Base della Sanità Elettronica


EA Enterprise Architecture IBIS InfoBroker Individuale Sanitario AG Access Gateway AO Azienda Ospedaliera MDA Model Driven Architecture P2P Peer To Peer RMI Remote Method Invocation CORBA Common Object Request Broker Architecture

(Object Management Group) UML Unified Modelling Language MMG Medico di Medicina Generale EB Event Broker RBAC Rule-Based Access Control CNS Carta Nazionale dei Servizi CIE Carta d’Identità Elettronica SAML Security Assertions Markup Language CIM Computation Indipendent Model PIM Platform Indipendent Model PSM Platform Specific Model HL7v3 Health Level 7 version 3 CDA Clinical Document Architecture DIT Dipartimento di Innovazione Tecnologica ebXML Electronic Business using eXtensible Markup

Language


Elenco Figure Figura 1 Il Sistema Sanitario Nazionale e l’ICT .................................................................................. 9 Figura 2 La Sanità Elettronica ........................................................................................................... 10 Figura 3 FSE (EHR) ........................................................................................................................... 12 Figura 4 Architettura Generale Sanità Elettronica ............................................................................. 14 Figura 5 Componenti IBSE ................................................................................................................ 16 Figura 6 IBSE un'architettura SOA basata su P2P ............................................................................. 18 Figura 7 Schemi di Deployment del FSE ........................................................................................... 20 Figura 8 Creazione di Eventi Clinici .................................................................................................. 22 Figura 9 Richiesta dell'informazione clinica di un paziente .............................................................. 23 Figura 10 : Architettura Funzionale FSE ........................................................................................... 26 Figura 11 Esempio di Computation Indipendent Model (Diagramma delle attività UML) .............. 29 Figura 12 Architettura di riferimento per il Fascicolo Sanitario Elettronico ..................................... 31 Figura 13: Specifica delle interfacce, dei metodi e del Data Model .................................................. 33 Figura 14: Funzionalità di ricerca di un documento sanitario ........................................................... 34 Figura 15: Funzionalità di pubblicazione di un documento sanitario ................................................ 35 Figura 16 Esempio di un sistema per la gestione del FSE ................................................................. 36


1. Obiettivi e contesto di riferimento Il Fascicolo Sanitario Elettronico o EHR (Elettronic Health Record), è un archivio informatico (repository) evoluto, che consente l’informatizzazione del processo di raccolta e gestione, secondo la logica del “fascicolo paziente”, di tutte le informazioni cliniche che possono essere generate durate la vita di una persona. Tutta la storia sanitaria di un paziente viene organizzata in un unico fascicolo elettronico che è consultabile per via telematica, in qualsiasi istante e da qualsiasi luogo, da chi (e solo da chi) sia autorizzato a farlo e limitatamente a quella parte per cui l’autorizzazione gli è stata conferita. Esempio. un cittadino piemontese, in vacanza in Valle D’Aosta, è colpito da un malore e viene ricoverato nel più vicino Pronto Soccorso di Aosta, che deve prestargli le prime cure in emergenza. In passato, questa persona è stata più volte oggetto di interventi e cure: ha subito un’operazione al cuore all’Ospedale Mauriziano di Torino, che custodisce nei suoi archivi l’anamnesi e i referti cardiologici; successivamente ha effettuato un paio di esami cardiologici presso l’Ospedale Le Molinette di Torino, che custodisce i relativi referti, lastre ed immagini; infine è stato degente, per problemi gastrici, nell’Ospedale di Pescara, che conserva i relativi referti, le lastre e i risultati delle analisi colà effettuate. L’obiettivo che ci si pone è di far arrivare in tempo reale al medico del Pronto Soccorso di Aosta tutte queste informazioni, in modo che egli possa avere immediatamente il quadro clinico della persona, che può essergli di grande ausilio rispetto all’appropriatezza delle cure da mettere in atto. Quindi il FSE serve a raccogliere elettronicamente le informazioni cliniche relative alla Persona, informazioni che possono essere state originate in qualunque struttura sanitaria (italiana, per cominciare, ma europea, come già prevedono i progetti UE) in modo da renderle disponibili ad ogni altro operatore sul territorio (nazionale e poi europeo) che debba prestare ulteriori cure a quella Persona. In Italia questa problematica è stata messa sotto la responsabilità di un Tavolo di lavoro permanente Sanità Elettronica delle Regioni e delle Province Autonome (TSE) che dal 2004 sta elaborando le linee guida del sistema italiano e nel 2006 ha emesso un documento di architettura. Va tenuto presente che i dati clinici non solo nascono e si originano all’interno di ogni singola struttura sanitaria che prende in cura la Persona, ma vengono colà custoditi secondo precise regole e normative riguardanti la responsabilità del dato, il suo livello di privatezza, le autorizzazioni all’accesso e alla distribuzione, etc. Attualmente una parte essenziale della documentazione viene consegnata alla Persona medesima, che può liberamente decidere l’uso da farne. In prima istanza, è quindi la Persona stessa a detenere il proprio Fascicolo Sanitario, su supporti prevalentemente cartacei o, al massimo, su memorie elettroniche off-line. Possiamo quindi avere architetture centralizzate, dove il FSE è fisicamente memorizzato in un repository centrale, accessibile in rete da ogni parte del mondo; e architetture cosiddette federate (come quella su cui si è orientato il TSE italiano) dove il FSE è in realtà un oggetto virtuale.


Nel primo caso sarà necessario copiare, attraverso un trasferimento fisico, i dati clinici dai sistemi della struttura che li ha originati, e che ne detiene la responsabilità, al repository centrale, con tutti i problemi di sicurezza e affidabilità, oltre a quelli legati al garantire disponibilità e accessibilità 24x7 del repository. Nel secondo caso (l’approccio italiano e della maggioranza degli altri Paesi) i dati restano fisicamente nelle strutture originanti e viene messo in rete, attraverso particolari protocolli e distribuendolo su vari nodi, semplicemente il loro indirizzo; su questa base, si realizza poi un sistema di ricerca, dove accedendo con l’identificazione della Persona, si ricevono i collegamenti ai documenti clinici relativi alla Persona medesima, che sono sparsi sui diversi sistemi informativi delle strutture sanitarie che li custodiscono. Il presente documento intende recepire le linee guida definite a livello di Amministrazione Centrale nell’individuazione di una strategia architetturale di riferimento per il sistema nazionale della Sanità Elettronica in coerenza con quanto previsto dal Decreto lgs. del 28 febbraio 2005, n° 42 che definisce e disciplina il Sistema Pubblico di Connettività (SPC). La visione architetturale è stata affrontata considerando alcuni requisiti necessari:

• deve permettere la disponibilità delle informazioni cliniche dell’assistito da ogni punto del territorio,

• deve, al contempo, rispettare l’architettura federata del Sistema Sanitario Nazionale utilizzandola come risorsa,

• deve avere un grado di sicurezza elevato e poter rispettare la legislazione sulla privacy, deve avere un livello elevato di Affidabilità/Disponibilità (24x7),

• deve avere una struttura modulare che permetta un’implementazione progressiva sul territorio e che sia, inoltre, resistente all’obsolescenza,

• deve avere la minima invasività possibile rispetto ai sistemi esistenti in modo da salvaguardare gli investimenti fatti,

• deve utilizzare standard aperti L’uso delle Tecnologie dell’Informazione e della Comunicazione (Information and Communication Technology, ICT) in ambito sanitario è necessario per poter realizzare un effettivo innalzamento qualitativo dei livelli di assistenza sanitaria e migliorare il coordinamento tra professionisti e tra strutture sanitarie. Le tecnologie ICT permettono inoltre una migliore partecipazione e consapevolezza dei cittadini verso il loro processo di cura. Come vedremo, l’uso delle tecnologie integrate nel processo di cura ha inoltre, come effetto secondario, anche la possibilità di un salto qualitativo del governo dell’intero Sistema Sanitario Regionale permettendo di raccogliere, in tempo reale, informazioni affidabili sulle prestazioni del sistema e rispettando simultaneamente la privacy dei cittadini.


2. La situazione attuale

Figura 1 Il Sistema Sanitario Nazionale e l’ICT La Figura 1 schematizza la situazione attuale dell’ICT in ambito sanitario. Le tecnologie sono in larga parte assenti nella parte centrale del sistema (la pratica clinica vera e propria). La conseguenza di questa situazione è che ad ogni suo accesso al sistema sanitario, l’assistito perde la sua storia: non vi è quasi memoria, per il sistema sanitario, delle sue caratteristiche mediche, del suo stato e della sua storia clinica. L’Amministrazione raccoglie con difficoltà le informazioni sull’attività medica per poi trasmetterle all’amministrazione centrale tramite mezzi obsoleti e ad alto rischio sia in termini di affidabilità che di privacy. E’ lo stesso assistito che deve portare con sé la sua memoria clinica, tramite documenti cartacei o, a volte, deve sperare in una rete di contatti informali tra il personale medico. Questo comporta sprechi di risorse e di tempo e può facilmente introdurre degli errori, vista la natura verbale e cartacea del processo. Oltre alle inefficienze cliniche dirette, anche dal punto di vista del governo del sistema complessivo la gestione cartacea genera mancanze e sprechi: i dati giungono con ritardo e devono essere sottoposti a processi di data entry intensivi risultando spesso non del tutto affidabili. La


conseguenza è un uso non ottimale delle risorse. Va inoltre considerato che un sistema interoperabile permetterebbe, in tempo reale, anche un efficace sistema di controllo statistico/epidemiologico di eventuali emergenze sanitarie.

3. La Sanità Elettronica Con la realizzazione di un sistema di Sanità Elettronica, gli strumenti dell’ICT sono utilizzati nella pratica medica per scambiare le informazioni tra professionisti lasciandone comunque il controllo all’assistito (vedi Figura 2). E’ importante sottolineare che per parlare di Sanità Elettronica non è sufficiente disporre di applicazioni informatiche stand alone, ma è necessario che le applicazioni siano tra loro interoperabili e permettano quindi l’effettivo passaggio delle informazioni tra attori, senza interruzioni. Con la realizzazione di un’infrastruttura di Sanità Elettronica viene progressivamente realizzato un dominio sistematico, dove gli operatori sanitari sanno come agire e che abilita nuove possibilità di conoscenza, accesso e manipolazione dei dati clinici elevando la qualità professionale del loro lavoro e generando nuove possibilità di servizio all’assistito.

Figura 2 La Sanità Elettronica


4. Il Fascicolo Sanitario Elettronico Il cuore di un’Infrastruttura di Base della Sanità Elettronica consiste in un efficace routing delle informazioni dell’assistito tra gli attori autorizzati del sistema. Il concetto chiave per realizzare questo è il Fascicolo Sanitario Elettronico (FSE) dove vengono raccolti gli eventi sanitari dell’assistito mano a mano che vengono generati. E’ importante sottolineare che l’FSE non va visto, concettualmente come un database. Storicamente è stato concepito in questo modo in quanto le basi di dati monolitiche erano il concetto chiave delle vecchie architetture (monolitiche) ed erano inizialmente l’unico disponibile. Tuttavia questa concezione è inadeguata dal punto di vista realizzativo e non corrisponde ai requisiti base della Sanità Elettronica. Infatti, vi è:

• una molteplicità di attori che creano le informazioni e di cui ne rimangono responsabili (secondo competenze distinte)

• una molteplicità di attori che utilizzano le informazioni (secondo le autorizzazioni ed in modo non del tutto prevedibile nei dettagli),

• una molteplicità di usi dei dati (primari e secondari). Le architetture oggi permettono, in questo contesto, l’uso di concetti più avanzati ed adeguati. Il problema di un Fascicolo Sanitario Elettronico non è solamente raccogliere i dati dell’Assistito ma portare le informazioni agli attori coinvolti nella cura dell’assistito ogni volta che queste sono necessarie. Questo concetto ci permette di fare un’importante distinzione tra i meccanismi di routing informativo e le applicazioni che producono ed elaborano tali informazioni. Il disaccoppiamento tra il servizio di distribuzione (routing) delle informazioni e le applicazioni permette di dare una maggiore flessibilità e robustezza architetturale al sistema, dando la possibilità alle applicazioni di evolvere senza che questo abbia seri impatti sull’architettura del sistema complessivo. Nella Figura 3 è rappresentata schematicamente questa concezione che permette inoltre di realizzare efficaci usi secondari delle informazioni con un minimo impatto sui sistemi clinici e sull’attività medica.


Figura 3 FSE (EHR)

5. Obiettivi dell’infrastruttura per la Sanità Elet tronica Nei punti seguenti sintetizziamo i principali requisiti adottati per l’Infrastruttura di Base della Sanità Elettronica (IBSE) che ha per obiettivo la realizzazione del Fascicolo Sanitario Elettronico (FSE): a) Disponibilità delle informazioni cliniche L’infrastruttura deve rendere disponibili le informazioni cliniche dell’assistito (la sua storia clinica) dove e quando queste sono clinicamente utili, da qualsiasi punto del territorio nazionale. Si dovrà cioè rendere disponibile all’assistito ed agli operatori sanitari autorizzati un Fascicolo Sanitario Elettronico (FSE), abbandonando progressivamente la gestione cartacea dell’attività clinica su scala nazionale. b) Architettura Federata Data la competenza regionale in ambito sanitario, l’architettura complessiva dell’infrastruttura deve essere federata. Questo, del resto, appare in linea con le moderne architetture tecnologiche e con la cooperazione applicativa prevista dal Sistema Pubblico di Connettività e Cooperazione (SPCoop). Quindi si può sostenere che l’esistenza di un’infrastruttura di Cooperazione Applicata è condizione sine qua non per la realizzazione del FSE. c) Sicurezza e Privacy L’infrastruttura, data la delicatezza delle informazioni trattate, deve avere un grado di sicurezza elevato in termini di sicurezza e rispetto della privacy. La federazione dei sistemi deve quindi basarsi su un profilo condiviso di sicurezza sia tecnologica che organizzativa. d) Affidabilità/Disponibilità dell’infrastruttura L’infrastruttura deve essere intrinsecamente affidabile e deve avere una disponibilità 24x7. Va progettata per poter raggiungere, progressivamente, un livello di affidabilità che, per alcuni aspetti, può essere considerato di tipo safety critical. Deve quindi avere meccanismi, caratteristiche e


ridondanze che garantiscano affidabilità e tolleranza ai guasti su tutti i livelli (hardware, sistemistico, di messaggistica, software). e) Struttura Modulare L’infrastruttura deve essere pensata in maniera modulare, e non in modo monolitico, per evitare una rapida obsolescenza del sistema. Le applicazioni di sanità elettronica devono poter evolvere indipendentemente senza che questo abbia un impatto rilevante a livello di sistema. f) Integrazione con i sistemi esistenti L’infrastruttura deve avere la minima invasività possibile rispetto ai sistemi esistenti, questo sia per salvaguardare gli investimenti fatti, sia per garantire che l’infrastruttura non carichi di complessità i sistemi locali rendendo difficoltosa la sua adozione. g) Uso di standard aperti L’uso di standard aperti non solo garantisce gli investimenti, ma è un prerequisito in un sistema, come quello della sanità elettronica, che ha nell’interoperabilità il suo substrato chiave. L’uso di standard aperti non riguarda solamente i protocolli di trasporto (la cui interoperabilità deve essere completa) ma anche gli aspetti sintattici e semantici (documenti e dati scambiati tra i sistemi).

6. Gli strati tecnologici della Sanità Elettronica La Figura 4 mostra schematicamente gli strati tecnologici che compongono un sistema di Sanità Elettronica nel suo complesso ed evidenziano i componenti dell’Infrastruttura di Base della Sanità Elettronica (IBSE):

• Alla base del sistema abbiamo gli standard per l’interoperabilità applicativa specificati da SPCoop. Questo insieme di specifiche abilita la realizzazione di SOA (Service Oriented Architecture) nei rapporti tra le pubbliche amministrazioni e fornisce la base infrastrutturale per i servizi applicativi federati, adeguati a superare i limiti delle vecchie architetture monolitiche che risultano, inoltre, particolarmente inadatte all’ambito sanitario.


Figura 4 Architettura Generale Sanità Elettronica • A livello infrastrutturale superiore vi è il sistema di indicizzazione e routing degli eventi

sanitari. Questo livello è costituito tramite il componente infrastrutturale che referenzia gli eventi/documenti e ne permette la distribuzione agli attori autorizzati. Il componente centrale del sistema è quindi un InfoBroker Individuale Sanitario (IBIS) che permette di realizzare il Fascicolo Sanitario Elettronico dell’assistito in modo virtuale. I documenti referenziati nell’IBIS rimangono sotto la responsabilità delle organizzazioni coinvolte, ma dal punto di vista dell’utente (autorizzato) appaiono in modo trasparente come un unico fascicolo.

• ll livello successivo è quello dell’interoperabilità a livello di informazioni scambiate (Interoperabilità Sintattica/Semantica) a livello di applicativi. Sebbene nella logica dell’infrastruttura è previsto che il sistema di indicizzazione delle informazioni sia indipendente dallo standard dei documenti elettronici scambiati all’interno del sistema è evidente che è necessario raggiungere progressivamente una standardizzazione dei documenti elettronici scambiati almeno a livello sintattico. A questo livello l’obiettivo finale è anche l’interoperabilità a livello semantico degli oggetti informativi scambiati anche se l’obiettivo pragmaticamente raggiungibile nell’immediato è solo a livello sintattico.

• L’ultimo livello è quello dell’integrità dei processi: se ad un livello iniziale è sufficiente raggiungere l’armonizzazione a livello di scambio di oggetti informativi mantenendo tuttavia i servizi forniti stateless, l’obiettivo finale è permettere l’orchestrazione/coreografia dei processi gestendo workflow e transazioni e garantendo l’integrità dei processi di collaborazione tra attori.


• Trasversali sono ovviamente le politiche di privacy e la sicurezza del sistema complessivo che sono un aspetto centrale per l’intero sistema di Sanità Elettronica.

• Il Repository dei modelli rende disponibili i modelli utilizzati nell’Enterprise Architecture Federata di IBSE in un insieme coerente di principi, processi, metodi e componenti utilizzati nel disegno e nella realizzazione dei sistemi partecipanti. L’Enterprise Architecture (EA) sta emergendo come un aspetto necessario del governo di sistemi complessi dove l’ICT e l’interoperabilità hanno un ruolo importante e dove gli aspetti tecnologici devono essere mappati efficacemente sugli aspetti organizzativi.

7. I componenti principali dell’infrastruttura di b ase per la Sanità Elettronica La Sanità è un sistema complesso, centrato sul cittadino/assistito, ma in cui gran parte delle

informazioni sono ad uso immediato di altri attori, come operatori sanitari (ad esempio, medici) ed amministrativi (ad esempio, istituti di previdenza, ..). Le informazioni sono sottoposte a criteri molto severi di accesso, di sicurezza e privacy ed al momento della creazione dell’informazione (es. un referto) non è prevedibile quale specifico attore sarà autorizzato ad accedervi. La gestione cartacea degli eventi sanitari occulta, in gran parte, questo tipo di problemi e questo si inserisce in una struttura amministrativa a carattere federale con competenze che sono distribuite tra Regioni, ASL/AUSL, AO, e organi centrali come Ministero della Salute ed Istituti di Previdenza. Il routing delle informazioni non è quindi supportato dai paradigmi tradizionali dell'interoperabilità che in gran parte sono basati sull’idea di transazioni bilaterali tra partner noti al momento della transazione. In questo contesto l’infrastruttura di IBSE ha come obiettivo la realizzazione di un efficace routing

delle informazioni sanitarie degli assistiti create dagli eventi individuali (contatti dell’assistito con il sistema sanitario nazionale). In questo modo viene data al cittadino la possibilità di disporre di un

proprio Fascicolo Sanitario Elettronico, fornendo l’accesso alle informazioni sanitarie indipendentemente dalla loro localizzazione fisica. L'infrastruttura è stata concepita per essere completamente decentralizzata e prevede che ogni ente, Regione o ASL, fornisca parte delle risorse di elaborazione e di rete necessarie per realizzare il sistema di gestione delle cartelle cliniche che apparirà, per un utente, come un unico sistema. IBSE quindi sarà costituita dall'insieme stesso degli enti partecipanti e da una parte delle loro risorse hardware. La strategia è di evitare di avere un'infrastruttura che si basi sull'esistenza di server centralizzati (o più server in un cluster intranet tra loro) che raccolga ed integri i dati clinici dei pazienti. Si vuole anche evitare di avere una soluzione che, pur non centralizzando i dati, dipenda da un unico sistema di mediazione tra le richieste. Ogni Regione sarà responsabile di cercare, prelevare ed aggregare i dati per tutti i suoi utenti o per quelli che vi si collegheranno. Il tipo di architettura prevista permette anche di ridurre al minimo l’impatto sui sistemi e le architetture locali preservando il più possibile gli investimenti. Si vuole che le informazioni cliniche nascano e vengano mantenute, in linea generale, dall'ente che le ha prodotte e non vengano copiate o spostate in altri sistemi. L’organizzazione che ha prodotto i dati resta il solo ed unico responsabile per gli aggiornamenti e ne deve garantire l'affidabilità e la sicurezza.


I cardini principali che guidano la definizione dell'architettura IBSE e i principali componenti coinvolti nell’infrastruttura, schematicamente illustrati in Figura 5, sono i seguenti:

• i sotto-sistemi regionali (ovvero l’insieme dei sistemi afferenti alla Regione Autonoma Valle D’Aosta) che forniscono le informazioni sulla singola cartella clinica o su un singolo evento, sono esposti come servizio attraverso una porta di dominio secondo la specifica SPCoop;

• tutti gli eventi che definiscono la storia medico/clinica di un assistito vengono tracciati da un registro distribuito, decentralizzato e federato (InfoBroker Individuale Sanitario, IBIS ). Si assume che ogni sottosistema che genera eventi clinici (prescrizioni, esiti, accettazione, dimissione ecc.) aggiorni l’IBIS;

Figura 5 Componenti IBSE

• L’ AccessGateway (AG) è il sistema che si occupa di raccogliere, aggregare e formattare la cartella clinica; è distribuito e può essere potenzialmente installato presso ogni singolo ente partecipante (Regione/ASL/AO). Si tratta di un servizio stateless che è il punto di accesso dei client all'infrastruttura di base. L'AccessGateway mette in connessione i propri utenti web o web-service con il registro degli eventi, raccoglie alla fonte i dati clinici, li aggrega e li fornisce agli utenti.

• Un componente importante, è il Model Repository. Questo raccoglie i modelli dei processi, dei servizi, dei dati (in termini di metadati) che sono implementati da IBSE, ne permette la consultazione e l'esportazione. In questo modo, ad esempio, i processi complessi che permeano la sanità sono facilmente navigabili e non vanno “persi” nelle righe di codice che lo implementano. Sono memorizzati in un formato semanticamente ricco che ne permette oltre che la visualizzazione grafica, anche la manipolazione. L'obiettivo, attraverso l'approccio Model Driven Architecture (MDA), è di poter successivamente definire e manutenere i processi più strategici e complessi senza dover passare per l'intero ciclo di


sviluppo software; un approccio MDA, associato al Repository di Modelli, può far sì che una modifica al modello comporti un aggiornamento del software senza problemi. La creazione di un repository dei modelli dei processi permette, inoltre, di salvaguardare gli investimenti, permettendo il riuso di modelli definiti in modo indipendente dall’evoluzione degli standard tecnologici. Il repository è anche una guida per permettere ad ogni amministrazione di gestire in modo coerente i propri workflow di processo/servizio.

• IBSE rispecchia, nel suo complesso, un'architettura Service Oriented (SOA), ma ha la peculiarità di avere un registro/infobroker dei documenti sanitari decentralizzato, basato su un'architettura P2P(peer to peer). Lo scopo principale di questa scelta è di ottenere una vista organica della cartella clinica, salvaguardando sia la logica naturalmente federata del sistema sanitario, sia permettendo un livello di affidabilità e flessibilità architetturale del suo componente critico non altrimenti ottenibile.

I componenti di IBSE, nel loro funzionamento, realizzano il Fascicolo Sanitario Elettronico componendolo dinamicamente a partire dai documenti clinici (prescrizioni, referti, ricoveri ecc.) che si accumulano nella storia clinica dell’assistito. L’FSE viene in questo modo realizzato senza complesse duplicazioni di dati, che rimangono nella responsabilità degli enti che li producono ma che possono essere acceduti, di volta in volta, secondo le autorizzazioni previste.

8. Struttura e funzionamento di IBSE La Figura 6, descrive l'organizzazione topologica del sistema; si individuano le ASL/Regioni (tra cui la VDA) ed all’interno di queste l’InfoBroker Individuale Sanitario (IBIS). Ogni ente, sia essa

Regione, ASL, AO o altro, fornisce il punto d'ingresso alla rete del Sistema Sanitario Nazionale

attraverso l'AccessGateway (AG).


Figura 6 IBSE un'architettura SOA basata su P2P

8.1 L’infoBroker IBIS In ogni tecnologia di elaborazione distribuita viene utilizzato un indice dei servizi chiamato

tecnicamente naming service (nella tecnologia web service prende il nome di UDDI, in J2E si chiama RMI Registry, in CORBA Naming Service, in Java JMS è JNDI) che ha lo scopo di permettere la ricerca dei servizi disponibili in rete. Alcuni ne descrivono anche l'interfaccia (es.

Web service UDDI e CORBA Naming Service). La ricerca basata su naming services avviene principalmente per descrizione, nome del fornitore del servizio, struttura dell'interfaccia, ma − diversamente dall'IBIS − la ricerca non verte sulle

informazioni che i servizi possono fornire. Nel caso IBSE un generico naming service non è sufficiente per sapere quale servizio deve essere interrogato per ricevere uno specifico tipo di

informazione (e.g. la cartella clinica di un paziente), poiché in una stessa rete vi sono più fornitori (sono gli enti ospedalieri stessi) dello stesso servizio (es. fornire la cartella clinica) che

implementano la medesima interfaccia ma che gestiscono dati di tipo diverso. L'IBIS non intende

sostituire un indice dei servizi che resta comunque sempre indispensabile, ma aggiunge un indice di eventi sanitari che permette, agli utenti programmatori e ad altri servizi IBSE, di conoscere quale servizio contattare per ottenere delle informazioni sanitarie.


E' stato più sopra accennato che l’IBIS è un registro distribuito, decentralizzato e federato. Si tratta di una rete peer to peer i cui nodi sono presenti in ogni ente partecipante e presso altri organismi al fine di aumentare il grado di ridondanza e migliorare la tolleranza ai guasti. L'informazione può essere scritta in qualunque nodo, e viene prontamente ed automaticamente

replicata presso altri nodi della rete attraverso specifici algoritmi. L'informazione è anche replicata

in modo ridondante, in questo modo la rete risulta essere tollerante ai guasti; se per caso un nodo non fosse raggiungibile, l'informazione sarebbe recuperabile da un qualunque altro nodo. Questo approccio evita il "single point of failure", e tramite il meccanismo della prossimità,

minimizza i tempi di riposta della rete, poiché avvicina il dato verso il sistema che lo richiede.

Questa caratteristica rende la topologia di rete dell' InfoBroker pensata sul modello scale-free. Come conseguenza, ogni nodo della rete sarà raggiungibile in circa 2 o al massimo 3 passi, il che rende la velocità di distribuzione molto veloce anche per diverse migliaia di nodi. L'obiettivo è far sì che IBIS si configuri automaticamente come una rete scale-free, rendendo, in questo modo, efficaci le ricerche e la distribuzione delle informazioni. Inoltre, affiancando dei

meccanismi di replicazione delle informazioni, IBIS è tollerante ai guasti. La ricerca, così come l'inserimento, è implementata tramite opportuni meccanismi (“flooding

algorithms”) che garantiscono che tutta la rete venga attraversata in tempi compatibili con le attese medie che si hanno consultando i grandi portali di ricerca di Internet (es. Google, Yahoo, Amazon, Ebay). Rispetto ad un database, un registro è più semplice poiché l'informazione non è strutturata e non è soggetta ed essere modificata. L’IBIS contiene un elenco di puntatori ad eventi clinici che risiedono al suo esterno; ogni record quindi rappresenta un'informazione complessa che, però, non risiede nel registro, ma nell'ente che lo ha prodotto e che ne detiene la responsabilità di gestione. Le operazioni possibili in un registro di questo tipo sono l'inserimento e la ricerca; non vi è generalmente la necessità di modificarlo. Nel caso in cui l'evento clinico stesso subisca una modifica, l'EventBroker dell’IBIS conterrebbe al più un nuovo evento: quello originario resterebbe invariato. Non supportando la modifica, l’IBIS non ha quindi la necessità di gestire gli accessi concorrenti e le transazioni.


Figura 7 Schemi di Deployment del FSE Un ulteriore aspetto rilevante è l’ampia flessibilità di deployment del sistema complessivo. Come mostrato nella Figura 7 l’architettura P2P permette ad ogni Regione di poter scegliere il proprio schema di deployment in base alle proprie esigenze architetturali ed organizzative; supportando, in modo trasparente, un ventaglio ampio di possibilità: dalla centralizzazione delle infrastrutture fino a schemi completamente distribuiti a livello di singola azienda.

8.2 Alcuni casi d’uso di IBSE In questo paragrafo vengono illustrati due scenari di funzionamento di IBSE mediante UML Communication Diagram. I componenti di IBSE coinvolti verranno illustrati più in dettaglio nei


paragrafi successivi. Per semplicità non sono riportate le porte di dominio SPCoop la cui presenza viene data per scontata. Rispetto al registro SICA i riferimenti dei servizi presenti in IBSE vengono mantenuti con le procedure standard previste in SPCoop. SICA (Servizi di Interoperabilità, Cooperazione ed Accesso), offre una serie di servizi e componenti software infrastrutturali, tra i quali il registro dei servizi, (non riconducibili a nessuna amministrazione specifica), il cui obiettivo è di mediare e supportare la cooperazione tra le amministrazioni..

8.2.1 Creazione Eventi Clinici Il Diagramma di Comunicazione UML in Figura 8 illustra il meccanismo di referenziazione e distribuzione di un nuovo evento/documento nel Fascicolo. 1. – Scarica documento: un soggetto (es. laboratori, reparti, pronto soccorsi, sottosistemi degli enti stessi, ecc.) che genera un evento (documento) clinico scarica il documento (es. un esito di laboratorio) nel repository (loadDocument). E’ possibile che, in alcuni casi, lo stesso sistema Gestionale possa avere le funzioni di repository nel qual caso non viene effettuato questo passo. 2. – Registra documento: viene inviato dal repository all’AccessGateway (e quindi all’IBIS) un opportuno messaggio (registerDocument) contenente le informazioni sul documento clinico generato che entrano a far parte dell’indice dei documenti. Data la natura distribuita dell'IBIS, il nodo contenente l’IBIS da contattare sarà quello installato presso il soggetto che ha generato l’evento; tuttavia, in caso di malfunzionamenti, qualunque altro nodo potrà essere usato. Il nodo IBIS contattato informerà i nodi “prossimi” del nuovo evento pubblicato ed essi, a loro volta, lo distribuiranno attraverso opportuni algoritmi a tutta la rete di nodi IBIS. 3. – Notifica documento clinico: l’ IBIS tramite l’Access Gateway (AG) notifica (notifyNewDocument) tramite un meccanismo di publish-subscribe la generazione del nuovo documento agli utenti autorizzati (subscriber, es. MMG) fornendo un indice (cioè un puntatore) dell’evento.


Figura 8 Creazione di Eventi Clinici

4. – Seleziona documento: L’utente che ha ricevuto la notifica all’interno del suo software gestionale (es. Software di Cartella clinica MMG ) o tramite un’interfaccia web seleziona il documento notificato (selectDocument) 5. – Richiedi documento: L’utente richiede il documento al repository (getDocument) 5.1 – Ricevi documento: L’utente riceve il documento dal repository (retrieveDocument) e lo può visualizzare

8.2.2 Richiesta dell’informazione clinica di un paz iente Il Diagramma di Comunicazione UML in Figura 9 illustra il meccanismo di ricerca e recupero di un evento/documento dal Fascicolo. 1. - Richiesta ricostruzione del quadro clinico di un assistito: un operatore sanitario autorizzato (medico di medicina generale, di pronto soccorso, specialista, ecc.) che vuole ricostruire il quadro clinico di un assistito si connette all'AccessGateway locale (tramite la sua applicazione o via interfaccia web), ed effettua la sua richiesta della lista dei documenti (getDocumentList).


L'AccessGateway accede all'IBIS tramite il nodo più prossimo che fornisce l'elenco degli (indici degli) eventi clinici. 1.1 – Ricezione lista documenti clinici: l’Access Gateway fornisce la lista al richiedente (retrieveList). L'elenco ottenuto contiene già di per sé delle informazioni di base, come, presumibilmente, la data e l'ora dell'evento, il soggetto che lo ha prodotto, il tipo di evento, ecc.

Figura 9 Richiesta dell'informazione clinica di un paziente

2. - Visualizzazione elenco (indici) documenti clinici: l’elenco degli (indici dei) documenti clinici viene visualizzato dall’operatore sanitario (visualizeList). 3. e 4. – Selezione e richiesta dettagli documento clinico: l’utente seleziona (selectDocument) e richiede (requestDocument) all’AccessGateway i dettagli relativi ad uno specifico evento clinico. 4.1 – Ricezione documento clinico: l’utente riceve il documento (retrieveDocument) e lo può visualizzare


8.3 L’Event Broker L'InfoBroker (IBIS) è anche in grado di fornire informazioni tramite un meccanismo basato sugli eventi chiamato “Publish and Subscribe”: EventBroker (EB) è il sottosistema di IBIS che implementa questa caratteristica. Tramite l'EB un utente può essere informato dall'IBIS quando un evento è avvenuto e prelevare poi i dati nella modalità sincrona classica; gli eventi consistono generalmente di nuove informazioni pubblicate o della loro modifica. L'utente che attende un evento clinico, come la disponibilità di alcuni esiti, non ha la necessità di fare un'interrogazione regolare (polling), deve solamente informare l'EB del suo interesse nei confronti di un certo tipo di evento associato ad un assistito ed attendere; sarà contattato nel momento in cui l'evento avverrà. La gestione degli eventi è complessa ed articolata poiché deve tenere anche conto che l'asincronia delle comunicazioni coinvolge un intervallo di tempo non breve nel quale vi possono essere delle condizioni che non rendono consegnabile l'evento: la linea potrebbe non essere disponibile, l'utente potrebbe non essere temporaneamente on-line oppure l'evento stesso potrebbe non verificarsi mai. L'EventBroker amplifica di molto le potenzialità del sistema dal punto di vista funzionale; può, ad esempio, essere usato per informare le Pubbliche Amministrazioni, oltre che medici di base, di eventi quali nascita e morte direttamente dagli Enti Ospedalieri senza un eccessivo carico di lavoro per le controparti.

8.4 Sicurezza e privacy La sicurezza, in questo contesto, è principalmente orientata a garantire la privacy dei dati. I dati sanitari sono oltremodo sensibili e devono poter essere consultati solo dalle figure professionali mediche autorizzate e solo nel contesto medico specifico (medico di base, pronto soccorso...), il sistema, inoltre, deve offrire un'elevata garanzia di essere impermeabile a tentativi di intrusione. In questo ambito andrà definito un apposito profilo di sicurezza IBSE che guidi l’implementazione e la rispondenza agli standard rispetto ai livelli compatibili con la Sanità Elettronica. In particolare, rispetto alle regole della riservatezza per la messaggistica le specifiche SPCoop, che IBSE supporterà completamente, prevedono una classificazione dei dati su 5 livelli. In particolare va considerato che i dati clinici andranno probabilmente classificati a livello R5 (dati riservati), mentre i dati non clinici andranno probabilmente classificati generalmente a livello R4 (dati sensibili), deve quindi essere implementata la riservatezza a livello di messaggio tramite W3C XML-Encryptions, come previsto in SPCoop. Al fine di offrire meno punti di criticità l'IBSE, diversamente da altre iniziative dello stesso tipo, non replica i dati sanitari in un database centrale e neppure li fa transitare attraverso un unico sistema di smistamento. I dati sanitari restano nel sistema esterno che li ha prodotti; è responsabilità delle Porte di Dominio garantire un adeguato meccanismo di controllo degli accessi in accordo con gli standard specificati dall'SPCoop. Le informazioni che fluiscono sia dalla Porta all'AccessGateway che da quest'ultimo al cliente web sono sempre crittografate, firmate e tracciate.


Fermo restando il rispetto della classica architettura orientata ai servizi ed ai relativi meccanismi di sicurezza come descritti nel SPCoop, l'IBSE deve principalmente garantire in aggiunta i necessari meccanismi di sicurezza per l'InfoBroker (IBIS) che agisce come un mediatore distribuito tra produttore e consumatore di servizi SPCoop. L'IBIS, essendo un registro, contiene degli indici ed alcune informazioni secondarie sull’assistito, ma comunque sensibili, queste sono comunque trattate con gli stessi meccanismi di sicurezza adottati per le porte di dominio. L'IBIS implementa un meccanismo di replicazione dei dati tra i nodi in modo tale che in caso di malfunzionamenti di rete o di hardware all'interno della rete IBIS stessa, la ridondanza prodotta garantisce di avere una quasi completa resistenza ai guasti. L'IBSE mantiene un registro di eventi e può fornire un middleware per l'interoperabilità, non è responsabile della memorizzazione delle informazioni sanitarie, le quali restano nei sistemi che li hanno generati e che sono gli unici a dover garantire adeguati sistemi di backup e di protezione da accessi indesiderati. Dovranno quindi essere definiti il livello delle politiche di sicurezza ed affidabilità comuni in ambito sanitario che dovranno stabilire le caratteristiche dei sistemi che possano entrare a far parte della rete IBSE. E’, infatti, evidente che un sistema regionale complesso, per poter interoperare con altri sistemi regionali, deve poter riconoscere una politica comune e accreditare i sistemi con cui dialoga secondo una metodologia condivisa. Le politiche di sicurezza minime andranno quindi concordate non solo a livello di cooperazione applicativa (SPCoop) ma anche a livello dei sistemi locali. Data la natura del Fascicolo potrebbe altrimenti accadere che si acceda da un certo sistema locale alle informazioni riservate senza rispettare criteri minimi comuni. La gestione della sicurezza deve basarsi essenzialmente sull’accertamento dell’identità e sulla definizione del ruolo dell’utente rispetto al servizio secondo un paradigma RBAC. L’accesso al sistema degli Operatori dovrà essere realizzato attraverso autenticazione forte con l’utilizzo della Carta Nazionale dei Servizi con firma (Carta Operatore). L’accesso al sistema degli Assistiti dovrà essere realizzato sempre attraverso autenticazione forte con l’utilizzo della Carta Nazionale dei Servizi (CNS) o Carta di identità Elettronica (CIE). Potranno essere previsti, in una fase transitoria, forme di accesso con funzionalità degradate senza l’utilizzo di carte. Dato che la realizzazione dell’FSE richiede necessariamente l’adozione di un’architettura di federazione di sistemi e domini, è senz’altro auspicabile la scelta di soluzioni che, da un lato, preservino l’autonomia dei diversi attori nella definizione delle politiche di accesso (regioni, aziende sanitarie, dipartimenti, ecc.), e, dall’altro, deleghino ai soli domini istituzionalmente competenti la produzione delle attestazioni relative a identità e ruolo degli operatori. Poiché obiettivo del Fascicolo è consentire la condivisione delle informazioni in possesso di diverse organizzazioni, e poiché sono in genere le Aziende a poter certificare il ruolo degli operatori sanitari, si tratta 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. Coerentemente con questo scenario SPCoop prevede l’uso di SAML versione 2.0. I modelli funzionali sono invece di pubblico dominio e non sono sottoposti agli stessi stringenti requisiti di sicurezza; è necessario solamente che le operazioni di scrittura siano autorizzate.


9. Architettura Funzionale L'architettura funzionale descrive qual è il modello funzionale implementato dal sistema IBSE: questo comprende principalmente la definizione dei servizi, dei dati, dei processi e degli eventi. A fronte dei processi sanitari, della struttura della cartella clinica, delle necessità di interoperabilità tra gli attori del sistema (Regioni, ASL, AO, etc.) si stabilirà in fase di analisi funzionale specifica quali eventi l'IBIS deve supportare e quale sarà la struttura dei servizi. L'IBIS sarà realizzato in modo da supportare qualunque ragionevole modello funzionale sarà disegnato, la sua implementazione è trasparente alle funzionalità che supporterà. Di seguito nella figura 10, viene mostrata con maggiore dettaglio quella che potrebbe essere l’intera architettura funzionale del Fascicolo Sanitario Elettronico.

Figura 10 : Architettura Funzionale FSE

Activity Diagram UML dei

processi principali (facoltativo)

IBIS l’indice del FSE è

sviluppato a livello

regionale

Design delle

specifiche documenti

HL7-CDA Rel.2

(Patient summary)


La realizzazione del Fascicolo Sanitario Elettronico è un’attività evidentemente complessa, pertanto si ritiene che sia preferibile introdurre i componenti che ne compongono l’architettura in momenti differenti, garantendo modularità e scalabilità in ottica di evoluzioni successive. Ad esempio, come già sperimentato in altre realtà come quella della Regione Toscana, la prima fase potrebbe caratterizzarsi per l’introduzione del FSE a livello regionale; le fasi successive potranno poi immergerlo in un contesto a livello nazionale ed europeo. A conferma della correttezza di questo approccio, si segnala che l’integrazione a livello nazionale delle sottoreti afferenti a ciascun IBIS regionale non è ancora possibile, in quanto non è ancora stata implementata una rete di tipo peer to peer che costituisca il network per la condivisione delle informazioni provenienti dai domini regionali. Tale elemento deve essere evidentemente sviluppato orchestrando le specificità delle singole regioni, nel contesto nazionale. Il componente Health Enterprise Architecture dovrebbe permettere tramite l’elemento Collaborative Process, di realizzare dei metamodelli che mappino i processi caratteristici del FSE e quindi della Sanità Elettronica (ad esempio la refertazione specialistica). Il componente Semantic / Syntactic Interoperability definisce il design dei documenti sanitari pubblicati nel FSE. Ambedue i componenti dovrebbero essere progettati secondo i dettami del paradigma MDA (Model Driven Architecture). Il concetto centrale di MDA è quello di modello, definito dal paradigma come una descrizione o specifica di un sistema e del suo ambiente fatta per un determinato scopo. La modellazione è l’attività centrale durante il processo di sviluppo del software. La principale differenza rispetto al classico processo di sviluppo software risiede nel fatto che i diversi artefatti non sono cartacei (raccolta requisiti, analisi funzionale, modello dei dati, architettura del software..) ma piuttosto modelli formali, ossia modelli comprensibili anche da strumenti automatici. I modelli principali su cui è basato l’approccio MDA sono:

• Computation Indipendent Model (CIM) che a partire dalle specifiche e dai requisiti del sistema da realizzare, modella tale sistema in termini di funzionalità, rimandando ai modelli successivi gli aspetti strutturali ( ad esempio le componenti del sistema) ed implementativi Il CIM descrive il modello di business del sistema

• Platform Indipendent Model (PIM) che , a partire dal CIM modella il sistema da realizzare

in termini di componenti ed interfacce , rimandando ai modelli successivi per gli aspetti implementativi. In altre parole rappresenta l’architettura di dettaglio del sistema astraendolo dalla piattaforma su cui il sistema sarà effettivamente deployato.

• Platform Specific Model (PSM) che a partire dal PIM modella il sistema da realizzare in

termini di dettagli implementativi. A partire dal PSM è possibile generare il codice in maniera semiautomatica: appositi tool infatti generano in modo automatico la struttura del codice ed indicano esplicitamente le parti lasciate al programmatore. Queste ultime riguardano essenzialmente gli aspetti di dettaglio non presenti nei modelli PIM o PSM


Dunque al fine di progettare un sistema per più piattaforme, è necessario generare un solo CIM, un solo PIM e un PSM per ogni piattaforma (Java, .NET, etc etc). Il passaggio tra una tipologia ed un’altra può avvenire per trasformazione semiautomatica di modelli. La sezione Collaborative Process dovrebbe essere implementata utilizzando il modello CIM. E’ possibile definire più diagrammi associati al CIM sulla base dei processi sanitari che costituiscono i casi d’uso del FSE. Ad esempio il caso d’uso di un assistito che si reca dal proprio medico per un prescrizione può essere modellato come nella figura 11 facendo uso di un diagramma delle attività UML1. Nella prima fase dello sviluppo del Fascicolo Sanitario Elettronico il componente Collaborative Process potrà essere considerato facoltativo, pensando di schematizzare i processi della sanità elettronica con gli UML Activity Diagram in un secondo momento.

1 UML è un linguaggio di modellazione e specifica del software. Si rimanda a testi specialistici un approfondimento sull’argomento (Maciaszek Sviluppo di sistemi informativi con UML – Addison-Wesley)


Figura 11 Esempio di Computation Indipendent Model (Diagramma delle attività UML) Da quanto sopra descritto risulta che i vantaggi dell’approccio MDA sono molteplici:

• Maggior aderenza alle specifiche utilizzate; • Sviluppo semi-automatico del codice a partire dai modelli; • Sviluppo di un unico modello per più piattaforme • Migliore manutenibilità e gestione evolutiva del codice basata sui modelli


Si noti inoltre che il linguaggio di modellazione utilizzato è UML (Unified Modeling Language), sebbene l’approccio MDA non sia necessariamente legato ad esso e sia possibile utilizzare altri linguaggi di modellazione. Per quanto concerne il componente di Interoperabilità, i documenti sanitari pubblicati nel FSE possono essere di varie tipologie:

• prescrizioni (di farmaceutica o specialistiche) • referti ( di specialistica, laboratorio analisi, radiologia ) • lettere di dimissioni • verbali di pronto soccorso

Essi sono rappresentati nel formato HL7v3/CDA2, uno standard internazionale basato su XML, appositamente creato per la modellazione e la condivisione dei documenti sanitari. Inoltre ciascun documento sanitario elettronico è firmato digitalmente, affinché sia equivalente all’analogo documento cartaceo sottoscritto con firma autografa, secondo quanto prescritto dal Codice dell’Amministrazione Digitale. I documenti sanitari pubblicati sul FSE sono caratterizzati da un insieme di informazioni (metadati), che abilitano la ricerca del documento stesso:

• metadati relativi all’autore del documento: identificativo, ruolo applicativo (medico di base, specialista, ecc) , struttura sanitaria di appartenenza

• metadati relativi al paziente cui il documento si riferisce: identificativo • metadati relativi al documento: tipo di documento, data di pubblicazione, riferimento (link)

al repository in cui il documento è memorizzato, ecc.


Figura 12 Architettura di riferimento per il Fascicolo Sanitario Elettronico

La figura 12 rappresenta ad alto livello l’architettura del Fascicolo Sanitario Elettronico che è di tipo SOA, basata su Web Service. Tale infrastruttura è conforme alle regole tecniche del Sistema Pubblico di Connettività e Cooperazione (CNIPA SPCoop) che abbiamo avuto già modo di approfondire. Il FSE è costituito dalle seguenti componenti principali:

• Repository: contiene i documenti sanitari firmati digitalmente, nel rispetto di quanto prescritto dal Codice in materia di Protezione dei Dati Personali (D.Lgs 196/2003). E’ distribuito a livello di ASL/AO, in quanto ciascuna struttura sanitaria memorizza e gestisce i documenti che ha prodotto. Si noti, pertanto, che le strutture sanitarie condividono con l’infrastruttura del fascicolo parte delle loro risorse di memorizzazione. Ovviamente prerequisito necessario per l’utilizzo del FSE è che le strutture sanitarie siano in grado di produrre documenti sanitari in formato elettronico, firmati digitalmente.

• Registry: è l’indice dei documenti sanitari e contiene i metadati caratterizzanti ciascun

documento memorizzato in un repository, tra cui i riferimenti necessari per il suo recupero (dal repository che lo contiene). Il Registry può essere centralizzato a livello regionale o distribuito a livello di ASL/AO. Le specifiche del DIT (Dipartimento di Innovazione Tecnologica) prevedono che il Registry, denominato Info Broker Individuale Sanitario (IBIS), sia realizzato con lo standard ebXML v3 (in quanto abilita nativamente la federazione dei Registry), e con un modello di metadati basato sui datatype di HL7v3.

Access Gateway

Client

Service

FSE

Services

Document

Management

Services

Document

Manager

Repository

Services

Registry

Services

Repository

Wrapper

Registry

Wrapper

Repository

Interface

Registry

Interface

Repository

Registry

Security

Services

Security


• Access Gateway (AG): realizza le funzionalità di comunicazione tra le applicazioni client del FSE e Registry e Repository, nonché tra Registry e Repository stessi. Può essere implementato a livello regionale o a livello di ASL/AO. L’AG è costituito dalle seguenti sotto-componenti:

o Client Service: raggruppa i servizi di interfacciamento del FSE con i client esterni,

rappresentati in Figura 13 mediante l’interfaccia FSE Services. Tale interfaccia nasconde ai client esterni tutta la complessità del sistema.

o Document Manager: raggruppa i servizi di gestione (ricerca/recupero) dei documenti da/verso Registry/Repository, offrendo al modulo Client Service i servizi rappresentati in Figura 13 mediante l’interfaccia Document Management Services

ed invocando i servizi messi a disposizione dai moduli Registry Wrapper e Repository Wrapper.

o Registry Wrapper: raggruppa i servizi di interfacciamento con il Registry, per il recupero e la memorizzazione dei metadati di un documento sanitario, rappresentati in Figura 13 mediante l’interfaccia Registry Services.

o Repository Wrapper: raggruppa i servizi di interfacciamento con il Repository, per il recupero e la memorizzazione di un documento sanitario, rappresentati in Figura 13 mediante l’interfaccia Repository Services.

• Security: realizza l’infrastruttura di sicurezza offrendo, mediante l’interfaccia Security

Services funzionalità per l’identificazione, l’autenticazione e l’autorizzazione dell’utente, nonché per le garanzie di integrità, non ripudio e confidenzialità nello scambio dei documenti, e per il tracciamento degli accessi, il tutto nel rispetto dei requisiti previsti dalla normativa italiana ed europea in tema di privacy e sicurezza. I servizi esposti da questa componente sono invocati (automaticamente) dall’AG quando l’utente invoca un servizio esposto dalla componente Cient Service. Se le verifiche di sicurezza si concludono positivamente, si procede con l’esecuzione del servizio richiesto dall’utente, altrimenti si restituisce all’utente un messaggio di errore.


Figura 13: Specifica delle interfacce, dei metodi e del Data Model

La Figura 13 illustra mediante le classi, le interfacce esposte dalle componenti del FSE e i loro metodi. Ciascun metodo è descritto dalla sintassi: <nome>(<tipo dato input>;<tipo dato output> ). Ciascun tipo di dato è definito mediante una classe del Data Model. Si notino, nel Data Model, le relazioni tra le classi associate ai tipi di dato, e le variabili di istanza associate a ciascuna classe (non sono definite operazioni per le classi del Data Model).

Access Gateway Repository Interfaces

Data Model

+LoadDoc(Document,Result)

+queryDoc(DocumentMeta,Document)

iRepository

+securityServices(UserIdData,securityAssertion)

SecurityServices

+LoadRepository(Document,Result)

+RetrieveforRep(DocumentMeta,Document)

Repository Services

+LoadDocument(Document,Result)

+getDocument(DocumentMeta,Document)

+searchDocument(DocAttr,Document)

FSE Services

+Load(Document,Result)

+retrieve(DocumentMeta,Document)

+query(DocAttr,Document)

DocumentMgmt Services

+LoadinReg(DocumentMeta,Result)

+queryReg(DocAttr,DocumentMeta)

Registry Services

Registry Interfaces

+LoadMeta(DocumentMeta,Result)

+queryMeta(DocAttr,DocumentMeta)

iRegistry

-DocumentData : base64Binary

-uniqueId : string

Document

-DocumentMeta : String

DocumentMeta

-Name : String

-Author : String

-Patient : String

-Date : Date

-Type : String

DocAttr

-Result : Enum

Result

Base64Binary

<<datatype>>


:Client Application :Client Service :Document Manager :Registry Wrapper :Registry

1: SearchDocument()

2: query()

3: queryReg()

4: queyMeta()

Figura 14: Funzionalità di ricerca di un documento sanitario

In figura 14 un utente autorizzato che vuole recuperare i metadati di un documento, invoca il metodo SearchDocument() dell’interfaccia FSE Services della componente architetturale Client

Service, fornendo in ingresso i criteri di ricerca [DocAttr]; i criteri di ricerca sono propagati alle varie componenti invocando i vari metodi di query fino ad eseguire la query sulla componente Registry. Una volta eseguita, il risultato ottenuto, e cioè la lista dei metadati che corrispondono alla query, viene propagato indietro alle componenti, fino ad essere visualizzato opportunamente dall’utente FSE.


Figura 15: Funzionalità di pubblicazione di un documento sanitario

In figura 15 relativamente al processo di pubblicazione di un documento si notino le operazioni interne svolte dalla componente Document Manager: esse sono necessarie, ad esempio, per l’estrazione dei metadati di un documento e per verificare che il documento sia stato formattato correttamente, rispettando la sintassi HL7v3/CDA2, prima che esso sia pubblicato. Di seguito viene mostrato a titolo di esempio come integrare il FSE all’interno di un sistema costituito da differenti sistemi informativi sanitari. Il sistema per la gestione del FSE (figura 16) abiliterà e favorirà un’effettiva comunicazione e condivisione delle informazioni in condizioni paritetiche tra gli operatori socio sanitari della Regione che contribuiscono, a vario titolo, all’erogazione di servizi di assistenza territoriale attraverso l’integrazione telematica di tutte le strutture sanitarie e l’interconnessione degli operatori.


Figura 16 Esempio di un sistema per la gestione del FSE L’architettura riutilizzerà il pattern dei sistemi business basati sui servizi adattandolo agli aspetti specifici della sanità elettronica, in particolare ai processi di creazione, gestione e utilizzo dei fascicoli sanitari dei cittadini. La stessa architettura potrà essere utilizzata per implementare applicazioni verticali come i vari libretti sanitari dei pazienti o il Patient Summary. Si osservi come finora ci siamo concentrati sui dati relativi all’ambito sanitario. L’architettura esposta può essere riutilizzata senza alcun intervento per la gestione di informazioni necessarie alla creazione della Cartella Sociale informatizzata, evolvendosi da FSE a FSSE. Per la gestione dei dati sociali il sistema dovrà recuperare le informazioni da sistemi informativi preesistenti e dedicati alle varie specificità dell’ambito sociale. Ad esempio per la regione Valle D’Aosta le applicazioni sono le seguenti:

• ADE (Assistenza Domiciliare Educativa) • ITACA ( Sistema per la gestione degli interventi sugli anziani) • HALPI (Sistema per la gestione dell’inserimento lavorativo per persone portatrici di

handicap) • ARDI (Sistema per la gestione dell’invalidità civile) • SANI (Sistema per la gestione delle pensioni di invalidità) • CARTELLA SOCIALE (Sistema di gestione delle assistenti sociali)

Rettangolo


• TATE (Sistema per la gestione delle attività delle tate familiari) Gli applicativi nel contesto proposto non subirebbero alcun tipo di impatto. Le attività di implementazione si concentrerebbero sui componenti di integrazione (Access Gateway per gestione documentale di documenti “sociali” e web service custom per recupero ed aggiornamento dati) per i diversi applicativi.

10. Conclusioni L’introduzione del FSE è un’attività che richiede una pianificazione di lungo periodo. Per prima cosa si ritiene che sia necessario implementare il FSE a livello regionale, in maniera tale da rispondere da subito alle esigenze di operatività da parte, ad esempio, dei MMG e per essere predisposti alla futura introduzione in un’architettura federata a livello nazionale come quella descritta nel presente documento. Le attività indispensabili per l’implementazione del FSE in ambito regionale e per il suo utilizzo sono riassunti nella WBS a tre livelli successiva. Task 1° livello Task 2° livello Task 3° livello

Rete SPCOOP Porta Di Dominio SPCoop Creazione PDD ad hoc e sua configurazione

InfoBroker Individuale

Sanitario (IBIS) Regionale Componente Access Gateway

Comunicazione eventi Access Gateway - Event

Broker

Servizi di interfacciamento del FSE con i client

esterni

servizi di gestione (ricerca/recupero) dei

metadati da/verso Registry

servizi di gestione (ricerca/recupero) dei

documenti da/verso Repository

Componente Registry

Definizione e implementazione del Registry

(indice dei documenti)

Servizi di caricamento dei metadati

Data Model

Componente Event Broker Funzionalità di Publish & Describe

Componente Repository

Documentale

Definizione e implementazione del Repository

(contenente i documenti)

Servizi di caricamento dei documenti

Data Model

Componente Security Servizi di sicurezza

Interoperabilità sintattica e

semantica

Definizione documenti clinici

con standard HL7v3/CDA2

Software di gestione FSE e

cartelle cliniche virtuali

Visualizzazione documenti

clinici

Richiesta documenti (Singola

o multipla)


Ricezione notifiche eventi di

inserimento e aggiornamento

documenti

La WBS da luogo alla seguente pianificazione di massima. La durata delle attività è puramente indicativa e su di essa non è stata effettuata alcuna attività di stima dell’effort.

LA GIUNTA REGIONALE - ausl.vda.it · entro il 2012 del Fascicolo Sanitario Elettronico al fine...

Documents

Transcript of LA GIUNTA REGIONALE - ausl.vda.it · entro il 2012 del Fascicolo Sanitario Elettronico al fine...