Piattaforme Cloud per servizi di Smart Health

Transcript

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in RETI DI CALCOLATORI
Piattaforme Cloud per servizi di Smart
Health
Anno Accademico 2013/2014
Relatore
Prof. Antonio Pescape’
Candidato:
Maurizio Sepe
matr. N46000531
“C’è un progresso solo quando i vantaggi di una nuova tecnologia diventano per tutti” Henry Ford.
INDICE
Introduzione
5
CAPITOLO 1 : SMART HEALTH
1.1 : Concetto di “Smart Health”
6
6
CAPITOLO 2 : CLOUD COMPUTING
2.1 : Modelli di servizio
2.1.1 : Software as a Service
2.1.2 : Platform as a Service
2.1.3 : Infrastructure as a Service
2.2 : Modelli di distribuzione
2.2.1 : Public cloud
2.2.2 : Private cloud
2.2.3 : Hybrid cloud
7
8
8
9
10
10
11
11
11
CAPITOLO 3 : PIATTAFORME CLOUD PER SERVIZI SMART HEALTH
3.1 : Progetto CHISTAR
3.1.1 : Motivazioni all’approccio cloud
3.1.2 : Architettura progetto CHISTAR
3.1.3 : Benefici del Cloud in ambito “Smart Health”
3.2 : Mobile e Cloud a servizio di “Smart Health”
3.2.1 : Architettura del mobile cloud
3.2.2 : Cloud mobile e “Smart Health”
3.3 : Sicurezza Cloud per “Smart Health”
3.3.1 : Semplice modello di E-Health Cloud
3.3.2 : Modello avanzato di E-Health Cloud
3.3.3 : Problemi dell’E-Health Cloud
3.3.3.1 : Data storage and Processing
3.3.3.2 : Management of E-Health Infrastructure
3.3.3.3 : Usability and User Experience
3.3.4 : Secure Infrastructure E-Health
3.3.4.1 : Domini privati in ambito E-Health
3.3.4.2 : Trusted Virtual Domain
3.3.4.3 : Client Platform
3.3.4.4 : Sviluppi futuri
12
12
13
14
17
17
18
18
20
20
21
22
22
23
23
24
24
25
26
27
CAPITOLO 4 : CASO DI STUDIO
4.1 : Smart Health 2.0
4.2 : Ambito applicativo
4.3 : Ambito sperimentale
4.4 : Ambito infrastrutturale
4.4.1 : OR1 – piattaforma abilitante
4.4.1.1 : Analisi dello stato d’arte
3
29
29
31
31
31
32
35
4.4.1.2 : Analisi dei requisiti
4.4.1.3 : Definizione dell’architettura
4.4.1.4 : Realizzazione del modello IaaS
4.4.1.5 : Realizzazione del livello PaaS ed integrazione con IaaS
4.4.1.6 : Sviluppo di modelli di sicurezza per la piattaforma
4.4.1.7 : Soluzioni per il Massive Parallel Processing (MPP)
4.4.1.8 : Test della piattaforma
35
35
36
36
37
37
38
Conclusioni
39
Ringraziamenti
40
Bibliografia
41
4
INTRODUZIONE
2050. Una data lontana, ma sorprendentemente vicina. Il giro di boa del primo secolo del nuovo
millennio che ci porterà a domandare come saremo in quel periodo. Qualche certezza già esiste e
fra le tante, la principale è che la popolazione mondiale dovrebbe toccare i 9 miliardi di individui,
con il circa 70% concentrata nei centri urbani.
Il problema è che le città oggi sono tutt’altro che virtuose,e i cittadini che attualmente vivono in un
contesto urbano consumano circa il 75% dell’energia planetaria. Da questi pochi dati numerici, è
facile intuire come la qualità della vita di miliardi di persone se non addirittura la sopravvivenza
stessa del pianeta, dipenderanno da quanto gli agglomerati urbani sapranno risparmiare
energia,ridurre emissioni e rendere più agevoli e semplici le condizioni di vita dei cittadini
migliorando la qualità dei servizi forniti. Per tali motivi diventa quasi obbligata la trasformazione
delle attuali città nelle note “Smart City”: vale a dire centri urbani intelligenti, dove grazie alla
tecnologia è possibile migliorare la vita del singolo cittadino con servizi più efficienti e accessibili,
nonché tentare di migliorare la situazione già precarie dell’intero pianeta.
Con questo obiettivo diverse amministrazioni in tutto il mondo, in partnership con grandi aziende,
università e centri di ricerca, hanno avviato progetti sperimentali: dalla sostenibilità ambientale, al
risparmio e all’efficienza energetica, ai trasporti intelligenti alle moderne infrastrutture per la
comunicazione fino ad arrivare al miglioramento dei servizi offerti ai cittadini. In particolare
l’Unione Europea con l’iniziativa “EU Smart City” ,ha stanziato 11 miliardi di euro per finanziare
progetti atti all’introduzione di elementi “Smart” nelle città del vecchio continente.[12]
Lo scopo di questa Tesi è quella di introdurre e approfondire uno degli aspetti principali che
derivano dal concetto più ampio di “Smart City”,cioè quello di “Smart Health”. Mi soffermerò
principalmente sulle piattaforme cloud a servizio dei vari progetti che come compito principale
hanno il miglioramento, attraverso la tecnologia, delle attività sanitarie a favore dei cittadini. In
particolare nei primi due capitoli introdurrò i concetti di “Smart Health” e Cloud Computing.
Successivamente andrò a introdurre piattaforme basate sull’utilizzo del cloud a favore dei servizi
“Smart Health”, per poi concludere il tutto soffermandomi su un progetto nato dalla collaborazione
delle varie regioni del sud Italia : “Smart Health 2.0”.
5
CAPITOLO 1 : SMART HEALTH
Il seguente capitolo seppur breve servirà ad introdurre il concetto di “Smart Health”, indicando
quelli che sono gli aspetti fondamentali , le innovazioni e gli obiettivi da perseguire nell’ambito
sanitario.
1.1 : CONCETTO DI “SMART HEALTH”
Con “Smart Health” indichiamo tutti quei progetti di innovazione e ricerca che nascono dalle analisi
delle problematiche sociali legate all’abbandono ,all’assenza di cure tempestive e per tutti quei
soggetti soli, deboli ed ammalati. Obiettivo quindi è di creare un’infrastruttura tecnologica in grado
di integrare le diverse strutture eroganti di servizi sanitari al cittadino/paziente, condividendo tutte
le informazioni Clinico – Sanitarie su un “Fascicolo Elettronico” ,nel quale è possibile reperire i dati
dei pazienti, il tutto conforme alle leggi vigenti in fatto di tutela dei dati personali. Su questa base si
tenderà a sviluppare diversi servizi, anche su supporto mobile, con l’obiettivo di migliorare la
capacità di controllo delle patologie,riducendo cosi la frequenza di ricoveri in ambiente ospedaliero,
l’ospedalizzazione forzata,il ricorso ai servizi di pronto intervento non motivati, la durata delle
assenze lavorative e di migliorare l’integrazione tra strutture territoriali e strutture ospedaliere,
riducendo cosi i costi dell’assistenza sanitaria.
Per quanto concerne l’architettura “Smart Health”, la gestione dei dati clinici è possibile senza la
necessità di ricorrere all’uso di complesse infrastrutture tecnologiche: l’accesso da parte degli
operatori sanitari o dello stesso paziente avviene attraverso internet. Naturalmente avremo la
sincronizzazione dei dati con server e nodi sia del sistema pubblico sia dei privati. Quindi utilizzando
semplici browser e menu intuitivi i pazienti e gli operatori sanitari possono accedere in maniera
riservata ai dati di loro interesse.
In particolare l’applicazione dell’informatica alla sanità è sempre più importante in molti paesi negli
ultimi anni, portando cosi a numerosi sforzi in ambito di normalizzazione nazionale ed
internazionale per l’interoperabilità e lo scambio di dati. Sono molti gli scenari applicativi in ambito
di sanità elettronica (E-Health) che oltre al “Fascicolo Elettronico”, avremo la contabilità e la
fatturazione, la ricerca medica e la negoziazione di proprietà intellettuali. Dal punto di vista
puramente economico con “Smart Health” andiamo a ridurre drasticamente i costi del settore
sanitario andando ad eliminare ad esempio diagnosi doppie costose o somministrazione di farmaci
ripetitiva fino ad arrivare ai numerosi acquisti di materiale cartaceo per il “salvataggio” delle
informazioni dei pazienti.[11]
6
CAPITOLO 2 : CLOUD COMPUTING
L’espressione Cloud Computing oggi è senza dubbio di moda nel mondo dell’informatica.
Nonostante il gran parlare che se ne fa, pochi riescono a darne una definizione precisa e a volte
persino gli addetti ai lavori non sanno esattamente di cosa si tratta. Per poter definire cos’è il Cloud
Computing è opportuno esaminare prima l’origine di questo termine : cloud fa riferimento
all’immagine più utilizzata per rappresentare internet nei diagrammi di rete, una nuvola. Ma Cloud
Computing non è ovviamente sinonimo di Internet, anche se coinvolge in maniera diretta la rete.
Con l’espressione di Cloud Computing si fa riferimento ad una modalità di elaborazione basata su
internet in cui le risorse vengono distribuite. L’idea dunque è semplice: demandare a qualcun altro
il compito di gestire l’infrastruttura informatica,abbattendo la spesa necessaria per la gestione
interna come l’Hardware o le licenze Software fino ad arrivare alla manutenzione. Non solo esistono
vari modi di utilizzare il cloud,ma sono anche molteplici le architetture che rientrano nella
definizione di Cloud Computing. Molto spesso quando si parla di Cloud Computing si fa riferimento
anche ad un altro termine : “virtualizzazione hardware”. Tale termine fa riferimento alla possibilità
di sfruttare le risorse di un computer per creare una o più macchine virtuali in grado di simulare
l’Hardware fisico di un pc. La” virtualizzazione hardware” viene oggi sfruttata molto intensamente
per il consolidamento di più server su un’unica macchina fisica e proprio per questo motivo è molto
importante per Cloud Computing. Per poter valutare correttamente la possibilità di migrare
un’applicazione o un server nel cloud è ovviamente fondamentale avere ben chiari i vantaggi e gli
svantaggi di una scelta simile. Tra i vantaggi abbiamo che l’adozione di un’architettura basata sul
cloud può consentire un risparmio significativo sull’Hardware, soprattutto per quel che riguarda le
applicazioni su lato server. Il risparmio a livello Hardware non si limita poi al server e
all’infrastruttura di storage (memorizzazione): con un approccio basato su cloud su può risparmiare
anche sui dispositivi di rete. Anche i costi legati alla gestione preventiva delle situazioni di
emergenza possono essere drasticamente ridotti: si può evitare di portare quotidianamente un
backup dei dati a casa in quanto i dati in un sistema cloud si trovano già per definizione off-site.
L’uso di una soluzione cloud è comodissimo per tutte le aziende che devono mettere a disposizione
alcuni servizi a chi lavora da casa o fuori ufficio. Infine tra i tanti vantaggi abbiamo anche quello
della scalabilità: per le aziende che sporadicamente hanno l’esigenza di disporre di una notevole
potenza di calcolo per un periodo limitato si tratta di una soluzione eccellente. Purtroppo l’adozione
di un sistema cloud non ha solo vantaggi, ma presenta anche aspetti negativi: il principale è legato
alla connettività, mentre un secondo problema è quello della sicurezza dei dati. Per i dati di
particolare criticità è bene studiare con cura l’approccio da adottare (una soluzione è quella del
Hybrid Cloud).[9]
7
2.1 : MODELLI DI SERVIZIO
Il modo più semplice per spostare un elemento dell’infrastruttura informatica di un’azienda nel
cloud è ovviamente isolarlo e trasformarlo in un servizio per il quale è disponibile un fornitore. Il
servizio in questione potrebbe essere semplicemente un componente software o persino un intero
ambiente di lavoro. Con l’espressione “as a service” (letteralmente “come servizio”) preceduta
dall’iniziale del servizio fornito si formano alcuni acronimi più utilizzati in ambito cloud. Per
identificare tutte le possibili varianti si usa in modo generico la sigla XaaS con X considerata appunto
come variabile [10]. Tra i vari modelli di servizio abbiamo:

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)
2.1.1 : SOFTWARE AS A SERVICE
L’architettura Software as a Service prevede la fornitura di applicazioni specifiche ed è senza dubbio
una delle più conosciute e discusse. Questa architettura può essere adottata dal produttore del
software, per fornire direttamente il suo prodotto. In ogni caso è sempre chi eroga il servizio ad
occuparsi di gestire gli aggiornamenti e di effettuare la manutenzione del Software,con tutti gli
oneri che questo comporta.
I vantaggi possono essere considerevoli, soprattutto per alcune tipologie di Software. I costi sono
strettamente legati all’utilizzo e perciò possono crescere progressivamente, senza richiedere un
forte investimento iniziale. Ci sono indubbi vantaggi anche per il produttore del Software, dal
momento che questo modello di business riduce il rischio di pirateria: tutto resta infatti sui suoi
server.
8
2.1.2 : PLATFORM AS A SERVICE
Il modello Platform as a Service prevede che il fornitore metta a disposizione una piattaforma di
sviluppo completa di tutte le risorse necessarie a creare applicazioni e servizi. Un’offerta PaaS
comprende dunque tutto quello che serve per il design dell’applicazione. In questo caso aumenta
ovviamente in modo considerevole la dipendenza nei confronti del fornitore ed è difficile trovare
soluzioni che permettono di mantenere un buon livello di indipendenza. La soluzione PaaS è quella
che presenta più rischi per l’utilizzatore. La migrazione da un provider ad un altro potrebbe essere
molto oneroso e se chi dovesse erogare il servizio dovesse cessare l’attività, l’impatto sulle attività
dell’utilizzatore potrebbero essere devastanti.
9
2.1.3: INFRASTRUCTURE AS A SERVICE
L’idea di base del modello Infrastructure as a Service è semplice. Non si parla più della fornitura di
un Software o di una piattaforma, ma di una o più macchine (fisiche o virtuali) a disposizione del
cliente che potrà utilizzarle e controllarle da remoto in base alle esigenze.
In genere il fornitore del servizio offre non solo l’Hardware dei/o del server, ma anche la licenza del
sistema operativo e tutto il sistema di virtualizzazione necessario.
2.2 : MODELLI DI DISTRIBUZIONE
Gli scenari possibili con il Cloud Computing sono diversi. Un’azienda può decidere in che modo
distribuire le informazioni sul cloud. Tra le varie distribuzioni abbiamo:

Public Cloud

Private Cloud

Hybrid Cloud
10
2.2.1 : PUBLIC CLOUD
Quando l’infrastruttura si trova completamente online allora vengono identificate con il termine di
Public Cloud. Tra i benefici di questo modello abbiamo l’abbattimento dei costi per l’investimento
iniziale e una distribuzione in genere molto più veloce e con maggiore scalabilità. Tuttavia tale
approccio presenta un problema di sicurezza e privacy dei dati, in quanto l’utente finale perde il
controllo degli stessi affidandoli a terze parti per la gestione.
2.2.2 : PRIVATE CLOUD
Quando l’infrastruttura si trova invece completamente in locale si parla di Private Cloud, cioè vi è un
uso esclusivo di una singola organizzazione che comprende più consumatori. Il vantaggio
nell’utilizzo di tale modello riguarda principalmente la sicurezza e riservatezza poiché solamente gli
utenti dell’organizzazione possono accedere al cloud privato.
2.2.3 : HYBRID CLOUD
Il cloud ibrido è costituito da due o più cloud privati o pubblici per offrire i vantaggi di entrambi i
modelli, restando però entità uniche dove ognuna mantiene la propria identità. In tale modello di
distribuzione l’organizzazione gestisce risorse interne ed altre fornite esternamente. Questo perché
generalmente un’azienda può eseguire un’applicazione inizialmente su un cloud privato e affidarsi
ad un cloud pubblico durante i picchi di utilizzo.
11
CAPITOLO 3 : PIATTAFORME CLOUD PER SERVIZI SMART HEALTH
Dopo aver analizzato quelle che sono le caratteristiche salienti del Cloud computing e cosa voglia
significare “Smart Health”, in questo terzo capitolo farò un analisi di come questi due elementi
possano cooperare tra loro a beneficio dei servizi sanitari.
3.1 : PROGETTO CHISTAR
In questo sezione del capitolo presenterò una piattaforma cloud per servizi “Smart Health” ideata
da Arshdeep Bahga e Vijay K. Madisetti. [3]
Come sappiamo il processo di sanità comporta un insieme massiccio di dati che possono essere di
tipi differenti e collocati in luoghi differenti. Per questo motivo con l’avanzamento tecnologico si è
ricorso all’utilizzo di EHR (Cartella clinica Elettronica) che vengono memorizzati in appositi sistemi
EHR. I medici se vogliono accedere ai dati del paziente,condividere informazioni con altri medici e
diagnosticare malattie devono solo accedervi. In questo scenario è possibile utilizzare ambienti di
Cloud Computing.
Con il cloud pubblico gli enti ospedalieri non hanno più bisogno di spendere una parte del loro
badget per le infrastrutture atte a contenere le informazioni. Cosi gli ospedali basandosi su sistemi
EHR su cloud pubblico , possono salvare il capitale da investimenti Hardware e per infrastrutture di
Data Center e pagare solo le spese operative delle risorse cloud utilizzate. Gli ospedali condividono
12
le informazioni dei pazienti con altri enti sanitari per le diagnosi in remoto delle malattie o gli stessi
pazienti possono gestire le loro prescrizioni e fornire ad esempio queste informazioni alle farmacie
di fiducia.
Il progetto CHISTAR [3] che analizzerò ha come compito quello di apportare i miglioramenti offerti
dal Cloud Computing ai sistemi di gestione di EHR. Nei paragrafi successivi analizzerò quelle che
sono le motivazioni che hanno spinto i due ricercatori all’utilizzo del cloud per sistemi EHR,
l’architettura del progetto e i suoi benefici.
3.1.1 : MOTIVAZIONI ALL’APPROCCIO CLOUD
Le principali motivazioni che hanno spinto i due ricercatori all’approccio cloud per sistemi EHR sono
i seguenti :

Metodologie progettuali : i sistemi EHR tradizionali sono stati realizzati sulla base di una delle
tre metodologie seguenti
o Approccio non strutturato : questo approccio consiste nella non strutturazione dei
dati.
o Approccio Big Model : tale approccio prevede la strutturazione dei dati, in
particolare avremo una tabella separata per ogni caso clinico portando ad un gran
numero di tabelle.
o Approccio generico : tale approccio permette una grande varietà di dati da
memorizzare in strutture di dati generici,in cui vige il vincolo che tali dati devono
essere validi in ambito clinico.
CHISTAR segue un approccio generico avendo dati strutturati e un modello definiti per i dati
clinici.

Dati interoperabili : i sistemi EHR tradizionali usano norme diverse e spesso contrastanti
tecniche e semantiche che portano a problemi di integrazione dei dati e alla
interoperabilità. Infatti i sistemi tradizionali EHR sono basati su standard differenti, su
diverse lingue e diverse generazioni tecnologiche portando conseguentemente alla
frammentazione.

Scalabilità e prestazioni : nei sistemi tradizionali EHR questi erano basati su un approccio
client-server . I dati vengono salvati su server e sono accessibili all’interno della rete
aziendale dai soli client autorizzati. Questo approccio comunque richiede un Hardware
aggiuntivo.
13
3.1.2 : ARCHITETTURA PROGETTO CHISTAR
L’architettura proposta dai due ricercatori è schematizzata nella figura successiva:
Lo strato Infrastructure Services è costituito dalle istanza cloud ( load balancers – bilanciatori di
carico,web server, application server, …) su cui CHISTAR viene distribuito; uno strato di Information
Services che consiste in una integrazione di dati provenienti da molteplici fonti disparate; uno strato
di Application Services in cui sono forniti vari servizi come quelli EHR , demografico ,terminologico e
infine abbiamo uno strato di Presentation Services formato da applicazioni di tipo sanitario (sia Web
che mobile).
I principi di progettazione fondamentali del progetto CHISTAR cono i seguenti:

Interoperabilità semantica : è definita come la capacità di condividere, interpretare e fare un
uso efficace delle informazioni scambiate. CHISTAR utilizza approccio di modellazione a due
livelli che separa i dati dalla conoscenza clinica.
14
L’approccio dei sistemi EHR è modellata come due livelli e consistono in un modello di Data
Storage e un modello di archetipo. Il modello di Data Storage definisce entità per il Data
Storage stesso e rappresenta la semantica di memorizzazione dei dati. Il modello di
archetipo rappresenta una struttura di domini a livelli e vincoli sui generici dati strutturati
definiti nel modello Data Storage. L’approccio di modellazione a due livelli fa si che il sistema
sia più robusto e il Software non deve essere cambiato ogni volta che c’è un cambiamento
nella conoscenza clinica. CHISTAR espande il concetto di archetipo che conterrà : una
sezione di intestazione che includerà i metadati dell’archetipo,una sezione di definizione che
contiene il caso clinico modellato e una sezione di ontologia che descrive le entità definite
nella sezione di definizione. Gli archetipi sono separati dai dati e memorizzati in un archivio
distaccato e vengono distribuiti a runtime. Il vantaggio nella suddivisione dei modelli e negli
archetipi sono : facilitano la convalida dei dati al momento dell’immissione per garantire la
conformità dei dati stessi e facilitano la ricerca delle informazioni.

Integrazione dei dati : i dati di tipo sanitario esistono in diverse forme o in differenti sistemi
di memorizzazione come database relazionali (MYSQL, ORACLE, ecc…), server di file (
testo,vido ,audio, ecc …) e in sistemi EHR standard. La trattazione sul come i ricercatori
hanno ideato l’integrazione esula dall’argomento di questa tesi, ma per ulteriori
informazioni riporto nella bibliografia il testo originale da dove ho prelevato tutte le
informazioni [3]. Lo schema seguente presenta l’approccio proposto dai ricercatori per
l’integrazione dei dati :
15

Componenti base dell’architettura : CHISTAR adotta vari elementi cloud, classificati in base
alle funzioni e al tipo di risorse utilizzate. Ogni blocco dell’architettura cloud esegue una
serie di azione per conseguire i risultati desiderati fornendoli ad altri componenti. Lo schema
del modello cloud di CHISTAR viene presentato come una tabella in cui le colonne
rappresentano varie funzioni dell’applicazioni e le righe rappresentano le risorse cloud.
I blocchi nella figura mostrano specifiche funzioni individuali dei vari componenti
dell’applicazione. Ogni componente del cloud è caratterizzata dalla funzione svolta e dal tipo
di risorse cloud necessarie. Ogni componente prende un ingresso specifico, esegue una serie
di azioni predefinite e produce i risultati desiderati. I componenti del cloud sono tra di loro
liberamente connessi cioè : elementi debolmente accoppiati comunicano attraverso
messaggi asincroni. Il beneficio dell’accoppiamento lasco per le applicazioni EHR è quello
che se un componente riceve e processa richieste più veloce di altri, il buffer di richieste,
utilizzando una coda di messaggi,contribuirà a rendere il sistema nel suo complesso più
resistente ai picchi di traffico.
16
3.1.3 : BENEFICI DEL CLOUD IN AMBITO “SMART HEALTH”
Nel concludere la trattazione del progetto CHISTAR , elencherò quelli che sono i vantaggi
dell’utilizzare il cloud in ambito “Smart Health” evidenziati dai due ricercatori :

Interoperabilità : CHISTAR ha una migliore interoperabilità rispetto ai sistemi basati su EHR
client-server. Per conseguire tale obiettivo, il motore di integrazione di CHISTAR consente di
integrare dati provenienti da diverse fonti e archiviandole nel cloud.

Scalabilità : CHISTAR adotta l’approccio a componenti che fornisce uno migliore scalabilità
grazie al disaccoppiamento e alla comunicazione asincrona. Poiché i vari componenti sono
progettati per elaborare richieste in modo asincrono è possibile parallelizzare il processo
delle richieste.

Manutenibilità : CHISTAR ha una migliore manutenibilità rispetto a sistemi client-server. La
funzionalità dei singoli componenti CHISTAR può essere migliorata o aggiornata
indipendentemente dagli altri componenti , inoltre l’accoppiamento lasco permette la
sostituizione o l’aggiornamento dei componenti senza doverne cambiare necessariamente
altri rendendo CHISTAR più resistente ai guasti.

Portabilità : sistemi come CHISTAR hanno una migliore portabilità. Avendo un
accoppiamento lasco e comunicazione asincrona, i singoli componenti possono trovarsi su
infrastruttura cloud differenti di diversi fornitori.

Riduzione dei costi : i sistemi client-server richiedono un apposito team di esperti per
installare , configurare,testare e aggiornare sia l’Hardware che il Software. Con il cloud,
come nel caso di CHISTAR, le organizzazioni sanitarie possono risparmiare sulla spesa
dell’Hardware e limitarsi a pagare per l’utilizzo del solo Software.
3.2 : MOBILE E CLOUD A SERVIZIO DI “SMART HEALTH”
Il cloud grazie alle grandi capacità di immagazzinamento, alla potenza di calcolo e ai suoi costi ridotti
diventa ogni giorno sempre più popolare. In particolare,con l’utilizzo di attuali dispositivi mobile
(smartphone,tablet…) è possibile avere accesso al cloud, in quanto abbiamo già una infrastruttura di
rete disponibile che non richiede una infrastruttura fisica a supporto. In questo ambito gli stessi
operatori telefonici offrono ai propri clienti servizi interni a basso costo e di facile comprensione
(GUI semplici). Una cloud mobile da una soluzione alla organizzazione abbattendo le barriere dello
spazio e riducendo i tempi di esecuzione incidendo sull’abbassamento dei costi di investimento
17
nonché risparmio di tempo. La distribuzione di applicazioni cloud mobile è facile e veloce : anche in
un solo minuto un utente può distribuire ed iniziare ad usare applicazioni di cloud mobile [2].
3.2.1 : ARCHITETTURA DEL MOBILE CLOUD
In una architettura cloud per cellulare da una parte vi è il dispositivo mobile con diversi operatori di
rete e dall’altra vi è il cloud. In particolare nel cloud vi è l’infrastruttura fisica usata per la
memorizzazione di dati,esecuzione di servizi e di sicurezza con protocolli di autenticazione. Dal
punto di vista del Software fornito, questi sono semplici applicazioni installate sui dispositivi mobile
e pronti all’uso. La piattaforma a supporto del cloud mobile deve prevedere la costruzione, il
collaudo e la distribuzione di applicazioni personalizzate. Da non dimenticare che Internet è la spina
dorsale di Cloud Computing su mobile, utilizzando la rete cellulare messa a disposizione dai vari
operatori telefonici. Ogni cellulare o altro dispositivo mobile è collegato alla rete dell’operatore per
trasmettere e ricevere dati. Un utente mobile può muoversi in qualsiasi momento senza ottenere
cambianti della rete o del dispositivo mobile stesso.
3.2.2 : CLOUD MOBILE IN SERVIZI “SMART HEALTH”
Per migliorare l’attuale modello di sanità esistente, possiamo utilizzare il cloud. Il suo utilizzo
prevede la memorizzazione dei dati in appositi infrastrutture fisiche, mentre ad ogni dispositivo o
utente collegato si assegna uno specifico link per accedere a tali informazioni. Ricordiamo che non
solo il dispositivo mobile può collegarsi al cloud, ma abbiamo tutta una serie di dispositivi che
permettono di monitorare i parametri del paziente in ambito sanitario (pressione sanguigna,
zucchero, peso, ecc…) che possono essere inviati direttamente nel cloud e acceduti dai dispositivi
mobile che prevedono l’utilizzo di un’applicazione apposita. Tale applicazione si sincronizza con i
vari gadget che ad intervalli di tempo predefiniti raccoglie i dati del relativo paziente. Questo rende
possibile che ospedali, medici , farmacisti e ambulanze con l’uso di dispositivi mobile siano collegati
al server centrale contente i dati. In questo modo abbiamo che dopo ogni intervallo di tempo,
dove vi è la sincronizzazione dei dati tra dispositivo mobile e server nel cloud, possiamo avere alert
tempestivi per quando riguarda un paziente e sulla base delle informazioni stesse capire che tipo di
servizio sanitario è il più adatto.
18
Numerosi sono i vantaggi utilizzando i dispositivi mobile in ambito “Smart Health” :

Diagnosi più dettagliate : grazie alla rete più medici possono analizzare i paramentri di un
paziente andando a valutare ogni punto di vista possibile.

Servizio alternativo di medicina : è possibile valutare in rete la disponibilità di un dato
medicinale e suggerire al paziente con discussione online la miglior cura.

Monitoraggio : grazie alla rete cellulare e ai dispositivi mobile i medici possono controllare
pazienti critici indipendentemente da dove si trovano.

Gestione delle informazioni : ogni aggiornamento di informazioni relative ai pazienti consiste
in una sincronizzazione tra il server e il dispositivo mobile non richiedendo aggiornamenti
manuali.

Robustezza ai fallimenti : se ad esempio il terminale di utilizzo di una data ambulanza non
funziona più, i dati non vanno persi perché una rapida sincronizzazione con il cloud
permetterà di recuperare i dati.
Nell’ambito del cloud mobile per servizi “Smart Health” non ci sono solo vantaggi, ma sono presenti
tutta una serie di parametri che necessitano di miglioramento al fine di garantire un miglior servizio
sanitario :

Durata della batteria : è il peggior nemico nell’utilizzo di dispositivi mobile.

Capacità di memorizzazione dei dati.

Disponibilità della rete : è un parametro fondamentale per l’utilizzo di tali servizi, in quanto
senza l’intera infrastruttura risulterebbe inutile, quindi va garantita la robustezza delle rete
stessa.

Larghezza di banda : vi deve essere una adeguata larghezza di banda per evitare congestione
di rete che possono portare alla perdita di dati critici e sensibili.

Sicurezza e privacy : si necessitano meccanismi di autenticazione per accedere ai dati
sanitari.
Quindi abbiamo visto come l’utilizzo in ambito sanitario del cloud mobile può portare a numerosi
vantaggi soprattutto a favore del paziente che riceverebbe cure più tempestive da parte dei medici,
ma anche solo visualizzare le informazioni diventa più semplice ed immediato. Di contro però
19
vediamo come determinati fattori possono minare la qualità effettiva del servizio, portando
problemi nelle cure dei pazienti.
3.3 : SICUREZZA CLOUD PER “SMART HEALTH”
In questa sezione analizzerò quelle che sono le problematiche dell’utilizzo del cloud a favore di
progetti “Smart Health” cercando di fornire una soluzione tecnica per la protezione dei dati
sensibili. Inizierò descrivendo un modello semplice e astratto di cloud E-Health e su tale modello
andrò ad introdurre quelle che sono le tre principali aree di problematiche per la sicurezza e la
privacy : l’archiviazione dei dati e il loro utilizzo, la gestione delle infrastrutture E-Health e l’usabilità
dei sistemi da parte degli utenti finali. In passato gli operatori sanitari memorizzavano le
informazioni dei loro pazienti in cartelle cliniche cartacee, permettendo un ambiente controllato
con facile gestione della privacy e della sicurezza dei dati mantenendo ad esempio tali cartelle
chiuse a chiave in armadietti. Con il crescente utilizzo dei personal computer e di moderne
tecnologie in ambito sanitario , è stato fatto un notevole sforzo per la gestione della privacy e della
riservatezza dei dati. L’utilizzo di servizi come il cloud ha portato a sistemi complessi in cui i dati
sensibili vengono memorizzati ed elaborati in luoghi diversi. Quindi diventa attraente utilizzare
sistemi cloud in ambito “Smart Health” , migliorando si la qualità del servizio, ma aumentando di
contro la complessità nel gestire la sicurezza e la privacy dei dati. Al fine di comprendere al meglio
la trattazione di questo paragrafo è utile introdurre quelli che sono le parti principali coinvolte nella
trattazione:

Health Professional ( Sanitario) : persona che fornisce servizi di assistenza sanitaria

Health Care Provider (Fornitore di assistenza sanitaria) : organizzazione che fornisce servizi
di professionisti della sanità

Personal Health Record (PHR) : banca dati di dati medici e dati relativi alla salute gestiti da un
paziente

Electronic Health Record (EHR): banca dati di dati medici e dati relativi alla salute gestiti da
health professional
Si noti che la differenzazione tra PHR e EHR è fatta a causa delle diverse implicazioni giuridiche in
alcuni paesi.
3.3.1 : SEMPLICE MODELLO DI E-HEALTH CLOUD
In questo tipo di sistema i pazienti possono conservare i propri dati relativi alla salute su alcuni
server web : il cosiddetto PHR. In tale modello i pazienti possono monitorare,raccogliere e gestire
le informazioni su di loro nei vari siti web messi a disposizione. Possono inoltre inserire date e
periodi di malattia, i loro appuntamenti con i medici e altri tipo di informazioni riguardanti la salute.
20
I pazienti possono inoltre anche importare dati nelle loro PHR che ricevono dai medici. I PHR sono
memorizzati su un server nel cloud. Il server provider PHR è responsabile di assicurare la protezione
dei dati. Tipicamente i pazienti possono stabilire “role-based”(basate sui ruoli) di diritti di accesso
per i singoli medici. I vantaggi di un tale approccio sono che il PHR è accessibile da ovunque a causa
della gestione centralizzata: il paziente può facilmente dare ad un medico l’accesso ai dati e risultati
di test che sono stati determinati da un altro medico aiutando ad evitare un doppio esame.
Tuttavia dal punto di vista tecnico tale modello ha un grande svantaggio per quanto riguarda la
privacy dei pazienti : da un lato i pazienti devono gestire complessi diritti di accesso capendo
affondo le loro implicazioni, d’altra parte hanno bisogno di fare affidamento sulla robustezza e
correttezza dei meccanismi di sicurezza implementati presso il server PHR. In generale può essere
possibile per chi fornisce il server poter accedere ai dati memorizzati nel PHR.
3.3.2 : MODELLO AVANZATO DI E-HEALTH CLOUD
Diverse dai PHR che vengono gestiti dai pazienti , abbiamo le EHR cioè cartelle cliniche elettroniche
gestiti dagli Health Professional. Nella maggior parte dei paesi ciò comporta diversi requisiti di legge
e una chiara distinzione tra PHR e EHR. Come risultato le infrastrutture che coinvolgono EHR sono
molto più complesse del caso ideale preso precedentemente in esame. In questo modello più
avanzato vediamo anche alcuni mezzi tecnici per far rispettare la sicurezza dei dati. Il requisito
fondamentale in questo modello è ancora la funzionalità e l’interoperabilità semantica dei dati
memorizzati nella EHR : tali cartelle elettroniche sono create ,mantenute e gestite da operatori
sanitari e possono essere condivise tramite server centrale EHR nel cloud con altri Health
Professional. Ma archiviazione ed elaborazione non sono gli unici servizi che possono essere
esternalizzati nel cloud : Health Care Provider possono utilizzare il cloud anche per servizi di
fatturazione e contabilità con le assicurazione sanitarie dei pazienti. Questo è uno scenario tipico
che possiamo trovare nella pratica: molti medici lasciano il compito di fatturazione ad un terzo
elemento il quale accumula la fatturazione dei diversi pazienti per le diverse classi di malattia o per
diversi Health Care Provider. Conseguentemente la privacy diventa un aspetto ancora più
importante in questo modello in quanto i pazienti o gli enti che fornisco la fatturazione non
dovrebbero essere in grado di accedere ai dettagli privati dei vari EHR. Ad esempio le smart card
sono utilizzate per proteggere tali dati, infatti: servono per autenticare gli operatori sanitari e i
pazienti, firmare documenti EHR e fornire autenticità, cifrare i dati prima che questi vengono salvati
sul cloud e autorizzare l’accesso ai dati stessi. Tuttavia si fa poca attenzione a ciò che accade dopo
l’accesso ai dati, cioè come i dati vengono elaborati e memorizzati su piattaforme client dagli utenti
21
finali. Virus o Cavalli di Troia possono danneggiare i dati e intercettare PHR dei pazienti , violando i
requisiti di privacy.
3.3.3 : PROBLEMI DELL’E-HEALTH CLOUD
In questo paragrafo ,darò una panoramica sistematica delle minacce di sicurezza o privacy riservate
al cloud dell’E-Health, tralasciando quelle che sono le problematiche giuridiche per il trattamento
dei dati e soffermandoci sui problemi tecnici. Analizziamo le seguenti tre aree problematiche :

Data Storage and Processing ( Memorizzazione dei dati e L’elaborazione )

Management of E-Health Infrastructure (Gestione dell’Infrastruttura dell e –health)

Usability and User Experience
3.3.3.1 : DATA STORAGE AND PROCESSING
Esistono problemi di sicurezza e privacy in cui i dati medici delle cartelle cliniche vengono
memorizzati ed elaborati. Grandi sforzi vengono compiuti per avere meccanismi di controllo
dell’accesso e alla crittografia dei dati in grado di garantire riservatezza dei dati medici. Tipicamente
le informazioni vengo memorizzate nei Data Center, nel quale però vi è il rischio della perdita o
violazione dei dati da parte di soggetti non autorizzati. Quindi i dati più delicati devono essere
opportunamente protetti con meccanismi di crittografia. Inoltre i Data Center devono essere gestiti
da un possibile amministratore senza consentire l’accesso ai dati dei pazienti. Altro problema si ha
con le piattaforme client : tipicamente tali piattaforme sono i pc e infrastrutture di rete utilizzati dal
medico o piattaforme di calcolo dei sistemi informativi negli ospedali. I medici non hanno la
competenza e il tempo di gestire con professionalità i propri sistemi informatici in termini di
22
sicurezza, avendo cosi la possibilità di minacce di violazione dei dati. Inoltre i sistemi di oggi che
vengono utilizzati non offrono meccanismi di sicurezza sofisticati, né sono implementati a causa
delle limitazioni architettoniche : mancano informazioni sul flusso, meccanismi di controllo ed
interfacce protette. Tutto questo rende i sistemi vulnerabili ad attacchi di malware portando alla
perdita di password e dati segreti. Infine a tali informazioni vi possono accedere più persone
connettendosi al sistema anche con dispositivi di archiviazione di massa portatili. Per tali motivi il
controllo della sicurezza viene lasciato alle infrastrutture di E-Health.
3.3.3.2 : MANAGEMENTE OF E-HEALTH INFRASTRUCTURE
Su una scala più ampia, l ‘intera infrastruttura di E-Health cloud ha più rischi che minacciano la
privacy dei dati. Sia i dati PHR che EHR si trovano in vari “punti” del cloud e il solo utilizzo ad
esempio di smart card o altri meccanismi di controllo all’accesso ai dati non forniscono la
protezione necessaria. L’utilizzo della crittografia richiede la gestione di chiavi crittografiche che
devono essere personalizzate e rilasciate agli utenti. Una preoccupazione che si deve avere è: chi
ha il controllo delle chiavi crittografiche? La risposta più semplice a questa domanda sarebbe dire il
paziente, naturalmente. Ma come gestire le chiavi di crittografia che vanno perse? Chi emana la
chiave o il server PHR e/o EHR devono avere delle copie di backup ( copie di backup che devono
tener conto delle esigenze di privacy dei dati sanitari) delle chiavi stesse? Se utilizzassimo le copie
di backup delle chiavi, avremo che o l’emittente delle chiavi o i fornitori dei server EHR, potrebbero
in linea di principio decifrare e accedere alle cartelle dei pazienti direttamente. Infine come in
qualsiasi infrastruttura a chiave crittografata, bisogna anche analizzare il problema della gestione
dei certificati tenendo conto della loro emissione e distribuzione nonché elenchi di aggiornamento
o revoca. Quindi oltre alla componente crittografica, altri componenti devono essere gestiti e
mantenuti includendo elementi sia Hardware (lettori di smart card, connettori di rete…) o Software.
In particolare l’installazione e aggiornamento dei componenti Software richiede un meccanismo di
distribuzione sicuro : da un lato deve essere possibile consentire modifiche nella configurazione
Software , dall’altro modifiche non autorizzate(a causa ad esempio di attachi malware) devono
essere rilevabili per fermare un ulteriore utilizzo o per escludere i componenti infetti nelle
infrastrutture di E-Health.
3.3.3.3 : USABILITY AND USER EXPERIENCE
Infine l’ultima area problematica che abbiamo sono gli utilizzatori finali : i pazienti e gli Health
Professional. Se i controlli di sicurezza configurati sono troppo complessi, le persone potrebbero
non essere in grado di usarle e cercherebbero un modo per aggirarle o ignorarle. Ad esempio
ricordare un PIN per la smart card può essere troppo difficile per i pazienti più anziani, avendo cosi
che parecchie persone tendono a scrivere il PIN su carta o anche sulla smart card stessa rendendo
l’aspetto della sicurezza fornita dal PIN del tutto inutile. Dal punto di vista degli Health Professional,
questi ultimi potrebbero essere sovraccaricati dalle varie configurazione Software per garantire la
sicurezza e tipicamente tutte le attività che ritardano le tipiche attività sanitarie vengono
sistematicamente ignorate o aggirate (Ad esempio l’inserimento di PIN e smart card potrebbe
richiedere molto tempo o operazioni nel caso in cui un paziente volesse consultare il proprio
medico via telefono).
23
3.3.4 : SECURE INFRASTRUCTURE E-HEALTH
Una possibile soluzione, trovata nel corso dello studio per la realizzazione di questa tesi, ai problemi
legati alla sicurezza e alla privacy dei dati che si hanno con l’utilizzo del cloud in ambito E-Health, è
stata proposta da Hans Löhr (Horst Görtz Institute for IT Security Ruhr-University Bochum
Germany), Ahmad-Reza Sadeghi (Horst Görtz Institute for IT Security Ruhr-University Bochum
Germany) e Marcel Winandy (Horst Görtz Institute for IT Security Ruhr-University Bochum
Germany)[1]. Questa soluzione prevede di fondare una infrastruttura di E-Health sicuro basato su
TVD – Trusted Virtual Domains. In particolare della soluzione ideata dai tre ricercatori, parlerò
prima dei domini privati introdotti in ambito di E-Health e poi della realizzazione basata su un kernel
di sicurezza e TVD.
3.3.4.1 : DOMINI PRIVATI IN AMBITO E-HEALTH
La privacy dei dati dei pazienti è una preoccupazione primaria e soluzioni tecnologiche dovrebbero
essere impiegate per sostenere norme di legge e contrattuali su questo tema. L’obiettivo del
progetto prevede che i sistemi ( Pc Client) siano in grado di eseguire le applicazione in domini isolati
l’uno dall’altro, avendo cosi che i dati sono conservati in domini di privacy e solo chi vi è autorizzato
può accedervi. Un aspetto importante per la diffusione di questo approccio è l’integrazione con
sistemi legacy(obsoleti). Infatti con il concetto di domini privati, i tre ricercatori si prefiggono di
riutilizzare applicazioni esistenti in esecuzione su sistemi operativi legacy. Per capire al meglio in che
modo utilizzare i domini privati vediamo il seguente scenario di applicazione : si consideri un
medico che vuole usare un Software di contabilità per presentare le fatture di assicurazioni
sanitarie e un Software per memorizzare dati sanitari dei pazienti. Inoltre, il medico ha bisogno di
un accesso Web e deve essere in grado di inviare e ricevere e-mail. Questi diversi flussi di lavoro
devono essere separati l'uno altro: L'assicurazione sanitaria non dovrebbe ottenere l'accesso ai dati
medici, e l’accesso ad Internet e la vulnerabilità del Browser Web dovrebbero non influenzare il
processo contabile, o avere un impatto sui dati medici. Solo il Software di contabilità può
connettersi alla rete sanitaria. Tuttavia, potrebbe essere auspicabile che il medico sia in grado di
inviare dati medici da una cartella clinica elettronica utilizzando un normale client e-mail. Il
Software di contabilità o le applicazioni di elaborazione dei dati medici potrebbero richiedere
specifici (forse obsoleti) sistemi operativi, mentre il Browser Web (e il sistema operativo su cui viene
eseguito) devono essere sempre aggiornati per includere la le ultime patch di sicurezza. Per
raggiungere questi obiettivi vengono utilizzati tre domini privati. Un dominio privacy, che è limitato
al Software autorizzato a accedere alla rete contabile. Un secondo dominio di privacy, il dominio di
E-Health, è dedicato alla conservazione e la lavorazione degli EHR. Un terzo dominio (che non è né
parte della contabilizzazione, né del dominio E-Health)contiene programmi come un Browser Web
ed e-mail client. Solo questo terzo dominio privato ha l'accesso Internet senza restrizioni; il
Software di contabilità è limitato a connettersi ai server di contabilità, il Software nel dominio di EHealth è limitato a connettersi ai server E-Health.
24
3.3.4.2 : TRUSTED VIRTUAL DOMAIN
I principali obiettivi del progetto di sicurezza prevedono la completa separazione dei dati medici (
come fatturazione e contabilità), nonché l’integrazione delle smart card sanitarie nel sistema. Prima
di addentrarci nella soluzione proposta vediamo cosa sono i TVD : è una coalizione di macchine
virtuali distribuite su più piattaforme fisiche che si fidano l’un l’altro, condividendo una politica di
sicurezza comune. In particolare le caratteristiche di sicurezza principale dei TVD sono :

Isolatend compartments (Compartimenti Isolati) : il kernel di sicurezza fornisce limiti di
contenimento per i differenti TVD , consentendo l’esecuzione di più TVD sulla stessa
piattaforma fisica.

Trust Reletionships : un TVD definisce una politica su quali piattaforme e macchine virtuali
possono partecipare al TVD stesso.

Trasparent Policy Enforcemente : il kernel di sicurezza rafforza la politica di sicurezza
indipendentemente dai compartimenti.

Secure Communication : le macchine virtuali appartenti allo stesso TVD sono collegati
tramite una rete virtuale strettamente isolato dalle reti virtuali di altri TVD.
Quindi durante il funzionamento del sistema, il kernel di sicurezza deve garantire il rigoroso
isolamento di domini diversi : ogni volta che i dati lasciano un dominio ( ad esempio durante un
trasferimento) i servizi di sicurezza devono crittografare tutti i dati con una chiave crittografica che
è disponibile solo nel TVD corrispondente. Una caratteristica importante delle infrastrutture TVD è
la sua automatica gestione: la gestione delle chiavi, applicazione delle politiche di accesso,
crittografia dei dati sono completamente trasparanti all’utente. Fintanto che gli utenti non cercano
di violare la politica di controllo e di sicurezza, l’unica differenza rispetto ad un sistema
convenzionale sono indicatori visivi che indicano in che dominio lavorano.
25
3.3.4.3 : CLIENT PLATFORM
Quindi avremo che la struttura TVD comprende una piattaforma client e un Master TVD utile alla
gestione dell’infrastruttura stessa, per ciascun dominio. Sulla piattaforma client, un kernel di
sicurezza è in esecuzione sulla parte superiore dell’Hhardware,fornendo isolate macchine virtuali
per le applicazioni e sistemi operativi tradizionali. Inoltre vi sono dei proxy TVD per ogni TVD, il
quale gestisce il TVD sul client e configura il kernel di sicurezza in base alla politica del TVD stesso.
Un'interfaccia utente grafica sicura (GUI sicuro) fornisce input e output, assicurando che gli utenti
possono sempre identificare in modo affidabile il dominio con cui stanno interagendo. L'interfaccia
grafica sicura impedisce che anche altri compartimenti leggano l'input dell'utente quando non sono
autorizzati a farlo. Inoltre la piattaforma client contiene un componente trusted Hardware che può
essere utilizzato per la verifica della integrità del Software sul client e il più diffuso componente
Hardware di questo tipo è il TPM - Trusted Platform Module (attualmente è implementato come
chip separato integrato sulla scheda madre di un computer, in particolari sui pc aziendali. Tali TPM
forniscono un insieme di funzioni di sicurezza e funzioni crittografiche). Per TVD tre elementi sono
importanti:

Authenticated boot (Avvio autenticato) : quando il sistema viene avviato, la piattaforma
calcola i valori crittografici dei componenti che vengono caricati ed eseguiti e vengono
memorizzati in modo sicuro all’interno di speciali registri del TPM, il Platform Configuration
Register (PCR).

Trusted Storage : l’uso di chiavi crittografiche creato dal TPM può essere limitata a specifici
valori di PCR, implicando che i dati possono essere utilizzati se viene avviato il sistema
corretto.

Attestation (Attestato) : il TPM può utilizzare per impieghi speciali chiavi crittografiche utili a
convalidare i valori del PCR.
Quando un client vuole partecipare ad un TVD, il TVD Master verifica l’integrità del kernel di
sicurezza del client, in modo tale da garantire che solo i client conformi alla politica del TVD sono
ammessi nello stesso. Successivamente un proxy TVD viene avviato sul client e il TVD Master
distribuisce la politica TVD necessaria e la crittografia delle chiavi.
26
3.3.4.4 : SVILUPPI FUTURI
Ci sono una serie di aspetti riguardanti la sicurezza e la privacy che devono essere presi in
considerazione per sviluppi futuri :

Assenza del paziente : il paziente non è presente quando bisogna accedere al EHR, ad
esempio dovrebbe essere rappresentato da un parente o amico invalidando però quelli che
erano i vantaggi del PIN e delle smart card.

Incapacità del paziente di autenticarsi : il paziente potrebbe non essere in grado di
autenticarsi (fisicamente o mentalmente) per immettere il PIN. Ad esempio scenari possibili
sono quelli che includono persone anziane o affette da handicap.

Riservatezza : la semplice esistenza di un EHR determina che una persona ha ricevuto cure
mediche e quindi deve essere mantenuta la riservatezza per evitare di violare la legge sulla
privacy.
27

Anonimato del cliente : l’anonimato di un cliente può essere violato dal tracciamento degli
utenti come ad esempio nel caso in cui un paziente acquista un farmaco in una farmacia
utilizzando una chiave elettronica e il farmacista non dovrebbe essere in grado di tracciare o
identificare il paziente.

Accesso di emergenza : in caso di emergenza, gli operatori sanitari potrebbero avere bisogno
di accedere ai dati urgentemente in situazioni in cui il paziente non è in grado di
autorizzarlo. In tali casi , l’accesso dovrebbe essere possibile, ma è importante che , per
ragioni legali, la persona che ha effettuato l’accesso sia identificato e ritenuto responsabile.
Inoltre tale persona non dovrebbe essere in grado di negare il fatto di aver effettuato
l’accesso.
28
CAPITOLO 4 : CASO DI STUDIO
In questo capitolo vado a trattare nel dettaglio uno dei maggiori progetti di tipo “Smart Health”
nato tra le regioni del sud Italia : “Smart Health 2.0”. In particolare, dove aver introdotto a caratteri
generali gli obiettivi, e gli elementi caratterizzanti la natura del progetto, mi soffermerò
principalmente sugli aspetti cloud del progetto stesso.
4.1 : SMART HEALTH 2.0
Il Progetto “Smart Health 2.0”[4] (Ulteriori riferimenti : [5],[6],[7],[8]), letteralmente “Salute
Intelligente” è finalizzato alla promozione dell'innovazione del Sistema Sanitario. Finanziato
nell’ambito del programma MIUR (Ministero dell’Istruzione dell’Università e della Ricerca)“Smart
Cities and Communities and Social Innovation" (D.D. 84/Ric. del 2 marzo 2012) Asse II – azioni
integrate per la società dell'informazione e per lo Sviluppo sostenibile. Le aree di intervento del
progetto sono:

La PREVENZIONE per ridurre l’incidenza e la progressione della malattia e le complicanze ad
essa associate

La DIAGNOSI precoce ed il TRATTAMENTO nelle fasi iniziali della patologia

L’INTEGRAZIONE e la CONTINUITA’ di prevenzione e cura

Il MONITORAGGIO e il SELF MANAGEMENT
L’obiettivo di “Smart Health 2.0” è la realizzazione di un sistema tecnologico che implementi un
modello innovativo di sanità digitale basato su architetture aperte, anche Cloud, modulari e scalabili
che permetta di abilitare lo sviluppo di nuovi modelli di cooperazione applicativa tra diverse entità
operanti nell’ambito della Sanità del Sud Italia, affinché esse possano partecipare attivamente alla
reingegnerizzazione e miglioramento dei processi. Nel dettaglio gli obiettivi che il progetto vuole
raggiungere sono molteplici:

Realizzare un sistema tecnologico che abiliti un nuovo modello di Sanità digitale basato
sulla cooperazione tra le diverse entità della Sanità stessa

Realizzare strumenti di business intelligence per modellare il rischio nelle attività di cura
ed ottimizzare i percorsi clinici in ottica di riduzione dello stesso

Realizzare servizi innovativi di telemedicina per la gestione del paziente a domicilio in
contesti sia di assistenza socio sanitaria che di trattamento di patologie croniche
29

Realizzare sensori innovati per il rilevamento diretto,continuo ed in tempo reale di
parametri clinicamente rilevanti.
Quindi abbiamo visto come il progetto “Smart Health 2.0” abbia una pluralità di obiettivi, i quali
possono essere schematizzati come segue :
30
4.2 : AMBITO APPLICATIVO
In ambito applicativo vediamo approfonditi specifici temi finalizzati ad una efficace declinazione del
concetto di “Smart Health” . Tali temi sono stati identificati seguendo il paradigma della continuità
di cura: Fascicolo Sanitario Elettronico(FSE) di 2° generazione,applicazioni dedicate a
prevenzione,gestione del rischio clinico e ottimizzazione dei percorsi clinici, sensoristica avanzata,
strumenti per l’aggiornamento professionale nella quotidiana attività lavorativa e per la
partecipazione del cittadino alla gestione della propria salute.
4.3 : AMBITO SPERIMENTALE
In ambito sperimentale abbiamo il coinvolgimento delle Pubbliche Amministrazioni delle Regioni
coinvolte nel progetto,in cui la sperimentazione si basa sulla creazione e utilizzo di un Living Lab che
funga da elemento collante tra le attività di ricerca e sviluppo e i siti di sperimentazione. In
particolare vediamo che gli enti preposti alla sperimentazione sono 4 regioni del sud Italia:
Campania(Università di Napoli Federico II), Calabria(Università degli studi di Catanzaro “Magna
Grecia”),Puglia(Università degli studi di Bari “Aldo Moro”) e Sicilia(Università di Palermo che si
occuperà di sviluppare l’aspetto cloud del progetto “Smart Health”).
4.4 : AMBITO INFRASTRUTTURALE
L’Ambito Infrastrutturale consiste nella realizzazione di quattro piattaforme:

Una piattaforma abilitante ce è la struttura portante dell’intero progetto, sviluppata sulla
base di una architettura federata di Cloud Pubblico/Privato, in grado di offrire servizi
Infrastructure as a Service (IaaS),Platform as a Service (PaaS) e Software as a Service (SaaS).

Una piattaforma tecnologica per la diagnostica,un ambiente per la progettazione e la
realizzazione di sensori avanzati in fibra ottica avanzati e miniaturizzati per il rilevamento
diretto, continuo e in tempo reale,di parametri clinicamente rilevanti.

Una piattaforma semantica e documentale, per l’orchestrazione di servizi strutturati in
processi/procedure: integrare e armonizzare i dati provenienti da fonti eterogenee
(sensori,cartelle cliniche,linee guida,protocolli..) garantendo la interoperabilità tra sistemi e
servizi e condividere i dati tra i diversi attori che intervengono nel percorso di cura,
permettendo una più efficiente ed efficace gestione del paziente,minimizzando la possibilità
di errore e fornendo maggiori garanzie per lo stesso.

Una piattaforma BPM(Business Process Management) /Transactional System, per
l’ottimizzazione e la gestione dei processi.
Quindi nell’ambito infrastrutturale ci si prefigge l’obiettivo di studiare, definire, progettare e
realizzare, fino ad un livello prototipale, un’infrastruttura tecnologica basata anche sul modello del
Cloud Computing, in grado di erogare servizi a supporto delle esigenze degli ambiti applicativi in cui
31
si articola il progetto. Tale infrastruttura costituisce un elemento trasversale sul quale poggiare lo
sviluppo di innovativi modelli di hosting, di applicazioni, Web Services e algoritmi in uno schema di
impiego multi accesso. In particolare l’infrastruttura tecnologica fornisce il supporto alla
realizzazione del FSE.
L’adesione al paradigma architetturale del Cloud Computing all’interno del progetto “Smart Health
2.0” è finalizzata al raggiungimento di risultati che si collocano nei seguenti ambiti :

Ricerca : vengono esplorate, con attività di studio ed analisi, le problematiche tecnologiche
salienti ancora irrisolte come quelle legate alla sicurezza, all’affidabilità delle infrastrutture
ed alla coerenza logica degli asset informativi. Sono approfonditi, in particolare, gli aspetti
necessari all’adozione di standard e soluzioni aperte, per garantire l’interoperabilità
applicativa, con l’obiettivo di progettare un sistema efficiente, successivamente realizzato in
forma prototipale impiegando anche tecnologie Open Source e facendo ampio ricorso al
riuso di applicazioni, servizi e sistemi già in dotazione alla Pubblica Amministrazione,
eventualmente re-ingegnerizzati o adattati al paradigma del Cloud Computing.

Tecnologico : viene progettato e realizzato il prototipo di un sistema di Cloud Computing
capace di erogare servizi secondo i modelli Iaas (Infrastructure as a Service), PaaS (Platform
as a Service), SaaS (Software as a Service).

Economico : viene prodotto un business model capace di quantificare gli elementi del
rapporto costo/benefici derivante dall’adozione del Cloud Computing nella Pubblica
Amministrazione.

Organizzativo : viene analizzato il possibile effetto, derivante dall’adozione del Cloud
Computing, sui singoli settori della Pubblica Amministrazione.
4.4.1 : OR1 - PIATTAFORMA ABILITANTE
L’OR1 studia, definisce e implementa la piattaforma abilitante, un elemento tecnologico fondante a
supporto di altri componenti architetturali del sistema. Il Progetto “Smart Health 2.0”, in particolare
in questo ambito, intende avvalersi delle sinergie possibili con il Progetto PRISMA [13], da cui poter
attingere parte delle soluzioni per lo strato infrastrutturale IaaS (quali meccanismi di fornitura delle
risorse infrastrutturali, migrazione delle Virtual Machine, work-load balancing, security,etc.) e
specializzarle per erogare servizi computazionali a supporto delle esigenze dei vari OR.
32
Il progetto "Smart Health 2.0" è altresì concentrato sullo sviluppo e implementazione dei livelli di
middleware (insieme di programmi informatici che fungono da intermediari tra diverse applicazioni
e componenti Software) della piattaforma abilitante (strato PaaS), complementari ed evolutivi
rispetto a PRISMA.
Le modalità di integrazione tra lo strato PaaS e le componenti IaaS, realizzate nell'ambito del
presente progetto e/o messe a disposizione da PRISMA, saranno opportunamente definite nel
corso delle attività progettuali. Particolare attenzione viene prestata, in particolare, agli aspetti di
Cloud Federation (interconnessione di Cloud Computing appartenenti a fornitori diversi in modo da
bilanciare il carico del traffico), in quanto strettamente connessi al livello infrastrutturale IaaS e
quindi dipendenti da come saranno indirizzati nel Progetto PRISMA. La piattaforma consente lo
sviluppo di nuovi modelli di cooperazione applicativa tra le entità della sanità coinvolte, le quali è
previsto che siano attivamente coinvolte nell'attività di reingegnerizzazione dei processi, utilizzando
una semantica comune (opportunamente gestita tramite l’integrazione con la Piattaforma
Semantica e Documentale) per la condivisione di informazioni e criteri di accessibilità ai dati
dipartimentali. Ciò viene realizzato anche grazie all'adozione del modello “Open Data” che
garantisce sicurezza, disponibilità di viste molteplici sui dati, anonimia delle informazioni e
possibilità di analisi epidemiologiche e statistiche nell’ambito della cura della persona.
La piattaforma è concepita per agevolare la cooperazione applicativa offrendo ambienti di sviluppo
a livello PaaS a supporto di terze parti, regionali o locali. Lo scenario ipotizzato prevede un uso
sinergico, condiviso, ottimale ed economicamente vantaggioso delle risorse, degli asset informativi.
La strategia che guiderà le scelte progettuali è basata su un approccio modulare volto al
soddisfacimento dei requisiti di sicurezza logica e infrastrutturale e fa ampio uso di tecnologie
“aperte”, nonché, qualora possibile, di soluzioni standard.
L’impiego del paradigma del Cloud Computing risulta, dunque, fondamentale per il raggiungimento
dei risultati sopra menzionati.
33
Esso, infatti, consente di:
 Facilitare il riuso delle applicazioni, erogandole in modalità “on demand”.
 Ottenere economie di scala ed efficientemente delle risorse tecnologiche.
 Garantire strutture ottimizzate, replicate e scalabili per la memorizzazione di grosse moli di
dati e la conservazione cosiddetta a lungo termine dei documenti, attraverso la
realizzazione e/o il riuso di Cloud Pubblico/Private in un contesto federato.

Fruire di servizi trasversali: gestione documentale, identità unitaria del cittadino,sistemi di
gestione delle infrastrutture e di tariffazione, grazie anche alla condivisione di piattaforme
legate a settori affini della Pubblica Amministrazione (Giustizia, Scuola, ecc.).

Garantire un accesso ubiquitario ai servizi e ai dati sanitari su scala nazionale con qualità del
Servizio garantita dalle reti di comunicazione di nuova generazione e dalla presenza di un
front-end (è responsabile dell'acquisizione dei dati di ingresso e della loro elaborazione con
modalità conformi a specifiche predefinite e invarianti) unico di accesso da parte degli
utenti.
OR1 si articola nelle seguenti attività :

Analisi dello Stato dell’Arte

Analisi dei Requisiti

Definizione dell’Architettura

Realizzazione del modello IaaS

Realizzazione del livello PaaS ed integrazione con IaaS

Sviluppo di modelli e meccanismi di sicurezza per la piattaforma

Soluzioni per il Massive Parallel Processing (MPP)

Test della piattaforma
34
4.4.1.1 : ANALISI DELLO STATO DELL’ARTE
Tale attività è dedicata all'analisi dello Stato dell'arte della ricerca recente ed in corso sulle
tematiche cloud, infrastrutturali e applicative in ambito sanitario, nonché alla sistematizzazione e al
confronto delle caratteristiche riconducibili al grado di maturità e affidabilità delle tecnologie open
source disponibili. Ciò al fine di disporre di un confronto tecnologico ragionato in grado di
indirizzare le successive fasi di progettazione e realizzazione della piattaforma. A tal fine, grande
importanza viene riconosciuta al rilevamento dei bisogni e delle richieste dei principali stakeholders
( enti interessati ) del Sistema Sanitario Nazionale (Amministrazioni sanitarie locali, ospedali, presidi
sanitari sul territorio, associazioni dei pazienti, fornitori delle reti per la ricerca, Ministero della
Salute etc.).
4.4.1.2 : ANALISI DEI REQUISITI
Questa attività è dedicata all'analisi estesa e puntuale dei requisiti di base che la piattaforma
abilitante deve soddisfare oltre che alla raccolta e sistematizzazione delle caratteristiche principali
degli scenari applicativi, ritenuti più significativi per indirizzare il Progetto "Smart Health 2.0" verso
una sperimentazione efficace. In particolare, vengono identificati attori, ruoli, funzionalità e
processi che animano i diversi casi d’uso, esaminando i requisiti e individuando i vincoli propri dei
vari scenari di interesse. Insieme ai requisiti funzionali, vengono analizzati anche i requisiti di
affidabilità, interoperabilità e prestazione. In particolare per rendere i risultati di progetto
concretamente utilizzabili nel quadro di ammodernamento della sanità del Sistema Paese, si ritiene
che particolare attenzione vada posta ai requisiti legati alla compatibilità con la rete tecnologica
InFSE (Interfaccia di accesso ai FSE), che definisce un’infrastruttura operativa a supporto
dell’interoperabilità delle soluzioni territoriali di FSE nel contesto del sistema pubblico di
connettività, condivisa a livello nazionale e allineata allo scenario internazionale.
4.4.1.3 : DEFINIZIONE DELL’ARCHITETTURA
Obiettivo di tale attività è lo studio e la progettazione dell'architettura di riferimento della
piattaforma abilitante che, in accordo con il principio della modularità, è chiamata ad offrire
componenti per:

gestire le architetture applicative e la loro distribuzione automatica e ottimale su
infrastrutture cloud, con funzionalità di monitoraggio delle performance e gestione dei
Service Level Agreement;

definire modelli per l'accesso agli Open Data eliminando le ambiguità informative,
condividendo e creando conoscenza in modo collaborativo, tramite processi
statistico/inferenziali, con viste multiple e funzionali agli stakeholder della filiera sanitaria;

garantire la massima segretezza e anonimato, laddove opportuno e richiesto, dei dati
sensibili archiviati nella piattaforma attraverso sistemi di autenticazione sicuri.
35
4.4.1.4 : REALIZZAZIONE DEL MODELLO IAAS
Obiettivo di tale attività è:

la realizzazione di parte dello strato IaaS previsto dalla piattaforma abilitante, in particolare
quella di supporto alla fornitura delle risorse e all'hosting dei Sistemi Informativi Ospedalieri
(SIO) e allo sviluppo dell'Fascicolo Sanitario Elettronico (FSE) di seconda generazione.

l’integrazione dello strato IaaS sviluppato e implementato nell'ambito del presente progetto
con quello reso disponibile da altre iniziative (ad es. dal Progetto PRISMA).
Questa attività è strettamente connessa con le attività specificamente legate allo implementazione
del FSE di Seconda Generazione e con il Data Warehouse(archivio informatico contenente i dati di
un'organizzazione)e rappresenta una fase assai rilevante del processo di prototipazione di una
soluzione innovativa, anche in termini di "sperimentazione normativa" volta al superamento degli
attuali limiti giurisprudenziali in materia di trattamento e proprietà dei dati sanitari. Si prevede
altresì un raccordo con l'infrastruttura computazionale sviluppata del progetto PRISMA per quanto
attiene le tematiche di delocalizzazione dei dati, di cloud e di Storage Federation.
4.4.1.5 : REALIZZAZIONE DEL LIVELLO PAAS ED INTEGRAZIONE CON IAAS
Obiettivo di tale attività è l’integrazione con lo strato IaaS reso disponibile da altre iniziative (es.
PRISMA) e la realizzazione dello strato PaaS dell'architettura di riferimento della piattaforma
abilitante. Quest’ultimo prevederà la gestione delle architetture applicative da rendere disponibili
sull’infrastruttura IaaS, con funzionalità di Application Deployment e Binding(distribuzione delle
applicazioni e unione delle stesse) con i servizi di piattaforma, Self-Provisioning (auto rifornimento)
per la gestione delle applicazioni, monitoraggio applicativo, SLA & Perfomance management. Lo
strato consentirà inoltre l’adattamento di singole applicazioni sulla piattaforma abilitante, con un
approccio che sarà fortemente basato sull’uso di servizi applicativi riusabili ed orchestrabili.
In particolare saranno focalizzati temi legati a:

Servizi di Cloud Computing rivolti al mondo sanitario.

Sistemi integrati di Identity Management e Access Control specifici per il mondo sanitario.

Soluzioni prototipali innovative, rispondenti a specifiche esigenze regionali di sistema e
definite a livello di Tavolo di Sanità Elettronica Regionale, in tema di hosting di interi Sistemi
Informativi Ospedalieri (SIO), nel rispetto delle stringenti normative in termini di proprietà e
gestione dei dati sanitari e di tutela della Privacy.

Integrazione e supporto di base al Data Warehouse sanitario di seguito descritto, a
fondamento del FSE.
36
4.4.1.6 : SVILUPPO DI MODELLI DI SICUREZZA PER LA PIATTAFORMA
Gli scopi primari di questa attività consistono nello sviluppo di modelli e di politiche e nel progetto
dei corrispondenti meccanismi di sicurezza a sostegno dell’affidabilità della piattaforma e al
mantenimento dell’integrità e della confidenzialità dei dati e della conoscenza durante il loro
utilizzo in ambito Cloud. In particolare si prevede di:

Studiare i meccanismi di trust e identity management in grado di supportare la creazione,
per ogni cittadino, di una "identità unica" per l’accesso ai servizi sanitari in modalità single
sign on.

Sviluppare un modello per la creazione e la gestione dinamica delle relazioni di trust tra i
servizi (come richiesto dall’integrazione di servizi medici basati su cloud federate)
studiandone anche le modalità di realizzazione attraverso l'individuazione degli standard e
delle tecnologie di trust management e trust negotiation più adatte allo scopo.

Studiare le politiche e i meccanismi sicuri per l’utilizzo di dati sensibili in ambito cloud,
controllando che la migrazione dei dati tra host e servizi determinata dal middleware e/o
dalla logica dei business process rispetti le politiche di privacy e usage control.
4.4.1.7 SOLUZIONI PER IL MASSIVE PARALLEL PROCESSING (MPP)
L’attività è finalizzata all’implementazione delle tecniche di MPP per la prototipazione di un sostrato
applicativo che possa correlare la moltitudine di dati disponibili all'interno del progetto. Questa
soluzione tecnica permette di introdurre sofisticati strumenti di indagine basati sul calcolo massivo
distribuito, proponendo l'analisi di dati scientifici secondo metodi computazionalmente complessi e
non convenzionali. Tali servizi sono concepiti in modo da avvalersi di tecnologie e processori di
ultima generazione. L'implementazione di tecniche di analisi (es. Wavelet, HHT, Neural Network),
verifica di inferenza statistica, processi decisionali (es. Euristici, MDP), data mining (insieme di
tecniche e metodologie che hanno per oggetto l'estrazione di un sapere o di una conoscenza a
partire da grandi quantità di dati ), classificazione, Feature Extraction e Pattern Recognition
rappresentano alcuni degli strumenti oggetto dell'attività capaci di forti ricadute sulla ricerca e sulla
realizzazione di soluzioni per l'MPP. L'applicazione di avanzate tecniche di filtraggio dei dati,
provenienti dal mondo dell'elaborazione dei segnali, permette di ridurre la ridondanza, offre nuovi
strumenti per matching e cross/validation, favorisce la determinazione di accurate metriche per
ogni serie di risultati, consente di focalizzarsi sui dati di interesse adattando, caso per caso, lo
spettro di indagine secondo le specifiche esigenze.
Ciò rende possibile il confronto tra gruppi di dati eterogenei e, attraverso la correlazione di tutte le
informazioni, permette di generare nuovo know-how.
37
4.4.1.8 : TEST DELLA PIATTAFORMA
Obiettivo di tale attività consiste nell'effettuazione di test, validazioni e benchmarking della
piattaforma abilitante realizzata. Le analisi svolte riguardano in particolare gli aspetti funzionali e
prestazionali dei servizi erogati, la consistenza e la validità dei business process, mentre opportuni
stress test verificano la scalabilità e l’affidabilità della piattaforma. Si prevede infine di raccogliere e
analizzare i dati prodotti durante la fase di sperimentazione. Essi costituiscono il feedback
necessario per consentire ai progettisti e agli sviluppatori l’adattamento dei componenti che
dovessero mostrare un funzionamento inadeguato rispetto alla progettazione ed al modello del
sistema.
38
CONCLUSIONI
E’ risultato chiaro alla fine di questo studio come la vita di milioni di pazienti possa nettamente
migliorare grazie alla tecnologia, portando in rete tutte le informazioni vitali per un miglior
trattamento sanitario degli ammalati. L’utilizzo del cloud , sfruttabile da qualsiasi dispositivo in
grado di connettersi alla rete, permette una migliore circolazione delle informazioni e un più
tempestivo intervento da parte degli enti sanitari. Benefici verrebbero portati anche agli stessi
medici che ridurrebbero in modo drastico tutte quelle attività da scrivania,avendo cosi più tempo
per compiere la propria professione. Anche le stesse organizzazioni sanitarie, grazie a tali progetti
“Smart Health” , avrebbero un riscontro positivo dal punto di vista economico, risparmiando ingenti
somme di denaro da destinare ad altre aree di ricerca e sviluppo.
Insomma l’informatizzazione in ambito sanitario porterebbe solo vantaggi al cittadino,
garantendogli un miglior servizio. Per questi motivi i numerosi progetti di ricerca in atto o in cerca di
finanziamento dovrebbero essere supportati appieno, al fine di raggiungere condizioni di vita
nettamente migliori per i cittadini. L’analisi dei progetti da me fatta in ambito Cloud Computing,
mobile e di sicurezza hanno portato alla luce quelle che sono le necessità oggettive della sanità,
presentando però problemi di natura tecnica ( vedasi la sicurezza e la privacy o l’interoperabilità dei
dati) che necessariamente devono essere risolti e superati con l’appoggio economico della Pubblica
Amministrazione e degli stati.
E’ auspicabile quindi che da ora e nei prossimi anni a venire ci sia un netto miglioramento dello stile
di vita per il singolo cittadino, andando cosi a realizzare quell’ideale di “Smart City”, scongiurando
cosi le previsioni pessimistiche del 2050.
39
RINGRAZIAMENTI
Ed eccomi finalmente giunto nell’angolo dei ringraziamenti. In primis devo ringraziare i miei genitori
per avermi sostenuto nell’arco di questi cinque anni( che dovevano essere tre eheh) fino ad oggi
nonostante i vari problemi avuti durante tutto il percorso di studi (qualcuno ricorda il numero di
volte in cui ho provato Analisi I ??? ), sperando di averli resi almeno un po’ orgogliosi e fieri di me.
Forse non tutti sanno che non è stato tutto rose e fiori questa triennale, infatti dopo il mio primo
anno fallimentare volevo lasciare tutto, ma cosi non è stato perché all’inizio del mio secondo anno
ho conosciuto delle persone speciali tra cui c’erano quelle che chiamavo “matricole” : il caro
Signor. Vela (chiamarla Dottor Vela non avrebbe senso), il buon Tortora colui che ha usufruito più di
tutti dei quaderni del sottoscritto (ritieniti fortunato che non hai pagato niente), il mio grafico di
fiducia nonché irascibile Gino, il signor Uomo e le nostre interminabili partite alla PS3, le corte (per
chi non lo sapesse Alina e Rosaria) e i loro inciuci, i 3 gemelli diversi, il caro Siervo più ricci che
uomo,il rumoroso Vibrati, agli Amici di Merda che mi hanno accolto non si sa perché tra le loro fila,
Ventimiglia, Scalingi, Polverino, Erasmo, Tessitore ….
Se dimentico qualcuno è fatto apposta, devo risparmiare carta e quindi denaro e non posso
nominare chiunque…..
Comunque scherzi a parte, quello che voglio dire è che anche grazie a tutti voi che io sono qui oggi,
senza la vostra voglia di studiare e di apprendere che mi avete trasmesso ( la mia era perduta chi sa
dove), io forse mi sarei fermato al primo anno, ma tutti voi mi avete dato le giuste motivazioni per
andare avanti e proseguire anche se non ve ne siete resi conto.
Per ultima e non per importanza ringrazio colei che ormai mi è accanto da quasi un anno, la ragazza
di cui sono perdutamente innamorato, che mi ha sopportato, supportato e consigliato in ogni
momento in questi mesi di avvicinamento ad oggi. E anche grazie al tuo sostegno che oggi sono qui.
Ti Amo.
E per concludere mi raccomando da oggi in poi per voi sarò il Dottor. Sepe .
40
BIBLIOGRAFIA
[1]
Ruhr–Universitat-Bochum
http://www.trust.rub.de/media/trust/veroeffentlichungen/2010/12/22/securing-theehealth-cloud.pdf
Accessed : 21/06/2014
[2]
IEEE XPLORE Digital Library
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6821461&url=http%3A%2F%2Fieeex
plore.ieee.org%2Fiel7%2F6821067%2F6821334%2F06821461.pdf%3Farnumber%3D682146
1
Accessed : 21/06/2014
[3]
IEEE XPLORE Digital Library
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6497443
Accessed : 21/06/2014
[4]
Consiglio Nazionale delle ricerche
http://www.cnr.it/SIGLA/genericdownload/Smart%20Health%202%200_capitolato%20tecnic
o%20definitivo.pdf?nodeRef=workspace://SpacesStore/98fd40c1-5cc0-450e-998871a3a465208f
Accessed : 21/06/2014
[5]
PON Ricerca e Competitività
http://www.ponrec.it/media/140130/smart_health_presentazione_miur.pdf
Accessed : 21/06/2014
[6]
PON Ricerca e Competitività
http://www.ponrec.it/media/309803/smart_health_2_0_presentazione_sal_27032014_v2.p
df
Accessed : 21/06/2014
[7]
SDN Napoli
http://www.sdn-napoli.it/wp-content/uploads/2013/10/Prof.GiorgioVentre_Salute-deiCittadini_SmartHealth2.0.pdf
Accessed : 21/06/2014
[8]
SlidePlayer.it
http://slideplayer.it/slide/932914/
Accessed: 21/06/2014
[9]
Filippo Moriggia , Il server tra le nuvole , Pc Professionale Ottobre 2010
41
[10]
www.wikipedia.org
http://it.wikipedia.org/wiki/Cloud_computing
Accessed : 21/06/2014
[11]
www.youtube.it
https://www.youtube.com/watch?v=YJCZk9-GPJw
Accessed : 21/06/2014
[12]
Gruppo Hera
http://www.gruppohera.it/gruppo/com_media/dossier_smartcities/articoli/pagina33.html
Accessed : 21/06/2014
[13]
SlidePlayer.it
http://www.slideshare.net/ProgettoPrisma/prisma-at-smart-city-med-napoli-27032014
Accessed : 21/06/2014
42
43

Piattaforme Cloud per servizi di Smart Health

Transcript

Documenti analoghi

OASIS Openly Accessible Services and Interacting

L`HR è in grado di favorire la crescita?

OFFERTA SERVER CLOUD COMPRENSIVO DI

COLLEGIO EINAUDI “CLOUD”

CYBERCRIME E CLOUD COMPUTING

My Cloud EX2 and EX4 Brochure

Licenze per il riutilizzo dei dati pubblici e Open Data

TECN. E PROG. DI SIST. INFORM - Fossati