theses - Barbiana 2.0 - Università degli Studi Mediterranea

Università degli Studi Mediterranea di Reggio Calabria
Dipartimento di Ingegneria dell’Informazione, delle Infrastrutture e dell’Energia Sostenibile
Corso di Laurea Magistrale in Ingegneria Informatica e dei Sistemi per le Telecomunicazioni
Tesi di Laurea Magistrale
Progettazione e implementazione di un sistema client-server
per il supporto del medico di base nelle diagnosi di anemie
Relatore:
Prof. Domenico Ursino
Candidato:
Dott. Domenico Carlo Romeo
Correlatore:
Prof. Pasquale Iacopino
Anno Accademico 2013 - 2014
Alla mia famiglia,
ai miei parenti
e ai miei amici.
Book Design by Erick Ragas
© StockInDesign
www.stockindesign.com
Tutti i diritti riservati
Dicembre 2014
Tesi stampata presso la tipografia EuroJason Srl, Reggio Calabria
Indice
IntroduzioneVII
Capitolo 1 Il sangue e l’anemia: generalità
1
1.1
Il sangue2
1.1.1
Il plasma2
1.1.2
I globuli rossi4
1.1.2.1
L’eritropoiesi4
1.1.3
I globuli bianchi5
1.1.4
Le piastrine6
1.2
Le anemie7
1.2.1
Cause7
1.2.2
Sintomi8
1.2.3
Classificazione delle anemie8
1.2.3.1
Classificazione delle anemie secondo i valori dell’MCV10
1.2.3.2
Classificazione delle anemie secondo i valori dell’MCHC11
1.2.4
Diagnosi11
Capitolo 2
Business plan del sistema13
2.1
Business plan14
2.1.1
Articolazione del business plan14
2.1.2
Business plan per il nostro sistema
16
2.2
Analisi SWOT19
2.2.1
Analisi SWOT del nostro sistema
20
[ VI ]
Indice
Capitolo 3 Architettura e progettazione del sistema
23
3.1
Caratteristiche tecniche del sistema
24
3.2
Architettura del sistema24
3.2.1
Apache Cordova25
3.2.1.1
HTML 5, CSS 3 e JavaScript
27
3.2.2
PHP 529
3.2.3
JSON30
3.2.4
MySQL31
3.2.5
XML31
3.2.6
XML Schema32
3.2.7
XQuery32
3.3
Progettazione del database32
3.3.1
Gestione dell’area riservata33
3.3.2
Utente “medico”33
3.3.3
Schema relazionale del database
34
Capitolo 4 Implementazione del sistema e guida utente
37
4.1
Implementazione dell’algoritmo38
4.1.1
TemplateMethod Pattern39
4.1.2
DAO Pattern40
4.1.3
Albero di decisione sulla diagnosi dell’anemia
41
4.1.4
Base di conoscenza del test anemia
44
4.1.5
Listati dell’algoritmo per la diagnosi dell’anemia
46
4.1.5.1
Script algoritmo.php47
4.1.5.2
Classe ClinicalTesting48
4.1.5.3
Classe AnemiaTesting48
4.2
Guida utente del nostro sistema
50
4.2.1
Utilizzo dell’algoritmo per la diagnosi dell’anemia
52
Capitolo 5 Confronto con sistemi correlati e studio del possibile riuso del software 55
5.1
Confronto con sistemi correlati56
5.1.1
Medical Diagnosis System56
5.1.2
AnalisiSangue57
5.1.3
Salute58
5.2
Analisi del possibile riuso del software applicato al nostro sistema
59
Conclusioni Considerazioni personali e uno sguardo al futuro
61
Ringraziamenti E per finire, i ringraziamenti
65
Bibliografia Maggiori approfondimenti67
Introduzione
In una situazione in cui il settore sanitario italiano sta vivendo dei momenti difficili, i medici di base devono offrire un servizio efficiente ai propri pazienti al fine
di soddisfare i loro bisogni. Questo scopo deve essere raggiunto seguendo una
filosofia basata sul costante miglioramento delle loro attività. In particolare, le
attività dei medici di base sono caratterizzate essenzialmente dalla formulazione della diagnosi dell’eventuale patologia presentata dal paziente, che si effettua attraverso l’osservazione dei sintomi e la valutazione dei dati clinici, come,
per esempio, quelli degli esami del sangue. Tuttavia, questi dati, a loro volta,
vengono elaborati tramite conoscenze ed esperienze mediche piuttosto vaste e
complesse per il medico di base.
Ad esempio, gli esami del sangue rivestono oggi, così come nel passato, un ruolo chiave nel fornire elementi diagnostici preziosi su possibili alterazioni dell’organismo. Infatti, i valori dei parametri di tale esame possono subire variazioni in
relazione all’età, al sesso, all’esercizio fisico, allo stress, all’assunzione di farmaci
e, soprattutto, alla presenza di determinate malattie. Svariate malattie possono
essere causa di un quadro clinico alterato; tra queste, citiamo le anemie.
Nonostante i quadri clinici sottesi siano estremamente complessi, in varie pubblicazioni mediche è stato già dimostrato che una semplice anomalia del quadro dell’esame del sangue possa consentire un generico ma tempestivo inquadramento diagnostico già a livello ambulatoriale e/o domiciliare. Grazie a ciò, si
ha la possibilità di razionalizzare al meglio l’utilizzo delle risorse, di migliorare la
qualità della vita dei pazienti e di individuare fin da subito procedure diagnostico-terapeutiche appropriate.
[ VIII ]
Introduzione
Il sistema informativo proposto in questa tesi si colloca in questo contesto. In
altre parole, è in grado di fornire al medico dei suggerimenti tempestivi e utili
per diagnosticare correttamente le eventuali malattie manifestate dai pazienti
in esame.
Il sistema implementa le conoscenze e le esperienze utili per il miglioramento
delle attività dei medici di base e della vita dei pazienti. A tal fine, le procedure
di acquisizione e codifica delle conoscenze ed esperienze mediche sono state effettuate tramite una stretta collaborazione con il Prof. Pasquale Iacopino,
già primario del reparto Ematologia1 degli Ospedali Riuniti di Reggio Calabria. Il
nostro consulente vanta un’esperienza ultratrentennale nel settore dell’ematologia e, inoltre, è attualmente riconosciuto come un esperto a livello internazionale in tale disciplina.
L’obiettivo della tesi è, quindi, quello di dimostrare che il nostro sistema può
supportare il medico nelle procedure di valutazione diagnostica.
Il sistema proposto riguarda la diagnosi dell’anemia. Esso consiste in un’app
HTML 5 che fornisce dei suggerimenti al medico dialogando con un server remoto implementato in linguaggio PHP 5. Il sistema, come si vedrà nei prossimi
capitoli, consentirà all’app costruita di poter essere installata su qualsiasi tablet,
smartphone, smartwatch e personal computer.
Per il sistema gioca un ruolo centrale la costruzione di un database e di una
base di conoscenza2 relativa alle patologie che si possono individuare sulla base
dell’esame, dell’età, del sesso, etc.
1 L’ematologia è la disciplina della medicina che studia le cause e le diagnosi delle
patologie del sangue e degli organi che lo producono.
2 Una base di conoscenza (individuata anche con il termine inglese knowledge base
oppure con l’acronimo KB) è un software finalizzato all’archivio, alla gestione della
conoscenza e della decisionalità di un’organizzazione. Costituisce un ambiente
che semplifica la raccolta, la gestione, l’organizzazione e la distribuzione delle
conoscenze relative ad una realtà di interesse.
Introduzione
Il presente lavoro di tesi è strutturato come di seguito specificato:
•
il Capitolo 1 tratta le nozioni alla base della diagnosi dell’anemia, ovvero il tessuto sanguigno e l’anemia;
•
il Capitolo 2 introduce alcuni cenni sul business plan e sull’analisi
SWOT, che verrà applicata al sistema oggetto della presente tesi;
•
il Capitolo 3 espone l’architettura e la progettazione del sistema;
•
il Capitolo 4 illustra le scelte implementative dell’algoritmo per la diagnosi delle anemie e i servizi fruibili dal medico;
•
il Capitolo 5 propone un confronto fra il sistema realizzato ed prodotti
analoghi;
•
il Capitolo 6 trae le conclusioni sulla tesi esaminando i possibili sviluppi futuri.
[ IX ]
[ X ]
Introduzione
Il sangue e l’anemia:
generalità
Capitolo 1
Nel presente capitolo verranno trattate le nozioni generali sul tessuto sanguigno
e su una patologia che affligge gran parte della popolazione mondiale: l’anemia.
Partendo dalla definizione di tessuto sanguigno, verranno illustratate l’anatomia
del sangue umano e le componenti principali di questo tessuto. Dopodiché, si
faranno alcuni cenni sulle anemie evidenziando le loro cause patologiche e i loro
sintomi. Infine, si descriveranno in maniera generale i principali tipi di anemie e la
diagnosi di queste patologie.
[2 ]
Capitolo 1
1.1 Il sangue
Il sangue è un tessuto allo stato liquido e viscoso di colore rosso nei vasi sanguigni arteriosi e rosso violaceo in quelli venosi. Esso si trova nel sistema cardiovascolare e, perciò, svolge funzioni vitali per il corpo umano, tra cui:
••
il trasporto dell’ossigeno nei polmoni e nel resto del corpo umano attraverso i vasi arteriosi1;
••
il trasporto di sostanze nutritive per l’organismo attraverso i vasi arteriosi;
••
la raccolta di sostanze di rifiuto (tossine e anidride carbonica) prodotte
dalle reazioni cellulari attraverso i vasi venosi;
••
la protezione dell’organismo da eventuali attacchi da parte di cellule
cancerose e microrganismi patogeni (microbi, virus, miceti e parassiti);
••
il trasporto degli ormoni, sostanze che regolano il funzionamento degli
organi del corpo umano;
••
la regolazione della temperatura corporea.
Con riferimento alla Figura 1.1, il sangue è formato da tre elementi corpuscolati
sospesi nel plasma:
••
i globuli rossi;
••
i globuli bianchi;
••
le piastrine.
1.1.1 Il plasma
Il plasma è un composto liquido di colore giallo che, oltre a sospendere i tre
elementi corpuscolati del sangue, contiene le seguenti componenti:
1
••
acqua;
••
sali minerali (in particolare cloruro di sodio);
••
carboidrati;
••
lipidi;
L’ossigeno trasportato nel sangue arterioso viene consumato dalle cellule durante
i processi vitali che in esse si svolgono.
Il sangue e l’anemia: generalità
globuli rossi
vaso
sanguigno
globulo bianco
plasma
piastrine
Figura 1.1 - Anatomia del sangue
••
enzimi;
••
tossine;
••
ormoni;
••
sostanze gassose;
••
anticorpi.
[3 ]
[4 ]
Capitolo 1
1.1.2 I globuli rossi
I globuli rossi (eritrociti o, più raramente, emazie) sono cellule senza nucleo di
diametro pari a circa 7 micron e a forma di disco biconcavo, schiacciato al centro
e rialzato ai bordi. Il loro compito è quello di trasportare l’ossigeno e l’anidride
carbonica nei polmoni e nel resto dell’organismo.
Il caratteristico colore rosso degli eritrociti è dato da una
proteina costituita da ferro (ferroproteina), chiamata emoglobina.
L’emoglobina è un composto chimico che permette ai globuli rossi di legarsi reversibilmente all’ossigeno negli alveoli polmonari e all’anidride carbonica nelle cellule durante
i processi di trasporto sanguigno. Conferisce al sangue il
noto colore rosso e agli eritrociti la fondamentale funzione
di trasporto di ossigeno e anidride carbonica nei polmoni e nel
resto del corpo umano. In particolare, durante il passaggio del sangue negli alveoli polmonari, l’emoglobina si combina con l’ossigeno presente nell’aria e lo
trasporta a livello dei tessuti. Qui cede l’ossigeno alle cellule, si carica di anidride
carbonica e torna negli alveoli polmonari. In questi ultimi cede l’anidride carbonica e si ricarica di ossigeno.
Gli eritrociti vivono circa tre mesi e vengono prodotti da un processo maturativo
delle cellule chiamato eritropoiesi.
1.1.2.1 L’eritropoiesi
Gli eritrociti, per poter essere prodotti e immessi nel sistema cardiovascolare,
devono seguire una serie di tappe del processo di eritropoiesi. Esso prevede
una linea maturativa che comprende le cellule staminali2 e una serie di elementi
cellulari non maturi, che include i proeritroblasti, gli eritroblasti basofili, gli eritroblasti policromatofili e gli eritroblasti ortocromatici.
Inizialmente, a partire dalle cellule staminali , vengono prodotti i proeritroblasti,
elementi corpuscolati con grande nucleo, nucleoli e citoplasma basofilo3.
2
Le cellule staminali sono elementi cellulari non maturi in grado dare origine a cellule
mature e appartenenti a uno o più tessuti differenti.
3 La basofilia è la proprietà caratteristica di alcune cellule e di alcuni costituenti
cellulari di colorarsi in maniera elettiva con i coloranti basici dell’anilina.
Il sangue e l’anemia: generalità
Dopodiché si trasforma in eritroblasto basofilo (privo di nucleoli), in eritroblasto policromatofilo (con citoplasma parzialmente basofilo e acidofilo) e poi in
eritroblasti ortocromatici (privi di nucleo ma con citoplasma acidofilo). Giunti
a questo stadio evolutivo, gli eritroblasti ortocromatici si trasformano in reticolociti (privi di nucleo), che abbandonano il midollo osseo ed entrano nel circolo
sanguigno. Dopo un po’ di tempo, i reticolociti si evolgono in globuli rossi maturi e, alla fine della loro vita, verranno distrutti dalla milza4.
1.1.3 I globuli bianchi
I globuli bianchi (leucociti) sono cellule nucleate di colore bianco-giallastro e diametro compreso tra i 7 e i 20 micron, quindi maggiore di quello dei globuli rossi. La loro forma è sferica ma può deformarsi: i globuli bianchi hanno la capacità di
alterare la propria morfologia per attraversare le pareti dei
vasi capillari e andare a difendere l’organismo dagli attacchi delle cellule cancerose e dei microrganismi ostili.
I globuli bianchi possono essere suddivisi in tre tipologie
con funzioni differenti:
••
i granulociti;
••
i monociti;
••
i linfociti.
I granulociti sono globuli presenti in un numero elevato nel sangue quando l’infezione è in atto. Si muovono emettendo protuberanze che trascinano la cellula
attraverso le pareti dei vasi sanguigni e nei tessuti. Hanno, inoltre, la facoltà di
inglobare e digerire i microrganismi responsabili delle infezioni.
I monociti sono globuli di maggiori dimensioni e molto mobili. Hanno la facoltà
di inglobare e digerire i microrganismi dannosi.
4 L’emoglobina contenuta nei globuli rossi, dopo la loro distruzione da parte
della milza, verrà comunque recuperata dal fegato per la produzione della bile.
[5 ]
[6 ]
Capitolo 1
I linfociti sono globuli che difendono l’organi-
L’anticorpo è una sostanza che rende
i microrganismi patogeni inattivi al
corpo umano.
smo attraverso la produzione di un anticorpo
specifico per ogni agente estraneo presente.
I globuli bianchi vengono prodotti dalla milza,
dal midollo osseo e dalle ghiandole linfatiche
e vivono dai 2 giorni fino a un anno.
1.1.4 Le piastrine
Le piastrine (trombociti) sono frammenti di cellule del midollo osseo il cui diametro varia tra i 2 e i 4 micron. Si tratta, quindi, di elementi corpuscolati più
piccoli dei globuli rossi e bianchi. La loro forma è tondeggiante oppure ovale.
Le piastrine hanno il compito di favorire la coagulazione del
sangue quando viene a contatto con l’aria in una ferita.
Con riferimento alla Figura 1.2, le piastrine, che arrivano in
prossimità della ferita a contatto con l’aria, dispongono su
di essa una fitta rete di sottili filamenti in fibrina che imprigionano gli eritrociti, bloccandone così il flusso: si forma, in
questo modo, il coagulo che, seccandosi, darà origine alla
cosiddetta crosta.
Affinché avvenga la coagulazione, è essenziale che ci sia la
presenza di vitamina K nel sangue. Nei casi in cui ci sia carenza
di questa vitamina, il sangue non avrà la capacità di coagulare e, perciò, una
minima ferita provocherà un’inarrestabile emorragia.
Le piastrine vengono prodotte dalla milza e dal midollo osseo e la loro vita dura
tra i 3 e i 7 giorni.
Il sangue e l’anemia: generalità
Figura 1.2 - Globuli rossi intrappolati in una rete in fibrina
1.2 Le anemie
Su base rigorosamente ematologica, il termine “anemia” dovrebbe stare ad indicare la totale mancanza di sangue. Sul piano clinico e sotto tale dizione, le anemie rappresentano, invece, delle patologie sostenute e caratterizzate da una diminuzione del numero di globuli rossi e/o dalla concentrazione di emoglobina
presenti nel sangue circolante.
L’anemia può esserci anche con un numero di globuli rossi normale oppure superiore alla norma e con una concentrazione di emoglobina abnormemente diminuita. In alcuni casi, si potrebbe ipotizzare la presenza di anemia anche quando il numero di emazie risulta nettamente diminuito ma con il loro contenuto
emoglobinico abnormemente elevato.
1.2.1 Cause
Le cause principali delle anemie sono molteplici: vanno dalla malaria all’anemia
mediterranea, dal cancro alle carenze nutrizionali (carenza di ferro, vitamina B12
e/o folati), dalle emorragie esterne e/o interne. Un’altra causa delle anemie è la
distruzione accelerata dei globuli rossi da parte del midollo osseo (il numero di
globuli rossi che vengono distrutti ed eliminati dal midollo osseo risulta molto
maggiore di quanti se ne producono).
L’anemia spesso può essere, inoltre, una complicanza di altre malattie, che aggrava la condizione della persona portando esiti anche fatali, come nei casi di
bronchite cronica e leucemia.
[7 ]
[8 ]
Capitolo 1
1.2.2 Sintomi
Con riferimento alla Figura 1.3, i sintomi delle anemie interessano diverse parti
del corpo umano. I principali organi coinvolti in queste forme patologiche sono:
••
l’encefalo;
••
il cuore;
••
gli occhi;
••
i vasi sanguigni;
••
i muscoli;
••
la milza;
••
i polmoni;
••
lo stomaco;
••
la cute;
••
l’intestino.
Si tenga, comunque, presente che i sintomi di un’anemia non dipendono tanto
dalla quantità di emoglobina presente nel sangue, bensì dalla velocità con cui
l’anemia stessa si instaura. Un ulteriore indizio è dato dalla fragilità delle unghie
che tendono a sfaldarsi o, ancor peggio, ad assumere una caratteristica forma
concava (coilonichia).
1.2.3 Classificazione delle anemie
Definire il tipo di anemia è essenziale per il medico da un punto di vista diagnostico e terapeutico. Descrivere i tipi di anemie risulta, invece, molto complesso
da esporre per l’estesa varietà di patologie anemiche. Per questo motivo, ci limitiamo soltanto alla classificazione delle anemie secondo i parametri clinici.
Prima di esaminare le classificazioni delle anemie, teniamo presente che i riferimenti ematologici per le suddette anemie sono specificati dai laboratori clinici
secondo l’età e il sesso del paziente. Ogni laboratorio stabilisce, solitamente, i
propri intervalli di riferimento in funzione della propria strumentazione, dei metodi di analisi ematologica, della demografia e dei pazienti. I valori di riferimento
normali sono stimati a partire da campioni sanguigni di individui sani.
Il sangue e l’anemia: generalità
[9 ]
astenia
capogiri
cefalea
svenimento
palpitazioni
tachicardia
subittero
ipotensione
sanguigna
astenia
splenomegalia
nausea
dispnea
perdita di appetito
cambiamento
del colore
delle feci
pallore
ingiallimento
ipotermia
Figura 1.3 - Sintomi principali delle anemie
[ 10 ]
Capitolo 1
Chiarite queste osservazioni, esaminiamo, adesso, le due classificazioni. Le anemie, infatti, vengono classificate in base ai valori dell’MCV5 oppure dell’MCHC6.
1.2.3.1 Classificazione delle anemie secondo i valori dell’MCV
Secondo i valori dell’MCV, le anemie vengono classificate in:
••
anemie microcitiche;
••
anemie normocitiche;
••
anemie macrocitiche.
Le anemie microcitiche sono caratterizzate da un MCV inferiore al range normale, quindi da globuli rossi mediamente minuscoli: in tale situazione, gli eritrociti
vengono chiamati microciti. Le anemie microcitiche sono causate da condizioni
che portano a una ridotta sintesi dell’emoglobina, come l’anemia mediterranea.
Le anemie normocitiche sono caratterizzate, invece, da un MCV pari ai valori del
range normale, quindi da globuli rossi di dimensioni mediamente normali; in
tale situazione, gli eritrociti vengono chiamati normociti. Alcune forme normocitiche si sviluppano a causa della distruzione prematura e della riduzione dei
globuli rossi maturi (anemia emolitica), ma sono caratterizzate da un elevato
numero di reticolociti. Altre anemie normocitiche si sviluppano, invece, a causa
di una diminuzione dei reticolociti.
Le anemie macrocitiche sono caratterizzate, infine, da un MCV superiore ai valori normali, quindi da globuli rossi di grandi dimensioni; in tale situazione,
gli eritrociti vengono chiamati macrociti. Le anemie macrocitiche possono essere megaloblastiche oppure non megaloblastiche. Le anemie megaloblastiche
sono forme anemiche causate da carenza di vitamina B12 e/o di folati.
5 MCV (acronimo che sta per Mean Corpuscolar Volume, volume corpuscolare
medio) misura il volume medio dei globuli rossi, ossia la dimensione media degli
eritrociti. Viene espresso in femtolitri (fL) oppure in micrometro al cubo (µm3).
6 MCHC (acronimo che sta per Mean Corpuscolar Hemoglobin Concentration,
concentrazione media di emoglobina) misura la quantità media di emoglobina
contenuta nei globuli rossi. Viene esprresso in grammi al decilitro (g/dL).
Il sangue e l’anemia: generalità
1.2.3.2 Classificazione delle anemie secondo i valori dell’MCHC
Sulla base dei valori dell’MCHC, le anemie vengono classificate in:
••
anemie ipocromiche;
••
anemie normocromiche;
••
anemie ipercromiche.
Le anemie ipocromiche sono caratterizzate da un MCHC inferiore ai valori normali, quindi da un contenuto emoglobinico mediamente piccolo.
Le anemie normocromiche presentano un MCHC pari ai valori normali, quindi da
un contenuto emoglobinico mediamente normale.
Le anemie ipercromiche presentano un MCHC superiore ai valori normali, quindi
da un contenuto emoglobinico mediamente elevato.
1.2.4 Diagnosi
L’anemia viene diagnosticata mediante una procedura che si articola nelle seguenti fasi:
1. anamnesi, ovvero la fase di raccolta delle informazioni che possono aiutare il medico a indirizzarsi verso la diagnosi finale di una certa patologia
dalla voce diretta del paziente e/o dei suoi familiari;
2. esame obiettivo, ovvero l’insieme di processi diagnostici effettuati dal
medico per verificare se il paziente presenti o meno i sintomi indicati
durante la fase di anamnesi;
3. esami di laboratorio, ovvero l’insieme di test clinici che comprende l’emocromo7, l’esame sullo striscio periferico8, la sideremia9 e ferritina10.
7 L’emocromo (abbreviazione comunemente usata per esame emocromocitometrico)
è l’esame completo del sangue effettuato in laboratorio mediante strumentazioni
automatizzate. Lo scopo di questo esame è quello di determinare la quantità dei
globuli, il livello dell’emoglobina, nonché diversi altri parametri del sangue.
8 L’esame sullo striscio periferico è l’esame che consente di ottenere un’istantanea
della popolazione cellulare presente in un campione sanguigno di un paziente.
9 La sideremia è l’esame per osservare la quantità di ferro presente nel sangue.
Comprende il parametro TIBC (capacità totale del ferro di legare con la transferrina).
10 La ferritina è l’esame finalizzato per osservare la quantità di ferritina, una proteina
globulare presente nel sangue.
[ 11 ]
[ 12 ]
Capitolo 1
Si tenga presente che l’anamnesi valuta:
••
l’età e il sesso del paziente;
••
il tempo di comparsa e durata dei sintomi;
••
eventuali gravidanze ripetute e/o ravvicinate;
••
esposizione a farmaci e/o sostanze tossiche;
••
presenza di altre patologie;
••
disturbi neurologici.
Business plan
del sistema
Capitolo 2
Nel presente capitolo verranno presentati alcuni cenni sul business plan e sulla sua
articolazione. Dopodiché verrà introdotta l’analisi SWOT e la stessa verrà applicata
al sistema oggetto della presente tesi.
[ 14 ]
Capitolo 2
2.1 Business plan
Il business plan è un documento volto a rappresentare in ottica prospettica la
business idea di un progetto aziendale, con l’intento di valutarne la fattibilità
e di analizzarne le possibili ricadute sul progetto e sui suoi risultati economici.
Per raggiungere tale scopo, è necessario redarre nel business plan una seriee di
informazioni inerenti ai seguenti aspetti:
••
caratteristiche dell’azienda di riferimento;
••
contenuti del progetto che si intende realizzare;
••
fattibilità del progetto;
••
possibili ricadute sullo stesso.
2.1.1 Articolazione del business plan
Il contenuto del business plan deve essere attendibile, chiaro e privo di ambiguità e incongruenze. Deve presentare un elevato grado di completezza, nel senso
che il piano deve comprendere tutte le informazioni sulle caratteristiche della
business idea e, quindi, sul progetto.
Un business plan comprende le seguenti sezioni:
••
executive summary;
••
descrizione dell’azienda;
••
descrizione sui prodotti/servizi;
••
descrizione del mercato target;
••
descrizione dell’ambiente competitivo;
••
strategie di marketing;
••
descrizione della logistica;
••
descrizione delle attività commerciali;
••
descrizione della produzione aziendale;
••
descrizione dell’assetto organizzativo;
••
descrizione dettagliata del progetto.
Business plan del sistema
[ 15 ]
L’executive summary rappresenta la descrizione sommaria del progetto, quindi
una sorta di “anteprima” di quei contenuti del progetto che verranno descritti
in dettaglio in un’altra apposita sezione del business plan. Questa sezione deve
spiegare sinteticamente le motivazioni che rendono “unico” e interessante il
progetto aziendale e, per questo motivo, rappresenta la sezione fondamentale
del business plan.
La descrizione dell’azienda comprende informazioni sia attuali che storiche
sull’azienda che propone il progetto.
La descrizione sui prodotti/servizi riporta in dettaglio le informazioni sui prodotti/servizi realizzati dall’azienda ed offerti sul mercato.
Il mercato target è l’insieme dei
La descrizione del mercato target compren-
clienti, attuali o potenziali, con
de sia una descrizione qualitativa che quella
caratteristiche
quantitativa del mercato target. La prima par-
loro,
te riguarda la descrizione dei potenziali clienti,
all’acquisto di un prodotto/servizio.
omogenee
potenzialmente
mentre la seconda quella in termini di fatturato o numero di unità di prodotti vendibili.
La descrizione dell’ambiente competitivo fornisce
la descrizione dei concorrenti diretti dell’azienda che
propone il progetto. Essa comprende:
••
i concorrenti diretti dell’azienda, ossia le aziende che offrono prodotti/
servizi simili a quelli dell’azienda proponente;
••
l’evoluzione della concorrenza, ossia l’evoluzione dei concorrenti dell’azienda negli ultimi anni;
••
informazioni sul contesto in cui opera l’azienda.
Le strategie di marketing rappresentano i macro-obiettivi prefissati dall’azienda
e il modo in cui si intende perseguirli, mantenendo per lo più un’ottica di medio-lungo periodo.
La descrizione della logistica rappresenta l’insieme delle descrizioni inerenti ai
fornitori dell’azienda che propone il progetto.
La descrizione delle attività commerciali descrive i canali di vendita e di distribuzione dei prodotti/servizi e le politiche di comunicazione dell’azienda.
La descrizione della produzione aziendale specifica il processo produttivo dell’azienda, che comprende, per esempio, il controllo della qualità e il know-how.
tra
interessati
[ 16 ]
Capitolo 2
La descrizione dell’assetto organizzativo rappresenta la descrizione della struttura organizzativa dell’azienda.
Infine, la descrizione dettagliata del progetto rappresenta una descrizione dettagliata del potenziale impatto che il progetto potrebbe avere sul mercato. Essa
comprende:
••
una descrizione del progetto, che deve consentire al lettore del business
plan una chiara e approfondita visione del progetto e dell’opportunità
che esso rappresenta. In particolare, in questa sezione, si indicano:
* in che cosa consiste il progetto;
* quali sono gli elementi innovativi rispetto ai principali prodotti/servizi già offerti dall’azienda e rispetto a quelli offerti dai concorrenti;
* quali sono le opportunità di mercato che si intende cogliere e le minacce che si dovranno affrontare.
••
gli obiettivi e i risultati del progetto, che esplicano rispettivamente le “tappe di avvicinamento” alla realizzazione progressiva del progetto e le realizzazioni da conseguire in termini quantitativi e quantitativo-monetari.
••
i tempi di realizzazione del progetto, che rappresentano l’intervallo temporale necessario a tradurre la business idea in realizzazioni concrete.
Una volta completati i vari elementi del business plan, si individuano i punti di
forza, debolezza, opportunità e minaccia presenti nel progetto attraverso un
processo di formulazione strategica chiamato analisi SWOT1, che verrà trattata
nel prossimo paragrafo.
2.1.2 Business plan per il nostro sistema
In Italia, secondo l’Istituto Nazionale di Statistica (ISTAT), i medici di base nel
2010 sono circa 46.000. In pratica, sono presenti 7.6 medici ogni 10.000 abitanti. Sebbene il contratto dei medici di
medicina generale preveda che si possano assistere fino a
un massimo di 1.500 pazienti, il dato medio nazionale è significativamente al di sotto di tale soglia: 1.147 assistiti per
1
SWOT è un acronimo che sta per Strengths, Weaknesses, Opportunities, Threats, ovvero
Punti di Forza, di Debolezza, di Opportunità e Minacce.
Business plan del sistema
medico. A livello territoriale, se si esclude il caso della provincia autonoma di
Bolzano, con un numero medio di 1.577 assistiti per medico, la variabilità regionale passa da 1.017 in Basilicata a 1.316 in Lombardia. Ciascun medico di base
potrebbe essere un potenziale utilizzatore del sistema informativo proposto in
questa tesi. Chiaramente, l’applicazione può essere successivamente estesa anche fuori dai confini nazionali.
Un altro possibile canale di vendita dell’applicazione è legato alle aziende farmaceutiche. Infatti, l’applicazione potrebbe essere acquistata dalle aziende farmaceutiche e donata ai medici come gadget. A tale proposito si osserva che le
aziende produttrici di farmaci e quelle di dispositivi sanitari hanno speso almeno 3,5 miliardi di dollari ai medici statunitensi negli ultimi cinque mesi del 2013.
È quanto emerge dal nuovo rapporto previsto dalle regole sulla trasparenza
dell’Obamacare2, riportato da Wall Street Journal. Secondo le case farmaceutiche, i pagamenti sono necessari sia per la ricerca che per la comunicazione
sull’uso dei prodotti.
Le aziende farmaceutiche hanno aumentato considerevolmente i loro investimenti nelle strategie di marketing digitale, che includono siti Web, e-marketing
e social media. Un esempio è il portale Web Digital Marketing Farmace, accessibile all’indirizzo http://www.digitalmarketingfarmace/. Nonostante la mancanza
di un quadro normativo complessivo per il “direct-to-consumer” social media
marketing, il monitoraggio degli eventi avversi, la loro gestione e un’analisi
incompleta del ritorno sugli investimenti, un recente rapporto pubblicato nel
2014 da Cutting Edge, rivista americana con sede in North Carolina, ha riportato che il marketing digitale nelle aziende farmaceutiche, come percentuale
del marketing mix, è salito nel 2011 al suo più alto livello. I canali digitali presi
in considerazione nel rapporto sono siti Web proprietari, siti sponsorizzati, spot
pubblicitari, banner pubblicitari, social media, tra cui blog, LinkedIn, Facebook,
Twitter, Flickr, portali su cui condividere video, come YouTube e forum.
2 Obamacare è la riforma sanitaria statiunitense attuata nel 2010 dal presidente della
Repubblica Barack Obama e riguarda pazienti, datori di lavoro e compagnie di
assicurazione per la salute. Si tratta di una legge per permettere a tutti i cittadini
statiunitensi di accedere senza vincoli alle infrastrutture sanitarie degli Stati Uniti.
[ 17 ]
[ 18 ]
Capitolo 2
I fattori che hanno influenzato la crescita e l’espansione del digital marketing
farmaceutico sono i seguenti:
••
Il ridimensionamento della spesa pubblicitaria. La necessità di ridimensionare i costi pubblicitari ha spinto le case farmaceutiche a tagliare le
spese su carta stampata, investendo nei canali digitali, caratterizzati da
costi relativamente bassi rispetto ai media tradizionali: ad esempio, uno
strumento come YouTube è stato apprezzato da diverse aziende come
sostituto della televisione (sebbene questo possa essere considerato un
approccio addirittura riduttivo nei confronti del canale digitale).
••
Lo scarso ritorno sull’investimento (ROI) con i media tradizionali. Un’importante azienda farmaceutica, di cui non è possibile qui riportare
il nome per privacy, in soli due anni ha incrementato dal 5% al 90% il
budget di marketing dedicato ai canali digitali, dopo una valutazione
della strategia online e dei risultati immediati, rispetto ai concorrenti. I
canali di comunicazione TV e radio, che prima rappresentavano il 50%
del marketing, sono stati eliminati e le spese per la stampa sono state
ridotte dal 25 al 10%.
••
Il mobile “specializzato”. L’utilizzo della telefonia “mobile” ha avuto, nel
2011, un incremento più forte di ogni altro canale digitale. Circa il 69%
delle aziende con un marchio sostiene di usare la tecnologia “mobile”
per il marketing o per iniziative mediche, un numero che, secondo il rapporto, dovrebbe raggiungere il 100% entro il prossimo anno. Le app per
device mobili sono dirette a medici, a pazienti e ad altri professionisti del
settore sanitario, come, per esempio, i farmacisti. “Le aziende farmaceutiche stanno decidendo quali tipi di applicazione mobile vogliono utilizzare”, si legge ancora nel rapporto Cutting Edge, ma sembrano tendere
verso lo sviluppo di applicazioni su misura per i medici e pazienti. Oltre
alle applicazioni, un esempio di come le aziende farmaceutiche stiano
conquistando questo canale è il lancio, da parte di Pfizer, di 10 siti Web
ottimizzati per alcuni farmaci e per i dispositivi mobili.
Business plan del sistema
2.2 Analisi SWOT
L’analisi SWOT è un processo di formulazione strategica in cui si fanno emergere
gli elementi del contesto competitivo capaci di favorire o di ostacolare il perseguimento degli obiettivi del progetto. Si tratta di una tecnica sviluppata ormai
da molti anni per valutare gli scenari di sviluppo progettuale.
L’analisi SWOT sottolinea gli elementi che contribuiscono al raggiungimento degli obiettivi del progetto, facendo leva su caratteristiche proprie (interne) e di
mercato (esterne) e, allo stesso tempo, quelli positivi e negativi.
Più specificamente, nell’analisi SWOT, i fattori si distinguono in quelli interni,
esterni, positivi e negativi.
I fattori interni, che afferiscono, ad esempio, all’ambiente dell’azienda, rappresentano i punti di forza e quelli di debolezza del progetto, ossia ciò che si identifica con un vantaggio competitivo rispetto ai progetti dei concorrenti. Esempi
tipici sono gli skill, le competenze o le risorse possedute da una determinata
azienda.
I fattori esterni, che afferiscono all’ambiente esterno all’azienda, invece, si dividono in opportunità e minacce. Queste ultime possono creare o distruggere valore
nel progetto e, quindi, nell’azienda; non possono essere controllate dall’interno
perché emergono dalle dinamiche competitive contestuali o da fattori demografici, economici, politici, sociali, legali o culturali.
I fattori positivi sono fattori che favoriscono il raggiungimento degli obiettivi del
progetto e riguardano i punti di forza e le opportunità.
I fattori negativi sono fattori che, invece, ostacolano e/o limitano il raggiungimento degli obiettivi progettuali e comprendono i punti di debolezza e le minacce.
L’analisi SWOT prevede le analisi preliminari dei suddetti fattori e una successiva costruzione di una matrice SWOT. Essa consiste nelle definizioni di quattro
aspetti:
••
punti di forza (Strength): risorse e competenze di cui l’azienda è dotata e
che è in grado di utilizzarle al meglio per raggiungere i propri obiettivi;
••
punti di debolezza (Weakness): limiti interni dell’azienda che ostacolano il
raggiungimento degli obiettivi prefissati;
[ 19 ]
[ 20 ]
Capitolo 2
••
punti di opportunità (Opportunity): situazioni favorevoli nel contesto
esterno all’azienda sulla quale agisce la strategia aziendale;
••
minacce (Threat): situazioni sfavorevoli nel contesto esterno all’azienda
che potenzialmente ostacolano la strategia aziendale.
La finalità dell’analisi SWOT sarà quella di mettere in luce e utilizzare i quattro
elementi per il raggiungimento degli obiettivi di un progetto. Partendo dai
quattro elementi, ne consegue che la strategia consiste nello sfruttare i punti
di forza, eliminare i punti di debolezza, sfruttare le opportunità e attenuare le
minacce del progetto.
2.2.1 Analisi SWOT del nostro sistema
Dalle osservazioni esposte nel paragrafo 2.1.2, si può derivare l’analisi SWOT mostrata in Figura 2.1.
tecnologie
•Possibilità, da parte di qualche
azienda farmaceutica, di utilizzare
l’app come gadget da regalare ai
medici
•Possibilità
di
applicare
la
medesima tecnologia in altri
contesti
medici
differenti
dall’analisi ematologica
Figura 2.1 - Analisi SWOT applicata al sistema
di
nuovi
•Possibile
ingresso
competitor
•A mbito di applicazione selettivo
•Innovazione e ricerca di nuovi
prodotti
•Resistenza, da parte di molti
medici di base e pazienti anziani
all’utilizzo della tecnologia
•Supporto
multipiattaforma
su
personal
computer,
tablet,
smartphone e smartwatch
•Supporto costante di uno dei
maggiori esperti internazionali di
ematologia
•Scalabilità
•Impiego
di
all’avanguardia
•Elevato know-how frutto delle
esperienze pregresse del team
Business plan del sistema
[ 21 ]
[ 22 ]
Capitolo 2
Architettura e
progettazione del sistema
Capitolo 3
Il presente capitolo espone l’architettura e la progettazione del sistema oggetto della
presente tesi. Più specificatamente, verranno descritte le caratteristiche tecniche e
l’architettura del sistema. Dopodiché verrà illustrata la progettazione del database
attraverso l’uso del modello relazionale.
[ 24 ]
Capitolo 3
3.1 Caratteristiche tecniche del sistema
Le caratteristiche principali del sistema in esame devono essere la semplicità di
utilizzo, la velocità di esecuzione e la sicurezza.
La semplicità di utilizzo del sistema è l’attitudine del sistema ad essere utilizzato
da chiunque, anche da coloro che non possiedono conoscenze tecniche dell’informatica. Il requisito fondamentale sarà, quindi, quello di rendere il sistema
facilmente consultabile dal medico di base attraverso un’interfaccia intuitiva.
La velocità di esecuzione indica la velocità di elaborazione delle richieste effettuate dall’utente. Il requisito principale si basa sull’utilizzo di query sul database:
la velocità di risposta del server dipende sia dalla quantità dei dati presenti nel
database che dalla complessità di esecuzione delle
richieste dell’utente. Quindi, per quanto riguarda le elaborazioni complesse su database, si è
Una tabella temporanea è una tabella
provveduto ad implementare query che ope-
che viene creata temporaneamente
rano su viste virtuali e tabelle temporanee per
durante una transazione, ma viene
migliorare la velocità di esecuzione.
eliminata al termine della stessa.
La sicurezza del sistema rappresenta una proprietà fondamentale ed essenziale nel progetto in esame, soprattutto per quello che riguarda i dati degli utenti nel rispetto della privacy.
Per questo motivo, è necessario implementare
una query in SQL trasparente all’utente, che verifi-
cherà se nel database esiste quel determinato username con
la relativa password.
3.2 Architettura del sistema
Il sistema si basa su un’architettura client-server, dove:
••
Il client consiste nell’app mobile del medico di base, implementata con
il framework Apache Cordova.
••
Il server consiste in un Web Service in PHP 5 che, al fine di fruire dei servizi richiesti dal client, elabora le richieste dell’app, i dati presenti nel
database e le conoscenze mediche presenti in una base di conoscenza
XML, necessarie per la gestione delle diagnosi dell’anemia.
Architettura e progettazione del sistema
[ 25 ]
Client e server comunicano fra loro attraverso JSON, cioè tramite messaggi
HTTP contenenti dati testuali in formato JSON.
Il DBMS adoperato nel progetto è MySQL 5.5.
Descriviamo, adesso, le tecnologie alla base dell’architettura del sistema.
3.2.1 Apache Cordova
Apache Cordova (alcune volte denomincato
con il nome del suo predecessore PhoneGap)
è un framework open source, cross-platform e
Un’app ibrida consiste in un’app nativa
mobile per lo sviluppo di app ibride. In altre
che esegue localmente sul dispositivo
parole, si tratta di una libreria software per svi-
mobile
luppare app ibride compatibili con qualsiasi
utilizzando tecnologie Web come,
dispositivo e piattaforma mobile.
per esempio, HTML 5, CSS 3 e
Seguendo l’approccio di programmazione
JavaScript.
una
Web
Web, Apache Cordova permette di utilizzare
HTML 5 e CSS 3 per implementare l’interfaccia
grafica della propria app e fornisce un set di API
che permettono allo sviluppatore di accedere, tramite chiamate JavaScript, alle risorse native del dispositivo mobile (fotocamera, accelerometro, GPS, file system, etc.).
Cordova prevede che ogni chiamata alle API venga poi “tradotta” dal framework
nella relativa chiamata implementata in codice nativo del dispositivo di utilizzo.
Il risultato di tale operazione è un codice sorgente che risulterà essere uniforme
indipendentemente dalla piattaforma di utilizzo, e che metterà lo sviluppatore
in condizione di disinteressarsi del dispositivo di utilizzo finale.
Proprio l’uso di tecnologie Web come HTML 5, CSS 3 e JavaScript rappresenta
la garanzia che l’app sia, a tutti gli effetti, multipiattaforma e che il porting su
dispositivi differenti non comporti, se non in minima parte, la necessità di modifiche al codice. Le applicazioni implementate con Cordova saranno compilate
come quelle native usando le relative SDK, in modo che siano installabili dai
tradizionali canali di distribuzione (App Store, Google Play e Windows Phone
Store).
application
[ 26 ]
Capitolo 3
Nonostante il framework si fondi sulla filosofia di unicità del codice, è comunque
inevitabile che la fase di deploy dell’applicazione debba essere effettuata su una
piattaforma di sviluppo nativa. Per questo motivo, il deploy dell’app prevede
la creazione di tre progetti, uno per ogni piattaforma. In particolare, si creano:
1. un progetto per iOS sull’IDE Xcode;
2. un progetto per Android sull’IDE Eclipse o simile;
3. un progetto per Windows Phone sull’IDE Visual Studio.
Cordova consente l’utilizzo combinato con altre librerie e framework esterni in
JavaScript, come, per esempio, Onsen UI, framework adoperato nel progetto
per realizzare l’interfaccia grafica dell’app.
Cordova è ormai utilizzato come soluzione mobile dalle grandi aziende e organizzazioni del settore IT. Tra queste, ne segnaliamo Adobe, Facebook, IBM,
Microsoft e Wikipedia.
Descriviamo le tre tecnologie alla base di Cordova nella prossima sezione.
Architettura e progettazione del sistema
3.2.1.1 HTML 5, CSS 3 e JavaScript
HTML 5 è un linguaggio di markup per la creazione di pagine, da Ottobre 2014
pubblicato come W3C Recommendation. Si tratta di HTML 4 con miglioramenti
e nuove funzionalità.
Tra le novità di HTML 5, si segnalano:
••
l’introduzione dei tag semantici;
••
il salvataggio dei dati su dispositivo dell’utente;
••
l’accesso offline alla Web application;
••
l’esecuzione di operazioni in background;
••
la gestione di flussi multimediali (video, audio);
••
l’editing di contenuti complessi, come, per esempio, i documenti di testo;
••
la gestione della cronologia della navigazione;
••
la gestione delle funzioni di drag and drop;
••
la generazione di grafici 2D e 3D in tempo reale;
••
l’accesso e la manipolazione delle informazioni generate in tempo reale
dall’utente attraverso sensori multimediali, quali microfono e webcam.
[ 27 ]
[ 28 ]
Capitolo 3
CSS (acronimo che sta per Cascading Style Sheets, fogli di stile) è un linguaggio
utilizzato per definire la visualizzazione dei documenti HTML, quindi delle pagine Web.
La Versione 3 di CSS introduce le seguenti novità:
••
nuove proprietà e nuovi metodi per la definizione del colore;
••
nuove proprietà dedicate alla gestione di bordi e sfondi;
••
funzionalità legate al testo e ai font, come, per esempio, la possibilità di
usare caratteri tipografici non presenti sul computer dell’utente (Web
Font);
••
layout multi-colonna;
••
possibilità di servire fogli di stile ad hoc in base alla tipologia dei dispositivi (media query);
••
metodi e tecniche per dare dinamicità alla pagina (transizioni, trasformazioni, animazioni).
JavaScript è un linguaggio di scripting orientato agli oggetti e agli eventi ed è
comunemente utilizzato nella programmazione Web lato client. Si tratta di un
linguaggio utilizzato nelle Web application per la creazione di effetti dinamici
interattivi. Questi effetti vengono realizzati tramite script invocati da eventi, a
loro volta innescati dall’interazione dell’utente via mouse o tastiera sulla pagina
Web in uso.
JavaScript è formalizzato con una sintassi più vicina a quella del linguaggio
Java e definisce le funzionalità tipiche dei linguaggi di programmazione objectoriented (classi, strutture di controllo, cicli, espressioni regolari, etc.).
A differenza di altri linguaggi come PHP, che permette la scrittura di software
completamente stand-alone, JavaScript viene utilizzato soprattutto come linguaggio di scripting integrato all’interno di un altro software: l’idea di JavaScript
è che il codice venga eseguito dal browser tramite un interprete incorporato nel
browser stesso quando viene visitata una pagina Web.
Affinché uno script venga invocato dal browser in una Web app, JavaScript si
rapporta con il browser mediante chiamate basate su DOM1.
1
DOM (acronimo che sta per Document Object Model, modello a oggetti del documento)
è un modello di dati introdotto dal consorzio W3C per rappresentare il contenuto
di documenti strutturati, in modo tali da essere neutrali sia per la lingua che per la
piattaforma. DOM consente di rappresentare il contenuto di un documento, come,
Architettura e progettazione del sistema
Un utilizzo principale di JavaScript in ambito Web riguarda l’implementazione
di funzioni integrate nelle pagine HTML che interagiscono con il DOM del browser, in modo tale da compiere determinate azioni non possibili con le pagine
HTML statiche. Un esempio di funzione di questo tipo è il menù a comparsa.
3.2.2 PHP 5
PHP (acronimo ricorsivo di PHP: Hypertext Preprocessor, PHP - preprocessore di
ipertesti) è un linguaggio di programmazione interpretato, originariamente concepito per la programmazione di pagine Web dinamiche. L’interprete PHP è un
software open source distribuito sul Web.
Attualmente, PHP è principalmente utilizzato per lo sviluppo di applicazioni
Web lato server, ma può essere usato anche per realizzare script a riga di comando o applicazioni stand-alone con interfaccia grafica.
PHP riprende, per molti versi, la sintassi del linguaggio C e, a partire dalla Versione 5, migliora il supporto al paradigma di programmazione ad oggetti. Il linguaggio è in grado di interfacciarsi a innumerevoli DBMS, tra cui MySQL, Oracle
DBMS, PostgreSQL, MariaDB, Microsoft SQL Server, e tanti altri. Solo per citarne
alcuni, PHP supporta anche DBMS NoSQL come, per esempio, MongoDB, e numerose tecnologie tra le quali JSON e XML.
PHP si integra con altri linguaggi/piattaforme, come Java e .NET: si può dire che
ne esista un wrapper per ognuno di essi.
per esempio, una pagina HTML, secondo una struttura ad albero.
[ 29 ]
[ 30 ]
Capitolo 3
3.2.3 JSON
JSON (acronimo che sta per JavaScript Object Notation, notazione a oggetti di
JavaScript) è un formato di file testuale basato su JavaScript e progettato per
lo scambio dei dati. Rappresenta un’alternativa a XML nello scambio di dati fra
client e server. JSON trova utilità non solo in tale applicazione, ma anche in altre,
come, per esempio, la gestione della configurazione di un sistema software.
L’uso di JSON tramite JavaScript è particolarmente
semplice, in quanto l’interprete JavaScript esegue il parsing tramite una semplice chiamata
eval() è un metodo di JavaScript per
alla funzione eval(). Tale caratteristica ha
eseguire uno statement in JavaScript,
reso JSON molto popolare nella programma-
rappresentato come una stringa di
zione Web e, in particolare, in quella mobile.
input.
JSON supporta i principali typesystem dei
linguaggi object-oriented: booleani (true e
false), interi, reali, virgola mobile, stringhe
racchiuse da doppi apici (“), array (sequenze
ordinate di valori, separati da virgole e racchiusi
in parentesi quadre), array associativi (sequenze chiave-valore separate da virgole racchiuse in parentesi graffe), e valori NULL.
Grazie alla semplicità e al typesystem di JSON, esistono progetti open-source
che consentono l’utilizzo di questa tecnologia con altri linguaggi, come PHP,
Java, C#, Objective C, Python, C++ e tanti altri.
Architettura e progettazione del sistema
3.2.4 MySQL
MySQL è un DBMS relazionale, composto da un client con interfaccia a riga di comando e un server, entrambi disponibili per Windows, GNU/Linux e OS X (anche
se prevale il suo utilizzo nel sistema operativo del pinguino).
MySQL possiede delle interfacce per diversi linguaggi object-oriented, come,
per esempio, PHP. Può essere accompagnato da alcuni tool che rendono più
agevole sia la gestione che l’interrogazione del database, come, per esempio,
phpMyAdmin.
phpMyAdmin è una Web application scritta in PHP e rilasciata su licenza open
source. Consente di amministrare un database MySQL tramite un browser qualsiasi ed è indirizzata principalmente agli amministratori del database; essa consente di creare un database da zero, creare tabelle ed eseguire operazioni di
ottimizzazione sulle stesse. Inoltre, fornisce un feedback sulle operazioni effettuate per evitare eventuali errori, e molto altro.
3.2.5 XML
XML (acronimo che sta per eXtensible Markup Language, linguaggio di markup
estensibile) è un linguaggio di markup, ovvero un linguaggio marcatore basato
su un meccanismo sintattico per definire e controllare il significato degli elementi contenuti in un documento strutturato. Si tratta di un linguaggio progettato per lo scambio dei dati. Esso trova utilità non solo nello scambio di dati fra
client e server, ma anche in altre applicazioni, come, per esempio, la gestione
della configurazione di un sistema software tramite file.
XML consente di definire in modo semplice nuovi linguaggi di markup da usare
in ambito Web: l’acronimo indica che si tratta di un linguaggio marcatore estensibile, in quanto permette di creare tag personalizzati.
[ 31 ]
[ 32 ]
Capitolo 3
3.2.6 XML Schema
XML Schema è un linguaggio di descrizione del contenuto di un file XML ed ha lo
scopo di delineare gli elementi permessi in un documento XML, i tipi di dati ad
essi associati e le relazioni gerarchiche che hanno fra loro.
XML Schema permette, principalmente, la validazione del file XML, ovvero la
verifica che i suoi elementi rispettino la sintassi di XML e che siano in accordo
con un preciso XML Schema.
XML Schema permette, inoltre, l’estrazione, o meglio una visione, da un file XML
di un insieme di oggetti con determinati attributi ed una struttura.
3.2.7 XQuery
XQuery (abbreviazione per XML Query Language) è un linguaggio di query destinato ad interrogare documenti e basi di dati XML. Sfrutta la sintassi delle
espressioni di XPath2 per la selezione degli elementi di un documento XML, con
l’aggiunta delle cosiddette espressioni simili a SQL per la formulazione di query
complesse.
A differenza di SQL, che opera su DBMS relazionali, XQuery usa delle strutture
dati disposte nell’ordine in cui appaiono nel documento XML, quindi secondo
una struttura ad albero.
3.3 Progettazione del database
L’utilizzo di un database di supporto al progetto in esame è necessario per il
funzionamento del sistema, in quanto l’archiviazione e l’interrogazione dei dati
rappresentano attività essenziali per la costruzione del sistema stesso. Data la
complessità del sistema, la progettazione del database risulta essere alquanto
elaborata ma, attraverso l’utilizzo di alcune tecniche, è possibile realizzare un
database efficiente e funzionale al tempo stesso.
2 XPath è un linguaggio che permette di individuare, tramite delle espressioni, gli
elementi o attributi presenti in un documento XML. Le espressioni XPath servono,
quindi, a localizzare con precisione gli elementi o attributi di un documento XML.
Architettura e progettazione del sistema
La progettazione del database a supporto del nostro progetto è stata fatta con
l’ausilio del modello relazionale sulla base dei requisiti descritti nell’introduzione della tesi.
Prima di illustrare lo schema del database, è necessario fare alcune considerazioni sulla gestione dell’area riservata e, in particolare, sull’utente “medico”.
3.3.1 Gestione dell’area riservata
Per quanto riguarda la gestione dell’area riservata, si è deciso di introdurre la
tabella “account”, caratterizzata dai seguenti campi:
••
un id univoco, che viene assegnato automaticamente dal DBMS quando
viene inserito un nuovo elemento;
••
uno username univoco;
••
una password di accesso;
••
attributi per la gestione della sicurezza del sistema.
Quindi, per accedere all’area riservata del sistema, l’utente “medico” inserirà uno
username e la relativa password tramite il login. Il sistema accederà al database
e verificherà la correttezza di tali credenziali. In caso affermativo, l’app del medico visualizzerà una schermata di benvenuto e, a questo punto, l’utente potrà accedere ai propri dati e a quelli dei propri pazienti (dati anagrafici, sintomi, esami,
etc.) Un’altra caratteristica del sistema è la possibilità di effettuare valutazioni
diagnostiche sui dati riscontrati dai pazienti in esame.
3.3.2 Utente “medico”
L’utente “medico” è una categoria di utente che si avvicina al ruolo di amministratore. Tuttavia, non può amministrare l’intero sistema; esso, infatti, può
svolgere on-line solo una parte delle attività del sistema, come la gestione del
proprio profilo e dei propri pazienti.
L’utente può registrare nuovi pazienti, gli esami effettuati, i sintomi e i risultati
clinici presentati dagli stessi. Tali funzionalità consentono di memorizzare i dati
utili per rilevare le eventuali patologie manifestate dai pazienti.
[ 33 ]
[ 34 ]
Capitolo 3
3.3.3 Schema relazionale del database
La Figura 3.1 mostra lo schema relazionale relativo al database del sistema, realizzato con MySQLWorkbench, tool visuale per lo sviluppo di database MySQL. Lo
schema è stata realizzato secondo le peculiarità di ciascun concetto coinvolto.
Di seguito sono elencate le entità coinvolte con le rispettive relazioni:
••
medico, entità che rappresenta un medico di base ed è caratterizzata da
un id univoco, un nome, un cognome, un codice fiscale e un indirizzo
e-mail; un medico possiede un solo account e può seguire zero o più
pazienti.
••
account, entità che rappresenta l’account del medico e comprende un id
univoco, uno username, una password e alcuni dati per la gestione della
sicurezza del sistema; un account è posseduto da un solo medico.
••
paziente, entità che rappresenta un paziente ed è caratterizzata da un id,
dai dati anagrafici e dai recapiti di un paziente; un paziente viene seguito
da zero o più medici, effettua zero o più esami, dichiara zero o più sintomi ed è associato a zero o più transazioni.
••
transazione, entità che riporta informazioni sulle diagnosi di eventuali
patologie presenti in un paziente ed è caratterizzata da un id univoco,
dal nodo dell’albero di decisione e dalla diagnosi finale; una transazione
riguarda un solo paziente.
••
sintomo, entità che denota un sintomo presentato da un paziente (capogiri, cefalea, etc.) ed è caratterizzata da un id, un nome e la descrizione di
un sintomo; un sintomo viene dichiarato da zero o più pazienti.
••
esame, entità che rappresenta un esame effettuato da un paziente ed è
caratterizzata dalla data di esecuzione e da quella di prescrizione di un
esame; un esame è svolto da un solo paziente, appartiene ad una sola
tipologia e comprende una o più voci con determinati valori.
••
tipologia, entità che rappresenta la tipologia di un esame ed è caratterizzata da un id univoco, dalla categoria e dalla descrizione di un esame;
una tipologia è relativa a zero o più esami e possiede una o più voci.
••
voce, entità che rappresenta un parametro clinico presente in una certa
tipologia di esame ed è caratterizzata da un id univoco, da un nome e
da note aggiuntive; una voce è presente in una sola tipologia di esame
effettuato da un paziente e presenta un certo valore.
Architettura e progettazione del sistema
Figura 3.1 - Schema relazionale del DB
[ 35 ]
[ 36 ]
Capitolo 3
Di seguito sono elencate le relazioni che coinvolgono le suddette entità:
••
medico_paziente, relazione molti-a-molti che associa un medico a un
paziente seguito dal medico stesso ed è caratterizzata dalla data di registrazione; il significato dell’associazione è il seguente: un medico segue
zero o più pazienti, così un paziente è seguito da zero o più medici.
••
paziente_sintomo, relazione molti-a-molti che associa un paziente a uno
o più sintomi che egli presenta, ed è caratterizzata da una data; il significato dell’associazione è il seguente: un paziente dichiara zero o più sintomi, così un sintomo è dichiarato da zero o più pazienti.
••
esame_voce, relazione molti-a-molti che associa un esame ad una voce
ed è caratterizzata da un valore numerico; il significato dell’associazione
è il seguente: un esame comprende zero o più voci, ognuno con un certo
valore, così una voce è presente in zero o più esami.
Implementazione del sistema e
guida utente
Capitolo 4
Il presente capitolo inizia con la descrizione delle scelte implementative dell’algoritmo
per la diagnosi dell’anemia. In particolare, verranno proposti alcuni cenni sui design
pattern applicati ad esso e su un modello strutturale alla base dell’algoritmo:
l’albero di decisione. Dopodiché, si mostrano alcune porzioni di codice sorgente
dell’algoritmo e, infine, tramite una sorta di guida utente per il sistema oggetto della
presente tesi, si illustreranno i servizi fruibili dal medico.
[ 38 ]
Capitolo 4
4.1 Implementazione dell’algoritmo
Progettare software basato sul paradigma ad oggetti non è affatto banale. Riuscire a renderlo anche riusabile ed estendibile a proprio piacimento è ancora
più arduo. Ciò che occorre, di volta in volta, è saper individuare gli oggetti giusti,
con un livello di dettaglio e di granularità adeguato, ed essere in grado di definire una struttura gerarchica consistente, basata su un insieme di relazioni e
collaborazioni coerente ed efficace.
Riuscire nell’intento di definire al primo tentativo una struttura ad oggetti che
sia corretta e, al tempo stesso, riusabile ed estensibile è un’impresa molto ardua,
soprattutto nel caso di applicazioni particolarmente complesse. Generalemente, durante la sua realizzazione, un software subisce innumerevoli modifiche
dettate dalla variabilità delle specifiche progettuali, dalla scarsa conoscenza del
dominio applicativo e dall’inesperienza. In più, la mancanza di tempo, che nei
progetti di sviluppo è un aspetto quasi congenito, porta sovente a scegliere soluzioni molto focalizzate sul modello reale attuale e poco orientate ad adattarsi
ai cambiamenti futuri.
In uno scenario come quello sopra descritto, per chi implementa il codice, diventa importante saper individuare delle soluzioni che siano riutilizzabili più
volte nell’ambito di uno stesso progetto, piuttosto che in progetti diversi, senza
ogni volta dover partire da zero per risolvere uno specifico problema.
Per minimizzare il lavoro da svolgere, gli sviluppatori meno esperti solitamente
tendono a ricorrere a tecniche non orientate agli oggetti (non ultimo, il famigerato copia-e-incolla), con il risultato di duplicare parti di codice e di introdurre
in modo più o meno voluto accoppiamento e dipendenze tra gli oggetti. Gli
architetti e gli sviluppatori con più esperienza tendono, invece, a preferire le soluzioni orientate ad oggetti che, in passato, si sono rivelate vincenti ed efficaci.
Queste soluzioni sono rappresentate dai design pattern, ossia soluzioni software
orientate alla risoluzione di particolari problematiche e che tendono ad introdurre, nell’ambito di una struttura ad oggetti, quella flessibilità necessaria per
rendere il codice riutilizzabile ed estendibile. In questo modo, si minimizza il
lavoro da svolgere durante le attività di implementazione e manutenzione del
sistema.
Implementazione del sistema e guida utente
[ 39 ]
A margine di tale discussione, all’algoritmo dell’anemia si sono applicati i seguenti pattern:
••
Template Method, che verrà utilizzato per demandare le parti invarianti
dell’algoritmo ad una superclasse, mentre quelle variabili verranno affidate a delle sottoclassi.
••
DAO, che verrà applicato per rendere portabile il codice relativo alla gestione della persistenza.
L’applicazione dei suddetti pattern verrà esposta nel Paragrafo 4.1.5.
4.1.1 TemplateMethod Pattern
Template Method è un pattern comportamentale basato su classi e utilizzato nell’ambito
della programmazione orientata agli oggetti.
Un pattern comportamentale è un
Permette di definire la struttura di un algorit-
pattern finalizzato alla distribuzione
mo lasciando alle sottoclassi il compito di im-
delle responsabilità fra oggetti tra
plementare alcuni passi dello stesso. Quindi, il
loro correlati. Fornisce soluzioni per
pattern consente di ridefinire e personalizzare
incapsulare diverse funzioni in un
parte del comportamento nelle varie sotto-
oggetto specifico, con l’intento di
classi senza dover riscrivere più volte il codice
delegare ad esso l’esecuzione del
in comune.
codice vero e proprio.
L’intento del pattern consiste nel definire lo
“scheletro” di un algoritmo in un metodo di
una superclasse, detto metodo template, e, inoltre, nel delegare alcuni passi dell’algoritmo stesso alle sottoclassi. La
superclasse è una classe astratta, mentre le sottoclassi sono invece classi
concrete, ottenute per estensione della classe astratta1. Infine, i passi delegati
prendono il nome di operazioni primitive. Quindi:
••
i partecipanti del pattern sono due: la classe astratta e le classi concrete;
1Una classe astratta è una classe di cui non si può creare un’istanza, per poter essere
utilizzata. Essa deve essere obbligatoriamente ereditata da una classe concreta.
Invece, una classe concreta è una classe di cui si può creare un’istanza e può estendere
un’altra classe, come, per esempio, una classe astratta.
[ 40 ]
Capitolo 4
••
il metodo template rappresenterà la parte invariante dell’algoritmo,
mentre le operazioni primitive quelle varianti: su queste parti si agirà
durante le attività di implementazione e sviluppo dell’algoritmo.
La Figura 4.1 mostra il diagramma delle classi relativo a Template Method.
Figura 4.1 - Diagramma delle classi nel Template Method Pattern
In un certo senso, Template Method ribalta il meccanismo dell’ereditarietà secondo quello che viene scherzosamente chiamato “principio di Hollywood”:
“non chiamarci, ti chiameremo noi”. In altre parole, nel pattern, è il metodo template a chiamare i metodi primitivi ridefiniti nelle classi concrete.
Template Method si applica generalmente quando si vuole implementare parti
invarianti di un algoritmo e lasciare alle sottoclassi l’implementazione dei comportamenti variabili dello stesso.
4.1.2 DAO Pattern
DAO (acronimo che sta per Data Access Object, oggetto per l’accesso ai dati)
è un pattern basato su classi e utilizzato nell’ambito della programmazione
orientata agli oggetti. Permette di rappresentare un’entità tabellare di una
sorgente dati mediante una classe, indipendentemente dalla sorgente stessa.
Implementazione del sistema e guida utente
[ 41 ]
L’intento del pattern consiste nel disaccoppiare l’accesso dati rispetto alla sua
memorizzazione sottostante. Per questa ragione, DAO consente di scegliere la
sorgente dei dati da utilizzare durante l’implementazione del software.
DAO si applica generalmente quando si vuole implementare logiche di accesso ai dati che siano portabili rispetto alla sorgente dei dati. In questo modo, la
logica di business rimarrà invariata, mentre quella di accesso al database sarà
variabile in funzione della sorgente dei dati. Il pattern è usato principalmente in
sistemi con architettura client-server in cui è presente un database relazionale
nel server.
4.1.3 Albero di decisione sulla diagnosi dell’anemia
Un albero di decisione è un modello strutturale ad albero utilizzato per il supporto delle procedure informatiche di decision making. Quindi, si tratta non
di una strutttura dati, bensì di una rappresentazione efficace e semplice degli
algoritmi basati su decisioni, come, per esempio, quello per la diagnosi dell’anemia.
Esaminando esaustivamente gli algoritmi clinici disponibili sul Web, si è scoperto che le procedure cliniche si basano su questo modello e godono delle
seguenti proprietà:
1. ogni algoritmo parte da un nodo radice, che
corrisponde a un order;
2. ogni nodo radice segue un nodo decisionale, ovvero una condizione di de-
Un order rappresenta una richiesta di
cisione sui risultati degli esami specifi-
esami che un paziente deve svolgere
cati dall’order connesso al nodo stesso;
per fini diagnostici.
3. ogni nodo di decisione può seguirne
un altro oppure collegarsi ad un nodo
foglia;
4. ogni nodo foglia corrisponde a un
suggerimento su possibili cause oppure ad una diagnosi finale di una certa
patologia.
[ 42 ]
Capitolo 4
In Figura 4.2 viene mostrato l’albero di decisione relativo alle anemie, che, in
termini informatici, può essere tradotto come segue:
Dopo aver registrato i sintomi presentati dal paziente in esame, il sistema consiglia
all’utente “medico di base“ di effettuare l’order o1 per quel paziente, ossia l’emocromo e l’esame sullo striscio periferico. A questo punto, il medico dovrà registrare i
risultati di quegli esami sul database.
Una volta registrati i risultati degli esami, il sistema valuta questi valori secondo la
seguente condizione booleana:
HGB < hgbThreshold && correctedReticulocyteIndex ≥ 2.5
dove:
•• HGB è un parametro clinico che denota il valore assoluto dell’emoglobina;
•• hgbThreshold indica la variabile soglia di HGB, che assume valori pari a:
* 13 g/dL se il paziente è di sesso maschile;
* 12 g/dL se il paziente è di sesso femminile.
•• correctedReticulocyteIndex specifica l’indice dei reticolociti corretti.
Se la suddetta condizione è verificata, allora si procede per la VIA 1, altrimenti per
la VIA 2.
Descriviamo adesso le due vie nelle prossime sezioni.
VIA 1
In questa via, si verifica se i globuli risultino enormemente frammentati all’esame
sullo striscio periferico. Se tale condizione è verificata, allora il sistema segnala al
medico le possibili cause di quei sintomi presentati dal paziente. A questo punto, il
software provvederà ad effettuare altre valutazioni tramite alberi di decisione esterni, quindi tramite altri algoritmi.
Invece, se la condizione non è verificata, il sistema suggerisce al medico la possibile
presenza di un’emorragia acuta nel paziente in esame.
Implementazione del sistema e guida utente
[ 43 ]
INDICATIONS FOR TESTING
Fatigue, weakness, pallor, dizziness, fainting
ORDER o1
CBC with Platelet Count and Automated
Differential (including RBC indices and
morphology on manual differential)
Reticulocytes, Percent & Number
DECISION d1
Anemia present on CBC (males Hgb <13g/dL,
females Hgb <12g/dL)
AND
Corrected reticulocyte index ≥2.5
No
Yes
DECISION d2
Fragmented cells on
peripheral smear
DECISION d3
Classify by RBC indices
DECISION d6
Normocytic, normochromic
(normal MCV, MCHC)
(suggests hypoproliferation)
DECISION d5
Microcytic, hypochromic
(low MCV, MCHC)
(suggests maturation defects)
Bone marrow disorder
(infiltration, aplasia)
Inflammation
Autoimmune disease
Chronic renal disease
Critical illness
Chronic endocrine
disorders
Aplastic anemia, pure
red cell aplasia
DECISION d4
Macrocytic
(high MCV)
(suggests maturation defects)
Folate, B12 deficiency
(see Megaloblastic
Anemia Testing
Algorithm)
Iron deficiency
Chronic disease
Thalassemia (see
Hemoglobinopathies
topic)
Sideroblastic anemia
Lead toxicity
No
Yes
Suspect
hemorrhage
and acute
blood loss
Suggests hemolytic process:
Metabolic defect (see PNH
Consult topic)
Hemoglobinopathies (eg,
sickle cell) (see Hemolytic
Anemias Testing Algorithm)
Autoimmune destruction
Splenic sequestration
RBC membrane defect (see
Hemolytic Anemias Consult
topic)
Intravascular hemolysis (see
Hemolytic Anemias Consult
topic)
Excessive alcohol use
Hypothyroidism
Myelodysplasia (see
Myelodysplastic
Syndromes Consult topic)
DECISION d7
Abnormal peripheral smear
ORDER o2
Iron and Iron Binding
Capacity
Ferritin
No
Yes
DECISION d8
Low/normal TIBC
Normal/high ferritin
Low/normal iron
Suggests:
Inflammation
Chronic disease
High TIBC
Low iron
Low ferritin
Iron deficiency
anemia
Workup based on
smear
characteristics
Bone marrow
biopsy may be
necessary
If no obvious chronic
disease present,
consider bone marrow
biopsy
© 2006 ARUP Laboratories. All Rights Reserved. 5/16/2011
Figura 4.2 - Albero di decisione relativo alle anemie
[ 44 ]
Capitolo 4
VIA 2
In questa via, si determina la tipologia dell’anemia secondo le classificazioni delle
anemie esposte nel Paragrafo 1.2.3. In base al tipo di anemia, il sistema segnala al
medico le possibili cause di quei sintomi presentati dal paziente e provvederà ad effettuare altre valutazioni tramite alberi di decisione esterni. Dopodiché, verifica se
i globuli risultino in numero abnorme all’esame sullo striscio. Se tale condizione è
verificata, allora il software suggerisce al medico di svolgere la biopsia sul midollo
osseo del paziente. Invece, se la condizione non è verificata, allora il sistema suggerisce al medico di effettuare l’order o2 per il paziente in esame, ossia la sideremia e
la ferritina.
In base ai valori riscontrati in questi due esami, l’algoritmo può segnalare uno dei
seguenti risultati:
••
il paziente in esame non è affetto da anemia;
••
il paziente in esame potrebbe avere un’infiammazione cronica e se la patologia è presente in modo evidente, allora si dovrebbe effettuare la biopsia
sul midollo osseo.
4.1.4 Base di conoscenza del test anemia
La base di conoscenza del test anemia è stata realizzata in XML e rispetta una
sintassi specificata tramite un preciso XML Schema.
La Figura 4.3 mostra la struttura della base di conoscenza XML dell’anemia, implementata con il software oXygen XML.
Il documento prevede un unico elemento root, chiamato Testing. Esso denota un test per la diagnosi di una determinata patologia e contiene:
••
un sottoelemento Information;
••
un sottoelemento Algorithm.
Il sottoelemento Information riporta le informazioni sull’algoritmo attraverso i sottotag Name e Description, che specificano, rispettivamente, il nome
e la descrizione dell’algoritmo.
Implementazione del sistema e guida utente
Figura 4.3 - Struttura della base di conoscenza relativa al test anemia
Il sottoelemento Algorithm include tre componenti fondamentali per l’esecuzione dell’algoritmo per il test anemia:
••
un sottoelemento Constants, che, a sua volta, contiene 15 sottotag
Constant;
••
un sottoelemento Orders, che contiene, a sua volta, 2 sottotag Order;
••
un sottoelemento Decisions, che, a sua volta, contiene 8 sottotag
Decision.
Il sottotag Constant rappresenta una costante fondamentale per l’algoritmo,
ai fini di valutazione dei risultati clinici del paziente in esame. Esso contiene una
stringa che denota un valore di soglia riportato in un nodo decisionale dell’albero di Figura 4.2. Il sottotag, inoltre, è caratterizzato da due attrbuti univoci:
id e name.
[ 45 ]
[ 46 ]
Capitolo 4
Il sottotag Order, come si evince dal nome, denota un order previsto nell’albero
di decisione mostrato in Figura 4.2. Esso contiene un sottotag Description,
per descrivere un order presente nell’albero, ed è caratterizzato dall’attributo
univoco id.
Il sottotag Decision rappresenta un nodo decisionale presente nell’albero.
Esso contiene un sottotag Code per riportare le istruzioni PHP che dovranno
essere invocate su richiesta dell’algoritmo ed è caratterizzato da un attributo
univoco id.
Si tenga presente che, nello schema relativo alla base di conoscenza, sono applicati i seguenti vincoli:
••
vincoli di chiave primaria applicati all’attributo id, presente nei sottotag
Constant, Order e Decision;
••
un vincolo di univocità assegnato all’attributo name, presente nel sottotag Constant.
4.1.5 Listati dell’algoritmo per la diagnosi dell’anemia
L’algoritmo ha lo scopo di fornire al medico dei suggerimenti per le diagnosi dell’anemia ed è scritto in PHP 5 usando l’IDE Eclipse e la suite di software
MAMP2. Esso viene invocato da algoritmo.php, script che viene eseguito solo
su richiesta da parte di un utente autenticato al sistema.
L’algoritmo è composto essenzialmente dai due partecipanti del pattern Template Method, cioè:
••
una classe astratta ClinicalTesting;
••
una classe concreta AnemiaTesting, che estende ClinicalTesting per ereditarietà.
Descriviamo, adesso, i codici sorgente di algortimo.php e delle suddette
classi.
2
MAMP è un acronimo che si riferisce ad una suite di software libero comunemente
utilizzata per far girare siti Web dinamici sul sistema operativo Apple Mac OS X.
L’acronimo sta per le iniziali dei seguenti software:
•
•
•
•
ac OS X, il sistema operativo;
M
Apache HTTP Server, il Web server;
MySQL, il DBMS;
PHP, Perl, o Python, linguaggi di programmazione di pagine Web dinamiche.
Implementazione del sistema e guida utente
Listato 4.1 - Listato dello script algoritmo.php
4.1.5.1 Script algoritmo.php
Lo script algoritmo.php, riportato in Listato 4.1, ha lo scopo di restituire al
client l’esito dell’algoritmo sotto forma di messaggio JSON. Questo scopo viene
raggiunto attraverso un processo che si articola come segue:
Se l’utente del client non è autorizzato all’accesso al sistema, riceverà un messaggio vuoto e, quindi, il processo termina. In caso contrario, lo script effettua le
seguenti operazioni:
1. caricamento della base di conoscenza XML;
2. estrazione dell’id della transazione relativa al paziente in esame dalla
richiesta JSON del client3;
3. esecuzione dell’algoritmo attraverso l’invocazione del metodo template
executeClinicalTesting(), presente in ClinicalTesting;
4. invio dell’esito dell’algoritmo sotto forma di messaggio JSON al client4.
3
L’id della transazione è contenuto nella richiesta HTTP di tipo POST, inviato dal client.
4 Una volta che il client riceve la risposta JSON, l’app stamperà il suo contenuto sullo
schermo del dispositivo mobile.
[ 47 ]
[ 48 ]
Capitolo 4
Listato 4.2 - Listato della classe ClinicalTesting
4.1.5.2 Classe ClinicalTesting
La classe ClinicalTesting, riportata in Listato 4.2, include un costruttore
per il caricamento della base di conoscenza XML, il metodo executeClinicalTesting() e una serie di metodi di supporto per quest’ultimo.
Il metodo template esegue le seguenti operazioni fondamentali:
1. estrazione del nodo corrente nell’albero dell’anemia a partire dall’id della transazione relativa al paziente in esame5;
2. esecuzione
che
va
del
metodo
rappresenta
dell’algoritmo
astratto
l’unica
ed
è
executeAlgorithm(),
operazione
implementato
nella
primiticlasse
AnemiaTesting.
4.1.5.3 Classe AnemiaTesting
La classe AnemiaTesting, riportata in Listato 4.3, include il metodo
executeAlgorithm(), implementazione dell’omonimo metodo astratto
5 L’operazione di estrazione del nodo corrente nell’albero dell’anemia si realizza
mediante classi DAO che operano su apposite tabelle del database.
Implementazione del sistema e guida utente
Listato 4.3 - Listato della classe AnemiaTesting
dichiarato nella classe ClinicalTesting. La funzione si basa su un costrutto
switch che effettua determinate operazioni in base al nodo corrente nell’albero delle anemie.
Per esempio:
••
se il nodo corrente è NULL, il sistema provvede ad inviare al client informazioni sull’order o1, che verrano estrapolate, tramite XQuery, dalla
base di conoscenza XML;
[ 49 ]
[ 50 ]
Capitolo 4
••
se il nodo corrente è, invece, o1, il sistema provvede ad effettuare una
valutazione a partire:
* dai dati relativi al paziente e al suo esame, che verranno estratti tramite le classi DAO;
* dalle costanti e dalle istruzioni PHP predefinite nella base di conoscenza XML, che verranno estratte sempre tramite XQuery.
L’esito del metodo verrà stampato nel messaggio JSON tramite l’istruzione PHP
echo.
4.2 Guida utente del nostro sistema
Per poter sfruttare le funzionalità dell’algoritmo, occorre, prima di tutto, effettuare l’autenticazione tramite app: la schermata principale dell’applicazione
consiste in un form di login, composto dai campi di input username e password
dell’utente “medico di base” e dal pulsante Login.
La Figura 4.4 mostra lo screenshot di login al sistema.
Figura 4.4 - Screenshot di login al sistema
Una volta compilati tutti i campi e poi premuto sul pulsante di login, il sistema
effettua le opportune verifiche e, quindi, l’utente sarà reindirizzato verso una
schermata, in cui sarà visualizzato un messaggio di avvenuta autenticazione e
di benvenuto. Da questa pagina è possibile sfruttare le funzionalità del sistema
tramite un menù, accessibile premendo il pulsante in alto a sinistra oppure scorrendo il dito sullo schermo da sinistra a destra.
Implementazione del sistema e guida utente
La Figura 4.5 mostra lo screenshot della schermata di avvenuta autenticazione
e di benvenuto. La Figura 4.6 mostra il menù con le funzionalità offerte dal sistema:
••
Logout;
••
Info Medico;
••
Aggiungi Paziente;
••
Ricerca Paziente.
Figura 4.5 - Screenshot di benvenuto
Figura 4.6 - Screenshot del menù
Logout è una funzionalità con cui l’utente esce dal sistema.
Info Medico è una funzionalità utilizzata per visualizzare e/o modificare il profilo
dell’utente, composto dai seguenti campi:
••
nome;
••
cognome;
••
indirizzo e-mail;
••
codice fiscale.
Aggiungi Paziente è una funzionalità che consente al medico di registrare i dati
anagrafici e i recapiti di un paziente in esame.
Ricerca Paziente è una funzionalità che permette al medico di cercare un paziente in esame.
Descriviamo, adesso, l’utilizzo dell’algoritmo nella prossima sezione.
[ 51 ]
[ 52 ]
Capitolo 4
4.2.1 Utilizzo dell’algoritmo per la diagnosi dell’anemia
Per poter utilizzare l’algoritmo per la diagnosi dell’anemia, occorre effettuare le
seguenti operazioni propedeudiche:
1. si registra un paziente tramite Aggiungi Paziente (Figura 4.7);
2. si cerca il paziente registrato tramite Ricerca Paziente (Figura 4.8);
3. si accede alla pagina del paziente trovato tramite Info Paziente (Figura
4.9);
4. si registrano i sintomi e la data di visita del paziente cercato tramite Visita
Medica (Figura 4.10), sezione dell’app accessibile da Info Paziente;
5. si registrano gli esami effettuati dal paziente tramite Inserisci esami, sezione dell’app accessibile da Info Paziente (Figura 4.11).
Una volta concluse le suddette operazioni, si può lanciare l’algoritmo cliccando
sul pulsante Valuta Decisione, accessbile da Info Paziente. A questo punto il sistema visualizzerà gli esami effettuati dal paziente e l’esito dell’esecuzione del processo, che consiste in un order, un suggerimento, oppure una diagnosi finale.
La Figura 4.12 mostra un esempio di esito dell’algoritmo, visualizzato cliccando
sul suddetto pulsante.
Figura 4.7 - Screenshot Aggiungi Paziente
Figura 4.8 - Screenshot Ricerca Paziente
Implementazione del sistema e guida utente
Figura 4.10 - Screenshot Visita Medica
Figura 4.9 - Screenshot Info Paziente
[ 53 ]
[ 54 ]
Capitolo 4
Figura 4.11 - Screenshot Inserisci Esame
Figura 4.12 - Screenshot Valuta Esame
Confronto con sistemi correlati
e studio del possibile
Capitolo 5
riuso del software
Nel presente capitolo verranno considerati alcuni sistemi per il settore sanitario. In
particolare, verrà effettuato un confronto tra tali sistemi e il sistema oggetto della
presente tesi, considerando sia gli aspetti comuni che quelli peculiari di ciascun
sistema. Infine, verrà fatta un’analisi del possibile riuso del software che compone il
sistema oggetto della presente tesi.
[ 56 ]
Capitolo 5
5.1 Confronto con sistemi correlati
I sistemi informativi a supporto delle attività sanitarie devono essere uno strumento per migliorare le attività dei medici, al fine di soddisfare i bisogni dei
pazienti. Esistono molti prodotti per questo settore, sia commerciali che gratuiti,
ma tra quelli analizzati si segnalano:
•
Medical Diagnosis System;
•
AnalisiSangue;
•
Salute.
Per ciascuno di essi, nelle prossime sezioni, si metteranno in evidenza le analogie e differenze rispetto al nostro sistema.
5.1.1 Medical Diagnosis System
Medical Diagnosis System (nel seguito, MDS) è un software gratuito e realizzato
da un progetto italiano. Si tratta di un sistema di supporto sanitario che presenta delle analogie con il nostro software. Queste ultime, riguardano prevalentemente, le funzionalità offerte da entrambi.
Sia MDS che il nostro sistema hanno lo scopo di supportare medico di base avvalendosi di una sorgente dati contenente sintomi, malattie ed esami associati a
tutte le patologie che ogni medico può trovarsi quotidianamente ad affrontare.
L’accesso ai servizi offerti è gestito tramite login.
Nonostante le loro analogie, si possono notare notevoli differenze analizzando i
due prodotti software. Più specificatamente:
1. MDS presenta un’interfaccia spartana di colore blu; il nostro sistema, invece, è dotato di un’interfaccia grafica accurata e di colori bianco e rosso,
che richiamano la salute.
2. MDS suggerisce una lista di ipotesi diagnostiche più probabili a partire
dal sesso e dall’età del paziente e dai sintomi rilevati dal medico (Figure
5.1 e 5.2); il nostro sistema, invece, suggerisce un’ipotesi clinica a partire
dal sesso, dall’età e dai dati clinici relativi al paziente.
Confronto con sistemi correlati e studio del possibile riuso del software
3. MDS prevede due categorie di utente, lo “specialista” e il “paziente”; per
il primo, i sintomi sono visibili in termini medici ufficiali, mentre per il
secondo, vengono proposti i sintomi in termini più semplici, attraverso
l’utilizzo di sinonimi dei termini tecnici; il nostro sistema, invece, prevede
solo una categoria utente identico allo “specialista”.
4. MDS è accessibile come portale Web oppure come app per smartphone
e tablet con Windows Phone; il nostro sistema, invece, come vedremo
nel Paragrafo 5.2, può supportare svariati dispositivi e piattaforme.
5. MDS è dotato di un pulsante per approfondire il sintomo o la diagnosi
sui motori di ricerca: si tratta di una funzionalità non presente nel nostro
sistema.
Figure 5.1 e 5.2 - Screenshot di Medical Diagnosis System
5.1.2 AnalisiSangue
AnalisiSangue è un’app a pagamento, sviluppata da un programmatore italiano
e dedicata esclusivamente all’analisi degli esami del sangue e delle urine (Figura
5.3).
AnalisiSangue e il nostro sistema presentano alcune analogie. Tra queste, segnaliamo la finalità del software e l’interfaccia, simili a quelle del nostro prodotto.
[ 57 ]
[ 58 ]
Capitolo 5
Le differenze tra i due prodotti riguardano funzionalità presenti in AnalisiSangue
ma non incluse nel nostro sistema. Tra questi citiamo:
•
visualizzazione del trend dei risultati clinici per mezzo di grafici (Figura
5.4);
•
invio report in formato PDF via e-mail.
Il software supporta solo iOS; questo è un punto debole rispetto al nostro sistema.
Figure 5.3 e 5.4 - Screenshot di AnalisiSangue
5.1.3 Salute
Salute è un app sviluppata dalla Apple per applicazioni sanitarie ed offre un’interfaccia simile a quella del nostro prodotto (Figure 5.5 e 5.6). Il software tiene
traccia dei parametri clinici relativi al possessore del dispositivo, ma non è in grado di svolgere valutazioni diagnostiche come il nostro sistema. Il motivo di ciò
è dovuto al fatto che l’app è stata progettata per l’archiviazione di dati relativi
alla salute, all’attività fisica e all’alimentazione del possessore del dispositivo; lo
scopo dell’app è quello di offrire all’utente uno strumento per la raccolta di dati,
la loro analisi statistica e la loro trasposizione in grafici (istogramma, poligono
di frequenza, etc.).
Il software non è rivolto a una categoria specifica di utente e, inoltre, non supporta né Android e né Windows Phone a causa di strategie di marketing dello
sviluppatore.
Confronto con sistemi correlati e studio del possibile riuso del software
Figure 5.5 e 5.6 - Screenshot di Salute
5.2
Analisi del possibile riuso del software applicato al nostro sistema
Durante la progettazione e l’implementazione del sistema, si sono potute
adoperare delle soluzioni software in grado non solo di soddisfare i requisiti della
realtà sanitaria, ma anche di rendere il software riusabile e, quindi, estensibile.
Da un punto di vista pratico, l’utilizzo di design pattern, di un framework per
lo sviluppo cross-platform di app e di una base di conoscenza XML implicano
senz’altro una riduzione dei tempi di sviluppo del sistema e, al tempo stesso,
una minore probabilità di errori.
A questo punto, si possono individuare le principali parti di software riusabile
presenti nel nostro sistema. Esse sono:
•
i codici HTML 5, CSS 3 e JavaScript relativi all’app;
•
il sorgente PHP della classe AnemiaTesting;
•
il documento XML relativo alla base di conoscenza relativa al test anemia;
•
la logica di accesso al database.
[ 59 ]
[ 60 ]
Capitolo 5
I codici dell’app sono riusabili perché il framework Cordova è cross-platform: i
codici della parte client del sistema possono essere riutilizzati per produrre non
solo app per dispositivi mobile Android e Windows Phone, ma anche un portale Web responsive per i personal computer e i dispositivi stessi1. Per quanto
riguarda la riusabilità di AnemiaTesting e della base di conoscenza, la classe
è riutilizzabile perché rappresenta la parte variabile del pattern Template Method. Inoltre, il documento XML può essere adattato ad altre conoscenze cliniche,
in quanto implementato secondo una sintassi
specificata tramite un preciso XML Schema. Per
queste ragioni, i codici potranno essere ripro-
Warfarin (conosciuto anche con il
grammati per implementare altri scenari diag-
nome commerciale di Coumadin) è
nostici nel sistema, quali, ad esempio, il test
un farmaco anticoagulante utilizzato
HIV oppure la pianificazione dell’intervento
nelle terapie cardiovascolari per
terapeutico ad un paziente (per esempio, il
regolare la coagulazione sanguigna
dosaggio del warfarin per regolare la coagu-
del paziente.
lazione sanguigna di un paziente).
Infine, la logica di accesso al database rende
il sistema adattabile a qualsiasi DBMS, grazie
all’introduzione delle classi DAO.
1 Un portale Web responsive consiste in un portale Web in grado di adattarsi
automaticamente e graficamente al dispositivo con il quale viene visualizzato
(personal computer con diverse risoluzioni, tablet, smartphone, smartwatch, etc.).
Questa tecnologia riduce al minimo la necessità per l’utente di ridimensionare e
scorrere i contenuti del portale stesso.
Considerazioni personali
e uno sguardo al futuro
Conclusioni
Il lavoro realizzato nella presente tesi ha portato ad un sistema per il supporto
del medico nelle diagnosi delle anemie. La motivazione che ha spinto alla
realizzazione di tale progetto nasce dal fatto che, nelle diagnosi, gli errori che
i medici di base commettono possono compromettere non solo la salute del
paziente, ma anche la carriera del medico stesso.
L’obbiettivo che si è voluto raggiungere con la presente tesi è stato quello di
proporre un sistema che offra svariati servizi ai medici, tra cui la registrazione
dei pazienti in esame e l’automatizzazione delle procedure diagnostiche.
Il sistema, prima di essere realizzato, è stato sottoposto ad un’analisi SWOT
per conoscere le sue potenzialità. Da questa analisi, si sono riscontrati parecchi punti di forza e di opportunità. Infatti, il sistema può supportare i tablet,
gli smartphone, gli smartwatch e i personal computer. Può essere esteso a
funzionalità avanzate ed è scalabile. Può essere applicato in altri contesti clinici e può essere venduto alle case farmaceutiche come gadget sanitario da
regalare ai medici.
Il sistema è stato concepito seguendo le tecniche di progettazione ed implementazione all’avanguardia nella costruzione di applicazioni mobile di tipo
enterprise. I linguaggi, le librerie e i framework utilizzati rappresentano soluzioni open source all’avanguardia che, integrate insieme, cooperano all’interno di un software, portandolo ad un alto livello tecnologico e, allo stesso
tempo, rendendolo riusabile ed estensibile. Al fine di garantire che il sistema
soddisfacesse pienamente i requisiti della realtà di interesse, la sua realizzazione è stata articolata in più fasi.
[ 62 ]
Conclusioni
Inizialmente, si è dovuto effettuare uno studio approfondito sulle caratteristiche fondamentali della realtà di interesse, al fine di produrre
un sistema funzionale e semplice da utilizzare per i medici di base. Tale procedimento è stato effettuato raccogliendo e codificando le conoscenze mediche tramite la stretta collaborazione con il Prof. Pasquale Iacopino.
Dopodiché, la progettazione ha prodotto, come risultato, un sistema
client-server in cui il client è un’app che fruisce dei servizi offerti dal server
attraverso l’invio di messaggi JSON. Tali servizi consistono in Web Service che
elaborano le richieste dell’app, i dati presenti nel database e le conoscenze
mediche archiviate in una base di conoscenza XML, necessaria per la diagnosi
dell’anemia.
A seguito della progettazione, è stato possibile implementare il sistema stesso avvalendosi di tecnologie che ne hanno facilitato la scrittura del codice.
In particolare, l’utilizzo di Cordova ha consentito di produrre un’app in tempi
minori rispetto a quanto si impiegherebbe con la programmazione nativa. Il
database di supporto è stato realizzato tramite MySQL DBMS 5.5, che è stato popolato e interrogato in maniera semplice ed intuitiva grazie all’ausilio
del tool phpMyAdmin. I Web Service sono stati implementati in PHP 5 e consistono in script e classi per l’interrogazione sul database e per la diagnosi
delle anemie. La base di conoscenza relativa a questa malattia si basa su un
documento XML che rispetta una sintassi specificata tramite un preciso XML
Schema.
Successivamente, si è potuto confrontare il nostro sistema con altri sistemi
analoghi, mettendo in luce analogie e differenze che hanno delineato le principali caratteristiche e i principali vantaggi che esso prevede.
Infine, esaminando il codice del software implementato, si è dimostrato che,
con l’introduzione dei design pattern in fase implementativa, il sistema favorisce un alto grado di riusabilità ed estensibilità del codice. Quindi, esso potrà
essere ampliato in futuro per rispondere a nuove esigenze o per sopperire ad
eventuali mancanze riscontrate.
Infatti, utilizzando i linguaggi HTML 5, CSS 3 e JavaScript, il framework
Cordova ha consentito di produrre un’app iOS, il cui codice è riusabile per
altre piattaforme. Pertanto, si potrà produrre l’app per le piattaforme mobile di Google e Microsoft (Android e Windows Phone) e per un’applicazione Web responsive indirizzata a personal computer e ai dispositivi mobili.
Considerazioni e uno sguardo al futuro
In questo modo, lo sviluppatore non sarà obbligato a scrivere del codice nativo per ogni piattaforma.
Inoltre, introducendo il pattern Template Method e una base di conoscenza XML nel sistema, il codice relativo al test dell’anemia potrà essere riusato
per implementare altri scenari diagnostici e per la pianificazione dell’intervento terapeutico. Ad esempio, si potrebbe definire un algoritmo per il test
HIV o per il dosaggio di farmaci come il warfarin.
Ulteriori funzionalità potrebbero essere rappresentate dal Data Warehousing
e Data Mining, ossia strumenti di Business Intellingence finalizzati al supporto dei manager. Queste tecnologie potranno fornire delle informazioni strategiche ai manager di aziende sanitarie nei processi decisionali aziendali.
Inoltre, si potrà prevedere nel sistema un meccanismo di aggiornamento della base di conoscenza avvalendosi delle segnalazioni dei medici di base. Questi, infatti, per ciascun loro paziente che ha utilizzato l’app (direttamente, o
tramite essi) per una diagnosi, potranno, in un secondo momento, fornire un
feedback sulla correttezza o meno della stessa. Sulla base di tale feedback, si
potrà procedere all’aggiornamento della base di conoscenza. Con un meccanismo di questo tipo, assume un ruolo centrale l’identificazione del valore di
trust e reputation di ciascun medico di base che fornisce i feedback.
Infine, si potrebbero introdurre nel sistema anche delle funzionalità di monitoraggio remoto dei pazienti. In questo contesto, l’app controllerà lo stato
di salute di un paziente tramite uno smartphone o smartwatch applicato al
soggetto stesso. In questo modo, all’insorgere di un problema di salute, il
dispositivo provvederà ad inviare una notifica al medico di base per curare
il paziente.
Viste le caratteristiche e le potenzialità del nostro sistema, il software può
essere rivolto non solo ai medici di base, ma anche ai pazienti, agli studenti, ai docenti di medicina e ai medici operanti in strutture sanitarie (aziende
ospedaliere, istituti clinici, aziende sanitarie locali, istituti previdenziali, etc.).
Pertanto, un sistema informativo come quello proposto nella tesi potrà migliorare non solo il lavoro di chi opera nella sanità e la vita dei pazienti, ma
anche il sistema sanitario italiano.
[ 63 ]
[ 64 ]
Conclusioni
E per finire,
i ringraziamenti
Ringraziamenti
Eccomi di nuovo qui, dopo tre anni, a scrivere
nuovamente i ringraziamenti. La sensazione che si prova è sempre piacevole, perché questo momento segna la fine di un percorso e l’inizio di qualcosa di nuovo e stimolante.
È difficile scrivere i ringraziamenti, perché tanti hanno contribuito a formare
la persona che oggi sono.
Il lavoro condotto per questa tesi non è completo, o meglio, sono molte le
cose che si possono affinare. Molte sono le cose che avrei potuto sviluppare,
ma si sa che prima o poi ”si chiude” per iniziare un dopo. Credo, comunque, di
essere stato all’altezza di quanto mi è stato chiesto di fare. Di certo, l’impegno
e la passione da parte mia non sono mai mancati. Il tempo già ridotto è volato
come sempre e, in ogni caso, ho dato il massimo di me stesso.
A questo punto, colgo l’occasione di ringraziare in queste pagine le persone
che mi sono state vicine nel raggiungimento di questo traguardo di studio.
Ringrazio, innanzitutto, il mio relatore della tesi, il Prof. Domenico Ursino, per
la cortesia dimostrata e per avermi dato la possibilità di mettermi in gioco e
di avermi proposto un argomento così affascinante come quello dell’informatica applicata al mondo sanitario.
Ringrazio, inoltre, il mio correlatore, il Prof. Pasquale Iacopino, per la sua professionalità, la sua immensa preparazione nel campo dell’ematologia e, soprattutto, per il suo prezioso supporto nella realizzazione della tesi.
Ringrazio, inoltre, tutto lo staff di Barbiana 2.0, laboratorio informatico di
co-working dove ho svolto la tesi con Ursino e Iacopino. In particolare, ringrazio le persone che hanno collaborato con me nel progetto di tesi: Marco
Scialò, Giuseppe Lucisano e Alfonso Martino.
Ringrazio, inoltre, un mio carissimo amico, Giuseppe Cotroneo, autore dell’icona dell’app, nonché creatore del logo presente sulla copertina della tesi.
[ 66 ]
Ringraziamenti
Ringrazio i miei genitori, per avermi incoraggiato e sostenuto nelle mie scelte, per avermi permesso di studiare e di conseguire con dignità la Laurea
Triennale e quella Magistrale. In particolare, ringrazio mia madre, che ha contribuito come medico alla stesura del primo capitolo di tesi.
Ringrazio i miei nonni e i miei parenti per i consigli di vita.
Ringrazio mia sorella Francesca, per essermi stata vicina.
Ringrazio la mia amica Lilli per il suo infinito affetto.
Ringrazio i miei colleghi ingegneri con cui ho studiato per gli esami e per le
tesine di gruppo, soprattuto coloro che mi hanno sopportato durante i tre
anni di studio.
Ringrazio Dio, che mi ha donato il talento, la pazienza e l’immensa forza per
superare le mie difficoltà di salute accadute tempo fa e per raggiungere il
nuovo traguardo di studio.
Per ultimo, ma non meno importante, ringrazio me stesso per essere riuscito
ad arrivare a questo nuovo traguardo.
Questo è tutto. :-)
Grazie infinite.
Domenico Carlo Romeo
3 dicembre 2014
Maggiori
approfondimenti
Bibliografia
Testi accademici
E. Gamma, R. Helm, R. Johnson e J. Vlissides, Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley, 1998.
P. Larizza, Manuale di Medicina Interna Volume I. Piccin Editore, 1977
F. Lenzi, A. Caniggia, Manuale di Semiotica Medica (IV Edizione).
Edizioni Minerva Medica, 1978.
B. F. Rodak, G. A. Fritsma, E. M. Keohane, Hematology - Clinical Principles and
Applications, 4th Edition. Elsevier Saunders, 2012.
M. L. Turgeon, Clinical Hematology – Theory & Procedures, 5th Edition.
Lippincott Williams & Wilkins, 2012.
[ 68 ]
Bibiliografia
Risorse sul Web (dicembre 2014)
Apache Cordova http://cordova.apache.org/
Apple http://www.apple.it/
ARUP Consult
http://www.arupconsult.com/
BicLazio
http://www.biclazio.it/
BNLhttp://www.bnl.it/
Camera di Commercio di Ascoli Picenohttp://www.ap.camcom.it/
Enciclopedia Treccani
http://www.treccani.it/
Encyclopædia Britannica
http://www.britannica.com/
HTMLhttp://www.html.it/
MDSystem
http://www.mdsystem.it/
Medici Italia
http://www.medicitalia.it/
Microsoft MSDN http://msdn.microsoft.com/
My Personal Trainer
http://www.my-personaltrainer.it/
My Virtual Medical Centre
http://www.myvmc.com/
Ospedale Bambino Gesù
http://www.ospedalebambinogesu.it/
PHPhttp://www.php.net/
Trice Designshttp://www.tricedesigns.com/
Università di Roma
http://web.uniroma2.it/
W3Schoolshttp://www.w3schools.com/
Wikipedia
http://it.wikipedia.org/
Maggiori approfondimenti
[ 69 ]