Family Room. Sviluppo di un'app per la consultazione di dati clinici da parte di genitori di pazienti ricoverati in terapia intensiva

SCUOLA DI INGEGNERIA

DIPARTIMENTO DI INGEGNERIA DELL’INFORMAZIONE

CORSO DI LAUREA MAGISTRALE IN INGEGNERIA

BIOMEDICA

Family Room

Sviluppo di un’app per la consultazione di dati clinici da parte di

genitori di pazienti ricoverati in terapia intensiva

Relatore:

Candidato:

Prof. Maurizio Mangione

Laura Cerni

Correlatore:

Dott. Giuseppe Muccioli

Indice

3.5 Google Web Toolkit . . . 21

4 Progetto prototipo 23 4.1 Analisi dello scenario . . . 23

4.1.1 Questionario . . . 24 4.2 Architettura . . . 29 4.2.1 Windget . . . 29 4.2.2 Connessione al DB . . . 31 4.3 Progettazione e sviluppo . . . 33 4.3.1 Login . . . 34 4.3.2 Contenuti . . . 43 5 Conclusioni 71 Bibliografia 73

A Codice 79 A.1 Algoritmo LM Hash . . . 79

Introduzione

L’utilizzo di dispositivi mobili `e in costante aumento, e con esso lo sviluppo di

appli-cazioni per smartphone che rendono sempre pi`u servizi a portata di mano. In questo contesto si `e pensato di realizzare un’applicazione web che permetta ai genitori di

bam-bini ricoverati presso la Fondazione Toscana Gabriele Monasterio in terapia intensiva di visualizzare alcune informazioni sul ricovero del figlio/a direttamente da smartphone

e dall’interno della struttura ospedaliera.

Utilizzando il codice fiscale del paziente sar`a possibile accedere, in sicurezza e

rispet-tando la privacy, sia ai dati ospedalieri quali esami di laboratorio, terapia in corso, diari clinici, sia ai dati amministrativi del reparto quali medici ed infermieri operanti

nel reparto, sia alle norme a cui attenersi per un corretto comportamento in reparto ed anche alle associazioni per il supporto familiare.

Capitolo 1

Stato dell’arte

Il lavoro `e iniziato con una analisi degli articoli scientifici presenti in letteratura

riguar-danti i documenti digitali sanitari consultabili dal paziente stesso o chi per lui (genitori, coniugi o caregivers).

In Italia, i documenti digitali contenenti informazioni cliniche pi`u noti sono: la Cartella Clinica Elettronica (CCE) e il Fascicolo Sanitario Elettronico (FSE). La CCE `e un

do-cumento digitale che viene creato e archiviato dalla struttura sanitaria che ha in cura un paziente al fine di gestire in modo organizzato tutti i dati relativi alla sua storia

clinica e garantire continuit`a al suo percorso di cura. La CCE raccoglie le informazioni sulle visite e gli esami a cui si `e sottoposto il paziente nel corso del tempo all’interno

della struttura, e le rende accessibili a tutto lo staff. Una realt`a che si `e ormai diffusa sia in Italia che in altri Paesi. Il Fascicolo Sanitario Elettronico `e una raccolta online di

dati e informazioni sanitarie che costituiscono la storia clinica e di salute dell’individuo ed `e alimentato dai soggetti che lo prendono in cura nell’ambito del Servizio Sanitario

Regionale. Un punto di accesso unico, comodo, sicuro e sempre disponibile alla propria storia sanitaria. Dal punto di vista del paziente, quindi, la CCE pu`o risultare molto

simile al FSE, ma con alcune differenze: il FSE `e legato al paziente, mentre la CCE `e legata alla struttura in cui `e stata sviluppata. Dunque sono due sistemi diversi, ma

ambedue utilissimi per avere sotto controllo la storia clinica aggiornata [7].

L’applicazione sviluppata in questa tesi permetter`a la consultazione della CCE da parte

del paziente o dai suoi familiari. Tradizionalmente, infatti, gli operatori clinici sono gli unici attori che raccolgono, monitorano e riflettono sui dati clinici. I pazienti coinvolti

un decremento dei costi per la sanit`a [23, 48, 24]. Pertanto, per rendere il paziente partecipe delle sue cure, `e necessario che esso sia informato direttamente sul suo stato

di salute e le cure stesse, piuttosto che affidarsi ai medici per ottenere tali informazioni. Usualmente i pazienti non dispongono di strumenti adatti per accedere ai propri

trat-tamenti sanitari e questa loro impossibilit`a limita la loro partecipazione alle cure [37, 52, 32]. La maggior parte delle applicazioni per il monitoraggio della salute riguarda il

benessere quotidiano come ad esempio il monitoraggio dietetico e il monitoraggio degli obiettivi di attivit`a fisica giornaliera o settimanale. Tuttavia, l’ambiente ospedaliero si

differenzia dal contesto quotidiano in quanto, nel contesto quotidiano, le persone hanno la possibilit`a di controllare i propri dati e possono decidere autonomamente di fissare

obiettivi e tracciare i loro progressi personali. Contrariamente, in ambito ospedaliero, i pazienti consegnano i loro corpi e dati sanitari a una schiera di medici, infermieri,

tec-nici e altri fornitori di assistenza sanitaria che probabilmente non hanno mai incontrato prima. L’accesso ai dati immagazzinati in un sistema informatico `e rivolto al personale

clinico, conseguentemente il paziente risulta essere meno informato di quanto avveniva precedentemente con gli archivi cartacei[35]. I pazienti in ospedale ricevono

informa-zioni sulla loro assistenza principalmente da incontri verbali con medici. Tuttavia, i pazienti in genere dimenticano il 40-80% delle informazioni comunicate negli incontri

verbali[45]. La ricerca ha inoltre dimostrato che i pazienti ospedalizzati e il personale sanitario attribuiscono valori diversi a tipi specifici di informazioni[1], sottolineando

l’importanza di comprendere le esigenze di entrambe le parti per la progettazione di strumenti di monitoraggio in ospedale.

In due ospedali pubblici americani, il Seattle Children’s Hospital e il Virginia Mason Hospital, sono state condotte interviste a 30 persone tra pazienti e assistenti (ad

esem-pio genitori e coniugi)[42] e si `e indagato sul modo in cui i pazienti ricoverati prendono nota dei loro stessi parametri per capire come poter supportarli in questo compito. Il

sondaggio consisteva in una serie di figure che simulavano uno strumento o una funzio-ne per il monitoraggio dello stato delle cure sanitarie e per facilitare la comunicaziofunzio-ne

con i medici. Ad esempio, una scheda mostrava un grafico a linee generico che rap-presenta i risultati di un test con un’area etichettata ”Note del dottore” accanto; altre

contenevano funzionalit`a che consentivano ai pazienti di prendere appunti in vari for-mati. Durante le interviste, i partecipanti hanno descritto le loro considerazioni su una

particolare funzione: come sarebbe stata o non sarebbe stata utile per loro, e come avevano immaginato che funzionasse. I partecipanti sono stati inoltre incoraggiati ad

ampliare ogni funzione, inclusa la possibilit`a di scrittura alfanumerica o grafica, per permettere di suggerire nuove idee. I consigli dei pazienti sono stati:

• Introdurre un men`u dove poter inserire i propri sintomi;

• Introdurre la possibilit`a di salvare “record fotografici” ad esempio per valutare l’andamento delle ferite, il cambiamento di dimensioni di masse superficiali, e per chi `e impossibilitato a scattarsi le foto, farle scattare dal personale sanitario per

per poi visionarle essi stessi;

• Raccogliere informazioni sia su s`e stessi, sia su altre persone e processi dell’ospe-dale rilevanti per la loro cura;

• Registrare i dialoghi avvenuti col personale medico;

• Fornire informazioni sui processi dell’ospedale e dell’amministrazione, ad es. l’o-rario di un medico;

• Venire aggiornati ogni volta che i risultati di qualche test sono pubblicati; • Tracciare appuntamenti passati e futuri e le informazioni a riguardo; • Avere la possibilit`a di scrivere e registrare proprie note;

• Alcuni minori hanno mostrato interesse ad avere conversazioni con il proprio medico senza che il genitore ne venga a conoscenza;

• Disporre di maggiori dettagli sulla propria cura;

• Alcuni preferivano non avere nessuna notizia per paura di avere qualche brutta notizia;

• Disporre di un quadro delle cure dopo la dimissione dall’ospedale.

Nonostante i vantaggi del coinvolgimento dei pazienti, una recente revisione sistema-tica ha identificato una scarsit`a di ricerche sugli approcci per favorire l’impegno del

insoddisfatti [2, 36, 29, 4, 27]. Kendall et al. hanno identificato diverse esigenze co-muni non soddisfatte, incluse domande sui farmaci, risultati di test o studi di imaging.

Mentre Caligtan et al. [3] hanno evidenziato la necessit`a di disporre di informazioni scritte sul lato del letto che includevano temi logistici, come informazioni sugli orari

giornalieri, nonch´e un’ampia variet`a di esigenze mediche informative e specifiche per il paziente.

L’uso di applicazioni per smartphone o tablet progettate per pazienti ospedalizzati, esaminato in diversi studi, `e sempre stato accolto con alti tassi di soddisfazione. La

possibilit`a di utilizzare questi strumenti sia come risorse educative, sia per ottenere liste di farmaci, sia per la pianificazione degli appuntamenti e messaggistica [49, 17,

50, 5, 44]. Nuovi servizi informatici di questo tipo sono pi`u frequentemente richiesti dagli ospedali pediatrici: terapie intensive neonatale e pediatrica e aree chirurgiche e

traumatologiche pediatriche [20]. Al Vanderbilt Children’s Hospital sono stati intervi-stati 22 pazienti ed `e stato chiesto loro quali fossero le esigenze e necessit`a all’interno

del ricovero. Sono state individuate 5 categorie di esigenze:

1. Informazioni generali: conoscenze mediche reperibili in un libro di testo medico;

2. Esigenze mediche: fornitura di assistenza in seguito ad un nuovo sintomo o il risultato di un test;

3. Esigenze logistiche: ad esempio l’ubicazione di una clinica;

4. Esigenze sociali: supporto emotivo;

5. Altro: conoscenze generali come ad esempio il livello di colesterolo non patologico e come lo si pu`o controllare.

Queste interviste hanno evidenziato 99 esigenze, 38 delle quali classificabili nella prima categoria (informazioni generali), 26 nella seconda (informazioni mediche), 23 nella

terza (informazioni logistiche) e 12 nella quarta (sociale). Le esigenze pi`u frequenti comprendevano domande sugli interventi con indicazioni ed effetti avversi, sull’eziologia

e la prognosi. Molti genitori infatti non conoscevano abbastanza la nuova diagnosi, il dispositivo o il trattamento per porre una domanda ben definita. Inoltre alla richiesta di

consigli e suggerimenti sulle nuove tecnologie, le risposte sono state le seguenti (elencati in ordine di gradimento):

1. Siti web; 2. Applicazioni mobili; 3. Gruppi online; 4. Video chat; 5. Blog; 6. Social media.

Negli Stati Uniti, un sistema simile al nostro FSE, noto come portale del paziente, `e

gi`a disponibile sul mercato dal 2014 e riguarda informazioni mediche, la possibilit`a di prendere appuntamenti e un servizio di messaggistica. Tale applicazione permette

quindi ai pazienti di avere un accesso tempestivo e trasparente alle informazioni sani-tarie e di essere quindi coinvolti nel processo di cura.

All’inizio del 2015, l’ospedale Holland Bloorview Kids Rehabilitation Hospital (Holland Bloorview) a Toronto, in Ontario ha lanciato un portale per i pazienti con l’obiettivo

finale di aiutare loro e i loro assistenti (i familiari, in genere i genitori) ad assumere un ruolo attivo nella gestione dell’assistenza. L’ospedale `e un importante appoggio per

bambini con paralisi cerebrale, lesioni cerebrali acquisite, distrofia muscolare,

ampu-tazione, epilessia, spina bifida, artrite, palatoschisi, autismo e altre disabilit`a fisiche e dello sviluppo. Il portale sulla salute del paziente (chiamato Connect2care) `e stato

svi-luppato in collaborazione con pazienti e famiglie [19]. Connect2care fornisce ai pazienti e alle famiglie l’accesso elettronico alle loro cartelle cliniche, le funzioni di

annullamen-to e prenotazione online degli appuntamenti, l’accesso trasparente e tempestivo alla documentazione clinica e l’e-messaging per connettersi con il personale sanitario.

A partire da gennaio 2015 `e stata avviata l’iscrizione al portale, prima per i ricove-rati poi successivamente estesa anche alle prestazioni ambulatoriali. In questa prima

versione, le funzioni disponibili includevano la possibilit`a di visualizzare il programma giornaliero del paziente, vedere la storia clinica, visualizzare e stampare note cliniche e

aggiornare i dettagli anagrafici. Nel mese di maggio 2015 sono stati apportati miglio-ramenti alla visualizzazione dei risultati dei test di laboratorio e microbiologici e sono

stati stabiliti nuovi processi per aumentare il numero di note cliniche che sarebbero confluite nel portale. Durante l’estate del 2015, `e stata completata la formazione di

pi`u di 100 operatori sanitari per supportare questa condivisione delle note cliniche. Nell’estate e nell’autunno 2015, `e stata implementata la funzionalit`a di messaggistica

elettronica sicura tra gli utenti del portale e gli operatori clinici (medici, psicologi, as-sistenti sociali ecc.). A partire da dicembre 2015 `e stata completata la formazione dei

fornitori di e-messaging. A fine anno, c’erano 869 utenti iscritti e pi`u di 4800 utilizzi. Inoltre, alla fine del 2015, erano presenti nella chat oltre 200 dipendenti tra medici,

fisioterapisti, patologi del linguaggio, assistenti sociali, psicologi, personale di ricrea-zione terapeutica, personale di ortopedia e protesi e infermieri.

Per capire meglio l’utilizzo di questo portale `e stato condotto uno studio retrospettivo [30] della durata di 14 mesi (da gennaio 2015 a marzo 2016), rivolto a chi utilizzava

il portale da almeno 2 mesi. L’obiettivo di questo studio era: (1) determinare l’uso del portale da parte dei caregivers, (2) esaminare i livelli di utilit`a e soddisfazione del

portale stesso e dell’e-messaging e (3) accertare le percezioni da parte dei caregivers e dei fornitori del servizio, l’utilit`a del portale e come potrebbe essere migliorato. Sono

stati utilizzati 3 metodi per la raccolta dei dati: acquisizione delle informazione sul login, interviste e sondaggi. Mentre i caregivers hanno partecipato sia a interviste che

a sondaggi, i lavoratori solo ad interviste.

Il sondaggio [13] constava di 38 domande in 5 sezioni: (1) utilit`a / soddisfazione:

docu-mentazione sanitaria del cliente, (2) utilit`a / soddisfazione: messaggistica portale, (3) coinvolgimento nel processo di cura, (4) impatto della messaggistica del portale con i

fornitori di servizi (ad esempio, miglioramenti della comunicazione, capacit`a di espri-mere preoccupazioni e ottenere chiarimenti, fiducia o rapporti con il team del fornitore

clinico), e (5) generale (es. soddisfazione e utilit`a generale, intenzione futura di usare, impatto sulla cura). Le interviste invece sono state sia di gruppo, (durata media 48

minuti) che individuali (durata media 19 minuti).

Un totale di 18 caregivers (genitori) hanno completato l’indagine e 6 di loro hanno

par-tecipato anche ad interviste, inoltre sono stati intervistati anche 5 lavoratori. Sebbene il modo di utilizzo del portale sia molto variato, l’utilizzo tipico `e quello di 2,5 volte al

mese per una media di 9 mesi. Le pagine del portale pi`u frequentemente utilizzate sono la home page, la pagina principale dei record sanitari, la pagina degli appuntamenti

e la pagina dei referti. Pertanto, gli utenti erano pi`u interessati alla documentazione sanitaria, agli appuntamenti e alle relazioni dei loro figli, come `e stato segnalato da

altri [6].

Il coinvolgimento del paziente per mezzo del portale potrebbe prevenire eventi

indesi-derati durante la loro permanenza in ospedale [9]. Uno studio recente stima che oltre 440.000 persone muoiano ogni anno negli Stati Uniti a causa di errori medici

preve-nibili. A partire dal 2016, gli errori medici prevenibili sono considerati la terza causa di morte negli Stati Uniti, preceduta da malattie cardiache e cancro [26]. Le ricerche

condotte negli ultimi dieci anni suggeriscono che i pazienti forniscono una prospettiva distinta sugli eventi di sicurezza che non vengono rilevati dai rapporti del personale e

dalla revisione delle cartelle cliniche [33, 25]. Weissman e colleghi hanno esaminato la sovrapposizione tra gli eventi indesiderati quali cattiva gestione, comunicazione,

poli-tica e mancanza di coordinazione nella cura, segnalati dai pazienti e la revisione da parte del medico delle cartelle cliniche. Il loro lavoro ha mostrato che il 23% dei 998

pazienti sottoposti a campionamento ha segnalato almeno un evento avverso, rispetto all’11% dei casi identificati attraverso la cartella clinica. Pertanto, per avere una

visio-ne completa della sicurezza del paziente, `e necessario indagare sia dal punto di vista del paziente che del medico. Tuttavia, sappiamo poco su quali siano le esperienze e i

punti di vista dei pazienti in merito alla loro sicurezza o su come sviluppare soluzioni informatiche che supportino i pazienti nel loro importante ruolo di salvaguardia. In uno

studio [9] sono stati intervistati 68 pazienti pediatrici per conoscere la loro esperienza in merito ad eventi negativi durante un ricovero ed `e stato chiesto loro di scegliere da

una lista di 9 strumenti come preferissero ricevere le informazioni di cui hanno bisogno, l’85% preferirebbe riceverle attraverso strumenti non basati sulla tecnologia (fogli di

carta, parlando con medici e infermieri), mentre il 15% preferirebbe riceverle attraverso strumenti tecnologici (portali, messaggi di testo, email).

Al Children’s Hospital of Pittsburgh [46] sono state sviluppate 2 applicazioni per mobi-le denominate MyCHP e MyUPCM, entrambe scaricabili gratuitamente dallo store del

proprio cellulare. Le due applicazioni sono pressoch´e simili, la distinzione tra le due `e dovuta al fatto che fino al 2001 l’ospedale pediatrico (CHP) era separato da quello per

adulti (UPMC) e ancora oggi i due sistemi non sono integrati pienamente, e restano quindi, due identit`a distinte anche se oggigiorno rappresentano un’unica autorit`a. Con

MyCHP `e possibile:

• Gestire gli appuntamenti: visualizzare quelli futuri o richiederne uno nuovo; • Visualizzare lo stato di immunizzazione, le allergie e la storia clinica;

• Visualizzare i risultati del laboratorio di analisi e della radiologia;

• Visualizzare, scaricare e stampare riepiloghi, istruzioni e indicazioni post dimis-sione;

• Aggiornare le informazioni personali.

Questa applicazione `e accessibile sia al paziente stesso che ai genitori o tutori di pa-zienti trai 13 e i 17 anni, senza l’autorizzazione del paziente, mentre, se il paziente ha

pi`u di 18 anni `e indispensabile la sua autorizzazione per consentire l’accesso ai anche genitori o tutori. L’accesso avviene tramite un form di login inserendo un codice

se-greto consegnato personalmente in ospedale.

Altri ospedali dove sono state implementate app simili sono: il Children’s Hospital of

Michigan, in Michigan, Stati Uniti [41], il Royal Children’s Hospital, a Melbourne, in Australia [40], l’East Tennessee Children’s Hospital, in Tennessee, Stati Uniti [12], il

Nicklaus Children’s Hospital, Miami, Florida, Stati Uniti [15] e il Boston Children’s Hospital, Boston, Massachusetts, Stati Uniti [11], in quest’ultimo ospedale `e stata

ag-giunta anche la possibilit`a di verificare i pagamenti effettuati o da effettuare.

Al John Radcliffe Hospital [14] situato a Oxford, Regno Unito, a luglio 2018 `e stata

lanciata una applicazione per dispositivi mobili, denominata vCreate, che permette ai neo genitori di vedere i progressi del proprio figlio neonato tramite un video ricevuto

sul proprio smartphone anche al di fuori della struttura ospedaliera. Il filmato viene registrato dagli infermieri e inviato in modo sicuro ai genitori tramite l’app, da cui pu`o

essere scaricato.

Al Texas Children’s Hospital [16] in Texas, Stati Uniti, `e stata introdotta un’app

abilitata a ricevere aggiornamenti, in tempo reale, direttamente dalla sala operatoria durante un intervento chirurgico, tramite messaggi scritti da un infermiere. L’app `e

scaricabile tramite QR Code generato dagli operatori clinici e valido solo per il tempo dell’intervento e per quel paziente.

Un’app, invece, che si avvicina molto al progetto di questa tesi e da cui ha preso prin-cipalmente spunto, `e stata sviluppata dalla Epic, un’azienda di sviluppo software con

sede nel Wisconsin, Stati Uniti, nel 2016. Tra gennaio e giugno 2016 `e stato condotto uno studio trasversale [28] in una unit`a medico/chirurgica generale composta da 24

letti all’interno di un ospedale pediatrico che offre servizi di ospedalizzazione, cardio-logia, pneumocardio-logia, gastroenterocardio-logia, neurocardio-logia, chirurgia, traumatocardio-logia, ortopedia,

trapianto o riabilitazione. Lo studio consisteva nel fornire un tablet ai genitori di bambini fino a 12 anni (i bambini pi`u grandi vennero esclusi per motivi legali legati

all’accesso dei dati sanitari) fornito di una app da utilizzare durante l’ospedalizzazione del figlio/a. Sono stati esclusi i genitori non disponibili o i cui figli avevano un trauma

non accidentale e i bambini con un breve periodo di degenza. Questo portale includeva informazioni su parametri vitali in tempo reale, farmaci, programmi, risultati di

la-boratorio, educazione, immagini/ruolo del team sanitario e funzionalit`a messaggistica. La CCE fu implementata nell’ambulatorio dell’ospedale nel 2004 e nella

ospedalizza-zione nel 2008. L’app per il portale ambulatoriale (MyChart, Epic System) `e stata sviluppata nel 2009; il portale dell’ospedalizzazione (MyChart Bedside, Epic System)

`e stato implementato nel 2014. MyChart Bedside `e un’applicazione che permette ai pazienti e/o ai loro familiari di avere accesso in tempo reale alle informazione sul loro

stato di ricovero. In figura 1.1 sono descritte le funzionalit`a di base assieme alle per-sonalizzazioni specifiche dell’ospedale, comprese le aspettative sul tempo di risposta,

la frequenza del rilascio dei risultati di laboratorio, la guida per l’utente e le versioni elettroniche dei contenuti educativi precedentemente sviluppati all’interno dell’istituto.

I tablet forniti alle famiglia erano abilitati solo per la rete interna dell’ospedale. Le altre app installate non avevano accesso ad internet. Il tablet fu offerto a 329 genitori,

il 90% accett`o. Su 24 tablet nessuno venne rubato, perso o danneggiato. Le funziona-lit`a pi`u usate dall’utente erano la home page (con informazioni sui parametri vitali e

l’elenco dei farmaci), Taking care of me (immagini e ruoli del team sanitario), Happe-ning Soon (programma giornaliero) e My Health (risultati di laboratorio). I genitori

che compilarono il questionario di gradimento furono 99, di cui il 76% mamme di et`a tra 25 e 44 anni con vari livelli di istruzione. La maggior parte dei genitori intervistati

di questo gruppo era molto soddisfatto del portale e ha riferito che ha contribuito al miglioramento dell’assistenza ospedaliera dei propri figli. L’uso del portale ha avuto

un impatto minore sulla facilitazione della comunicazione, solo il 60% dei genitori ha infatti riferito di aver migliorato la comunicazione con l’infermiera o il medico del

pro-Figura 1.1: Schermata della home page del portale MyChart Bedside e la descrizione

delle funzionalit`a.

prio bambino. Nel complesso, i genitori hanno trovato il portale facile da usare, ci sono stati relativamente pochi problemi tecnici e nessun tablet `e stato perso o danneggiato.

Al contrario, uno studio recente sugli adulti ospedalizzati non ha riscontrato differenze tra l’ospedalizzazione con la possibilit`a di accedere ai propri dati tramite dispositivo

medico o senza [31]. La parte di messaggistica non ha riscontrato molto successo, i dati suggeriscono che il portale `e usato perlopi`u per individuare errori medici durante

l’ospedalizzazione del figlio. Ai genitori sono stati chiesti consigli su come migliorare il portale, le risposte esprimevano il desiderio di maggiori delucidazioni sulla diagnosi,

sui test e sui risultati, essere informati sul tracking del peso, dell’altezza e della circon-ferenza della testa.

L’anno successivo `e stato fatto un sondaggio per testare l’indice di gradimento di que-sta app da parte del team sanitario [10]. In tutto il personale sanitario, 686 membri

del personale hanno completato il questionario: 193 medici (23,6%), 439 infermie-ri (53,7%) e 186 tecnici di supporto (22,7%). Il 40-60% degli intervistati di ciascun

gruppo ha segnalato un orientamento positivo verso la tecnologia e l’addestramento ricevuto. Questo orientamento positivo era pi`u alto tra il personale di supporto,

infe-riore tra gli infermieri e pi`u basso ancora per i medici. I limiti di questo studio sono:

• L’applicazione ad un unico ospedale del Midwest; • Il non poter settare una lingua diversa dall’inglese;

• I risultati riguardano solo i genitori che hanno accettato il tablet e risposto al sondaggio.

Per quanto riguarda il territorio italiano va menzionata la Fondazione Monza e Brian-za per il bambino e la sua mamma di MonBrian-za che ha vinto il premio nella categoria

“Processi clinici e assistenziali” per il progetto di rilevazione dei parametri vitali dei neonati, di remotizzazione di allarmi e di condivisione dei dati tramite i dispositivi

mobili di cui `e dotato il personale medico e infermieristico del reparto di Terapia In-tensiva Neonatale. Il progetto, a regime da aprile 2017, `e stato reso possibile anche

grazie alla trasformazione del reparto neonatale da open space a una “single family room”, con l’obiettivo di favorire il contatto madre-neonato fin dai primi momenti di

vita. Tra i vantaggi del progetto, la garanzia che i dati del paziente vengano monitorati costantemente durante l’intero percorso clinico-sanitario, la possibilit`a di accedere ai

parametri di ogni paziente attraverso la centrale di monitoraggio, l’integrazione con la cartella informatica per la gestione dei dati clinici ed assistenziali, la remotizzazione

degli allarmi e delle comunicazioni su dispositivi mobili e la creazione di un ambiente pi`u confortevole per i famigliari del paziente [47].

Capitolo 2

Contesto

Figura 2.1: Logo FTGM.

Costituita dal Consiglio Nazionale delle

Ricerche e dalla Regione Toscana per la gestione finalizzata ad un ulteriore

svilup-po delle attivit`a sanitarie specialistiche e di ricerca di interesse del SSR toscano,

gi`a svolte dall’Istituto di Fisiologia Clini-ca CNR, la Fondazione costituisce un

en-te pubblico specialistico del Servizio Sa-nitario Regionale, ai sensi della Legge n.

85/2009.

Due sono le sedi delle attivit`a: lo

Stabili-mento ospedaliero di Pisa, presso l’Area della Ricerca CNR, e quello di Massa (Ospedale del Cuore ”G. Pasquinucci”, gi`a Ospedale Pediatrico Apuano), in localit`a Montepepe.

La Fondazione costituisce un centro di alta specialit`a per la cura delle patologie car-diopolmonari, comprese le patologie rare di interesse specifico, quali ad esempio le

cardiopatie congenite, le dislipidemie ereditarie, l’emocromatosi, l’ipertensione polmo-nare e l’amiloidosi.

La fondazione eroga in particolare prestazioni di:

• cardiologia neonatale, pediatrica e per adulti;

• emodinamica diagnostica ed interventistica neonatale e pediatrica (ambiti in cui costituisce centro di riferimento regionale);

• emodinamica diagnostica ed interventistica per adulti; • elettrofisiologia;

• cardiochirurgia neonatale e pediatrica (ambiti in cui costituisce il centro di rife-rimento regionale);

• cardiochirurgia per adulti;

• anestesia e terapia intensiva neonatale, pediatrica e per adulti; • pneumologia;

• endocrinologia e malattie del metabolismo;

• trattamento delle ipercolesterolemie (rispetto a cui `e centro di riferimento regio-nale);

• imaging diagnostico avanzato: radiodiagnostica, medicina nucleare, risonanza magnetica nucleare;

• medicina di laboratorio.

L’attivit`a assistenziale combina una impostazione specialistica a livello delle compe-tenze mediche e chirurgiche con una impostazione per intensit`a di cure a livello

or-ganizzativo, che si esplica in regime di degenza, ambulatoriale, di day hospital e day service.

Presso la Fondazione, il paziente `e al centro di un sistema multidisciplinare che offre i pi`u moderni ed appropriati percorsi preventivi, diagnostico-terapeutici e riabilitativi,

grazie all’alto profilo delle competenze disponibili, alla disponibilit`a delle tecnologie pi`u avanzate per la diagnostica funzionale, d’immagine e di laboratorio ed alla completa

informatizzazione delle attivit`a cliniche e di gestione.

La Fondazione, inoltre, svolge attivit`a di ricerca in ambito sanitario e delle tecnologie

applicate alla sanit`a, anche in collaborazione con Istituti del Consiglio Nazionale delle Ricerche - primo tra tutti l’Istituto di Fisiologia Clinica - le Universit`a, Scuole

Ogni articolazione operativa, dipartimento od unit`a operativa, svolge al contempo at-tivit`a sanitarie specialistiche ed attivit`a di ricerca ad esse correlate, traendo

dall’e-sperienza dell’attivit`a clinica spunti per l’investigazione di ricerca e, dai risultati dalla ricerca e dell’innovazione suggerimenti per il miglioramento della pratica clinica [43].

Capitolo 3

Risorse

In questo capitolo vengono illustrati gli strumenti hardware e software e le tecnologie

utilizzate per lo sviluppo dell’applicazione. La scelta, tra quelle possibili, si `e orientata verso strumenti gi`a largamente utilizzati all’interno della FTGM. La configurazione

adottata `e riportata di seguito:

• STRUMENTI PER LO SVILUPPO:

– PROCESSORE: Intel Core(TM) i5-7260U CPU @ 2.20GH ;

– SISTEMA OPERATIVO: Linux, Ubuntu;

– DATABASE: Oracle Database;

– CLIENT SQL: DBeaver ;

– IDE1_{: Eclipse;}

– FRAMEWORK: Google Web Toolkit.

• AMBIENTE DI UTILIZZO:

– BROWSER: Chrome, Firefox.

Di seguito questi strumenti verranno descritti nel dettaglio.

3.1

Linux

Figura 3.1: Logo Ubuntu.

Il sistema operativo Linux open source, o Linux OS, `e

un sistema operativo multipiattaforma basato su Unix. E’ rilasciato come free, ovvero, liberamente utilizzabile

da chiunque senza alcuna restrizione, in forma sorgente o compilata. Anche la distribuzione e la modifica dello

stesso non sono vincolate, sebbene in caso di modifiche all’originale ne debba essere sempre indicato l’autore.

Linux non `e solo un sistema operativo ma anche un modo di concepire la programmazione e lo sviluppo del software. In questo ambiente,

`e pi`u corretto usare il termine distribuzioni piuttosto che versioni. Una distribuzione software del sistema operativo GNU/Linux, `e realizzata a partire dal kernel Linux, un

sistema di base GNU e solitamente anche da diversi altri applicativi (talvolta anch’essi parte di GNU) si possono identificare perci`o distribuzioni specifiche per un

determi-nato contesto: ad esempio ambienti grafici pi`u semplici oppure pi`u performanti. Tali distribuzioni appartengono quindi alla sotto-famiglia dei sistemi operativi GNU e, pi`u

in generale, alla famiglia dei sistemi Unix-like, perch´e ispirati a Unix e in certa misu-ra compatibili con esso. Le distribuzioni pi`u note sono: Linux Mint, elementary OS,

Ubuntu, Debian. Quella utilizzata da questo elaborato `e Ubuntu 18.04 LTS. [53, 54, 34]

3.2

Database Oracle

Figura 3.2: Logo Oracle.

Oracle Database `e uno tra i pi`u utilizzati database management system (DBMS), cio`e sistema di gestione

di basi di dati, scritto in linguaggio C. Fa parte dei RDBMS (Relational DataBase Management System)

ovvero, di sistemi di database basati sul Modello rela-zionale, che si `e affermato come lo standard dei

data-base. La societ`a informatica che lo ha sviluppato, la Oracle Corporation `e stata fondata nel 1977 da

impor-tante azionista), Bob Miner e Ed Oates, con sede centrale in California. La prima versione di Oracle Database disponibile pubblicamente risale al 1979. Da allora `e stato

sempre aggiornato per seguire gli sviluppi tecnologici, fino ad arrivare alla versione attuale 12c R2.

Oracle `e organizzato logicamente in tablespace. Tale struttura `e realizzata, fisicamente, sotto forma di file (datafile). Un tablespace pu`o essere formato da uno o pi`u

datafi-le, che a sua volta composto da vari tipi di segment. Ognuno di questi a sua volta si suddivide in uno o pi`u extent. Ogni extent comprende gruppi contigui di blocchi

di dati (data block). Questi ultimi sono la pi`u piccola informazione memorizzabile da Oracle. A livello fisico, i file comprendono almeno due o pi`u extent. Fino alla

versione 8i la dimensione del blocco di dati era stabilita alla creazione del database e non poteva pi`u essere modificata. A partire dalla versione 9i in poi i blocchi di dati

possono essere di dimensione variabile, sebbene ogni tablespace debba necessariamente essere costituito da datafile aventi la stessa dimensione di blocco dati. Oracle tiene

traccia dei dati memorizzati tramite l’ausilio di informazioni presenti nelle tabelle di sistema, contenenti il dizionario dei dati e se presenti indici e cluster, che assicurano la

consistenza dei dati applicativi. Il dizionario dati consiste in una collezione di tabelle in sola lettura che contengono informazioni riguardo a tutti gli oggetti del database.

Tra le varie potenzialit`a possiamo citare le stored procedure e le funzioni. Con l’ausilio del PL/SQL, un’estensione procedurale del linguaggio SQL, sviluppato da Oracle, si

possono sviluppare funzioni, procedure, trigger e package. Oracle `e un RDBMS che se configurato e gestito in maniera appropriata, garantisce una sicurezza dei dati molto

elevata. Attivando la modalit`a detta archiving (o archivelog mode) `e eseguito un bac-kup di tutte le transazioni che avvengono nel DB e che dovranno essere utilizzati in

caso di DB recovery dovuta a crash totale o parziale del sistema. In questa modalit`a `e possibile sfruttare l’hot backup (backup a caldo) ossia il salvataggio dei dati a sistema

acceso senza arrestare il DBMS. Esistono diverse modalit`a per il backup a caldo. Quella standard Oracle `e denominata RMAN ossia Recovery Manager. L’amministratore del

DB pu`o comunque gestire il backup/restore delle istanze Oracle2 _{in maniera manuale} o automatica tramite scripting [57].

2_{Insieme delle aree di memoria e dei processi di background necessari ad accedere ai dati, ovvero} al DB.

3.3

DBeaver

Figura 3.3: Logo DBeaver.

Nato nel 2010 per hobby, DBeaver `e un client SQL e

uno strumento di amministrazione di database proget-tato per gestire diverse tipologie di DBMS. Si tratta di

un’applicazione che per operare richiede esclusivamen-te un’installazione aggiornata di Java ed `e compatibile

con tutte le piattaforme operative pi`u diffuse (Linux, Mac OS X e Windows).

Tra i Database Manager supportati vi sono MySQL, MSSQL, Oracle, IBM DB2, SQLite, Sybase, Firebird,

cio`e tutti gli engine pi`u diffusi per l’archiviazione dei dati.

L’architettura si basa sui plugin di Eclipse e consente agli utenti di sviluppare appli-cazioni dotate di funzionalit`a specifiche del database o funzionalit`a indipendenti dal

database. L’edizione community (CE) di DBeaver `e un software gratuito e open source distribuito con la licenza Apache. Esiste anche un’edizione commerciale di DBeaver

distribuita sotto una licenza commerciale. Tra le funzionalit`a disponibili si segnalano [56]:

• gestione di connessioni multiple;

• amministrazione delle utenze e dei diversi livelli di accesso ai dati;

• features per la manipolazione di indici, colonne, campi, records e metadata; • possibilit`a di realizzare diagrammi basati sul modello entit`a-relazione per la

progettazione degli archivi;

• supporto per il tunnelling SSH3_.

3_{Con l’acronimo SSH (Secure SHel), ci si riferisce ad un protocollo di rete che consente di collegarsi} ad un computer remoto in sicurezza, tramite un’interfaccia testuale a linea di comando.

3.4

Eclipse

Figura 3.4: Logo Eclipse.

Eclipse `e un ambiente di sviluppo integrato

multi-linguaggio e multipiattaforma. Ideato da un consor-zio di grandi societ`a quali Ericsson, HP, IBM, Intel,

MontaVista Software, QNX, SAP e Serena Software, chiamato Eclipse Foundation.

Eclipse `e un software libero distribuito sotto i termini della Eclipse Public License. Eclipse pu`o essere utilizzato per la produzione di software

di varia tipologia, si passa infatti da un completo IDE per il linguaggio Java (JDT, “Java Development Tools”) a un ambiente di sviluppo per il linguaggio C++ (CDT,

“C/C++ Development Tools”) e a plug-in che permettono di gestire XML, JavaScript, PHP e persino di progettare graficamente una GUI per un’applicazione JAVA (Window

Builder), rendendo di fatto Eclipse un ambiente RAD4. Questo programma `e scritto in linguaggio Java, ma anzich´e basare la sua GUI su Swing, il toolkit grafico di Sun

Microsystems, si appoggia a SWT, librerie di nuova concezione che conferiscono ad Eclipse un’elevata reattivit`a. La piattaforma di sviluppo `e incentrata sull’uso di

plug-in, cio`e componenti software ideate per uno specifico scopo, per esempio la generazione di diagrammi UML, ed in effetti tutta la piattaforma `e composta da plug-in, versione

base compresa, e chiunque pu`o sviluppare e modificare i vari plug-in. Nella versione base `e possibile programmare in Java, usufruendo di utili funzioni di aiuto quali:

com-pletamento automatico (“Code completion”), suggerimento dei tipi di parametri dei metodi e riscrittura automatica del codice (funzionalit`a questa detta di Refactoring)

per una variazione delle classi. Essendo scritto in Java, Eclipse `e disponibile per le piattaforme Linux, HP-UX, AIX, macOS e Windows. La Eclipse Foundation `e una

or-ganizzazione attualmente non-profit fondata nel 2001 da societ`a come Borland, IBM, Red Hat e SUSE, ed altre. Nel corso degli anni altri colossi industriali hanno deciso di

partecipare al progetto come ad esempio HP e Fujitsu.

3.5

Google Web Toolkit

Figura 3.5: Logo Eclipse.

Google Web Toolkit (GWT) `e un toolkit di

svilup-po per la creazione e l’ottimizzazione di applicazioni complesse basate su browser. Il suo obiettivo `e quello

di consentire lo sviluppo di applicazioni web ad alte prestazioni senza che lo sviluppatore debba essere un

profondo conoscitore di browser, XML, HttpRequest5 e JavaScript. `E open source, completamente gratuito e

utilizzato da migliaia di sviluppatori in tutto il mondo. Lo scambio di dati tra client e server `e sviluppata con

AJAX, acronimo di Asynchronous JavaScript and XML. Lo sviluppo di applicazioni HTML con AJAX si basa su uno scambio di dati in background fra web browser e

server, che consente l’aggiornamento dinamico di una pagina web senza esplicito ricari-camento da parte dell’utente. AJAX `e asincrono nel senso che i dati extra sono richiesti

al server e caricati in background senza interferire con il comportamento della pagina esistente. Normalmente le funzioni richiamate sono scritte con il linguaggio JavaScript.

Tuttavia, e a dispetto del nome, l’uso di JavaScript e di XML non `e obbligatorio, come non `e detto che le richieste di caricamento debbano essere necessariamente asincrone

[55]. Le applicazioni AJAX, d’altra parte, possono inviare richieste al web server per ottenere solo i dati che sono necessari (generalmente usando SOAP6 _{e JavaScript per} visualizzare la risposta del server nel browser). Come risultato si ottengono applica-zioni pi`u veloci (dato che la quantit`a di dati interscambiati fra il browser ed il server

si riduce). Anche il tempo di elaborazione da parte del web server si riduce poich´e la maggior parte dei dati della richiesta sono gi`a stati elaborati. Un esempio concreto: la

scelta di un nuovo nickname in fase di creazione di un account su un sito web, nel caso classico, se il nome che abbiamo scelto fosse gi`a esistente, dovremmo compilare prima

tutto il modulo ed accorgerci solo dopo aver atteso il caricamento della pagina di con-ferma che il nome `e gi`a esistente e dobbiamo cambiarlo, invece con AJAX pu`o essere

introdotto un controllo sull’evento onChange o OnKeyUp della casella di testo che pu`o informare tempestivamente che il nome inserito non `e valido, magari evidenziando il

5_{Trasferire dati da e verso un server attraverso il protocollo HTTP.} 6_{Protocollo per lo scambio di messaggi tra componenti software.}

testo (CSS + JavaScript). Il vantaggio di usare AJAX `e la grande velocit`a alla qua-le un’applicazione risponde agli input dell’utente. Da sottolineare che qua-le applicazioni

AJAX possono rendere inutilizzabile il tasto “indietro” del browser: con questo tipo di applicazioni, infatti, non si naviga da una pagina all’altra, ma si aggiorna di volta

in volta una singola parte del medesimo documento. Proprio per questo i browser, che sono orientati alla pagina, non hanno possibilit`a di risalire ad alcuna di tali versioni

“intermedie”.

Lo sviluppo di Web app compatibili con pi`u browser pu`o essere un processo lungo e

soggetto a errori. Si pu`o dedicare il 90% del tempo di sviluppo a risolvere i problemi re-lativi browser. Inoltre, la creazione, il riutilizzo e il mantenimento di un grande numero

di script JavaScript e componenti AJAX pu`o risultare difficile e ’fragile’. GWT sem-plifica questo onere consentendo agli sviluppatori di creare e mantenere rapidamente

applicazioni front-end JavaScript complesse ma altamente performanti nel linguaggio di programmazione Java. Uno dei pacchetti ivi contenuti `e GWT SDK, che permette

di scrivere il front-end AJAX nel linguaggio di programmazione Java che GWT esegue e poi, successivamente, cross-compila in JavaScript ottimizzato ed eseguibile su tutti i

principali browser. E’ anche possibile cambiare e interagire con JavaScript direttamen-te nel codice sorgendirettamen-te. Durandirettamen-te lo sviluppo, mediandirettamen-te le impostazioni per sviluppatori

del browser, `e possibile modificare direttamente il codice in JavaScript ed eseguire il debug entrambi dal browser. Quando lo sviluppo `e ultimato, GWT compila il codice

sorgente Java in file JavaScript autonomi e ottimizzati pronti per la distribuzione. GWT `e in grado di gestire tutte le comunicazioni ed i dettagli client-server in AJAX,

in modo indipendente dal formato dei dati di interscambio ad es. JSON, XML, o RPC (Remote Procedure Call ) ottimizzato da GWT[8].

Capitolo 4

Progetto prototipo

In questo capitolo saranno presentati gli aspetti progettuali ed implementativi

riguar-danti lo sviluppo dell’applicazione web realizzata. L’attivit`a ha messo in opera le tec-nologie e gli strumenti discussi nei capitoli precedenti ed ha previsto le fasi di analisi

dei requisiti, progettazione e implementazione.

4.1

Analisi dello scenario

Prima di procedere con una descrizione dettagliata di quelle che sono state le scelte

effettuate, `e conveniente analizzare il contesto in cui il progetto andr`a ad inserirsi. L’applicazione web realizzata in questo progetto `e dedicata ai pazienti della terapia

in-tensiva pediatrica dell’ospedale del Cuore “Gaetano Pasquinucci” di Massa. Secondo le ultime rilevazioni, il 12% dei reparti di terapia intensiva pediatrica non pone restrizioni

nelle 24 ore alla presenza dei genitori; il 59%, invece, non permette la presenza costante di un genitore nemmeno nelle ore diurne; 5 le ore di visita in media al giorno; ai

geni-tori `e consentito rimanere accanto al figlio/a durante manovre ordinarie di nursing nel 62% dei reparti, durante manovre invasive nel 3% e durante manovre di rianimazione

cardio-polmonare nel 9% [39]. Si `e quindi progettato un sistema in grado di fornire un’interfaccia tra un qualsiasi dispositivo capace di connettersi alla rete Internet

tra-mite browser ed un portale di servizi online che permetta ai genitori dei pazienti della Fondazione Toscana Gabriele Monasterio di consultare alcune informazioni relative al

4.1.1

Questionario

Per avere un feedback dai genitori che si sono trovati in questa situazione, `e stata con-tattata l’associazione di Promozione Sociale Fight The Stroke, costituita formalmente

nel 2014 con gli obiettivi di [51]:

• Rispondere alla necessit`a di conoscenza delle famiglie impattate dalla gestione di un sopravvissuto da Ictus;

• Educare alla consapevolezza che i bambini, anche quelli non ancora nati, possono essere colpiti dall’Ictus;

• Ispirare le nuove generazioni e favorire la ricerca e l’adozione di terapie ‘disrup-tive’.

L’associazione `e rappresentata da: Francesca Fedeli in qualit`a di Presidente e

Co-Fondatrice, Mario D’Angelo in qualit`a di Presidente Onorario e Roberto D’Angelo in qualit`a di CEO e Co-Fondatore. E’ stato chiesto loro di diffondere tramite i loro

asso-ciati, rappresentati da famiglie che hanno avuto figli in cura per l’ictus, un questionario anonimo, prodotto da noi, per comprendere meglio le loro esigenze.

Nel questionario, sviluppato con la funzionalit`a di Google Moduli, e distribuito tramite link, sono state proposte alcune funzionalit`a da inserire successivamente nella

applica-zione. Per ognuna di queste, veniva chiesto di esprimere un parere riguardo all’interesse che poteva riscuotere, in base all’esperienza del partecipante, selezionando una

valuta-zione da 1 (poco interessante) a 5 (molto interessante). Le domande erano dieci, nove a risposta multipla e una a risposta libera. A rispondere sono stati in totale 30 persone,

di cui 10 hanno risposto anche alla domanda aperta, non obbligatoria. Nella tabella 4.1 vengono riportate le nove domande a risposta multipla in ordine di gradimento, da

Domanda Punteggio medio

Saresti interessato a vedere i risultati degli esami di laboratorio e

referti (es. ecografia, TAC, risonanza magnetica)? 4,88

Ti piacerebbe sapere nome e ruolo del team medico che si sta

occupando di tuo/a figlio/a? 4,75

Ti piacerebbe avere il programma delle visite, in modo da sapere

sempre dov’`e tuo/a figlio/a?

4,58

Ti piacerebbe avere informazioni relative al reparto e all’ospedale (es.

numero di telefono, orario di presenza del medico)? 4,54

Ti piacerebbe avere delle informazioni su come affrontare al meglio

l’ospedalizzazione (es. l’importanza di lavarsi le mani, il significato dei suoni di dispositivi medici)?

4,46

Ti piacerebbe avere informazioni da parte del medico su un eventuale

cambio terapia? 4,42

Saresti interessato a vedere la terapia farmacologica corrente? 4,37

Ti piacerebbe prendere appuntamento con il medico direttamente da

dispositivo?

3,96

Saresti interessato a vedere i parametri vitali di tuo/a figlio/a in tem-po reale (es. battito cardiaco, frequenza respiratoria, temperatura,

pressione)?

3,96

Tabella 4.1: Risultati questionario: domande a risposta multipla, ordinate per gradimento, e relativo punteggio medio ottenuto.

La domanda aperta, facoltativa, era la seguente:

Hai qualche suggerimento? Qualsiasi consiglio, anche se all’apparenza banale, ha

molta importanza per noi!

A questa domanda hanno risposto 10 persone nel seguente modo:

• La possibilit`a di avere anche la presenza dell’altro genitore;

• Il primo giorno di terapia intensiva l’infermiera intensivista di mio figlio si pre-sent`o e poi mi disse “il bambino `e suo, i monitor sono miei”. L’unica chance di

Figura 4.1: Risultati questionario: grafico a barre del punteggio medio ottenuto da ciascuna domanda a risposta multipla.

rimanere sani di mente in TIP1 _{`e cercare di NON guardare i monitor (tanto c’`e} chi li guarda per noi) quindi decisamente mi sembrerebbe deleterio per la salute

mentale di chiunque avere una APP che li riproduce sul cellulare. Per quanto riguarda i rapporti con il medico, ogni TIP che si rispetti fornisce i numeri di

contatto e nominativi e orari dei medici. Invece avrei apprezzato molto poter leggere il diario medico e infermieristico giorno per giorno. grazie;

• Sono tutte informazioni interessanti per un genitore, ma mi chiedo se siano ef-fettivamente utili. E’ utile per un genitore che `e appena uscito dall’ospedale dopo

averci passato 12 ore sapere che suo figlio sta avendo una desaturazione? io credo che sia sempre necessario un filtro, i genitori vanno tutelati anche restituendogli le

informazioni utili e necessarie. Noi siamo stati ricoverati in due diverse TIN2_{, la} prima dovrebbe sprofondare su se stessa, la seconda `e il Bambin Ges`u. Tutto

fun-zionava correttamente e avevamo accesso alle informazioni quando ne avevamo bisogno con il filtro dei dottori. mi rendo conto che nella societ`a dell’ipercontrollo

un sistema del genere sarebbe molto interessante, ma credo sia necessario anche comprendere quando le informazioni, se non comprese e gestite correttamente,

possano essere deleterie;

• Supporto ai genitori che spesso manca; 1_{Terapia Intensiva Pediatrica}

• Sono passati 8 anni quasi 9 e spero molte cose siano cambiate. Nessuno mi ha detto che potevo toccare mio figlio. Era molto grave in fin di vita e io sfioravo

il vetro con timore... se l’avessi toccato e coccolato sicuramente l’avrei aiutato. Noi genitori che arriviamo in quella miriade di suoni fastidiosi, persone che ti

guardano senza sapere chi siano, ti studiano, camici bianchi intorno a te senza avere certezze. A me sono passati dei passaggi fondamentali! Parlare con genitori

che avevano gi`a avuto quell’esperienza mi sarebbe stato sicuramente utile!! La possibilit`a di fare foto, l’esigenza di scrivere un diario con sensazioni da poter

rileggere dopo anni... brutti momenti da ricordare;

• Salve, ho trascorso 4 mesi in una semintensiva con la mia bimba, nonostante ringrazi tutto il team ´e una sola la cosa che migliorerei ad esempio: aumentare il personale nei reparti per agevolare gli infermieri e il personale a fare il loro

lavoro nel massimo della sicurezza e della pulizia, cosicch´e non vi siano errori(ad esempio non accorgersi per un’intera mattinata che la cvc3 <sub>si `e rotta e il bimbo in</sub> incubatrice `e completamente zuppo e freddo, che pulendo le incubatrici con i bimbi non si dimentichino batuffoli di cotone inzuppati di alcool, che si dimentichino di

sostituire i contenitori che raccolgono bile al fine di quantizzarla o ancora che in una stanza con sei/otto bambini siano sempre presenti due o tre infermieri per

garantire la sicurezza dei bimbi in qualsiasi malaugurato inconveniente )e questo tutto a causa della mancanza di personale. I genitori hanno bisogno del contatto

diretto per avere le informazioni, l’applicazione la creerei anche per il personale medico per mettere in rete tutto ci`o che si `e fatto e che non si `e riusciti a fare

un’applicazione che segnali a tutto lo staff se un bambino necessita di qualche cura o se qualcosa ´e stato dimenticato, soprattutto in quei casi i bimbi sono talmente

piccoli da non potersi esprimere da soli;

• Prevedere un luogo dove riposare per i genitori o per chi va ad assistere il bambino. In tin agli ospedali civili di Brescia ad esempio ho sempre ricevuto puntualmente tutte le info e ho sempre parlato con i medici quotidianamente, ma ci si sente

“In prestito”, non si sa dove stare, non si pu`o sempre uscire perch´e tutte le volte che si rientra si portano dentro batteri, ma dentro non c’`e posto per aspettare il 3_{Catetere Venoso Centrale.}

momento di poter rientrare in stanza con il proprio bimbo quando ti fanno uscire per visite, controlli, etc... Poi sarebbe utile poter parlare con qualcuno che ti

indirizzi dopo, una volta fuori, verso l’associazione che ti possa aiutare in base alla patologia del tuo bimbo, perch´e dentro sei “protetto”, ti senti al sicuro, fuori

invece ti senti perso. Grazie;

• Inserire riferimenti di associazioni o professionisti che possano dare un supporto psicologico alle famiglie;

• La nostra esperienza in terapia intensiva `e stata molto positiva. A Treviso Ria-nimazione centrale ci `e stato possibile stare sempre con Pietro, mettendoci a disposizione anche una cambretta per appoggio. Direi che l’eccellenza si trova

anche senza andare troppo lontano;

• No alla musica della radio di continuo come sottofondo e i continui beep tra allarme delle varie apparecchiature.

I risultati del questionario sono stati incoraggianti, infatti, anche i genitori pi`u scettici

hanno comunque manifestato il loro interesse verso almeno un men`u. In seguito alle risposte ricevute si `e pensato di modificare le seguenti informazioni in base all’interesse

manifestato:

• Escludere la visualizzazione dei parametri in tempo reale e mantenere soltanto quelli inseriti manualmente dal team clinico nella propria CCE;

• Escludere la possibilit`a di prendere appuntamento col medico direttamente da dispositivo;

• Escludere la possibilit`a di essere informati su un eventuale cambio terapia; • Inserire un men`u dove poter venir a conoscenza di associazioni per il supporto

familiare;

• Inserire un men`u dove poter prendere visione dei diari clinici di medici e infer-mieri.

4.2

Architettura

Il progetto, sviluppato con Eclipse, prevedeva una rapida configurazione che consisteva

in due passaggi: (1) installazione su Eclipse del plugin di GWT e (2) impostazione degli SDK (contengono le librerie e il compilatore) scaricabili dal web, in particolare

la versione di SDK utilizzata per l’applicazione `e la 2.8.2. Il web server utilizzato `e Jetty, che fa anche da contenitore di servlet4_{. Sviluppato da Eclipse, Jetty `e un} progetto gratuito e open source che fornisce tutti i servizi del protocollo HTTP che sono necessari ad una applicazione Java per operare.

4.2.1

Windget

Gli elementi dell’interfaccia grafica utente (es. bottoni, pannelli, immagini), chiamati windget, sono stati sviluppati da GWT Material Design [38]. Creato e progettato da

Google, Material Design `e un linguaggio di progettazione che combina i principi clas-sici del design di successo con l’innovazione e la tecnologia. L’obiettivo di Google `e

sviluppare un sistema di progettazione che consenta un’esperienza utente unificata su tutti i loro prodotti su qualsiasi piattaforma. I windget sono stati scaricati tramite file

Jar5, inglobati nel progetto e successivamente personalizzati.

I windget possono essere utilizzati in due modi, o dinamicamente in una classe Java o

staticamente in un file con estensione XML6 legato ad una classe Java. Ad esempio co-struiamo il bottone di figura 4.2 prima dinamicamente e successivamente staticamente.

DINAMICO:

i m p o r t gwt . m a t e r i a l . d e s i g n . c l i e n t . ui . M a t e r i a l B u t t o n ;

i m p o r t gwt . m a t e r i a l . d e s i g n . c l i e n t . c o n s t a n t s . B u t t o n T y p e ;

4_{I servlet sono oggetti scritti in linguaggio Java che operano all’interno di un server web (es.} Tomcat, Jetty) oppure un server per applicazioni (es. WildFly, GlassFish) permettendo la creazione di applicazione web (elaborazione lato server).

5_{Un file con estensione JAR (Java Archive) indica un archivio dati compresso (ZIP) usato per} distribuire raccolte di classi Java. Tali file sono concettualmente e praticamente assimilabili a package, e quindi talvolta associabili al concetto di libreria.

6_{sigla di eXtensible Markup Language, `e un metalinguaggio per la definizione di linguaggi di} markup, ovvero un linguaggio marcatore basato su un meccanismo sintattico che consente di definire e controllare il significato degli elementi contenuti in un documento o in un testo.

Figura 4.2: Bottone di prova. i m p o r t gwt . m a t e r i a l . d e s i g n . c l i e n t . c o n s t a n t s . C o l o r ; M a t e r i a l B u t t o n btn = new M a t e r i a l B u t t o n () ; // c r e a z i o n e o g g e t t o btn. s e t T y p e ( B u t t o n T y p e .O U T L I N E D) ; // b o t t o n e d e l i n e a t o btn. s e t T e x t C o l o r ( C o l o r .B L U E) ; // t e s t o di c o l o r e blu btn. s e t T e x t (" P R O V A ") ; STATICO:

E’ necessario definire un file con estensione .ui.xml ad esempio prova.ui.xml. Per legarlo alla classe Java, all’interno della classe stessa dove va inserito:

i m p o r t com . g o o g l e . gwt . u s e r . c l i e n t . ui . C o m p o s i t e ; i m p o r t com . g o o g l e . gwt . u i b i n d e r . c l i e n t . U i B i n d e r ; i m p o r t com . g o o g l e . gwt . u s e r . c l i e n t . ui . W i d g e t ; i m p o r t com . g o o g l e . gwt . c o r e . c l i e n t . GWT ; p u b l i c c l a s s C l a s s e J a v a e x t e n d s C o m p o s i t e { p r i v a t e s t a t i c p r o v a X m l V i e w U I B i n d e r u i B i n d e r = GWT . c r e a t e ( p r o v a X m l V i e w U I B i n d e r .c l a s s) ; i n t e r f a c e p r o v a X m l V i e w U I B i n d e r e x t e n d s U i B i n d e r < Widget , p r o v a X m l > { } p u b l i c C l a s s e J a v a () { // c o s t r u t t o r e i n i t W i d g e t (u i B i n d e r. c r e a t e A n d B i n d U i (t h i s) ) ; } }

E quindi nel file prova.ui.xml andr`a inserito:

< m : M a t e r i a l B u t t o n t e x t=" P R O V A " t y p e=" O U T L I N E D " t e x t C o l o r=" B L U E "

Nell’applicazione sviluppata sono stati utilizzati entrambi i metodi a seconda del-l’esigenza. E’ stato privilegiato l’uso statico di pi`u immediata comprensione ma non

sempre `e stato possibile utilizzarlo, ad esempio nel caso in cui i windget dovevano esse-re cesse-reati dinamicamente in funzione dei dati, andava utilizzata la definizione dinamica

degli elementi. Nel seguente esempio vengono creati un numero di elementi uguale alla dimensione dell’arrayList aL:

for ( int i = 0; i < aL . s i z e () ; i ++ ) {

M a t e r i a l B u t t o n btn = new M a t e r i a l B u t t o n () ; }

4.2.2

Connessione al DB

Tra i molteplici metodi di comunicazione tra client e server, discussi al capitolo

pre-cedente, `e stato scelto il framework di GWT RPC (Remote Procedure Call ). RPC di GWT semplifica la condivisione di oggetti Java su HTTP tra applicazione web client

e web server. Il codice lato server, invocato dal client, viene spesso definito servizio. L’implementazione di un servizio RPC GWT si basa sulla architettura servlet Java.

All’interno del codice client, `e utilizzata una classe proxy7 generata automaticamente per effettuare chiamate al servizio. GWT gestir`a la serializzazione degli oggetti Java in

entrambe le direzioni, quindi sia gli argomenti del metodo della chiamata sia il valore restituito. Gli elementi coinvolti nel processo sono:

• Il servizio eseguito sul server (il metodo invocato); • Il codice lato client che invoca il servizio;

• Gli oggetti trasmessi.

La capacit`a di serializzazione sia del client, sia del server consente lo scambio delle

in-formazioni in forma testuale. La creazione di un’interfaccia RPC prevede la definizione dei seguenti elementi:

7_{Una classe proxy `e una classe che implementa una lista di interfacce specificate runtime in modo} tale che una chiamata ad un metodo attraverso una delle interfacce su un’istanza della classe venga codificata e inviata ad un altro oggetto tramite un’interfaccia uniforme.

1. Un’interfaccia per il servizio che estenda l’interfaccia RemoteService e riporti tutti i metodi RPC (lato client). Ad esempio immaginiamo di voler creare un servizio

che data una stringa in input restituisca un intero, l’interfaccia in questione sar`a cos`ı definita:

i m p o r t com . g o o g l e . gwt . u s e r . c l i e n t . rpc . R e m o t e S e r v i c e ;

i m p o r t com . g o o g l e . gwt . u s e r . c l i e n t . rpc . R e m o t e S e r v i c e R e l a t i v e P a t h ;

@ R e m o t e S e r v i c e R e l a t i v e P a t h (" d b _ s e r v i c e ") // a s s o c i a il s e r v i z i o ad un p e r c o r s o di d e f a u l t r e l a t i v o all ’ URL del

m o d u l o

p u b l i c i n t e r f a c e D b S e r v i c e e x t e n d s R e m o t e S e r v i c e {

int n o m e M e t o d o ( S t r i n g i n p u t ) ; }

2. Una classe che estenda la classe RemoteServiceServlet e implementi l’interfaccia creata al punto precedente (lato server). Da notare che lato server il codice non

viene tradotto in JavaScript, linguaggio lato client e quindi andr`a messo in un package diverso. Riprendendo l’esempio precedente la classe sar`a cos`ı definta:

i m p o r t com . g o o g l e . gwt . u s e r . s e r v e r . rpc . R e m o t e S e r v i c e S e r v l e t ; p u b l i c c l a s s D b S e r v i c e I m p l e x t e n d s R e m o t e S e r v i c e S e r v l e t i m p l e m e n t s D b S e r v i c e { p u b l i c int n o m e M e t o d o ( S t r i n g i n p u t ) { int r e s u l t = ... // T O D O r e t u r n r e s u l t; }

3. Un’interfaccia asincrona per invocare il servizio dal client (lato client). Ripren-dendo ancora una volta l’esempio precedente l’interfaccia sar`a cos`ı esplicitata:

i m p o r t com . g o o g l e . gwt . u s e r . c l i e n t . rpc . A s y n c C a l l b a c k ;

p u b l i c i n t e r f a c e D b S e r v i c e A s y n c {

v o i d n o m e M e t o d o ( S t r i n g input , A s y n c C a l l b a c k <int> c a l l b a c k ) ;

Successivamente alla definizione di questi tre elementi, per utilizzare il servizio sar`a sufficiente creare un oggetto dell’interfaccia asincrona (creata nel precedente punto 3),

da utilizzare per richiamare il metodo di interesse e implementare i metodi onSuccess e onFailure necessari a gestire, rispettivamente, l’avvenuta connessione col server o il

fallimento di questa: i m p o r t m y P a c k a g e . c l i e n t . D b S e r v i c e A s y n c ; i m p o r t com . g o o g l e . gwt . c o r e . c l i e n t . GWT ; p r i v a t e D b S e r v i c e A s y n c d b S e r v i c e; d b S e r v i c e = GWT . c r e a t e ( D b S e r v i c e .c l a s s) ; p r i v a t e v o i d m e t o d o () {

d b S e r v i c e. n o m e M e t o d o ( input , new A s y n c C a l l b a c k <int>() {

@ O v e r r i d e p u b l i c v o i d o n S u c c e s s (int r e s u l t) { // c o n n e s s i o n e s t a b i l i t a } @ O v e r r i d e p u b l i c v o i d o n F a i l u r e ( T h r o w a b l e c a u g h t ) { // c o n n e s s i o n e f a l l i t a } }) ; }

Sfruttando il codice appena descritto ed ulteriori metodi gi`a definiti all’interno della

FTGM ‘e stato possibile interfacciarsi al database tramite sql standard.

4.3

Progettazione e sviluppo

Questo paragrafo entrer`a nel dettaglio del progetto. Si esporr`a contemporaneamente

sia la progettazione che lo sviluppo dal momento che le due fasi sono spesso perfezionate in parallelo. Accade infatti, che lo sviluppo metta in luce problematiche o modalit`a che

la progettazione non aveva preso in considerazione risultando quindi in una modifica del progetto iniziale.

All’interno di alcuni ospedali `e presente una stanza chiamata “Family Room” in cui i genitori possono soggiornare giorno e notte insieme al proprio neonato. Pensata in

particolare per i neonati ricoverati a lungo, come nelle gravi prematurit`a, al fine di rafforzare il nucleo familiare nella gestione del neonato prima della dimissione. In tale

area i genitori si prendono cura del neonato in prima persona, come accadr`a dopo la dimissione, con la supervisione del personale medico ed infermieristico del reparto.

Ispirata a questo concetto, l’applicazione `e stata denominata Family Room. Si propone di essere di supporto negli ospedali dove tale concetto `e presente e di virtualizzarlo dove

non `e ancora presente.

4.3.1

Login

L’autenticazione del genitore `e stato un passaggio critico. Si doveva garantire la

riser-vatezza dei dati senza complicare troppo il processo stesso. Infatti nel caso in cui fosse stato di difficile compimento o se avesse coinvolto pi`u persone sarebbe stato di difficile

diffusione.

La prima idea `e stata quella di far generare dall’infermiera un QR Code8 <sub>dalla propria</sub> cartella informatizzata (cartella gi`a in uso in reparto), mediante un bottone apposi-tamente creato. Successivamente, il genitore, inquadrando il QR Code dal proprio

smartphone avrebbe potuto scaricare l’applicazione contente gi`a i dati di proprio figlio. Il QR Code avrebbe dovuto contenere informazioni relative al paziente ed un codice

univoco auto generato dal server e salvato su di esso. Integrare nel QR Code anche il codice univoco evitava di poter generare un QR Code al di fuori della cartella clinica

e quindi impedire ad estranei, in possesso delle informazioni del paziente, di poter sca-ricare l’applicazione e leggere informazioni riservate. La chiave univoca sarebbe stata

l’ora del server, in millisecondi, in cui veniva premuto il pulsante per generare il QR Code. Tuttavia, questa soluzione `e stata abbandonata per i seguenti motivi:

1. Sarebbe stato necessario modificare la cartella clinica gi`a in uso per aggiungere il pulsante generatore;

2. Il personale infermieristico andava formato su questa nuova funzione;

8_{Codice a barre bidimensionale, ossia a matrice, composto da moduli neri disposti all’interno di} uno schema bianco di forma quadrata. In un solo crittogramma possono essere contenuti fino a 7.089 caratteri numerici o 4.296 alfanumerici. Il nome ”QR” `e l’abbreviazione dell’inglese Quick Response (”risposta rapida”), in virt`u del fatto che il codice fu sviluppato per permettere una rapida decodifica del suo contenuto.

3. L’infermiere, o chi per lui, avrebbe dovuto assumersi la responsabilit`a dell’aver generato il codice e quindi di aver identificato correttamente i genitori;

4. L’infermiere che non ha effettuato il logout, lascia incustodita la postazione e di conseguenza il pulsante generatore;

5. I genitori potevano temere che il sistema fosse poco sicuro dal momento che a loro non veniva chiesta nessuna conferma.

Queste problematiche vennero superate con la successiva proposta, risultata poi essere quella finale. Si basa sull’adozione di due fattori indipendenti, ovvero qualcosa che

l’utente conosce e qualcosa che l’utente possiede:

• credenziali univoche (codice fiscale e password);

• un dispositivo fisico associato univocamente al soggetto (telefono cellulare). Infatti per accedere `e sufficiente che il genitore conosca il codice fiscale del figlio e abbia fornito all’ospedale il numero di cellulare corretto durante la fase standard di

accettazione. Non `e quindi richiesto nessun intervento da parte del personale clinico. Vediamo ora nel dettaglio questo procedimento. Verr`a analizzata prima la parte client

(browser) e poi quella lato server (Database).

Lato Client

All’avvio dell’applicazione, al genitore sar`a richiesto di inserire il codice fiscale del figlio.

Al primo accesso per quel ricovero, verr`a inviato un SMS al numero che egli stesso ha fornito all’ospedale, contenente la password da inserire successivamente. Negli accessi

seguenti il genitore, essendo gi`a a conoscenza della password, potr`a inserirla senza l’invio di alcun messaggio. Se codice fiscale e password inseriti sono corretti allora il

genitore pu`o accedere ai dati del proprio figlio. In futuro, come ulteriore misura di sicurezza, potrebbe essere implementata la funzionalit`a di inviare un SMS al genitore

ad ogni accesso, in modo da tenere una maggiore tracciabilit`a degli accessi. Di seguito le schermate di quanto appena descritto:

1. Ad ogni nuovo accesso viene chiesto di inserire il codice fiscale del paziente;

Figura 4.3: Schermata di login: inserimento del codice fiscale del paziente e successiva

2. Se `e il primo accesso per quel ricovero viene chiesta la conferma per l’invio di un sms, al numero fornito all’ospedale, visibile in chiaro prima della conferma e

che fornir`a la password da inserire successivamente. Se non `e il primo accesso si passa direttamente alla fase del punto 4.

3. Entro il tempo massimo di 1 minuto l’sms viene ricevuto.

4. Il campo dove poter inserire la password, appena ricevuta per messaggio o gi`a nota, diventa visibile. Nel primo caso appare un toast9 <sub>avvisando che l’invio del</sub> messaggio `e andato a buon fine. Se l’utente non `e pi`u in possesso della password pu`o cliccare sul men`u “ho dimenticato la password” indicato dalla freccia rossa

in figura 4.6.

Figura 4.6: Schermata di login: inserimento della password o richiesta di riceverne una nuova.

5. Se l’utente clicca su “ho dimenticato la password” appare un popup con un bottone per l’invio di un messaggio con la nuova password.

Figura 4.7: Schermata di login: conferma invio della nuova password.

Lato Server

Sul database, per il login, sono state aggiunte allo schema gi`a esistente per la CCE della FTGM, una vista ed una tabella, chiamate rispettivamente V FR e T FR. La tabella

T FR `e legata con una relazione “uno a molti” alla tabella chiamata T ENCOUNTER (figura 4.8) appartenente allo schema della CCE della FTGM. La tabella T ENCOUNTER

contiene informazioni relative al ricovero, la sua chiave primaria `e il codice univoco che identifica ogni ricovero (T ENCOUNTER OID ).

Le colonne di T FR sono:

Figura 4.8: Relazione tra T ENCOUNTER e T FR.

• CODFISCALE : codice fiscale del paziente;

• T ENCOUNTER OID : chiave esterna rappresentata da un codice univoco che identifica il singolo ricovero della CCE della FTGM;

• T FR PASSWORD : codice alfanumerico che rappresenta la password criptata per l’accesso a Family Room;

• T FR STATO : codice rappresentato dal carattere ’A’ quando il login `e attivo, cio`e i campi codice fiscale e password sono utilizzabili, ’Z’ quando il login non `e pi`u attivo;

• TELEFONO : chiave esterna, rappresenta il numero di telefono del genitore del paziente.

La vista V FR `e definita per contenere informazioni sui ricoveri in stato aperto, ovvero di pazienti non ancora dimessi, a cui sia associato un numero di telefono. Quindi,

ricoveri di pazienti dimessi o che non abbiano un numero di telefono associato non verranno visualizzati nella vista. Le colonne di V FR sono le seguenti:

• T ENCOUNTER OID : codice univoco che identifica un ricovero; • CODFISCALE : codice fiscale del paziente;

• TELEFONO : numero di telefono del genitore del paziente;

• T IDENTITA OID : codice univoco che identifica un singolo paziente; • DTRICOV : data di inizio ricovero.

Quando l’utente, dopo aver inserito il codice fiscale, clicca su “conferma” nel form di login, il browser invia al server il codice fiscale. Il server controlla in T FR se