UNIVERSITÀ POLITECNICA DELLE MARCHE

Transcript

1 UNIVERSITÀ POLITECNICA DELLE MARCHE FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Elettronica Dipartimento di Elettronica, Intelligenza Artificiale e Telecomunicazioni UN ARCHITETTURA SOFTWARE COMPLETA PER TELECONSULTO E TELEREFERTAZIONE: PROGETTO ED IMPLEMENTAZIONE DEL REPOSITORY CENTRALE Tesi di Laurea di: Mirco Sturari Relatore: Prof. Aldo Franco Dragoni Correlatore: Prof. Paolo Puliti Anno Accademico

2 INDICE Introduzione... 1 Capitolo 1. Telemedicina Introduzione Applicazioni Vantaggi Problemi Stato dell Arte Progetti dell ASUR Marche zona Sistema di teleconsulto ospedale di Osimo con stazioni fisse e stazioni mobili Assistente Virtuale Delocalizzazione della Refertazione Diagnostica Capitolo 2. Specifiche progetto MiRo Finalità Architettura generale Repository Laboratorio Medico Soluzioni tecniche Comunicazione sicura e Mutuo Riconoscimento Messaggi SOAP Capitolo 3. Implementazione del progetto Repository Concetto di evento Struttura della base-dati Web Service Web Service Repository Web Service Laboratory I -

3 Capitolo 4. Tecnologie Software Java Platform Java lato server: le Servlet Service-Oriented Architecture Web Services Protocollo SOAP Application Server Apache Tomcat Comunicazione SSL Strumenti di Sviluppo Apache Axis Database Relazionale MySQL Conclusioni Appendice A. Codice sorgente A.1 Common Library A.2 Web Service Repository A.3 Web Service Laboratory Bibliografia II -

4 INTRODUZIONE Con il continuo sviluppo tecnologico, con la digitalizzazione e con la diffusione della banda larga è diventata forte la necessità di ristrutturare l intero sistema sanitario nazionale. Questi fattori hanno dato nuovi impulsi al settore della Telemedicina, nell ottica di una maggiore integrazione e una migliore efficienza dei servizi sanitari. Il progetto MiRo nasce dalla collaborazione tra ASUR zona 7 di Ancona e l Università Politecnica delle Marche, per rispondere proprio a queste necessità. Abbiamo iniziato il nostro lavoro, essendo ingegneri, da un analisi del concetto di telemedicina e da una panoramica della situazione attuale nel settore. Abbiamo quindi cominciato a progettare un architettura software flessibile che potesse fungere da substrato alla realizzazione di un qualsiasi servizio sanitario delocalizzato, prendendo a riferimento uno dei rami di maggior interesse, la teleradiologia. Dal progetto si è passati all implementazione, con la scelta delle tecnologie più idonee agli ambienti distribuiti ed eterogenei, i Web Service, e della piattaforma software più diffusa e portabile, Java. Una prima conferma della validità del progetto, la presentazione al convegno internazionale di telemedicina EMMIT

5 CAP. 1 - TELEMEDICINA CAPITOLO 1 TELEMEDICINA Introduzione al concetto di telemedicina, stato dell arte nella sanità italiana e approfondimento dei progetti dell ASUR Marche zona Introduzione 1.2 Applicazioni Vantaggi Problemi 1.3 Stato dell Arte 1.4 Progetti dell ASUR Sistema di teleconsulto ospedale di Osimo con stazioni fisse e stazioni mobili Assistente Virtuale Delocalizzazione della Refertazione Diagnostica - 2 -

6 CAP. 1 - TELEMEDICINA 1.1 INTRODUZIONE Una definizione della Telemedicina che ha riscosso un notevole successo è la seguente: la Telemedicina rappresenta l erogazione di servizi sanitari, laddove la distanza rappresenti un fattore critico da parte di professionisti nell assistenza sanitaria che utilizzino tecnologie dell informazione e della comunicazione per lo scambio di informazioni rilevanti, per la diagnosi, il trattamento e la prevenzione delle patologie e per l educazione continuativa degli operatori sanitari, nell interesse del miglioramento della salute e delle comunità assistite. La Telemedicina utilizza le tecnologie della telecomunicazione per erogare assistenza sanitaria specialistica, spesso a notevoli distanze, con la possibilità di contenere i costi delle prestazioni. Questo avviene in special modo quando l Assistenza Sanitaria è rivolta ad aree isolate o comunque dove non sia disponibile direttamente la prestazione specialistica del medico. La Telemedicina consente di conseguire notevoli benefici sia per erogatori di assistenza remota, sia naturalmente, per gli utenti dei servizi, siano essi pazienti o operatori sanitari

7 CAP. 1 - TELEMEDICINA Lo sviluppo e l applicazione della Telemedicina richiede significativi expertise nei settori delle telecomunicazioni, delle erogazioni dei servizi sanitari e dell information tecnology and comunications. L applicazione della Telemedicina ben si presta ad un opera di cooperazione fra i paesi dotati di maggiori tecnologie e quelli ancora in via di sviluppo. Fig. 1.1 Telemedicina come servizio sanitario delocalizzato - 4 -

8 CAP. 1 - TELEMEDICINA 1.2 APPLICAZIONI Il concetto di telemedicina non significa dunque soltanto medicina praticata a distanza, ma include tutti quegli aspetti legati all assistenza sanitaria in senso lato. Una serie di nuovi concetti sono ora riferiti alla telemedicina; due di questi sono e-health e tele-health (tele-assistenza). La telemedicina/teleassistenza può essere applicata in vari modi in tutti i servizi sanitari; può facilitare e razionalizzare la comunicazione e lo scambio di informazioni, tra servizi di primaria assistenza e gli ospedali, tra ospedali diversi, tra ospedali e i laboratori, tra i servizi di riabilitazione e le organizzazioni paramediche. La telemedicina riguarda anche la direzione e l amministrazione dell unità sanitarie locali, i pazienti e i loro familiari Vantaggi L avvento dell informatica medica e la conseguente introduzione di nuove tecnologie nell ambito sanitario hanno portato e porteranno notevoli vantaggi sia per i pazienti che per il personale medico

9 CAP. 1 - TELEMEDICINA L introduzione della telemedicina permette : Diagnosi e cure più rapide Minor numero di spostamenti sia del personale medico che dei pazienti Riduzione dei costi per personale (compreso quello di emergenza) Comunicazioni più veloci Aggiornamento più semplice e rapido delle informazioni riguardanti diagnosi e metodi di cura Miglior sostegno allo staff medico per la formazione sia teorica che pratica Problemi In passato i costi per l attrezzatura e le telecomunicazioni sono stati troppo alti da permetterne un introduzione su larga scala, oggi tuttavia la situazione sotto questo punto di vista è notevolmente migliorata il vero ostacolo da affrontare è cercare di introdurre metodi che favoriscano l accettazione e la comprensione da parte del personale interessato, delle applicazioni di telemedicina/teleassistenza nei servizi sanitari. Bisogna sottolineare che l introduzione della telemedicina influenza i tradizionali metodi di lavoro, si vanno a modificare i modelli di cooperazione, si creano nuove figure - 6 -

10 CAP. 1 - TELEMEDICINA lavorative e molto spesso sorgono problemi di distribuzione dei costi e di investimenti delle risorse. Alcuni progetti di telemedicina sono partiti proprio da un analisi preliminare dell impatto che possono avere nelle procedure ospedaliere, nella ridistribuzione dei compiti e delle risorse. Dato l impiego di tecnologie avanzate sia come digitalizzazione che come diffusione dell informazione, quindi nei settori dell informatica e della telecomunicazione, è necessaria anche la formazione del personale e l addestramento dello stesso all utilizzo corretto delle infrastrutture e alla manutenzione di questo nuovi sistemi. A livello internazionale, ad oggi, si registra una mancanza di uniformità sull applicazione del concetto di telemedicina, dato che vanno a sovrapporsi due differenti sfere di interesse, quella medica e quella ingegneristica; tutto ciò rende difficile la creazione di standard riconosciuti che possano regolamentare tale disciplina. Questo rappresenta un limite alla diffusione e all impiego su larga scala delle soluzioni che in questi anni sono state elaborate

11 CAP. 1 - TELEMEDICINA 1.3 STATO DELL ARTE Oggigiorno i sistemi sanitari mondiali stanno facendo passi da gigante nell utilizzo massiccio della telemedicina, grazie soprattutto allo sviluppo di nuove tecnologie. In ambito nazionale ogni regione si sta attrezzando allo sviluppo di sistemi di informatica medica. Uno dei principali progetti a livello nazionale è rappresentato da As.ter: un sistema informativoinformatico per la gestione di tutte le attività del territorio sviluppato dalla USL 11 di Empoli. As.Ter integra, con l ausilio di una piattaforma tecnologica innovativa, tutti gli applicativi ed i database delle attività sanitarie e sociali svolte sul territorio, consentendo la rilevazione dei bisogni complessivi dei cittadini, l individuazione delle modalità e dei tempi di risposta ai loro bisogni, la rilevazione dei costi; tutto ciò al fine di pianificare e gestire le attività sociosanitarie sul territorio in un ottica manageriale di costi/benefici. Un altro progetto è stato proposto dal servizio sanitario regionale Emilia-Romagna con il nome di SOLE. Esso è finalizzato a realizzare una rete telematica, basata su una serie di hub (centri di archiviazione) e spoke (centri di acquisizione), di collegamento tra i servizi ospedalieri e i servizi territoriali per agevolare la comunicazione tra operatori sanitari e, di conseguenza, agevolare l'erogazione - 8 -

12 CAP. 1 - TELEMEDICINA dei servizi con importanti e positive ricadute sulla continuità assistenziale e sulla semplificazione dell accesso ai servizi per il cittadino. Un interessante applicazione sviluppata da un equipe guidata da Ennio Amori, all interno di questo progetto è Neurosurgery Teleconsulting, un servizio di teleconsultazione tra i centri di neurochirurgia collegati attraverso la rete hub&spoke, nella nuova logica distribuita e digitale, in modo da poter trattare ogni trauma e lesione in modo appropriato sfruttando il livello avanzato che ha raggiunto l IT. Molti sono i progetti pilota che puntano a creare tra i nostri ospedali e centri d eccellenza un collegamento con i paesi dell Europa dell est, che sono da poco entrati nella comunità europea, per fornire servizi di teleconsulto e telediagnosi, come per esempio tra Padova o Milano e la Romania. Nello sviluppo di questo tipo di progetti è possibile usufruire anche dei finanziamenti della comunità europea che ovviamente danno maggiore spinta alla ricerca e permettono di pagare la consulenza di software house, esterne alle aziende sanitarie, che possono dare un forte supporto tecnico e far ottenere un prodotto software più completo ed evoluto. In tutto questo panorama di progetti non emerge nessun sistema simile a quello sviluppato nella nostra tesi, si tratta sempre di servizi ad hoc per applicazioni specifiche, senza una vera ottica di integrazione e supporto globale di servizi sanitari delocalizzati

13 CAP. 1 - TELEMEDICINA 1.4 PROGETTI DELL ASUR MARCHE ZONA 7 L ASUR della regione Marche zona 7 ha sviluppato una serie di progetti che riguardano l ambito medico tra i quali troviamo: Sistema di Teleconsulto ospedale di Osimo con stazioni fisse e stazioni mobili Assistente Virtuale Delocalizzazione della refertazione diagnostica Sistema di teleconsulto ospedale di Osimo con stazioni fisse e stazioni mobili La Telelettrocardiografia è stata la prima applicazione derivata dalle esperienze aerospaziali sia americane che russe. Lo sviluppo enorme in tutti i paesi industrializzati della telefonia cellulare consente di erogare questo tipo di servizio di Telerefertazione con una eccezionale capillarità territoriale. Il sistema è composto da un server situato presso l Ospedale di Osimo, le caratteristiche del server sono le seguenti: Server Compaq Proliant ML 370 T, P GB,

14 CAP. 1 - TELEMEDICINA Cache 256 K ram 256 MB, 3 Hard Disk da 18 GB, il software permette la connessione fino a 25 apparecchiature in rete Ethernet. È inoltre composto da un client situato presso l Ospedale di Osimo, le caratteristiche del client sono: Compaq EVO D500 SFFP GB Hard Disk da 20GB, schede di rete CD Rom 48x, monitor 17 e stampante laser HP 1200 e da tre stazioni fisse composte da tre elettrocardiografi del tipo Archimed Base Plus, il quale consiste in un elettrocardiografo portatile per l acquisizione contemporanea di dodici derivazioni dotate di monitor Lcd retroilluminato ad alta risoluzione di grandi dimensioni per la visualizzazione di sei tracce Ecg, tastiera alfanumerica, Driver per floppy da 3,5 e hard disk da 1 GB per la memorizzazione dei tracciati. L elettrocardiografo è provvisto di varie uscite esterne, tra cui quattro seriali RS 232, una rete Ethernet per trasmissione e ricezione di tracciati ecg con relativo referto e stampante Archimed 4240 termica formato A4. Inoltre di una stazione mobile composta da una valigetta AT 4 Gsm che è una 24 ore completa di elettrocardiografo portatile computerizzata, dotato di Display Lcd di grandi dimensioni che permette di visualizzare contemporaneamente tre tracce ecg oltre una stampante per l acquisizione contemporanea di dodici derivazioni ecg in modalità automatica, l apparecchio è dotato di memoria interna per l archiviazione di quaranta ecg (10 secondi 12 derivazioni) fornita di cellulare Gsm

15 CAP. 1 - TELEMEDICINA Dual Band con interfaccia per elettrocardiografo e cavi di connessione per la trasmissione digitale dell ecg alla Centrale di Ascolto, funzione di viva voce per comunicare con la Centrale di Ascolto. Il Client è posto nella zona di controllo della Unità di Terapia Critica del Dipartimento di Medicina Interna ove un operatore è costantemente presente durante le ore del giorno e della notte. Le tre stazioni fisse sono al momento situate presso le Unità di degenza mediche del Presidio Ospedaliero di Osimo ed una presso i Poliambulatori di Camerano situati all interno di una struttura residenziale per anziani con circa 80 degenti. La stazione mobile viene al momento affidata agli operatori della Emergenza Urgenza Territoriale che fanno capo al Distretto Ancona Sud. Fig. 1.2 Applicazione di telemedicina con elettrocardiografo

16 CAP. 1 - TELEMEDICINA Assistente Virtuale È un progetto ancora in fase embrionale che ha come obiettivo quello di creare un assistente personale virtuale che sia in grado di offrire ad ogni singolo utente un valido appoggio in riferimento alla propria situazione clinica. L utente che si connetterà a questo nuovo sistema avrà a disposizione un alter-ego virtuale che attraverso un interfaccia user-friendly gli permetterà di interagire in modo guidato con i suoi dati clinici, oltre che fornire in modo automatico un promemoria degli eventuali esami da svolgere o dei referti pronti alla consultazione. Quindi un sistema con interfaccia amichevole per accedere ai propri dati clinici che funga anche da archivio e agenda sanitaria. Fig. 1.3 Interfaccia dell assistente virtuale

17 CAP. 1 - TELEMEDICINA Delocalizzazione della Refertazione Diagnostica Nell ottica di capillarizzare l offerta sanitaria così come negli obiettivi della sanità regionale, può essere importante pensare ad una struttura informatica che renda indipendenti le due fasi tipiche della diagnostica: l esecuzione dell esame e la sua refertazione. Infatti mentre è possibile pensare di localizzare alcuni macchinari (di basso costo) anche nei poliambulatori più piccoli, può risultare sconveniente portare in questi poliambulatori personale di alta specializzazione. Quello che ci si propone è di potenziare la rete di acquisizione dell esame digitale, aumentando il numero delle macchine e dei tecnici di laboratorio, concentrando invece il personale medico che deve compilare il referto; il personale di laboratorio ha un costo inferiore rispetto ai dottori, quindi si aumentano capacità, capillarità e efficienza del servizio limitando gli investimenti. La struttura informatica che ci si propone di realizzare in questa fase, poi potrà anche servire per altri scopi come

18 CAP. 1 - TELEMEDICINA consulti medici oppure per fornire servizi (a pagamento) di refertazione per altri enti. seguente: L architettura di massima proposta e quindi la Fig. 1.4 Schema a blocchi delocalizzazione diagnostica Sostanzialmente un sistema per la refertazione a distanza altro non è che un repository di eventi sanitari con relativo output dell esame (per esempio radiografia, elettrocardiogramma, etc). In questo repository gli enti periferici (poliambulatori, etc.) depositano gli output degli esami e prelevano i referti mentre il centro di refertazione preleva gli output degli esami ed inserisce i referti relativi

19 CAP. 1 - TELEMEDICINA Per mettere in piedi la procedura appena descritta è indispensabile: che tutti i partecipanti siano collegati ad una rete intranet o internet; essere collegati ad una infrastruttura PKI funzionante; utilizzare un metodo di trasferimento sicuro (SSL). Il nostro progetto di tesi nasce proprio come ricerca di una soluzione ingegneristica a livello software per rispondere ad un esigenza sanitaria di delocalizzazione. Requisiti fondamentali di tale sistema, data la varietà di dati da trattare e di ambienti in cui operare, sono la semplicità e la flessibilità; tenendo presenti questi due punti il sistema può raggiungere un livello di efficienza adeguato al supporto di servizi di teleconsulto e la telerefertazione e non solo, in generale per qualsiasi servizio sanitario delocalizzato

20 CAP. 2 SPECIFICHE PROGETTO MIRO CAPITOLO 2 SPECIFICHE PROGETTO MIRO Descrizione dell architettura del Progetto MiRo, spiegazione del funzionamento delle varie componenti del sistema: repository, laboratorio e medico. Panoramica delle soluzioni tecniche adottate. 2.1 Finalità 2.2 Architettura Generale Repository Laboratorio Medico 2.3 Soluzioni Tecniche Comunicazione sicura e Mutuo Riconoscimento Messaggi SOAP

21 CAP. 2 SPECIFICHE PROGETTO MIRO 2.1 FINALITÀ Il progetto MiRo nasce dalla collaborazione tra l Università Politecnica delle Marche con l azienda ASUR Marche Zona 7 di Ancona, come soluzione software all esigenza mostrata dall ASUR, data la frammentarietà del nostro territorio marchigiano, di poter delocalizzare la refertazione diagnostica. L obiettivo del nostro progetto era quello fornire all azienda sanitaria locale, un prodotto flessibile che implementasse un servizio di refertazione asincrono; cioè in grado di separare non solo da un punto di vista temporale, ma anche da quello spaziale, l esecuzione dell esame dalla refertazione dello stesso. Per asincrono intendiamo che non ci si aspetta che l esame venga refertato in tempo reale, ma in un tempo accettabile concordato tra i fornitori del servizio e gli utenti. Fig. 2.1 Contesto del progetto

22 CAP. 2 SPECIFICHE PROGETTO MIRO Come si evince dalla figura, la nostra architettura deve fornire un supporto per lo sviluppo di servizi sanitari, non si pone l obiettivo di sostituire i sistemi informativi già esistenti che sono molteplici e variegati, ma li vuole integrare in una rete di comunicazione sicura che faciliti e razionalizzi lo scambio di informazioni. Nello specifico si tratta di servizi di teleconsulto in ambiente Intra/Internet, quindi basati su TCP/IP, come la refertazione e la second opinion. Visto che l ambiente in cui opera il nostro sistema è intrinsecamente non sicuro, uno dei requisiti fondamentali da rispettare è il livello di sicurezza e di affidabilità, del trattamento del dato clinico, cioè consentire uno scambio di informazioni sicuro in un ambiente che non lo è. Lo scopo di MiRo è stato creare un applicazione software completa in grado di gestire l intero processo di telerefertazione e di teleconsulto, più in generale supportare in modo sicuro un servizio sanitario delocalizzato

23 CAP. 2 SPECIFICHE PROGETTO MIRO 2.2 ARCHITETTURA GENERALE Il primo passo fatto per progettare MiRo (che è l acronimo per Medical Instruments for Report Objects) è stato capire come si doveva integrare con il sistema informativo sanitario già esistente; la prima ipotesi semplificativa adottata è stata quella di creare una piattaforma flessibile per lo sviluppo di servizi sanitari che avesse un architettura orientata ai servizi. Si è pensato di creare una struttura semplice, basata su standard diffusi e riconosciuti, come Internet, in modo da sviluppare una piattaforma che potesse facilmente essere applicata in ambito sanitario sia a livello del personale medico che in un prossimo futuro direttamente ai cittadini. MiRo si basa sul concetto di evento, questo aspetto rappresenta il punto focale dell intero sistema. L effettuazione di un esame presso un laboratorio (qualsiasi, di una qualunque struttura ospedaliera) e la conseguente archiviazione del dato in forma digitale genera ciò che viene chiamato evento. L evento non è il dato clinico vero e proprio ma rappresenta una sorta di meta-dato-clinico del dato digitale generato dai laboratori. È composto da una serie di

24 CAP. 2 SPECIFICHE PROGETTO MIRO informazioni che riguardano il dato digitale prodotto dall evento come ad esempio: l unità che ha erogato la prestazione, la data e l ora dell esame, la struttura che l ha prodotto, l eventuale dottore richiedente ed il codice dell impegnativa, lo stato della fase di refertazione, e, cosa molto importante il link al servizio web che consente di scaricare il dato, ecc. Ogni evento quindi viene immagazzinato all interno di un apposito raccoglitore, definito repository, che costituisce il nucleo del sistema e che funziona da collegamento tra colui che referta e l esame. Questo legame è contenuto nell evento e il repository è una sorta di sofisticato gestore di eventi clinici. Qualsiasi esame che può essere memorizzato in forma digitale può essere associato ad un evento, con questa soluzione ingegneristica siamo riusciti ad ottenere quella flessibilità ed adattabilità che venivano richieste in fase di progettazione. Una soluzione semplice, ma molto efficace, che abbiamo ritrovato anche in altri progetti di sistemi informativi in ambito sanitario. L architettura, di conseguenza, mostra un analoga flessibilità e semplicità, infatti è prevista la presenza solamente di tre attori principali che interagiscono tra loro e che rappresentano un astrazione delle funzioni principali: da un lato l esecuzione dell esame, dall altro la generazione del referto, con al centro un nodo di gestione del sistema

25 CAP. 2 SPECIFICHE PROGETTO MIRO Fig. 2.2 Architettura generale di MiRO Il cuore del sistema è rappresentato dal Repository centrale che può essere ospitato da un azienda o da un ente erogante (in prima istanza l ASUR stessa), il quale si impegna nel corretto funzionamento dell intero sistema di refertazione e nella manutenzione dello stesso. Nella parte destra della figura sono rappresentate le strutture che producono i dati digitali di un esame clinico e che si interfacciano nel nostro sistema come dei client di laboratorio: sono quelli che attivano il processo di refertazione e attendono i risultati. Dall altra parte si trova il personale che fornisce il servizio di refertazione, una clinica specializzata, un semplice medico o una equipe di medici; attraverso l interfaccia del medico possono interagire nel nostro

26 CAP. 2 SPECIFICHE PROGETTO MIRO sistema e pubblicare il proprio referto autenticandolo con la propria firma digitale Repository La struttura del sistema prevede la presenza di un repository centrale, costituito da un server che ospita un database relazionale nel quale vengono memorizzati le informazioni relative ai dati digitali prodotti nei laboratori. Ogni registrazione all interno del database di questo repository costituisce quello che noi chiamiamo evento ; l evento rappresenta una sorta di meta-dato informativo riguardante il dato digitale prodotto nei laboratori. Le informazioni che vengono registrate sono data e ora dell inserimento nella base dati, il tipo do esame eseguito e il laboratorio in cui è stato effettuato, informazioni sulla provenienza della richiesta di prestazione sanitaria e il percorso (pathname) dove recuperare l esame o meglio il dato digitale riguardante l esame vero e proprio. La scelta delle informazioni da memorizzare è stata fatta consultando il personale dell azienda sanitaria, in modo da render semplici ed accessibili le informazioni principali riguardanti un esame. Da notare che non vengono mai registrate le informazioni relative al paziente, infatti il nostro primo obiettivo è quello di fornire un servizio di refertazione che

27 CAP. 2 SPECIFICHE PROGETTO MIRO abbia la possibilità di concedere second opinion. Viceversa non viene fornito un servizio di diagnosi, per il quale sarebbe necessario un trattamento dei dati sensibili del paziente. Tutto ciò rende molto flessibile la struttura eliminando i problemi riguardanti la privacy. Nel caso di applicazioni future per telediagnosi, o per la consultazione della cartella clinica dei pazienti, avremmo l obbligo legale di strutturare in modo più robusto, dal punto di vista della sicurezza, il server che ospita il repository, oltre all utilizzo di tecniche di criptazione per la memorizzazione dei dati Laboratorio La seconda figura che viene presa in esame è il laboratorio, con questo termine intendiamo qualsiasi struttura sanitaria abbia necessità di farsi refertare un esame; potrebbe essere un laboratorio radiologico, analisi, epidemiologico oppure un autoambulanza con apposita apparecchiatura, una piattaforma petrolifera (anche essa con la giusta strumentazione), ecc. Quindi nella descrizione del nostro sistema parleremo sempre di laboratorio come interfaccia comune che identifica in modo univoco ognuna di queste unità. Il laboratorio apre un evento, cioè una volta effettuato un esame e ottenuto il dato digitale sia in maniera diretta o tramite passaggi di discretizzazione, si collega al web

28 CAP. 2 SPECIFICHE PROGETTO MIRO service dell ente che fornisce il servizio di telerefertazione (nel nostro caso ASUR Marche zona 7) e tramite un opportuna interfaccia inserisce i dati relativi all esame eseguito all interno del database centrale. Grazie al repository che pubblica l evento, il dato digitale presente nel laboratorio diventa accessibile e pronto per essere refertato da parte degli altri attori di questo sistema, i dottori o meglio il personale specializzato per la refertazione. Una volta generato l evento il laboratorio può monitorare l evento, ossia controlla tutte le varie fasi di refertazione che l evento da lui generato subisce, fino a che non ritiene soddisfatta la sua richiesta. A questo punto il laboratorio dichiara chiuso l evento e termina la fase di refertazione; logicamente solo chi ha generato la richiesta può dichiarare terminato il processo di refertazione. Fig. 2.3 Funzionalità lato del laboratorio

29 CAP. 2 SPECIFICHE PROGETTO MIRO Medico Una volta che il laboratorio apre l evento e quindi va ad aggiungere un record al Repository centrale, effettua una richiesta di refertazione all altra figura che compare nell architettura di MiRo: i medici o per meglio dire il personale specializzato. Ogni medico effettuando l accesso tramite un semplice web browser (per esempio Internet Explorer) accede al web service centrale dove tramite opportune interfacce userfriendly vengono mostrati solo gli eventi che ogni medico è in grado di refertare: questo perché in generale noi stiamo parlando di specialisti in particolari discipline mediche e non ha senso confondere l utente con una serie di eventi che non ha nessuna utilità di consultare. Ad ogni dottore verrà visualizzato un elenco di tutti gli eventi che può refertare e dove sono presenti data e ora di inserzione nel database, il laboratorio che l ha creata, lo stato dell esame (aperto, refertato, chiuso) e infine il download ossia la possibilità di scaricarsi il dato ottenuto nel laboratorio sul proprio pc per visualizzarlo in modalità offline e quindi refertarlo

30 CAP. 2 SPECIFICHE PROGETTO MIRO Fig. 2.4 Funzionalità lato del medico. Quando il medico decide di refertare un esame gli verrà presentata una form dove può scrivere il suo referto e contemporaneamente può leggere i referti emessi dagli altri medici, in questo modo si viene a creare un meccanismo definito second opinion (uno degli obiettivi di partenza del nostro lavoro). Un altro aspetto fondamentale che riguarda il medico è la firma digitale. Una volta scritto il referto il medico deve, tramite certificato digitale firmare il referto in modo da garantire a tutti gli operatori del sistema la propria identità e veridicità. Ciò se basta a confermare chi ha redatto il referto non da certezze su quando il referto sia stato scritto e firmato; quindi una volta scritto, il referto firmato deve essere spedito ad un web service esterno chiamato TimeStamp Service il quale sancirà in modo inequivocabile l istante temporale in cui il dottore ha sottomesso il referto al sistema. Il web service TimeStamp rimanderà al medico il referto con il TimeStamp e il medico lo spedirà al repository centrale che lo immagazzinerà

31 CAP. 2 SPECIFICHE PROGETTO MIRO In questo modo si offrono le garanzie necessarie sulla fase di refertazione. Fig. 2.5 Processo di Refertazione

32 CAP. 2 SPECIFICHE PROGETTO MIRO 2.3 SOLUZIONI TECNICHE MiRo è un applicazione object-oriented basata su internet che fa uso di database relazionali per memorizzare i dati. Questa applicazione, basata su un modello client server viene eseguita all interno di un web browser standard utilizzando la Java Virtual Machine, riducendo in maniera significativa i tempi e le difficoltà di configurazione dei client. Questo è un requisito fondamentale specialmente in ambiente remoto. MiRo è un sistema che si basa su di un architettura orientata ai servizi, implementata attraverso Web Services, i quali stanno diventando uno standard de facto per quanto riguarda la distribuzione di servizi all interno di un ambiente eterogeneo come Internet. I Web Services offrono un insieme di standard di comunicazione che permettono a diverse applicazioni di scambiarsi dati e servizi applicativi. Tutto ciò garantisce la massima accessibilità da parte degli operatori. L architettura prescelta è quella delineata da Java 2 Standard Edition di Sun e gli strumenti di sviluppo sono: Eclipse 3.1 RC2 e JDK come piattaforma di sviluppo; Apache Axis e Java Servlet per la realizzazione dei web service;

33 CAP. 2 SPECIFICHE PROGETTO MIRO Apache Struts e Java Sever Pages per le interfacce web. Data la architettura così generica il sistema può operare su qualsiasi piattaforma che supporti i web services realizzati in Java. I database supportati sono tutti quelli con interfacce JDBC (nel nostro caso MySQL). I client possono accedere in qualsiasi momento per consultazione o inserimento dati utilizzando un comune Web Browser. Ogni operatore accederà a funzionalità diverse del sistema sulla base del proprio profilo professionale Comunicazione sicura e Mutuo Riconoscimento Un aspetto al quanto fondamentale, oggetto di studio e di progettazione nel nostro lavoro, è stata la sicurezza, nello specifico si è parlato di comunicazione sicura e mutuo riconoscimento. Anche se, come detto precedentemente, in questo lavoro non vengono mai trattati i dati sensibili relativi ai pazienti, la sicurezza delle comunicazioni all interno del sistema svolge un ruolo fondamentale, perché la struttura è stata pensata e sviluppata per applicazioni che si basano su Internet, rete insicura per sua natura, si è reso necessario utilizzare il protocollo di

34 CAP. 2 SPECIFICHE PROGETTO MIRO comunicazione https che rappresenta l equivalente del classico http, dove le informazioni viaggiano in maniera criptata; le transazioni effettuate vengono criptate tramite lo standard SSL con mutuo riconoscimento. Fig. 2.6 Comunicazione SSL con mutuo riconoscimento Alla base di una comunicazione sicura, è necessario un riconoscimento di entrambi i partecipanti alla conversazione. Tutto ciò è stato possibile attraverso l utilizzo di certificati digitali che garantiscano l identità di chi si collega al sistema. Una volta effettuato l accesso e quindi, avvenuto il riconoscimento, al client (sia esso medico o laboratorio) viene offerto un accesso guidato all interno della struttura in base alle informazioni che sono contenute nel certificato digitale; in questo modo il sistema può stabilire dal lato del laboratorio quali eventi può generare e controllare, viceversa dal lato del medico individua quali esami è abilitato a refertare. Il certificato digitale rappresenta una sorta di carta identità elettronica per chi si aggancia al sistema

35 CAP. 2 SPECIFICHE PROGETTO MIRO Tramite l utilizzo della tecnologia SSL e dei certificati vengono soddisfatti i quattro requisiti fondamentali per la sicurezza: Autenticazione: garanzia che l utente sia chi dichiara di essere. Ottenuta grazie al certificato ed agli Username e Password. Confidenzialità: garanzia che i dati possono essere letti esclusivamente dall utente autorizzato. Ottenuta grazie ai certificati. Integrità: garanzia che le informazioni non vengano modificate durante la trasmissione. Ottenuta grazie alla crittografia. Non-ripudiazione: garanzia che chi utilizza il programma tramite il certificato se ne assuma le responsabilità Messaggi SOAP La comunicazione all interno del sistema, avviene con scambio di messaggi SOAP (cosa sono e come funzionano verrà spiegato nei prossimi capitoli). I dati si inviano come allegati ai messaggi SOAP, abbiamo scelto questa tecnica per lo scambio di informazione perché avendo come obbiettivo quello di creare una struttura in grado di adattarsi a qualsiasi tipo di esame, era importante avere la possibilità di scambiare

36 CAP. 2 SPECIFICHE PROGETTO MIRO messaggi di dimensioni variabili, in questo modo abbiamo raggiunto tale obbiettivo. Ad esempio, un dato proveniente da un laboratorio radiologico produce dei file Dicom di dimensioni che si aggirano attorno ai 40 Mb (dipende dall esame), con questo sistema non si sono verificati problemi di trasmissione dei pacchetti. Una cosa importante da notare è che per implementare questa struttura si ha bisogno di una rete a larga banda che consenta le transizioni di file di dimensione variabile

37 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO CAPITOLO 3 IMPLEMENTAZIONE DEL PROGETTO Descrizione dell implementazione del progetto, analisi degli elementi principali dell architettura, dal repository centrale, ai web service del repository e del laboratorio. 3.1 Repository Concetto di Evento Struttura della base-dati 3.2 Web Service Web Service Repository Web Service Laboratory

38 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO 3.1 REPOSITORY La struttura del sistema prevede la presenza di un repository, costituito da un database relazionale, nel quale vengono memorizzati i dati degli eventi generati dall esecuzione di un esame presso uno dei laboratori collegati. All interno dell architettura che abbiamo studiato si possono distinguere differenti tipi di informazioni che vengono scambiati nella rete, uno dei quali è alla base del nostro sistema, l evento, come è rappresentato in figura. Fig. 3.1 Strutture dati astratte

39 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO Concetto di Evento L evento corrisponde alla registrazione dell esame all interno del repository. Tecnicamente costituisce un record di una tabella all interno di un database che risiede in un server centrale che costituisce il nucleo centrale dell intero sistema. L evento si configura come un metadato che racchiude le informazioni sul dato digitale vero e proprio, cioè sull esame, e sul processo di refertazione. Usiamo il termine di meta-dato perché è un dato del dato : non contiene l informazione originale, ma un puntatore ad essa. Per mezzo di questo link è possibile raggiungere il dato digitale dell esame, corredato da ulteriori specifiche: chi ha eseguito l esame e quando, oltre alla tipologia di prestazione. In questo modo l evento astrae il dato digitale dell esame, fornendo al sistema un modo univoco di accesso al dato, una specie di interfaccia per l esame che astrae le varie differenze di formato dovuto alla varietà di periferiche digitale, quali elettrocardiografi o macchine per radiografie. Questi dati rimangono memorizzati all interno delle memorie di massa dei laboratori, non andando a creare criticità per un possibile sottodimensionamento dei supporti rigidi all interno del repository. Per esempio quando si parla di immagine DICOM, parliamo di file che possono raggiungere i 20 MB e considerando un bacino di utenza dell ASUR di più di un milione di persone ci possiamo rendere conto che se

40 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO fossero generate 50 immagini al giorno avremmo bisogno di 1GB al giorno. Inoltre andremmo a centralizzare la memorizzazione dei dati, in un unica struttura, limitando l indipendenza dei sistemi già presenti nelle varie zonalità. Volendo costituire un substrato che si integra con i sistemi informativi presenti non vogliamo sicuramente obbligare a determinate scelte organizzative per i vari enti, vogliamo che il costo di ingresso a questa rete di scambio di informazione sia il minimo, una semplice interfaccia di accesso al sistema e un servizio per la fornitura dei dati digitali memorizzati al proprio interno. In questo modo non è necessario apportare modifiche a procedure interne già esistenti, ma semplicemente aggiungere ulteriori funzionalità. Poi sarà l ente stesso a valutare l utilità di questo sistema di delocalizzazione delle risorse e dei servizi. In questa rete è evidente che l informazione principalmente scambiata è quella dell evento, che racchiude non solo l esame come un link esterno, ma anche tutti i dati sulla refertazione. Oltre ad una struttura di memorizzazione relazionale come il database necessitiamo di un sistema di archiviazione su file-system, per registrare i referti. Il nostro repository deve avere una certa capacità di storage per poter archiviare sia i file di testo originali contenenti i referti, sia i file generati dal processo di firma

41 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO Struttura della base-dati Fig. 3.2 Diagramma della struttura della base-dati. Tab. 3.1 Riepilogo delle tabelle. NOME TABELLA tm_eventi DESCRIZIONE Contiene gli eventi che vengono generati dai laboratori

42 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO Contiene la tipologia di esami che un tm_permissioni tm_referti laboratorio è in grado di registrare nel sistema e quelli che un medico è in grado di refertare. Contiene i referti relativi a ciascun esame registrato. Contiene le tipologie di esame, tm_tariffario tm_unitaeroganti codificate in un tariffario delle prestazioni. Contiene le unità che erogano i servizi sanitari. Contiene gli utenti registrati nel tm_utenti sistema, o come laboratori o come medici. Tab. 3.2 Tabella degli Eventi. NOME CAMPO evt_id evt_trf_codice evt_codente DESCRIZIONE Identificativo univoco dell evento all interno del sistema. Tipologia dell esame collegato all evento. Codice identificativo dell ente. evt_codstruttura Codice identificativo della struttura. evt_codspecialita Codice identificativo della specialità

43 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO evt_codunitaeroga Codice identificativo dell unità nte erogante. Flag che indica se l unità è esterna evt_esterno evt_dtmevento evt_dtmchiuso evt_token evt_wslink evt_stato evt_richiedente evt_impegnativa evt_note all azienda sanitaria dove risiede il repository. Data e ora di apertura dell evento. Data e ora di chiusura dell evento. Identificativo dell esame che permette di ottenere i dati collegati. Link al web service che deve fornire i dati digitali dell esame. Stato dell evento (0=aperto, 1=refertato, 2=chiuso). Informazione aggiuntiva del medico o struttura che ha richiesto l esame. Informazione aggiuntiva del codice dell impegnativa. Eventuali note legate all evento. Tab. 3.3 Tabella delle Permissioni. NOME CAMPO prm_utn_id DESCRIZIONE Identificativo univoco dell utente all interno del sistema

44 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO Tipologia dell esame a cui l utente prm_trf_codice può accedere, sia esso un laboratorio che un medico. Tab. 3.4 Tabella dei Referti. NOME CAMPO ref_evt_id DESCRIZIONE Identificativo univoco dell evento all interno del sistema. Indice progressivo del referto dell evento, in questo modo un ref_ind ref_filename ref_timestamp ref_notvalid referto è individuato univocamente dal campo ref_evt_id e dal campo ref_ind. Nome del file che contiene il referto in formato testo. Data e ora di sottomissione del referto. Flag che indica se il referto è stato invalidato. Identificativo univoco dell utente ref_utn_id all interno del sistema che ha scritto il referto

45 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO Tab. 3.5 Tabella del Tariffario. NOME CAMPO trf_codice trf_descr DESCRIZIONE Codice identificativo della tipologia dell esame. Descrizione per esteso della prestazione. Tab. 3.6 Tabella delle Unità Eroganti. NOME CAMPO uer_codente DESCRIZIONE Codice identificativo dell ente. uer_codstruttura Codice identificativo della struttura. uer_codspecialita Codice identificativo della specialità. uer_codunitaeroga Codice identificativo dell unità nte erogante. uer_descr Descrizione per esteso dell unità erogante. Tab. 3.7 Tabella degli Utenti. NOME CAMPO utn_id utn_cn DESCRIZIONE Identificativo univoco dell utente all interno del sistema. CommonName che deve essere

46 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO presente anche all interno del certificato digitale. utn_type utn_codente Tipo di utente (L=laboratorio, M=medico). Codice identificativo dell ente. utn_codstruttura Codice identificativo della struttura. utn_codspecialita Codice identificativo della specialità. utn_codunitaeroga Codice identificativo dell unità nte erogante. Nel caso di laboratorio specifica il link utn_labwslink utn_archivepath al web service per l ottenimento dei dati di laboratorio. Specifica la cartella di lavoro dell utente

47 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO 3.2 WEB SERVICE Web Service Repository Fig. 3.3 Struttura del WebService Repository Il cuore del sistema è rappresentato dal Web Service Repository che offre una serie di funzioni che permettono la gestione del repository. In figura è evidenziata la struttura della classe con i metodi esposti (quelli nei riquadri di

48 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO colore giallo), quelli che costituiscono l interfaccia con cui è possibile comunicare con l oggetto. Sarà poi questa interfaccia ad essere tradotta da codice Java in un file WSDL, ovvero il documento xml che descrive i metodi forniti da un web service. Questo file viene poi pubblicato e reso disponibile a chiunque voglia fruire di uno dei servizi web forniti, per visualizzarlo basta richiamare l URL WSRepository?wsdl a partire dal percorso che contiene il web service. Fig. 3.4 Visualizzazione del file WSDL descriptor Questo file è fondamentale nell architettura distribuita, perchè rappresenta come è possibile comunicare e interagire con il server e quindi anche come costruire un

49 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO client che lo possa sfruttare. In ambiente Java è presente un tool, Java2WSDL, che automatizza questo processo e si carica del tedioso lavoro di creazione del file descrittore WSDL a partire da una classe Java. Fig. 3.5 Struttura del file WSDL Ad ogni metodo pubblico della classe corrisponderà un metodo del web service, richiamabile attraverso una URL in un formato particolare: WSRepository?method= nome del metodo & nome del parametro = valore del parametro &... Dall altra parte, è presente un tool che compie il lavoro inverso: WSDL2Java, a partire dal descrittore WSDL crea le classi per una minima implementazione del client. Per maggiori informazioni su questi tool è possibile consultare la documentazione della Sun. Vediamo ora una panoramica dei metodi esposti dalla classe WSRepository e quindi dal corrispondente Web Service:

50 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO closeevent(int evt_id) chiude un evento esistente, l evento è individuato dal suo identificativo; echo(string value) funzione di test del webservice; ritorna la stringa che è stata inviata come parametro; getreports(int evt_id) ritorna l'elenco dei referti come una stringa e in allegato tutti i file di referto associati all evento specificato; invalidatereport(int evt_id, int ref_ind) invalida un referto di un evento esistente, l evento è individuato dal suo identificativo mentre il referto dal suo indice; listevents(int utn_id) ritorna l'elenco degli eventi in base alle permissioni dell utente, l utente è individuato dal suo identificativo; openevent(int utn_id, String evt_codice, boolean evt_esterno, String evt_token, String evt_wslink, String evt_richiedente, String evt_impegnativa, String evt_note)

51 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO apertura dell'evento, con inserimento di un nuovo record nella tabella degli eventi e registrazione delle informazioni passate come parametro e di quelle ottenute in modo automatico; uploadreport(int evt_id, int utn_id, String evt_content) carica nel repository un nuovo referto per l'evento, viene inserito un nuovo record nella tabella dei referti, memorizzato il contenuto del referto in un file e salvata la firma del referto per una successiva verifica dell integrità dei dati, questa viene passata come allegato; userinfo(string utn_cn) ritorna le informazioni dell'utente, individuato dal CommonName estratto dal certificato del client;

52 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO Web Service Laboratory Fig. 3.6 Struttura del WebService Laboratory Visto che il dato digitale dell esame rimane memorizzato all interno del laboratorio, questo deve fornire un modo per ottenere questa informazione. Quindi anche il laboratorio ha bisogno di un web service. Il client che deve eseguire il referto di un esame, avrà la possibilità di visualizzare e consultare il dato richiamando il servizio web esposto dal laboratorio che ha generato l evento corrispondente all interno del repository. Ogni struttura che voglia partecipare alla nostra rete come laboratorio che produce eventi clinici, come requisiti, deve provvedersi di un servizio web per la condivisione dei propri dati sugli esami, mantenendoli però all interno della propria struttura e conservando una certa autonomia. Il

53 CAP. 3 - IMPLEMENTAZIONE DEL PROGETTO laboratorio non deve cambiare le proprie procedure, ma deve solo integrare questa funzionalità di condivisione delle risorse. Vediamo ora una panoramica dei metodi esposti dalla classe WSLaboratory e quindi dal corrispondente Web Service: echo(string value) funzione di test del webservice; ritorna la stringa che è stata inviata come parametro; getevent(string file) ritorna come allega il file di risorsa contenente i dati digitali dell esame e inviduati dal token passato;

54 CAP. 4 - TECNOLOGIE SOFTWARE CAPITOLO 4 TECNOLOGIE SOFTWARE Panoramica delle tecnologie software impiegate nella realizzazione del progetto dal lato server del repository con i web service. 4.1 Java Platform Java lato server: le Servlet 4.2 Service-Oriented Architecture Web Services Protocollo SOAP 4.3 Application Server Apache Tomcat Comunicazione SSL 4.4 Strumenti di Sviluppo Apache Axis 4.5 Database Relazionale MySQL

55 CAP. 4 - TECNOLOGIE SOFTWARE 4.1 JAVA PLATFORM Fig. 4.1 Architettura della piattaforma Java. Java appena è uscito è stato accolto con molto entusiasmo dalla comunità mondiale dei progettisti di software e dei provider di servizi Internet, questo perché Java permetteva agli utenti di Internet di utilizzare applicazioni sicure e indipendenti dalla piattaforma, che si possono trovare in qualsiasi punto della rete. Java è quindi nato come linguaggio per la rete, per affiancare l'hyper Text Markup Language (HTML), il quale non è un linguaggio di programmazione vero e proprio, e per dargli quella sicurezza che l'html non ha. Da quando è

56 CAP. 4 - TECNOLOGIE SOFTWARE nato Java sulla rete si è iniziato a poter parlare di numeri di carte di credito e di informazioni sicure, notizia che ha molto affascinato le grosse società mondiali, le quali hanno trasformato la vecchia Internet, rete ad appannaggio delle sole università e centri di ricerca, nell'attuale mezzo di comunicazione aperto a tutti. Il linguaggio di programmazione Java è stato creato verso la metà degli anni novanta, è il più recente tra i suoi cugini, e per questo è ancora in fase evolutiva, tanto che ogni anno circa ne viene rilasciata una nuova relase. Da linguaggio nato solo per la rete è divenuto un vero e proprio linguaggio di programmazione, paragonabile, dal punto di vista delle funzionalità, al più blasonato C++. Java e la maggior parte degli altri linguaggi possono essere paragonati solo dal punto di vista delle funzionalità, perché sono fondamentalmente molto diversi, infatti Java compila i sorgenti dei suoi programmi in un codice detto Bytecode, diverso dal linguaggio della macchina su cui è compilato, mentre linguaggi come il C++ compilano i sorgenti dei programmi in un codice che è il codice della macchina ( per macchina intendo computer + sistema operativo ) su cui è eseguito. Quindi per eseguire un programma Java occorre avere uno strumento che è chiamato Java Virtual Machine, la quale interpreta il bytecode generato dal compilatore Java e lo esegue sulla macchina su cui è installato. Grazie alla Java Virtual Machine Java è indipendente dalla