Tesi Finale Antonio Lepore PDF

UNIVERSIT DEGLI STUDI DI BARI
FACOLTA DI SCIENZE MATEMATICHE FISICHE E NATURALI

CORSO DI LAUREA IN INFORMATICA E COMUNICAZIONE DIGITALE
TESI DI LAUREA
DOSEWEBUNAPIATTAFORMAWEB
DISUPPORTOALLAGESTIONEDEGLISTUDICLINICI
StudioD.O.S.E.:DrugOutcomesSurvEy
Relatore:
Chiar.ma Prof.ssa Enrichetta Gentile
Laureando:
Lepore Antonio
ANNO ACCADEMICO 200 8 - 200 9

Sommario
Introduzione __________________________________ 4
Capitolo 1: Contesto di Riferimento _________________ 8
1.1 Il Consorzio Mario Negri Sud. Un istituto di ricerca Biomedica 8
1.1.1 Il Dipartimento di Farmacologia Clinica e Epidemiologia
(DFCE) ________________________________________ 10
1.1.2 Il Laboratorio di Epidemiologia Assistenziale e Sistemi
Informatici (LEASI) ______________________________ 12
1.2 LEpidemiologia e i diversi tipi di studio__________________ 13
1.3 La raccolta e la cultura dei dati_______________________ 16
1.3.1 Il problema clinico: lArtrite reumatoide ______________ 22
1.4 Lo Studio D.O.S.E., Uno Studio Osservazionale Di Monitoraggio
Su Nuovi Farmaci __________________________________ 27
Capitolo 2: Analisi dei Requisiti ___________________ 30
2.1 Motivazioni & Scopo_________________________________ 31
2.2 Contesto di Business ________________________________ 32
2.3 Capacit __________________________________________ 33
2.3.1 Capacit di Presentazione (Parte Pubblica) ____________ 33
2.3.2 Capacit di Accesso (Parte Privata)__________________ 34
2.3.3 Capacit di Supervisione (Parte Privata)______________ 34
2.3.4 Capacit di Raccolta (Parte Privata) _________________ 34
2.4 Premesse dei Requisiti: Stakeholder ____________________ 36
2.5 Servizi del Sistema _________________________________ 39
2.5.1 Servizi del Sistema: Contesto del Sistema: ___________ 39
2.5.2 Servizi del Sistema: Requisiti Funzionali______________ 41
2.5.3 Servizi del Sistema: Requisiti Informativi _____________ 46
2.6 Vincoli di Sistema __________________________________ 50
2.6.1 Vincoli di Sistema: Requisiti di Interfaccia ____________ 51
2.6.2 Vincoli di Sistema: Requisiti Operativi _______________ 52
2.6.3 Vincoli di Sistema: Altri Vincoli _____________________ 53
2.6.4 Vincoli di Sistema: Stabilit dei Vincoli _______________ 55
Capitolo 3: Progetto di sistema ___________________ 56
3.1 Classi stereotipate __________________________________ 56
3.1.1 Diagramma delle classi stereotipate: entit ____________ 56
3.2 Casi duso _________________________________________ 57
3.2.1 Diagramma dei casi duso __________________________ 57
3.3 Casi duso: Informazioni di base________________________ 59
3.4 Scenari ___________________________________________ 75
3.5 Diagrammi di Sequenza ______________________________ 91
3.6 Progetto Dei Dati __________________________________ 105
3.6.1 Diagramma della dipendenza dei Dati________________ 107
3.6.2 Modello del Database ____________________________ 108
2
3.6.3 Dettaglio Dei Dati _______________________________ 108
Capitolo 4: Analisi delle tecnologie impiegate _______ 124
4.1 Larchitettura J2EE (Java 2 Enterprise Edition)____________ 126
4.2 I tre strati della piattaforma J2EE: _____________________ 129
4.2.1 Struts e il Web Tier _____________________________ 132
4.2.2 Java Servlet e Java Server Pages___________________ 133
4.3 Utilizzare un framework _____________________________ 135
4.4 Design Patterns in J2EE _____________________________ 136
4.4.1 Il pattern MVC (Model-View-Controller) ______________ 138
4.4.2 Struts e il pattern MVC ___________________________ 144
4.5 Hibernate ________________________________________ 148
4.6 Ambiente di Sviluppo e Deploy ________________________ 152
Capitolo 5: Manuale dUso ______________________ 155
5.1 Interfaccia________________________________________ 155
5.2 Pulsanti __________________________________________ 156
5.3 Login e Logout ____________________________________ 158
5.4 Gestione schede: Inserimento\Visualizzazione\Stampa _____ 161
5.5 Gestione Pazienti: Ricerca\Elenco\Cancellazione\Esportazione 165
5.6 Ottenere documentazione____________________________ 167
Conclusioni e Sviluppi futuri ____________________ 168
Glossario e Acronimi __________________________ 169
Bibliografia _________________________________ 173
Allegati_____________________________________ 174
3
Introduzione
Il lavoro presentato si inserisce in un pi ampio ed esteso

progetto di sviluppo di soluzioni informatiche avanzate su
piattaforma web capaci di supportare, in modo efficace, la
gestione di progetti di ricerca in ambito sanitario e scientifico. A
tale scopo il lavoro si svolto allinterno di un team presso un
istituto di ricerca in campo biomedico quale lIstituto Mario
Negri.
In particolare la collaborazione si sviluppata in una delle
quattro sedi dellistituto: il Consorzio Mario Negri Sud di Santa
Maria Imbaro (CH) per la sua vicinanza geografica e per la
disponibilit offerta di poter frequentare il Laboratorio di
Epidemiologia Assistenziale e Sistemi Informatici allinterno del
quale stato condotto concretamente il presente lavoro.
Lambito scientifico proprio quello della ricerca
farmacologia sia per lo sviluppo di nuove terapie sia per la
valutazione di efficacia e sicurezza nellimpiego di farmaci per la
cura di molte malattie in campo oncologico, cardiovascolare,
neurologico e reumatologico come nel mostrato nel presente
lavoro di tesi.
4
E importante sottolineare alcune considerazioni utili ad
una migliore comprensione del lavoro svolto.
Sin dalla loro prima introduzione gli elaboratori e/o

calcolatori hanno sempre mirato a migliorare e potenziare le
abilit umane nella risoluzione di molteplici e concreti problemi
senza mai sostituirsi alluomo nelle sue pi specifiche capacit di
decisione e di scelta. Luso sinergico degli attuali strumenti
informatici pu e deve essere focalizzato al potenziamento delle
facolt delluomo e fornire il miglior supporto ai suoi processi
cognitivi e progettuali. Solamente in tempi relativamente recenti
lattenzione stata diretta verso questi aspetti del rapporto tra
uomo e macchina, visti oramai come ununit cooperante. Tale
visione stata stimolata in particolare dallavvento dei sistemi
multimediali, che aprono contemporaneamente delle prospettive
estremamente interessanti ad un insieme di problematiche di
non facile soluzione.
In questo senso larea sanitaria, in tutti i suoi molteplici

aspetti, si presenta come spazio privilegiato di interesse per
esplorare, approfondire, progettare e testare soluzioni
informatiche per la risoluzione di svariate problematiche:
strettamente Cliniche, per la raccolta ed immagazzinamento

dei dati anamnestici (la storia del paziente), della valutazione
obiettiva (la visita medica), dei molteplici ed innumerevoli dati
di laboratorio e strumentali (esame del sangue, radiografie
ecc), delle diverse terapie praticate e dei corrispondenti
risultati ottenuti;
5
realizzazione di Archivi capaci di mantenere accessibili e
costantemente aggiornabili popolazioni anche numerose di
pazienti, spesso seguiti per lunghi periodi di tempo;
possibilit, oggi sempre pi richiesta, di realizzazione di vere

e proprie Banche di Dati in cui far confluire, secondo criteri e
logiche altamente strutturate, archivi elettronici e flussi
ordinati di dati provenienti, ad esempio, da differenti medici o
ospedali o centri specialistici ovunque localizzati;
infinite opportunit di arricchire tali Banche di Dati collegando

ed integrando tra di loro fonti informative di differente
provenienza (ad es. il medico di famiglia, lospedale, la
farmacia, il comune, gli uffici amministrativi della ASL, ecc..)
con sistemi di supporto ai processi decisionali.
Se lintroduzione di sistemi informativi sanitari innovativi

rappresenta una grande opportunit non bisogna per mai
dimenticare la relativa rigidit e complessit di un sistema come
quello sanitario. Ed proprio per questo motivo che lesperienza
qui presentata ha dovuto necessariamente collocarsi, per la sua
concreta realizzazione e sviluppo, allinterno di un istituto e di un
progetto di ricerca. Lambiente stimolante ed innovativo di un
centro di eccellenza in ambito biomedico e farmacologico ha
fornito le condizioni necessarie per linserimento in un gruppo di
lavoro gi consolidato e con elevate competenze nel settore
consentendo non solo la realizzazione del lavoro presentato ma
anche e soprattutto una preziosa esperienza formativa di alto
livello.
6
In sintesi il presente lavoro di tesi intende illustrare le
soluzioni informatiche elaborate presso i Laboratori dellIstituto
Consorzio Mario Negri Sud nella messa a punto di una
piattaforma web di supporto alla gestione di uno studio
osservazionale sui trattamenti con farmaci biologici nei pazienti
con artrite reumatoide. La tesi organizzata in cinque capitoli
in cui vengono discussi i vari aspetti del lavoro svolto.
Nel primo capitolo viene descritto il contesto scientifico e
sanitario in cui si elaborata la piattaforma web sviluppata.
Nel secondo capitolo vengono analizzati i requisiti che
una piattaforma web deve possedere ai fini di poter fornire il
supporto necessario alla gestione di uno studio del tipo di quello
proposto.
Nel terzo capitolo viene presentato il progetto del sistema
con le sue varie caratteristiche.
Nel quarto capitolo vengono analizzate e motivate le
scelte riguardo le tecnologie impiegate.
Nel quinto capitolo, infine, presentato il manuale duso
per lutente.
Le conclusioni riassumono brevemente i risultati che
lanalisi approfondita del sistema ha consentito di trarre e illustra
alcuni dei possibili sviluppi futuri.
7
Capitolo 1: Contesto di Riferimento
1.1 Il C onsorzio M ario N egri S ud. Un istituto di

ricerca Biomedica
Figura 1: Consorzio Mario Negri Sud, S. Maria Imbaro (CH)
Costituitosi il 5 dicembre 1980, il Consorzio Mario Negri

Sud comprende lIstituto Mario Negri di Milano, l'Amministrazione
Provinciale di Chieti e, dal 2002, la Regione Abruzzo.
Il Negri Sud, nato per rispondere all'esigenza di formazione
e qualificazione di ricercatori del Sud, oggi un centro di ricerca
d'eccellenza e rappresenta in Abruzzo una prestigiosa realt
scientifica nei campi biotecnologico, socio-sanitario, chimico-
analitico e nel controllo e nella tutela dellambiente.
Principali settori di ricerca:

biologia cellulare e molecolare, con particolare riguardo ai
processi di cancerogenesi, di produzione ed azione dei
secondi messaggeri e del traffico intracellulare di
membrane;
8
oncologia molecolare e clinica;
coordinamento di studi clinici controllati sul diabete, infarto
miocardico, tumore della mammella, e malattie
mieloproliferative;
malattie cardiovascolari;
epidemiologia assistenziale e farmacoepidemiologia;
ricerca clinica ed epidemiologica e formazione in medicina
generale, sistemi informativi e politiche sanitarie, rapporti
tra salute ed ambiente;
metodologie analitiche per il monitoraggio ambientale e
agroalimentare.
9
1.1.1 Il Dipartimento di Farmacologia Clinica e
Epidemiologia (DFCE)
Il DFCE opera allinterno del Negri Sud con la finalit di:
produrre, diffondere e trasferire conoscenze scientifiche in

tema di prevenzione, cura e gestione delle malattie;
organizzazione ed erogazione dell'assistenza sanitaria;
promozione e tutela della salute come diritto
fondamentale.
Le metodologie utilizzate, e/o oggetto di ricerca e sviluppo,

sono integrate nei singoli progetti secondo una logica
multidisciplinare, ed includono:
sperimentazioni cliniche controllate;

epidemiologia clinica e valutativa;
epidemiologia generale, descrittiva ed analitica;
ricerca sui servizi sanitari;
outcome research;
farmacoepidemiologia e farmacoeconomia;
economia sanitaria e sociale;
tecniche statistiche multivariate;
sviluppo di software per sistemi informativi avanzati.
Altre attivit dipartimentali integrate con la ricerca

riguardano la formazione del personale sanitario, l'informazione
e la comunicazione al pubblico, la consulenza tecnico-scientifica
10
aziendale ed il trasferimento tecnologico per lo sviluppo dei
sistemi socio-sanitari regionali.
La strategia comune ai progetti specifici del DFCE consiste
nel coinvolgere, metodologicamente e culturalmente, gli
operatori e i dirigenti del servizio sanitario (medici - ospedalieri,
specialisti, di medicina generale, di sanit pubblica e direzione
aziendale - farmacisti, infermieri, amministrativi, pianificatori e
operatori socio-assistenziali) secondo una logica di
collaborazione in rete tra persone ed istituzioni, partecipazione
attiva e condivisione di obiettivi, progetti e risultati.
11
1.1.2 Il Laboratorio di Epidemiologia Assi stenziale e
Sistemi Informatici (LEASI)
Il LEASI opera all'interno del Dipartimento di Farmacologia

Clinica ed Epidemiologia con lo scopo di contribuire alla ricerca
sanitaria adattando e sviluppando metodi, strategie di analisi ed
uso di tecnologie informatiche finalizzate alla realizzazione di
studi sanitari basati sulla popolazione.
L'attivit di ricerca svolta dal Laboratorio si pu ricondurre
ad alcuni punti principali:
analisi comparativa delle strutture sanitarie
analisi dei sistemi sanitari regionali
analisi dei profili e della qualit della cura
valutazione dei fattori di rischio
Il Laboratorio si propone quindi di avviare un lavoro
direttamente pensato nei termini di servizio alle istituzioni, in
quanto teso a superare i classici limiti della ricerca astratta e
ad offrire il necessario supporto in aree strategiche per il
supporto alle decisioni in campo sanitario. Il fine ultimo quello
di fornire risultati importanti per armonizzare gli sforzi degli
operatori sanitari su un approccio centrato al paziente, il pi
possibile trasparente ed appropriato. L'affermarsi della cultura
del dato, cio il confronto critico tra analisi su dati reali e
principi statistici obiettivi, rappresenta un punto caratterizzante
l'attivit del Laboratorio.
12
1.2 LEpi demiologia e i diversi tipi di studio
L'epidemiologia (dal Greco =sul, =popolo e

=discorso, studio) la disciplina biomedica che si occupa
dello studio della distribuzione e frequenza di malattie e di eventi
di rilevanza sanitaria nella popolazione. Collabora con la
medicina preventiva e clinica. Si occupa di analizzare le cause, il
decorso e le conseguenze delle malattie.
Scopi dell'epidemiologia:
determinare l'origine di una malattia la cui causa

conosciuta;
studiare e controllare una malattia la cui causa
sconosciuta o poco nota;
acquisire informazioni sull'ecologia e sulla storia naturale
della malattia;
programmare ed attivare piani di controllo e di
monitoraggio della malattia;
valutare gli effetti economici di una malattia ed analizzare i
costi e benefici economici.
L'epidemiologia si serve della statistica, basata a sua volta

sulla matematica e sulla demografia.
Per schematizzare, la sua articolazione tradizionale in tre
settori (anche se sono comuni i casi di interazione tra settori):
Epidemiologia descrittiva
Epidemiologia analitica
Epidemiologia sperimentale
13
Epidemiologia descrittiva:
Descrive eventi sanitari come malattie, cause di morte e la
presenza di fattori di rischio come ad esempio il fumo di tabacco.
questa la branca che utilizza gli strumenti statistici detti misure
di frequenza (come i tassi di incidenza o di prevalenza, rapporti)
e informazioni di tipo demografico.
Epidemiologia analitica:
Indaga e cerca relazioni causa-effetto tra fattori di rischio e
malattie. Riprendendo l'esempio precedente, l'epidemiologia
analitica cerca il nesso tra il fattore di rischio "fumo di sigaretta"
e l'eventuale insorgenza di patologie legata ad esso (come
cancro al polmone, enfisema, etc.). Si pone, quindi, come
obiettivo quello di rispondere a domande come: "chi si
ammalato?", "fa parte di una qualche categoria a rischio?",
"dove?", "quando?", "perch?".
Epidemiologia sperimentale
Valuta l'efficacia degli interventi sanitari adottati in seguito
a indagini epidemiologiche. Studi di epidemiologia sperimentale
possono essere sia di tipo preventivo (ad esempio la valutazione
dell'effettiva riuscita di campagne di sensibilizzazione) che
terapeutico (ad esempio sperimentazioni sui farmaci e tecniche
operatorie). Gli studi in epidemiologia sperimentale si possono
effettuare a singolo cieco, a doppio cieco o a triplo cieco. A
seconda che:
1) solo i volontari non hanno coscienza di essere parte del
gruppo dei controlli o degli sperimentali;
14
2) anche il ricercatore non sa chi appartenga ad un gruppo
e chi ad un altro (lo sa solo il supervisore);
3) ci si affidi ad un ricercatore esterno.
Nel caso qui presentato, e tecnicamente definito come

studio osservazionale prospettico, lapproccio tipicamente
descrittivo ed orientato a raccogliere, in modo sistematico, tutte
le informazioni (dati) rilevanti per il problema esaminato per un
numero sufficientemente ampio di pazienti e per un tempo
sufficientemente lungo di osservazione.
15
1. 3.1 La raccolta e la cultura dei dati
E forse questo laspetto pi rilevante ai fini del presente

lavoro specificatamente orientato ad implementare in contesti
sanitari di normale assistenza tutte le soluzioni informatiche per
favorire, facilitare, promuovere, garantire una raccolta di dati
utili, necessari e di buona qualit.
Cominciamo col dire metaforicamente che la materia prima
(malta, cemento e mattoni) di ogni edificio epidemiologico
costituita dai dati.
Che cosa sono i dati?
I dati sono numeri o valori o attributi inseriti in un

particolare contesto (come ad esempio s o no, malato o sano
ecc.), che portano con s una dose di informazione. I dati
rappresentano il raccolto di ogni studio epidemiologico, ed
anche il mezzo per giungere a conclusioni scientificamente valide
ed osservazioni documentate.
Comunemente, quando si effettuano indagini
epidemiologiche "di routine" nella pratica clinica e su argomenti
gi ampiamente noti, alcuni dei passi del classico metodo
scientifico vengono omessi, e lo schema dell'indagine pu essere
riassunto in sole 3 fasi:
raccolta dei dati
elaborazione dei dati
interpretazione dei dati (conclusioni)
16
I dati sono numeri in un contesto.
Ad esempio, il numero "3.8" o il valore "3.8 kg" in s non

portano alcuna informazione. Ma se veniamo a sapere che una
conoscente ha dato alla luce un bambino del peso di 3.8 kg,
allora questo numero assume significato in uno specifico
contesto e, ad esempio, possiamo congratularci per il buon peso
del bambino, indice di presumibile buona salute.
Il contesto implica il possesso di conoscenze sull'argomento,
le quali ci consentono di formulare giudizi. Ad esempio,
sappiamo che un bambino alla nascita non pu pesare 450
grammi, n 45 kg. Il contesto fa s che il numero contenga
informazione.
I dati nella pratica
La struttura logica ora descritta (cio i processi di raccolta-

elaborazione-interpretazione dei dati) non peculiare
dell'epidemiologia, ma comune a tutti i settori della professione
sanitaria. Per esempio, nel procedimento diagnostico di fronte ad
un ammalato, il medico raccoglie dati (anamnesi, visita medica
con evidenziazione dei sintomi, esami di laboratorio ecc.); questi
dati vengono elaborati (spesso quasi inconsciamente) nella
mente del medico che infine, interpretandoli anche in base al suo
buon senso clinico, arriver alla diagnosi.
Durante la visita clinica, alcuni dei dati raccolti non sono
facilmente ed immediatamente esprimibili in forma numerica.
Ad esempio, molto difficile misurare e rappresentare con
precisione attraverso un numero fenomeni come il dolore di una
17
articolazione infiammata. In altri casi, invece, i dati sono
esprimibili in forma numerica; ad esempio, il numero di
pulsazioni cardiache al minuto.
Quasi sempre, le osservazioni non quantificabili
numericamente possono essere trasformate in un numero in
base a criteri pi o meno arbitrari. Ad esempio, come nel
problema qui esaminato, stato necessario utilizzare scale
analogico digitali per quantificare la percezione soggettiva del
dolore in un paziente con artrite reumatoide codificando
lintensit del dolore con i valori 0, 1, 2, 3, 4, ecc.. dove 0
corrisponde allassenza del dolore, 1 a dolore appena
percettibile, 2 a dolore lieve ecc. Questo tipo di trasformazione
molto utile quando i dati devono essere sottoposti ad una
elaborazione.
In epidemiologia i dati sono sempre rappresentati da
numeri.
Ad esempio, uno studio epidemiologico potrebbe mirare a
stabilire QUANTI soggetti sono affetti da una malattia in un
determinato momento, oppure QUANTI nuovi casi si sono
verificati in un lasso di tempo, oppure QUANTI soggetti esposti
ad un certo fattore vengono colpiti dalla malattia, ecc.
Ecco perch l'epidemiologia, servendosi di dati numerici,
ricorre pi di altre discipline a tabelle o grafici in cui riportare i
dati numerici. Per lo stesso motivo, l'epidemiologia si serve
frequentemente di due altre discipline: la matematica e,
soprattutto, la statistica. Quest'ultima comprende i metodi di
studio dei fenomeni collettivi e quindi rappresenta logicamente
la compagna ideale dell'epidemiologia (e di altre discipline).
18
La statistica come l'interfaccia tra la matematica e la
scienza medica.
Attraverso procedimenti statistici di "analisi", i dati possono

essere convertiti dalla forma grezza iniziale (poco o nulla
interpretabile) ad una forma pi comprensibile. Il fatto che per
tutte le discipline scientifiche che studiano gli organismi viventi, i
dati ottenuti attraverso gli esperimenti oppure raccolti in
campo (ossia in natura) non consentono mai di giungere ad una
conclusione con una certezza del 100%.
La statistica ci aiuta in maniera oggettiva, numericamente,
ad analizzare le diverse ipotesi: lo studio e l'interpretazione dei
fenomeni biologici dipende quindi strettamente dal metodo
statistico.
Inoltre, attraverso i metodi statistici, le osservazioni
effettuate su un campione possono essere generalizzate all'intera
popolazione, attraverso un processo logico detto di inferenza
(statistica inferenziale). D'altra parte , gi da secoli,
ampiamente noto che l'analisi dei dati parte inscindibile del
processo di ampliamento delle conoscenze umane:
Non si deve per pensare che il processo di raccolta-
elaborazione-interpretazione dei dati sia puramente meccanico o
possa essere in qualche modo automatizzato in tutte le sue fasi.
Infatti, sia nella raccolta che nell'elaborazione che - soprattutto -
nell'interpretazione dei dati necessario ingegno, acume e
discernimento, associati ad una profonda conoscenza della storia
naturale della malattia (cio come essa si manifesta e decorre in
natura, senza intervento del medico) nonch di tutte le altre
19
discipline mediche di base (anatomia, fisiologia, patologia
generale ecc.).
Gli obiettivi pratici dell'epidemiologia clinica ed

assistenziale
Le informazioni sullo stato sanitario di popolazioni e/o

soggetti affetti da particolari condizioni di interesse sono utili ad
una ampia gamma di persone, a partire dai diretti interessati (i
pazienti), fino alle Autorit sanitarie periferiche e centrali
(nazionali ed internazionali) ed ai centri di ricerca.
In particolare le informazioni raccolte sono utili a:

identificare la causa e l'origine delle malattie;
identificare la presenza di determinate malattie in un
territorio;
accertare l'assenza di determinate malattie (aspetto molto
richiesto dai partner commerciali che non intendono
correre il rischio di importare nuove malattie in territori
indenni e di particolare importanza per le malattie
trasmissibili;
individuare la frequenza, o la localizzazione geografica, o
l'andamento nel tempo delle malattie;
valutare l'importanza (sanitaria, economica, ecc.) delle
malattie esistenti in un territorio;
determinare le priorit di intervento, tenuto conto delle
risorse disponibili;
determinare evalutare lefficacia, lefficienza e il rapporto
rischi/benefici della diverse terapia;
20
pianificare ed implementare piani di controllo e
sorvegliarne l'andamento;
soddisfare le richieste di informazioni provenienti da
organismi nazionali e internazionali.
21
1.3.2 Il problema clinico: l Artrite reumatoide
L'artrite reumatoide una poliartrite infiammatoria cronica

e progressiva a carico delle articolazioni sinoviali a patogenesi
autoimmunitaria. Si differenzia dall'osteoartrosi perch interessa
le articolazioni sinoviali e non la cartilagine e colpisce con meno
frequenza e in et pi giovane rispetto all'osteoartrosi. Sono pi
colpite le donne (rapporto 3:1). Interessa l'1-2% della
popolazione, il numero dei casi aumenta con l'et, infatti
colpito il 5% delle donne oltre i 55 anni. L'esordio si osserva al
termine della adolescenza o tra la 4^ e la 5^ decade di vita, un
secondo picco si osserva tra i 60 e 70 anni.
Non si conosce la causa certa, ma sicuramente c'
un'influenza genetica.
I sintomi:
1. Dolore
2. Tumefazione calda ma non arrossata
3. impotenza funzionale delle articolazioni
L'infiammazione pu colpire anche i tendini e allora si

avranno manifestazioni cliniche diverse:
"dito a collo di cigno" con iperestensione della seconda
falange e flessione della terza;
"dito a bottone in occhiello" con flessione della seconda
falange e iperestensione della terza;
22
La terapia e i farmaci biologici per lArtrite reumatoide
Nonostante non sia ancora nota la causa scatenante

lArtrite Reumatoide (AR), nel corso degli anni 90 stato
definitivamente dimostrato che linfiammazione cronica
determinata ed alimentata dalla rottura dellequilibrio fisiologico
tra proteine pro-infiammatorie (che alimentano linfiammazione)
e anti-infiammatorie (che inibiscono linfiammazione).
Linfiammazione rappresenta infatti un importante
meccanismo di difesa dellorganismo, ma necessario che essa
venga limitata nel tempo, una volta superata laggressione
ambientale, per non danneggiare il medesimo organismo.
Nella maggior parte dei malati il decorso della artrite
conduce ad alterazioni invalidanti delle articolazioni con
notevole riduzione della qualit della vita.
Infine dimostrato che lArtrite Reumatoide provoca
enormi costi alla societ per le cure (ricoveri, visite, farmaci,
contributi di invalidit) e per la perdita di giornate lavorative e
precoci abbandoni del posto di lavoro. A questi vanno sommati i
costi che i malati e le loro famiglie devono sostenere per
laiuto a loro necessario. I costi aumentano con laumentare della
disabilit che, in genere, interviene nelle fasi pi evolute della
malattia.
E stato per osservato che possibile cambiare il decorso
della malattia e prevenire, o quantomeno ritardare, levoluzione
verso linvalidit. La opportunit di bloccare questa malattia
distruttiva dipendente dalla diagnosi precoce e dalla
impostazione di una corretta terapia con farmaci anti-
reumatici fin dalle prime fasi della AR.
23
Affinch ci sia realizzabile devono essere coinvolti i Medici
di Medicina Generale e gli Specialisti alla condivisione di un
definito percorso diagnostico-terapeutico.
All'esordio dell'artrite il malato lamenta dolore e
tumefazione articolare. Per questo motivo, nella maggior parte
dei casi, si rivolge al proprio Medico di Medicina Generale che
ha l'importante compito di sospettare la malattia e di inviare
tempestivamente il malato allo specialista. Entrambi i medici, a
disposizione del malato, avranno cura di sorvegliare l'evoluzione
della malattia e i potenziali effetti tossici dei farmaci,
collaborando in stretta integrazione, nel rispetto dei reciproci
ruoli.
Farmaci vecchi e nuovi per una strategia terapeutica

vincente
I farmaci anti-reumatici (elencati nella tabella seguente)
fino ad oggi impiegati per la cura dellArtrite Reumatoide
possono, se impiegati precocemente, entro sei mesi dallesordio
dei sintomi, modificare il decorso della malattia ed efficacemente
contrastare levoluzione verso linvalidit.
Sono questi i farmaci su cui si basa lintervento terapeutico
precoce e, nonostante lavvento dei nuovi farmaci biologici,
mantengono immutata la loro preminente posizione nelle
strategie terapeutiche anti-reumatiche.
24
Tabella 1: Farmaci AR
Nel caso di mancata o incompleta risposta alla terapia con

farmaci anti-reumatici tradizionali, anche assunti in associazione
tra loro, possibile impiegare i farmaci biologici, soprattutto
nei casi in cui prevedibile una evoluzione sfavorevole. Questi
farmaci rappresentano la grande novit terapeutica degli ultimi 9
anni e derivano dalla sintesi in laboratorio (e produzione su vasta
scala) di anticorpi e recettori in grado di mimare la normale
funzione delle proteine naturali anti-infiammatorie e, per questo
motivo, sono stati definiti farmaci biologici.
Il vero problema: il costo della terapia con farmaci

biologici
Un problema a parte rappresentato dai costi elevati di
queste terapie che ha imposto, al momento del loro ingresso nel
prontuario terapeutico, la creazione di un apposito Registro
Osservazionale del Ministero della Salute in collaborazione con la
Societ Italiana di Reumatologia (Studio ANTARES). Questo
studio finalizzato alla valutazione dei costi, della sicurezza di
impiego e, in definitiva, alla individuazione del malato candidato
ideale a queste terapie.
25
Per questo motivo sono stati individuati Centri di
Riferimento in ogni Regione per la gestione di questi malati e
la trasmissione dei dati al Ministero.
E intuibile che questi potenti farmaci dovrebbero essere
impiegati, oltre che nei malati con AR evoluta, attiva e resistente
alle terapie convenzionali, nelle prime fasi della malattia al fine di
evitare levoluzione verso linvalidit e determinare quindi un
risparmio futuro di risorse economiche.
26
1.4 Lo Studio D.O.S.E., Uno Studio Osservazionale
Di Monitoraggio Su Nuovi Farmaci
Drug Outcome Survey for Biological treatments in

Rheumatoid Arthritis: an observational study (D.O.S.E
study) - Studio osservazionale sui trattamenti con farmaci
biologici nei pazienti con artrite reumatoide;
E stato scelto per illustrare alcune delle originali soluzioni
informatiche realizzate presso i Laboratori dellistituto Consorzio
Mario Negri Sud per garantire ai differenti Centri partecipanti,
distribuiti sul territorio nazionale, la trasmissione immediata via
web delle informazioni cliniche raccolta attraverso schede
strutturate contenente tutti i dati ritenuti necessari agli obiettivi
della ricerca.
Tale studio si propone come obiettivo primario di
descrivere e stabilire come ad oggi gli agenti anti-TNF (anti-
Tumor Necrosis Factors, noti anche come farmaci biologici), sono
gestiti quotidianamente nel trattamento dei pazienti con Artrite
Reumatoide, definendo il profilo clinico dei soggetti, lo schema
prescrittivo e l'algoritmo terapeutico, secondo un metodo
epidemiologico di sorveglianza.
Lindagine osservazionale si svolger in circa 28 centri
italiani e coinvolger 500 pazienti. Per tutti i pazienti, lindagine
avr una durata di 12 mesi a partire dal momento
dellarruolamento.
27
Figura 2: Stato attuale dei centri aderenti allo studio
Tale indagine non prevede luso di alcun farmaco

sperimentale, n di esami aggiuntivi oltre quelli eseguiti dalla
normale pratica medica. Durante lo studio e in accordo alla
routine del centro di reumatologia, saranno somministrati dei
questionari sulla qualit della vita.
Lo studio molto semplice e mira a raccogliere alcune
informazioni sullo stato di salute dei pazienti partecipanti e sui
trattamenti che essi ricevono per il controllo dellartrite
reumatoide.
La partecipazione a tale studio, di tipo esclusivamente
osservazionale, non cambier in alcun modo il livello di
assistenza che normalmente viene fornito e i farmaci utilizzati
saranno quelli che normalmente verrebbero prescritti per la cura
della malattia.
La partecipazione alla ricerca completamente volontaria e
non in alcun modo vincolante: tutti i soggetti invitati possono
28
decidere di non partecipare o di ritirasi dallo studio in qualsiasi
momento, senza che la qualit e le modalit dellassistenza
offerta siano influenzate in alcun modo.
Lo studio avr la durata di un anno e per valutare nel
tempo il decorso della malattia sono previste quattro visite di
controllo: a tre, sei, nove e dodici mesi a partire dal giorno di
inizio dellosservazione (visite Follow-Up) .
Per acquisire il parere, da parte del paziente, sulla cura
prescritta sar richiesto, al paziente stesso, di rispondere ad
alcune domande riportate su due questionari, che permetteranno
di ottenere informazioni importanti sulla malattia e sullo stato di
salute complessivo del soggetto partecipante.
Tutte le informazioni raccolte, insieme a quelle degli altri
pazienti che accetteranno di partecipare, saranno inserite in una
banca dati comune e saranno sottoposte ad una serie di
elaborazioni a scopo scientifico.
Tutte le informazioni raccolte saranno trattate con modalit
idonee a garantire l'assoluta riservatezza, confidenzialit e
sicurezza in conformit a quanto previsto dalle norme per la
tutela dei dati personali e del diritto alla riservatezza (D. Lgs.
196/03). Ciascun soggetto sar identificato mediante un codice
che impedir qualsiasi specifica identificazione.
29
Capitolo 2: Analisi dei Requisiti
2.1 Motivazioni & Scopo
Lo sviluppo costante e crescente di nuovi farmaci impone

alla comunit scientifica ed alle autorit ed istituzioni regolatorie
un costante ed attento monitoraggio e sorveglianza anche
quando, superata la fase sperimentale, nuovi principi attivi
vengono immessi in commercio e routinariamente utilizzati nella
pratica clinica quotidiana.
Questo contesto ha portato ad una pressante necessit di
raccogliere informazioni relative allintroduzione e allutilizzo dei
farmaci nei normali processi di cura con modalit tali da
garantire:
la massima tempestivit;
la pi ampia diffusione;
la maggiore standardizzazione;
la pi efficace automatizzazione del sistema;
la massima collaborazione ed interdisciplinarit,
coinvolgendo non solo i medici, ma anche farmacisti,
operatori sanitari e, aspetto oggi molto rilevante, i
pazienti stessi e/o i familiari;
al fine di raccogliere le informazioni su un numero esteso di
pazienti per migliorare le conoscenze disponibili per la cura
dellartrite reumatoide e valutare leffettivo valore dei trattamenti
farmacologici impiegati acquisendo come informazione anche il
punto di vista dei pazienti (la loro percezione del dolore o della
30
funzionalit, la soddisfazione, ecc.), accanto a quello del medico
curante.
Su questi presupposti si colloca il sistema DOSE WEB:

una piattaforma web che supporta lutente nei processi
automatizzati di inserimento, gestione e visualizzazione dei dati
richiesti dallo studio.
La dislocazione a livello nazionale dei centri attivi ha reso
necessario lo sviluppo di un sistema real-time di raccolta
distribuita ma con memorizzazione centralizzata dei dati
nellunico sito del Mario Negri Sud. Questa caratteristica soddisfa
gli obiettivi richiesti di massima tempestivit e ampia diffusione.
La standardizzazione dei dati garantita dai vincoli e
check previsti nella fase di inserimento dei dati evitando i
comuni errori o omissioni.
Le tre tipologie di utenti, inoltre, sono state previste per
permettere laccesso al sistema web con differenti livelli di
privilegi garantendo massima collaborazione ed
interdisciplinariet tra medici e farmacisti, referente del progetto
e soggetto sponsor.
31
2.2 Contesto di B usiness
Il sistema DOSE web si inserisce in un contesto di ricerca

farmacologica a livello nazionale.
Le informazioni raccolte saranno inserite in una banca dati
comune e saranno sottoposte ad una serie di elaborazioni a
scopo scientifico.
Il prodotto della collaborazione tra la casa farmaceutica
(soggetto sponsor), il consorzio Mario Negri Sud e i centri attivi
nello studio verr condiviso tra tutti i membri della comunit
scientifica internazionale interessati alloggetto dello studio
32
2.3 Capacit
Le capacit del sistema web sono state suddivise in due

categorie principali:
1. Pubblica: presentazione dello studio osservazionale e
del gruppo di ricerca
2. Privata:
2.1. Supervisione in itinere dellandamento dello studio
2.2. Accesso alla parte privata del sistema
2.3. Raccolta dei dati clinici
2.3.1 Capacit di Presentazione (Parte Pubblica)
Accesso alla pagina iniziale (HOME): viene mostrato un

testo introduttivo che riassume le motivazioni dello studio
osservazionale.
Accesso al protocollo: viene mostrato un testo che
illustra come viene effettuato lo studio, evidenziando gli
obbiettivi e gli aspetti pratici, logistici e temporali.
Accesso al diagramma di studio: viene mostrato uno
schema contenente il diagramma di flusso dello Studio Dose in
cui viene elencata la sequenza delle operazioni di raccolta dei
dati in relazione ai tempi di osservazione dei pazienti inclusi nello
studio.
Accesso al gruppo di ricerca: viene mostrato un elenco
dei componenti della Segreteria scientifico organizzativa e dei
membri del Comitato Scientifico.
33
Accesso ai contatti: vengono mostrati i recapiti telefonici,
di posta elettronica e logistici del Data Manager, della segreteria
e del supporto informatico.
2.3.2 Capacit di Accesso (Parte Privata)
Accesso alla parte privata: viene mostrata una coppia di

campi testo (Username\Password) che permette di riconoscere
lutente che vuole interagire con il sistema.
Richiesta di reinvio password: lutente ha la possibilit
di richiedere nuovamente la password eventualmente smarrita
dal centro di coordinamento dello studio.
2.3.3 Capacit di Supervisione (Parte Privata)
Lista centri: viene mostrato un elenco di tutti i Centri di

Cura, il totale complessivo dei pazienti inseriti in tutti i centri e il
totale complessivo per ogni centro.
Elenco pazienti: viene mostrato un elenco di tutti i
pazienti in ordine di inserimento e lo storico di tutte le visite.
Esporta elenco pazienti: viene generato un file standard
contenente lelenco dei pazienti e dei relativi dati clinici.
Stampa elenco pazienti: viene mostrato lelenco pazienti
formattato per la stampa su foglio A4.
2.3.4 Capacit di Raccolta (Parte Privata)
Inserimento nuovo paziente: viene mostrata la scheda

di accettazione che coincide con la visita di inizio studio.
Inserimento nuova scheda: viene mostrata la prossima
scheda da inserire per il paziente selezionato.
34
Elimina paziente esistente: viene mostrato un
messaggio di avvertimento che richiede la conferma
delleliminazione del paziente.
Ricerca pazienti: vengono mostrati alcuni campi di
ricerca che permettono la ricerca di uno specifico paziente per
Data di Nascita, Codice e Sesso.
Prelevare materiale: viene mostrato un elenco di
documenti informativi relativi allo studio prelevabili in formato
testo digitale.
35
2.4 Premesse d ei Requisiti: Stakeholder
I soggetti interessati e coinvolti allinterno del progetto dose web

sono stati descritti nei seguenti cinque modelli:
Referente del progetto: Medico Specialista che funge da

tramite tra lUtente Medico, lEnte Coordinatore e il Soggetto
Sponsor. Ha il ruolo di esperto di dominio e di supervisore del
team di sviluppo. Concorda, insieme al Soggetto Sponsor i
requisiti del processo di sviluppo, i vincoli di costo del progetto,
la quantit di risorse tecnologiche e umane da dedicare al
progetto.
Il Referente presenter lartefatto software finale allEnte
Coordinatore e i risultati dello Studio al Soggetto Sponsor.
Il Referente pu:
Accedere alla parte pubblica del sistema (Home, Protocollo,
Gruppo, Contatti, Diagramma)
Accedere alla parte privata in modalit supervisore (Lista
Centri, Elenco Pazienti, Esporta, Stampa, Ricerca, Preleva)
Soggetto sponsor: casa farmaceutica che ha permesso la

realizzazione del progetto Dose Web fornendo i finanziamenti
necessari per acquisire le tecnologie e le risorse umane
necessarie. Nello studio DOSE il soggetto sponsor
rappresentato dalla Wyeth Lederle S.p.A (wyeth.it)
Il soggetto sponsor pu:

36
Accedere alla parte privata in modalit supervisore limitato
(Lista Centri, Elenco Pazienti)
Utente del Centro attivo: Personale medico composto da

Farmacisti Ospedalieri e Medici Reumatologi. Rappresenta
lutente attivo del sistema che si occupa di popolare la banca dati
inserendo le informazioni richieste dai CRF (Case Report Form,
scheda raccolta dati).
Lutente del centro attivo pu:

Accedere alla parte privata in modalit inserimento (Elenco
Pazienti, Esporta, Stampa, Ricerca, Preleva, Inserimento
Nuovo, Inserimento Scheda, Elimina Pazienti)
Amministratore del portale: Un membro del team di

sviluppo ha il compito di supervisionare gli accessi al sistema, di
verificare la bont dei dati immessi e di fornire un supporto
tecnico agli utenti che eventualmente ne faranno richiesta.
L Amministratore del portale pu:

Accedere alla parte privata in modalit completa (Lista
Centri, Elenco Pazienti, Esporta, Stampa, Ricerca, Preleva,
Inserimento Nuovo, Inserimento Scheda, Elimina Pazienti)
37
Sviluppatori: il team di sviluppo dopo aver redatto i
documenti di Analisi e Progettazione sar impiegato nella codifica
del sistema Dose Web.
Sono anche responsabili di scegliere gli strumenti piu
adatti (IDE, framework, Database ecc), dellintegrazione di
nuove componenti e della manutenzione evolutiva.
Gli sviluppatori possono:

Accedere alla parte privata in modalit completa (Lista
Centri, Elenco Pazienti, Esporta, Stampa, Ricerca, Preleva,
Inserimento Nuovo, Inserimento Scheda, Elimina Pazienti)
38
2.5 Servizi del S istema
I servizi di sistema definiscono cosa deve garantire Dose WEB.
Si classificano in:
Contesto del sistema (Diagramma di contesto)
o Requisiti funzionali: sono elenchi di servizi che il
sistema deve fornire, indicano come dovrebbe
reagire a particolari input e come dovrebbe
comportarsi in particolari reazioni. In alcuni casi
posso affermare esplicitamente cosa il sistema non
dovrebbe fare (processi di business).
o Requisiti informativi: sono requisiti che derivano
dal dominio di applicazione del sistema, ne riflettono
le caratteristiche e i limiti. (informazioni di business).
2.5.1 Servizi del Sistema: Contesto del Sistema:
Identifica lo scope del sistema

Entit esterne: Altri sistemi, organizzazioni, persone,
macchine, etc.
Flusso di servizi dal sistema verso le entit esterne:
informazioni in uscita.
Flusso di servizi dalle entit esterne verso il sistema:
informazioni in ingresso.
39
Figura 3: Diagramma di contesto del sistema
40
2.5.2 Servizi del Sistema: Requisiti Funzional i
Nella tabella sono elencati tutti i requisiti funzionali (RF#)

che identificano i processi di business per i quali il sistema
stato concepito.
RF# REQUISITO FUNZIONALE
RF1 Il Sistema permette la visualizzazione senza credenziali delle

pagine:
Home
Protocollo
Diagramma di Studio
Gruppo di Ricerca
Contatti
RF2 LUtente del Centro Attivo inserisce le sue credenziali nel
Sistema per visualizzare:
ELENCO PAZIENTI
TOT PAZIENTI per il suo Centro
RF3 Il Referente del Progetto inserisce le sue credenziali nel
Sistema per visualizzare:
LISTA DEI CENTRI insieme al TOT PAZIENTI
Complessivo
TOT PAZIENTI per ogni Centro nello stessa vista
RF4 Il Referente del Progetto pu visualizzare ELENCO PAZIENTI
per ogni Centro.
RF5 Il Referente del Progetto pu visualizzare Tutte le SCHEDE per
ogni Paziente di ogni Centro.
41
RF6 Il Soggetto Sponsor inserisce le sue credenziali nel sistema per
visualizzare:
LISTA DEI CENTRI insieme al TOT PAZIENTI
Complessivo
TOT PAZIENTI per ogni Centro nello stessa vista
RF7 Il Referente del Progetto pu Esportare ELENCO PAZIENTI per
ogni centro in formato CSV contenente tutti i Dati richiesti dallo
Studio
RF8 Il Referente del Progetto pu Stampare lELENCO PAZIENTI
per ogni Centro Attivo in Formato Cartaceo o PDF contenente
tutti i Dati richiesti dallo Studio
RF9 LUtente del Centro Attivo pu inserire un NUOVO PAZIENTE
compilando la Scheda VISITA INIZIO STUDIO (Allegato 1)
RF10 LUtente del Centro Attivo pu effettuare il Download dei file in
formato ODT, DOC, PDF:
Allegato 1: CRF Visita inizio Studio
Allegato 2: CRF Visita Follow UP 3,6,9,12 mesi
Allegato 3: Scheda Informativa e Dichiarazione di
consenso informato
Allegato 4: Scheda Informativa per il Medico Curante
Allegato 5: CRF Rilevazione dei costi diretti e
indiretti
Allegato A1: Valutazione da parte del paziente
Allegato A2: Valutazione da parte del medico
Allegato A3: CRF Questionario sullo stato di salute
(SF36)
Allegato A4: CRF Indice di disabilit funzionale (HAQ)
42
RF11 LUtente del Centro Attivo, dopo ogni compilazione deve:
cliccare sul Tasto SALVA per inviare i Dati al Database
Centrale.
Viceversa deve cliccare sul Tasto CANCELLA per
azzerare tutti i campi della scheda.
RF12 LUtente del Centro Attivo pu Cancellare un Paziente e tutte le
sue SCHEDE cliccando sul tasto ELIMINA PAZIENTE in ELENCO
PAZIENTI
RF13 Il Sistema mostra una Richiesta di Conferma per le operazioni
di:
SALVA\CANCELLA SCHEDA
ELIMINA PAZIENTE
RF14 Il Sistema mostra un avviso se in una determinata SCHEDA
sono presenti Dati Errati o Mancanti.
RF15 LUtente del Centro Attivo pu Stampare le SCHEDE ultimate di
ogni Paziente nel suo Centro
RF16 LUtente del Centro Attivo pu Esportare lELENCO PAZIENTI
del suo Centro in formato CSV contenente tutti i Dati richiesti
dallo studio
RF17 LUtente del Centro Attivo pu Stampare lELENCO PAZIENTI
del suo Centro in Formato Cartaceo o PDF contenente tutti i
Dati richiesti dallo Studio
RF18 LUtente del Centro Attivo per ogni NUOVA SCHEDA VISITA
INIZIO STUDIO (Allegato 1) deve compilare anche la SCHEDA
VALUTAZIONE DA PARTE DEL MEDICO (Allegato A2)
INIZIO STUDIO (Allegato1) deve compilare anche la SCHEDA
QUESTIONARIO SULLO STATO DI SALUTE (SF36)
(AllegatoA3)
43
INIZIO STUDIO (Allegato 1) deve compilare anche la SCHEDA
INDICE DI DISABILITA FUNZIONALE (HAQ) (Allegato A4)
RF21 LUtente del Centro Attivo pu inserire una NUOVA SCHEDA di
VISITA FOLLOW-UP 3 mesi (Allegato 2) DOPO aver inserito
la SCHEDA VISITA INIZIO STUDIO (Allegato 1)
la SCHEDA di VISITA FOLLOW-UP 3 mesi (Allegato 2)
RF25 LUtente del Centro Attivo per ogni SCHEDA di VISITA
FOLLOW-UP 3, 6, 9, 12 mesi (Allegato 2) deve compilare
anche la SCHEDA RILEVAZIONE DEI COSTI (Allegato 5)
FOLLOW-UP 3, 6, 9, 12 mesi (Allegato 2) deve compilare la
SCHEDA VALUTAZIONE DA PARTE DEL MEDICO (AllegatoA2)
FOLLOW-UP 12 mesi (Allegato 2) deve compilare ANCHE la
SCHEDA QUESTIONARIO SULLO STATO DI SALUTE (SF36)
(Allegato A3)
FOLLOW-UP 3, 6, 9, 12 mesi (Allegato 2) deve compilare la
SCHEDA INDICE DI DISABILITA FUNZIONALE (HAQ)
(Allegato A4)
44
RF29 LUtente del Centro Attivo pu RITIRARE un Paziente dallo
Studio Dopo la SCHEDA VISITA INIZIO STUDIO (Allegato 1)
o Dopo una SCHEDA di VISITA FOLLOW-UP 3, 6, 9 mesi
(Allegato 2)
RF30 Il Paziente pu decidere di Ritirarsi dallo Studio compilando la
SCHEDA DI FOLLOW-UP12/FINE STUDIO.
Il sistema non permette linserimento di nuove schede per i
Pazienti Ritirati.
RF31 Ogni centro pu effettuare un singolo accesso al sistema e una
singola operazione di:
INSERIMENTO
MODIFICA
CANCELLAZIONE
per volta.
RF32 Le operazioni di:
INSERIMENTO
MODIFICA
CANCELLAZIONE
devono essere effettuate parallelamente da pi centri diversi.
Tabella 2
45
2.5.3 Servizi del Sistema: Requisiti Informativi
Nella tabella sono elencati tutti i Requisiti Informativi (RI#)

che identificano le principali informazioni di business che il
sistema deve gestire, la loro struttura e le loro eventuali
relazioni.
RI# REQUISITO INFORMATIVI
Contiene i dati relativi allUtente del

Centro Attivo
Struttura:
RI1 Utente Nome, Cognome, Ruolo, Username,
Password
Relazioni:
Centro(1..1)
Contiene i dati relativi al Centro Attivo
Struttura:
Codice_Centro, Nome, Farmacista,
RI2 Centro
Medico
Relazioni:
Utente(1..1), Paziente(1..18)
Contiene i dati relativi al Paziente
Struttura:
Codice_Paziente, Sesso, Data Nascita,
RI3 Paziente Attivit_Lavorativa
Relazioni:
Centro(1..1)
Scheda_Reclutamento(1..1),
46
Contiene i dati relativi alla visita di Inizio
Studio (Allegato1)
Struttura:
Codice_Paziente, Codice_Centro, Data,
Dati_Anamnesi_Clinica,
Dati_Valutazione_AR,
RI4 Scheda Reclutamento
Dati_Anamnesi_Farmacologica
Relazioni:
Paziente(1..1), Indice_HAQ(1..1),
Questionario_SF36(1..1),
Scheda FUP 3/6/9(1..3),
Scheda FUP 12(1..1)
Contiene i dati relativi alla Visita Follow-
Up 3,6,9 mesi (Allegato 2)
Struttura:
RI5 Scheda FUP 3/6/9
Dati_Trattamenti_Attuali
Relazioni:
Scheda Reclutamento(1..1)
Contiene i dati relativi alla Visita Follow-
Up 12 mesi (Allegato 2)
Struttura:
RI6 Scheda FUP 12
Dati_Trattamenti_Attuali
Relazioni:
Scheda Reclutamento(1..1)
47
Contiene i dati relativi alla rilevazione dei
costi diretti e indiretti
Struttura:
Codice_Paziente, Codice_Centro,
RI7 Scheda Costi Dati_Costi_Diretti, Dati_Costi_Indiretti,
Dati_Caregiver, Dati_Costi_Trasporto
Relazioni:
Scheda FUP 3/6/9(1..1),
Scheda FUP 12(1..1)
Contiene i dati relativi alla valutazione
da parte del medico (Allegato A2)
Struttura:
Scheda Valutazione Dati_Articolazioni, Vas_Malattia
RI8
Medico Relazioni:
Scheda_Reclutamento(1..1),
Scheda_FUP3/6/9(1..1),
Scheda_FUP12(1..1)
Contiene i dati del Questionario sullo
Stato di Salute SF36 (Allegato A3)
Struttura:
RI9 Questionario_SF36
Nome, Cognome, Data, Risultato_SF36
Relazioni:
Scheda_Reclutamento(1..1)
48
Contiene i dati dellIndice di Disabilit
Funzionale HAQ (Allegato A4)
Struttura:
RI10 INDICE_HAQ Dati_Questionario,
Risultato_Questionario
Relazioni:
Scheda_Reclutamento(1..1)
Tabella 3
49
2.6 Vincoli di Sistema
Figura 4:Vincoli
Le limitazioni cui il sistema deve sottostare quando esegue

i propri servizi rappresentano i Requisiti di Interfaccia, i Requisiti
Operativi ed eventuali Altri vincoli.
I Requisiti di Interfaccia definiscono come il prodotto si
rapporta con gli utenti e richiede la definizione a grandi linee
delle caratteristiche generali dellinterfaccia che il sistema dovr
includere.
I Requisiti Operativi specificano lambiente hardware e
software dove operer il sistema.
Gli Altri vincoli di sistema sono ad esempio Requisiti di
Prestazione, Requisiti di Sicurezza, Requisiti Legali e Politici,
Requisiti di Manutenibilit, Requisiti di Usabilit, Requisiti di
Progetto e cos via.
50
2.6.1 Vincoli di Sistema : Requisiti di Interfaccia
V1: Interfaccia Utente

Linterazione avviene mediante uninterfaccia visuale di tipo
Browser-Based caratterizzata da un men verticale, schede
orizzontali di navigazione e moduli per linserimento dei dati.
La messaggistica e le etichette (men, pulsanti, campi testuali,
ecc) che compaiono durante linterazione sono di immediata
comprensione da parte dellutente.
I termini farmacologici appartenenti al dominio applicativo
aderiscono al linguaggio tecnico-scientifico condiviso e compreso
da tutti gli utenti.
Il sistema garantisce il controllo dellinterazione, limitando la
possibilit di commettere errori. In ogni fase dellinterazione
sono mostrate allutente tutte e sole le informazioni necessarie al
loro svolgimento.
V2: Interfaccia Hardware

La tecnologia adottata di uso comune (video, tastiera e
mouse). Luso della tastiera richiesto solo per inserimento dei
dati e non per invocare lesecuzione.
V3: Interfaccia Software

Lapplicazione non richiede altro software aggiuntivo.
51
2.6.2 Vincoli di Sistema: Requisiti Operativi
V4: Hardware
Client (Requisiti Minimi):

Mac \ Pc
1Gb Ram
Cpu Amd \ Intel x86 Compatibile
Ulteriore spazio su disco non richiesto
Ethernet 10/100/1000
Server:
Server HP ProLiant serie ML115 G5
1 Cpu AMD Athlon 4450B Dual Core a 2,30 GHz
8GB SDRAM DDR2 PC2-6400 (800Mhz)
Controller SATA2 RAID (0,1,5) Hotswap
4 Dischi SATA2 da 500GB in configurazione Raid 5
Ethernet Gigabit
Gruppo di Continuit dedicato APC Smart-UPS XL 750VA
V5: Software
Client:
Sistema Operativo: Il sistema Dose Web OS-Indipendent
JAVA VM: Version 6 Update 14
Browser Web Compatibili: Mozilla Firefox 3.x, Apple Safari
4.x, Opera 10.x, Google Chrome 2.x
52
Server:
Sistema Operativo: Red Hat Enterprise Linux 5 server
Server Web: Apache 2 Http Server
Web Container: Apache Tomcat 6.x
JAVA VM: Version 6 Update 14
DBMS: MySql 5.x
2.6.3 Vincoli di Sistema: Altri Vincoli
V6: Requisiti di sicurezza
Laccesso al sistema richiede limmissione di Username e

una password alfanumerica di 8 caratteri.
La banca dati sar conservata fino al completamento dello studio
osservazionale alla fine del quale verr distrutta.
Il sistema attuale non utilizza nessuna politica di crittografia per
la trasmissione e il mantenimento delle informazioni.
V7: Requisiti di progetto
Lintero sistema deve essere unapplicazione Java, quindi la

tecnologia da utilizzare deve essere una piattaforma per lo
sviluppo di applicazioni Java2EE.
Questi aspetti verrano approfonditi pi dettagliatamente nel
capitolo IV di questo documento.
V8: Requisiti Legali
Il sistema identifica ogni Paziente mediante un codice che

impedisce qualsiasi specifica identificazione in conformit alle
53
norme per la tutela dei dati personali e del diritto alla
riservatezza (D. Lgs. 196/03).
V9: Affidabilit
Il sistema deve essere disponibile 8h su 24h (8:0016:00),

5 giorni su 7. Verr eseguito un backup automatico giornaliero
della banca dati nelle ore notturne con notifica per
lAmministratore del Portale.
54
2.6.4 Vincoli di Sistema: Stabili t dei Vincoli
VINCOLO
Stabile
Stabile
Non
Motivazione
V1
V2
V3
Levoluzione del sistema potrebbe richiedere
V4 laggiornamento dei requisiti hardware.
Levoluzione del sistema potrebbe richiedere
V5 laggiornamento dei requisiti software.
Levoluzione del sistema potrebbe introdurre una
V6 politica di crittografia per la trasmissione e il

mantenimento delle informazioni.
V7
Levoluzione del sistema deve tenere conto di
V8 modifiche alle leggi in materia di tutela dei dati

personali.
V9
Tabella 4
55
Capitolo 3: Progetto di sistema
3.1 Classi Stereotipate
3.1.1 Diagramma delle classi stereotipate: entit
Questo diagramma descrive gli oggetti che rappresentano

le entit del dominio applicativo e che partecipano in differenti
realizzazioni dei casi duso.
Figura 5: Classi stereotipate
56
3.2 Casi duso
3.2.1 Diagramma dei casi duso
Dopo la fase di raccolta dei requisiti funzioni e informativi

saranno descritte tutte le funzionalit operative fornite dalle
specifiche entit del sistema, i messaggi scambiati tra di essi e le
sequenze di azioni che svolgono.
Questo diagramma mette in relazione i requisiti
permettendo una visione chiara delle possibili modalit di utilizzo
del sistema e le interazioni tra di esso e lambiente esterno.
57
Figura 6: Casi duso
58
3.3 Casi duso : Informazioni di base
Caso dUso (1): Accesso alla Parte Pubblica
Consente di accedere alle pagine

Home
Protocollo
Descrizione
Diagramma di Studio
Gruppo di ricerca
Contatti
Attore Primario Qualsiasi Utente
LUtente possiede tutti i requisiti vincoli software (V5)
richiesti:
Pre-Condizioni
Browser web compatibile | Java VM: v6 Update 14 o
superiore
Post-Condizioni
Il sistema On-Line e lutente visiona le pagine
per il successo
Il sistema Off-Line e lutente visualizza una pagina che
Post-Condizioni
avverte della temporanea interruzione del servizio e
per il fallimento
suggerisce i contatti per richiedere informazioni.
Evento Lutente inserisce lindirizzo web del sistema
Innescante nellapposita barra del proprio browser.
Tabella 5
Caso dUso (2): Autenticazione
Consente di accedere alla parte privata e alle funzionalit

Descrizione
previste nel sistema.
Attore Primario Qualsiasi Utente
Pre-Condizioni Lutente in possesso della proprio username e password.
59
Il sistema riconosce lutente mostra una pagina diversa a
seconda del tipo di utente:
1) Responsabile del progetto (Monitor): Lista dei centri
Post-Condizioni
attivi
per il successo
2) Utente del centro attivo (Medico): Elenco Pazienti
3) Soggetto sponsor (Wyeth Lederle S.p.A): Lista dei centri
attivi
L'utente non possiede username e password:
lutente non pu accedere.
Lutente ha dimenticato username e password: il
sistema suggerisce i contatti per richiederli
Post-Condizioni nuovamente.
per il fallimento Lutente non ha ancora ricevuto username e
password: il sistema suggerisce i contatti per
richiederli.
Lutente ha inserito username e password eratti: il
sistema avverte dellerrore.
Evento
Lutente ha cliccato sul pulsante di LOGIN.
Innescante
Tabella 6
Caso dUso (3): Inserimento visita inizio studio
Consente di arruolare un paziente nello studio inserendo la

Descrizione
prima scheda Visita inizio studio.
Attore Primario Utente del centro attivo
Lutente stato riconosciuto dal sistema.
Il paziente non stato arruolato precedentemente.
Pre-Condizioni
Il paziente soddisfa i criteri di inclusione dello studio
(Protocollo)
60
Lutente ha compilato correttamente tutti i campi
Post-Condizioni
della scheda.
per il successo
Lutente ha salvato la scheda compilata.
L'utente ha arruolato un paziente che non soddisfa i
criteri di inclusione: il sistema avverte lutente che il
paziente non pu essere arruolato (et <18,
partecipazione ad altro studio)
Lutente non ha compilato tutti i campi della scheda
o alcuni campi in modo errato: il sistema evidenzia i
Post-Condizioni campi non corretti.
per il fallimento Lutente ha intenzione di chiudere la scheda prima
di completare linserimento di tutti i campi: il
sistema avverte lutente che non pu salvare una
scheda incompleta o errata.
Lutente non ha completato linserimento anche del
Questionario SF36 | Valutazione Medico | Indice
HAQ: Il sistema avverte lutente.
Evento
Lutente clicca su Nuovo Paziente
Innescante
Caso dUso (3a): Questionario SF36
Include Caso dUso (3b): Valutazione Medico
Caso dUso (4a): Indice HAQ
Tabella 7
Caso dUso (4): Inserimento Visita Follow-Up (Caso Generale)
Consente lavanzamento dello studio inserendo una scheda

Descrizione
di Follow-Up per un paziente gi arruolato.
61
Pre-Condizioni
Il paziente stato precedentemente arruolato.
Post-Condizioni
della scheda.
per il successo
campi non corretti.
Lutente ha intenzione di chiudere la scheda prima
Post-Condizioni di completare linserimento di tutti i campi: il
per il fallimento sistema avverte lutente che non pu salvare una
Valutazione Medico | Indice HAQ | Rilevazione
Costi: Il sistema avverte lutente.
Evento Lutente clicca sul pulsante di inserimento di Visita
Innescante FollowUp
Caso dUso (4d): Inserimento Visita Follow-Up 3 Mesi
Caso dUso (4e): Inserimento Visita Follow-Up 6 Mesi
Generalizza
Caso dUso (4f): Inserimento Visita Follow-Up 9 Mesi
Caso dUso (4g): Inserimento Visita Follow-Up 12 Mesi
Caso dUso (3b): Valutazione Medico
Include Caso dUso (4a): Indice HAQ
Caso dUso (4b): Rilevazione Costi
Richiede Caso dUso (3): Inserimento visita inizio studio
Tabella 8
Caso dUso (4d)/(4e)/(4f): Inserimento Visita Follow-Up 3/6/9 Mesi
Consente di inserire una scheda di Follow-Up a 3/6/9 Mesi

Descrizione
per un paziente gi arruolato nello studio
62
Il paziente stato precedentemente arruolato.
Il paziente possiede una:
(4d) Visita inizio studio completa.
Pre-Condizioni (4e): Visita inizio studio completa.
(4e): Scheda di Follow-Up a 3 Mesi completa.
(4f): Visita inizio studio completa.
(4f): Scheda di Follow-Up a 3 Mesi completa.
(4f): Scheda di Follow-Up a 6 Mesi completa.
Lutente ha compilato correttamente tutti i campi della
Post-Condizioni
scheda.
per il successo
campi non corretti.
Post-Condizioni
per il fallimento
Valutazione Medico | Indice HAQ | Rilevazione
Costi: Il sistema avverte lutente.
Lutente clicca sul pulsante di inserimento di Visita

Evento
Innescante Follow-Up 3/6/9 Mesi
(4d) Caso dUso (3): Inserimento visita inizio studio
Richiede (4e) Caso dUso (4d): Inserimento visita Folow-Up 6 mesi
(4f) Caso dUso (4e): Inserimento visita Folow-Up 9 mesi
Include Caso dUso (4a): Indice HAQ
Specializza Caso dUso (4): Inserimento Visita Follow-Up
Tabella 9
Caso dUso (4g): Inserimento Visita Follow-Up 12 Mesi
Consente di concludere lo studio compilando lultima

Descrizione
scheda
63
Il paziente possiede la scheda Visita inizio studio e
Pre-Condizioni
tutte le schede di Follow-Up compilate
correttamente
Post-Condizioni
della scheda.
per il successo
campi non corretti.
Post-Condizioni di completare linserimento di tutti i campi: il
per il fallimento sistema avverte lutente che non pu salvare una
Lutente non ha completato anche linserimento di
Valutazione Medico | Indice HAQ | Rilevazione Costi
| Questionario SF36: Il sistema avverte lutente.
Evento Lutente clicca sul pulsante di inserimento di Visita
Innescante Follow-Up 12 Mesi
Richiede Caso dUso (4e): Inserimento visita Folow-Up9mesi
Include
Tabella 10
64
Consente di compilare il Questionario sullo stato di salute

Descrizione
SF36 (Allegato A3).
Lutente sta compilando una scheda di Visita Inizio
Pre-Condizioni Studio o una scheda Follow-Up a 12 Mesi.
Il sistema mostra una sotto-finestra contenente i
campi del questionario.
del questionario.
Post-Condizioni Lutente ha salvato il questionario compilato.
per il successo Il sistema calcola il valore finale del questionario e
lo inserisce allinterno della scheda che lutente sta
compilando
Lutente non ha compilato tutti i campi del
questionario o alcuni campi in modo errato: il
sistema evidenzia i campi non corretti.
Post-Condizioni
Lutente ha intenzione di chiudere il questionario
per il fallimento
prima di completare linserimento di tutti i campi: il
sistema avverte lutente che non pu salvare un
questionario incompleto o errato.
Lutente clicca sul pulsante per il calcolo
Evento
dellSF36 allinterno della scheda di Visita Inizio
Innescante
Studio o della scheda Follow-Up a 12 Mesi.
Tabella 11
65
Consente di compilare il Questionario sulla Valutazione da

Descrizione
parte del medico (Allegato A2).
Pre-Condizioni Studio o una scheda Follow-Up a 3/6/9/12 Mesi.
del questionario.
compilando
Post-Condizioni
per il fallimento
Lutente clicca sul pulsante per il calcolo delle
Evento Articolazioni dolente e tumefatte interno della scheda di
Innescante Visita Inizio Studio o della scheda Follow-Up a 3/6/9/12
Mesi.
Tabella 12
66
Consente di compilare il questionario per il calcolo

Descrizione
dellIndice HAQ di disabilit funzionale (Allegato A4).
Pre-Condizioni Studio o una scheda Follow-Up a 3/6/9/12 Mesi.
del questionario.
compilando.
Post-Condizioni
per il fallimento
Lutente clicca sul pulsante per il calcolo dellIndice
Evento
HAQ allinterno della scheda di Visita Inizio Studio o
Innescante
della scheda Follow-Up a 3/6/9/12 Mesi.
Tabella 13
67
Consente di inserire una scheda di Rilevazione dei costi

diretti e indiretti per un paziente gi arruolato nello
Descrizione
studio e per il quale si sta inserendo anche una scheda
Follow-Up 3/6/9/12 mesi
Pre-Condizioni
Il paziente possiede la scheda Visita inizio studio.
Post-Condizioni
della scheda.
per il successo
campi non corretti.
Post-Condizioni
per il fallimento
Lutente clicca sul pulsante di inserimento della
Evento Scheda di Rilevazione Costi in prossimit del
Innescante pulsante di inserimento di una scheda di visita
Follow-Up 3/6/9/12 mesi
Tabella 14
Caso dUso (5): Download Allegati
Consente il download di tutte le schede di raccolta dati e

Descrizione
del materiale informativo di supporto allo studio
68
Pre-Condizioni Lutente stato riconosciuto dal sistema.

Post-Condizioni
Il download stato completato al 100%
per il successo
Post-Condizioni I file sono presenti sul server
per il fallimento Errori di trasmissione durante il download
Evento Lutente clicca sul pulsante di download nel menu
Innescante laterale
Tabella 15
Caso dUso (6): Elimina Paziente
Consente leliminazione di tutti i dati raccolti per un

Descrizione
determinato paziente durante lo studio
Pre-Condizioni Il paziente possiede almeno una scheda di Visita
inizio studio.
Post-Condizioni
I dati dellutente sono stati eliminati dalla banca dati
per il successo
Post-Condizioni
per il fallimento
Evento Lutente clicca sul pulsante di Elimina Paziente
Innescante nellElenco Pazienti
Tabella 16
Caso dUso (7): Interrompi studio
Consente i ritirare un paziente dallo studio prima che abbia

Descrizione
completato tutte le visite
69
Pre-Condizioni Il paziente possiede almeno una scheda di Visita
inizio studio.
Post-Condizioni Il sistema non permette di inserire altre schede per il
per il successo paziente ritirato
Post-Condizioni L'utente compila una scheda diversa da Follow-Up
per il fallimento a 12 Mesi
Lutente seleziona una scheda di Follow-Up a 12
Evento
mesi prima di aver compilato le precedenti a 3/6/9
Innescante
mesi
Tabella 17
Caso dUso (8): Lista Centri
Consente di visualizzare la lista di tutti i centri attivi nello

Descrizione
studio.
Attore Primario Referente del Progetto e Soggetto Sponsor

Post-Condizioni
Lutente visualizza la lista aggiornata
per il successo
Post-Condizioni
per il fallimento
Evento Lutente si logga nel sistema
Innescante Lutente seleziona la voce Lista Centri
Tabella 18
70
Caso dUso (8a): Totale Pazienti
Consente di visualizzare il numero totale di tutti i pazienti

Descrizione
arruolati nello studio

Post-Condizioni Lutente visualizza la tabella dei totali sopra la lista dei
per il successo centri e dei pazienti
Post-Condizioni
per il fallimento
Evento
Lutente si logga nel sistema
Innescante
Estende Caso dUso (8): Lista Centri
Tabella 19
Caso dUso (8b): Totale Pazienti Centro
Consente di visualizzare il numero Totale dei Pazienti di un

Descrizione
Centro Attivo suddiviso per mesi e tipo di scheda inserita

Post-Condizioni Lutente visualizza la tabella dei totali sopra la lista dei
per il successo centri e dei pazienti
Post-Condizioni
per il fallimento
Evento Lutente si logga nel sistema
Innescante Lutente visualizza la Lista Pazienti per Centro
Estende Caso dUso (8): Lista Centri
Tabella 20
71
Caso dUso (9): Elenco Pazienti del centro
Consente di visualizzare la lista di tutti i pazienti arruolati

Descrizione
in un centro attivo nello studio.
Attore Primario Referente del Progetto e Utente del Centro Attivo

Post-Condizioni
per il successo
Post-Condizioni
per il fallimento
Per il Referente Del Progetto: Lutente clicca il nome
Evento del centro allinterno nella Lista Centri
Innescante Per lUtente del Centro Attivo: Lutente si logga nel
sistema
Tabella 21
Caso dUso (9a): Esporta Elenco Pazienti
Consente di esportare la lista di tutti i pazienti arruolati in

Descrizione
un centro attivo nello studio
Pre-Condizioni
Lutente visualizza la Lista Pazienti
Post-Condizioni
Lutente salva il file sul proprio client
per il successo
Post-Condizioni
per il fallimento
72
Lutente clicca sullicona di esportazione in
Evento
CSV oppure
Innescante
Lutente clicca sullesportazione Stampa\PDF
Estende Caso dUso (9): Elenco Pazienti
Tabella 22
Caso dUso (9b): Visualizza Scheda Paziente
Consente di visualizzare una qualsiasi Scheda Clinica gi

Descrizione
compilata
Pre-Condizioni
Lutente visualizza una Scheda Clinica gi compilata
Post-Condizioni
Lutente salva il file sul proprio client
per il successo
Post-Condizioni L'utente clicca su una scheda che non ancora
per il fallimento stata compilata
Evento
Lutente clicca sullicona di una scheda compilata
Innescante
Tabella 23
Caso dUso (9c): Esporta Scheda Paziente
Consente di esportare una qualsiasi Scheda clinica gi

Descrizione
compilata in formato PDF
Pre-Condizioni
Lutente visualizza una scheda gi compilata
73
Post-Condizioni
per il successo
Post-Condizioni L'utente clicca su una scheda che non ancora
per il fallimento stata compilata
Evento
Lutente clicca sullesportazione Stampa\PDF
Innescante
Tabella 24
74
3.4 SCENARI
Scenario di Base Caso dUso (1): Accesso alla parte pubblica
1. Lutente inserisce lindirizzo web nel browser
2. Il sistema mostra la pagina Home
3. Lutente visualizza il contenuto principale e un menu di navigazione laterale
Scenario Alternativo 1
3.1 Lutente sceglie di visualizzare la pagina Protocollo
3.2 Il sistema mostra la pagina Protocollo
3.1a Lutente sceglie di visualizzare la pagina Diagramma di Studio
3.2a Il sistema mostra la pagina Diagramma di Studio
3.1b Lutente sceglie di visualizzare la pagina Chi siamo (Gruppo di Ricerca)
3.2b Il sistema mostra la pagina Chi siamo
3.1c Lutente sceglie di visualizzare la pagina Contatti
3.2c Il sistema mostra la pagina Contatti
Scenario Alternativo 5 (Insuccesso)
2.1 Il sistema offline
2.2 Lutente visualizza una pagina per richiedere informazioni di supporto.
2.3 Lutente chiude il browser e termina la navigazione

Tabella 25
75
Scenario di Base Caso dUso (2): Autenticazione
1. Lutente seleziona la funzionalit di login dal men laterale

2. Il sistema mostra un form per linserimento di username \ password e
fornisce la possibilit di richiedere i dati nel caso lutente ne sia sprovvisto o li
abbia smarriti
3. Lutente inserisce username e password corretti
4. Il sistema valida i dati inseriti e riconosce la tipologia di utente: Referente
del Progetto e Soggetto Sponsor
5. Il sistema mostra la Lista dei Centri Attivi
4.1 Il sistema valida i dati inseriti e riconosce la tipologia di utente: Utente del
Centro Attivo
4.2 Il sistema mostra lElenco Pazienti del Centro Attivo
Scenario Alternativo 2 (Insuccesso)

3.1 Lutente inserisce username e password non corretti
3.2 Il sistema notifica lerrore

3.3 Ripeti 3
Tabella 26
Scenario di Base Caso dUso(3): Inserim. visita inizio studio
1. Il sistema visualizza lElenco Pazienti del centro

2. Lutente selezione la funzionalit per linserimento di un Nuovo Paziente
(Arruolamento)
3. Il sistema visualizza un form per la compilazione della Scheda di
Reclutamento
4. Lutente compila la scheda correttamente e clicca sul pulsante salva
76
5. Il sistema verifica i dati, visualizza lIdentificativo numerico del nuovo
paziente inserito e aggiorna lElenco Pazienti
Scenario Alternativo 1 (insuccesso)
4.1 Lutente compila in parte o in nessuna parte la scheda e clicca sul
pulsante cancella
4.2 Il sistema avverte che tutti i dati inseriti saranno azzerati e attende
conferma
4.3 Lutente conferma la cancellazione
4.1a Lutente commette degli errori nella compilazione e clicca sul pulsante
salva
4.2a Il sistema verifica i dai non corretti e attente la correzione prima del
salvataggio
4.3a Lutente corregge\completa la scheda e clicca sul pulsante salva
4.4a Ripeti 5
Tabella 27
Scenario di Base Caso dUso (4): Inserimento Visita FUP
Caso generale vedere le tabelle successive 4d, 4e, 4f, 4g

Tabella 28
Scenario di Base Caso dUso (4d): Inserim. Visita FUP 3 mesi
1. Il sistema mostra lElenco di tutti i pazienti di un centro gi arruolati

2. Lutente individua il paziente mediante il suo Identificativo numerico e
clicca su Inserimento Visita Follow-Up 3 mesi
3. Il sistema mostra un form per la compilazione della scheda
5. Il sistema verifica i dati e aggiorna lElenco Pazienti
77
2.1 Lutente cerca il paziente tramite il suo identificativo numerico

2.2 Il sistema mostra lelenco pazienti ridotto al solo paziente
cercato
2.3 Lutente clicca su Inserimento Visita Follow-Up 3 mesi
2.3 ripeti 3

2.1a Il paziente possiede gi una scheda di Follow-Up a 3 mesi o
successiva
2.2a Il sistema avverte lutente e non visualizza nessuna scheda di
raccolta dati
3.1 Lutente compila in parte o in nessuna parte la scheda e clicca
sul pulsante cancella
3.2 Il sistema avverte che tutti i dati inseriti saranno azzerati e
attende conferma
4.1a Lutente commette degli errori nella compilazione e clicca sul
pulsante salva
4.2a Il sistema verifica i dai non corretti e attende la correzione
prima del salvataggio
4.3a Lutente corregge\completa la scheda e clicca sul pulsante
salva
4.4a Ripeti 5
Tabella 29
78
Scenario di Base Caso dUso (4e): Inserim. Visita FUP 6 mesi


cercato
2.3 ripeti 3

successiva
raccolta dati
attende conferma
79
pulsante salva
salva
4.4a Ripeti 5
Tabella 30
Scenario di Base Caso dUso (4f): Inserim. Visita FUP 9 mesi


cercato
2.3 ripeti 3

successiva
raccolta dati
80
attende conferma
pulsante salva
salva
4.4a Ripeti 5
Tabella 31
Scenario di Base Caso dUso (4g): Inserim. Visita FUP 12mesi

clicca su Inserimento Visita Follow-Up 12 mesi / Conclusione Studio

cercato
81
2.3 Lutente clicca su Inserimento Visita Follow-Up 12 mesi / Conclusione
Studio
2.3 ripeti 3

attende conferma
pulsante salva
salva
4.4a Ripeti 5
Tabella 32
Scenario di Base Caso dUso (3a): Questionario SF36
1. Lutente clicca sul pulsante per il calcolo dellSF36

2. Il sistema apre una sotto-finestra contenente un form con i dati
richiesti per il calcolo dellSF36
3. Lutente compila la scheda correttamente e clicca sul pulsante
salva
4. Il sistema verifica i dati e calcola lSF36 inserendolo nella scheda
principale
82
5. Lutente chiude la sotto-finestra e continua con la compilazione
della scheda principale (Inizio Studio o FUP 12)
attende conferma
3.3 Lutente conferma la cancellazione e ripeti 5
pulsante salva
salva
3.4a Ripeti 5
Tabella 33
Scenario di Base Caso dUso (3b): Valutazione Medico
Questo scenario presenta lo stesso comportamento del precedente

Caso dUso (3a): Questionario SF36 ad eccezione della scheda
principale che in questo scenario una scheda di Follow-Up
3/6/9/12
Tabella 34
Scenario di Base Caso dUso (4a): Indice HAQ

Tabella 35
83
Scenario di Base Caso dUso (4b): Rilevazione Costi

clicca su Inserimento Visita Follow-Up 3 o 6 o 9 o 12 Mesi
3. Il sistema mostra un form per la compilazione della scheda se la relativa
scheda di Visita Follow stata compilata correttamente

cercato
2.3 Lutente clicca su Inserimento Visita Follow-Up 3 o 6 o 9 o 12 Mesi
2.3 ripeti 3

attende conferma
pulsante salva
84
salva
4.4a Ripeti 5
Tabella 36
Scenario di Base Caso dUso (5): Download Allegati
1. Lutente clicca sulla voce download nel men laterale
2. Il sistema mostra la pagina con lelenco dei file
3. Lutente clicca sullicona del formato PDF e conferma il download
3.1 Lutente clicca sullicona del formato DOC\ODT e conferma il download

Tabella 37
Scenario di Base Caso dUso (6): Elimina Paziente
1. Il sistema mostra lElenco Pazienti
2. Lutente individua il paziente mediante il suo Identificativo numerico
3. Lutente clicca sul pulsante Elimina Paziente
4. Il sistema mostra un messaggio e attenda conferma
5. Lutente conferma leliminazione
6. Il sistema aggiorna lElenco Pazienti

cercato
2.3 Ripeti 3
Tabella 38
85
Scenario di Base Caso dUso (7): Interrompi Studio

clicca su Inserimento Visita Follow-Up 12 mesi / Conclusione Studio

5. Il sistema verifica i dati e blocca linserimento delle altre schede Follow-Up
3/6/9 mesi nel caso non siano state ancora completate
2.2 Il sistema mostra lelenco pazienti ridotto al solo paziente cercato

2.3 Lutente clicca su Inserimento Visita Follow-Up 12 mesi / Conclusione
Studio
2.3 ripeti 3

3.1 Lutente compila in parte o in nessuna parte la scheda e clicca sul
pulsante cancella
3.2 Il sistema avverte che tutti i dati inseriti saranno azzerati e attende
conferma
4.1a Lutente commette degli errori nella compilazione e clicca sul pulsante
salva
4.2a Il sistema verifica i dai non corretti e attende la correzione prima del
salvataggio
86
4.3a Lutente corregge\completa la scheda e clicca sul pulsante salva
4.4a Ripeti 5
Tabella 39
Scenario di Base Caso dUso (8): Lista Centri
1. Lutente effettua lAutenticazione nel sistema

2.1 Lutente clicca sulla voce Lista Centri nel men laterale
2.2 ripeti 3
Tabella 40
Scenario di Base Caso dUso (8a): Totale Pazienti

3. Il sistema mostra la Tabella dei Totali Complessivi sopra la Lista dei Centri
Attivi
3.2 ripeti 3
Tabella 41
Scenario di Base Caso dUso (8b): Totale Pazienti Centro
87
4. Lutente seleziona un centro nella lista
5. Il sistema mostra la Tabella del Totale Pazienti sopra la Lista dei Pazienti
3.2 ripeti 3
Tabella 42
Scenario di Base Caso dUso (9): Elenco Pazienti del Centro

Caso dUso (8b): Totale Pazienti Centro per il Referente del Progetto
ad eccezione di:
Non valido per il Soggetto Sponsor.
Utente del centro attivo visualizza lElenco Pazienti subito
dopo lAutenticazione o selezionando la voce Elenco Pazienti
nel men laterale.
Tabella 43
Scenario di Base Caso dUso (9a): Esporta Elenco Pazienti
1. Il sistema mostra lElenco Pazienti di un centro attivo
2. Lutente clicca sullicona di file CSV e conferma il download
2.1 Lutente clicca sullicona di file STAMPA\PDF e conferma il download

Tabella 44
88
Scenario di Base Caso dUso (9b): Visualizza scheda Paziente
3. Lutente clicca su una Scheda di Inizio Studio
4. Il sistema mostra la scheda completata

cercato
2.3 Ripeti 3
3.1 Lutente clicca su una Scheda di Follow-Up 3/6/9/12 compilata

3.2 Il sistema mostra una pagina contenente licona di una scheda
Follow-Up 3/6/9/12 e licona di una scheda di Rilevazione Costi
3.3 Lutente sceglie di visualizzare una delle due schede
3.4 Ripeti 4
3.1a Lutente clicca su una Scheda di Follow-Up 3/6/9/12 non compilata

3.2a Il sistema apre la scheda per la compilazione solo se
una Scheda Follow-Up 3
una Scheda Follow-Up 6 se stata completata la precedente
una Scheda Follow-Up 12 se stata completata la precedente o
nel caso lutente voglia ritirare il paziente dallo studio (Caso
duso(7): Interrompi studio)
3.3a Vai al Caso duso (4) Inserimento Visita Follow-UP

Tabella 45
89
Scenario di Base Caso dUso (9c): Esporta Scheda Paziente
3. Lutente clicca su una Scheda di Inizio Studio
4. Il sistema mostra la scheda completata
5. Lutente clicca sullicona STAMPA\PDF e conferma il download
2.2 Il sistema mostra lelenco pazienti ridotto al solo paziente cercato
2.3 Ripeti 3
3.1 Lutente clicca su una Scheda di Follow-Up 3/6/9/12 compilata
3.2 Il sistema mostra una pagina contenente licona di una scheda Follow-
Up 3/6/9/12 e licona di una scheda di Rilevazione Costi
3.3 Lutente sceglie di visualizzare una delle due schede
3.4 Ripeti 4

3.1a Lutente clicca su una Scheda di Follow-Up 3/6/9/12 non compilata
3.2a Il sistema apre la scheda per la compilazione solo se

una Scheda Follow-Up 3
una Scheda Follow-Up 12 se stata completata la precedente o
nel caso lutente voglia ritirare il paziente dallo studio (Caso
duso(7): Interrompi studio)
3.3a Vai al Caso duso (4) Inserimento Visita Follow-UP

Tabella 46
90
3.5 Diagrammi di Sequenza
I diagrammi di sequenza hanno il compito di modellare

graficamente le interazioni tra gli oggetti che implementano
insieme un preciso comportamento o, pi generalmente, un
preciso scenario. Rappresentano il tipo di interazione, la risposta
e la distruzione degli oggetti e l'istante di tempo in cui queste
operazioni avvengono.
Figura 7: Accesso alla parte pubblica
91
Figura 8: Autenticazione
92
Figura 9: Inserimento visita inizio studio
93
Figura 10: Inserimento visita Follow-up 3 Mesi
94
Figura 13: : Inserimento visita Follow-up 12 Mesi
95
Figura 14: Alternativa 1 Questionario SF36
96
Figura 15: Alternativa 2 Questionario SF36
97
Figura 16: Alternativa 1 Valutazione Medico
Figura 17: Alternativa 2 Valutazione Medico
98
Figura 18: Alternativa 1 Indice HAQ
Figura 19: Alternativa 2 Indice HAQ
99
Figura 20: Alternativa 1 Rilevazione Costi
Figura 21: Alternative 2,3,4 Rilevazione Costi
100
Figura 22: Elimina Paziente
101
Figura 23: Interrompi studio
Figura 24: Lista centri
102
Figura 25: Totale Pazienti
Figura 26: Totale Pazienti Centro
Figura 27: Elenco Pazienti Centro
103
Figura 28: Esporta Elenco Pazienti
Figura 29: Visualizza Scheda paziente
104
3.6 Progetto De i Dati
La progettazione del Database ha richiesto particolare

attenzione in quanto i numerosi dati raccolti saranno manipolati
successivamente da applicativi di analisi statistica.
Pertanto non ci si soffermati su problemi di efficienza o
semplicit ma si riflettuto in particolar modo sulla struttura pi
adatta per la successiva manipolazione.
Il DB stato realizzato in modo da poter contenere i
seguenti dati rispettando, il pi possibile, la struttura imposta dal
diagramma dello studio Dose con la suddivisione in visite di inizio
studio (Reclutamento) e visite follow-up:
i dati di autenticazione al sistema;
i dati di ogni utente attivo e relativo centro;
i dati anagrafici dei pazienti secondo una modalit
conforme alle norme per la tutela dei dati personali e del
diritto alla riservatezza (D. Lgs. 196/03);
i dati clinici di ogni paziente;
i dati farmacologici della terapia
i dati socio-economici di ogni paziente
i dati parziali per il calcolo dei questionari e indici (SF36,
HAQ, ecc..)
La struttura del database stata trasferita su MYSQL,

mentre la definizione delle classi venute fuori da questa analisi
stata trasferita sul framework Struts.
Il framework, presuppone la suddivisione logica secondo il
pattern MVC, per cui le classi boundary della fase di
progettazione sono state tradotte in pagine JSP, o meglio pagine
105
appartenti alla View del sistema; mentre le classi controller
sono state tradotte in Action.
In relazione alle classi entity, invece, abbiamo dei bean.
Tali oggetti Java sono a loro volta mappati nel database
relazionale derivante, attraverso lutilizzo di Hibernate, che
permette allapplicativo di diventare totalmente indipendente al
tipo di database utilizzato.
106
3.6.1 Diagramma della dipendenza dei Dati
Figura 30: Dipendenza dei dati
Per rendere il diagramma di facile comprensione sono stati

rappresentati solo gli attributi principali e le chiavi primarie.
Per il dettaglio di tutti gli attributi si rimanda alla
consultazione della seguente tabella: Dettaglio Dei Dati.
107
3.6.2 Modello del Database
Figura 31: Modello del Database
108
3.6.3 Dettaglio Dei Dati
In queste tabelle sono descritte tutte le relazioni e relativi i

campi presenti nel DB del sistema DOSE Web.
Nelle descrizioni sono stati raggruppati alcuni campi che
presentano contenuti simili. Il raggruppamento stato indicato
con il simbolo ().
account
Identificatore Campo Chiave Tipo Descrizione
Identificativo univoco di
id Primaria INT un account per laccesso
al sistema
centro VARCHAR Codice univoco del centro
VARCHAR Cognome del medico del

medico
centro
VARCHAR Cognome del farmacista
farmacista
del dentro
user VARCHAR Username per il login
pass VARCHAR Password per il login
nome VARCHAR Nome del centro
VARCHAR Cognome medico e

cognome
farmacista
VARCHAR Identificativo del ruolo
ruolo
dellutente nel sistema
Tabella 47
109
pazienti
id Primaria INT
un paziente
Codice univoco di un
Codice VARCHAR
paziente
Sesso del paziente
Sesso CHAR
(0 uomo, 1 donna)
Data di nascita del
DataNascita VARCHAR
paziente
Attivit Lavorativa
AttivitaLav VARCHAR (Manuale, dufficio,
pensionato, ecc)
Data inclusione del
DataInclusioneDB TIMESTAMP
paziente nel database
Tabella 48
corticosteroidi \ dmard \ fans \ altri farmaci \ brms
Codice univoco di
ATC7 Primaria VARCHAR identificazione di un
farmaco
Descrizione del
Desc_ATC7 VARCHAR
farmaco\principio attivo
Tabella 49
110
farmaciFollowUp
id Primaria INT farmaco per una scheda
Follow-Up
idPaziente VARCHAR
paziente
Codice univoco di
farmaco VARCHAR identificazione di un
farmaco
dose VARCHAR Dose somministrata
Frequenza di
freqSomm VARCHAR
somministrazione
Stato di somministrazione
stato VARCHAR
nella terapia
Nuova Dose
doseNew VARCHAR
somministrata
Nuova frequenza di
freqSommNew VARCHAR
somministrazione
Altra nuova frequenza di
freqSommAltro VARCHAR
somministrazione
Identificativo del tipo di
nScheda VARCHAR
scheda follow-up 3,6,9,12
Numero progressivo
idProg VARCHAR che indica l'ordine
nella lista dei farmaci
111
Codice Identificativo di
typeFarm VARCHAR
una tipologia di farmaco
Tabella 50
schedareclutamento
Id Primaria INT
una scheda reclutamento
IdPaziente VARCHAR
un paziente
Data di arruolamento del
DataRecl VARCHAR
paziente nello studio
Centro VARCHAR Codice univoco del centro
Data della prima diagnosi
DataPrimaAR VARCHAR
di AR
DataUltimoAR VARCHAR Data ultimo controllo AR
Flag per lattivazione
dellinserimento di
CoinvExtraMusc VARCHAR ulteriori dati sul
coinvolgimento
extrarticolare
Tipo di coinvolgimento
TipoCoinvExMusc VARCHAR
extrarticolare
Flag per lattivazione
dellinserimento di
Comorbilita VARCHAR
ulteriori dati su
comorbilit rilevanti
112
Tipo di comorbilit
TipoComorbilita VARCHAR
rilevanti
fansFar() VARCHAR FANS e Analgesici
cortFar() VARCHAR Corticosteroidi

Trattamento
dmardFar() VARCHAR precedente con
DMARDs
Farmaco modificante
brmFar() VARCHAR
la risposta biologica
Trattamento attuale
dmardAtt() VARCHAR
con DMARDs
FANS e Analgesici
fansAtt() VARCHAR
attuali
cortAtt() VARCHAR Corticosteroidi Attuali
idSchedaRilCosti() INT una scheda di
rilevamento costi
Minuti durata rigidit
RigMatt VARCHAR
mattutina
Num. Totale Articolazioni
NumArtDol VARCHAR Dolenti (Questionario
Valutazione Medico)
Num. Totale Articolazioni
NumArtTum VARCHAR Tumefatte (Questionario
Valutazione Medico)
113
Punteggio del grado di
attivit della artrite su
VASMed VARCHAR analogica visiva del
dolore (VAS) espresso
dal medico
Punteggio del grado di
attivit della artrite
VASPaz VARCHAR espresso dal paziente
su scala visu-
analogica
VARCHAR Punteggio del grado
del dolore espresso
VASDol
dal paziente su scala
visu-analogica
VARCHAR Punteggio dello stato di
salute complessivo su
GH
scala visu-analogica
espresso dal paziente
VARCHAR Misura della velocit di
VES eritrosedimentazione
(VES)
VARCHAR Punteggio del calcolo del
DAS28
DAS28
PCR VARCHAR Livello di PCR
VARCHAR Flag presenza del

FattReum
fattore reumatoide
VARCHAR Valore del fattore
FattReuVal
reumatoide
114
VARCHAR Valore degli anticorpi
AntiCCP
Anti-CCP
Anticorpi
antinucleo
AntiDNA
anti-DNA
VARCHAR Indicatore del livello di
AST
transaminasi AST
VARCHAR Indicatore del livello di
ALT
transaminasi ALT
VARCHAR Punteggio del calcolo
HAQ
dellindice HAQ
VARCHAR Punteggio del calcolo per
SF36ISF lindice ISF del
questionario SF36
VARCHAR Punteggio del calcolo per
SF36ISM lindice ISM del
questionario SF36
flagCompleto() VARCHAR Flag di scheda completa
VARCHAR Flag di scheda

flagCompletoCosti() rilevamento costi
completata
VARCHAR Flag di paziente
flagDelete
cancellato
VARCHAR Altri farmaci
fansFarAltro()
FANS e Analgesici
cortFarAltro() VARCHAR Altri Corticosteroidi
115
VARCHAR Altri trattamenti
brmFarAltro()
precedenti con DMARD
VARCHAR Altri trattamenti attuali
dmardAttFarAltro()
con DMARDs
Tabella 51
SchedaAttivitaAR
una scheda di attivit AR
Id Primaria INT
per tutte le schede
Follow-UP
IdPaziente
paziente
RigMatt VARCHAR =schedareclutamento
NumArtDol INT =schedareclutamento
NumArtTum INT =schedareclutamento
VASDol VARCHAR =schedareclutamento
VASPaz VARCHAR =schedareclutamento
VASMed VARCHAR =schedareclutamento
VES VARCHAR =schedareclutamento
DAS28 FLOAT =schedareclutamento
PCR VARCHAR =schedareclutamento
FattReum VARCHAR =schedareclutamento
HAQ VARCHAR =schedareclutamento
SF36ISF VARCHAR =schedareclutamento
116
Anticorpi VARCHAR =schedareclutamento
AST VARCHAR =schedareclutamento
ALT VARCHAR =schedareclutamento
GH VARCHAR =schedareclutamento
VARCHAR Motivazioni di cambio

mot()
terapia
VARCHAR Tipo alterazioni parametri
tipoMot()
laboratoristici
dataMot() VARCHAR Data alterazioni
valoreMot() VARCHAR Valore delle alterazioni
VARCHAR Codice identificativo

farm()
farmaco
dataVisita VARCHAR Data Visita Follow-Up
fattReuVal VARCHAR =schedareclutamento
antiCCP VARCHAR =schedareclutamento
antiDNA VARCHAR =schedareclutamento
SF36ISM VARCHAR =schedareclutamento
farmAltro() VARCHAR =schedareclutamento
VARCHAR Farmaco modificante

brm()
la risposta biologica
VARCHAR Trattamento con
dmard()
DMARDs
fans() VARCHAR FANS e Analgesici
corti() VARCHAR Corticosteroidi

Tabella 52
117
SchedaRilevamentoCosti
idSchedaRilCosti Primaria INT una scheda di
rilevamento costi
VARCHAR Codice univoco di un
IdPaziente
paziente
VARCHAR Codice progressivo
univoco che identifica una
codiceScheda
scheda rilevamento costi
di 3/6/9/12
VARCHAR FLAG attivazione
ospedalizzazioni
ospedalizzazioni
VARCHAR Numero di
numOsped
ospedalizzazioni
centro VARCHAR Codice univoco del centro
VARCHAR Motivo di
mot()
ospedalizzazione
tipoOspe() VARCHAR Tipo di ospedalizzazione
VARCHAR Numero giorni di

ngiorni()
ospedalizzazione
VARCHAR Flag di attivazione
visite
visite/prestazioni/esami
numVis VARCHAR Numero totale di visite
VARCHAR Descrizione delle

vis()
118
VARCHAR Tipo
tipoVis()
VARCHAR Costo in euro di
spesa()
VARCHAR Situazione lavorativa del
lavoro
paziente
lavoroAltro VARCHAR Altro tipo di lavoro
VARCHAR Ente lavorativo (Pubblico

enteLav
o Privato)
VARCHAR Ore lavorative (Part o Full
nOreLav
time)
VARCHAR Numero di ore lavorative
tempLav
part-time
pensione VARCHAR Flag Attivazione Pensione
VARCHAR Situazione lavorativa negli

sitAttLav
utlimi 3 mesi
VARCHAR Data di
quando cambio\trovato\perso
lavoro
VARCHAR Situazione lavorativa
sitPreLav
precedente
sitPreLavAltro VARCHAR Altro lavoro precedente

camSitLav cambiamento situazione
lavorativa
VARCHAR Assenza o sospensione
assLav
lavorativa
119
VARCHAR Numero di assenze
numAss
lavorative
VARCHAR Situazione lavorativa del
lavoroCar
Caregiver
VARCHAR Altro tipo di lavoro del
lavoroAltroCar
Caregiver
VARCHAR Ente lavorativo (Pubblico
enteLavCar
o Privato) del Caregiver
VARCHAR Ore lavorative (Part o Full
nOreLavCar
time)
VARCHAR Numero di ore lavorative
tempLavCar
part-time
VARCHAR Flag Attivazione Pensione
pensioneCar
Caregiver
VARCHAR Situazione lavorativa negli
sitAttLavCar
utlimi 3 mesi Caregiver
VARCHAR Data di
quandoCar cambio\trovato\perso
lavoro per il Caregiver
VARCHAR Situazione lavorativa
sitPreLavCar
precedente del Caregiver
VARCHAR Altra situazione lavorativa
sitPreLavAltroCar
precedente del Caregiver
camSitLavCar cambiamento situazione
lavorativa Caregiver
VARCHAR Assenza o sospensione
assLavCar
lavorativa Caregiver
120
VARCHAR Numero di assenze
numAssCar
lavorative Caregiver
assistito VARCHAR FLAG presenza Caregiver
VARCHAR Specifica della figura del

assistente
Caregiver
assistenteAltro VARCHAR Altra figura del Caregiver
VARCHAR Luogo di spostamento del

spostamento()
Caregiver
motivo() VARCHAR Motivo dello spostamento
VARCHAR Mezzo di trasporto

mezzo()
(Pubblico o Privato)
distanza() VARCHAR Distanza percorsa
spesaSpo() VARCHAR Spesa per lo spostamento

Tabella 53
allegato1
un questionario per il
idAllegato1 Primaria INT
calcolo della Valutazione
da parte del Medico
VARCHAR Codice univoco di un
idPaziente
paziente
VARCHAR Identificativo del tipo di
nScheda
scapoloOmerale() VARCHAR Scapolo omerale dolente
gomito() VARCHAR Gomito dolente
121
polso() VARCHAR Polso dolente
ginocchio() VARCHAR Ginocchio dolente
VARCHAR Metacarpo-falangee
met()
dolenti
VARCHAR Interfalengee prissimali
int()
dolenti
VARCHAR Scapolo omerale
TumScapOme()
tumeffatto
TumGomito() VARCHAR Gomito tumeffatto
TumPolso() VARCHAR Polso tumeffatto
TumGinocchio() VARCHAR Ginocchio tumeffatto
VARCHAR Metacarpo-falangee
TumMet()
tumetaffi
VARCHAR Interfalengee prissimali
TumIntPri()
tumefatte
TotDol() VARCHAR Totale articolazioni dolenti
VARCHAR Totale articolazioni

TotTum()
tumefatte
Tabella 54
allegato2
idAllegato2 Primaria INT un scheda per il calcolo
dellIndice HAQ
idPaziente VARCHAR
paziente
122
nScheda VARCHAR
Dom() VARCHAR Valore del dolore
Punteggio totale
PuntTot VARCHAR
dellindice HAQ
Tabella 55
allegato3
idAllegato3 Primaria INT una scheda per il calcolo
del questionario SF36
idPaziente VARCHAR
paziente
nScheda VARCHAR
Dom() VARCHAR Risposte al questionario
Tabella 56
123
Capitolo 4:
Analisi delle tecnologie impiegate
Dopo aver studiato il dominio applicativo del sistema, le

problematiche ad esso connesse, aver individuato requisiti e
vincoli da soddisfare e infine modellato i dati e le funzionalit
previste per lo sviluppo del sistema approfondiremo in questo
capitolo le tecnologie utilizzate.
Il sistema Dose Web stato realizzato sfruttando il
framework opensource Apache Struts, per la realizzazione
dellapplicazione web su piattaforma J2EE, e il framework
opensource Hibernate come soluzione Object-relational mapping
(ORM) per la persistenza dei dati e per mappare il database
relazionale MySql.
La scelta di creare unapplicazione web usando un
framework quale Struts stata incentivata dalle potenzialit,
dalla facilit duso e dalle caratteristiche di questo valido frame
work, come ad esempio:
la portabilit dell'applicazione che rende pi semplice la
messa in opera;
la semplificazione nella comprensione e manutenibilit del
codice da parte di altri sviluppatori, in quanto sar molto
pi semplice sapere dove si trovano le classi, gli archivi Jar
(Java ARchive) e le altre componenti dell'applicazione
stessa;
sar possibile racchiudere l'intera applicazione in un
archivio WAR (Web Archives Repository), rendendone
124
semplice l'installazione su tutti i servlet container conformi
alle specifiche Sun;
i diversi ruoli dell'applicazione sono affidati a diversi
componenti. Ci consente di sviluppare codice modulare e
pi facilmente riutilizzabile;
possibile sviluppare in parallelo le varie parti
dell'applicazione, view (JSP/HTML) e logica di business
(Java) sfruttando al meglio le conoscenze dei componenti
del team di sviluppo permettendo di impiegare sviluppatori
meno esperti e anche con poche conoscenze di Java per la
realizzazione delle view, lasciando agli sviluppatori Java pi
esperti il compito di concentrarsi sulla realizzazione della
business logic.
125
4.1 Larchitettura J2EE (Java 2 Enterprise Edition)
Larchitettura proposta dalla piattaforma J2EE divide le

applicazioni enterprise in tre strati applicativi fondamentali:
componenti, contenitori e connettori.
Figura 32: Architettura J2EE
Componenti:
Il modello di programmazione prevede lo sviluppo di
soluzioni utilizzando componenti a supporto delle quali fornisce
quattro tecnologie fondamentali:
Enterprise Java Beans;
Servelet ;
Java Server Pages ;
Applet
La prima delle tre denotata con EJB fornisce supporto per

la creazione di componenti server-side che possono essere
generate indipendentemente da uno specifico database, da uno
specifico transaction server o dalla piattaforma su cui gireranno.
126
La seconda, servlet, consente la costruzione di servizi web
altamente performanti ed in grado di funzionare sulla maggior
parte dei web server ad oggi sul mercato.
La terza, JavaServer Pages o JSP, permette di costruire

pagine web dai contenuti dinamici utilizzando tutta la potenza del
linguaggio java.
Le applet, anche se sono componenti client-side

rappresentano comunque tecnologie appartenenti allo strato
delle componenti.
Contenitori:
Il secondo strato rappresentato dai contenitori ovvero
supporti alle tecnologie appartenenti al primo strato logico della
architettura. La possibilit di costruire contenitori rappresenta la
caratteristica fondamentale del sistema in quanto fornisce
ambienti scalari con alte performance.
Connettori:
Infine i connettori consentono alle soluzioni basate sulla
tecnologia J2EE di preservare e proteggere investimenti in
tecnologie gi esistenti fornendo uno strato di connessione verso
applicazioni-server o middleware di varia natura: dai database
relazionali con JDBC (Java DataBase Connectivity) fino ai server
LDAP (Lightweight Directory Access Protocol) con JNDI (Java
Naming and Directory Interface).
127
Gli application-server compatibili con questa tecnologia
riuniscono tutti e tre gli strati in un una unica piattaforma
standard e quindi indipendente dal codice proprietario,
consentendo lo sviluppo di componenti in grado di girare in
qualunque container compatibile con J2EE indipendentemente
dal fornitore di software, e di interagire con una vasta gamma di
servizi pre-esistenti tramite i connettori.
Un ultima considerazione, va fatta sul modello di approccio

al problem-solving: la suddivisione netta che la soluzione
introduce tra logiche di business, logiche di client, e logiche di
presentazione consente un approccio per strati (tier) al
problema, garantendo ordine nella progettazione e nello sviluppo
di una soluzione, fornendo una separazione delle responsabilit,
il riuso dei componenti, una migliore scalabilit, e molti altri
aspetti vantaggiosi.
Uno schema degli strati funzionali di un applicazione web

mostrato nella figura seguente:
Figura 33: Architettura three-tier
128
4.2 I tre strati della piattaforma J2EE:
1) Strato Client (Client Tier): fornisce linterfaccia Utente;

2) Strato Intermedio (Middle Tier): Composto da uno o pi
middle-tier per erogare servizi e la business logic al client;
3) Strato EIS (Enterprise Information System Tier): fornisce i
dati.
Figura 34: Architettura J2EE three-tier
Lo Strato Client
Appartengono allo strato client le applicazioni che
forniscono allutente una interfaccia semplificata verso il mondo
enterprise e rappresentano quindi la percezione che lutente ha
della applicazione J2EE.
Tali applicazioni si suddividono in due classi di
appartenenza: le applicazioni web-based e le applicazioni non-
web-based.
129
Le prime sono quelle applicazioni che utilizzano il browser
come strato di supporto alla interfaccia verso lutente ed i cui
contenuti vengono generati dinamicamente da Servlet e Java
Server Pages o staticamente in HTML.
Le seconde (non-web-based) sono invece tutte quelle
basate su applicazioni stand alone che sfruttano lo strato di rete
disponibile sul client per interfacciarsi direttamente con la
applicazione J2EE senza passare per ilWeb-Tier.
Nel caso di Struts, e nello specifico di Dose Web, il tipo di
client il browser web.
Lo Strato Web
Lo strato web consente allo strato client di comunicare e
interagire con la logica dellapplicazione, la quale risiede su altri
strati. In web applications tradizionali, non raro che parte della
logica sia presente in questo strato, ma in applicazioni di scala
pi ampia, a livello enterprise, il web tier agisce come
traduttore effettuando un mapping delle richieste HTTP verso
invocazioni di servizi sullo strato successivo, ilmiddle tier.
Il web tier il collante che lega le applicazioni client al
nucleo fondamentale di sistemi business. I componenti che
risiedono nello strato web consentono agli sviluppatori di
estendere le funzionalit fondamentali di un web service. Nel
caso di Struts, ci avviene tramite coponenti dellinfrastruttura
che vanno in esecuzione allinterno di un servlet container.
Lo strato business
Nellambito di una applicazione enterprise, questo lo
strato che fornisce servizi specifici: gestione delle transazioni,
controllo della concorrenza, gestione della sicurezza, ed
130
implementa inoltre logiche specifiche circoscritte allambito
applicativo ed alla manipolazione dei dati. Mediante un
approccio di tipo Object Oriented possibile decomporre tali
logiche o logiche di business in un insieme di componenti ed
elementi chiamati business object. La tecnologia fornita da
Sun per implementare i business object quella che in
precedenza abbiamo indicato come EJBs(Enterprise Java Beans).
Tali componenti si occupano di:
Ricevere dati da un client, processare tali dati (se
necessario), inviare i dati allo strato EIS per la loro
memorizzazione su base dati;
Acquisire dati da un database appartenente allo strato EIS,
processare tali dati (se necessario), inviare tali dati al
programma client che ne abbia fatto richiesta.
Lo strato EIS (Enterprise Information System)

Le applicazioni enterprise implicano per definizione
laccesso ad altre applicazioni, dati o servizi sparsi allinterno
delle infrastrutture informatiche del fornitore di servizi. Le
informazioni gestite ed i dati contenuti allinterno di tali
infrastrutture rappresentano la ricchezza del fornitore, e come
tale vanno trattati con estrema cura garantendone la integrit.
Il business tier comunica con i componenti presenti nello
strato EIS utilizzando protocolli specifici per la risorsa. Per
esempio, per comunicare con un database relazionale
normalmente utilizzer un driver JDBC.
131
4.2.1 Struts e il Web Tier
Allinterno di questo scenario appena descritto,

linfrastruttura di Struts si nel del web tier. Le applicazioni Struts
sono ospitate da un web container e possono far uso di servizi
forniti dal container stesso, quali la gestione delle richieste
tramite i protocolli HTTP e HTTPS. Questo d agli sviluppatori la
libert di concentrarsi sulla realizzazione della logica di business
che risolve i problemi reali della loro applicazione, costituendo il
valore aggiunto delle web applications Struts.
Allinterno dello strato web, il web-server gioca un ruolo
fondamentale. In ascolto su un server, riceve richieste da parte
del browser (client), le processa, quindi restituisce al client una
entit o un eventuale codice di errore come prodotto della
richiesta.
Le entit prodotte da un web-server possono essere entit
statiche o entit dinamiche. Quello che pi ci interessa sono
invece le entit dinamiche, ossia entit prodotte dalla esecuzione
di applicazioni eseguite dal web-server su richiesta del client.
Il modello statico del web-server ora si complica
maggiormente in quanto viene introdotto un nuovo grado di
complessit nella architettura del sistema che, oltre a fornire
accesso a risorse statiche dovr fornire un modo per accedere a
contenuti e dati memorizzati su una Base Dati, con i quali un
utente internet potr interagire da remoto.
132
4.2.2 Java Servlet e Java Server Pages
Le servlet sono oggetti java utilizzati per creare contenuto

dinamico per il web. Le servlet non vengono eseguite
direttamente da un web server, ma hanno necessit di un loro
contenitore, detto servlet-container come ad esempio Apache
Tomcat. Nel corso degli anni le servlets sono diventate la
tecnologia migliore per utilizzare il web dinamico di Java.
Figura 35: Web Container
Sono in grado sfruttare lintera serie delle API Java

(application programming interfaces) tra cui JDBC (Java
DataBase Connectivity) e EJB.
Una servlet viene mappata a uno o pi URL (Uniform
Resource Locator) e, quando il server riceve una richiesta ad uno
degli url della servlet, viene invocato il metodo di servizio nella
servlet che risponde. Il package di base delle Servlet API
javax.servlet e contiene le classi per definire Servlet standard
indipendenti dal protocollo. Tecnicamente una Servlet generica
una classe definita a partire dallinterfaccia Servlet contenuta
allinterno del package javax.servlet. Questa interfaccia contiene
i prototipi di tutti i metodi necessari alla esecuzione delle logiche
di business, nonch alla gestione del ciclo di vita delloggetto dal
133
momento del suo istanziamento, sino al momento della sua
terminazione.
Nel contesto della piattaforma Java, la tecnologia JSP
correlata con quella dei servlet. All'atto della prima invocazione,
le pagine JSP vengono infatti tradotte automaticamente da un
compilatore JSP in servlet. Una pagina JSP pu quindi essere
vista come una rappresentazione ad alto livello di un servlet. Per
via di questa dipendenza concettuale, anche l'uso della
tecnologia JSP richiede la presenza, sul Web server, di un servlet
container, oltre che di un server specifico JSP detto motore JSP
(che include il compilatore JSP); in genere, servlet container e
motore JSP sono integrati in un unico prodotto come ad esempio
Apache Tomcat che svolge entrambe le funzioni.
La JSP Si basa su un insieme di speciali tag con cui

possono essere invocate funzioni predefinite o codice Java (JSTL
- JavaServer Pages Standard Tag Library). In aggiunta,
permette di creare librerie di nuovi tag che estendono l'insieme
dei tag standard (JSP Custom Tag Library). Le librerie di tag JSP
si possono considerare estensioni indipendenti dalla piattaforma
delle funzionalit di un Web server.
134
4.3 Utilizzare un framework
Un framework una architettura generica che costituisce

linfrastruttura per lo sviluppo di applicazioni in una determinata
area tecnologica, nel caso di Struts, si tratta del mondo delle
web-application. In parole povere, un framework un insieme
di classi ed interfacce di base, a disposizione del programmatore,
che costituiscono linfrastruttura di una applicazione. Non
bisogna per pensare, che usare un framework, equivalga
quindi, ad usare una libreria di classi, quali ad esempio le classi
di base del linguaggio Java. Usare una libreria, vuol dire avere a
disposizione dei metodi e delle funzionalit, ma resta a nostro
carico, il compito di controllare il flusso applicativo.
Adottare un framework, invece, vuol dire attenersi ad una
specifica architettura, in cui saranno i componenti del framewrok
ad occuparsi del flusso applicativo ed il programmatore avr solo
il compito di estendere le classi del framewrok e/o
implementarne delle interfacce.
Da un punto di vista pratico significa senz'altro ridurre i
tempi di un progetto ed evitare errori nella fase di disegno in
quanto si utilizza una infrastruttura realizzata secondo le best-
practises dell'ambito tecnologico di riferimento.
E' bene precisare che un framework non va confuso con un
design-pattern. Un design-pattern una strategia di soluzione di
un problema comune, qualcosa di concettuale che prescinde
dall'implementazione tecnologica.
135
4.4 Design Patterns in J2EE
Mentre la piattaforma J2EE continua a evolvere,

lesperienza in applicazioni reali e le conoscenze acquisite dai
migliori sviluppatori J2EE sono state distillate e catturate nei
cosiddetti BluePrint Enterprise di Sun. I BluePrint Enterprise sono
suggerimenti, configurazioni, best practice e codice che possono
essere utilizzati per garantire che le applicazioni J2EE sviluppate
siano progettate e implementate nel migliore dei modi.
Il risultato il cosiddetto J2EE Pattern Catalog, che
raggruppa i diversi Pattern sostanzialmente in tre categorie:
Presentation Tier, Business Tier, Integration Tier.
Figura 36: Presentation Tier Patterns
136
Figura 37: Business Tier Patterns
Figura 38: Integration Tier Patterns
137
4.4.1 Il pattern MVC (Model - View - Controller)
Uno dei principali requisiti di qualsiasi applicazione web

quello di definire un modello applicativo che consenta di
disaccoppiare i diversi componenti dell'applicazione in base al
loro ruolo nell'architettura per ottenere vantaggi in termini di
riusabilit e manutenibilit. Esempio tipico di questo problema
l'utilizzo nello sviluppo di una applicazione web J2EE di quei
modelli applicativi che nella letteratura sono indicati spesso come
"JSP Model 1" e JSP Model 2, introdotti con le prime specifiche
delle JavaServer Pages.
Nel Model 1 le sole JavaServer Pages consentono di
realizzare applicazioni web dinamiche accedendo a componenti
Java contenenti logiche di business o alla base dati del sistema.
Lapplicazione quindi costruita secondo una logica "JSP centric"
in base alla quale presentation , control e business logic
dell'applicazione sono tutti a carico delle pagine JSP con ovvi
svantaggi quando l'applicazione cresce in complessit.
138
Figura 39: Model 1
Nella figura precedente mostrato molto sinteticamente il

funzionamento del Model 1:
1) Il browser invia una richiesta ad una pagina JSP

2) La pagina JSP comunica con un Java bean
3) Il Java bean connesso ad un database
4) La pagina JSP invia la risposta al browser
Il Model 2, utilizza JavaServer Pages come strumento per

sviluppare template demandando completamente ad una
particolare servlet la processazione dei dati di input.
Nellarchitetture Model 2 la richiesta del client viene
intercettata prima da una servlet, detta controller servlet.
Questa gestisce lelaborazione iniziale della richiesta e determina
quale pagina JSP deve essere visualizzata.
139
Figura 40: Model 2
Nella figura precedente mostrato molto sinteticamente il

funzionamento del Model 2:
1) Il browser invia una richiesta ad una servlet;
2) La servlet istanzia un Java bean connesso ad un
database;
3) La servlet comunica con una pagina JSP
4) La pagina JSP comunica con il Java bean
5) La pagina JSP invia la risposta al browser
Dunque in questa architettura un client non invia mai

direttamente una richiesta a una pagina jsp. Ci permette alla
servlet di effettuare una elaborazione di front-end comprendente
autorizzazione ed autenticazione, logging centralizzato e
internazionalizzazione. Una volta terminata lelaborazione della
richiesta, la servlet dirige la richiesta alla giusta pagina JSP.
Come si vede la differenza principale tra le due architetture la
presenza di questo punto di accesso ai servizi singolo,
rappresentato dalla servlet, il che incoraggia il riutilizzo e la
separazione tra i vari strati dellapplicazione. Proprio per questo
il pattern Model 2 pi conosciuto come pattern MVC (Model-
140
View-Controller) Secondo questo pattern, i componenti di
un'applicazione vengono logicamente classificati a seconda che
siano gestori di logiche di business e di accesso ai dati (model),
gestori di visualizzazione dati e dell'input dell'utente (viewer o
view) e gestori del flusso di controllo complessivo
dell'applicazione (controller).
Laccoppiamento tra i vari livelli minimo, con evidenti
vantaggi in termini di riusabilit, manutenibilit, estensibilit e
modularit.
Di seguito presentato un diagramma di interazione che
evidenza le responsabilit dei tre componenti:
Figura 41: Il pattern MVC
Il Model:
Analizzando la figura precedente, si evince che il core
dell'applicazione viene implementato dal Model, che incapsulando
lo stato dell'applicazione definisce i dati e le operazioni che
possono essere eseguite su questi. Quindi definisce le regole di
business per l'interazione con i dati, esponendo alla View ed al
Controller rispettivamente le funzionalit per l'accesso e
141
l'aggiornamento. Per lo sviluppo del Model quindi vivamente
consigliato utilizzare le tipiche tecniche di progettazione object
oriented al fine di ottenere un componente software che
astragga al meglio concetti importati dal mondo reale. Il Model
pu inoltre avere la responsabilit di notificare ai componenti
della View eventuali aggiornamenti verificatisi in seguito a
richieste del Controller, al fine di permettere alle View di
presentare agli occhi degli utenti dati sempre aggiornati.
La View:
La logica di presentazione dei dati viene gestita solo e
solamente dalla View. Ci implica che questa deve
fondamentalmente gestire la costruzione dell' interfaccia grafica
(GUI) che rappresenta il mezzo mediante il quale gli utenti
interagiranno con il sistema. Ogni GUI pu essere costituita da
schermate diverse che presentano pi modi di interagire con i
dati dell'applicazione.
Inoltre la View delega al Controller l'esecuzione dei
processi richiesti dall'utente dopo averne catturato gli input e la
scelta delle eventuali schermate da presentare.
Il Controller:
Definisce il meccanismo mediante il quale il Model e la
View comunicano. Realizza la connessione logica tra linterazione
dellutente con linterfaccia applicativa e i servizi della business-
logic nel back end del sistema. E responsabile della scelta di
una tra molteplici viste dello stesso modello, in base al tipo di
dispositivo utilizzato dallutente per accedere al sistema ma
anche in realzione alla localizzazione geografica dellutente
142
stesso. Una qualsiasi richiesta (request) fatta al sistema viene
acquisita dal Controller che individua allinterno del Model il
gestore della richiesta (request handler). Ottenuto il risultato
dellelaborazione (response), il Controller stesso determina a
quale View passare i dati per la presentazione degli stessi
allutente.
143
4.4.2 Struts e il pattern MVC
Come gi detto Struts un framework per la realizzazione

di web application che aderisce a pieno al pattern MVC.
Si basa fortemente sugli strumenti che costituiscono
principalmente unapplicazione Web realizzata in Java: le pagine
JSP e le Servlet. Infatti, il flusso di esecuzione allinterno di
ciascuna Web application gestito attraverso una Servlet, in
esecuzione nel Web Container.
La semplicit di configurazione della Web application da
realizzare garantita dalla presenza di un file XML (strut-
config.xml), nel quale vengono impostati tutti i parametri e gli
elementi costitutivi dellapplicazione stessa. Questo file XML
viene letto in fase di start-up dell'applicazione dalla ActionServlet
e definisce le associazioni tra i vari elementi di Struts. Nello
struts-config.xml sono ad esempio definite le associazioni tra i
path delle richieste http e le classi Action che hanno il compito di
elaborare le singole richieste. Le associazioni tra le Action e gli
ActionForm, che vengono automaticamente popolati dal
framework con i dati della richiesta ad essi associata e passati in
input alla Action. Contiene inoltre l'associazione tra la Action e le
ActionForward, ovvero i path configurati nello struts-config.xml
ai quali la ActionServlet rediriger il flusso applicativo al termine
della elaborazione della Action.
Un altro importante componente del framework il file

web.xml. Rappresenta il descrittore di deploy della web-
application, trasmette le informazioni di configurazione tra chi
sviluppa lapplicazione, chi ne effettua il deploy e chi lassembla.
144
Questo file descritto in dettaglio nelle specifiche delle
Servlet Java, essendo un file di configurazione necessario per
tutte le web application, non solo per quelle realizzate con il
framework Struts. I web container utilizzano il descrittore per
caricare e configurare la web-application quando questo viene
avviato.Il file viene letto allavvio del Web container e specifica
dove si trova la nostra applicazione e come deve essere
eseguita, in altre parole il file specifica ogni richiesta dove deve
andare.
Tutti gli elementi che costituiscono il framework sono
raggruppati in otto principali Package Top-Level:
Figura 42: Gli otto package Top-Level di struts
Action: contiene le classi del controller, la ActionForm,

la ActionMessages, e diversi componenti necessari per il
framework;
145
Actions: contiene le classi Action rimanenti, quali la
DispatchAction, che pu essere utilizzata o estesa dalla
propria applicazione;
Config: include le classi di configurazione che sono
rappresentazioni presenti in memoria del file di
configurazione di Struts;
Taglib: contiene le classi tag handler per le tag library di
Struts;
Tiles: contiene le classi usate dal framework Tiles;
Upload: include classi utilizzate per lupload e il
download del file dalfilesystem locale con un browser;
Util: contiene classi di utilit generale utilizzate
dallintero framework;
Validation: contiene le classi di estensione, specifiche
per Struts, utilizzate dal framework quando si effettua il
deploy del validation. Le classi e le interfacce vere e
proprie di Validation si trovano nel package commons,
che separato da Struts.
Nella figura seguente rappresentato schematicamente il

flusso elaborativo nella logica di Struts. Per semplicit il flusso di
operazioni elencato non completo ma fornisce una indicazione
di base su come viene gestito il flusso elaborativo in una
applicazione sviluppata con Struts.
146
Figura 43: Flusso elaborativo di una applicazione sviluppata con struts
1) Il client invia una richiesta http (1);

2) La richiesta viene ricevuta dalla servlet di Struts che provvede
a popolare l'ActionForm associato alla richiesta con i dati della
request (2) e l'ActionMapping con gli oggetti relativi alla Action
associata alla richiesta (4). Tutti i dati di configurazione sono
stati letti in fase di start-up dell'applicazione (0) dal file XML
struts-config.xml;
3) La ActionServlet delega l'elaborazione della richiesta alla
Action associata al path della richiesta (3) passandole in input
request e response http e l'ActionForm e l'ActionMapping
precedentemente valorizzati;
4) La Action si interfaccia con lo strato di business che
implementa la logica applicativa. Al termine dell'elaborazione
restituisce alla ActionServlet un ActionForward (6) contenente
l'informazione del path della vista da fornire all'utente;
5) La ActionServlet esegue il forward alla vista specificata
nell'ActionForward (7).
147
4.5 Hibernate
Hibernate uno strumento di mappaggio tra oggetti e

relazioni per gli ambienti basati su Java. Il termine mappaggio
oggetto-relazione (object relational mapping o ORM) si
riferisce alla tecnica di creare una corrispondenza tra una
rappresentazione di dati secondo il modello a oggetti ed quella
secondo il modello relazionale, con uno schema basato su SQL.
Hibernate si occupa non solo del mappaggio dalle classi
Java alle tabelle della base di dati (e dai tipi di dato Java a quelli
SQL), ma fornisce anche funzionalit di interrogazione e
recupero dei dati, e pu ridurre significativamente i tempi di
sviluppo altrimenti impiegati in attivit manuali di gestione dei
dati in SQL e JDBC.
Lo scopo di Hibernate di alleviare lo sviluppatore dai pi
comuni compiti di programmazione legati alla persistenza dei
dati.
Una visione (molto) di alto livello sull'architettura di
Hibernate:
Figura 44: Architettura Hibernate
148
L'architettura di Hibernate, permette all'applicazione di
astrarre dai dettagli delle API JDBC/JTA e lascia che se ne occupi
Hibernate.
Nella figura seguente rappresentata lArchitettura
completa:
Figura 45: Architettura completa Hibernate
Descriveremo qui di seguito alcuni oggetti presenti nei

diagrammi precedenti:
SessionFactory (net.sf.hibernate.SessionFactory):
una cache immutabile e "thread-safe" di mappaggi
compilati per un database singolo. Allo stesso tempo un
factory per oggetti Session e un client di
ConnectionProvider. Potrebbe contenere una cache di
secondo livello opzionale riutilizzabile tra le transazioni, sia
a livello di processo, sia a livello di cluster.
Session (net.sf.hibernate.Session): un oggetto

mono-thread, di corta durata, che rappresenta una
149
conversazione tra l'applicazione e il contenitore
persistente. Incapsula una connessione JDBC. un factory
per oggetti Transaction. Mantiene una cache obbligatoria
(di primo livello) per gli oggetti persistenti, usata quando si
naviga il grafo degli oggetti o si ricercano oggetti per
identificatore.
Oggetti persistenti e collezioni: Sono oggetti di corta

durata, a thread singolo, che contengono stato persistente
e funzioni applicative. Potrebbero essere normali oggetti
POJO/Javabeans, con l'unica particolarit che in un dato
momento sono associati con (esattamente) una Session.
Nel momento in cui la Session viene chiusa, verranno
staccati e saranno liberi di essere usati in qualsiasi strato
applicativo (ad esempio direttamente come oggetti di
trasferimento dei dati da e allo strato di presentazione).
Oggetti transienti e collezioni: Sono le istanze delle

classi persistenti che in un dato momento non sono
associate con una Session. Possono essere state istanziate
dall'applicazione e non (ancora) rese persistenti, o possono
essere state istanziate da una Session poi chiusa.
Transaction (net.sf.hibernate.Transaction): un
oggetto a thread singolo, di corta durata, usato
dall'applicazione per specificare unit di lavoro atomiche.
Separa le applicazioni dalla transazione JTA, CORBA o
JDBC sottostante. Una Session potrebbe estendersi lungo
varie Transaction in certi casi.
150
Connection Provider
(net.sf.hibernate.connection.ConnectionProvider):
Un factory (e pool) di connessioni JDBC. Astrae le
applicazioni dai dettagli dei sottostanti Datasource o
DriverManager. Non viene esposta all'applicazione, ma pu
essere estesa/implementata dagli sviluppatori.
TransactionFactory
(net.sf.hibernate.TransactionFactory): Un factory per
istanze di Transaction. Non viene esposta all'applicazione,
ma pu essere estesa/implementata dagli sviluppatori. In
un'architettura "leggera", l'applicazione aggira le API
Transaction/TransactionFactory e/o ConnectionProvider per
parlare direttamente con JTA o JDBC.
151
4.6 Ambiente di Sviluppo e Deploy
Il gruppo di lavoro ha deciso di utilizzare esclusivamente

applicativi opensource di livello medio-alto con una
documentazione completa ed esaustiva. Quello che stato fatto
unindagine sugli strumenti open source ad oggi disponibili, ma
in questa sezione riportiamo solo gli strumenti che abbiamo
deciso di adottare per lo sviluppo del progettto.
1) Application server: Apache Tomcat lelemento

fondamentale di tutta la piattaforma J2EE: svolge buona parte
del lavoro necessario per rendere un componente utilizzabile dai
vari client remoti, sia per supportare i servizi pi importanti
(transazioni, mantenimento dello stato, sessioni, sicurezza).
Tomcat un Application Server conforme alle specifiche J2EE,
Open Source e pienamente compatibile con il framework Struts.
Per essere precisi Tomcat un Servlet Container ed un JSP
Engine. Un motore quindi in grado di eseguire lato server
applicazioni web basate su architetture J2EE e costituite da
componenti Servlet e da pagine JSP.
2) IDE (Integrated development environment): Netbeans

IDE un ambiente di sviluppo multi-linguaggio scritto
interamente in Java, scelto dalla Sun Microsystems come IDE
ufficiale, da contrapporre al pi diffuso Eclipse. Si tratta di un
tool orientato alla massima espansibilit tramite il meccanismo
dei plug-in, infatti la stessa piattaforma su cui si basa costituita
da un aggregato di moduli di espansione. I plug-in sono delle
152
componenti software ideate per uno specifico scopo, per esempio
la generazione di diagrammi UML.
Nella versione base possibile programmare in Java,
usufruendo di comode funzioni di aiuto quali: completamento
automatico, suggerimento dei tipi di parametri dei metodi,
riscrittura automatica del codice in caso di cambiamenti nelle
classi.
Essendo scritto in Java, Netbeans IDE disponibile per
tutte le piattaforme. La licenza di riferimento per Netbeans IDE
la Common Development and Distribution License (CDDL),
licenza open source sviluppata da Sun Microsystems che
permette l'utilizzo del codice sorgente come base per la
creazione di altri programmi anche proprietari, richiedendo solo il
rilascio delle modifiche del codice sotto licenza CDDL.
Con oltre 5 milioni di download di NetBeans IDE sino ad
oggi, e oltre 100,000 sviluppatori che partecipano, il progetto
netbeans.org fiorente. Ogni mese contribuiscono ed usano
NetBeans visitatori di oltre 130 diversi paesi.
3) DBMS: MySQL un database management system

relazionale, composto da un client con interfaccia a caratteri e un
server, entrambi disponibili sia per sistemi Unix come GNU/Linux
che per Windows, anche se prevale un suo utilizzo in ambito
Unix. Dal 1996 supporta la maggior parte della sintassi SQL e si
prevede in futuro il pieno rispetto dello standard ANSI. Possiede
delle interfacce per diversi linguaggi, compreso un driver ODBC,
due driver Java e un driver per Mono e .NET.
Dalla versione 5.0, resa disponibile come stabile il 24
ottobre 2005, MySql introduce nuove funzionalit che vanno ad
153
accorciare (non ancora completamente) la distanza tra questo
DBMS e i grandi concorrenti quali IBM DB2, Oracle, Microsoft
SQL Server e Sybase ma soprattutto permettono a MySql di
competere sul piano delle caratteristiche avanzate come i
triggers, le viste, le stored procedures, i cursori.
154
Capitolo 5: Manuale dUso
5.1 Interfaccia
Il sistema DOSE Web presenta il layout tipico di un sito

web con menu fisso di navigazione sulla parte sinistra, mentre il
resto della pagina permette la visualizzazione dei contenuti e
delle CRF. Il design dellinterfaccia si presenta sobrio e pulito e
quindi di semplice consultazione ed utilizzo.
Figura 46: Dose Web Home
155
5.2 Pulsanti
Il menu di navigazione laterale permette di accedere sia ai

contenuti di consultazione pubblica e sia laccesso alla parte
privata del sistema, ovvero allapplicazione web vera e propria.
Tutti i pulsanti presenti del sistema sono elencati
nella seguente tabella, seguiti da una breve descrizione.
Pulsanti del sistema
Visualizza il calendario per linserimento della

data corrente.
Navigazione tra CRF: Sinistra \ Destra,

Precedente sezione della CRF \ Successiva
sezione della CRF
Apre una finestra di aiuto contenente le

istruzioni per la compilazione delle CRF.
Apre un messaggio di suggerimento per la

compilazione di uno specifico campo
Apre una finestra per la compilazione degli

allegati. (Valutazione Medico, Sf36, HAQ)
Permette luscita dallarea privata del sistema

(Logout)
156
Permette la stampa dellelenco pazienti o CRF
visualizzate
Permette lesportazione dei dati in formato CSV
Permette il download di un documento in

formato DOC
Permette il download di un documento in

formato ODT
Indica che la CRF corrispondente deve essere

ancora compilata, al click apre il form di
compilazione della CRF.
Indica che la CRF corrispondente stata

compilata con successo, al click apre il form con
la CRF completa.
Indica che il paziente stato ritirato dallo studio,

al click apre un messaggio di avvertimento.
Indica che la CRF corrispondente incompleta,

al click apre il form di compilazione della CRF.
Permette la cancellazione di un paziente, al click

apre un messaggio di avvertimento.
Tabella 57
157
5.3 Login e Logout
Per effettuare laccesso con username e password

necessario selezionare lapposita voce nel menu (1) e inserire i
propri dati di autenticazione.
Figura 47: Login
In caso di smarrimento dei propri dati di autenticazione

possibile richiederli cliccando sul link corrispondente (2) che
invier le credenziali alla casella di posta registrata.
Se ancora non si dispone dei dati di autenticazione
possibile ottenerli inviando una mail allindirizzo indicato (3).
Per effetuare il logout dal sistema necessario selezionare
lapposita voce nel menu (5) o selezionare licona corrispondente
(4).
Figura 48: Logout
158
Se lautenticazione si conclusa con successo, nel caso di utente
Medico o Farmacista verr mostrato lElenco Pazienti contenente
tutti e soli i pazienti appartenenti al centro a cui lutente
afferisce. I pazienti sono elencati per Id incrementale (6) con
affianco lo stato delle sue CRF (7).
Figura 49: Elenco Pazienti
Nel caso di utente Referente o Soggetto sponsor verr

mostrato lElenco centri contenente tutti i centri attivi nello
studio DOSE sul territorio nazionale. I centri sono elencati per
Codice centro (8). Per ogni centro sono riportati i totali dei
159
pazienti suddivisi per CRF (9). Nella parte superione
visualizzato il totale dei pazienti di tutti i centri suddivisi per CRF
(10).
Figura 50: Elenco Centri
160
5.4 Gesti one schede:
Inserimento \ Visualizzazione \ Stampa
Dopo lautenticazione del Medico o del Farmacista

possibile inserire un nuovo paziente (Scheda di reclutamento)
selezionando lapposita voce nel men (11).
Figura 51: Nuovo Paziente
Il form per la compilazione della CRF si presenta suddiviso

in pi sottosezioni sfogliabili mediante tab orizzontali (12) o
pulsanti di navigazione (13) verso sinistra \ destra.
Durante la compilazione possibile salvare i dati immessi
in qualsiasi momento premendo il tasto salva (14) o cancellare
linserimento dellintera scheda premendo il tasto cancella (14).
Figura 52: CRF Nuovo Paziente
161
Nellinserimento di determinate schede richiesto di
compilare anche gli allegati indicati con il simbolo (14). Cliccando
sul simbolo si apre unaltra finestra (15) contenente il
questionario da compilare e salvare. Il risultato del questionario
viene calcolato e inserito nella scheda principale (16).
Figura 53: Allegato
162
Per visualizzare una scheda specifica scheda gi compilata
cliccare sullicona (17) nellElenco Pazienti.
Nella seguente figura si scelto ad esempio di visualizzare
la Visita Follow-Up a 3 Mesi del paziente n.32
Figura 54: Visualizza scheda compilata
Figura 55: Scheda compilata
163
Per la stampa una scheda sufficiente cliccare sullicona (18)
allinterno della scheda stessa.
Si aprir unanteprima (19) della scheda in formato A4 che
potr essere stampata su supporto cartaceo o memorizzata
come file PDF (20).
Figura 56: Stampa\PDF
164
5.5 Gestione Pazienti:
Ricerca \ Elenco \ Cancellazione \ Esportazione
E possibile ricercare un paziente compilando il campo codice con

il suo identificativo numerico (22), data di nascita (21) e sesso
(23) mentre il pulsante Cancella (26) pulisce i campi di ricerca
dai caratteri inseriti.
Figura 57: Ricerca
E possibile effettuare la ricerca solo allinterno di un singolo

centro attivo e non su tutti i centri aderenti allo studio, quindi
ogni utente effettuer le ricerche solo e soltanto sul proprio
centro.
E possibile inoltre compilare uno solo dei campi di ricerca per

ottenere particolari risultati: ad esempio per visualizzare tutti i
tutti i pazienti di sesso Femminile selezionare lopzione [F] nel
campo sesso e cliccare su Ricerca (25) per ottenere la lista di
tutte le donne afferenti al centro attivo su cui si sta effettuando
la ricerca.
Dopo la ricerca possibile tornare alla visualizzazione della
lista pazienti completa cliccando sul pulsante Elenca Tutti(24)
165
Per cancellare un paziente cliccare sullicona (28) nella
colonna Elimina Paziente sulla riga del paziente che si vuole
eliminare (27) e confermare loperazione (29).
Figura 58: Elimina Paziente
Per esportare lelenco dei pazienti cliccare sul relativo

pulsante (30) e confermare il download (31) del file in formato
csv.
Figura 59: Esporta
166
5.6 Ottenere documentazione
Per visualizzare tutto il materiale informativo relativo allo

studio Dose come ad esempio le CRF in formato PDF stampabile,
Doc e Odt modificabile selezionare la voce (32) sul men
laterale.
Individuare il nome del documento e cliccare sul formato
richiesto (33), confermare il download del file (34).
Figura 60: Download
167
Conclusioni e Sviluppi futuri
Il presente lavoro di tesi ha descritto in maniera dettagliata

ed approfondita il sistema web elaborato presso i Laboratori
dellIstituto Consorzio Mario Negri Sud come supporto allo
studio D.O.S.E..
In particolare, sono stati esaminati i requisiti, le capacit, i
servizi offerti dal sistema web ed i suoi vincoli. Inoltre, sono
state descritte tutte le funzionalit operative fornite dalle
specifiche entit del sistema mettendo in evidenza le possibili
modalit di utilizzo e le interazioni tra di esso e lambiente
esterno. Le motivazioni che hanno portato alla scelta delle
soluzioni tecnologiche adottate per la realizzazione sono state
chiaramente descritte in termini di potenzialit, facilit di uso e
caratteristiche.
Questo studio dettagliato consente dunque di affermare
che lo sviluppo modulare e i diversi livelli di astrazione del
sistema Dose Web permetteranno di inserire agevolmente ed
efficacemente nuove funzionalit.
E ipotizzabile linserimento di una funzionalit in-line di
analisi statistica dei dati raccolti che renda pi immediata la
supervisione dellandamento dello studio.
In questottica il sistema Dose Web rappresenta un
patrimonio di base che potr essere riutilizzato per nuovi studi
osservazionali ovvero adattare la soluzione sviluppata per
risolvere problemi simili.
168
Glossario e Acronimi
A
Anti-TNF: Farmaco Anti-Tumor Necrosis Factor
Anamnesi: In medicina, l'anamnesi la raccolta dalla voce diretta del
paziente e/o dei suoi familiari (per esempio i genitori nel caso di un
lattante o di un bambino), di tutte quelle informazioni, notizie e
sensazioni che possono aiutare il medico a indirizzarsi verso una
diagnosi.
Anti-CCP: Anticorpi Anti Peptide Ciclico Citrullinato
AR: Artrite Reumatoide
ATC: acronimo di "Anatomical Therapeutic Chemical Classification
System". Sistema di Classificazione Anatomico Terapeutico e Chimico.
Viene usato per la classificazione sistematica dei farmaci ed
controllato dall'Organizzazione Mondiale della Sanit. L'ATC un
sistema di classificazione di tipo alfa-numerico che suddivide i farmaci
in base ad uno schema costituito da 5 livelli gerarchici
Autenticazione: Nel campo della sicurezza informatica il processo
tramite il quale un computer, un software o un utente , verifica la
corretta , o almeno presunta , identit di un altro computer, software o
utente che vuole comunicare attraverso una connessione.
C
Care-giver: letteralmente prestatore di cura, colui che da
assistenza ad una persona malata, pu essere un familiare o un
esterno.
CRF: Case Report Form
CSV: Comma Separated Values un formato di file basato su file di
testo utilizzato per l'importazione ed esportazione (ad esempio da fogli
elettronici o database) di una tabella di dati.
Client: Un computer collegato ad un server tramite una rete
informatica (locale o geografica) ed al quale richiede uno o pi servizi,
utilizzando uno o pi protocolli di rete un esempio di client hardware.
CPU: central processing unit. L'unit centrale di elaborazione di un
calcolatore elettronico, anche chiamata nella sua implementazione
fisica processore, uno dei due componenti principali della macchina di
von Neumann, il modello su cui sono basati la maggior parte dei
moderni computer.
D
DAS: Disease Activity Score (DAS)
E' calcolato secondo la formula:
DAS = 0.54 (RAI) + 0.065 (sw) + 0.33Ln(ESR) + 0.0072GH
dove:
RAI = Indice di Ritchie
SW= Numero di articolazioni tumefatte (44)
Ln(ESR) = Logaritmo naturale della VES (mm/ora)
169
GH = Stato di salute complessivo (scala visuo-analogica).
Il DAS applicabile a:
- valutazione della attivit di malattia in un determinato momento
(Elevata attivit di malattia >3.7, bassa attivit di malattia <2.4,
remissione <1.6),
- valutazione della modificazione nel tempo della attivit di malattia.
DAS28: L. Disease Activity Score 28 (DAS28)
E' calcolato secondo la formula:
DAS28 = 0.56 (t28) + 0.28 (sw28) + 0.70Ln(ESR) +
0.014GH
dove:
t28 = numero di articolazioni dolente su 28
sw28 = numero di articolazioni tumefatte su 28
Ln(ESR) = Logaritmo naturale della VES (mm/ora)
GH = Stato di salute complessivo (scala visuo-analogica)
Il DAS applicabile a:
- valutazione della attivit di malattia in un determinato momento
(Elevata attivit di malattia >5,1, bassa attivit di malattia <3,2,
remissione <2,6),
- valutazione della modificazione nel tempo della attivit di malattia.
DBMS: DataBase Management System sistema software progettato
per consentire la creazione e manipolazione efficiente di database
(ovvero di collezioni di dati strutturati) solitamente da parte di pi
utenti.
DMARDS: Disease Modifying AntiRheumatic Drugs, farmaci
antireumatici modificanti la malattia.
DOC: estensione dei file dei documenti di testo creati con il
programma Microsoft Office Word.
F
FANS: Farmaci antinfiammatori non steroidei. Medicinali che
combattono le infiammazioni e non contengono cortisone.
Follow-UP: visite periodiche di controllo, che hanno come scopo
principale quello di valutare l'evoluzione della malattia in relazione ad
un trattamento a cui il paziente viene sottoposto.
G
GH: Stato di salute complessivo (scala visuo-analogica). Il paziente
viene invitato ad esprimere un giudizio (punteggio) sul proprio stato di
salute generale, riferito al momento della valutazione, impiegando una
scala visuo-analogica simile a quella sopra riportata, dove 100
corrisponde al peggior stato di salute.
H
HAQ: Health Assessment Questionnaire, Questionario sviluppato per
valutare la disabilit nei pazienti con AR. Valuta la disabilit fisica e il
dolore.
HARD DISK: (anche chiamato disco rigido o disco fisso) un
dispositivo utilizzato per la memorizzazione a lungo termine dei dati in
un computer.
HTML: acronimo per Hyper Text Mark-Up Language, linguaggio di
marcatura per ipertesti) un linguaggio usato per descrivere la
struttura dei documenti ipertestuali disponibili nel World Wide Web
ossia su Internet. Tutti i siti web sono scritti in HTML, codice che viene
170
letto ed elaborato dal browser, il quale genera la pagina che viene
visualizzata sullo schermo del computer.
I
In-line: funzionalita che permette lattuarsi di una determinata
procedura in tempo reale che coincide con il click di un pulsante.
INTERNET: percepita come la pi grande rete telematica mondiale,
e collega alcune centinaia di milioni di elaboratori per suo mezzo
interconnessi. In realt nata nelle intenzioni dei suoi inventori come
"la" rete delle reti. Nell'arco di alcuni decenni oggi divenuta la rete
globale.
J
JAVA VIRTUAL MACHINE: detta anche JVM, la macchina virtuale
che esegue i programmi in linguaggio bytecode, ovvero i prodotti della
compilazione dei sorgenti Java. La JVM formalmente una specifica,
mantenuta da Sun Microsystems. Qualsiasi sistema che si comporti in
modo coerente con tale specifica sar quindi da considerarsi una
particolare implementazione della JVM.
Esistono implementazioni software per praticamente tutti i sistemi
operativi moderni, sia gratuite che commerciali. Inoltre, esistono
implementazioni speciali per particolari ambienti hardware/software
(per esempio telefoni cellulari e palmari), e persino implementazioni
hardware.
O
ODF: Il formato OpenDocument, abbreviazione di OASIS Open
Document Format for Office Applications (Formato OASIS Open
Document per Applicazioni da Ufficio), un formato aperto per file di
documento per l'archiviazione e lo scambio di documenti per la
produttivit di ufficio come documenti di testo (memo, rapporti e libri),
fogli di calcolo, diagrammi e presentazioni.
ODT: File ODT di tipo testo
P
PDF: Portable Document Format, un formato di file basato su un
linguaggio di descrizione di pagina sviluppato da Adobe Systems per
rappresentare documenti in modo indipendente dall'hardware e dal
software utilizzati per generarli o per visualizzarli.
POPUP: menu che appare sullo schermo quando l'utente seleziona un
oggetto sulla finestra. Tale menu appare generalmente nel punto in cui
si cliccato col mouse e scompare quando si seleziona un altro
controllo.
PROCESSORE: vedi CPU
R
RAM: acronimo di Random Access Memory, il supporto di memoria
su cui possibile leggere e scrivere informazioni con un accesso
"casuale", ovvero senza dover rispettare un determinato ordine, come
ad esempio avviene per un nastro magnetico.
S
Server: Un server (detto in italiano anche servente o serviente) una
componente informatica che fornisce servizi ad altre componenti
(tipicamente chiamate client) attraverso una rete. Si noti che il termine
server, cos come pure il termine client, possono essere riferiti sia alla
componente software che alla componente hardware.
171
SF 36: un questionario psicometrico generico. Valuta il livello di
attivit e la sensazione di benessere di ciascuno. Comprende 8 scale a
quesito multiplo (per un totale di 36 domande) che misurano i seguenti
domini di salute percepita:
1) attivit fisica;
2) limitazioni nelle attivit legate al proprio ruolo dovute a problemi di
salute fisica;
3) dolore fisico;
4) salute in generale;
5) vitalit (energia/affaticamento);
6) attivit sociali;
7) limitazioni nellattivit legata al proprio ruolo dovute a problemi
emotivi;
8) salute mentale (sofferenza psicologica e benessere psicologico).
V
VAS: Scala Analogica Visiva del dolore,
VAS dolore (0-100): il paziente viene invitato ad esprimere un
punteggio, mediante visualizzazione di una scala visuale, del grado del
dolore presente in quel giorno, al risveglio.
VAS pz: VAS attivit di malattia espresso dal paziente il quale viene
invitato ad esprimere un giudizio (punteggio) sul grado di attivit della
propria artrite, riferito al periodo degli ultimi 7 giorni, impiegando una
scala visuo-analogica simile a quella sopra riportata.
VAS med: VAS attivit di malattia espresso dal medico il quale
esprime un giudizio (punteggio) sul grado di attivit della artrite
osservata, riferendosi per confronto alla precedente rilevazione clinica.
La scala simile a quella sopra riportata
VES: l'acronimo di "velocit di eritro-sedimentazione"
Un esame del sangue introdotto in diagnosi intorno agli anni '20 del
secolo scorso. Nel sangue, i globuli rossi tendono a rimanere in
sospensione, separati gli uni dagli altri grazie alla carica negativa di
membrana che ostacola la formazione di aggregati (rouleaux). In
condizioni normali la componente proteica del plasma tale da
preservare la carica di superficie delle emazie. Al contrario, quando nel
corpo si instaurano processi flogistici, l'aumentata concentrazione
ematica di proteine tipiche dell'infiammazione (tra cui il fibrinogeno e
la proteina C reattiva) porta ad un indebolimento delle forze repellenti.
I globuli rossi, di conseguenza, tendono ad aggregarsi con formazione
di rouleaux ad alta tendenza a precipitare. Quanto pi grossolani
risultano tali ammassi, tanto pi rapida la sedimentazione.
La VES, per l'appunto, misura la velocit di sedimentazione delle
emazie nel plasma, in mm per ora, quando il campione di sangue viene
lasciato riposare in un'apposita pipetta.
172
Bibliografia
(1) Iam Sommerville - Ingegneria del software, Pearson, Addison-Wesley

2007
(2) Martin Fowler - UML Distilled Pearson Addison Wesley, 2004
(3) Chuck Cavaness - "Programming Jakarta Struts", O'Reilly, 2003
(4) Rod Johnson - "J2EE Design and Development", Wrox, 2002
(5) James Goodwill, Richard Hightower - Professional Jakarta Struts", Wrox
2004
(6) Singh, Stearns, Johnson and the Enterprise Team Designing
Enterprise Applications with the J2EETM Platform, Second Edition,
Addison-Wesley
(7) C. Bauer, G. King Hibernate in Action, Manning, 2008
(8) Doriano Gallozzi - Mokabyte 89 Perch usare i Pattern, 2004,
http://www.mokabyte.it/2004/10/pattern.htm
(9) Alfredo La Rotonda - Mokabyte 82 Sviluppare applicazioni J2EE con
Jakarta Struts, 2004 Parte 2
http://www.mokabyte.it/2004/02/jstruts-2.htm
(10) Harris ED Jr Rheumatoid arthritis: pathophysiology and
implications for therapy. N Eng J Med 1990; 322: 1277-1289
(11) Wolfe F, Zwillich SH. The long-term outcomes of rheumatoid
arthritis: a 23-year prospective, longitudinal study of total joint
replacement and its predictors in 1,600 patients with rheumatoid
arthritis. Arthritis Rheum 1998; 41: 1072-82G.
(12) Valesini et al. Recommendations for the use of biologic (TNF-
_ blocking) agents in the treatment of rheumatoid arthritis in Italy,
Clin Exp Rheum 2006;24;4;413-423
(13) Dr. R.Gorla - "I Farmaci biologici per la cura dell'AR", 2008,
http://www.bresciareumatologia.it/biologici.html
(14) Dr. R.Gorla - "AR: Importanza della diagnosi precoce", 2008
http://www.bresciareumatologia.it/ARearly2.html
(15) Prof. Ezio Bottarelli, "Quaderno di Epidemiologia", 2009
http://www.quadernodiepidemiologia.it/epi/defin/defin.htm
173
Allegati
Allegato 1: CRF Visita inizio Studio
Allegato 2: CRF Visita Follow UP 3,6,9,12 mesi
Allegato 3: Scheda Informativa e Dichiarazione di consenso

informato
Allegato 4: Scheda Informativa per il Medico Curante
Allegato 5: CRF Rilevazione dei costi diretti e indiretti
Allegato A1: Valutazione da parte del paziente
Allegato A2: Valutazione da parte del medico
Allegato A3: CRF Questionario sullo stato di salute (SF36)
Allegato A4: CRF Indice di disabilit funzionale (HAQ)
174

Tesi Finale Antonio Lepore PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesi Finale Antonio Lepore PDF

Caricato da

Copyright:

Formati disponibili

UNIVERSIT DEGLI STUDI DI BARI

FACOLTA DI SCIENZE MATEMATICHE FISICHE E NATURALI

ANNO ACCADEMICO 200 8 - 200 9

Il lavoro presentato si inserisce in un pi ampio ed esteso

Sin dalla loro prima introduzione gli elaboratori e/o

In questo senso larea sanitaria, in tutti i suoi molteplici

strettamente Cliniche, per la raccolta ed immagazzinamento

possibilit, oggi sempre pi richiesta, di realizzazione di vere

infinite opportunit di arricchire tali Banche di Dati collegando

Se lintroduzione di sistemi informativi sanitari innovativi

1.1 Il C onsorzio M ario N egri S ud. Un istituto di

Figura 1: Consorzio Mario Negri Sud, S. Maria Imbaro (CH)

Costituitosi il 5 dicembre 1980, il Consorzio Mario Negri

Principali settori di ricerca:

Il DFCE opera allinterno del Negri Sud con la finalit di:

produrre, diffondere e trasferire conoscenze scientifiche in

Le metodologie utilizzate, e/o oggetto di ricerca e sviluppo,

sperimentazioni cliniche controllate;

Altre attivit dipartimentali integrate con la ricerca

Il LEASI opera all'interno del Dipartimento di Farmacologia

L'epidemiologia (dal Greco =sul, =popolo e

determinare l'origine di una malattia la cui causa

L'epidemiologia si serve della statistica, basata a sua volta

Nel caso qui presentato, e tecnicamente definito come

E forse questo laspetto pi rilevante ai fini del presente

Che cosa sono i dati?

I dati sono numeri o valori o attributi inseriti in un

Ad esempio, il numero "3.8" o il valore "3.8 kg" in s non

I dati nella pratica

La struttura logica ora descritta (cio i processi di raccolta-

Attraverso procedimenti statistici di "analisi", i dati possono

Gli obiettivi pratici dell'epidemiologia clinica ed

Le informazioni sullo stato sanitario di popolazioni e/o

In particolare le informazioni raccolte sono utili a:

L'artrite reumatoide una poliartrite infiammatoria cronica

L'infiammazione pu colpire anche i tendini e allora si

Nonostante non sia ancora nota la causa scatenante

Farmaci vecchi e nuovi per una strategia terapeutica

Nel caso di mancata o incompleta risposta alla terapia con

Il vero problema: il costo della terapia con farmaci

Drug Outcome Survey for Biological treatments in

Tale indagine non prevede luso di alcun farmaco

2.1 Motivazioni & Scopo

Lo sviluppo costante e crescente di nuovi farmaci impone

Su questi presupposti si colloca il sistema DOSE WEB:

Il sistema DOSE web si inserisce in un contesto di ricerca

Le capacit del sistema web sono state suddivise in due

2.3.1 Capacit di Presentazione (Parte Pubblica)

Accesso alla pagina iniziale (HOME): viene mostrato un

2.3.2 Capacit di Accesso (Parte Privata)

Accesso alla parte privata: viene mostrata una coppia di

2.3.3 Capacit di Supervisione (Parte Privata)

Lista centri: viene mostrato un elenco di tutti i Centri di

2.3.4 Capacit di Raccolta (Parte Privata)

Inserimento nuovo paziente: viene mostrata la scheda

I soggetti interessati e coinvolti allinterno del progetto dose web

Referente del progetto: Medico Specialista che funge da

Soggetto sponsor: casa farmaceutica che ha permesso la

Il soggetto sponsor pu:

Utente del Centro attivo: Personale medico composto da

Lutente del centro attivo pu:

Amministratore del portale: Un membro del team di

L Amministratore del portale pu: