Potenzialità dell'approccio Multi- Agente nell'ambito dei Sistemi Informativi Sanitari

Transcript

1 Potenzialità dell'approccio Multi- Agente nell'ambito dei Sistemi Informativi Sanitari Luca Palazzo, Matteo Rossi, Gianluca Dolcini, Andrea Claudi, Paolo Sernani, Gianluigi Biancucci, Aldo Franco Dragoni Dipartimento di Ingegneria dell'informazione (DII) Università Politecnica delle Marche Via Brecce Bianche, Ancona Italy {l.palazzo, g.dolcini, a.claudi, p.sernani, g.biancucci, Abstract Il campo dell'assistenza sanitaria è ampio e caratterizzato dall'eterogeneità dei sistemi adottati e dei dati utilizzati. Per ottenere elevati standard di qualità ed efficienza, è fortemente richiesta l'interoperabilità fra diversi sistemi informativi. In questo paper viene proposta un architettura ad agenti per affrontare tali tematiche, seguendo le linee guida dell'unione Europea e i requisiti del Ministero della Salute. Per validare il nostro sistema e mostrarne le potenzialità, abbiamo sviluppato su tale architettura un tipico scenario di emergenza, dove il personale di pronto soccorso deve accedere, tramite periferiche mobile, al Profilo Sanitario Sintetico (PSS) di un cittadino, contenuto nel Fascicolo Sanitario Elettronico (FSE). Keywords: Sistema Informativo Sanitario; Interoperabilità; Sistemi Multi-Agente; Profilo Sanitario Sintetico; Fascicolo Sanitario Elettronico. 1. Introduzione Il campo dell'assistenza sanitaria sta fronteggiando un numero sempre crescente di sfide: l'incidenza dell'errore medico sta salendo, molte strutture sanitarie, pur servendo vaste aree in crescita, sono a corto di personale, i costi della sanità aumentano sempre più. Inoltre il budget a disposizione si sta restringendo in molti paesi e le strutture si trovano sotto pressione per fornire servizi migliori con meno risorse [1]. I Sistemi Informativi Sanitari (SIS) sono al centro di tutte queste sfide: possono fornire un miglior coordinamento tra il personale medico e tra le varie strutture riducendo quindi il numero e

2 l'incidenza degli errori; allo stesso tempo possono diminuire i costi della sanità e possono costituire un mezzo per migliorare la gestione degli ospedali, contribuendo ad ottenere il corretto iter delle prestazioni fornite dal sistema sanitario. Sfortunatamente, a causa della complessità del loro dominio di applicazione, i SIS sono frammentati in vari sistemi che difficilmente sfruttano standard di comunicazione, protocolli di definizione dei processi e una rappresentazione omogenea dei dati. Gran parte della ricerca in questo campo è rivolta a questi problemi e diverse soluzioni sono state proposte negli ultimi anni Stato dell'arte In anni recenti, per quanto riguarda i SIS, la ricerca si è focalizzata su due tecnologie: il cloud computing e i sistemi multi-agente (MAS). In [3] viene proposto un sistema mobile che permette la memorizzazione, l'aggiornamento e l'accesso a dati elettronici relativi all'assistenza sanitaria utilizzando il cloud computing. In [4] viene utilizzata una rete di sensori wireless per automatizzare il processo di raccolta dei dati. Le informazioni sono distribuite al personale medico grazie a tecnologie cloud. Koufi et al. [5] propongono un approccio alternativo, dove l'interoperabilità di dati e servizi è ottenuta mediante un sistema multi-agente. Infine in [6] e [7] si utilizzano i sistemi multi-agente per la cura e il monitoraggio a distanza dei pazienti Il nostro contributo In questo lavoro presentiamo un'architettura ad agenti che permetta l'accesso a dati geograficamente distribuiti per consentire al personale medico di recuperare e/o aggiornare ogni documento di un paziente in modo efficiente ed affidabile. Tale architettura risponde ai requisiti di interoperabilità tra differenti strutture sanitarie e, allo stesso tempo, si integra con sistemi legacy (inclusi i database locali), costituendo un nuovo layer software in cima a quelli esistenti: ciò permette di proteggere gli investimenti da parte delle istituzioni e delle strutture, come richiesto dalla direttive ministeriali [8], oltre ad affrontare i problemi di interoperabilità. I principali vantaggi di tale architettura sono: Distribuzione. Un concetto chiave della tecnologia ad agenti è la flessibilità: i problemi di interoperabilità e integrazione con i sistemi esistenti sono demandati ai task assegnati ai singoli agenti: la cooperazione costituisce la soluzione a queste problematiche. Il recupero dei dati è possibile da ogni punto del territorio, grazie semplicemente alla comunicazione tra agenti distribuiti, non richiedendo complesse infrastrutture (tipiche delle soluzioni basate sul cloud). Elevata Modularità. Grazie all'attività di standardizzazione compiuta dalla comunità di riferimento dei MAS FIPA IEEE le capacità del sistema possono essere estese semplicemente aggiungendo nuovi agenti (registrando i loro servizi ed utilizzando la stessa ontologia) all'architettura. Robustezza. Un'infrastruttura orientata agli agenti fornisce numerose tecniche di recovery per ottenere una migliore tolleranza ai guasti.

3 Integrazione con i sistemi esistenti. Con l'aiuto di agenti contenitore, ognuno dei quali progettato per una particolare istanza dei sistemi legacy, l'architettura costituisce un layer software più alto, che gestisce l'interoperabilità. La comunicazione a questo livello può facilmente utilizzare ontologie standard per lo scambio di messaggi (HL7), per la definizione di documenti clinici (HL7 CDA), scheduled workflows (IHE) e terminologie dell'assistenza sanitaria (come LOINC e SNOMED CT) Struttura del paper Il resto del paper è strutturato come segue: la sezione 2 descrive nel dettaglio l'architettura del sistema multi-agente; la sezione 3 illustra l'implementazione di uno scenario di risposta all'emergenza; infine nella sezione 4 sono discussi i risultati di questo lavoro. 2. Infrastruttura L'architettura ad agenti è formata a partire da tre livelli di astrazione chiamati local platform, district platform e client platform (fig. 1 e 2): ognuno è costituito dai suoi specifici agenti e risorse come descritto nelle prossime sottosezioni. Il fattore discriminante tra i primi due livelli è di natura amministrativa: c'è una local platform per ogni struttura sanitaria nel territorio (ad esempio un ospedale); le strutture sono raggruppate in distretti amministrativi, che costituiscono il secondo livello. Infine il livello client è rappresentato da qualunque agente software capace di collegarsi all'infrastruttura per accedere ai documenti o inserire e/o aggiornare il fascicolo sanitario di un paziente. Fig. 1. L'architettura globale è strutturata in tre livelli.

4 Fig. 2. Relazione tra le local platform e le loro district platform di riferimento Local Platform C'è una local platform (fig. 3) per ogni struttura sanitaria. Il suo ruolo è quello di interfacciarsi con ogni sistema informativo attualmente presente nella struttura e destinato alla gestione (creazione, modifica, ricerca e accesso) dei documenti clinici e dei differenti dipartimenti all'interno della clinica. LocalDBWrapper Il compito degli agenti LocalDBWrapper è di interfacciarsi con i database delle istituzioni sanitarie locali. I vantaggi dell'utilizzo di agenti contenitore sono i seguenti: tutti i sistemi legacy non sono modificati o rimpiazzati, ma di fatto incapsulati dentro tali agenti. In questo modo, ogni agente esterno che necessita di accedere ai dati contenuti nel database locale, sarà in grado di ottenerli semplicemente

5 comunicando con l'agente LocalDBWrapper di riferimento, evitando l'interazione diretta con i sistemi legacy. Si può astrarre l'effettiva rappresentazione dei dati nei differenti sistemi informativi delle varie strutture sanitarie. Con questa soluzione non c'è bisogno di affrontare problemi come informazioni in conflitto (omonimia e sinonimia) o inconsistenze mediante pesanti tecniche di ridenominazione, ristrutturazione o reingegnerizzazione; è sufficiente progettare un agente contenitore per ogni differente sistema legacy, capace di tradurre la rappresentazione interna dei dati nell'ontologia comune condivisa da tutti gli agenti nell'infrastruttura. Per aggiungere una local platform all'intera infrastruttura gli agenti LocalDBWrapper devono registrarsi all'agente DF_Intra-District della loro district platform di riferimento: ciò li rende disponibili per agenti distribuiti e remoti che necessitano di accedere ai dati contenuti nella struttura locale. Fig. 3. Agenti delle local platform. DocumentHandler Gli agenti di questo tipo sono in grado di accedere al contenuto di uno specifico documento prodotto dalla struttura come report clinici, test di laboratorio, prescrizioni, ecc. In generale un DocumentHandler viene contattato da un agente client per ottenere i record che gestice: l'agente DocumentHandler individua il documento richiesto attraverso il suo identificatore univoco, lo ottiene dal repository clinico e traduce l'informazione in un messaggio da inviare all'agente client che otterrà così i dati clinici desiderati. Service Agents Si tratta di agenti per la gestione di dipartimenti diversi all'interno della struttura sanitaria (ad esempio radiologia, cardiologia, laboratorio analisi, ecc.). In questo lavoro non vengono fornite ulteriori informazioni riguardanti tale aspetto. Maggiori dettagli riguardo un implementazione ad agenti dello scheduled workflow per gli esami

6 radiologici proposto dal consorzio Integrate the Healthcare Enterprise (IHE) possono essere trovati in [9] District platform Il compito principale della district platform (fig. 4) è quello di incapsulare tutte le local platform che amministrativamente ne fanno parte. Le district platform permettono di raggiungere l'obiettivo di interoperabilità del nostro sistema distribuito: è necessario che ognuna conosca l'indirizzo delle altre. Fig. 4. Agenti della district platform. DistrictDBWrapper Questi agenti hanno funzioni simili ai LocalDBWrapper visti in precedenza: gestiscono i dati dei database distrettuali. L'agente Gateway li contatta per memorizzare o accedere a qualsiasi riferimento al fascicolo sanitario di un paziente che può essere prodotto da qualsiasi struttura locale del distretto.

7 DocumentHandler Gli agenti DocumentHandler gestiscono quei documenti la cui competenza amministrativa ricade sul distretto, come il Fascicolo Sanitario Elettronico (FSE) e il Profilo Sanitario Sintetico (PSS) [10]. Tali documenti possono riferirsi a record distribuiti su diverse local platform: l'agente Gateway deve cercare e recuperare queste informazioni. Gateway L'agente Gateway raccoglie le richieste dal client e invia le query ai LocalDBWrapper e ai DistrictDBWrapper, per ottenere i dati relativi al fascicolo di un cittadino. Una volta ottenute queste informazioni fornisce al client l'indirizzo degli agenti DocumentHandler da contattare per ottenere i documenti desiderati. Per assolvere questi compiti l'agente Gateway svolge principalmente due attività: quando recupera dati distribuiti per soddisfare la richiesta del client deve integrarli in una struttura dati, cosicchè il client possa gestire un singolo dataset. Quando in un distretto viene prodotto un documento relativo ad un paziente afferente ad un altro distretto, il gateway del primo deve informare quello del secondo di registrare al proprio DistrictDBWrapper tale evento sul database distrettuale. Init Durante l'inizializzazione della district platform l'agente Init registra il Gateway su tutti gli agenti DF_Inter-District delle district platform del territorio. DF_Inter-District Come appena illustrato, si tratta del Directory Facilitator (DF) presso il quale sono registrati tutti i Gateway remoti, permettendo a questi ultimi di comunicare tra loro. DF_Intra-District Tale DF contiene i riferimenti a tutti gli agenti LocalDBWrapper dello stesso distretto. LoginServer L'agente LoginServer deve stabilire una connessione sicura con il client che accede all'infrastruttura per ottenere dati da uno specifico distretto Client platform Tale piattaforma logica contiene le applicazioni client, vale a dire qualsiasi software ad agenti che sia capace, dopo una fase di login, di accedere alle informazioni attraverso la connessione con l'agente Gateway di un distretto. Alcuni esempi di applicazioni client potrebbero essere: software per accedere al FSE, sia per il personale medico che per i cittadini, applicazioni mobile per recuperare il PSS per situazioni di emergenza, software per permettere ai medici di base di aggiornare il FSE, ecc.

8 3. Scenario Fig. 5. Alcune istantanee dell'applicazione Android. Per mostrare le potenzialità dell'infrastruttura proposta ipotizziamo uno scenario dove un medico di pronto soccorso deve consultare rapidamente il FSE di un paziente, in particolare il suo PSS. Secondo la definizione dell'ue, il PSS è un documento clinico archiviato digitalmente in appositi repository dotati di sistemi di indicizzazione e protetti da sistemi di accesso sicuro. Il PSS è un documento che rispetta lo standard HL7 CDA, è contenuto nel FSE e riassume la storia clinica del paziente e la sua situazione corrente. In breve, i casi d'uso del PSS sono schematizzati dai seguenti punti [11]: situazioni d'emergenza nelle quali il paziente non è in grado di dare una descrizione esaustiva della propria storia clinica (ad esempio allergie, medicinali assunti nell'ultimo periodo, ecc.). Flusso di informazioni tra il medico di famiglia e le strutture sanitarie. Pazienti affetti da malattie croniche curati da diversi specialisti o anziani in regime di cura a domicilio Supporto alla diagnosi, telemedicina, ecc. Inoltre il PSS contiene sia campi obbligatori che facoltativi ed è espresso tramite il linguaggio di markup XML. Per costruire lo scenario sono stati usati: il framework JADE [12] per implementare gli agenti locali e distrettuali in alcuni computer desktop. Un applicazione Android (fig. 5) per simulare l'agente client, sviluppata con

9 l'addon Jade Leap. Le direttive del Ministero della Salute per costruire un PSS per l'esperimento, un parser XML e un ontologia per gli agenti basata su HL7. L'esecuzione è molto semplice (fig. 6). Per prima cosa l'applicazione client effettua il login nella district platform, inserendo username e password: viene stabilita una connessione sicura con la district platform usando il protocollo TSL, in modo da garantire un accesso sicuro ai dati personali e sensibili dei pazienti. Successivamente il client richiede il PSS di un cittadino inserendo il suo codice fiscale: l'agente Gateway interroga le varie entità distribuite per cercare l'ubicazione dei dati richiesti e informarne il client. Infine l'applicazione client richiede le informazioni agli agenti DocumentHandler della piattaforma di competenza. Fig. 6. L'agente client interroga l'infrastruttura per ottenere il fascicolo di un paziente. 4. Conclusioni Nei sistemi informativi sanitari, l'importanza dell'interoperabilità tra i sistemi esistenti è ampiamente riconosciuta. Un punto cruciale è permettere al personale medico di ottenere ogni informazione di cui necessita riguardo ad un paziente in una maniera affidabile ed esaustiva, anche se tali informazioni sono contenute in sistemi informativi differenti tecnicamente e distribuiti su diverse strutture.

10 Per rispondere a tali requisiti abbiamo proposto in questo paper un'architettura basata sulla tecnologia dei sistemi multi-agente che tragga vantaggio dall'adozione di standard per la gestione di documenti clinici. Il nostro obiettivo era mostrare come le caratteristiche tipiche dei MAS possano migliorare i Sistemi Informativi Sanitari in termini di interoperabilità, affidabilità, modularità e robustezza e come il personale medico (e, di conseguenza, i cittadini) possa beneficiare di questo sistema distribuito ed efficiente. Riferimenti [1] U. Varshney, "Pervasive healthcare", Computer, vol. 36, pp , [2] R. Haux, Health information systems - past, present, future.", International journal of medical informatics, vol. 75 (3-4), pp , [3] C. Doukas, and T. Pliakas, and I. Maglogiannis, "Mobile healthcare information management utilizing Cloud Computing and Android OS", Engineering in Medicine and Biology Society (EMBC), 2010 Annual International Conference of the IEEE, pp , [4] C. Rolim, F. Koch, C. Westphall, J. Werner, A. Fracalossi, and G. Salvador, "A Cloud Computing Solution for Patient's Data Collection in Health Care Institutions", 2010 Second International Conference on ehealth, Telemedicine, and Social Medicine, pp , [5] V. Koufi, F. Malamateniou, Flora and G. Vassilacopoulos, "Building Interoperable Health Information Systems Using Agent and Workflow Technologies", Medical Informatics in a United and Healthy Europe, pp , [6] D. Capozzi, and G. Lanzola, "An Agent-Based Architecture for Home Care Monitoring and Education of Chronic Patients", 2010 Complexity in Engineering, vol.9, pp , [7] M. Lyell, and X. Liu, "Software agent application to support the patient-at-home", 2012 International Conference on Collaboration Technologies and Systems (CTS), , [8] P. Ferronato, S. Lotti, and D. Berardi, "Strategia architetturale per la Sanità Elettronica", Ministero della Salute, pp. 1-56, [9] L. Palazzo, A. Dragoni, A. Claudi, and G. Dolcini, "A Multi-Agent Approach for Health Information Systems Domain", Proc. of the 1st Workshop on Artificial Intelligence and NetMedicine (NetMed), pp [10] M. Ciampi, G. De Pietro, C. Esposito, M. Sicuranza, and P. Donzelli, "On federating Health Information Systems", International Conference in Green and Ubiquitous Technology}, pp , [11] "Specifiche tecniche per la creazione del "Profilo Sanitario Sintetico" secondo lo standard HL7-CDA Rel. 2, Tavolo Permanente per la Sanità Elettronica, Ministero della Salute, pp , [12] F. Bellifemine, G. Caire, and D. Greenwood, "Developing multi-agent systems with JADE", Wiley, 2007.