- Progress in Training

UNIVERSITÀ DEGLI STUDI DI BARI “A. MORO”
in collaborazione con
CONSORTIUM GARR-X
***
MASTER IN METODOLOGIE E TECNOLOGIE PER
LO SVILUPPO DI INFRASTRUTTURE DIGITALI
Tesi
Business e Data modeling di Smartcare, una
piattaforma web per la democrtizzazione della Sanità
Relatore : Nicholas Caporusso
Correlatore : Gianluca Lattanzi
Candidato : Dott.ssa Mirna Valvano
ANNO ACCADEMICO 2013 - 2014
INDICE
Introduzione…………………………………………………………………………….........................1
1. La Tecnologia nella Sanità…………………………………………………………….........................3
2. Concetti generali di Business Model………………………………………………………………...4
2.1 Il Business Model Canvas………………………………………………………………….5
2.2 Business Model Canvas per lo Smartcare…………………………………..............................7
3. Smartcare…………………………………………………………………………………………..10
3.1 Cos'è Smartcare…………………………………………………………………………...10
3.2 Come funziona Smartcare………………………………………………………………....11
3.3 DATA MODELING di Smartcare……………………..............................................................11
4. Le basi di dati e i sistemi di gestione delle basi di dati…………………………………………….......18
4.1 Il Modello dei dati di un Database…………………………………………………………19
4.2 I Database Relazionali (RDBMS)………………………………………………………….20
5. Progettazione di Database relazionale……………………………………………………………...23
5.1 Progettazione concettuale: il Modello Entità-Relazione……………………………………23
5.2 Progettazione Logica di un Database Relazionale………………………………………….24
5.3 Diagramma Entità – Relazione per lo Smartcare…………………………………………...25
5.4 Progettazione Logica: le Tabelle di Smartcare……………………………………………...28
5.5 Creazione delle tabelle per i dati generali…………………………………………………..29
5.6 Implementazione del database in MySQL…………………………………………………33
6. Privacy e trattamento dei dati sensibili attraverso sistemi di elaborazione digitale…………………….34
6.1 Dati generali e dati sensibili dell'utente…………………………………………………….35
7. Infrastruttura di rete SMARTcare ………………………………………………………………….37
8. Progettazione database Farmacovigilanza…………………………………………………………..39
9. Conclusioni………………………………………………………………………………………...41
10. Bibliografia ………………………………………………………………………………………43
INTRODUZIONE
Tra gli obiettivi principali dell’Organizzazione Mondiale della Sanità (OMS), Agenzia delle
Nazioni Unite specializzata per le questioni sanitarie, c’è sia “il raggiungimento, da parte di
tutte le popolazioni, del più alto livello possibile di salute", definita come “uno stato di
totale benessere fisico, mentale e sociale”, e sia ridurre il trend stimato di morte per malattia
cronica del 2% ogni anno fino al 2015.1 Questa riduzione potrebbe evitare il decesso di 36
milioni di persone nei prossimi dieci anni. Secondo l’OMS in Europa le malattie croniche
provocano almeno l’86% dei morti e il 77% del carico di malattia. Per questo motivo la
lotta alle malattie croniche rappresenta una priorità della Sanità Pubblica, sia nei Paesi più
ricchi che in quelli più poveri. L’epidemia è più drammatica nei Paesi a basso e medio
reddito, dove si verificano l’80% di tutte le morti per malattia cronica. Il rapporto Oms
fornisce dati relativi a nove Paesi: Brasile, Canada, Cina, India, Nigeria, Pakistan, Russia,
Gran Bretagna e Tanzania. Inoltre, dà anche nuove proiezioni dell’impatto economico delle
malattie croniche. Per esempio, in Cina, India e Russia miliardi di dollari potrebbero andare
perduti nei prossimi dieci anni a causa di queste patologie. La stima delle perdite totali, solo
nel caso della Cina, tra il 2005 e il 2015, è pari a 558 miliardi di dollari, a 236 per l’India e a
303 per la Russia1. Per risolvere questi problemi è necessario coinvolgere tutte le strutture
governative, l’industria privata, la società civile e le comunità, che dovrebbero collaborare
congiuntamente. Di qui la necessità di investire nel controllo di queste malattie ma anche
nella prevenzione. Diventa perciò importante la ricerca di strumenti e strategie che
consentano di aiutare la comunicazione tra medici e pazienti al fine di intervenire il prima
possibile. Si parla di prevenzione, di diagnosi precoce, e di possibilità di intervento
immediato nei casi estremi.
Le metodologie e tecnologie odierne potrebbero venire incontro a queste necessità,
educando e formando medici e pazienti, all'utilizzo di software o di dispositivi hardware
indispensabili per la salute del paziente. I primi veri segnali in questa direzione si sono avuti
già alcuni anni fa, quando la sempre maggiore diffusione di internet ha favorito la
condivisione di dati clinici e il confronto tra i medici su questioni prettamente terapeutiche.
Da quel momento in avanti si è assistito ad un progressivo coinvolgimento del paziente nei
percorsi di cura e, di pari passo ad un aumento dell’attenzione verso il proprio stato di
salute. In generale è stata osservata:
1
 una maggiore familiarità2 nell’utilizzo di dispositivi mobili in grado di raccogliere
informazioni relative allo stile di vita, registrare l’attività fisica e misurare parametri
fisiologici;
 frequentazione2 dell’ambiente web alla ricerca di rapporti diretti basati sul confronto
tra medici;
 diffusione della connessione internet veloce2 che ha reso più facile accedere alle
informazioni, ai servizi e alle applicazioni interattive presenti in rete.
Un’indagine condotta dal Pew Research Center’s Internet and American Life project
evidenzia che3:
 l’80% delle persone cerchi online informazioni in ambito salute;
 il 15-20% cerchi un secondo parere riguardo una diagnosi rifacendosi all’esperienza
altrui;
 la percentuale complessiva di dati clinici che sono effettivamente presenti in rete
nella modalità open non supera il 30% (essenzialmente dati dei pazienti costituiti, in
gran parte, dagli aspetti meno tecnici della diagnosi e della terapia);
 nel rimanente 70% vi è la componente più importante di questi dati, incluse le loro
rielaborazioni in senso epidemiologico e prospettico.
Partendo da simili considerazioni il lancio di piattaforme di self-tracking e condivisione
cloud di informazioni cliniche (come l’Apple Healthkit) potrebbe avere numerose
conseguenze positive. Di qui nasce l’idea di creare un’applicazione gratuita, attraverso l’uso
di una piattaforma cloud, in grado di consentire il monitoraggio di dati privati in tempo
reale da parte di medici, o da parte di chiunque voglia utilizzare questa nuova tecnologia.
L’utilizzo dell’applicazione di Smartcare proposta in questo progetto consente di
monitorare in maniera costante lo stato di salute del cliente attraverso la condivisione dei
dati con i propri supervisori (medici, personal trainer), e potrebbe essere esteso a tutti, cioè
anche a soggetti sani che controllano le proprie condizioni di salute e che seguono diete
particolari per ogni evenienza. Ad esempio l’applicazione potrebbe essere molto utile per
chi pratica sport. L’attività fisica4 in generale apporta innumerevoli benefici sia al corpo che
alla mente e in particolare irrobustisce il fisico e aiuta a prevenire le malattie. L’attività fisica
è molto importante anche perché sviluppa e aiuta a mantenere sano l'apparato osseo, aiuta
a ridurre lo stress, e consente di mantenere un ridotto contenuto di grassi corporei oltre che
ad abbassare la pressione sanguigna. Per cui diventa importante curare il cliente che intende
intraprendere un percorso sportivo, per il benessere fisico e mentale dello stesso.
2
Statisticamente circa il 60% degli sportivi4 abbandona la palestra dopo qualche mese, e la
maggior parte dei motivi sono: il non raggiungimento degli obiettivi che il cliente si era
prefissato e il non essere seguiti. Tutto ciò è facilmente prevedibile se ci si ricollega alle
peculiarità individuali fisiche5, somatiche o psicologiche, di cui bisogna assolutamente tener
conto quando ci si avvicina ad uno sport. Ed è qui che subentra la figura del personal
trainer che studia caso per caso ed è chiamato ad applicare le sue competenze
tecnico/scientifiche sul singolo cliente. I personal trainer lavorano sul corpo umano per cui
è scontato che debbano conoscere nella maniera più approfondita possibile: anatomia,
fisiologia, biomeccanica muscolo-scheletrica e esercizi specifici per correggere, modellare o
per migliorare il benessere fisico del cliente. Ovviamente i personal trainer non sono
chiamati a fare diagnosi ma devono obbligatoriamente valutare il soggetto per poterci
"lavorare su” nel miglior modo possibile. Sarebbe molto utile che il personal trainer così
come il medico potessero seguire il proprio cliente, analizzando i suoi dati, monitorandoli
costantemente e suggerendo anche in tempo reale le “azioni” da svolgere per migliorarne le
condizioni psico-fisiche.
1. LA TECNOLOGIA NELLA SANITÀ
La cartella clinica6 è uno strumento utilizzato per gestire i dati clinici del paziente, dati che
vengono raccolti durante gli incontri con gli operatori sanitari a scopo di prevenzione, o
quando si manifestano episodi di malattia. La classica cartella cartacea ha perso di efficacia
in quanto il continuo miglioramento del processo di cura ha portato la versione cartacea a
diventare sempre più voluminosa, con una grande varietà di fonti da cui attingere
documenti ed informazioni, e ha reso più difficile consultare e trovare tempestivamente le
informazioni necessarie. Pertanto la cartella clinica informatizzata è diventata l’evoluzione
elettronica della cartella cartacea. Per rendere più facilmente disponibile una cartella clinica
elettronica si è pensato di realizzare un’applicazione chiamata Smartcare completamente
gratuita che consente l’inserimento dei dati garantendone la privacy. Il percorso necessario
e di prassi per poter realizzare uno strumento del genere prevede la creazione e sviluppo di
un modello che miri a cercare le strategie migliori per sviluppare e distribuire lo stesso
prodotto.
3
2. CONCETTI GENERALI DI BUSINESS MODEL
Negli ultimi anni la rete web ha acquisito sempre più rilevanza nella vita delle persone e
delle organizzazioni; l’utilizzo di tecnologie innovative è andato sempre più moltiplicandosi
ed affinandosi nel tempo, la crescita di mercati emergenti ed una costante evoluzione dei
processi di globalizzazione, hanno determinato un forte interesse verso i “business
models7,8 ”, non solo nella mente dei ricercatori e degli studiosi ma anche all’interno delle
imprese e delle organizzazioni che hanno visto subentrare nel loro mercato di riferimento
nuovi “competitors”, la cui forza principale era quella di implementare un business model
innovativo. Per cui il primo passo necessario per lanciare un nuovo prodotto/servizio, o per
avviare una startup ad alto valore, consiste nel creare il proprio modello di business. In
questo modo sarà possibile stabilire con precisione “cosa” bisogna fare, “come” bisogna
farlo e “per quali precisi clienti” l'azienda vuole creare valore. Infatti il compito principale
di ogni impresa è fornire valore al cliente8, un valore che sia superiore alla concorrenza e
che sia al tempo stesso in grado di garantire all’impresa una sicura redditività. Un’impresa
per avere successo deve definire in maniera chiara il modo in cui rende disponibile e
distribuisce il valore al cliente. L’offerta del prodotto di valore deve far cogliere al cliente gli
elementi di differenza e superiorità dell’impresa rispetto alla concorrenza8, delineando tutte
le fasi che vanno dall’analisi alla progettazione, alla distribuzione vera e propria del valore, e
all’esperienza di acquisto e consumo e cioè la cosiddetta customer experience. Ci sono una
serie di definizioni che contribuiscono a dare un significato esaustivo al business model. Tra
le principali definizioni ricordiamo :
- statement o descrizione9,10,11,12
- rappresentazione o modello9,13
- architettura o disegno di riferimento9,14
- insieme di strumenti di gestione o metodo9,15
- struttura o set9,16
Riassumendo il business model17si può definire come l’insieme delle soluzioni organizzative
logiche e strategiche attraverso cui l’impresa crea, distribuisce e cattura valore, al fine di
acquisire un vantaggio competitivo. Il business model, quindi, mira alla creazione di valore
per tutte le parti coinvolte nella sua architettura e ciò definisce l’entità del valore totale che
4
creerà. Il business model in particolare nel campo dell’innovazione presenta i seguenti punti
fermi9 :
- articolazione dell’offerta di valore, cioè il valore creato per i consumatori è basato
sull’innovazione. In questa fase è necessario individuare i motivi che potrebbero portare i
consumatori ad interessarsi al prodotto innovativo.
- identificazione del mercato di riferimento ;
- definizione della catena di valore grazie a cui l’impresa è in grado di creare e distribuire
l’innovazione;
- stima dei costi di struttura e dei profitti potenziali conseguibili dall’innovazione.
- descrizione della posizione investita dall’impresa all’interno dell’intero network con
conseguente identificazione di partners e competitors.
Un’analisi dettagliata di questi punti fermi del business model potrebbe portare gli
imprenditori stessi a modificare il modello al fine di renderlo adatto alla tipologia di valore
che si vuole proporre. Per questo motivo è possibile costruire sulla base di queste
modifiche una “road map9” da prendere come riferimento per facilitare lo sviluppo e
distribuzione del valore. Per lo sviluppo e progettazione dello Smartcare la road map
adottata è basata sul business Model Canvas9,17.
2.1 IL BUSINESS MODEL CANVAS8,17
Per creare e sviluppare modelli di business innovativi può essere usato il Business Model
Canvas, uno strumento strategico che vede l’utilizzo di un linguaggio visuale. In particolare
tale modello consente di rappresentare in maniera visiva il modo in cui un’azienda crea,
distribuisce e cattura valore. Questo modello scompone le componenti del business model
in nove blocchi17:
Attività primarie:
- key partners: questo primo blocco identifica tutti i partners con i quali l’azienda stringe le
relazioni chiave che si configurano come fonti del valore che verrà portato al cliente.
Queste relazioni possono avere svariate forme: alleanze, partnership e cooperazioni.
- key activities: ovvero tutte le attività necessarie alla creazione del prodotto;
- key resources: tutto ciò che serve all’azienda per riuscire a produrre valore: risorse fisiche,
intellettuali, umane e finanziarie;
5
- value proposition: descrive la proposizione del valore composta da tutto ciò che per i
clienti ha valore e quindi per il quale essi sono disposti a pagare;
- customer relationships: tutte le modalità attraverso cui l’azienda si relaziona con i clienti e
gestisce la relazione;
Figura 1. Business Model Canvas
- channels: l’insieme di mezzi attraverso cui il servizio/ prodotto dell’azienda raggiunge il
cliente attraverso comunicazione, distribuzione, rete di vendita;
- customer segments: ovvero i clienti divisi in segmenti in base a parametri prescelti
dall’azienda (geografici, bisogni, interessi, canali di distribuzione)
- cost structure: la definizione dei costi fissi e variabili che l’azienda deve sostenere per
sviluppare la propria offerta:
- revenue streams: ovvero l’insieme dei ricavi suddivisi per tipologia di cliente ed orizzonti
temporali.
6
2.2 BUSINESS MODEL DI CANVAS PER Smartcare
Il business model Canvas applicato allo Smartcare, un’applicazione in grado di monitorare
anche a domicilio la salute dei pazienti in maniera costante, è suddiviso in nove blocchi:
- Value Proposition : il prodotto è una piattaforma web e App mobile che consente
l’aggregazione, l’analisi e condivisione di informazioni sanitarie con i propri medici,
personal trainer o tutti coloro con cui si vorrà condividere i propri dati in tempo reale. La
piattaforma Smartcare si avvale di una collezione di Applicazioni mobile e dispositivi
medicali (ICE) che permettono di semplificare l’acquisizione dei dati e motivare l’utente a
tenere sotto controllo la propria salute in modo sistematico, come un gesto quotidiano di
cura della persona. Lo Smartcare presenta diverse funzionalità tra cui la possibilità di
collegarsi ad un braccialetto elettronico (ICE) usato per le emergenze e di farmacovigilanza.
L'implementazione di tale modello consentirà sicuramente al paziente di aggiornare
quotidianamente i dati relativi alla propria patologia o relativi alla propria attività sportiva,
in modo tale da tenere sempre aggiornato il proprio medico o il proprio personal trainer.
Inoltre lo Smartcare potrebbe essere molto utile per valutare la bontà di un farmaco e per
fare studi statistici di Farmacovigilanza attraverso l’uso di questionari posti in risalto
sull’interfaccia grafica dell’App. Il prodotto potrebbe essere subito disponibile sul web, o
addirittura potrebbe essere installato sul proprio Smartphone (come una cartella clinica
portatile ed elettronica), in cui inserire quotidianamente i propri dati. In questo senso
ovviamente sarà importante tutelare la privacy dei pazienti e dei dati recuperati dai centri o
medici che hanno in cura il paziente.
- Key Activities : Le attività chiave per rendere funzionante il modello potrebbero essere
le seguenti :
A1. Attività preliminare : Ricerca di dati demografici riguardanti la parte di popolazione
affetta da patologie e studi sulle attività da svolgere per migliorare il benessere psico-fisico
dei clienti appartenenti ad altre fasce. In modo tale da avere un'idea della necessità di
intervenire sul problema, in maniera immediata.
A2. Studio e ricerca di strategie mirate all'inserimento della tecnologia dello Smartcare nel mondo della
Sanità. Una delle possibili strategie potrebbe prevedere il coinvolgimento del settore della
Farmacovigilanza. I nuovi farmaci utilizzati nelle nuove terapie in fase di sperimentazione
clinica, richiedono infatti un monitoraggio continuo sugli effetti benefici e sugli effetti
7
avversi perlopiù ancora sconosciuti, così come la maggior parte dei farmaci richiede
continuo monitoraggio.
A3. Studio di strategie mirate ad aumentare la compliance del paziente, dello sportivo o di chiunque voglia
utilizzare il prodotto. Succede spesso che le terapie non vengono assiduamente seguite così
come anche le diete e le attività giornaliere sportive consigliate e ciò danneggia la salute del
cliente. L’utilizzo del prodotto potrebbe garantire continuità e efficacia nell’applicazione dei
suggerimenti terapeutici o relativi ad azioni da svolgere mirate a migliorare la salute. Tutto
ciò potrebbe anche richiedere lo sviluppo di “funzionalità che fungano da sensore” per
“richiamare il paziente” in determinate ore, giorni o periodi dell'anno, e invitarlo a
rispondere a domande specifiche miranti a monitorarne le condizioni fisiche e mentali.
A4. Individuazione lista campi e principali indici fisiologici o patologici da considerare per il monitoraggio.
A5. Ricerca di strategie per il rewind di dati forniti dalle persone sane e persone malate.
A6. Introduzione dell’App su una piattaforma Cloud. Questo punto è basato principalmente sul
concetto di servizio e sul concetto di Cloud. I servizi sono componenti computazionali
autonomi, che non dipendono dalla piattaforma e che possono essere pubblicati e
composti ottenendo reti di applicazioni distribuite. In questo modo l'applicazione diventa
un servizio disponibile sulla rete. Per la realizzazione dello Smartcare è necessario costruire
un backend e un frontend costituenti essenziali del cloud compunting. Il frontend è cio che
l'utente vede e, per essere visualizzato, è necessario che il computer dell'utente e
l'applicazione possano accedere al cloud. E' importante la creazione di interfacce grafiche
semplici e intuitive al fine di agevolare e migliorare l'impatto con il prodotto. Il backend è
invece il cloud vero e proprio (messo a disposizione da un potenziale fornitore) ed è quindi
composto da tutti quei dispositivi come computer, server-web e dispositivi di
memorizzazione dati (storage, database) che ovviamente necessitano di essere monitorati.
Sarà perciò necessario il monitoraggio del traffico di rete, amministrare il sistema e gestire
le richieste degli utenti da un server centrale. Questo segue determinate regole (i cosiddetti
protocolli) e sfrutta un software speciale chiamato middleware che dà la possibilità ai
computer nella rete di comunicare tra di loro.
A7. sviluppo d interfacce grafiche e di ulteriori implementazioni volte a realizzare tutti i moduli dell'APP.
A8. Studio della legislazione della privacy dei dati del paziente, per garantire la totale tutela dello stesso
paziente.
8
Attività secondarie:
B1. Formazione dei medici e dei pazienti sull'utilizzo del prodotto, e offerta di continuo supporto tecnico
agli stessi.
C1 Revisione. Studio e ricerca di migliorie finali del prodotto, in seguito alla conoscenza del
parere di medici e pazienti, e in seguito all'apprendimento delle loro ulteriori esigenze.
Correzioni errori attraverso lo sviluppo di eventuali implementazioni volte a migliorare
l'applicazione.
Customers Segment : sono i segmenti di clienti ai quali l'azienda si rivolge e cioè : 1)
medici di base, che in questo modo potranno avere in tempo reale tutte le informazioni
relative al paziente per poter intervenire in maniera tempestiva e vegliare in maniera
continuativa sulle condizioni di salute del cliente; 2) aziende ospedaliere pubbliche e
private; 3) medici di base e specialisti; 4) ASL di riferimento dei pazienti; 5) aziende
farmaceutiche; 6) i pazienti, che usufruirebbero dello Smartcare per inserire in qualunque
momento i propri dati; 7) chiunque necessiti di comunicare in tempo reale o raccogliere
dati giornalmente e condividerli, ad esempio persone che fanno sport a qualsiasi livello, o
che seguono diete particolari o indicazioni per la cura del benessere fisico e mentale.
Key Resources: le risorse chiave necessarie perché l'azienda funzioni :
- Programmatori in grado di creare il software necessario per la realizzazione dell'APP
completa. Inoltre, i computer possiedono processori multicore e sono collegati in rete per
cui gli ingegneri del software dovranno essere esperti anche nel calcolo distribuito e in
parallelo per sfruttare al meglio queste nuove tecnologie.
- Grafici e esperti in User Experience e User Interface per la progettazione di interfacce
grafiche intuitive e semplici per garantire usabilità e fruibilità adeguate e semplici sia per i
medici che per i pazienti.
- Sistemisti per la configurazione, gestione e manutenzione dei server dedicati in cloud.
- Programmatori per lo sviluppo della piattaforma web con relativa interazione con i
database.
- Risorse in grado di raccogliere dati relativi ai farmaci e in grado di poter supervisionarne
gli effetti benefici o nocivi attraverso stime statistiche.
- Aziende farmaceutiche (di farmaci o di integratori alimentare di qualunque tipo), diretti
(eventuali) fruitori del prodotto. In particolare per le aziende l'utilizzo del prodotto
potrebbe tornare utile per monitorare gli effetti avversi dei farmaci.
9
- Figure in grado di formare in modo adeguato il cliente e assistenti domiciliari disponibili
per aiutare il paziente o i suoi familiari e i medici nell'uso del prodotto.
-Formatori nelle scuole per educare anche i ragazzi ad un uso “Responsabile” e non
improprio dello Smartcare, sempre per il benessere della popolazione.
Customer Relationships : le relazioni che si instaurano con i clienti.
Relazionarsi con il cliente è fondamentale per consentire allo stesso di avere costantemente
un supporto per ogni eventuale chiarimento, e per consentire allo stesso di avere fiducia
nella potenzialità dello strumento tecnologico che si propone oltre che nella azienda
proponente.
Tra le figure di Customer Relationships si individuano: 1) intermediari, tipo infermieri
professionale o operatori socio-sanitari in grado di supportare il paziente nell'uso del
prodotto; 2) le scuole, ottimo veicolo con cui inserire il concetto dell'utilizzo della cartella
clinica elettronica, attraverso un'APP; 3) i medici e i personal trainer.
Channels: i canali di distribuzione e contatto con i clienti.
I canali di distribuzione potrebbero essere aziende private, aziende ospedaliere pubbliche,
medici di base, ASL (settore della farmacovigilanza), compagnie telefoniche.
Le scuole e palestre costituirebbero un altro strumento di distribuzione del prodotto.
Key Partnerships : ossia i partner chiave con cui l'impresa dovrà stringere alleanze.
- I partner chiave sono: i Medici, le strutture ospedaliere private e pubbliche, le compagnie
telefoniche a cui proporre l'inserimento dello Smartcare, e l'ASL, l'Istituto superiore di
Sanità che potrebbe magari essere interessato a raccogliere dati sull'epidemiologia delle
diverse patologie.
- Fornitori di piattaforme cloud.
Non rientrano nel lavoro qui di seguito riportato la definizione dei costi fissi e variabili che
l’azienda deve sostenere per sviluppare la propria offerta, e l’insieme dei ricavi suddivisi per
tipologia di cliente.
3. SMARTCARE
3.1 Cos'è Smartcare
Lo Smartcare è una piattaforma web supportata da un’APP mobile tramite cui l’utente
potrà inserire quotidianamente e in qualsiasi momento i dati (record, radiografie, etc)
relativi alle proprie condizioni di salute.
10
È sufficiente iscriversi via web all'applicazione e inserire i propri dati per poter disporre
delle numerose funzionalità di cui dispone, tra cui la possibilità di monitorare l'andamento
delle proprie attività sportive in termini calcolo di calorie da “bruciare, memo per gli
esercizi da svolgere, calcolo di km percorsi in corsa, monitoraggio continuo da parte del
proprio personal-trainer. Smartcare può essere utile anche per allertare il proprio medico o
centri di farmacovigilanza, su eventuali reazioni avverse dei farmaci. Nel complesso lo
Smartcare potrebbe diventare uno strumento utilissimo, multifunzionale e molto versatile.
3.2 Come funziona Smartcare
Si accede collegandosi al seguente link:
http://Smartcare.intacthealthcare.com
ci si registra inserendo nome, cognome, e-mail, codice fiscale, password, cioè dati generali.
L’ID_Utente e il codice fiscale consentiranno al medico di identificare il proprio cliente.
L'utente dopo essersi iscritto alla piattaforma, completerà il suo profilo inserendo tutte le
informazioni personali, di cui potrà definire la visibilità limitata al proprio medico di base, a
medici specialisti specifici, e ai propri familiari che garantiranno assistenza in casi di
emergenza. I familiari del cliente che usa Smartcare potranno inserire i propri dati in
schede dedicate in modo tale da consentire al medico curante di avere una visione completa
delle condizioni di salute del paziente e dei dati di ereditarietà. Lo Smartcare offre anche la
possibilità di utilizzare un forum in cui il cliente può fare domande e confrontarsi con tutti i
medici specialisti e aggiungerli alle persone di fiducia che hanno visibilità completa del
profilo. I dati del paziente rimarranno sempre tutelati da privacy. La privacy dei dati clinici
inseriti è garantita. Nella fase successiva alla registrazione infatti il cliente acconsentirà al
trattamento dei dati sensibili ai sensi dell'articolo 81 del D.Lgs.vo n. 196/200318. Nel caso di
minorenni sarà necessario che uno o entrambi i genitori, sottoscrivano il consenso e
“accompagnino” il minorenne nell'inserimento dei dati nello Smartcare. Anche i dati degli
sportivi e delle aziende saranno tutelati da privacy.
11
3.3 DATA MODELING DI SMARTCARE
Per la realizzazione dello Smartcare è necessario individuare e selezionare con cura i campi
che il cliente utilizzerà per inserire i propri dati generici e privati. Per fare questo come
prima cosa occorre pensare di dividere la mole di dati che il cliente inserirà nello Smartcare.
Perciò consideriamo due tipologie di dati: i dati generali di tutti gli utenti, come nome
cognome etc., e i dati privati del cliente stesso. Una lista di campi pensati e creati per
l’introduzione dei dati del cliente Smartcare, e in cui potranno essere inseriti caratteri
numerici e alfanumerici è la seguente:
Informazioni generali
Codice Fiscale
Nome
Cognome
Genere
Data di Nascita
Indirizzo
Email
Telefono
Gruppo sanguigno
Password
Anamnesi generale
Data
Altezza
Peso
Patologie croniche
Patologie presenti in famiglia (note libere)
Appetito (Normale/ Ridotto/Aumentato)
Calo ponderale ultimo anno
Età prima gravidanza
Figli
Aborti
Parto (Naturale o Cesareo)
Allattamento (Artificiale o Naturale)
12
Menarca ( Età prima mestruazione)
Mestruazioni (Regolari/Irregolari)
menopausa
Consumo di alcolici (Birra/Vino/Superalcolici/Aperitivo)
Consumo di tabacco SI NO
Stupefacenti (Morfina e simili/ Eroina /Cocaina /Amfetamine/LSD /Altro)
Uso di sostanze psicoattive
Malattie Esantematiche avute ( Morbillo/Scarlattina/Rosolia/Parotite/Quinta
malattia/sesta malattia/Varicella/Pertosse)
Vaccinazioni:
Difterite, tetano, pertosse
Poliomelite (IPV)
Epatite B
Haemophilus influenzae b
MPR(antimorbillo-rosolia-parotite)
Varicella
HPV (antipapilloma virus)
PCV (antipneumococco coniugato)
Men C (antimeningococco C)
Trapianti d’organo
Organo colpito
Dati privati
Occhi
Deficit visivo (da barrare con crocetta)
Vista (Emmetrope=nessun disturbo, Miope=Non mette a fuoco oggetti lontani,
Ipermetrope= Non mette a fuoco oggetti vicini, Astigmatico= Vede l'immagine deformata
secondo una direttrice)
Fundus oculare (in caso di patologie a carico della retina)
13
Orecchie
Deficit uditivo (da barrare con la crocetta) Orecchio DS o Orecchio SN
Utilizzo di protesi uditive
Presenza di protesi
Numero
Localizzazione protesi (Testa/Denti/Torace/Braccia/Gambe)
Mutilazioni o minorazioni fisiche della mobilità
Allergie
alimenti
sostanze chimiche
metalli
farmaci
acari della polvere
piante
glutine
lattosio
proteine del latte
altre tipologie di allergie (note)
Cuore
Affezioni cardiovascolari
Cardiopatie
Aritmie
Malattie congenite cardiache (quali?)
Pressione sist/diast (pressione minima e massima): Normale/ Iperteso
Infarto miocardio o cardiopatie ischemiche
Bypass coronarici o stent
sostituzione valvole cardiache
Aneurisma
14
Sistema nervoso e malattie neurologiche
Malattie del Sistema Nervoso centrale (quali?)
Morbo di Parkinson Si/No
Alzheimer
Soffri di attacchi epilettici? Si/No
Distrofia
Sclerosi multipla
Altro
Apparato respiratorio:
ASMA
Malattie respiratorie (quali?)
Apparato escretore, malattie metaboliche
Malattie endocrine (quali?)
Malattie metaboliche (quali?)
Diabete (Tipo diabete)
Tipo 1 : Insulina utilizzata: Breve/media/lunga durata
Tipo 2 : Farmaco utilizzato: Solfoniluree/Biguanidi/Glitazoni/Inibitori dell alfaglucosidasi/Altro
Reni
Calcolosi renale?
Diuresi (normale/anormale)
Insufficienza renale ? Nessuna/Acuta/Cronica
Malattie renali(quali?)
Malattie del sangue
Anemia (da carenza di ferro/ da carenza di B12/emolitica, tipo di anemia)
Talassemia? (alfa / beta /mediterranea)
Leucemie
Linfomi
Mieloma multiplo
Emofilia
15
Difetti di coagulazione
Altro
Malattie sistema immunitario
malattie croniche/autoimmuni
artrite reumatoide
spondilite
Dermatomiosite
lupus eritematoso
vasculiti
artrosi
Sclerodermia
Psoriasi
Gotta
Osteoartrosi
Altro
Malattie infettive
Agenti infettivi
Gonorrea
Sifilide
Gardnerella
Chlamydia trachomatis
ureaplasma urealyticum
trichomonas vaginalis
AIDS
HPV (Papilloma Virus)
Epatite B,C
Tumori
organo colpito
(Ossa/Cervello/Sangue/Pelle/Polmoni/Stomaco/Colon/Ovaie/Testicoli/Vescica/Reni/I
ntestino/Pancreas/Tiroide/Cuore/Occhi)
Tipo di terapia utilizzata
16
Chemioterapia
Radioterapia
Uso di terapie a base di anticorpi monoclonali o altro
Interventi subiti (numero e organi colpiti)
Farmaci usati
Malattie urogenitali
Iperplasia prostatica
Disfunzione erettile
Tumori uterini
Cisti ovariche
Endometriosi
Infezioni frequenti
Altro
Farmaci assunti
DATI GIORNALIERI :
Dato_identif_per utente ( Pressione dell’occhio, Indice glicemico, VES, PCR etc..)
Data inserimento
Pressione
Diuresi
Note
Funzionalità respiratorie
Frequenza cardiaca
Diagnosi di medico o personal trainer datata
Farmaci assunti giornalmente
Alimentazione (proteica, glicidica, carica di grassi o carica di zuccheri)
Consigli alimentazione
Scheda esercizi fisici da fare ogni giorno per ogni sport praticato
Durata tipologia di esercizi (giornalieri, settimanali o mensili)
Dimagrimento
Massa
Forza
Definizione
17
Possibilità di inserimento immagine di esercizi fisici specifici da consigliare al cliente.
Upload Analisi
Hb(concentrazione emoglobina nel sangue)
Ferritemia(riserva epatica di ferro)
Sideremia(concentrazione del ferro nel sangue)
Piastrine
Azotemia(concetrazione urea nel sangue)
Bilirubina
Creatinina
Trigliceridi
HDL(Aggregati colesterolo ad alta densità, “benigni”)
LDL(Aggregati colesterolo a bassa densità,”nocivi”)
Glicemia (Concentrazione glucosio nel sangue)
Globuli bianchi
Transaminasi(Proteina essenzialmente epatica o muscolare, indica danni a carico di questi
organi)
TSH/FT3/FT4(Ormoni tiroidei circolanti)
Aldosterone (Ormone delle surrenali, importante nel controllo della pressione)
Analisi specifiche in base alla patologia (possibilità di upload) o in base al consiglio del
personal trainer.
Tutti i campi e quindi sia i dati privati che generali devono perciò essere immagazzinati in
un database che ne consenta una facile fruizione. Perciò è necessario pensare alla
realizzazione di un database ad hoc per lo Smartcare.
4. LE BASI DI DATI E I SISTEMI DI GESTIONE DELLE BASI DI DATI
I dati possono essere suddivisi in tre distinte tipologie19: dati di input che corrispondono a
dati che devono essere inseriti nel database e dati isolati le cui associazioni non sono ancora
stabilizzate; una volta inseriti nel database questi dati occupano il posto a loro destinato
nello schema informativo ed attivano le associazioni logiche da essi realizzate: in questa
fase si parla di dati operazionali. Quando lo schema informativo viene interrogato, e
18
vengono ricercati i dati opportuni, navigando attraverso lo schema e le sue associazioni
logiche, si ottengono i dati richiesti che sono presentati come dati di output. Per cui un
database può essere definito come una collezione di dati operazionali memorizzati ed
utilizzati dalle applicazioni di un’organizzazione. I dati sono separati in entità e associazioni.
Le entità sono gli oggetti fisici, i documenti, le persone; le associazioni invece sono i fatti
che le coinvolgono. L’ANSI19 (American National Standard Institute) su proposta dello
SPARC (System Planning and Requirements Committee) ha costituito un gruppo di studio
con lo scopo di fornire alcuni standard nella realizzazione degli aspetti funzionali di un
DBMS (Database Management System). Un DBMS20 è un sistema o prodotto software in
grado di gestire collezioni di dati che siano grandi di dimensioni, persistenti (con un
periodo di vita indipendente dalle singole esecuzioni dei programmi che le utilizzano),
condivisi (utilizzate da applicazioni diverse) e in grado perciò di garantire affidabilità
(resistenza ai malfunzionamenti hardware e software) e privatezza (cioè con una certa
disciplina e controllo degli accessi). In particolare ogni DBMS deve essere efficiente perché
è necessario utilizzare al meglio le risorse di spazio e tempo del sistema ed efficace per
rendere produttive le attività dei suoi utilizzatori.
In particolare l’ANSI ha stabilito che I DBMS19 (Database Management System)
presentano un’architettura a tre livelli: il livello di riferimento è la definizione (schema)
concettuale del database; a questo corrispondono (da parti opposte) il livello del database
fisico ospite della macchina e del suo software di base, ed il livello esterno attraverso il
quale il database viene percepito dagli utenti. Tra i DBMS più conosciuti ricordiamo:
Oracole, MySQL, Mongo DB. I problemi principali che si possono riscontrare nei DBMS
sono la ridondanza ossia le informazioni ripetute, e i rischi di incoerenza.
4.1 IL MODELLO DEI DATI DI UN DATABASE20
I modelli di dati di un database possono essere :
1. Relazionali, ossia modelli che permettono di definire tipi per mezzo del costruttore di
relazione, e che consentono di organizzare i dati in insiemi di record a struttura fissa.
2. Gerarchici cioè basati sull’utilizzo di strutture ad albero.
3. Reticolari e cioè basati sull’uso di grafi, e sviluppati successivamente al modello
gerarchico.
19
4. Database a Oggetti, ossia sviluppati come evoluzione del modello relazionale negli anni
80. Principalmente abbiamo due tipi di modelli più diffusi e cioè i modelli logici, utilizzati
nei DBMS esistenti per l’organizzazione dei dati, indipendenti dalle strutture fisiche
(esempi: relazionale, reticolare, gerarchico, a oggetti) e modelli concettuali. Questi
permettono di rappresentare i dati in modo indipendente da ogni sistema e cercano di
descrivere i concetti del mondo reale. Il più noto è il modello Entity-Relationship.
In particolare in ogni base di dati esistono: gli schemi che ne descrivono la struttura che
rimane invariata nel tempo e le istanze ossia il corpo delle tabelle. Le transazioni effettuate
sui DBMS godono delle cosiddette proprietà logiche ACID20 ossia Atomicity, Consistency,
Isolation, e Durability (Atomicità, Coerenza, Isolamento e Durabilità). Affinchè le
transazioni operino in modo corretto sui dati è necessario infatti che i meccanismi che le
implementano soddisfino queste quattro proprietà: atomicità: consiste nel fatto che la
transazione è indivisibile nella sua esecuzione e la sua esecuzione deve essere o totale o
nulla, infatti non sono ammesse esecuzioni parziali; consistenza: quando inizia una
transazione il database si trova in uno stato coerente e quando la transazione termina il
database deve essere in un altro stato coerente, ovvero non deve violare eventuali vincoli di
integrità, quindi non devono verificarsi contraddizioni (inconsistenza) tra i dati archiviati
nel DB; Isolamento: ogni transazione deve essere eseguita in modo isolato e indipendente
dalle altre transazioni, l'eventuale fallimento di una transazione non deve interferire con le
altre transazioni in esecuzione; Durabilità: detta anche persistenza, si riferisce al fatto che
una volta che una transazione richiede un commit work, i cambiamenti apportati non
dovranno essere più persi.
4.2 I DATABASE RELAZIONALI (RDBMS)
L’obiettivo del modello di database relazionale è quello di affrancare le applicazioni da
qualsiasi forma di dipendenza dai dati, svincolando il database sia dalla loro organizzazione
che dalle loro vie d’accesso. I database relazionali sono molto flessibili e concettualmente
semplici, il linguaggio con cui vengono interrogati è basato principalmente sui concetti di
insiemistica. Nel modello relazionale i dati si inseriscono in tabelle bidimensionali, dette per
l’appunto “relazioni21”. Ogni riga di una tabella rappresenta una tupla della relazione e
ciascuna colonna è detta attributo. I valori degli attributi vengono scelti nell’ ambito di
classi o gamme di valori accettabili (domini).
20
I database relazionali risultano basati su dei valori e non su degli indirizzi di
memorizzazione. Ad esempio, il modo in cui sono ordinate le righe e gli attributi non è
significativo e ciascun valore deve essere di tipo atomico, cioè elementare. Non sono
pertanto ammessi nè vettori mono o pluridimensionali nè strutture composte. Se non è
fatta in questa maniera, una relazione si presenta nella cosiddetta “prima forma normale”,
che tuttavia può ancora contenere delle dipendenze funzionali e dare quindi luogo a delle
anomalie in occasione di operazioni di inserimento, cancellazione,
aggiornamento. Per cui, come tecnica di progettazione, conviene suddividere una relazione
in due o più “tronconi”: in questo processo verranno perciò eliminate le anomalie
ottenendo così la normalizzazione dei dati. Inoltre un database non è relazionale se non
viene percepito dall’utente come un insieme di relazioni. In un database relazionale la
rappresentazione dei dati avviene come abbiamo detto senza dover descrivere dove si
trovano fisicamente i dati. Con i DBMS non relazionali invece il progettista di
un’applicazione è spesso tenuto a conoscere e rispettare una sequenza fisica dei dati. I
database relazionali inoltre sono caratterizzati da integrità referenziale, e per creare tale
integrità è necessario creare una chiave primaria in una tabella. Le chiavi21 sono campi
speciali che giocano ruoli specifici, infatti il tipo di chiave determina il proprio scopo
all’interno della tabella. Ci sono diversi tipi di chiave, ma in questo lavoro faremo
riferimento solo a due tipi principali di chiave e cioè la chiave primaria e la chiave esterna.
In particolare la chiave primaria è un campo o un gruppo di campi che identifica in modo
univoco ogni record all’interno della tabella. Quando una chiave primaria è composta da
due o più campi, viene denominata chiave primaria composita. La chiave primaria è
importante perché il suo valore identifica un record specifico nell’interno del database,
mentre il suo campo identifica una data tabella nell’intero database. Le chiavi primarie21
inoltre rafforzano l’integrità del livello di tabella e aiutano a stabilire delle relazioni con le
altre tabelle. Le chiavi esterne invece sono importanti non solo perché aiutano a stabilire
relazioni tra coppie di tabelle, ma anche perché aiutano ad assicurare l’integrità del livello di
relazione. Questo significa che le registrazioni nelle tabelle considerate nella progettazione
di un database, saranno sempre propriamente legate perché i valori della chiave esterna
dovranno derivare dai valori della chiave primaria alla quale si riferiscono. Le chiavi esterne
aiutano ad evitare i record orfani, di cui un esempio classico è un record d’ordine senza un
cliente di riferimento, infatti se non si conosce chi ha inoltrato l’ordine, questi non può
essere effettuato.
21
Una dipendenza di chiave esterna è una regola specificante che, a meno che la chiave
esterna non sia nulla, deve sempre corrispondere ad un valore della chiave primaria. Le
dipendenze di chiavi esterne sono rafforzate dall’imposizione di regole19 sulle operazioni di
manipolazione dei dati, quali:
1. REGOLE PER L’INSERIMENTO
No action: non permette l’aggiunta di un record a meno che la chiave esterna sia
nulla o vi sia una corrispondente chiave primaria nella tabella primaria. Si noti che è
possibile specificare che il valore nullo non è ammesso in una colonna, incluse quelle
della chiave esterna.
2. REGOLE PER L’AGGIORNAMENTO
No action: non permette di dare un valore non nullo ad una chiave esterna a meno
che vi sia una corrispondente chiave primaria nella tabella primaria. Non permette
l’aggiornamento di una chiave primaria se esistono righe con una corrispondente
chiave esterna. Restrict: identico a NO ACTION, eccetto che il controllo è immediato.
3. REGOLE PER LA CANCELLAZIONE
No action: non permette la cancellazione di una riga nella tabella primaria se esiste
una riga con chiave esterna corrispondente.
Restrict: identico a NO ACTION, eccetto che il controllo è immediato.
Cascade: quando una riga nella tabella primaria viene cancellata, vengono cancellate
anche tutte le righe con corrispondente chiave esterna.
Set null: imposta al valore nullo le colonne delle chiavi esterne che possono assumere
tale valore quando viene cancellata la riga con la corrispondente chiave primaria.
Set default: imposta al valore di default tutte le colonne della chiave esterna quando
la riga della corrispondente chiave primaria viene cancellata.
Le chiavi primarie sono dunque degli identificatori univoci di righe e sono costituite dal
numero minimo di attributi necessari per differenziare ciascuna riga della tabella da tutte le
altre (di chiavi primarie ce ne possono essere più di una, ed in tal caso la scelta spetta al
progettista). Le chiavi primarie non possono contenere valori nulli e devono avere un
significato. Per salvaguardare l’integrità delle entità, bisogna infatti che nessuno degli
attributi presenti in una chiave primaria contenga un valore nullo. Inoltre, nessuno degli
attributi che costituiscono una chiave primaria può essere eliminato senza rinunciare
all’univocità dell’identificazione. L’altra regola è quella dell’integrità referenziale ed assicura
non solo che le tabelle siano correlate tra loro, ma che lo siano in modo non ambiguo.
22
Ogni valore di una chiave deve infatti esistere come valore di una chiave primaria in
un’altra tabella o essere nullo. Una chiave esterna è un attributo (o una combinazione di
attributi) di una tabella i cui valori devono corrispondere a quelli della chiave primaria di
un’altra tabella o essere nulli, ossia non avere alcun valore. Le chiavi esterne devono essere
definite nell’ambito della stessa gamma di valori o dominio. I linguaggi utilizzati per la
manipolazione dei dati in un RDBMS possono essere molteplici, in particolare in questo
lavoro è stato usato SQL. Il modello relazionale usa le operazioni dell’albegra relazionale
di selezione di righe, fusione di tabelle e proiezione di colonne (select, join e project) per
reperire o estrarre i dati delle tabelle: tali operatori manipolano tabelle e restituiscono
tabelle, cioè insiemi di righe e colonne.
5. PROGETTAZIONE DI UN DATABASE RELAZIONALE22
1. Analisi dei requisiti. In questa fase vengono analizzate le necessità informative e le
transizioni da soddisfare.
2. Progettazione concettuale. Nella fase di progettazione concettuale viene analizzato
l'insieme dei dati informativi, per cui vengono individuate e definite le entità e le
associazioni coinvolte al fine di formalizzarne l'insieme. Le associazioni possono esistere tra
entità e sono da non confondere con le tabelle o le relazioni del database. La fase di
progettazione concettuale rappresenta perciò la prima fase di lavoro per la realizzazione di
un Database relazionale, in cui viene rappresentato il contenuto della base di dati
prescindendo dal modo in cui i dati saranno rappresentati nel modello di Database scelto.
3. Progettazione logica. Rappresenta lo step successivo nella realizzazione di un database
relazionale e si basa sullo schema generato dalla fase precedente e lo traduce nel modello
della base di dati adottata. Per esempio, nel modello relazionale, lo schema viene tradotto in
un insieme di relazioni (tabelle) con definite le chiavi primarie ed esterne.
4. Progettazione fisica. Traduce lo schema logico in termini delle tabelle e relazioni.
23
5.1
PROGETTAZIONE
CONCETTUALE22:
IL
MODELLO
ENTITÀ-
RELAZIONI
In un Database Relazionale il modello concettuale dei dati più diffuso è il modello EntitàRelazioni. Lo schema Entità-Relazioni22 è costituito da un diagramma che contiene alcuni
elementi fondamentali:
- Le Entità: rappresentano una classe di oggetti di interesse che hanno caratteristiche
comuni. Vengono rappresentate da un rettangolo all'interno del quale vengono inserite
delle etichette che identificano l'entità.
- La Relazione: tra due o più entità possono esistere delle relazioni o legami logici. La
relazione viene indicata con un rombo in cui viene scritta un’etichetta che la identifica.
Nei rami della relazione viene specificata la cardinalità della relazione che descrive il
numero minimo e massimo di istanze della relazione cui una istanza dell'entità può essere
collegata. In base alla cardinalità le relazioni possono essere di tre tipi :
- 1:1 Una coppia di Entità può intrattenere una relazione Uno a Uno quando un unico
record di una tabella è legato ad un unico record di una seconda tabella e un solo record
della seconda tabella è legato ad un solo record della prima tabella La relazione avviene
prendendo la Chiave Primaria della tabella principale ed inserendola nella seconda tabella
dove diviene Foreign Key. Questo è un tipo particolare di relazione, perché in molti casi la
Foreign Key diviene Chiave principale della seconda tabella.
- 1: N Quando una coppia di tabelle presenta una relazione Uno a Molti, vuol dire che un
singolo record della prima tabella può essere legato a molti record della seconda tabella, ma
un singolo record della seconda tabella può essere legato con un unico record della prima
tabella. Questa relazione è stabilita prendendo la Chiave Primaria della tabella dal lato
“Uno” ed inserendola nella tabella dal lato “Molti” dove diviene Foreign Key.
- N:N Un a coppia di tabelle intrattiene una relazione molti a molti quando un singolo
record della prima tabella può legarsi a molti record della seconda tabella e un singolo
record della seconda tabella può legarsi a molti record della prima tabella. Per stabilire
questa relazione è necessario creare una tabella di collegamento, che fornisce un modo
semplice di associazione dei record di una tabella con quelli di un’altra. Una tabella di
collegamento viene definita prendendo una copia delle Chiavi Primarie di ciascuna tabella
della relazione ed utilizzandole per formare la struttura della seconda tabella.
24
Questi campi rivestono due ruoli distinti e formano la Chiave primaria composita della
tabella di collegamento, mentre separatamente ciascuna serve come Foreign Key.
- L' Attributo: è una proprietà dell'entità o della relazione. Esiste un identificatore che è un
attributo particolare che in maniera univoca una istanza dell'entità e corrisponde alla chiave
primaria. Il simbolo che si usa per indicarlo è un cerchietto finale pieno.
5.2 PROGETTAZIONE LOGICA DI UN DATABASE RELAZIONALE
Il secondo passo nella progettazione di un database è quello di creare un Modello
Relazionale in cui i dati di un database sono immagazzinati in relazioni, che all’utente
appaiono sotto forma di tabelle. Ogni tabella o relazione è composta da tuple (records,
righe) e attributi (fields, campi, colonne). Un database perciò è costituito principalmente da
tabelle e ciascuna tabella rappresenta un soggetto unico. Non è importante in una tabella
l’ordine logico dei record cosi come l’ordine dei campi. Ogni tabella contiene almeno un
campo chiamato Chiave Primaria che identifica ogni record in modo univoco. In questo
modo i dati in un database relazionale possono esistere indipendentemente dal modo in cui
sono stati immagazzinati. Nella fase di progettazione logica22 le entità del diagramma entità
relazione, diventano tabelle. Il soggetto rappresentato in ogni tabella può essere sia un
oggetto che un evento, entrambi possono essere immagazzinate come dati.
5.3 DIAGRAMMA ENTITÀ - RELAZIONI PER LO SMARTCARE
Per comprendere meglio l'uso del Diagramma Entità-Relazioni lo applichiamo al fine di
realizzare un Database Relazionale in MySQL che supporti lo Smartcare.
Nel diagramma Entità-Relazione dello Smartcare, le entità sono :
Utente_dati_generali a cui fanno riferimento le persone di fiducia (i familiari), i pazienti,
i medici di base e specialisti, gli sportivi, i personali trainer e i soccorritori, che inseriranno i
loro dati generali nei campi indicati e uguali per tutti. La modalità per esprimere la
dipendenza di una entità da un’altra entità al fine di ereditarne tutti i suoi attributi è la
generalizzazione o generalizzazione IS-A24 che consiste in legami logici tra un'entità E detta
entità Padre e una o più entità E1...En, dette entità figlie, di cui E è più generale nel senso
che le comprende come caso particolare.
25
Si dice che in questo caso E è generalizzazione di E1….En e che E1,...En sono
specializzazioni dell'entità E.
Quindi Utente è la generalizzazione di persone di fiducia, medici, personal trainer,
soccorritori, atleti o sportivi. Per contro, le entità appena indicate rappresentano le
specializzazione dell'Utente. Tra le entità coinvolte in una generalizzazione valgono le
proprietà generali riportate di seguito. Ogni occorrenza di un'entità figlia è un'occorrenza
dell'entità padre. Ogni proprietà dell'entità padre (attributi, identificatori, relazioni e altre
generalizzazioni) è anche una proprietà delle entità figlie. Per esempio se l'entità
Utente_dati_generali ha come attributi nome, cognome, anche le entità figlie avranno gli
stessi attributi che andranno a completare le specializzazioni (ulteriori specifici attributi
caratteristici di ciascuna entità figlia) delle entità figlie. Questa proprietà delle
generalizzazioni è nota come ereditarietà. Le generalizzazioni vengono rappresentate
graficamente mediante delle frecce che congiungono le entità figlie con le entità padre, e
per le entità figlie, le proprietà ereditate non vanno rappresentate esplicitamente.
Le generalizzazioni possono essere classificate sulla base di due proprietà tra loro
ortogonali24:
- una generalizzazione è totale se ogni occorrenza della classe padre è almeno
un'occorrenza di almeno una delle entità figlie, altrimenti è parziale.
- una generalizzazione è esclusiva se ogni occorrenza della classe padre è al più una
occorrenza delle entità figlie, altrimenti è sovrapposta.
Nel nostro caso parliamo di generalizzazione totale, perché tutte le occorrenze dell'utente
generale sono anche occorrenze delle entità figlie, per cui tutte le figure individuate sono
utenti che inseriscono dati generali comuni o che accedono al database. Inoltre la
generalizzazione è al tempo stesso anche esclusiva, perché ogni utente poi si distingue come
familiare, medico, paziente, sportivo, personal trainer o soccorritore, evidenziando le
proprie caratteristiche. La chiave primaria dell’entità Utenti_dati_generali è l’ID_UTENTE
che costituirà l’identificatore esterno per le altre specializzazioni e che sarà creato in
automatico dal database. Questo vuol dire che in ciascuna entità ci sarà una chiave primaria
specifica per quell’entità e un ID_Utente che fungerà da chiave esterna di collegamento con
la tabella di Utente_dati_generali. In questa prima tabella esiste anche una chiave secondaria
individuata nel codice fiscale (CF).
Inoltre tra le diverse specializzazioni di utente esistono delle relazioni o vincoli di chiave, ad
esempio un paziente può selezionare più persone di fiducia (cardinalità 1,N) e le persone di
26
fiducia possono accedere ai dati del paziente o di più pazienti a loro assegnati (cardinalità
1,N). Per quel che riguarda la relazione medico paziente la cardinalità è sempre del tipo
1,N e sarà intesa come possibilità di accesso dei medici selezionati a più pazienti, o come
effettiva selezione di medici da parte dei pazienti. In più i medici potranno in tempo reale
fornire N referti a N pazienti, con riportata la relativa data. Nella sezione dedicata agli
sportivi invece ci saranno personal trainer (cardinalità 1,N) che potranno essere selezionati
da N sportivi(cardinalità 1,N) in quanto uno sportivo potrà svolgere più attività ed essere
seguito da più allenatori. Viceversa i personal trainer potranno avere più sportivi assegnati.
Anche in questo caso ci sarà la possibilità di refertare o di dare suggerimenti in tempo reale
agli atleti attraverso l’utilizzo di referti datati. (relazione N,N). Particolare importanza è da
attribuire anche ai soccorritori (1,N) che in caso di emergenza potranno accedere ai dati
generali dei pazienti (1,N) o degli atleti(1,N) come nella figura:
Figura 2. Diagramma Entità-Relazione Smartcare
Una volta stabilito il mondo degli utenti, gli stessi inseriranno i loro dati nella cartella clinica
accedendovi online attraverso lo Smartcare. Per cui l'inserimento dei dati consentirà la
creazione di due cartelle una per gli sportivi e una per i pazienti. Poi distinguiamo altre tre
entità e cioè l’entità Anamnesi generale, l’entità Patologia_organo e l’entità dati giornalieri.
Questi dati costituiscono i dati clinici privati. L’entità Anamnesi generale raccoglie attributi
come data e ID_patologie croniche oltre a proprietà come altezza e peso.
27
Nel diagramma entità relazione viene riportata anche l’entità Patologia_organo per cui c’è
un ID_Patologia_organo necessario per individuare le patologie che ciascun utente potrà
segnalare. Questa entità racchiude una serie di campi (mostrati nel paragrafo Data modeling
di Smartcare) indispensabili al medico per inquadrare lo stato complessivo del proprio
paziente. La parte dinamica invece dello Smartcare è incentrata sull’entità Dati_giornalieri,
che presenta come attributi una data (chiave primaria), un dato indicativo del paziente che
viene costantemente monitorato dal proprio medico, i dati pressori registrati giornalmente
o periodicamente e ovviamente un ID_Utente_Paziente che indicherà il paziente
proprietario della cartella e che servirà al medico per poterlo individuare tra i suoi clienti.
5.4 PROGETTAZIONE LOGICA : LE TABELLE DI SMARTCARE
Dal momento che il modello relazionale non permette di rappresentare direttamente una
generalizzazione è necessario trasformare questo costrutto in altri costrutti più semplici del
modello E-R : le entità e le relazioni. Infatti le entità e le relazioni sono invece direttamente
rappresentabili. Si eliminano perciò le gerarchie sostituendole con entità e con relazioni.
Per rappresentare una generalizzazione mediante entità e associazioni ci sono tre alternative
possibili24 :
1. Accorpamento delle figlie della generalizzazione nel padre.
2. Accorpamento del genitore della generalizzazione nelle figlie.
3. Sostituzione della generalizzazione con relazioni.
La scelta tra le varie alternative può essere fatta considerando vantaggi e svantaggi delle
varie possibili alternative relativamente al costo di memoria e al costo delle operazioni
coinvolte. Si possono tuttavia riassumere delle regole generali per la scelta:
A) L’alternativa (1) è conveniente quando le operazioni non fanno distinzione tra le
occorrenze e tra gli attributi dell’entità genitore, e delle entità figlie.
B) L'alternativa (2) è possibile solo se la generalizzazione è totale, altrimenti le occorrenze
dell’entità padre che non sono occorrenze né di una entità figlia e né di un’altra entità figlia,
non sarebbero rappresentate. È conveniente quando ci sono operazioni che si riferiscono
solo a occorrenze di una certa entità figlia oppure di un’altra entità figlia, e dunque fanno
delle distinzioni tra tali entità. In questo caso abbiamo un risparmio di memoria rispetto
alla scelta (1), perché, in linea di principio, gli attributi non assumono mai valori nulli.
28
Inoltre, c'è una riduzione degli accessi rispetto alla scelta (3) perché non si deve visitare
l’entità figlia per accedere ad alcuni attributi delle entità figlie.
C) L'alternativa (3) è conveniente quando la generalizzazione non è totale (sebbene ciò non
sia necessario) e ci sono operazioni che si riferiscono solo a occorrenze delle entità figlie
oppure dell’entità padre, e dunque fanno delle distinzioni tra entità figlia ed entità padre. In
questo caso abbiamo un risparmio di memoria rispetto alla scelta (1), per l'assenza di valori
nulli, ma c'è un incremento degli accessi per mantenere la consistenza delle occorrenze
rispetto ai vincoli introdotti.
5.5
CREAZIONE DELLE TABELLE PER I DATI GENERALI
Dal diagramma entità relazione si evincono le seguenti tabelle :
ENTITA’ UTENTE GENERALE
ID_Utente
CF
Nome
Cognome
Password
Genere
Indirizzo
Data di nascita
Gruppo Sanguigno
Email
Telefono
CHIAVE PRIMARIA
CHIAVE SECONDARIA
ENTITA’ PERSONE DI FIDUCIA
Grado di familiarità
ID_Utente_Persona_di_fiducia
ID_Utente
CHIAVE PRIMARIA
CHIAVE EST. (VERSO ENTITA’ UT)
ENTITA’ MEDICO
ID_Tipologia_medico
ID_Utente
ASL
CHIAVE PRIMARIA
CHIAVE EST. (VERSO ENTITA’ UT)
29
ENTITA’ PAZIENTE
ID_Utente_Paziente
ID_Utente
Codice Paziente
ASL
CHIAVE PRIMARIA
CHIAVE EST. (VERSO ENTITA’ UT)
RELAZIONE PAZIENTE_MEDICO
ID_Utente_paziente
ID_Tipologia_medico
CHIAVE EST. (VERSO ENTITA’ PZ)
CHIAVE EST. (VERSO ENTITA’ MD)
RELAZIONE DIAGNOSI_MEDICO
Referto
Data
ID_Tipologia_medico
ID_Utente_paziente
CHIAVE EST. (VERSO ENTITA’ MD)
CHIAVE EST. (VERSO ENTITA’ PZ)
ENTITA’ PERSONAL TRAINER
Palestra
ID_Utente_Personal_Trainer
ID_Utente
CHIAVE PRIMARIA
CHIAVE EST. (VERSO ENTITA’ UT)
ENTITA’ SPORTIVO
ID_Utente_Sportivo
ID_Utente
Codice Tessera
Palestra
CHIAVE PRIMARIA
CHIAVE EST. (VERSO ENTITA’ UT)
RELAZIONE PERSONAL TRAINER_SPORTIVO
ID_ Utente_Sportivo
ID_Utente_Personal_Trainer
CHIAVE EST. (VERSO ENTITA’ SP)
CHIAVE EST. (VERSO ENTITA’ PT)
RELAZIONE REFERTI_PERSONAL TRAINER
ID_Utente_Personal_Trainer
Referto
ID_Utente_Sportivo
Data referto
CHIAVE EST. (VERSO ENTITA’ PT)
CHIAVE EST. (VERSO ENTITA’ SP)
30
ENTITA’ PATOLOGIA_ORGANO
ID_Utente_Paziente
ID_Patologia_Organo
ID_Utente
Organo
CHIAVE EST. (VERSO ENTITA’ PZ)
CHIAVE PRIMARIA
CHIAVE EST. (VERSO ENTITA’ UT)
Relazione PATOLOGIA_ORGANO_UTENTE_GENERALE
ID_Utente
ID_Patologia_Organo
CHIAVE EST (VERSO ENTITA’ UT)
CHIAVE EST. (VERSO ENTITA’ P.O.)
ENTITA’ DATI GIORNALIERI
ID_Dato_indicativo_per_utente
Data
Pressione
Note
ID_Utente
CHIAVE SECONDARIA
CHIAVE PRIMARIA
CHIAVE EST. (VERSO ENTITA’ UT)
ENTITA’ ANAMNESI GENERALE
Altezza
Peso
Data
Patologie croniche
ID_Utente
CHIAVE PRIMARIA
CHIAVE EST. (VERSO ENTITA’ UT)
ENTITA’ CARTELLA SPORTIVO
Dati Sportivo
ID_Utente_Sportivo
ID_Utente
CHIAVE PRIMARIA
CHIAVE EST. (VERSO ENTITA’ UT)
ENTITA’ SOCCORRITORI
ID_Utente
ID_Soccorritore
Nome Ospedale
CHIAVE EST. (VERSO ENTITA’ UT)
CHIAVE PRIMARIA
31
RELAZIONE SOCCORRITORI-PAZIENTI
ID_Utente_Paziente
CHIAVE ESTERNA (VERSO ENTITA’
PZ)
CHIAVE ESTERNA (VERSO ENTITA’
SOCC.)
ID_Soccorritore
La prima tabella è quella dell’ entità Utente generale che contiene attributi comuni a tutte le
entità figlie. In particolare l’ID_Utente calcolato in maniera automatica durante la creazione
del database, identificherà ciascun cliente in maniera unica e tale da consetirgli l’inserimento
e la visualizzazione dei dati all’interno dello Smartcare. L’ID_Utente quindi sarà la chiave
primaria interna della prima cartella e identificatore esterno o chiave esterna per le seguenti
entità : entità persone di fiducia, entità paziente, entità medico, entità soccorritore, entità
personal trainer e entità soccorritore. Il Codice Fiscale è invece una chiave secondaria che
ad esempio consente al medico o al personal trainer di selezionare nel database il cliente di
cui si vogliono monitorare i dati. La tabella successiva che visualizziamo è rappresentata
dall’Entità Persone di Fiducia, e si riferisce ai familiari del cliente che avranno la facoltà di
accedere ai dati privati del cliente stesso attraverso una password. In questo caso nella
tabella abbiamo l’attributo grado di familiarità che distinguerà la categoria dalle altre, e una
chiave esterna ID_ Utente_persone_di _fiducia che rappresenta la chiave primaria
dell’Entità Utente Persone di fiducia, mentre l’ID_Utente rappresenta la chiave esterna che
consente alla categoria di ottenere tutti gli attributi dell’Utente generale. Lo stesso discorso
vale per l’Entità Paziente che in realtà presenta come chiave esterna l’ID_Utente, come
chiave Primaria l’ID_Utente_paziente e come attributi ASL e codice paziente. L’entità
Medico invece ha come attributo l’ASL di riferimento e come chiave esterna l’ID_Utente
mentre l’ID_tipologia_medico indica la chiave primaria. Lo stesso varrà per l’entità
sportivo e l’entità soccorritore, che ovviamente presenteranno attributi diversi per
distinguersi dalle altre categorie.
Non esiste perciò una chiave primaria esterna, una chiave o è primaria o è esterna. La
chiave primaria è l'ID della tabella stessa, mentre la chiave esterna è un riferimento ad altre
tabelle. Come possiamo osservare invece per l’entità sportivo e personal trainer esiste
sempre una chiave primaria e una chiave esterna che fa riferimento alla tabella Utente
generale. Lo stesso vale per la tabella soccorritori che in questo caso riportiamo perché
ogni soccorritore effettuando l’accesso al database per soccorrere un certo paziente verrà
32
registrato nel database. Per quel che riguarda le cardinalità invece valgono le seguenti regole
generali21:
- le relazioni con 1:N da una parte e 1:1 dall'altra diventano chiavi esterne nella tabella dove
c’è la cardinalità 1:1.
- le relazioni con N:N da tutte e due le parti diventano tabelle, come succede ad esempio
con la relazione paziente medico. In questo caso ID Utente Paziente e ID Tipologia di
medico sono due chiavi esterne rispettivamente verso l’entità paziente e l’entità medico e gli
altri attributi non vanno aggiunti. Come regola generale nelle relazioni N:N da tutte e due
le parti si hanno sempre due chiavi esterne (verso le due entità che sono in relazione),
nessun attributo a meno che gli attributi vengano messi direttamente sul rombo, e nessuna
chiave primaria esplicita (la chiave primaria sarebbe la coppia ID Utente paziente + ID
Tipologia di medico, che in genere non si scrive). Nel nostro caso l’unica relazione con
attributi diversi dalle chiavi esterne è la relazione in cui i medici refertano i pazienti, in cui ci
deve essere anche data e referto oltre alle due chiavi esterne. Lo stesso di relazione esiste tra
i personal trainer per gli sportivi relativamente alla refertazione.
Per la tabella Utente generale e dati giornalieri non si fa una relazione perché la relazione ha
N:N solo da una parte. E’ sufficiente in questo caso mettere una chiave esterna sui dati
giornalieri (tabella entità) verso l'utente generale. I dati giornalieri rappresentano la parte
dinamica dei dati, in questo caso la relazione tra utenti e dati giornalieri sarà del tipo 1,1 a
1,N e questo vuol dire che per ogni utente ci sarà la possibilità di scrivere ogni giorno nuovi
dati e che i nuovi dati faranno riferimento solo ad un unico utente.
Poi abbiamo l’ Entità Utente dati generali e l’entità patologia _organo per le quali esiste una
relazione del tipo N, N e quindi una relazione in cui vengono riportate ID_Utente e
ID_patologia organo, per poter risalire alla patologia in base all’organo colpito per ciascun
utente. Le entità Utente e Anamnesi generale presentano una relazione del tipo 1, N a N,N
e cioè per ogni utente esisterà una ed una sola anamnesi generale che farà riferimento ai
dati fissi di ogni utente. Per gli sportivi esisterà la possibilità di compilare una unica cartella.
Infine esiste la tabella per i soccorritori che potranno soccorrere i pazienti e gli sportivi e
dunque qualsiasi utente registratosi, in questo caso l’ID_soccorritore sarà la chiave primaria
dell’entità soccorritore e l’ID Utente rappresenterà la chiave esterna verso l’entità Utente
generale.
33
5.6 IMPLEMENTAZIONE DEL DATABASE SQL 23
> CREATE TABLE Utente generale (
ID_Utente INT NOT NULL AUTO_INCREMENT PRIMARY KEY
Nome VARCHAR(40) NOT NULL, Cognome VARCHAR (40) NOT NULL, CF
VARCHAR (20) NOT NULL, Genere VARCHAR (3) NOT NULL, Indirizzo
VARCHAR(20) NOT NULL, Data di nascita (DATE) NOT NULL, Telefono VARCHAR
(20) NOT NULL, Gruppo Sanguigno VARCHAR (4) NOT NULL, EMAIL
VARCHAR(20) NOT NULL, Password VARCHAR (20) NOT NULL
) DEFAULT CHARACTER SET utf8 ENGINE=InnoDB
>SHOW TABLES
>DESCRIBE Utente_generale
>INSERT INTO `Utente_generale` (`Nome`, `Cognome`, `Genere`, `Data di
nascita`, `Indirizzo`, `Residenza`, `Email`, `Telefono`, `CF`)
VALUES ('Mirna','valvano','f',24091975,'melfi','melfi1','mirna.valvano',333,'vlvmrn')
Questa operazione viene fatta per la creazione di ogni tabella, così come l’inserimento dei
valori all’interno di ciascuna tabella. In particolare per la cartella Patologia Organo avremo :
>CREATE TABLE Patologia organo (
ID_Utente INT NOT NULL
ID_Patologia_organo INT (20) NOT NULL AUTO_INCREMENT PRIMARY KEY,
Trapianti d’organo VARCHAR(40) NOT NULL, Organo VARCHAR (15) NOT NULL,
Cardiopatie VARCHAR (20) NOT NULL, Problemi cardiovascolari VARCHAR (30) NOT
NULL, Aritmie VARCHAR(20) NOT NULL, Malattie congenite VARCHAR (20) NOT
NULL, Pressione Arteriosa VARCHAR (20) NOT NULL, Malattie del SNC VARCHAR
(20) NOT NULL, Alzheimer VARCHAR(10) NOT NULL, Parkinson VARCHAR (20)
NOT NULL, ASMA VARCHAR(20) NOT NULL, Malattie respiratorie VARCHAR (20)
NOT NULL., Malattie metaboliche VARCHAR (20) NOT NULL, Diabete VARCHAR
(20) NOT NULL, Insufficineza renale VARCHAR(20) NOT NULL
ID_Utente INT NOT NULL, FOREIGN KEY (ID_Utente) REFERENCES
Utente_generale(PRIMARY-KEY)
);
) DEFAULT CHARACTER SET utf8 ENGINE=InnoDB
34
>INSERT INTO `Patologia_Organo`(`ID_utente`, `ID_Patologia
organo`, `Trapianto
d’organo `, `Organo`, `Problemi cardiovascolari`, etc..)
VALUES ('********','123456','si',occhio,'infarto miocardico',etc..);
In questo modo sarà possibile creare le tabelle per l’inserimento dei dati generici e privati di
ciascun cliente. Dopodichè sarà possibile sempre con il linguaggio SQL creare delle
“QUERY” ossia script di interrogazione al database.
6. PRIVACY E TRATTAMENTO DEI DATI SENSIBILI ATTRAVERSO
SISTEMI DI ELABORAZIONE DIGITALE
In caso di trattamento elettronico dei dati sensibili sanitari, ossia di dati personali riferibili
alla salute delle persone, è tuttavia necessario adottare sia tecniche di separazione dei dati
identificativi dai dati sensibili, sia modalità di cifratura dei dati sensibili. La normativa
richiamata per tutelare la privacy dei clienti sui dati personali, trova fonte esclusivamente
nel D.Lgs. 196/2003 (Codice della Privacy). Per cui è necessario porre in essere delle
misure volte sia alla separazione sia alla cifratura degli stessi dati; infatti il 6° comma dell’art.
22 stabilisce la cifratura dei dati sensibili ed il 7° comma precede, in aggiunta, la
conservazione separata dei dati sensibili sanitari dagli altri dati personali. Il punto 24
dell’Allegato B prevede “le modalità di cui all'articolo 22, comma 6, del codice”, ossia che le
modalità relative alla cifratura dei dati, devono essere applicate “anche al fine di consentire
il trattamento disgiunto” dei dati sensibili sanitari dagli altri dati personali identificativi. Tale
trattamento disgiunto può essere applicato con svariate modalità, tra cui la cifratura dei dati
sensibili o l’utilizzo di codici identificativi. La conferma sulla correttezza di questa
interpretazione è desumibile dal dettato del punto 19.8 dell’Allegato B del Codice della
privacy, in base al quale il Documento Programmatico della Sicurezza contiene idonee
informazioni riguardo i dati personali idonei a rivelare lo stato di salute e la vita sessuale,
l'individuazione dei criteri da adottare per la cifratura o per la separazione di tali dati dagli
altri dati personali dell'interessato. Diventa importante nel nostro caso proteggere i dati e
soprattutto dividere i dati identificativi generali dell’utente che si registra in Smartcare dai
dati privati clinici sensibili che necessiteranno a questo punto di essere inseriti in un
database diverso da quello dei dati generali. Alla luce di queste considerazioni è necessario
pensare ad una possibile struttura di rete in cui posizionare due database distribuiti su due
35
server diversi e posizionati in posti diversi, e cioè uno che contenga i dati generali e uno che
contenga i dati sensibili.
6.1 DATI GENERALI E DATI SENSIBILI DELL’UTENTE
L’utilizzo di Database separati distribuiti su server disgiunti al fine distinguere i dati generali
da quelli privati, ha indotto alla ricerca o allo studio di plausibili piattaforme di cui disporre
ad un basso costo e attraverso cui realizzare l’infrastruttura di rete per lo Smartcare. Questo
ha consentito la fruizione del sito di Digital Ocean25, un semplice e veloce fornitore di
cloud hosting integrato per gli sviluppatori. Digital Ocean utilizza la virtualizzazione KVM
e inoltre ospita una libreria di utili procedure dettagliate e tutorial che coprono la
configurazione e ottimizzazione dei server. In sostanza, ciò che Digital Ocean offre26, è un
VPS (Virtual Private Server), cioè un server cloud con storage SSD. Questo tipo di storage
infatti rappresenta una tipologia di dispositivo di memoria di massa basata su
semiconduttore, che utilizza memoria allo stato solido (in particolare memoria flash) per
l'archiviazione dei dati, anziché supporti di tipo magnetico come nel caso dell'hard
disk classico. Altra caratteristica vantaggiosa delle memorie flash risiede nelle ridotte
dimensioni fisiche. Oltre alla memoria in sé, un'unità disco SSD dispone di diversi
componenti necessari alla gestione del suo funzionamento. Ne consegue che l'altra
importante differenza con i classici dischi è la possibilità di memorizzare in maniera non
volatile grandi quantità di dati, senza l'utilizzo di organi meccanici (piatti, testine, motori
ecc.) come fanno invece gli hard disk tradizionali. La piattaforma di Digital Ocean offre
perciò la possibilità di utilizzare dispositivi di storage (database) in cloud su Tier-127 (rete di
primo livello) di rete con 1 TB di trasferimento dei dati a un costo bassissimo. Una rete di
primo livello è una rete IP (tipicamente ma non necessariamente un Internet Service
Provider) che si connette all'intera Internet soltanto attraverso un'interconnessione non
regolata da contratto, conosciuta anche come peering. La definizione generalmente
accettata tra i professionisti del networking è: Rete di Primo livello ossia una rete che
comunica con ogni altra rete per raggiungere Internet. Per definizione, una rete di primo
livello non acquista transito IP da nessun'altra rete per raggiungere Internet. Di
conseguenza, per poter essere un primo livello, una rete deve comunicare con altre reti di
primo livello. Le reti di primo livello cercano di proteggere il proprio stato relativamente
privilegiato impedendo alle nuove reti di diventare esse stesse di primo livello, e per questo
36
potenzialmente competitive. L’dea per la realizzazione dei database a supporto di Smartcare
è quella di costruire una rete client – server punto punto, in cui attraverso il client
dell’utente che accede all’APP è possibile collegarsi a un server web database posizionato in
una FARM del Cloud che conterrà i dati generali di identificazione e un database situato in
un altro punto in cui introdurre i dati sensibili da proteggere. In questo modo l’utente potrà
inserire i propri dati personali generali in un database situato in cloud, e continuare poi con
l’inserimento di dati privati che confluiranno in un database separato garantendone
l’archiviazione, la privacy e la custodia. Tale complessa stratificazione delle risorse è
realizzata in modo del tutto trasparente per l’utente finale, per via dell’efficiente grado di
virtualizzazione garantendo così un’efficienza elevata. Il tipo di database posizionato in
cloud potrebbe essere un database relazionale MySQL. Mentre il database in cui inserire i
dati privati potrebbe essere del tipo non relazionale. I database non relazionali, presentano
una migliore ed elevata performance relativamente ai tempi di risposta.
7. INFRASTRUTTURA DI RETE DI Smartcare
L’infrastruttura di rete di Smartcare client-server punto punto costituisce un sistema
distribuito e in particolare un sistema web distribuito28. Infatti il Web può essere visto come
un sistema distribuito composto da client e server che accedono a documenti collegati. I
server in genere gestiscono insiemi di documenti. I client forniscono agli utenti una
interfaccia facile da usare per accedere e presentare questi documenti. Il modello
applicativo riguarda un tipo particolare di collaborazione tra utenti distribuiti su una rete di
calcolatori. Ogni utente può generare localmente un documento e metterlo in condivisione.
I componenti fondamentali di un'applicazione Web sono analoghi per certi versi a quelli di
una tradizionale applicazione client-server. Nell'ambito Web l'interazione tra client e server
è un po' più articolata per consentire l'integrazione di componenti di varia natura.
Le architetture si dividono in:
a) Architetture Web Tradizionali
b) Architetture Web Multilivello
Lo Smartcare in particolare presenta una Architettura del tipo Web tradizionale.
Un'applicazione Web si basa su elementi software standard indipendenti dalle caratteristiche
della particolare applicazione e dalla piattaforma software e hardware su cui viene eseguita.
37
Una tipica applicazione client-server è costituita da un client che implementa l'interfaccia
utente con alcune funzionalità di elaborazione e di comunicazione e da un server che
fornisce una serie di servizi come la gestione e l'accesso ai dati di un database. Per cui nel
nostro caso avremo un client con su il database in MySQL fornito dalla piattaforma cloud,
che registra i dati generali dei clienti e un altro server su cui invece ci sarà il database in
MONGO DB per la gestione dei dati sensibili. Si ottiene così una rete client-server punto
punto. L’interazione tra i sistemi comunicanti passa attraverso l’utilizzo di regole codificate
che stabiliscono le modalità dell’interazione ossia i cosiddetti protocolli. Il protocollo
utilizzato per la gestione dei database MYSQL è il POD. La struttura del database che
perciò si prospetta per costruire Smartcare al fine di suddividere i dati generali dell’utente
dai dati sensibili e privati dello stesso utente presenta nel diagramma entità relazioni,
un’entità utente che potrà specializzarsi in un’altra entità chiamata RELATIONSHIP in cui
sarà presente la tipologia di relazione che gli utenti avranno fra di loro, ad esempio il
medico con il paziente.
Figura 3. Diagramma Entità-Relazione per la suddivisione dei dati in privati e sensibili di Smartcare. Creazione
di due database: Mysql per i dati privati e Mongo DB per i dati sensibili.
Ciascuna persona in relazione con l’utente ad esempio persone di fiducia, personal trainer
medici o soccorritori potrà essere a sua volta accettata dall’utente di cui visualizzerà i dati
tramite una password. L’entità UTENTE sarà inoltre in relazione con l’entità
Organizzazione che rappresenterà l’ente in cui l’utente verrà inquadrato, e cioè una palestra,
38
ospedale, ASL di appartenenza. La tipologia di utente invece sarà indicata con l’entità
GROUPS che racchiuderà i vari gruppi di utenti: medici, sportivi, pazienti, soccorritori,
personal trainer e persone di fiducia. Ciascun utente avrà dei permessi per poter accedere ai
dati degli altri utenti, ad esempio una password o permessi particolari del database forniti
dall’amministratore del sistema. Questa porzione di dati sarà inserita nel database MYSQL
fornito dal cloud hosting e indicherà solamente i dati generali dell’utente. Sull’altro
Database del tipo MONGO DB, molto più flessibile in termini di struttura e realizzazione
verranno inseriti i dati sensibili. L’utilizzo di due database e anche di tipo differente
consentirà di tutelare maggiormente la privacy. Sarà necessario inoltre realizzare
un’interfaccia per il database in Mongo DB, in cui sarà possibile inserire dati come
USERTYPE ossia l’User vero e proprio e l’organizzazione di appartenenza, la tipologia di
applicazione per cui si registra l’utente, attraverso il campo APPLICATIO-ID, l’USER ID,
una DATA, e i vari FIELDS o campi in cui sarà possibile inserire dati sensibili riguardanti
ad esempio l’anamnesi generale. Ovviamente ogni inserimento di dati risulterà datato. La
data anche in questo caso costituirà un elemento importante per poter individuare per ogni
ID i dati sensibili
8. PROGETTAZIONE DATABASE FARMACOVIGILANZA
Un’ulteriore funzione che si potrebbe aggiungere nella creazione dello Smartcare è quella
della Farmacovigilanza, mirata a monitorare gli effetti benefici e avversi dei farmaci. In
particolare potrebbe essere utile, ad esempio inserire sopra l’interfaccia dell’applicazione un
questionario attraverso cui sarà possibile valutare statisticamente quanto vengono usati i
farmaci e quali sono i relativi benefici e effetti avversi. Sarà perciò necessaria la creazione di
un terzo database specifico per la farmacovigilanza, in cui verranno inseriti tutti i farmaci e
tutti gli effetti avversi relativi a ciascun farmaco. Ciò richiederà lo sviluppo e progettazione
di questo nuovo database in cui verranno raccolte le risposte alle domande che appariranno
sul front end dell’APP Smartcare e a cui gli utenti potranno rispondere. Lo sviluppo di un
software per effettuare calcoli statistici potrebbe ulteriormente rendere più interessante la
raccolta dei dati di farmacovigilanza, stimando le statistiche sui farmaci più usati e sui
relativi effetti avversi, oltre che sui nuovi farmaci di cui ancora non si conoscono
perfettamente gli effetti avversi. Anche in questo caso è necessario creare un diagramma
entità relazione in cui i distinguono differenti entità.
39
Figura 4. Diagramma Entità-Relazione per la Farmacovigilanza in Smartcare
Nel diagramma è possibile visualizzare l’entità Farmaci con chiave primaria ID_Farmaco e
atttributi come categoria farmaco e dosaggio. Questa entità entra in relazione con l’entità
effetti avversi, con una cardinalità N,N, e cioè per ogni farmaco esisteranno N effetti
avversi e per ogni effetto avverso esisteranno N farmaci che lo provocheranno.
l’Entità’ Questionario invece conterrà tutte le domande che verranno poste all’utente in
forma anonima per ogni farmaco, esisterà perciò l’ID_Domanda chiave primaria dell’entità
e poi la domanda specifica come attributo. Per ogni domanda ci saranno una serie di
risposte dell’utente e risposte fornite come soluzione alla domanda specifica per ogni
farmaco, e il tutto sarà rappresentato dall’entità RISULTATO TEST CON
SPIEGAZIONE PER FARMACO. Le tabelle relative che rappresentano la parte di
progettazione logica sono le seguenti:
ENTITA’ FARMACI
ID_FARMACO
Dosaggio
Categoria
CHIAVE PRIMARIA
ENTITA’ EFFETTI AVVERSI
ID_EFF_AVV_PER_ORGANO
Sugg_eff_avv
CHIAVE PRIMARIA
40
RELAZIONE FARMACO-EFFETTO-AVVERSO
ID_FARMACO
CHIAVE ESTERNA (VERSO ENTITA’
FARMACO)
CHIAVE ESTERNA (VERSO ENTITA’
EFFETTI AVVERSI)
ID_EFF_AVV_PER_ORGANO
ENTITA’ QUESTIONARIO
ID_DOMANDA
Domanda
CHIAVE PRIMARIA
ENTITA’ RISULTATI
ID_SPIEGAZIONE
SI
NO
CHIAVE PRIMARIA
RELAZIONE FARMACO-QUESTIONARIO
ID_FARMACO
ID_DOMANDA
CHIAVE ESTERNA (VERSO ENTITA’
FARMACO)
CHIAVE ESTERNA (VERSO
QUESTIONARIO)
RELAZIONE QUESTIONARIO-RISULTATO
ID_DOMANDA
CHIAVE ESTERNA (VERSO ENTITA’
FARMACO)
CHIAVE ESTERNA (VERSO ENTITA’
EFFETTI AVVERSI)
ID_SPIEGAZIONE
In questo caso la chiave primaria per la tabella ENTITA’ FARMACO, sarà ID_Farmaco,
che rappresenterà la chiave esterna per le altre tabelle. Poi attraverso l’utilizzo del
linguaggio SQL sarà possibile interrogare la banca dati per ottenere tutto ciò che riguarda lo
storico del cliente. A questo punto sarà necessario creare interfacce grafiche semplici per
l’interazione immediata dei clienti.
41
CONCLUSIONI
Molte cartelle cliniche elettroniche sono state spesso realizzate in passato come copia delle
cartelle cliniche cartacee. Tuttavia l’utilizzo delle nuove tecnologie informatiche offre
opportunità totalmente nuove rispetto allo strumento cartaceo. La diffusione della
telematica e dell’accesso tramite rete, sottoposto a rigidi controlli ed autorizzazioni, fa
prevedere la realizzazione di un ulteriore passo: la cartella clinica virtuale di un assistito
(paziente, sportivo o chiunque desideri utilizzare la piattaforma dello Smartcare) che
permette di accedere istantaneamente a tutte le informazioni cliniche rilevanti dalla nascita
in poi. E le stesse informazioni potranno essere usate per scopi di sanità pubblica, per la
gestione ottimale delle strutture e soprattutto per monitorare il benessere psico-fisico del
cliente in ogni istante. Il sistema di gestione delle cartelle cliniche diventa così una
funzionalità di un sistema di gestione più vasto di tutte le informazioni cliniche. Per creare
un sistema di questo tipo è stato necessario inquadrare e catalogare tutte le attività previste
per il business model e tutto ciò che comporta la creazione e lo sviluppo del prodotto. La
fase successiva ha previsto lo studio della progettazione di un database relazionale e
l’individuazione dei campi necessari per creare il database dello Smartcare. La privacy non è
da sottovalutare nella gestione dei dati sensibili, cosi come la necessità di custodire i dati in
maniera tale che non vadano perduti. Entrambi questi aspetti hanno fatto pensare alla
possibilità di realizzare due database in cui suddividere i dati generali dai dati sensibili.
Inoltre una funzione importante dello Smartcare è la possibilità di vigilare sugli effetti
avversi dei farmaci, attraverso l’utilizzo di questionari anonimi e tool statistici in grado di
estrapolarne dati concreti di farmacovigilanza. Ulteriori funzionalità potrebbero essere
aggiunte in futuro al prodotto, tra cui, l’utilizzo di un forum che consenta ai clienti di
comunicare con altri medici o personal trainer registrati nel database, o ancora la possibilità
di utilizzare sensori che “attirino” l’attenzione dei clienti durante momenti importanti della
giornata o durante determinati periodi dell’anno, in maniera tale da monitorare in maniera
adeguata e continuativa le condizioni psico-fisiche dei clienti.
42
Bibliografia 1. http://www.epicentro.iss.it/temi/croniche/oms_prevenire.asp
Il portale dell'epidemiologia per la sanità pubblica: Prevenire le malattie croniche
un investimento vitale. 5/02/2015.
2. http://esciencecentral.org/journals/the-use-of-internet-for-health-education-23320893.1000e102.php?aid=9839.
Mo Phoenix. Biosafety & Health Education: The Use of Internet for Health
Education. School of Public Health and Primary Care, The Chinese University of
Hong Kong, China. 2012, 1-2.
3. http://www.trenta3mag.it/2014/07/09/la-rivoluzione-social-nellhealthcare-unasalute-sempre-piu-misura-duomo/
Robotti Andrea. Trenta 3 Magazine Healthcare Marketing Blog. La rivoluzione
social nell’healthcare: una salute sempre più a misura d’uomo. 09/07/2014.
4. http://www.inftub.com/educazione-fisica/LA-SALUTE-LA-SALUTE
DINAMICA42644.php
Inftube.com. L’importanza dello sport nelle varie fasce d’età.
5. Cozzi Renato. Mypersonaltrainer. Ruolo del personal trainer: importanza del
singolo individuo. 06/01/2015.
6. Bellancini
Michele.
Elaborato
in
Informatica
e
Telemedicina:
Utilizzo
dell’infrastruttura proposta I.H.E per garantire interoperabilità fra sistemi
informativi in ambito sanitario. Cap. 2, 2011/2012.
7. http://www.kairoscremona.it/business-model-canvas-generation/
sito Kairos : Cos’è il Business Model. 2014
8. Kolter, Keller, Ancarani, Costabile. Libro: Marketing Management. Quattordicesima
edizione. Editore Pearson. Cap. 1-2-3.
9. Civiero Veronica. Tesi in Economia e gestione delle imprese: L’innovazione
aziendale e la ridefinizione dei business models in un’ottica strategica. 2011-2012,
Pg. 42-46.
10. Stewart, Qin Zhao. Internet Marketing, Business Models, and Public Policy. Journal
of Public Policy & Marketing: Fall 2000, Vol. 19, No. 2, pg. 287-296.
11. Zott Christoph,Amit Raphael,Massa Lorenzo.Working Paper: The Business Model,
Theoretical roots, recents developments, and future research.9/2010, pg1-26.
43
12. Weill, P. and M. R. Vitale. Place to Space: Migrating to eBusiness Models. Boston:
Harvard Business School Press. 2001
13. Morris, M. Schindehutte, M., & Allen,J.. The entrepreneur’s business model :
Toward a unified perspective. Journal of business research. 2005, 58(6):726-735.
14. Brousseau, E., & Penard, T. The economics of digital business models: A
framework for analyzing the economics of platforms. Review of Network
Economics. 2006, 6(2): 81-110.
15. George, Gerard and Bock, Jay Adam. The Business Model in Practice and its
Implications for Entrepreneurship Research. 2009.
16. Seelos and Mair. Academy of Management Perspectives : Profitable Business
Models and Market Creation in the Context of Deep Poverty: A Strategic View.
11/2007.
17. http://www.businessmodelcanvas.it/bmc/cosa-e-un-business-model.html
www.businessmodelgeneration.com. Osterwalder, A., Pigneur, Y. (2010). Creare
modelli di business. Milano: FAG, 2012.
18. DECRETO LEGISLATIVO 30 giugno 2003, n. 196. Codice in materia di
protezione dei dati personali"pubblicato nella Gazzetta Ufficiale n. 174 del 29 luglio
2003 - Supplemento Ordinario n. 123.
19. Gallo Crescienzo. La progettazione dei database relazionali. pg 1-3.
20. Bruno Giovanni. SER&PRACTICES. Basi di dati. Concetti di base. 2015
21. Hernandez Micheal J., Viescas John L. SQL Queries for Mere Mortals. Mondadori.
Informatica.
22. Russo Nino. I&T Informatica e Telecomunicazioni S.p.A. Progettazione di
database relazionali. 05/1998
23. Yank Kevin. Sviluppare applicazioni con PHP e MySQL. Editore Apogeo.
01/2015.
24. Traduzione dello schema E-R in modello logico relazionale.
25. https://cloud.digitalocean.com/droplets.
Sito Digital ocean.
26. http://www.hostingtalk.it/digitalocean-i-cloud-server-su-ssd-che-continuano-avendere_-c0000068C/
Hosting Talk.it : Il Portale italiano sull’Hosting.
27. http://it.wikipedia.org/wiki/Rete_di_primo_livello
28. Castellano Marcello. Sistemi Web Distribuiti. Corso Sistemi Distribuiti. 09/2014
44
45