Sistem Suport Pentru Trialuri

SISTEM SUPORT PENTRU TRIALURI

LUCRARE DE LICENȚĂ

Cuprins

Contents

Capitolul 1. Introducere

1.1. Contextul proiectului

1.2. Descrierea proiectului

1.3. Domeniu de aplicativitate al proiectului

Capitolul 2. Obiectivele Proiectului

2.1. Obiectivul principal

2.2. Obiective sepecifice

Capitolul 3. Studiu Bibliografic

3.1. Conceptul de trial medical

3.2. Fazele unui trial

3.2.1. Lansarea ipoteze

3.2.2. Randomizarea subiectilor conform factorilor

3.2.3. Lansarea trialului si colectarea datelor

3.2.4. Finalizarea trialului si interpretarea datelor

3.3. Calcul numarului minim de subiecti

3.4. Aplicatii similare

3.5. Beneficiile framework-ului ADF in dezvoltarea proiectului

Capitolul 4. Analiză și Fundamentare Teoretică

4.1. Arhitectura generala a sistemului

4.2. Formule matematice utilizate la stabilirea esantionului minim

4.3. Analiza componentelelor aplicatiei

4.3.1. Inregistrarea si autentificarea utilizatorilor

4.3.2. Definirea si lansarea unui trial

4.3.3. Achizitia de date pentru trial

4.3.4. Finalizarea trialului si generarea rezultatelor statistice

4.3.5. Functionalitati conexe folosite la indeplinirea obiectivelor

4.4. Tipuri de utilizatori si cazurile de utilizare aferente

4.4.1. Tipuri de utilizatori

4.4.2. Cazuri de utilizare

Capitolul 5. Proiectare de Detaliu si Implementare

5.1. Designul sistemului

5.1.1. Designul bazei de date

5.1.2. Designul aplicatiei

5.2. Detalii de implementare

Capitolul 6. Testare și Validare

Capitolul 7. Manual de Instalare si Utilizare

7.1. Resurse hardare

7.2. Resurse software

7.3. Manual de instalare a aplicației

7.4. Manual de utilizare a aplicației

7.4.1. Manual de utilizare comun fiecărui utilizator

7.4.2. Manual de utilizare pentru coordonatorul trialului

7.4.3. Cazuri de utilizare pentru doctor

7.4.4. Manual de utilizare pentru asistent

7.4.5. Manual de utilizare pentru administratorul de utilizatori

7.4.6. Manual de utilizare pentru administratorul bazei de date

7.4.7. Manual de utilizare pentru pacient

Capitolul 8. Concluzii

8.1. Contributie personala

8.2. Analiza rezultatelor obtinute

8.3. Dezvoltari ulterioare

Bibliografie

Introducere

Contextul proiectului

Apariția tot mai frecventă a bolilor necesită un mediu de creare si testare a unor medicamente noi pentru a combate disfuncționalitățile organismului uman.Procesul de testare a medicamentelor pe subiecți se numește trial medical.In zilele noastre tratarea anumitor boli sau simptomuri nu mai poate fi realizata prin metode sau tratamente utilizate in trecut deoarece si aceste boli au avut o evolutie in timp,devenind tot mai complexe de tratat,unele chiar de depistat.Trialurile medicale vin in ajutorul nostru tocmai pentru a tine pasul cu aceasta evolutie a disfunctionalitatilor organismului uman.Ele ulterior raspund la multe intrebari lansate de catre pacienti,cadre medicale si nu in ultimul rand de catre industria farmaceutica.Cu ajutorul acestora putem dovedi daca un tratament nou intradevar va da roade,daca un tratament este mai bun decat altul si se poate stabili daca au efecte adverse sau nu.

Prin crearea unui formalism in ceea ce priveste desfășurarea activitățiilor in cadrul trialurilor medicale poate sa creasca performanță acestor studii.Asadar este incurajator sa se dezvolte aplicatii care sa rezvolte gestiunea si monitorizarea trialurilor.Aplicatiile sa aiba aiba acelasi scop dar sa modeleze diferite particularitari ale trialurilor.De exemplu testarea unor proceduri noi nu neaparat testarea de medicamente,iar monitorizarea sa nu fie realizata doar pe parametri biologici.

Inevitabil se ajunge la problema necesitarii unor astfel de sisteme,acuratetea acestora si persistenta in timp a conceptului de trial.Raspunsul la problema necesitatii vine chiar din primele afirmatii facute in acest subcapitol si anume faptul ca disfunctionalitatile organismului uman sunt tot mai diversificate si mai complexe ceea ce face ca nevoia unor astfel de sisteme sa fie indispensabila.Acuratetea datelor se data de precizia preluarii acestora si de constrangerile impuse la introducerea lor in sistem.In problema persistentei concepului de trial putem face doar o previziune si anume ca aceasta va fi de actualitate mult timp de acum inainte,dar cu nuantari diferite in functie de dinamicitatea aparitiei bolilor.

Descrierea proiectului

Acest proiect va fi un sistem suport independent si complex de management al datelor din trialuri.Independeta sistemului va fi data de un modul de gestiune a informatiilor din baza de date si un alt modul de administrare a utilizatorilor,iar complexitatea va fi data de varietatea functionalitatilor oferite.Sistemul se va baza pe prelucrarea statistica a datelor introduse in urma analizelor efecutate asupra subectiilor.Acesta va furniza rezultate usor interpretabile atat de oamenii de specialitate cat si de persoanele neavizate.Aplicatia va fi accesibila de la distanta si va utiliza o baza de date partajata care va aduce un prim beneficiu prin reducerea costurilor necesare deplasarilor intre un centru de testare si altul precum si timpul pierdut pentru aceste actiuni.In concluzie subiectii pot fi analizati in centre diferite iar datele preluate sa ajunga intr-un singur loc de unde toti utilizatorii au acces la ele in functie de rolul acestora.Pe langa aceste functionalitati,sistemul va fi capabil sa genereze o lista de subiecti din baza de date folosind tehnici de matching si de variere al acestora pentru ca trialul sa poata beneficia de pacientii cei mai potriviti pentru studiul tratamentelor in functie de sablonul selectat la definirea trialului.

Sistemul va trebui sa faciliteze munca mai multor persoane implicate in desfasurarea unui trial pe intreg fluxul de operare:definire trial,selectie,subiecti,colectare de date,prelucrare date si reprezentare date.Astfel se elimina susceptibilitatea datelor eronate din gestiunea bazata pe fisiere individuale,persoanele specializate in statistica medicala pentru care se ocupa de interpretarea datelor si totodata se elimina si persoanele cu rolul de a informa subiectii cu privire la rezultatele trialului deoarece acestea vor fi expuse intr-o maniera usor de inteles chiar si pentru oamenii neavizati.

Accesul facil la informatiile din sistem nu trebuie sa neglijeze securitatea datelor.Proiectul trebuie privind din perspectiva a mai multor categorii de persoane care pot sa isi desfasoara munca cu ajutorul aplicatiei,dar aceste categorii sa fie limitate in functie de rolul lor pentru a nu oferii prea multe informatii si optiuni unor persoane neavizate.

Domeniu de aplicativitate al proiectului

Proiectul este destinat domeniului medical,dar care poate avea un impact ulterior in societate in functie de rezultatele obtinute in urma studiilor realizate.Acest impact constand in schimbarea tratamentelor care in momentul de fata reprezinta un standard.Sistemul poate fi folosit si doar pentru o gestiunea centralizata a pacientilor in care se tine evidenta diagnosticelor identificate si a buletinelor de analize pentru fiecare pacient.

Obiectivele Proiectului

Obiectivul principal

Scopul fiecarei aplicatii sau a sistemelor digitale se rezuma la patru mari functionalitati comune: transformarea informatiilor in date,prelucrarea acestor date,stocarea lor si mai apoi transformarea datelor in informatii relevante si precise.Acest proiect are acelasi scop,de a oferi suport in primul rand cadrelor medicale care presteaza servicii in trialurile medicale,dar nu in ultimul rand si pacientilor care vor putea accesa foarte usor informatii relevante despre starea lor de sanatate.Utilitatea majora al acestui proiect este acela de a scuti utilizatorii de a face calcule statistice complexe si de a lua decizii asupra in cazul randomizarii subiectilor.Sistemul este capabil sa genereze numarul minim de subiecti pentru fiecare brat al trialului.Acesta fiind o problema foarte mare pentru coordonatorii trialurilor.De acest numar generat depinzand veridicitatea rezultatelor trialului.

Un alt plus al acestei aplicatii este randomizarea automata a subiectilor in functie de combinatiile complexe ale factorilor de includere si excludere definiti.Metoda randomizarii asigura dispersia echilibrata a subiectilor pe fiecare brat si corectitudinea filtrarii pacientilor,ceea ce reduce semnificativ munca depusa si timpul investit de catre coordonatori pentru aceasta operatiune.

Al treilea avantaj este capabilitatea de a vizualiza grafic evolutia partiala si finala a subiectilor din fiecare trial precum si alte rezultate statistice.In acest mod de reprezentarea a datelor se poate vizualiza mult mai usor diferenta dintre tratamente avand o evolutie in timp al fiecarui parametru biologic urmarit in trialul in cauza.

Obiective sepecifice

Atingerea obiectivului principal depinde de mai multe obiective secundare sau mai corect spus obiective specifice sistemului.Aceste obiective ofera sistemului un caracter complet si complex.Aproape toate aceste obiective asigura un management eficient si sigur al informatiilor din sistem.Pentru o mai buna delimitare a functiilor si a securitatii informatiilor s-a ales impartirea functionalitatilor sistemului mai multor roluri.Aceste roluri sunt: administrator de utilizatori,administrator al bazei de date,coordonator de trial,doctor,asistent si nu in ultimul rand pacientul.

Obiectivele specifice pentru:

administratorul de utilizatori sunt:

autorizarea accesului utilizatorilor in sistem

accordarea sau dealocarea rolurilor utilizatorilor

stergerea utilizatorilor

administratorul bazei de date sunt:

adaugarea de persoane noi in baza de date

stergerea persoanelor

adaugarea de echipamente medicale noi in baza de ate

stergerea echipamentelor medicale casate

adaugarea de angajati noi in baza de date

stergerea angajatilor

coordonatorul de trial sunt:

definirea unui trial nou

vizualizarea partiala si finala a rezultatelor statistice pentru trialurile definite personal

vizualizarea grafica a evolutiei partiale si finale a subiectilor din trialurile definite personal

trimiterea invitatilor de inrolare in triali la pacienti

acceptarea sau refuzarea solicitarilor de inrolare in trial primite de la pacienti

lansarea si finalizarea trialurilor

doctor sunt:

crearea fiselor medicale pentru pacienti

stergerea fiselor medicale ale pacientilor

adaugarea diagnosticelor pentru pacienti

stergerea diagnosticelor care nu mai sunt de actualitate

adaugarea analizelor medicale generale pentru pacienti

adaugarea analizelor medicale pentru pacienti pentru fiecare trial in desfasurare

vizualizarea grafica a evolutiei subiectilor si a rezultatelor statistice din trialurile finalizate

exportarea in format microsoft excel a analizelor medicale din fiecare trial

vizualizarea grafica a evolutiei subiectilor din trialurile finalizate

asistent sunt:

adaugarea analizelor medicale ale pacientilor pentru fiecare trial in desfasurare

vizualizarea grafica a evolutiei subiectilor si a rezultatelor statistice din trialurile finalizate

vizualizarea grafica a evolutiei subiectilor din trialurile finalizate

pacient sunt:

vizualizarea propriei fise medicale

adaugarea analizelor medicale pentru trialul in care este inrolat

vizualizarea evolutie personale in trialul in care este inrolat

solicitarea inrolarii in trial

acceptarea sau refuzarea invitatiilor de inrolare in trial primite

vizualizarea evolutiei grafice pentru trialurile finalizate

Toate aceste obiective specifice ajuta intregul sistem sa fie catalogat ca fiind un sistem suport complet deoarece ofera posibilitatea introducerii datelor,persistenta lor,managementul acestora acolo unde este cazul si mai apoi de a oferii informatii relevante in urma prelucrarii datelor.

Studiu Bibliografic

Trialurile medicale nu au prezentat interes pentru publicul larg in anii anteriori,dar aparitia tot mai frecventa de disfunctionalitati ale organismului uman a facut ca acest subiectstergerea angajatilor

coordonatorul de trial sunt:

definirea unui trial nou

vizualizarea partiala si finala a rezultatelor statistice pentru trialurile definite personal

vizualizarea grafica a evolutiei partiale si finale a subiectilor din trialurile definite personal

trimiterea invitatilor de inrolare in triali la pacienti

acceptarea sau refuzarea solicitarilor de inrolare in trial primite de la pacienti

lansarea si finalizarea trialurilor

doctor sunt:

crearea fiselor medicale pentru pacienti

stergerea fiselor medicale ale pacientilor

adaugarea diagnosticelor pentru pacienti

stergerea diagnosticelor care nu mai sunt de actualitate

adaugarea analizelor medicale generale pentru pacienti

adaugarea analizelor medicale pentru pacienti pentru fiecare trial in desfasurare

vizualizarea grafica a evolutiei subiectilor si a rezultatelor statistice din trialurile finalizate

exportarea in format microsoft excel a analizelor medicale din fiecare trial

vizualizarea grafica a evolutiei subiectilor din trialurile finalizate

asistent sunt:

adaugarea analizelor medicale ale pacientilor pentru fiecare trial in desfasurare

vizualizarea grafica a evolutiei subiectilor si a rezultatelor statistice din trialurile finalizate

vizualizarea grafica a evolutiei subiectilor din trialurile finalizate

pacient sunt:

vizualizarea propriei fise medicale

adaugarea analizelor medicale pentru trialul in care este inrolat

vizualizarea evolutie personale in trialul in care este inrolat

solicitarea inrolarii in trial

acceptarea sau refuzarea invitatiilor de inrolare in trial primite

vizualizarea evolutiei grafice pentru trialurile finalizate

Toate aceste obiective specifice ajuta intregul sistem sa fie catalogat ca fiind un sistem suport complet deoarece ofera posibilitatea introducerii datelor,persistenta lor,managementul acestora acolo unde este cazul si mai apoi de a oferii informatii relevante in urma prelucrarii datelor.

Studiu Bibliografic

Trialurile medicale nu au prezentat interes pentru publicul larg in anii anteriori,dar aparitia tot mai frecventa de disfunctionalitati ale organismului uman a facut ca acest subiect sa capete o importanta deosebita ajungandu-se chiar la implicarea benevola a pacientilor in testarea posibilelor tratamente.

In acest capitol se vor detalia aspecte legate de trialuri,fazele acestora,termeni importanti folositi la stabilirea numarului minim de subiecti,informatii despre aplicatii similare deja existente pe piata si nu in ultimul rand se va relata studiul de fezabilitate a mediilor de dezvoltare alese pentru implementarea proiectului.

Conceptul de trial medical

In cartea [10] sunt prezentate trialurile medicale care sunt defapt studii prospective de cercetare biomedicala sau comportamentala pe subiecti umani care sunt concepute pentru a raspunde la intrebari specifice (ipoteze) despre interventii biomedicale (exemplu: vaccinuri noi,medicamene,tratamente,dispozitive sau noi modalitati de utilizare a interventiilor cunoscute) generand date relevante asupra carora se vor lua decizii la finalul trialurilor.Acestea sunt efectuate numai dupa ce au fost adunate suficiente informatii care mai apoi sunt aprobate de catre autoritariile din domeniul sanatatii sau de catre comitetul de etica.Trialurile pot varia in dimensiunea lor.Pot sa implice un singur studiu de cercetare intr-o singura tara sau mai multe in diferite tari.

Un mod de clasificare a trialurilor este dupa scopul lor.Institutul National de Sanatate din Statele Unite (NIH) a organizat trialurile in cinci tipuri diferite:

Trialuri de preventie in care se cauta o modalitate mai buna de preventie a bolilor la persoanele care nu au avut niciodata aceste boli sau modalitati de a inceta recidivitatea.Aceasta abordare poate sa includa medicamente,vitamine,vaccinuri,minerale sau schimbari in stilul de viata.

Trialuri „Screening” in care se testeaza o modalitate mai eficienta de a depista anumite boli sau stari de sanatate

Trialuri de diagnosticare sunt efectuate pentru a gasit teste sau proceduri mai bune in diagnosticarea unei anumite boli sau conditii

Trialuri de tratare in care se fac teste cu tratamente experimentale cum ar fi noi combinatii de medicamente sau de noi abordari in inverventiile chirurgicale sau radioterapeutice.

Trialuri „Quality of life” in care sunt vizate persoanele cu bol cronice.In aceste trialuri se cauta o modalitate mai buna de a imbunatati confortul si „calitatea” vietii acestor.Cu alte cuvinte de a face ca bolile sa nu devine insuportabile.

Trialurile la care facem noi referire in acest proiect sunt trialurile de tratare.Mai sunt cunoscute sunt denumirea de trialuri observationale.

Aceste trialurile se pot si ele clasifica in trei subcategorii conform detaliilor oferite in cartea [2]:

Grup singular:sunt trialurile in care exista un singur grup de subiecti la care li se administreaza acelasi tratament sau se aplica aceea si interventie.

Grupuri paralele:sunt trialurile in care exista doua grupuri paralele de subiecti la care li se administreaza tratamente diferite sau se aplica interventii diferite.De exemplu un trial paralel cu doua brate implica doua grupuri de subiecti.Un grup a primit tratamentul A,iar celalalt grup primeste tratamentul B.Aceasta asignarea a tratamentelor ramane neschimbata pe tot parcursul defasurarii trialului.Factorul de risc sau de expunere este distribuit aleator la grupurile de control.Este unul din cele mai bune tipuri de trial deoarce elimina in mare masura prejudecatiile observatorilor.

Crossover:sunt trialurile in care exista doua grupuri de subiecti la care li se administreaza doua sau mai multe tratamente sau interventii intr-o ordine prestabilita.De exemplu un trial crossover „doi-cu-doi” implica doua grupuri de subiecti.Un grup primeste tratamentul A in fata initiala a procesului, apoi primeste tratamentul B in cursul unei faze ulterioare.Alt grup primeste mai intai tratamentul B in fata initiala,apoi primeste tratamentul A in cursul fazei ulterioare.Deci in timpul studiului subiectii „trec” de la un tratament la altul.Toti participantii primesc atat tratamentul A cat si tratamentul B la un moment dat in timpul studiului,dar intr-o ordine diferita in functie de grupul in care sunt repartizati.

Pentru trialurile medicale se mai iveste o problema.Aceasta fiind cine are dreptul sa patricipe.La o analiza sumara a acestei problema am putea spune ca este o problema minora deoarece se pot inrola chiar si voluntari,dar acest aspect nu simplifica deloc cazul.Fiecare persoana care doreste sau ii se propune participarea la un asemenea trial semneaza un contract de luare la cunostiinta a riscurilor.Dupa selectarea populatiei propuse se trece la un asa numit proces de filtrare in functie de anumiti factori de includere si de excludere specifici fiecarui trial.

Factorii de includere sunt caracteristici care viitori subiecti trebuie sa le aiba pentru a fi inclusi in trial in timp de factorii de excludere sunt acele caracteristici care descalifica potentiali subiecti de la includerea in studiu.Criteriile de includere si excludere pot include factori cum ar fi varsta,sexul,rasa,etnie,tipul si stadiul bolii,antecedente ale tratamentelor si de prezenta sau absenta altor afectiuni medicale,psiho-sociale sau emotionale.

Pe langa caracterul fiecarui trial exista asociat si un design.Design-ul trialului poate fi simplu ,orb,dublu-orb si placebo:

Design-ul simplu inseamna ca fiecare parte implicata in trial este instiintata despre medicamentul sau medicamentele administrate.Asta inseamna ca atat coordonatorul,doctorii,asistentii si pacientii cunosc tratamentele.Acesta este mai rar intalnit,doar in anumite situatii in care studiile sunt mult mai evidente cum ar fi numararea supravietuitorilor.In cazul in care se studiaza doar corectarea anumitor parametrii biologici se recomanda folosirea evaluatorilor independeti pentru a lua o decizie corecta asupra rezultatelor.

Design-ul orb inseamna ca subiectii implicati in studiu nu au habar despre tratamentul pe care il primesc,doar cadrele medicale au cunostiinte asupra acestui fapt.Aceasta regula poate fi aplicata si invers,doar subiectii sa fie constienti de tratamentul primit,iar investigatorii sa fie „oribiti”.

Design-ul dublu-orb este design-ul cel mai preferat in aceste studii deoarece asigura o corectitudine suplimentara a interpretarii datelor de la finalul studiului.In acest caz nimeni nu va partinii nici un tratament in favoarea celuilalt.Acest tip de design inseamna ca nici cadrele medicale implicate in trial nici subiectii carora li se administreaza tratamentele nu cunosc tratamentul.In anumite situatii acest design este imposibil de aplicat.Un exemplu ar fi administrarea de citostatice la subiectii depistati cu cancer.La acest tratament subiectii au reactii adverse vizibile ceea ce ar dezvalui secretul.

Ultimul tip de design,dar nu cel din urma este design-ul placebo.In acest tip de design se mizeaza pe efectul placebo care consta in administrarea unui tratament fals cu scopul de a vindeca organismul doar folosindu-se de constiinta individuala.O tehnica des intalnita in momentul actual.

In cartea [3] ne este relatata o alta caracteristica a unui trial.Aceasta fiind randomizarea.In cel mai simplu caz randomizarea este un proces prin care fiecare participant are aceeasi sansa de a fi distribuit in grupul studiat sau in cel de control.Elementul de noroc stand la baza procesului de alocare.Tehnica de randomizare este considerata de cei mai multi ca fiind cea mai sigura forma de evidenta stiintifica.Aceasta tehnica face o distributie echilibrata a subiectiilor in echipe.Randomizarea tinde sa produca grupuri de studiu tinand cont de factori de risc cunoscuti si necunoscuti, eliminand partinirea anchetatorilor in alocarea participantilor si garanteaza ca testele statistice vor avea rata de eroare minima.Un trial randomizat poate oferi dovezi convingatoare ca tratamentul studiat produce un efect asupra sanatatii umane.

Desi termenul de trial medical este frecvent asociat cu studiul randomizat de faza III pe grupuri foarte mari de subiecti ,multe dintre acestea sunt defapt de dimensiuni reduse.Sunt concepute pentru a testa intrebari simple.In domeniul bolilor rare,numarul de pacienti este factorul de limitare pentru dimensiunea unui trial medical.

Fazele unui trial

Trialul medical este un proces de cercetare complex si ca orice element cu acest atribut poate fi descompus sau analizat din mai multe privinte.Aceste se pot analiza mai usor descompunandu-le in faze.Fiecare astfel de trial trece prin patru faze:

faza de lansare a ipotezei

faza de randomizarea subiectilor conform factorilor

faza de lansare a trialului si de colectare a datelor

faza de finalizare a trialului si interpreare adatelor

Lansarea ipoteze

Toate trialurile medicale pornesc de la o idee numita ipoteza.Exemplu: „tratamentul A este mai eficient decat tratamentul B”.Tinand cont ca pentru orice afirmatie facut trebuie sa avem o justificare.Aceasta justificare este dependenta de numar minim de subiecti care trebuie testati si caracterul ipotezei.

Din punct de vedere al acestui caracter al ipotezei exista trialuri de testare a:

Egalitatii: in care sunt comparate doua tratamente cu premisa ca au acelasi efect.Nu intotdeaua se fac teste pe grupuri paralele.

Echivalentei: in care sunt comparate doua tratamente cu scopul de a gasi similaritati intre acestea.Estimarile diferentelor se pot depista doar in trialurile de dimensiuni foarte mari.

Superioritatii sau a non-inferioritatii: in care sunt comparate doua tratamente cu scopul de evidentierea a superioritatii sau a non-inferioritatii in cazul in care tratamentul deja intrat in standard isi apara valoarea.

Randomizarea subiectilor conform factorilor

Dupa lansarea ipotezei se defineste factorii de includere si de excludere din trial pentru a face filtrarea persoanelor selectate pentru introlarea in trial.La finalul aplicarii filtrului avem generata una sau doua echipe de subiecti.Pentru ca rezultatele sa aiba o veridicitate ridicata se aplica tehnica de randomizare.Cum am mentionat si in subcapitolul in care se descrie conceptul de trial,randomizarea poate oferi dovezi convingatoare ca tratamentul sau tratamentele studiate produc un efect benefic asupra sanatatii umane.

Lansarea trialului si colectarea datelor

Avand stabile echipele de subiecti se poate face lansarea trialului.Aceasta lansare echivaleaza cu momentul zero al trialului in care se incepe colectarea datelor.Pe parcursul intregii perioade de desfasurare se fac preluari de analize care se stocheaza indiferent de natura acesteia.

Finalizarea trialului si interpretarea datelor

Finalizarea trialului poate sa nu insemne neaparat sfarsitul perioade de desfasurare.Inchiderea unui trial poate fi decisa in cazul in care administrarea tratamentelor sau aplicarea interventiilor pericliteaza starea de sanatate a pacientului.Daca nu sunt probleme in aceasta perioada atunci se asteapta expirarea timpului alocat dupa care se finalizeaza trialul.In momentul in care trialul este incheiat se incepe interpretarea datelor si mai apoi stabilirea rezultatelor statistice care vor afirma sau infirma ipoteza lansata.

Calcul numarului minim de subiecti

Determinarea dimensiunii esantionului este procesul de alegere a numarului de cazuri care vor fi incluse in esantionul statistic conform [10].Aceasta dimensiune este o caracteristica importanta a oricarui studiu empiric in care obiectiviul este de a face deductii cu privire la o populatie dintr-o proba.In practica marimea esantionului utilizat intr-un studiu este determinat pe baza cheltuielilor de colectare a datelor precum si necesitatea de a avea putere statistica suficienta.

Ca si in orice alt studiu si in trialurile medicale calcularea numarului minim de subiecti este o problema importanta.Daca acest numar nu este calculat corect atunci ipoteza poate fi infirmata chiar daca aceasta este adevarata.

In functie de tipul de trial ,caracterul ipotezei si proportia grupelor se aplica formule matematica specifice.Inainte de a expune aceste formule vom explica cativa termeni specifici acestora si vom da cateva exemple pentru a clarifica acesti termeni.

Cei mai importanti factori in estimarea marimii esantionului sunt eroarea de tipul I,eroare de tipul II si puterea testului.Pentru a explica factorul de eroare de tip I luam un exemplu din cartea[9].

Se presupune ca testam doua marci de paracetamol pentru a evalua daca brandul 1 este mai bun in tratarea subiectilor care au febra fata de brandul 2.Deoarece ambele marci contin paracetamol,este de asteptat ca efectul ambelor marci sa fie similar.Se lanseaza ipoteaza statistica in jurul acestei intrebari.Avem impoteza nula (H0) in care spunem ca brandul 1 este egal cu brandul 2.Ipoteza alternativa (H1) in care spunem ca brandul 1 este mai bun decat brandul 2.Pe baza analizei sa ajuns la concluzia ca brandul 1 este mai bun decat brandul 2,in principiu,noi respindem H0,facem o eroare aici prin respinderea H0.Acest lucru este numit ca avem o eroare de tip I.Probabilitatea de a face o eroare de tipul I este numita „nivel de semnificatie” si se noteaza cu α.

Tot in cartea [9] avem un exemplu in care ne este explicat factorul de eroare de tipul II.Se presupue ca testam un paracetamol fata de placebo pentru a evalua daca paracetamolul este mai bun in tratarea subiectilor care au febra comparativ cu placebo.Este de asteptat ca efectul paracetamolului sa fie mai bun decat efectul placebo.Se lanseaza ipoteza statistica in jurul acestei idei.Avem ipoteza nula (H0) in care paracetamolul este egal cu placebo si ipoteza alternativa (H1) in care paracetamolul este mai bun decat placebo.Daca analizam si ajungem la concluzia ca paracetamolul este egal cu placebo,vom accepta H0.Stiind ca paracetamolul este mai bun decat placebo (H1) facem o eroare acceptand H0.Aceasta eroare se numeste eroare de tipul II.Probabilitatea de a face o eroare de tipul II este notata cu β.In cazul de mai sus daca in urma analizei ajungem la concluzia ca paracetamolul este mai bun decat placebo atunci respindem H0,care are putea fi chiar decizia buna.Probabilitatea unei asemenea decizii se numeste „putere a testului” care este 1-β.

Un alt parametru critic necesar pentru estimarea marimii esantionului este caracterul ipotezei:egalitate,non-inferioritate,superioritate sau echivalenta.Studiul egalitatii si al echivalentei sunt teste statistice bilaterale,iar cele de non-inferioritate si de superioritate sunt teste statistice unilaterale.

Diferenta semnificativa numita si importanta medicala sau marja este unul din cele mai critice si unul dintre cei mai dificili parametrii.Aici provocarea consta in definirea unei diferene intre tratamentul test si cel de referinta care poate fi considerat important din punct de vedere medical.Aceasta diferenta poate avea impact asupra medicamentelor deja intrat in standard.Pragul acesta nu este usor de aflat si ar trebui decis bazandu-se pe analize medicale.

Aplicatii similare

In momentul actual pe piata software nu exista aplicatii care sa cuprinda toate functionalitatile propuse ale acestui proiect.Cel mai probabil exista aplicatii dezvoltate si particularizate pentru anumite clinici private care si-au dorit imbunatarirea fluxului de date in ceea ce priveste managementul in trial.Diversitatea acestui concept de trial medical este foarte mare ceea ce face extrem de dificiala dezvoltarea unei aplicatii care sa cuprinda toate particularitatile unui trial.Chiar si acest proiect s-a limita la trialurile de faza trei in care se testeaza in mare parte medicamente noi sau proceduri noi care vizeaza modificarea anumitor parametrii biologici.Totusi dintre produsele software existente am putut identifica unul care sa contina o parte din functionalitatile acestui proiect.Acesta aplicatie se numeste „Epiinfo”.

Conform informatiilor disponibile pe website-ul produsului [12] se poate observa partea comuna a acestor care este suportul pentru calculul statistic, generarea de grafice in functie de anumite date si posibilitatea de stocarea a informatiilor dintre in aplicatie.Epiinfo este un produs care a exploatat zona de biostatistica oferind mai multe functionalitati in acest sens,dar un mare dezavantaj este natura aplicatiei,fiind vorba de o aplicatie desktop.Este considerat un dezavantaj deoarece informatiile sunt stocate pe sisteme de calcul individuale ceea ce defavorizeaza sincronizarea cu alte baze de date sau impartasirea datelor cu alti utilizatori ai aplicatei.In tabelul 3.4.1 este prezentata comparatia dintre proiectul produs si aplicatia Epiinfo.

Tabelul 3.4.1 – Comparatia aplicatiilor

Beneficiile framework-ului ADF in dezvoltarea proiectului

Aplication Development Framework dezvoltat de compania Oracle este un framework Java EE integrat in mediul de dezvoltare Oracle Jdeveloper 11g conform informatiilor din cartea[1].Aceste unelte le vom utiliza in implementarea solutiei.Din acest framework vom folosii in special ADF Business Components (ADF BC) pentru maparea usoara a tabelelor din bazate de date si ADF Faces pentru crearea interfetelor utilizator intr-un mod rapid si foarte usor de interconectat cu restul componentelor ale arhitecturii.

Analiză și Fundamentare Teoretică

In cadrul acestui capitol se va face o descriere a arhitecturii pe care se bazeaza sistemul, o detalierea pentru fiecare componenta a aplicatiei, o expunere si exemplificare a formulelor matematice utilizate in calculul esantionului minim si nu in ultimul rand vom detalia cazurile de utilizare aferente fiecarui tip de utilizator.

Arhitectura generala a sistemului

In figura 4.1.1 este ilustrala arhitectura generala a sistemului.Aceasta este bazata pe arhitectura Model-View-Controller(MVC).

Ca orice aplicatie web partea de „front-end” este defapt web browser-ul cu ajutorul caruia utilizatorii vor interactiona cu sistemul,iar partea de „back-end” dupa cum sugereaza si numele este partea in care se executa solicitarile utilizatorilor in server.Nivelul Model reprezinta valorile datelor legate de pagina curenta.Nivelul View continte interfetele utilizator sub forma de pagini,folosite pentru a vizualiza sau modifica datele.Nivelul Controller proceseaza datele introduse de utilizator si determina navigarea intre pagini,iar nivelul Business Services se ocupa de accesul la date si incapsuleaza logica de business.

Formule matematice utilizate la stabilirea esantionului minim

In acest subcapitol vom prezenta formulele matematice care vor fi utilizate la stabilirea numarului minim de subiecti care trebuie sa participe in studiul trialului astfel incat acesta sa fie valid.Vom da si cate un exemplu pentru fiecare formula utilizata pentru a arata transpunerea limbajului natural in parametrii si impactul acestor parametrilor asupra rezultatului.

Pentru tipurile de trial in care se studiaza evolutia pacientilor dintr-un singur grup avem urmatoarele formule:

Testarea egalitatii: ,unde:

depinde este nivelul de semnificatie al unui test statistic bilateral (α);

depinde de puterea testului (β);

reprezinta proportia de succes asteptata a esantionului;

reprezinta proportia de succes cunoscuta;

N reprezinta dimensiunea esantionului rezultat aplicarii formulei

Exemplu:Se presupune ca rata de raspuns a populatiei de pacienti in studiu dupa tratament este de asteptat sa fie in jur de 50% (θ=0.5).Pentru α = 0.05 marimea esantionului necesar pentru atingerea unei puteri de 80% (β=0.2) care detecteaza corect o diferenta intre rata de raspuns post-tratament si valoarea de referinta 30% () este N= 50.

Testarea superioritatii/non-inferioritatii: ,unde;

depinde este nivelul de semnificatie al unui test statistic unilateral (α);

depinde de puterea testului (β);

reprezinta proportia de succes asteptata a esantionului;

reprezinta proportia de succes cunoscuta;

δ reprezinta diferenta semnificativa(pentru valori pozitive se testeaza superioritatea,iar pentru valori negative se testeaza non-inferioritatea);

N reprezinta dimensiunea esantionului rezultat aplicarii formulei;

Exemplu:Vrem sa aratam ca majoritatea pacientilor a caror schimbare a densitatii osoase dupa tratament este cel putin la fel de buna ca valoarea de referinta 30% ().Daca presupunem ca diferenta de 10% din rata de raspuns este considerata ca nu are nici o semnificatie δ = -10% pentru a testa non-inferioritatea.De asemenea,rata de raspuns adevarata este 50% (θ=0.5).Marimea esantionului necesar pentru a avea o putere a testului de 80% (β=0.2) este N=18

Testarea echivalentei: ,unde:

depinde este nivelul de semnificatie al unui test statistic unilateral (α);

depinde de puterea testului (β);

reprezinta proportia de succes asteptata a esantionului;

reprezinta proportia de succes cunoscuta;

δ reprezinta limita de echivalenta;

N reprezinta dimensiunea esantionului rezultat aplicarii formulei;

Exemplu:Consideram ca un medicament pentru tratarea osteoporozei de pe piata are o rata de raspuns de 60%.O diferenta de δ = 20% a ratei de raspuns este o diferenta ne semnificativa.Asadar,cercetatorul vrea sa arate ca medicamentul studiat este echivalent cu medicamentul existent pe piata prin rata de raspuns.In cazul in care rata de raspuns cunoscuta este 65% (), α = 0.05,presupunand ca rata de raspuns asteptata este 60% (θ=0.6) atunci marimea estantionului necesar pentru a avea o putere a testului de 80% (β=0.2) este N=92.

Pentru tipurile de trial in care se studiaza evolutia pacientilor din doua grupuri paralele avem urmatoarele formule:

Testarea egalitatii: ,unde:

depinde este nivelul de semnificatie al unui test statistic bilateral (α);

depinde de puterea testului (β);

reprezinta proportia de succes asteptata a esantionului 1;

reprezinta proportia de succes asteptata a esantionului 2;

r reprezinta proportia esantioanelor;

reprezinta dimensiunea esantionului 1;

reprezinta dimensiunea esantionului 2;

N reprezinta dimensiunea totala a esantioanelor;

Exemplu: Să presupunem că o diferență de din răspunsul clinic de vindecare este considerat o diferența clinica semnificativa între doi agenti antimicrobieni. Presupunând că rata reala pentru agentul de control activ este de 65% ( = 0,65 și = 0,85), apoi mărimea eșantionului necesar cu alocarea egală (r = 1) pentru a obține o putere de 80% (β = 0,2) la α = 0,05 se poate determina prin .

Testarea superioritatii/non-inferioritatii: ,unde:

depinde este nivelul de semnificatie al unui test statistic unilateral (α);

depinde de puterea testului (β);

reprezinta proportia de succes asteptata a esantionului 1;

reprezinta proportia de succes asteptata a esantionului 2;

δ reprezinta diferenta semnificativa(pentru valori pozitive se testeaza superioritatea,iar pentru valori negative se testeaza non-inferioritatea)

r reprezinta proportia esantioanelor;

reprezinta dimensiunea esantionului 1;

reprezinta dimensiunea esantionului 2;

N reprezinta dimensiunea totala a esantioanelor;

Exemplu: Să presupunem ca se dorestea a se stabili non-inferioritatea medicamentului testat față de agentul de control activ. Având în vedere diferența de mai puțin de 10% nu are importanță clinică. Astfel, marja de non-inferioritate este δ = -0.1. Acum, având în vedere că ratele medii de vindecare asteptate ale agenților de tratament și de control activ sunt = 85% și = 65% rezulta ca mărimea eșantionului necesar cu alocarea egală (r = 1) pentru a obține o putere de 80% (β = 0,2) la α = 0,05 se poate determina prin n1 = n2 = 25.

Testarea echivalentei: ,unde:

depinde este nivelul de semnificatie al unui test statistic unilateral (α);

depinde de puterea testului (β);

reprezinta proportia de succes asteptata a esantionului 1;

reprezinta proportia de succes asteptata a esantionului 2;

δ reprezinta limita de echivalenta;

r reprezinta proportia esantioanelor;

reprezinta dimensiunea esantionului 1;

reprezinta dimensiunea esantionului 2;

N reprezinta dimensiunea totala a esantioanelor;

Pentru trialurile de tip crossover in care se studiaza evolutia pacientilor din doua grupuri paralele egale avem urmatoarele formule:

Testarea egalitatii: ,unde:

depinde este nivelul de semnificatie al unui test statistic bilateral (α);

depinde de puterea testului (β);

reprezinta diferenta media acceptabila dintre esantioane;

reprezinta variata asteptata;

N reprezinta dimensiunea fiecarui esantion;

Testarea superioritatii/non-inferioritatii: ,unde:

depinde este nivelul de semnificatie al unui test statistic bilateral (α);

depinde de puterea testului (β);

reprezinta diferenta media acceptabila dintre esantioane;

reprezinta variata asteptata;

δ reprezinta diferenta semnificativa(pentru valori pozitive se testeaza superioritatea,iar pentru valori negative se testeaza non-inferioritatea);

N reprezinta dimensiunea fiecarui esantion;

Testarea echivalentei: ,unde:

depinde este nivelul de semnificatie al unui test statistic bilateral (α);

depinde de puterea testului (β);

reprezinta diferenta media acceptabila dintre esantioane;

reprezinta variata asteptata;

δ reprezinta limita de echivalenta;

N reprezinta dimensiunea fiecarui esantion;

Analiza componentelelor aplicatiei

La o privirea de ansamblu aplicatia poate fi descompusa in mai multe componente care impreuna realizeaza obiectivele propuse.Aceste componente sunt urmatoarele: inregistrarea si autentificarea utilizatorilor,definirea si lansarea unui trial,achizitia de date pentru trial,finalizarea si generarea rezultatelor statistice.Mai exista inca o componenta conexa acestora care contine toate functionalitatile neceare realizarii obiectivelor.

Inregistrarea si autentificarea utilizatorilor

Optiunea de inregistrare implica rezolvarea a trei probleme.Un utilizator este defapt o persoana care define o cheie de acces in aplicatie si poate avea unul sau mai multe roluri.In acest sens va trebui create trei entitati: una in care avem informatiile persoanei,una in care avem cheia de acces a utilizatorului si inca una in care avem starea utilizatorului si rolurile in aplicatie.Avand aceste entitati,baza optiunii de autentificare este facuta.La autentificarea utilizatorilor se va face o cautare printre informatiile entitatii de utilizatori care va avea legatura stabilita cu entitatiile de persoana si roluri.

Pentru a face cat mai usoara utilizarea aplicatiei vom folosi ca pagina de start pagina de autentificare a utilizatorilor.Astfel dupa accesarea linkului, utilizatorul va putea direct sa se autentifice,iar in cazul in care nu este inregistrat atunci va intra pe pagina de inregistrare.

Analizand mai in detaliu entitatile de utilizatori si rolurile acestora constatam ca un utilizator poate avea multiple roluri in aplicatie aceea ce vom avea nevoie de un continut dinamic.Rezolvarea acestui aspect se face introducand inca un pas,adica o pagina,in care utilizatorul va alege sub ce rol va utiliza aplicatia.Exemplu:Un doctor poate fi la randul lui un pacient si in alt caz coordonator de trial.Asta inseamna ca va avea trei optiuni disponibile in pagina de selectia a rolului.Informatiile referitoare la rolurile disponibile pentru acel utilizator vor fi preluate din entitatea de roluri.Aceasta selectie a rolurilor ne ajuta mai departe la delimitarea functionalitatilor in functie de roluri fara a supraincarca o pagina cu prea multe functionalitati.

Definirea si lansarea unui trial

Cel mai important element din acest proiect este trialul.In jurul acestui concept se construiesc celelalte entitati.Conform studiului despre trialuri facut in capitolul trei observam ca aceste este foarte customizabil.Nu exista o „reteta” generala a unui trial.Din aceste considerente alegem sa impartim conceptul de trial in doua entitati.Prima entitate care pastreaza informatiile necesare identificarii acestuia si a doua entitate care pastreaza caracteristicile trialului cum ar fi tipul acestuia,designul,esantioanele minime necesare, frecventa tratamentului, proportia bratelor si denumirile tratamentelor.Tipul si designul trialului sunt ele doua aspecte foarte variabile ceea ce forteaza sa eliminam replicarea datelor din entitati.Astfel in entitatea caracteristicilor trialului vom pastra doar identificatorii acestor aspecte care vor face legaturile intre alte doua entitati care modeleaza tipul trialului si designul.Pentru primul pas in definirea trialului mai avem nevoie doar de o singura entitate,aceea este entitatea in care pastram informatiile despre parametrii biologicii urmariti.In aceasta entitate se va pastra si perspectiva dorita a parametrului biologic (majorare sau micsorare) pentru a facilita mai apoi calculul rezultatelor statistice.Tot pentru a elimina replicarea datelor vom pastra in entitatea parametrilor monitorizati doar identificatori ai parametrilor biologici regasiti intr-o alta entitate specifica acestora.Toate aceste entitati le vom pune in contextul primului pas in definirea unui trial si vom creea o pagina pentru a realiza toate aceste setari.

Pasul al doilea in definirea trialului este acela de lansare a ipotezei.Conform studiului facut in capitolul trei stim ca aceasta ipoteza depinde de tipul si designul trialului ceea ce inseamna ca vom avea o dependenta de pasul anterior.In functie de setarile facute in primul pas vom crea un continut dinamic in care se va calcula numarul minim de subiecti necesari cu ajutorul formulelor matematice din capitolul 4.2.Dupa ce avem determinat acest numar putem trece la pasul urmator si sa salvam toate caracteristicile trialului.

Pasul al treilea tine de selectia persoanelor care vor presta servicii in cadrul trialului.Acest pas este un pas optionat,dar facand selectia putem avem o structura a persoanelor implicate in trial si putem afla un cost estimativ al trialului.Pentru acest pas avem nevoie de doua entitati si o pagina suplimentara in care sa se faca aceasta selectie.Prima entitate fiind vorba de entitatea in care pastram informatiile despre angajati si a doua in care pastram informatiile despre angajatii care lucreaza in fiecare trial. Entitatea ce face referire la angajati va trebui sa fie legata de entitatea cu persoane,deci vom pastra doar un identificator al persoanei si atributele ce definesc un angajat:functie, remuneratie lunara si eventuala emuneratie pentru activitati suplimentare.Fiecare angajat va avea un identificator unic care va fi regasit in entitatea ce face referire la angajatii care lucreaza in trial.

Pasul patru tine de selectia frecventei tratamentului si a echipamentelor utilizate pentru acest trial.Selectia frecventei tratamentului este obligatorie insa cea a echipamentelor este facultativa care va avea impact asupra costului estimativ de desfasurarea al trialului.In acest pas avem nevoie de o suplimentare a entitatilor,una fiind entitatea ce pastreaza informatii despre echipamente si inca o entitate care pastreaza informatiile despre echipamentele utilizate in desfasurarea fiecarui trial.Fiecare echipament va avea un identificator unic,o denumire si costul utilizarii acestuia intr-o zi. Identificatorul unic va fi regasit si in entitatea responsabila de gestiunea echipamentelor din trial.Vom crea si o pagina noua pentru a putea realiza toate aceste selectii.

Pasul cinci in definirea trialului este un pas mai complex.Acesta implica selectarea factorilor de includere si de excludere din trial precum si randomizarea subiectilor dupa aplicarea filtrarii in functie de factorii selectati. Factori de includere si de excludere din trial pot fi divizati in trei categorii: factori ce privesc parametrii biologici, factori ce privesc boli si factori de stratificare (varsta,sex,grupa sanguina,etc.).Pentru a modela toate aceste aspecte vom avea nevoie sa cream opt entitati noi.Primele doua entitati fac referire la categori de boli si bolile din acele categorii.Fiecare categorie va avea un identificator unic si o denumire.La fel ca si cazul categoriilor de boli,fiecare boala va avea un identificator unic,o denumire si va avea in plus identificatorul categoriei din care face parte.Urmatoarele doua entitati fac referire la categori ale factorilor de stratificare si factori de stratificare din aceste categorii.Fiecare categorie de factori de stratificare va avea un identificator si o denumire,iar factorii de stratificare vor avea si ei un identificator,o denumire si identificatorul categoriei din care fac parte.Ultimele patru entitati au legatura directa cu organizarea trialului.Pentru fiecare categorie de factori de includere si excludere din trial se va creaza o entitate.Entitatea in care se vor pastra factorii ce privesc parametrii biologici va avea identificatorul trialului la care se aplica factorul, identificatorul parametrului biologic,limita minima,limita maxima si inca un atribut care sa indice tipul factorului,includere sau excludere.La fel si in cazul entitatii care va pastra factorii cu privire la boli vom avea identificatorul trialului la care se aplica factorul,identificatorul bolii si atributul care indica tipul factorului.Entitatea in care vom pastra factorii ce privesc stratificarea va avea urmatoarele atribute: identificatorul trialului la care se aplica factorul,identificatorul categoriei factorului de stratificare,identificatorul factorului de stratificare,limita minima si limita maxima in cazul unui factor de stratificare dinamic si atributul de diferentiere (includere sau excludere).Din ultimele patru entitati pe care trebuie sa le cream mai ramane cea de identificare a pacientilor din trial.Pacientii din trial se numeste subiecti,asa ca vom avea o entitate cu subiectii trialului. In aceasta entitate vom pastra identificatorul trialului din care face parte,identificatorul persoanei,data de inrolare in trial,data iesirii din trial si numarul grupului din care face parte.

In procesul de randomizare vom lucra cu urmatoarele concepte: trial,persoana, pacient,fisa medicala,diagnostic,analiza,factori de includere si de excludere.Observam ca notiunile de pacient,fisa medicala,diagnostic si analiza nu sunt inca definite.Pentru a reutiliza munca deja facuta putem considera ca un pacient este o persoana care are definita o fisa medicala in sistem.Atfel vom aveam o entitate in care se pastrea informatiile despre fisele medicale.Fiecare fisa medicala va contine identificatorul persoanei,grupa sanguina,greutatea corporala,observatii si un identificator al unei liste de diagnostice.Lista de diagnostice este defapt tot o entitate in care vom avea identificatorul acesteia,identificatorul bolii din entitatea de boli,starea bolii,o descriere optionala a diagnosticului si data diagnosticarii.Dinte conceptele cu care vom lucra in procesul de randomizare mai ramane sa definim entitatea de analize.Acesta entitate va contine buletinul de analize a fiecarui pacient,deci conditia necesara ca o persoana sa aiba analize in sistem este sa aiba definita o fisa medicala.Fiecare analiza este defapt o valoare asociata unui parametru biologic.Pentru entitatea de analize avem nevoie de urmatoarele atribute: identificatorul peroanei,identificatorul parametrului biologic, valoarea si data analizei.Procesul de randomizare efectiva a subiectilor va fi disponibil in doua optiuni,randomizare a pacientilor din baza de date si randomizare pe baza unui fisier cu identificatori ai persoanelor.Pentru prima optiune se vor executa o serie de etape dupa cum urmeaza:

Se cauta in sistem toate fisele medicale disponibile

Se preiau factorii definiti si se impart in liste pe categorii de includere si de excludere.

Se aplica filtrul de excludere

Se aplica filtrul de includere in care se calculeaza si punctajul fiecarui pacient

Se impart pacientii in fiecare grupa a trialului conform proportie si punctajului obtinut prin aplicarea filtrului de includere,garantand ca exista un echilibru in fiecare grupa.

Avand toate entitatile definite si legaturile dintre ele putem sa intram in detaliul de design al interfetei utilizator.Utilizatorul trebuie sa faca selectia factorilor si randomizarea pacientilor intr-o singura pagina.Astfel vom avea pagina impartina in doua sectiuni,prima cea de selectia,iar a doua cea de randomizare.Utilizatorul trebuie sa vada fiecare tip de factor definit si sa poata sa stearga factorii definiti in cazul unei erori.In sectiunea de randomizare utilizatorul va trebui sa aiba posibilitatea de incarcare a fisierului cu persoanele care urmeaza sa fie randomizate pe langa optiunea de randomizare a pacientilor direct din baza de date.

Pasul sase in definirea trialului este defapt ultimul pas in care vom avea un sumar a tuturor informatiilor introduse si a selectiilor facute.Aici vom avea calculat si costul estimativ al trialului.Pentru acest pas nu este necesar sa suplimentam numarul entitatilor ci doar sa avem o interfata utilizator care sa expuna toate informatiile propuse.Aceasta pagina o vom imparti in patru: zona de informatii despre trial impreuna cu caracteristicile asociate,zona listei de echipamentelor folosite,zona listei de angajati care vor presta servicii in trial si zona listei de subiecti gata randomizati.Daca totul este in regula se va salva definirea trialului sau se va anula in cazul in care definirea a fost incorecta.

O data ce trialul este definit acesta poate fi lansat,cu conditia ca pragul esantionului minim a fost atins.Lansarea si finalizarea este de preferat sa se execute dintr-o pagina separata de cele mentionata pana acum.In aceasta pagina avem nevoie de a afisa o lista doar cu trialurile coordonatorului care le-a definit si cele doua optiuni,lansare si finalizare.Optiunea finalizare va fi explicata in subcapitolul 4.3.4.Pentru realizarea lansarii avem nevoie doar de data acestui fapt.Cu aceasta data vom face actualizarea datei de inceput din entitatea cu trialuri.

Achizitia de date pentru trial

Aceasta operatiune este defapt preluarea perioda a analizelor pacientilor din fiecare trial lansat.Achizitia datelor pentru trial o pot realiza doar doctorii,asistentii si pacientii inscris in trialuri in desfasurare.Pacientii vor avea restrictie la adaugarea analizelor,putand sa introduca doar analize personale.Pentru pastrarea acestor analize in sistem avem nevoie de o entitate cu rolul de istoric medical pentru fiecare trial.In aceasta entitate vom avea identificatorul trialului,identificatorul persoanei careia s-a preluat analiza,identificatorul parametrului biologic,valoarea parametrului si data analizei. Justificarea acestui design al entitatii este ca se elimina replicarea datelor,iar identificatorii trialului si ale persoanelor sunt mult mai usor de aflat decat cautarea dupa denumirea trialurilor si numele pacientilor.

Pentru fiecare utilizator care poate realiza achizitia de date vom avea o pagina separata.In cazul pacientului,pagina va avea informatii doar in cazul in care acesta este inscris intr-un trial in desfasurare si ii se vor afisa doar parametrii biologici urmariti in acel trial pentru a evita inregistrari eronate de analize.Doctorii si asistentii vor putea prelua analize de la toti pacientii din toate trialurile in desfasurare.Pentru acestia preluarea de analize trebuie facuta in mai multi pasi.Primul pas este cel de selectie a trialului in cauza,care va actualiza o lista a subiectilor din acel trial,pasul doi este cel de selectia a subiectului la care se preia analiza,pasul trei actionarea unui element din interfata astfel incat sa pregatesca parametrii biologici urmariti in trialul selectat si sa se genereze o legatura a analizei cu trialul si persoana.Ultimul pas este cel de introducere a valorilor pentru parametrii si selectarea datei in care s-a realiza analiza.

Finalizarea trialului si generarea rezultatelor statistice

Finalizarea trialului reprezinta terminarea perioadei alocate studiului subiectilor. Exista totusi o exceptie in care trialul poate fi finalizat atunci cand coordonatorul considera ca administrarea tratamentului pune in pericol starea de sanatate sau chiar viata subiectilor.Asta inseamna ca pentru aceasta optiune nu putem realiza o constrangere. Singura restrictie poate fi pusa ca un trial sa fie finalizat doar daca a fost in prealabil lansat.Aceasta operatiune va fi disponibila in pagina de lansare si finalizare a trialurilor de care am pomenit in subcapitolul 4.2.1.Exact ca si pentru operatiunea de lansare si in cazul finalizarii avem nevoie de data acestui fapt cu care vom actualiza data finalizarii trialului din entitatea corespunzatoare.Dupa ce se seteaza data finalizarii trialului se porneste procesul de generare a rezultatelor statistice care respecta urmatorii pasi:

Se preiau toti parametrii biologici urmariti in trial.

Se preiau toti subiectii din trial si se repartizeaza pe grupe.

Se verifica pentru fiecare parametru biologic urmarit in trial evolutia fiecarui pacient.Daca persoana a raspuns tratamentului conform predictiei parametrului atunci va fi contabilizat la calculul statistic.Verificarea evolutiei pacientului se face pe baza informatiilor din entitatea istoricului medical al trialului.

Se executa pasul trei si in cazul echipei celelalte daca studiul trialului implica studiul a doua grupe.

Se calculeaza rata de raspuns si media de raspuns a pacientilor pentru fiecare grupa conform datelor identificate.

Se insereaza rezultatele in enitatea ce pastreaza rezultatele statistice ale trialurilor.

Dupa ce rezultatele statistice ajung in entitatea corespunzatoare face posibila afisarea acestora celorlalti utilizatori.

Functionalitati conexe folosite la indeplinirea obiectivelor

In acest moment avem analizate toate componentele importante insa doar cu acestea nu am inca un sistem complet si independent.Vom lua pe rand in ordinea in care am prezentat componentele importante din subcapitolele 4.3.1-4.3.4 si vom explica nevoia unor functionalitati conexe care sa ne asigure independeta sistemului si completitudinea.

Functionalitati conexe in contexul utilizatorilor

Avem nevoie de un modul in care se poate realiza managementul utilizatorilor. Acest management cuprinde: acordarea sau revocarea accesului in aplicatie,acordarea sau revocarea rolurilor unui utilizator, stergerea utilizatorilor inactivi.Pentru toate aceastea avem nevoie de un utilizator cu drepturi superioare care va fi un administrator de utilizatori.Administratorul va putea realiza aceste o operatiuni dintr-o pagina separata dedicata exclusiv acestuia.In cazul acordarii sau revocarii accesului in aplicatie va fi o simpla actualizare a unui status care sa indice acest fapt.La acordarea sau revocarea rolurilor in aplicatie se vor folosi variabile bivalente numerice pentru fiecare rol posibil care pot lua valori doar in multimea finita {0,1}.Zero insemnand ca utilizatorul nu are acel rol,iar unu inseamna ca detine acel rol.Stergerea din sistem implica doar stergerea utilizatorului nu si a persoanei in sine.

Functionalitati conexe in contexul datelor din sistem

Se pune problema cine va putea actualiza datele din sistem.De exemplu introducerea unei categorii noi de boli sau o boala noua,echipamente noi,etc.La aceasta problema putem gasi rezolvarea adaugand un nou rol in aplicatie cel de administrator baza de date.Administratorul va putea realiza aceste optiuni de intretinere a bazei de date dintr-o pagina separata dedicata exclusiv acestuia.Pentru a nu incarca o pagina cu prea multe elemente de interfata grafica alegem ca aceasta pagina sa faca referire doar la posibilitatile de management asupra datelor pe care le va putea realiza administratorul. Asta inseamna ca va avea disponibile trei optiuni de management: al persoanelor,al echipamentelor si a datelor medicale.Pentru fiecare optiune de management se creaza o pagina separata.In pagina de management al persoanelor,administratorul va putea adauga persoane noi,angajati noi si va putea sterge persoane si angajati.In pagina de management al echipamentelor va putea adauga,modifica costul utilizarii pe o zi a unui echipament si sterge echipamente,iar in pagina de management al datelor medicale va putea insera sau sterge categorii de boli si insera respectiv sterge boli din fiecare categorie existenta.

Functionalitati conexe in contexul vizualizarii evolutiei subiectilor din trial

Tinand cont ca deobicei trialurile se desfasoara pe o perioada indelungata de timp apare nevoia de a vizualiza evolutia subiectior chiar in timpul desfasurarii si dupa finalizare.Va trebui sa cream doua module in care sa afisam aceasta evolutie.Un modul pentru trialurile in desfasurare si un modul pentru trialurile finalizate.S-a ales aceasta varianta deoarce nu toti utilizatorii au dreptul sa vizualizele trialurile in desfasurare din motive de confidentialitate a datelor.Utilizatorii cu rol de doctor si asistent vor putea vizualiza evolutia subiectilor in amandoua module.Coordonatorul de trial va putea vizualiza evolutia subiectilor doar din trialurile definite de acesta chiar daca sunt in desfasurare,iar pacientul va putea vizualiza doar evolutia persoana din trialul in desfasurare la care este inrolat si evolutia subiectilor din trialurile finalizate.Pentru fiecare utilizator vom vrea o pagina separata in care sa vizualizeze aceaste evolutii,exceptie facand coordonatorul de trial care va putea vizualiza evolutia subiectiilor dintr-o singura pagina atat pentru trialurile in desfasurare cat si pentru cele finalizate.Datele cu care se vor construi graficele de evolutie a subiectiilor se vor prelua din entitatea cu istoricul medical al fiecarui trial.

Functionalitati conexe in contexul invitatiilor si solicitarilor de inrolare in trial

Posibilitatea ca in baza de date cu pacienti sa nu existe numarul necesar de pacienti care sa respecte filtrele de includere si de excludere este relativ mare.De aceea s-a decit ca inrolarea in trial sa fie disponibila si dupa procesul de randomizare.Aceasta inrolare se poate realiza sub forma unor invitatii trimise pe adresa de email de catre coodonatori si la randul lor pacientii sa solicite inrolarea in trial trimitand o cerere.Avand in vedere ca doar pacientii si coodonatorii trialurilor pot executa aceste optiuni vom crea doar doua pagini separate de management al invitatiilor si solicitarilor.Pentru a tine evidenta acestora avem nevoie de o entitate suplimentara in care sa pastram informatii cu privire la invitatii.Aceasta trebuie sa contina identificatorul trialului in care se doreste inrolarea sau pentru care se trimite invitatia,identificatorul persoanei careia a trimis solicititarea sau cui i se trimite invitatia si inca un atribut care sa indice faptul daca este o solicitare sau invitatie.Entitatea va juca rolul unei liste de mesaje.Cand coodonatorul accepta solicitarea atunci se sterge invitatia din evidenta si se adauga pacientul in lista de subiecti al trialului respectiv.In cazul unui refuz se sterge invitatia din evidenta.Pentru ambele cazuri se trimit notificari pe adresa de email.Daca un pacient primeste o invitatie de inrolare in trial acesta o poate accepta si atunci se sterge invitatia din entitate apoi se adauga pacientul in lista de subiecti,iar daca pacientul refuza invitatia se va executa doar o operatiune de stergerea a invitatiei din evidenta.La fel ca si in cazul solicitariilor si la acceptul sau refuzul unei invitatii se vor trimite notificari prin email.

Functionalitati conexe in contexul fiselor medicale

O persoana este considerata pacient atunci care in sistem exista o fisa medicala asignata acestuia.Datorita faptului ca in sistem oricand pot aparea persoanei noi necesita introducerea unei metode de diferentiere dintre persoane si pacienti.Aceasta diferentiere o va putea face doar utilizatorul cu rol de doctor care va avea o pagina separata unde sa poata realiza managementul fiselor medicale.Entitatile legate de fise medicale,diagnostice si analize au fost prezentate in subcapitolul 4.3.2.Acum vom prezenta mai pe larg doar legaturi dintre acestea si utilitatea lor.In aceasta pagina de management al fiselor medicale,doctorul va putea adauga o fisa medicala pentru o persoana sau sa stearga fisa medicala din sistem atunci cand este cazul.Unei fise medicale ii este asociata o lista de diagnostice.Tot doctorul va putea actualiza datele aceste liste prin operatii de inserare a diagnosticelor noi si de stegere a acelora care nu sunt de actualitate.Fisei medicale ii mai este asociat si un buletin de analize.Aceste analize sunt separate de cele din istoricul medical al fiecarui trial.In cazul acestor analize este valabila doar operatia de inserare,iar analizele care nu sunt de actualitate vor aparea la coada listei.Ordonarea facandu-se dupa data preluarii analizei.Toate aceste informatii sunt disponibile spre vizualizare si pentru pacient intr-o pagina separata de cea a managementului fiselor medicale.Acesta putand sa isi vada fisa medicala,diagnosticele puse de doctori si istoricul analizelor.

Tipuri de utilizatori si cazurile de utilizare aferente

Tipuri de utilizatori

Pentru a separa informatiile si functionalitatile in functie de nevoile si competentele utilizatorilor s-a optat pentru definirea mai multor roluri in aplicatie.In figura 4.3.1.1 puteti observa tipurile de utilizatori in functie de roluri.

Exista doua tipuri de administratori in aceasta aplicatie.Administratori de baze de date responsabili de intretinerea informatiilor din baza de date.Administratori de utilizatori care sunt responsabili de autorizarea utilizatorilor in aplicatiei si stergerea lor acolo unde este cazul.La fel ca si in cazul utilizatorilor exista doua tipuri de cadre medicale care pot utiliza aplicatia si anume:doctorul si asistentul.Acestia pot introduce date pentru trialurile definite si vizualiza rezultatele statistice ale trialurilor.Diferentierea dintre aceste doua tipuri de utilizatori este ca doctorul poate sa se ocupe de gestiunea pacientilor.Utilizatorii cu rolul de coordonator trial vor avea acces doar la trialurile definite de aceastia,iar utilizaorii cu rolul de pacient vor avea acces doar la informatii personale si la trialurile finalizate pentru a putea pastra confidentialitatea datelor din trialurile in desfasurare.

Cazuri de utilizare

Cazurile de utilizare vor explica mai exact fluxul de lucru al operatiunilor pe care fiecare utilizator poate sa le savarseaza.Prezentarea acestora va fi facuta dupa modelul standard din Unified Process.Mai intai vom explica cazurile de utilizare comune fiecarui utilizator.

Nume caz de utilizare: Autentificare

Actor primar: Persoana inregistrata deja

Partile implicate si interesele lor:

Persoana inregistrata deja doreste sa se autentifice.

Preconditii:

Sistemul sa fie disponibil si persoana sa fie inregistrata.

Postconditii:

Utilizatorul sa fie logat in aplicatie.

Scenariul de succes:

Utilizatorul acceseaza link-ul aplicatie.

Introduce credentialele.

Actioneaza butonul de autentificare.

Sistemul autorizeaza operatiunea.

Extensii:

3a. Credentiale incorecte:

1.Sistemul va directiona persoana intr-o zona restrictionata.

Nume caz de utilizare: Inregistrare

Actor principal: Persoana neinregistrata

Partile implicate si intereselor:

Persoana doreste inregistrarea sa in sistem.

Preconditii:

Sistemul sa fie disponibil.

Postconditii:

Persona sa fie inregistrata.

Scenariul de succes:

Persoana acceseaza link-ul aplicatiei.

Actioneaza butonul de inregistrare.

Persoana introduce numele de utilizator,parola,nume,prenume,adresa,adresa de e-mail telefon,sex,data nasterii,rolul in aplicatie,fisa de acces.

Actioneaza butonul de finalizare a inregistrarii.

Sistemul salveaza inregistrarea persoanei.

Extensii:

3a.Persoana introduce date incorecte:

1.Sistemul avertizeaza persoana cu scopul de corectare.

4.aPersoana renunta la inregistrare:

1.Sistemul anuleaza stadiul inregistrarii si directioneaza pe pagina de start.

Nume caz de utilizare: Deconectare

Actor principal: Utilizatorul

Partile implicate si intereselor:

Utilizatorul doreste deconectarea din aplicatie.

Preconditii:

Utilizatorul sa fie autentificat.

Postconditii:

Utilizatori sa fe deconectat.

Scenariul de succes:

Actioneaza butonul de deconectare.

Sistemul deconecteaza utilizatorul.

Cazurile de utilizare aferente coordonatorului de trial

In figura 4.3.2.1.1 puteti observa diagrama cazurilor de utilizare aferente coordonatorului de trial.

Nume caz de utilizare: Definire trial

Actor principal: Coordonator trial

Partile implicate si interesele lor:

Coordonatorul doreste definirea unui trial nou pentru compararea tratamentelor.

Preconditii:

Utilizatorul sa fie autentificat.

Postconditii:

Trialul sa fie definit cu succes.

Scenariul de succes:

Actioneaza butonul de definire trial

Introduce numele trialului,o scurta descriere,perioada de desfasurare,tipul trialului,design-ul trialului

Selecteaza parametrii biologici urmariti in trial

Actioneaza butonul de directionare la pasul urmator

Introduce denumirile tratamentului/tratamentelor,selecteaza parametrii statistici si proportia bratelor

Actioneaza butonul de calculare a esantionului minim

Actioneaza butonul de directionare la pasul urmator

Selecteaza persoanele implicate in trial

Actioneaza butonul de directionare la pasul urmator

Selecteaza echipamentele utilizate in trial si frecventa tratamentului

Actioneaza butonul de directionare la pasul urmator

Selecteaza factorii de includere si de excludere

Actioneaza butonul de randomizare a pacientilor

Actioneaza butonul de directionare la pasul urmator

Vizualizeaza sumarul selectiilor facute si actioneaza butonul de salvarea a definirii trialului

Sistemul salveaza definirea trialului

Extensii:

2a.Coordonatorul nu introduce unul sau mai multe elemente din cele solicitate

1.Sistemul avertizeaza lipsa datelor

3a.Coordonatorul nu selecteaza parametrii biologici urmariti

1.Sistemul avertizeaza lipsa setarii parametrilor

13a.Coordonatorul nu apasa butonul de randomizare a pacientilor

1.Sistemul directioneaza utilizatorul la pasul urmator fara a randomiza pacientii

15a.Coordonatorul actioneaza butonul de anularea a definirii trialului

1.Sistemul anuleaza definirea trialului

2.Directioneaza utilizatorul pe pagina cu optiuni disponibile

Nume caz de utilizare: Lansare trial

Actor principal: Coordonator trial

Partile implicate si interesele lor:

Coordonatorul doreste lansarea trialului.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie definit.

Postconditii:

Trialul sa fie lansat.

Scenariul de succes:

Actioneaza butonul de directionare la trialurile definite.

Selecteaza data lansarii pentru trial in cauza.

Actioneaza butonul de lansare a trialului.

Sistemul lanseaza trialul.

Extensii:

1a.Coordonatorul nu are nici un trial definit:

1.Sistemul nu va afisa nici o inregistrare in tabelul cu trialuri.

3a.Coordonatorul lanseaza trialul dar nu esantionul minim nu a fost atins:

1.Sistemul va avertiza acest aspect.

Nume caz de utilizare: Finalizare trial

Actor principal: Coordonator trial

Partile implicate si interesele lor:

Coordonatorul doreste finalizarea trialului.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie definit.

Postconditii:

Trialul sa fie finalizat.

Scenariul de succes:

Actioneaza butonul de directionare la trialurile definite.

Selecteaza data finalizarii .

Actioneaza butonul de finalizare trial.

Sistemul finalizeaza trialul.

Extensii:

1a.Coordonatorul nu are nici un trial definit:

1.Sistemul nu va afisa nici o inregistrare in tabelul cu trialuri.

Nume caz de utilizare: Timitere invitatie de inrolare in trial

Actor principal: Coordonator trial

Partile implicate si interesele lor:

Coordonatorul doreste trimiterea unei invitatii de inrolare.

Persoana caruia i se adreseaza invitatia sa o primeasca

Preconditii:

Utilizatorul sa fie autentificat.

Trialul pentru care se trimite invitatia sa fie definit.

Persoana la care se doreste trimiterea invitatie sa fie in sistem.

Postconditii:

Invitatia sa fie trimisa persoanei corecte pentru trialul ales.

Scenariul de succes:

Actioneaza butonul de directionare la managementul invitatiilor.

Selecteaza trial pentru care se trimite invitatia.

Actioneaza butonul de trimitere a invitatie pentru persoana corespunzatoare.

Sistemul trimite invitatie persoanei alese.

Extensii:

2a. Coordonatorul nu are nici un trial definit

1.Sistemul nu va afisa nici o inregistrare in tabelul cu trialuri

3a. Nu exista persoane in sistem

1.Sistemul nu va afisa nici o inregistrare in tabelul cu persoane

Nume caz de utilizare: Accepta/refuza solicitarea de inrolare in trial

Actor principal: Coordonator trial

Partile implicate si interesele lor:

Coordonatorul doreste acceptarea/refuzarea solicitarii de inrolare in trial a unei persoane.

Persoana doreste sa aiba raspuns la solicitarea facut.

Preconditii:

Utilizatorul sa fie autentificat.

Sa existe solicitari inregistrate.

Postconditii:

Solicitarea de inrolare sa fie accepta/refuzata.

Persoana care a solicitat inrolarea sa primeasca raspunsul.

Scenariul de succes:

Actioneaza butonul de directionare la managementul invitatiilor.

Selecteaza panoul cu lista solicitarilor primite.

Actioneaza butonul de acceptare/refuzare pentru solicitarea in cauza.

Sistemul marcheaza solicitarea ca fiind accepta/refuzata.

Extensii:

3a.Coordonatorul nu are nici o solicitare de inrolare primita:

1.Sistemul nu va afisa nici o inregistrare in lista solicitarilor.

Nume caz de utilizare: Vizualizare rezultate statistice

Actor principal: Coordonator trial

Partile implicate si interesele lor:

Coordonatorul doreste sa vizualizeze rezultatele statistice ale unui trial.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie definit si lansat.

Postconditii:

Rezultatele statistice sa fie afisate.

Scenariul de succes:

Actioneaza butonul de directionare la trialurile definite

Actioneaza butonul de vizualizare a rezultatelor pentru trialul corespunzator.

Sistemul afiseaza rezultatele statistice.

Extensii:

2a. Coordonatorul nu are lansat nici un trial.

1.Sistemul nu va afisa nici o inregistrare in lista trialurilor

2b.Nu exista date achizitionate pentru acel trial lansat

1.Sistemul va afisa o statistica nula pentru acel trial

Nume caz de utilizare: Vizualizare grafica a evolutie pacientilor

Actor principal: Coodonator trial

Partile implicate si interesele lor:

Coordonatorul doreste vizualizarea grafica a evolutie pacientilor dintr-un anumit trial si pentru un grup anume.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul sa fie definit si lansat.

Postconditii:

Graficul de evolutie al pacientilor sa fie afisat.

Scenariul de succes:

Actioneaza butonul de directionare la trialurile definite.

Selecteaza trialul

Selecteaza parametrul urmarit

Actioneaza butonul de afisare grafic

Sistemul afiseaza graficul

Extensii:

2a.Coordonatorul nu are lansat nici un trial.

1.Sistemul nu va afisa nici o inregistrare in lista trialurilor

4.Nu exista date achizitionate pentru acel trial lansat

1.Sistemul nu va genera nici un grafic

Cazurile de utilizare aferente doctorului

In figura 4.3.2.2.1 puteti observa diagrama cazurilor de utilizare aferente doctorului.

Nume caz de utilizare: Adauga fisa medicala

Actor principal: Doctor

Partile implicate si interesele lor:

Doctorul doreste inregistrarea unei persoane ca pacient.

Pacientul sa aiba fisa medicala in sistem.

Preconditii:

Utiliatorul sa fie autentificat.

Persoana sa existe in sistem.

Postconditii:

Pacientul sa aiba adaugata fisa medicala in sistem

Scenariul de succes:

Actioneaza butonul de directionare la managementul fiselor medicale.

Actioneaza butonul de adaugarea a fisei medicale pentru persoana in cauza.

Completeza grupa sanguiva,greutate si alte observatii.

Actioneaza butonul de salvarea a fisei medicale.

Sistemul adauga fisa medicala.

Extensii:

4a.Doctorul nu actioneaza butonul de salvarea fisei medicale:

1.Sistemul anula solicitarea facuta.

Nume caz de utilizare: Sterge fisa medicala

Actor principal: Doctor

Partile implicate si interesele lor:

Doctorul doreste stergerea fisei medicale a pacientului.

Pacientul doreste stergerea sa din evidenta medicala.

Preconditii:

Utilizatorul sa fie autentificat.

Persoana sa existe in sistem.

Persoana sa aiba o fisa medicala in sistem.

Postconditii:

Fisa medicala sa fie stearsa.

Scenariul de succes:

Actioneaza butonul de directionare la managementul fiselor medicale.

Actioneaza butonul de stergere a fisei medicale pentru pacientul in cauza.

Sistemul sterge fisa medicala.

Nume caz de utilizare: Adauga diagnostic pacientului

Actor principal: Doctor

Partile implicate si interesele lor:

Doctorul doreste adaugarea unui diagnostic pacientului.

Pacientul doreste ca fisa medicala sa fie actualizata.

Preconditii:

Utilizatorul sa fie autentificat.

Persoana sa existe in sistem.

Persoana sa aiba o fisa medicala definita.

Postconditii:

Diagnosticul sa fie introdus.

Scenariul de succes:

Actioneaza butonul de directionare la managentul fiselor medicale.

Selecteaza pacientul.

Actioneaza butonul de adaugare a unui nou diagnostic.

Selecteaza boala/simptomul,starea acesteia,data diagnosticului.

Actioneaza butonul de salvarea a diagnosticului.

Sistemul adauga diagnosticul.

Extensii:

5a.Doctorul nu actioneaza butonul de salvare a diagnosticului:

1.Sistemul va anula solicitarea facuta.

Nume caz de utilizare: Sterge diagnosticul pacientului

Actor principal: Doctor

Partile implicate si interesele lor:

Doctorul doreste stergerea unui diagnostic care nu mai este de actualitate

Pacientul doreste ca fisa medicala sa fie actualizata

Preconditii:

Utilizatorul sa fie autentificat.

Persoana sa existe in sistem.

Persoana sa aiba o fisa medicala definita.

Persoana sa aiba diagnosticul respectiv.

Postconditii:

Diagnosticul sa fie sters.

Scenariul de succes:

Actioneaza butonul de directionare la managementul fiselor medicale

Selecteaza pacientul

Actioneaza butonul de stergerea a diagnosticului

Sistemul sterge diagnosticul

Nume caz de utilizare: Adauga analize pentru pacient

Actor principal: Doctor

Partile implicate si interesele lor:

Doctorul doreste adaugarea unei analize noi pentru pacient.

Pacientul doreste ca buletinul de analize sa fie actualizat.

Preconditii:

Utilizatorul sa fie autentificat.

Persoana sa existe in sistem.

Persoana sa aiba fisa medicala

Postconditii:

Analiza sa fie adauga.

Scenariul de succes:

Actioneaza butonul de directionare la managementul fiselor medicale

Selecteaza pacientul

Actioneaza butonul de adaugarea a unei analize

Selecteaza parametru biologic,valoarea parametrului si data analizei

Actioneaza butonul de salvarea a analizei.

Sistemul salveaza analiza.

Extensii:

4a.Doctorul nu selecteaza valoarea sau data analizei.

1.Sistemul va avertiza lipsa datelor.

Nume caz de utilizare: Vizualizare grafic evolutie pacienti din trialurile in desfasurare

Actor principal: Doctor

Partile implicate si interesele lor:

Doctorul doreste vizualizarea grafica a evolutiei pacientilor din trialurile in desfasurare.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie nefinalizat.

Postconditii:

Afisarea graficului ce reprezinta evolutia pacientilor din acel trial.

Scenariul de succes:

Actioneaza butonul de directionare la triaurile in desfasurare.

Selecteaza trialul in cauza.

Selecteaza parametru pentru care se doreste constructia graficului.

Actioneaza butonul de afisarea a graficului.

Sistemul va afisa graficul.

Extensii:

2a.Nu exista trialuri in desfasurare:

1.Sistemul nu va afisa nici o inregistrare in lista de trialuri

Nume caz de utilizare: Export date achizitionate in trial

Actor principal: Doctor

Partile implicate si interesele lor:

Doctorul doreste sa descarce datele achizitionate in trial sub forma unui fisier microsoft excel.

Preconditii:

Utilizatorul sa fie autentificat

Trialul sa fie finalizat.

Postconditii:

Fisierul cu datele achizitionate in trial sa fie disponibil pentru descarcare.

Scenariul de succes:

Actioneaza butonul de directionare la trial finalizate.

Selecteaza trialul.

Actioneaza butonul de export al datelor.

Sistemul pune la dispozitie fisierul pentru a fi descarcat.

Extensii:

2a.Nu exista trialuri finalizate:

1.Sistemul nu va afisa nici o inregistrare in lista de trialuri.

Nume caz de utilizare: Vizualizare grafic evolutie pacienti din trialuri incheiate

Actor principal: Doctor

Partile implicate si interesele lor:

Doctorul doreste sa vizualizele graficul evolutie pacientilor dintr-un trial incheiat.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie finalizat.

Postconditii:

Afisarea graficului ce reprezinta evolutia pacientilor in trial.

Scenariul de succes:

Actioneaza butonul de directionare la trialurile finalizate.

Selecteaza trialul in cauza.

Actioneaza butonul de vizualizare a graficelor.

Selecteaza parametrul biologic pentru care se va construi graficul.

Actioneaza butonul de afisarea a graficului.

Sistemul va afisa graficul solicitat.

Extensii:

2a.Nu exista trialuri finalizate:

1.Sistemul nu va afisa nici o inregistrare in lista de trialuri.

Nume caz de utilizare: Vizualizare rezultate statistice pentru trialurile incheiate

Actor principal: Doctor

Partile implicate si interesele lor:

Doctorul doreste sa vizualizeze rezultatele statistice pentru un trial finalizat.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie finalizat.

Postconditii:

Rezultatele statistice sa fie afisate.

Scenariul de succes:

Actioneaza butonul de directionare la trialurile finalizate

Selecteaza trialul in cauza

Sistemul va actualiza rezultatele statistice pentru trialul ales

Nume caz de utilizare: Adauga analize pentru pacienti din trialuri

Actor principal: Doctor

Partile implicate si interesele lor:

Doctorul doreste sa insereze in istoricul medical al trialului analiza unui pacient.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie lansat si nefinalizat.

Persoana in cauza sa fie inrolata in trial.

Postconditii:

Analiza sa fie adauga in istoricul medical al trialului.

Scenariul de succes:

Actioneaza butonul de directionare la zona de achizitionat date pentru trial.

Selecteaza trialul.

Sistemul va actualiza lista pacientilor inrolati conform trialului selectat.

Selecteaza persoana.

Actioneaza butonul de adaugarea a analizei.

Sistemul afiseaza doar parametrii biologii urmariti in trialul selectat.

Introduce valoarea si data analizei pentru paramatrul biologic corespunzator

Actioneaza butonul de salvarea a analizei.

Sistemul va inregistra analizat.

Extensii:

7a.Doctorul nu introduce valoarea parametrului sau data analizei:

1.Sistemul va avertiza lipsa datelor.

9a.S-a preluat anterior o analiza pentru pacientul respectiv din data selectata

1.Sistemul va avertiza duplicitatea datelor si va anula adaugarea.

9b.S-a depasit frecventa tratamentului pe acea saptamana:

1.Sistemul va avertiza limitarea analizelor conform limitei setate si va anula analiza.

Cazurile de utilizare aferente asistentului

In figura 4.3.2.3.1 puteti observa diagrama cazurilor de utilizare aferente asistentului.

Nume caz de utilizare: Adauga analiza pentru pacient din trial

Actor principal: Asistent

Partile implicate si interesele lor:

Asistentul doreste sa insereze in istoricul medical al trialului analiza unui pacient.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie lansat si nefinalizat.

Persoana in cauza sa fie inrolata in trial.

Postconditii:

Analiza sa fie adauga in istoricul medical al trialului.

Scenariul de succes:

Actioneaza butonul de directionare la zona de achizitionat date pentru trial.

Selecteaza trialul.

Sistemul va actualiza lista pacientilor inrolati conform trialului selectat.

Selecteaza persoana.

Actioneaza butonul de adaugarea a analizei.

Sistemul afiseaza doar parametrii biologii urmariti in trialul selectat.

Introduce valoarea si data analizei pentru paramatrul biologic corespunzator

Actioneaza butonul de salvarea a analizei.

Sistemul va inregistra analizat.

Extensii:

7a.Asistentul nu introduce valoarea parametrului sau data analizei:

1.Sistemul va avertiza lipsa datelor.

9a.S-a preluat anterior o analiza pentru pacientul respectiv din data selectata

1.Sistemul va avertiza duplicitatea datelor si va anula adaugarea.

9b.S-a depasit frecventa tratamentului pe acea saptamana:

1.Sistemul va avertiza limitarea analizelor conform limitei setate si va anula analiza.

Nume caz de utilizare: Vizualizare grafic evolutie pacienti din trialurile in desfasurare

Actor principal: Asistent

Partile implicate si interesele lor:

Asistent doreste vizualizarea grafica a evolutiei pacientilor din trialurile in desfasurare.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie nefinalizat.

Postconditii:

Afisarea graficului ce reprezinta evolutia pacientilor din acel trial.

Scenariul de succes:

Actioneaza butonul de directionare la triaurile in desfasurare.

Selecteaza trialul in cauza.

Selecteaza parametru pentru care se doreste constructia graficului.

Actioneaza butonul de afisarea a graficului.

Sistemul va afisa graficul.

Extensii:

2a.Nu exista trialuri in desfasurare:

1.Sistemul nu va afisa nici o inregistrare in lista de trialuri

Nume caz de utilizare: Vizualizare rezultate statistice pentru trialuri incheiate

Actor principal: Asistent

Partile implicate si interesele lor:

Asistentul doreste sa vizualizeze rezultatele statistice pentru un trial finalizat.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie finalizat.

Postconditii:

Rezultatele statistice sa fie afisate.

Scenariul de succes:

Actioneaza butonul de directionare la trialurile finalizate

Selecteaza trialul in cauza

Sistemul va actualiza rezultatele statistice pentru trialul ales

Nume caz de utilizare: Vizualizare grafic evolutie pacienti din trialuri incheiate

Actor principal: Asistent

Partile implicate si interesele lor:

Asistenul doreste sa vizualizele graficul evolutie pacientilor dintr-un trial incheiat.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie finalizat.

Postconditii:

Afisarea graficului ce reprezinta evolutia pacientilor in trial.

Scenariul de succes:

Actioneaza butonul de directionare la trialurile finalizate.

Selecteaza trialul in cauza.

Actioneaza butonul de vizualizare a graficelor.

Selecteaza parametrul biologic pentru care se va construi graficul.

Actioneaza butonul de afisarea a graficului.

Sistemul va afisa graficul solicitat.

Extensii:

2a.Nu exista trialuri finalizate:

1.Sistemul nu va afisa nici o inregistrare in lista de trialuri.

Cazurile de utilizare aferente administratorului de utilizatori

In figura 4.3.2.4.1 puteti observa diagrama cazurilor de utilizare aferente administratorului de utilizatori.

Nume caz de utilizare: Acorda/revoca accesul utilizatorului in aplicatie

Actor principal: Administrator de utilizatori

Partile implicate si interesele lor:

Administratorul de utilizatori doreste sa acorde/revoce accesul unu utilizator in sistem

Preconditii:

Utilizatorul sa fie autentificat.

Persoana sa fie inregistrala sau sa fie activa/inactiva.

Postconditii:

Utilizatorul in cauza sa aiba/sa nu aiba accesa in aplicatie.

Scenariul de succes:

Selecteaza utilizatorul

Selecteaza statusul utilizatorului

Actioneaza butonul de salvarea a modificarilor

Sistemul salveaza modificarile.

Nume caz de utilizare: Acorda/revoca rolurile utilizatorului in aplicatie

Actor principal: Administrator de utilizatori

Partile implicate si interesele lor:

Administratorul de utilizatori doreste sa acorde/revoce rolul unui utilizatori in aplicatie.

Preconditii:

Utilizatorul sa fie autentificat.

Persoana sa fie inregistrata.

Postconditii:

Utilizatorul in cauza sa i se acorde/revoce rolul in aplicatie.

Scenariul de succes:

Selecteaza utilizatorul.

Selecteaza indicatorul de rol pe valoarea afirmativa.

Actioneaza butonul de salvarea a modificarilor.

Sistemul salveaza modificarile.

Nume caz de utilizare: Vizualizare fisa de acces a utilizatorului

Actor principal: Administrator de utilizatori

Partile implicate si interesele lor:

Administratorul de utilizatori doreste sa vizualizeze fisa de acces a utilizatorului pentru o eventual acordare de acces in aplicatie sau de asignarea unui rol superior.

Preconditii:

Utilizatorul sa fie autentificat.

Persoana sa fie inregistrata.

Persoana sa aiba in baza de date fisa de acces.

Postconditii:

Fisa de acces sa fie disponibila pentru descarcare.

Scenariul de succes:

Selecteaza utilizatorul..

Actioneaza butonul de descarcare a fisei de acces.

Sistemul preia fisierul si il pune la dispozitie pentru a fi descarcat.

Nume caz de utilizare: Sterge utilizator

Actor principal: Administrator de utilizatori

Partile implicate si interesele lor:

Administratorul de utilizatori doreste sa stearga un utilizator care nu va mai fi activ in sistem.

Preconditii:

Utilizatorul sa fie autentificat.

Persoana sa fie inregistrata.

Postconditii:

Utilizatorul in cauza sa fie sters din sistem.

Scenariul de succes:

Selecteaza utilizatorul.

Actioneaza butonul de stergere a utilizatorului

Actioneaza butonul de salvare a modificarilor.

Sistemul sterge utilizatorul si salveaza starea actuala.

Extensii:

3a.Administratorul de utilizatori nu actioneaza butonul de salvarea

1.Sistemul va mentine tranzactia activa un timp limitat dupa care va anula tranzactia.

Cazurile de utilizare aferente administratorului bazei de date

In figura 4.3.2.5.1 puteti observa diagrama cazurilor de utilizare aferente administratorului bazei de date.

Nume caz de utilizare: Adaga categorie boala

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste sa introduca o noua categorie de boli.

Cadrele medicale doresc sa fie actualizate informatiile despre boli

Preconditii:

Utilizatorul sa fie autentificat.

Postconditii:

Categorie de boli sa fie adaugata.

Scenariul de succes:

Actioneaza butonul de directionare la managementul datelor medicale.

Actioneaza butonul de adaugarea unei noi categorii de boli.

Introduce numele categoriei.

Actioneaza butonul de salvarea a inserarii.

Sistemul salveaza inserarea.

Extensii:

3a.Administratorul nu introduce numele categoriei.

1.Sistemul va avertiza lipsa datelor.

Nume caz de utilizare: Sterge categorie boala

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste sa stearga o categorie de boli.

Cadrele medicale doresc ca informitiile despre boli sa fie actualizate.

Preconditii:

Utilizatorul sa fie autentificat.

Postconditii:

Categoria de boli sa fie stearsa din sistem.

Scenariul de succes:

Actioneaza butonul de directionare la managementul datelor medicale

Selecteaza categoria de boli

Actioneaza butonul de stergerea a categoriei

Sistemul sterge categoria si toate bolile din aceasta.

Nume caz de utilizare: Adauga boala

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste adaugarea unei boli noi.

Cadrele medicale doresc ca informatiile despre boli sa fie actualizate.

Preconditii:

Utilizatorul sa fie autentificat.

Sa existe o categorie in care sa fie incadrata boala.

Postconditii:

Informatia despre noua boala sa fie adaugata in sistem.

Scenariul de succes:

Actioneaza butonul de directionare la managementul datelor medicale.

Selecteaza categoria bolii.

Actioneaza butonul de adaugarea a unei boli noi.

Introduce numele bolii.

Actioneaza butonul de salvarea a bolii.

Sistemul salveaza adaugarea bolii.

Nume caz de utilizare: Sterge boala

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste stergerea unei boli din sistem.

Cadrele medicale doresc actualizarea informatiilor despre boli.

Preconditii:

Utilizatorul sa fie autentificat.

Sa existe in sistem boala in cauza.

Postconditii:

Boala in cauza sa fie stearsa din sistem.

Scenariul de succes:

Actioneaza butonul de directionare la managementul datelor medicale.

Selecteaza categoria bolii

Sistemul actualizeaza informatiile conform categoriei selectate.

Selecteaza boala.

Actioneaza butonul de stergere a bolii.

Sistemul sterge boala.

Nume caz de utilizare: Adauga persoana

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste sa introduca in sistem o persoana noua.

Coordonatorii si cadrele medicale doresc sa fie actualizate informatiile despre persoane.

Preconditii:

Utilizatorul sa fie autentificat.

Postconditii:

Persoana sa fie adaugata in sistem.

Scenariul de succes:

Actioneaza butonul de managementul persoanelor.

Actioneaza butonul de adaugare a unei persoane noi.

Introduce nume, prenume, adresa, adresa de e-mail, telefon, sex, data nasterii.

Actioneaza butonul de salvare a persoanei.

Sistemul salveaza persoana in sistem.

Extensii:

3a.Administratorul nu introduce informatii in unul sau mai multe din campuri solicitate.

1.Sistemul va avertiza lipsa datelor.

Nume caz de utilizare: Sterge persoana

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste stergerea unei persoane din sistem.

Coordonatorii si cadrele medicale doresc sa fie actualizate informatiile despre persoane.

Preconditii:

Utilizatorul sa fie autentificat.

Persoana in cauza sa existe in sistem.

Postconditii:

Persoana in cauza sa fie stearsa din sistem.

Scenariul de succes:

Actioneaza butonul de directionare la managementul persoanelor.

Selecteaza persoana.

Actioneaza butonul de stergere a persoanei.

Sistemul sterge persoana.

Nume caz de utilizare: Adauga angajat nou

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste adaugarea unui angajat nou in sistem.

Preconditii:

Utilizatorul sa fie autentificat.

Postconditii:

Angajatul nou sa fie adaugat in sistem.

Scenariul de succes:

Actioneaza butonul de management al persoanelor.

Selecteaza zona de afisare a angajatilor.

Actioneaza butonul de adaugarea a unui angajat

Introduce nume, prenume, adresa, adresa de e-mail, telefon, sex, data nasterii, functie, remuneratia lunara si remuneratia pentru activitati suplimentare.

Actioneaza butonul de salvarea a angajatului.

Sistemul salveaza angajatul introdus.

Extensii:

4a.Administratorul nu introduce informatii in unul sau mai multe din campurile solicitate.

1.Sistemul va avertiza lipsa datelor.

Nume caz de utilizare: Adauga anajat nou – persoana din sistem

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste numirea unei persoane din sistem ca angajat.

Preconditii:

Utilizatorul sa fie autentificat.

Persoana vizata sa existe in sistem.

Postconditii:

Persoana sa fie regasita si ca angajat.

Scenariul de succes:

Actioneaza butonul de directionare la managementul persoanelor.

Selecteaza zona de afisarea a angajatilor.

Actioneaza butonul de adaugarea a unui angajat.

Cauta angajatul in sistemul.

Introduce functia,renumeratia lunara si renumeratia pentru activitati suplimentare.

Actioneaza butonul de salvare a angajatului.

Sistemul salveaza angajatul.

Extensii:

Nume caz de utilizare: Sterge angajat

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste stergerea unui angajat din sistem.

Preconditii:

Utilizatorul sa fie autentificat.

Angajatul sa fie definit in sistem.

Postconditii:

Angajatul sa fie sters din sistem.

Scenariul de succes:

Actioneaza butonul de directionare la managementul persoanelor.

Selecteaza zona de afisare a angajatilor.

Selecteaza angajatul.

Actioneaza butonul de stergere a angajatului.

Sistemul sterge angajatul.

Nume caz de utilizare: Adauga echipamente

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste inserarea unui nou echipament in sistem.

Cadrele medicale doresc ca informatiile despre echipamente sa fie actualizate.

Preconditii:

Utilizatorul sa fie autentificat.

Postconditii:

Echipamentul sa fie adaugat in sistem.

Scenariul de succes:

Actioneaza butonul de directionare la managementul echipamentelor.

Actioneaza butonul de adaugarea a unui echipament nou.

Introduce denumirea echipamentului si costul inchirierii acestuia pe o zi.

Actioneaza butonul de salvare a echipamentului.

Sistemul salveaza echipamentul.

Extensii:

3a.Administratorul nu introduce denumirea sau costul echipamentului:

1.Sistemul va avertiza lipsa datelor.

Nume caz de utilizare: Sterge echipament

Actor principal: Administrator baze de date

Partile implicate si interesele lor:

Administratorul bazei de date doreste sa stearga din sistem un echipament.

Cadrele medicale doresc ca informatiile despre echipamente sa fie actualizate.

Preconditii:

Utilizatorul sa fie autentificat.

Echipamentul in cauza sa fie definit in sistem.

Postconditii:

Echipamentul in cauza sa fie sters din sistem.

Scenariul de succes:

Actioneaza butonul de directionare la managementul echipamentelor.

Selecteaza echipamentul.

Actioneaza butonul de stergerea a echipamentului.

Sistemul sterge echipamentul.

Cazurile de utilizare aferente pacientului

In figura 4.3.2.6.1 puteti observa diagrama cazurilor de utilizare aferente pacientului.

Nume caz de utilizare: Vizualizare fisa medicala

Actor principal: Pacient

Partile implicate si interesele lor:

Pacientul doreste sa isi vizualizeze fisa medicala.

Preconditii:

Utilizatorul sa fie autentificat.

Postconditii:

Fisa medicala sa fie afisata.

Scenariul de succes:

Actioneaza butonul de directionare la fisa medicala.

Nume caz de utilizare: Adauga analize personale

Actor principal: Pacient

Partile implicate si interesele lor:

Pacientul doreste adaugarea analizelor personale pentru trialul la care este inrolat.

Preconditii:

Utilizatorul sa fie autentificat.

Pacientul sa fie inrolat intr-un trial.

Postconditii:

Analiza personala sa fie adaugata in istoricul medical al trialului.

Scenariul de succes:

Actioneaza butonul de directionare la zona de adaugarea a analizelor.

Sistemul afiseaza parametrii biologici pentru care se pot adauga analize.

Selecteaza parametrul biologic si introduce valorea si data analizei.

Actioneaza butonul de salvarea a analizei.

Sistemul salveaza analiza.

Extensii:

4a.Analiza introdusa exista deja in istoricul medical.

1.Sistemul alerteaza duplicitarea datelor si renunta la inserare.

4b.S-a atins limita numarului de analize introduse pentru saptamana respectiva.

1.Sistemul alerteaza atingerea acestei limite.

Nume caz de utilizare: Vizualizare evolutie personala

Actor principal: Pacient

Partile implicate si interesele lor:

Pacientul doreste sa vizualizeze evolutia personala din trialul in care este inrolat.

Preconditii:

Utilizatorul sa fie autentificat.

Pacientul sa fie inrolat intr-un trial.

Postconditii:

Graficul de evolutie al persoanei sa fie afisat.

Scenariul de succes:

Actioneaza butonul de directionare la zona de vizualizare a evolutiei sale.

Selecteaza unul din parametrii biologici urmariti in trialul in care este inrolat.

Actioneaza butonul de afisare a graficului.

Sistemul va afisa graficul de evolutie a persoanei.

Nume caz de utilizare: Accepta/refuza invitatia in trial

Actor principal: Pacient

Partile implicate si interesele lor:

Pacientul doreste sa accepte/refuze invitatia in trial.

Preconditii:

Utilizatorul sa fie autentificat.

Pacientul sa fi primit o invitatie.

Postconditii:

Invitatia sa fie accepta/refuzata.

Raspunsul pacientului sa fie propagat la coordonator.

Scenariul de succes:

Actioneaza butonul de directionare la zona de management al invitatiilor.

Selecteaza invitatia primita.

Actioneaza butonul de accept/refuz al invitatie.

Sistemul marcheaza invitatia ca fiind acceptata/refuzata.

Sistemul instiinteaza coordonatorul cu privire la raspunsul pacientului.

Nume caz de utilizare: Trimite solicitare de inrolare in trial

Actor principal: Pacient

Partile implicate si interesele lor:

Pacientul doreste sa solicite inrolarea intr-un trial

Preconditii:

Utilizatorul sa fie autentificat.

Postconditii:

Solicitarea pacientului sa fie trimisa.

Coordonatorul trialului sa fie instiintat.

Scenariul de succes:

Actioneaza butonul de directionare la zona de management al invitatiilor.

Selecteaza trialul in care doreste sa se inroleze.

Actioneaza butonul de trimitere a solicitarii.

Sistemul trimite solicitiarea coordonatorului.

Nume caz de utilizare: Vizualizeaza grafic evolutia pacientilor din trialurile incheiate

Actor principal: Pacient

Partile implicate si interesele lor:

Pacientul doreste sa vizualizele graficul evolutie pacientilor dintr-un trial incheiat.

Preconditii:

Utilizatorul sa fie autentificat.

Trialul in cauza sa fie finalizat.

Postconditii:

Afisarea graficului ce reprezinta evolutia pacientilor in trial.

Scenariul de succes:

Actioneaza butonul de directionare la trialurile finalizate.

Selecteaza trialul in cauza.

Actioneaza butonul de vizualizare a graficelor.

Selecteaza parametrul biologic pentru care se va construi graficul.

Actioneaza butonul de afisarea a graficului.

Sistemul va afisa graficul solicitat.

Extensii:

2a.Nu exista trialuri finalizate:

1.Sistemul nu va afisa nici o inregistrare in lista de trialuri.

Proiectare de Detaliu si Implementare

Implementarea aplicatiei debuteaza cu crearea bazei de date in sistemul de gestiune Oracle DataBase 11g.Aceasta baza de date va reprezenta nivelul cel mai de jos al aplicatiei peste care construiecte sistemul mapand fiecare entitate.La finalul crearii bazei de date se incepe implementarea proiectului in mediul de dezvoltare Oracle Jdeveloper.Tipul proiectului ales este „Fusion Web Application”.

Designul sistemului

Designul bazei de date

Entitati specifice persoanelor

Entitatile care fac referice la conceptul de persoana si corespondentul lor in aplicatie sunt: tabelele PERSON,USERS,IOT_USERS_RIGHTS si EMPLOYEE.Legaturile si atributele fiecarei tabele sunt reprezentate in figura5.1.1.1.1.

Tabela PERSON contine atributele necesare descrierii minime a unei persoane avand atributul ID de tip numeric ca identificator unic.

Tabela USERS reprezinta legatura persoanelor cu aplicatia.Aceasta legatura este realizata prin cheia straina PERSON_ID care pointeaza spre identificatorul unic din tabela PERSON.Identificatorul unic al tabelei USERS este atributul alfanumeric USERNAME.Nevoia unicitatii numelui de utilizator este justificata prin nevoia de securitate.Un alt element ce tine de securitatea sistemului si de securitatea informatiilor este atributul PASSWORD care stocheaza parola utilizatorului in format criptat.Atributul STATUS arata starea utilizatorului.Multimea valorilor ale atributului de stare este : “O” care reprezinta un utilizator activ, “W” care simbolizeaza utilizatorul in asteptarea confirmarii inregistrarii si “C” care reprezinta utilizatorul inactiv.

Tabela IOT_USER_RIGHTS are legatura directa cu tabela PERSON prin cheia straina ID.Atributele acestei tabele reprezinta raspunsul binar la intrebarea “are rolul de…?” putand avea valori doar in multimea finita {0,1}.Zero fiind raspunsul negative la intregare,iar unu fiind raspunsul afirmativ.Pentru utilizatorii cu rolul mai importante decat cel de pacient este necesar ca atributul ACCESS_FILE sa contina fisa de acces in formatul BLOB.

Tabela EMPLOYEE este defapt un subtip a tabelei cu persoane care simbolizeaza daca o persoana este angajata sau nu.Legatura dintre aceste tabele se face prin cheia straina PERSON_ID care pointeaza spre cheia primara ID din tabela PERSON.

Entitati specifice trialurilor

In figura 5.1.1.2.1 avem prezentate relatiile dintre tabela principala TRIAL si TRIAL_CHARACTERISTICS care la randul ei are legaturi cu tabelele TRIAL_TYPE_DETAILS si TRIAL_DESIGN_TYPE.

Tabela TRIAL contine atributul ID cu rolul de identificator unic si alte atribute necesare unei descrieri minime cum ar fi:numele trialului,o scurta descriere,perioada de desfasurare exprimata printr-o valoare numerica reprezentand numarul de luni,data lansari,data finalizarii si identificatorul persoanei care a definit trialul,COORDINATOR_ID, care care pointeaza spre cheia primara ID din tabela PERSON.Extinderea descrierii unui trial este realizata cu ajutorul tabelei TRIAL
_CHARACTERISTICS,legata de tabela TRIAL prin cheia straina TRIAL_ID.

Tabela de caracteristici contine urmatoarele informatii:frecventa tratamentului,numarul minim de subiecti pe bratul unu,numarul minim de subiectie pe bratul doi,proportia bratelor si denumirile fiecarui tratament.Pentru trialurile in care se studiaza tratamente pe un singur grup se completeaza campul MIN_SUBJECTS_GROUP_2 cu valoarea zero,iar campul TREATMENT_NAME_2 se lasa necompletat.Aceasta tabela are la randul ei legatura cu tabela TRIAL_DESIGN_TYPE prin cheia straina TRIAL_DESIGN_ID si o alta legatura cu tabela TRIAL_TYPE_DETAILS prin cheia straina TRIAL_TYPE_DETAILS_ID.

Tabelele TRIAL_TYPE,TRIAL_TYPE_DETAILS si TRIAL_DESIGN modeleaza particularitatile fiecarui trial (Ex: grup singular sau grupuri paralele, trial de superioritate sau trial de echivalenta,randomizat simplu sau randomizat orb).

In figura 5.1.1.2.2 avem prezentala relatia dintre tabela TRIAL si criterile de selectia pentru randomizare din tabelele TRIAL_PARAMETERS_FACTORS, TRIAL_DISEASE_FACTORS si TRIAL_OTHER_FACTORS.

Legaturile acestor tabele se realizeaza prin cheia straina TRIAL_ID prezenta in fiecare din aceasta care face pointeaza la atributul ID din tabela TRIAL.Tabela TRIAL_DISEASE_FACTORS contine filtrele de incluziune sau excludere din trial din punct de vedere al bolilor.Legatura acestei tabele cu tabela DISEASE_TYPE si DISEASE se realizeaza prin cheia straina DISEASE_TYPE_ID si respectiv DISEASE_ID.Atributul FACTOR_MARK poate avea valori finite din multimea {0,1}.Valoarea zero insemnand factor de excludere,iar valoarea unu factor de includere.

Tabela TRIAL_PARAMETERS_FACTORS contine filtrele de incluziune si excludere din trial din punct de vedere al analizelor pacientului.Legatura acestei tabele cu tabela CHEMICAL_ELEMENT_ID se realizeaza prin cheia straina PARAMETER_ID care pointeaza la identificatorul unic,ID. Atributul FACTOR_MARK poate avea valori finite din multimea {0,1}.Valoarea zero insemnand factor de excludere,iar valoarea unu factor de includere.

Tabela TRIAL_OTHER_FACTORS contine filtrele de incluziune si excludere din trial din punct de vedere al factorilor de stratificare (ex: varsta,sex,grupa de sange etc.). Legatura acestei tabele cu tabelele FILTER_FACTOR si FILTER_FACTOR_DETAILS se realizeaza prin cheia straina FACTOR_ID si respectiv FACTOR_DETAIL_ID.De asemenea atributul FACTOR_MARK poate avea valori finite din multimea {0,1}.Valoarea zero insemnand factor de excludere,iar valoarea unu factor de includere.

In figura 5.1.1.2.3 sunt reprezentate entitatile conexe ale trialurilor si relatiile dintre acestea.

Aceste tabele conexe au o caracteristica comuna.Au in componenta lor atributul TRIAL_ID ca si partea din cheia primara a fiecarei tabele.Acest atribut are referinta in tabela TRIAL la atributul ID.

Tabela TRIAL_MONITORIZED_PARAMETERS contine lista parametrilor biologici urmariti ai fiecarui trial.Un parametru este exprimata printr-un identificator CHEMICAL_ELEMENT_ID care are referinta in tabela CHEMICAL_ELEMENTS la atributul ID.Atributul DIRECTION indica predictia parametrului din trialul respectiv(majorare sau micsorare).

Tabela TRIAL_SUBJECTS contine lista persoanelor care parte din studiul trialului. Legatura cu tabela de persoane se face prin cheia straina PERSON_ID care pointeaza spre cheia primara ID.

Tabela TRIAL_RESULTS pastreaza rezulatele statistice ale trialului pentru fiecare grup in parte.

Tabela TRIAL_MEDICAL_HISTORY contine lista tuturor analizelor realizate in trialuri. Legatura cu tabela de persoane se face prin cheia straina PERSON_ID care pointeaza spre cheia primara ID,iar legatura cu parametrul biologic din tabela CHEMICAL_ELEMENTS se face prin cheia straina CHEMICAL_ELEMENT_ID. Traducand in limbaj natural o inregistrare din tabela ar putea fi exprimata astfel: pentru trial x si persoana y s-a preluat analiza z cu valoare v in data d.

Tabela TRIAL_STAFF contine lista persoanelor care presteaza servicii in trialuri. Legatura cu tabela de persoane se face prin cheia straina PERSON_ID care pointeaza spre cheia primara ID.

Tabel TRIAL_EQUIPMENTS contine lista echipamentelor utilizate in trialuri. Legatura cu tabela de echipamente se face prin cheia straina EQUIPMENT_ID care pointeaza spre cheia prima ID.

Tabel TRIAL_INVITATIONS are rolul de a gestiona invitatiile si solicitarile de inrolare in trial. Legatura cu tabela de persoane se face prin cheia straina PERSON_ID care pointeaza spre cheia primara ID.Atributul PATIENT_INVITATION_FLAG indica faptul ca pacientul a solicitat inrolarea in trial atunci cand are valoare zero,in caz contrat a fost invitat.

Entitati specifice datelor medicale

Entitatile care fac referire la conceptul de date medicale sunt urmatoarele tabele:DISEASE_TYPES,DISEASE,MEDICAL_RECORDS,DIAGNOSTICS_RECORDS,ANALYSIS,CHEMICAL_ELEMENTS si EQUIPMENT.Atributele acestor tabele si relatiile dintre ele sunt relatate in figura 5.1.1.3.1.

Figura 5.1.1.3.1 – Entitati specifice datelor medicale

Tabela DISEASE_TYPES contine informatiile despre categorii de boli.Fiecare categorie are un identificator unic ID.Acest atribut este cheia de referinta a tabelei DISEASE care contine informatii despre bolile fiecarei categorii.Legatura stabilindu-se prin cheia straina DISEASE_TYPE_ID.

Tebela MEDICAL_RECORDS reprezinta fisa medicala a unei persoane.Daca o persoana are fisa medica atunci acesta este considerata pacient.Legatura dintre fisa medicala si pacient se stabileste prin atributul PERSON_ID care are referinta la atributul ID al tabelei PERSON.Atasat fiecarei fise medicala exista o lista de diagnostice cu inregistrarile DIAGONOSTICS_RECORDS.Cheia primara a tabelei de diagnostice este o cheie compusadin doua atribute ID si DIAGNOSTIC_ID.Atributul DIAGNOSTIC este cheia straina cu legatura in tabela DISEASE prin atributul ID.

Tabela ANALYSIS stocheaza analizele fiecarui pacient.Aceste analize sunt independente de cele preluate din perioada trialului.Tabela are o cheie primara compusa din trei atribute:PERSON_ID,CHEMICAL_ELEMENT_ID si HIST_DATE. Legatura dintre analiza si pacient se stabileste prin atributul PERSON_ID care are referinta la atributul ID al tabelei PERSON,iar legatura dintre analiza si parametrul biologic se stabileste prin atributul CHEMICAL_ELMENT_ID care are referinta la atributul ID al tabelei CHEMICAL_ELEMENTS

Din categoria entitatilor specifice datelor medicale mai face parte si tabela EQUIPMENT care contine informatii despre echipamentele disponibile.Fiecare echipamente are un identificat unic ID,o denumire si costul de utilizare pe o singura zi.

Designul aplicatiei

Aplicatia poate fi vazuta ca o structura arborestenta din punct de vedere al navigarii in aceasta,existand la inceput o radacina care se ramifica in functie de selectiile realizate.Mediul de dezvoltare permite crearea si afisarea acestor structuri pe care se va baza aplicatia numite „task flow-uri”.In figura 5.1.2.1 puteti observa task-flow-ul principal.

Pagina LoginPage reprezinta punctul de start al aplicatiei.Din acest punct exista doua ramificari.Atunci cand se incearca autentificarea unui utilizator se verifica credentialele inauntrul componentei security care este defapt un factor de decizie in functie de rezultatul compararii datelor introduce pentru autentificare si credentialele utilizatorului din sistem.Daca rezultatul compararii nu este egalitate atunci utilizatorul este directionat pe pagina ErrorPage care este pagina cu acces restrictionat.In cazul de egalitate utilizatorul este directionat pe pagina AvailableOptions de unde isi poate selecta rolul in aplicatie si vizualiza profilul.Pentru persoanele care nu sunt inregistrare se merge pe a doua ramificatie,cea de inregistrare care directioneaza persoana la pagina RegisterPage.

Din momentul in care utilizatorul este autentificat se apeleaza task-flow-ul utilizatorului conectat(figura 5.1.2.2).

In pagina Options avem expuse optiunile utilizatorului de selectia a rolului in aplicatiei.Aceste optiuni apar in functie de rolurile definite pentru acesta in tabela IOT_USERS_RIGHTS.De exemplu:daca utilizatorul are rolul de doctor si de coordonator trial atunci dupa autentificare in pagina de optiuni ii vor aparea doar optiunile de doctor si coordonator trial,restul optiunilor fiind ascunse.Optiunile sunt disponibile sub forma de butoane care o data actionate vor face apel la unul dintre task-flow-uri.

Dintre optiunile utilizatorului vom incepe sa detaliem task-flow-ul corespunzator coordonatorului de trial reprezentat in figura 5.1.2.3.

Rolul coordonatorului de trial are disponibil si el cateva optiuni:

Optiunea de vizualizare a trialurilor definite de acesta din pagina TrialCoordinatorPage care face mai intai apelul unei metode ca filtrare a trialului in functie de identificatorul coodonatorului.

Optiunea de lansare si finalizare a trialurilor din pagina StartEndTrials.Si in acest caz se executa metoda de filtrare a trialurilor in functie de identificatorul coordonatorului.

Optiunea de management al invitatiilor din pagina InvitationManagement.Inainte de a ajunge pe aceasta pagina se executa metoda de filtrare a trialurilor si metoda de filtrare a solicitariilor de inrolare in trialurile definite de coordonatorul.

Optiunea de definire a unui trial,care este o optiune mai complexa si in acest sens face apelul task-flow-ului de definire a unui trial prezentat in figura 5.1.2.4

Task-flow-ul de definire a unui trial nou incepe cu prima pagina TrialDetails care este primul pas in definirea trialului.Pasul doi este cel al lansarii ipotezei din pagina Hypotesis,al treilea pas este cel de selectia a angajatilor implicati in trial din pagina PeopleInvolved,pasul patru constra in selectia echipamentelor utilizate in trial din pagina NecesaryEquipment,pasul cinci este cel al selectiei factorilor de includere si excludere si a randomizarii din pagina Randomization,iar ultimul pas este cel al prezentarii sumarului selectiilor facute din pagina Review.

Figura.5.1.2.4 – Task-flow-ul corespunzator definirii unui trial nou

Urmatorul task-flow pe care il vom detalia este cel corespunzator doctorului,ilustrat in figura 5.1.2.5.

In pagina DoctorPage sunt toate optiunile posibile utilizatorilor cu rol de doctor din aceasta aplicatie.Aceste optiuni sunt afisate sub forma de butoane.Pagina MedicalData este pagina in care se fac preluarile de analize pentru pacientii inscrisi in trialuri.In pagina Patients se realizeaza managementul fiselor medicale.EndedTrails este pagina unde se poate vizualiza evolutia subiectiilor precum si rezultatele statistice din trialurile finalizate,iar in pagina Trails sunt afisate toate trialurile in desfasurare la care se poate vizualiza evolutia partiala a subiectilor si se pot descarca datele privind analizele subiectilor.

O alta optiune a utilizatorului conectat este rolul de asistent.In figura 5.1.2.6 este ilustrat task-flow-ul corespunzator acestui rol.

Pagina AssistantPage contine toate optiunile disponibile utilizatorului cu rolul de asistent.Fiecare optiune este afisata sub forma unui buton.La actionarea lor aplicatia ne directioneaza spre pagina corespunzatoare optiuni.In pagina MedicalData se preiau analizele pacientilor din trialurile in desfasurare.Pagina EndedTrials este dedicata vizualizarii evolutiei pacientilor si a rezultatelor statistice din trialurile finalizate.Ultima optiune disponibila este cea de vizualizare a evolutiei pacientilor din trialurile in desfasurare afisata in pagina CurrentTrials.

Inca o optiune a utilizatorului conectat este optiunea corespunzatoare rolului de pacient ilustrata in figura 5.1.2.7.

Pagina PatientPage contine toate optiunile disponibile utilizatorului cu rolul de pacient sub forma de butoane care daca sunt actionate directioneaza utilizatorul spre paginile corespunzatoare optiunii:

MedicalRecord contine informatiile despre fisa medicala,diagnostice si buletinul de analize al pacientului conectat.Inainte de a ajunge pe aceasta pagina se face cautarea acestor informatii pe baza identificatorului de persoana.

PersonalMedicalData contine interfata grafica unde se pot introduce analizele personale pentru trialul in care este inrolat pacientul conectat.

TrialEnrollment contine interfara grafica pentru managementul invitatiilor de inrolare in trial primite.Inainte de a ajunge pe aceasta pagina se face cautarea invitatiilor pe baza identificatorului de persoana.

PersonalEvolution contine interfata grafica pentru vizualizarea evolutiei personale din trialul la care este inrolat pacientul conectat.Inainte de a ajunge pe aceasta pagina se face cautarea analizelor pacientului pe baza identificatorului de persoana.

EndedTrials este pagina dedicata vizualizarii evolutiei pacientilor din trialurile finalizate.

Ultimul task-flow care necesita detalierea este cel al rolului de administrator baze de date ilustrat in figura 5.1.2.8.

Pagina DbAdminPage contine toate optiunile disponibile administratorului bazei de date sub forma de butoane care daca sunt actionate directioneaza utilizatorul pe paginile corespunzatoare.Pagina MedicalDataManagement este pagina in care se realizeaza gestiunea datelor medicale.In pagina PersonManagement se realizeaza gestiunea persoanelor din sistem,iar in pagina EquipmentManagement se face gestiunea echipamentelor din sistem.

Detalii de implementare

In implementarea aplicatiei s-au folosit elemente ale framework-ului ADF Business Components.Aceste elemente fiind entitatile care asigura maparea tabelelor din baza de date,vederile care asigura interogarea tabelelor,asocierile asigura legaturile dintre entitati,iar relatiile dintre vederi sunt asigurate de legaturi(view-links).Obiectele de tip entitate sunt reprezentari de cod sursa a unui tabel din baza de date.Aceste obiecte realizeaza insertia,actualizarea si stergerea din baza de date a inregistrarilor.Obiectele de tip vedere sunt interogari pe baza de date.Aceste vederi sunt doar cu drept de citire atunci cand nu sunt construite pe baza unei entitati.Fiecare entitate contine si o clasa de implementare,iar vederile pe langa clasa de implementare mai contine si interfata prin care se face accesul la metode si view row class care reprezinta o instanta a unei singure tuple returnate de catre vedere.In figura 5.2.1 avem structura pe pachete a entitatiilor definite in aplicatie.

Structurarea pe pachete este facuta in functie de semnificatia entitatilor.Pachetul medical_data_eo contine entitatile care modeleaza conceptele ce tin de date medicale. Pachetul person_eo contine entitatiile legate de conceptele persoana si corespondentul acesteia in aplicatie,iar pachetul trial_eo contine entitatiile care modeleaza conceptul de trial.Dintre toate aceste entitati doar una singura are customizata metoda de stergere si de actualizare. Aceasta entitate se numeste Users.Metoda de stergere remove() implica si stergerea inregistrarii din entitatea IotUsersRights corespunzatoare utilizatorului.

Metoda de actualizare doDML(int operation,TransationEvent e) analizeaza solicitarea tranzactiei (inserare,actualizare sau stergere) si in cazul unei solicitari de actualizare se verifica daca starea utilizatorului a fost modificat in starea activa atunci trimite utilizatorului un email de notificare.

In figura 5.2.2 avem imaginea tuturor vederilor din aplicatie si relatiile dintre acestea.Vom lua pe rand fiecare vedere si ii vom explica scopul si metodele aferente.

Vederi care preiau informatii despre persoane si utilizatori:

AllUsersDetailsView – are rezultatul interogarii a trei tabele intersectate din baza de date care este o lista a tuturor utilizatorilor definiti in aplicatie.Aceasta lista este rezultatul intersectiei inregistrarilor din tabela de utilizator cu inregistrarile din tabelele de persoane si drepturi ale acestora.

PersonView – contine lista tuturor persoanelor definite in sistem.Suplimentar exista un atribut medical_record_flag care indica daca persoana este pacient sau nu.Pe langa metodele de set si get aceasta vedere mai contine si urmatoarele metode:

public int addPeson(String firstName,String lastName,String address, String email,String telephone,String sex,Timestamp birthDate) care adauga o persoana noua in sistem in tabela Person.Valoare numarului intreg returnat reprezinta statusul operatiunii.Daca se returneaza o valoare diferita de -1 atunci inseamna ca operatiunea s-a finalizat cu succes care este defapt identificatorul persoanei nou create.

public List<Integer> getPersonsIds() care returneaza o lista a identificatorilor unici ale tuturor persoanelor din sistem.

public int getPersonByID(int p_user_id) executa o filtrare a persoanelor in functie de parametrul de intrare si returneaza numarul de inregistrari gasite.

EmployeeView – contine lista tuturor angajatilor din sistem rezultata in urma interogarii tabelei Employee.Aceasta vedere pe langa metodele de set si get mai contine si alte metode necesare:

public int addEmployee(int person_id,String job,BigDecimal salary, BigDecimal extraPayments) care insereaza in tabela Employee un angajat nou.Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

public BigDecimal employeesCost(String employeeListIds) care returneaza suma costurilor de prestari suplimentare de serviciilor ale angajatiilor din lista data ca si parametru.Aceasta lista contine identificatorii unici ai angajatiilor separati prin caracterul virgula(,).

UsersDetailsView – este vederea in care se executa interogarea de autenificare din tabela cu utilizatori.In caz de autentificare reusita se intersecteaza cu date din tabela de persoane si cea a drepturilor utilizatorului in aplicatie. Aceasta vedere pe langa metodele de set si get mai contine si o alta metoda necesara:

public void login(String username,String password) care realizeaza autentificarea utilizatorului.

UsersView – contine lista tuturor utilizatorilor rezultata in urma interogarii exclusive a tabelei Users.

IotUserRightsView – contine lista tuturor drepturilor utilizatorilor rezultata in urma interogarii exclusive a tabelei Iot_Users_Rights

Vederi care preiau informatii despre date medicale:

AnalysisView – este vederea care toate buletinele de analizele ale pacientilor exceptand cele preluate in trialuri. Aceasta vedere pe langa metodele de set si get mai contine si o alta metoda necesara:

public int addAnalysis(int person_id,int param_id,BigDecimal value, Timestap hist_date) care introduce in tabela Analysis o analiza a unui pacient. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

DiagnosticsRecordsView – contine lista tuturor diagnosticelor puse in acest sistem.Lista este populata in urma interogarii tabelei DiagnosticsRecords. Aceasta vedere pe langa metodele de set si get mai contine si alte metode necesare:

public int addDiagnostic(int diagnostic_list_id,int diagnostic,String state, Timestamp diagnosticDate,String otherDetails) care introduce un diagnostic in tabela.Parametrul diagnostic_list_id corespunde unui identificator de lista a diagnosticelor a unei fise medicale. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

public removeDiagnostic() care sterge diagnosticul din tabela.Stergerea se realizeaza prin identificarea diagnosticului din contextul curent. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

EquipmentView – contine lista echipamentelor din sistem.Aceasta lista este populata in urma interogarii facute pe tabela Equipments.Vederea contine pe langa metodele de set si get si alte metode necesare:

public int addEquipment(String equipmentName, BigDecimal pricePerDay) care introduce un echipament nou in tabela. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

public equipmentCost(String equipmentListIds) care returneaza suma costurilor de utilizare pe o singura zi a echipamentelor din lista data ca si parametru. Aceasta lista contine identificatorii unici ale echipamentelor separati prin caracterul virgula(,).

MedicalHistoryParameterView – contine lista analizelor unui pacient preluate intr-un trial filtrate dupa parametrul biologic.Aceste inregistrari sunt obtinute in urma interogarii tabelei Trial_Medical_History. Aceasta vedere pe langa metodele de set si get mai contine si o alta metoda necesara:

public void getMedicalHistory(int trial_id,int person_id,int chemical_element_id) care filtreaza analizele din istoricul medical al trialurilor dupa identificatorul trialului,persoanei si a parametrului biologic.

MedicalHistoryPerTrialGroup – contine lista analizelor unui grup de subiecti dintr-un trial filtrate dupa parametrul biologic.Pentru a extrage aceste informatii am folosit urmatoarele metode:

public void getMedicalHistoryPerGroup1(int trial_id,int chemical_element_id) care filtreaza analizele din istoricul medical al trialurilor dupa identificatorul trialului si parametrul biologic pentru grupul cu numarul unu al trialului cu identificatorul dat ca si parametru de intrare.

public void getMedicalHistoryPerGroup2(int trial_id,int chemical_element_id) care filtreaza analizele din istoricul medical al trialurilor dupa identificatorul trialului si parametrul biologic pentru grupul cu numarul doi al trialului cu identificatorul dat ca si parametru de intrare.

ChemicalElementsLov – contine lista parametrilor biologici din sistem.Aceasta lista este populata in urma interogarii tabelei Chemical_elements.

DiseaseTypesView – contine lista tuturor categoriilor de boli din sistem.Lista este populata in urma interogarii tabelei Disease_types.Vederea contine pe langa metodele de set si get si alte metode necesare:

public int addDiseaseType(String category) care adauga o noua categorie de boli in tabela. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

public int deleteDiseaseType() care sterge categoria de boli din tabela impreuna cu bolile asignate acestei categorii. Stergerea se realizeaza prin identificarea categoriei din contextul curent. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

DiseaseView – contine lista tuturor bolilor si a simptomelor din sistem.Lista este populata in urma interogarii tabelei Disease.Vederea contine pe langa metodele de set si get si alte metode necesare:

public int addDisease(int disease_type_id,String disease) care insereaza o boala sau simptom nou in tabela care corespunde categoriei de boli cu identificatorul disease_type_id.Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

public int removeDisease() sterge boala sau simptomul din tabela. Stergerea se realizeaza prin identificarea bolii din contexul curent. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

MedicalRecordsView – contine lista tuturor fiselor medicale definite in sistem. Lista este populata in urma interogarii tabelei Medical_Records.Vederea contine pe langa metodele de set si get si alte metode necesare:

public int addMedicalRecord(int person_id,String bloodGroup, BigDecimal weight,String otherObservations) care insereaza in tabela o fisa medicala noua corespunzatoare persoanei cu identificatorul person_id. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

public int removeMedicalRecord() care sterge din tabela fisa medicala. Stergerea se realizeaza prin identificarea fisei medicale din contextul curent.Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

public List<MedicalRecordsViewRowImpl> getAllMedicalRecords() returneaza o lista cu toate fisele medicale din sistem.Obiectele din lista reprezinta o tupla din tabela.

MostRecentAnalysis – contine lista celor mai recente analize a unui pacient indiferent de parametrul biologic.Aceste analize nu fac parte din istoricul medical al trialurilor.Aceste vedere contine metoda:

public List<MostRecentAnalysisRowImpl> getMostRecentAnalysis(int person_id) care returneaza o lista a ultimelor analize ale pacientului cu identificatorul person_id in urma interogarii tabelei Analysis.Objectele listei reprezinta o tupla din tabela.

PersonsFirstAnalysis – contine prima analiza preluata dintr-un trial pentru o anumita persoana si un anume parametru biologic.Acesta vedere contine metoda:

public BigDecimal getFirstAnalysis(int trial_id,int person_id,int chemical_element_id) care filtreaza analizele din istoricul medical al trialurilor(tabela Trial_Medical_History) dupa identificatorul trialului, persoanei si a parametrului biologic lasand doar cea mai veche dintre acestea.

PersonsLastAnalysis – contine ultima analiza preluata intr-un trial pentru o anumita persoana si un anume parametru biologic.Acesta vedere contine metoda:

public BigDecimal getLastAnalysis(int trial_id,int person_id,int chemical_element_id) care filtreaza analizele din istoricul medical al trialurilor(tabela Trial_Medical_History) dupa identificatorul trialului, persoanei si a parametrului biologic lasand doar cea mai recenta dintre acestea.

Vederi care preiau informatii despre trialuri si componentele aferente:

TrialView – contine lista tuturor trialurile definite in sistem.Aceasta este populata in urma interogarii tabelei Trial.Aceasta vedere contine pe langa metodele de set si get inca trei metode necesare:

public void getTrial(int trial_id) care filtreaza trialurile dupa identificatorul dat ca si parametru.

Public int addTrial(String trialName,String description,int period,int coordinator_id) care inseareaza un trial in tabela.Parametrul coordinator_id reprezinta identificatorul coordonatorului care a definit trialul.Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

Public int removeTrial() care sterge din tabela trialul.Stergerea se realizeaza prin identificarea trialului din contextul curent.Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

UnstartedTrials – contine lista tuturor trialurilor nelansate.Un trial nelansat este trialul care nu are setat atributul start_date.Aceasta lista este populata in urma interogarii tabelei Trial in conformitate cu specificatia facuta.

EndedTrialsView – contine lista tuturor trialurilor finalizate.Un trial finalizat este trialul careare setat atributul end_date.Aceasta lista este populata in urma interogarii tabelei Trial in conformitate cu specificatia facuta.

TrialCharacteristicsView – contine lista tuturor caracteristicilor trialurilor definite in sistem.Lista este populata in urma interogarii tabelei Trial_characteristics. Aceasta vedere contine pe langa metodele de set si get si urmtoarele metode:

public int addTrialCharacteristics(int trial_id,int trial_type_details_id,int trial_design_id,int treatment_frequency,String treatment_name_1,int min_subjects_group1,String treatment_name_2,int min_subjects_group2, String ratio) care insereaza un caracteristicile trialului cu identificatorul trial_id in tabela.Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

public int getTrialCharacteristics(int trial_id) care realizeaza filtrarea caracteristicilor in functie de identificatorul trialului dat ca si parametru de intrare.Valoarea returnata reprezinta numarul de inregistrari gasite in urma filtrarii.

TrialTypesLov – contine lista tipurilor de trialuri.Aceste tipuri sunt preluate in urma interogarii tabelei Trial_type.

TrialTypeDetails – contine lista subtipurilor de trial aferente unui tip de trial din tabela Trail_type.Aceste subtipuri sunt preluate in urma interogarii tabelei Trial_type_details.

TrialDesignTypes – contine lista designurilor de trialuri.Aceste designuri sunt preluate in urma interogarii tabelei Trail_design_type.

TrialMonitorizedParametersView – contine lista parametrilor biologici urmariti in fiecare trial definit.Aceste informatii sunt preluate din tabela Trial_ monitorized_ parameters.Aceasta vedere contine pe langa metodele de set si get si urmatoarele metode:

public int addMonitorizedParameter(int trial_id,int chemical_element_id, String direction) care insereaza un parametru biologic urmarit in trialul cu identificatorul trial_id.Valoarea returnata reprezinta statusul operatiunii. Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

Public List<MonitorizedParameter> getTrialMonitorizedParameters(int trial_id) care returneaza o lista cu parametrii biologici urmariti in trialul cu identificatorul trial_id.Acesti parametrii sunt reprezentati prin clasele de tipul MonitorizedParamter.

TrialMedicalHistoryView – contine lista tuturor analizelor preluate pentru fiecare trial din sistem.Aceste analize sunt defapt inregistrari din tabela Trial_Medical_ History.Vederea contine pe langa metodele de set si get si urmatoarele metode:

Public int addAnalysisToHistory(int trial_id,int person_id,int chemical_id, BigDecimal value,Timestamp hist_date) care adauga in tabela o noua analiza pentru persoana cu identificatorul person_id inrolata in trialul cu identificatorul trial_id.Valoarea returnata reprezinta statusul operatiunii. Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

private int searchAnalysis(int trial_id,int peson_id,int chemical_id, Timestamp hist_date) care cauta daca persoana cu identificatorul person_id are o analiza cu identificatorul chemical_id preluata in data hist_date pentru trialul cu identificatorul trial_id.Functia returneaza numarul inregistrarilor gasite.

private int searchLatestWeekAnalysis(int trial_id,int person_id,int chemical_id) care cauta daca persoana cu identificatorul person_id are analize cu identificatorul chemical_id preluata in ultima saptamana pentru trialul cu identificatorul trial_id.Functia returneaza numarul inregistrarilor gasite.

TrialMedicalHistoryReport – contine lista tuturor analizelor din istoricul medical al trialurilor (tabela Trial_Medical_History) sub forma de raport.Aceasta contine metoda:

public byte[] getTrialMedicalHistoryReportXls() care returneaza vector de bytes reprezentand un fisier microsoft excel cu raportul analizelor.

TrialParametersFactorsView – contine lista parametrilor biologici cu rol de factorilor de includere si de excludere din trialuri.Pentru ca incarca aceasta lista cu date se face o interogare pe tabela Trial_Parameters_Factors.Vederea contine pe langa metodele de set si get si urmatoarele metode:

public void executeTrialParametersFactors(int trial_id) care cauta parametrii biologici cu rol de factori in tabela pentru trialul cu identificatorul trial_id.

public List <TrialParametersFactorsViewRowImpl> getParameters Factors(int trial_id) care returneaza o lista cu parametrii biologici cu rol de factori definiti pentru trialul cu identificatorul trial_id.Aceasta lista contine obiecte ce reprezinta tuple din tabla Trial_Parameters_Factors.

public int addParameterInclusionFactor(int trial_id,int param_id, BigDecimal lowLimit,BigDecimal highLimit) care adauga un factor de includere (atributul factor_mark este egal cu 1) in tabela pentru trialul cu identificatorul trial_id.Valoarea returnata reprezinta statusul operatiunii. Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

public int addParameterExclusionFactor(int trial_id,int param_id, BigDecimal lowLimit,BigDecimal highLimit) care adauga un factor de excludere (atributul factor_mark este egal cu 0) in tabela pentru trialul cu identificatorul trial_id.Valoarea returnata reprezinta statusul operatiunii. Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

public int removeTrialParameterFactor() care sterge din tabela factorul. Stergerea se realizeaza prin identificarea factorului din contextul curent. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

public int removeTrialParametersFactors(int trial_id) care sterge din tabela toti factorii definiti pentru trialul cu identificatorul trial_id. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

TrialDiseaseFactors – contine lista tuturor bolilor cu rol de factorilor de includere si excludere din trial.Acesti factori sunt preluati in urma interogarii tabelei Trial_Disease_Factors.Vederea contine pe langa metode de set si get si urmatoarele metode:

public void executeTrialDiseaseFactors(int trial_id) care cauta bolile cu rol de factori in tabela pentru trialul cu identificatorul trial_id.

public List <TrialDiseaseFactorsViewRowImpl> getDiseaseFactors(int trial_id) care returneaza o lista de boli cu rol de factori definiti pentru trialul cu identificatorul trial_id.Aceasta lista contine obiecte ce reprezinta tuple din tabla Trial_Disease_Factors.

public int addDiseaseInclusionFactor(int trial_id,int disease_type_id,int disease_id) care adauga un factor de includere (atributul factor_mark este egal cu 1) in tabela pentru trialul cu identificatorul trial_id.Valoarea returnata reprezinta statusul operatiunii. Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

public int addDiseaseExclusionFactor(int trial_id, int disease_type_id, int disease_id) care adauga un factor de excludere (atributul factor_mark este egal cu 0) in tabela pentru trialul cu identificatorul trial_id.Valoarea returnata reprezinta statusul operatiunii. Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

public int removeTrialDiseaseFactor() care sterge din tabela factorul. Stergerea se realizeaza prin identificarea factorului din contextul curent. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

public int removeTrialDiseaseFactors(int trial_id) care sterge din tabela toti factorii definiti pentru trialul cu identificatorul trial_id. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

TrialOtherFactorsView – contine lista tuturor factorilor de stratificare cu rol de factorilor de includere si excludere din trial.Acesti factori sunt preluati in urma interogarii tabelei Trial_Other_Factors.Vederea contine pe langa metode de set si get si urmatoarele metode:

public void executeTrialOtherFactors(int trial_id) care cauta in tabela factorii de stratificare cu rol de factori pentru trialul cu identificatorul trial_id.

public List <TrialOtherFactorsViewRowImpl> getOtherFactors(int trial_id) care returneaza o lista de factori de stratificare cu rol de factori definiti pentru trialul cu identificatorul trial_id.Aceasta lista contine obiecte ce reprezinta tuple din tabla Trial_Other_Factors.

public int addOtherInclusionFactor(int trial_id,int factor_id,int factor_detail_id,BigDecimal lowLimit,BigDecimal highLimit) care adauga un factor de includere (atributul factor_mark este egal cu 1) in tabela pentru trialul cu identificatorul trial_id.Valoarea returnata reprezinta statusul operatiunii. Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

public int addOtherExclusionFactor(int trial_id, int factor_id,int factor_detail_id,BigDecimal lowLimit,BigDecimal highLimit) care adauga un factor de excludere (atributul factor_mark este egal cu 0) in tabela pentru trialul cu identificatorul trial_id.Valoarea returnata reprezinta statusul operatiunii. Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

public int removeTrialOtherFactor() care sterge din tabela factorul. Stergerea se realizeaza prin identificarea factorului din contextul curent. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

public int removeTrialOtherFactors(int trial_id) care sterge din tabela toti factorii definiti pentru trialul cu identificatorul trial_id. Valoarea returnata reprezinta statusul operatiunii.Valoare negativa indica existenta unei erori in operatiunea de stergere,iar o valoare pozitia indica finalizarea cu succes a operatiunii.

SubjectsNoPerGroup1 – contine numarul subiectilor din grupul unu al unui trial.Acest numar este calculat cu ajutorul interogarii pe tabelul Trial_Subjects. Metoda de calcul al numarului de subiecti din grupul unu pentru trialul cu identificatorul trial_id este:

public int getSubjectsNoPerGroup1(int trial_id)

SubjectsNoPerGroup2 – contine numarul subiectilor din grupul doi al unui trial.Acest numar este calculat cu ajutorul interogarii pe tabelul Trial_Subjects. Metoda de calcul al numarului de subiecti din grupul doi pentru trialul cu identificatorul trial_id este:

public int getSubjectsNoPerGroup2(int trial_id)

TrialEquipmentsView – contine lista echipamentelor utilizate in trialuri.Aceasta lista este populata in urma interogarii tabelei Trial_Equipments.Vederea contine pe langa metodele de set si get si metoda urmatoare:

public int addEquipmentToTrial(int trial_id,String equipmentList) care introduce in tabela toate echipamentele date ca si parametru de intrare subforma unei liste de identificatori separati prin virgula.Valoarea returnata reprezinta statusul operatiunii. Valoare negativa indica existenta unei erori in operatiunea de inserare,iar o valoare pozitia care este chiar identificatorul trialului nou creat indica finalizarea cu succes a operatiunii.

TrialInvitationsView – contine lista tuturor invitatiilor si solicitarilor de inrolare in trialuri.Aceste invitatii provind din tabela Trial_Invitations.Vederea contine pe langa metodele de set si get si urmatoarele metode:

public int refuseTrialInvitation(int trial_id,String trial_name,int person_id,String firstName,String lastName,String email) care sterge invitatia din tabela si trimite notificare al acestui fapt prin email.

public int sendInvitationToPacient(int trial_id,String trial_name,int person_id,String firstName,String lastName,String email) care insereaza invitatia in tabela si trimite notificare al acestui fapt prin email.

public int searchInvitation(int trial_id,int person_id) care cauta invitatia persoanei cu identificatorul person_id pentru trialul cu identificatorul trial_id.

public searchPersonsInvitations(int person_id) care cauta solicitarile de inrolare in trialurile ale persoanei cu identificatorul person_id.

public int deleteInvitation(int trial_id,int person_id) care sterge din tabela invitatia persoanei cu identificatorul person_id pentru trialul cu identificatorul trial_id.

CoordinatorsInvitations – contite lista cu toate solicitarile de inrolare ale pacientilor in trialurile definite de un coordonator de trial.Aceasta lista este populata in urma interogarii tabelei Trial_Invitations.Avem urmatoarea metoda de cautare:

public void getCoordinatorsInvitations(int coordinator_id) care cauta toate solicitariile de inrolare a pacientilor pentru trialurile pe care le-a definit coordonatorul cu identificatorul coordinator_id.

CoordinatorsTrialsView – contine lista cu toate trialurile definite de un coordonator.Aceasta lista este populata in urma interogarii tabelei Trial.Avem urmatoarele metode in aceasta vedere:

public getCoordinatorsTrials(int coordinator_id) care cauta in tabela toate trialurile definite de coordinatorul cu identificatorul coordinator_id.

public int endTrial(Timestamp endDate) care finalizeaza trialul si incheie perioada de preluare a anlizelor pentru pacienti.Finalizarea se realizeaza identificand trialul din contexul curent.

TrialResultsView – contine lista rezultatelor statistice ale trialurilor finalizate.Aceste rezultate sunt defapt inregistrari din tabela Trial_Results.Aceasta vedere contine metoda de inserare a rezultatelor:

public int addTrialResult(int trial_id,String parameter,double responseRate,double averageCorrection,int group_no) care insereaza rezultatul statistic pentru trialul cu identificatorul trial_id.

TrialStaffView – contine lista angajatilor care presteaza servicii in cadrul unui trial.Aceste informatii sunt preluate din tabela Trial_Staff.

TrialSubjectsView – contine lista subiectilor din trialuri.Aceasta lista este populata in urma interogarii tabelei Trial_Subjects.Vederea contine pe langa metodele de set si get si urmatoarele metode:

public int addSubjectToTrial(int trial_id,int person_id,Timestamp start_date,int group_no) care insereaza in tabela legatura dintre trial si pacientul studiat.

public List<TrialSubjectsViewRowImpl> getTrialSubjectsFromGroup(int trial_id,int group_no) care returneaza o lista cu subjectii din trialul cu identificatorul trial_id si din grupul group_no.Obiectele aceste liste sunt tuple din tabela Trial_Subjects.

public List<Integer> getAlreadyEnrolledPersons(in trial_id) returneaza o lista cu identificatorii pacientilor inrolati in trialul cu identificatorul trial_id.

public int removeTrialSubjects(int trial_id) care sterge toti pacientii studiati din trialul cu identificatorul trial_id.

FilterFactorsView – contine lista tuturor categoriilor de factori de stratificare. Aceasta lista este populata in urma interogarii tabelei Filter_factors.

FilterFactorsDetailsView – contine lista tuturor factorilor de stratificare care apartin categoriilor definite in tabela Filter_factors.Acesti factori sunt preluati in urma interogarii tabelei Filter_Factors_Details.

Pe langa aceste vederi mai este controlerul principal al aplicatiei care are si acesta clasa sa de implementare cu urmatoarele metode importante:

public String registerUser(String username,String password,String firstName, String lastName,String address,String email,String telephone,Timestamp birthDate,BlobDomain accessFile) care realizeaza registrarea unu utilizator in aplicatie.Daca adresa de email pe care a introdus-o nu exista in sistem atunci se creaza o inregistrare noua a unei persoane conform datelor introduse si apoi se creaza utilizatorul si drepturile acestuia.In cazul in care adresa de email exista atunci se creaza doar utilizatorul si drepturile acestuia.

public randomize(int trial_id,Boolean fromDataBase, BlobDomain patient_list_ids) care face apelul metodei private de randomizare a pacientilor din baza de date in cazul in care parametrul de intrare fromDataBase este adevarat,iar in cazul in care acesta este fals se apeleaza metoda privata de randomizare pe baza fisierului cu identificatori ale persoanelor din fisierul dat ca si parametru (patient_list_ids).

private int randomizeFromDataBase(int trial_id) care cauta in sistem toti pacientii definiti, preia toti factorii de includere si excludere ai trialului cu identificatorul trial_id.Pe pacientii gasiti in sistem se aplica filtrul factorilor de excludere,apoi lista de pacienti rezultate trece prin filtrul factorilor de incluziune.Aceste filtre de incluziune si excludere sunt metode private numite applyInclusionFilter si applyExclusionFilter.La finalul aplicarii acestor filtrari se verifica daca pacientii pregatiti pentru inserarea exista deja in tabela cu subiecti ai trialurilor.Dupa aceasta verificare se introduc in tabela de subiecti pacientii conform scorului obtinut prin aplicarea filtrului de incluziune si conform proportiei grupelor.

private int randomizeFromFile(int trial_id,BlobDomain patientsFile) care extrage o lista de identificatori ai pacientilor din fisierul dat ca si parametrul. Acesti identificatori trec printr-o sesiune de validare pentru a ne asigura ca intradevar apartin unor persoane.Se face apelul unei metode private checkExistingEnrollments care ne va returna o lista cu identificatorii pe care ii vom adauga in tabela de subiecti conform proportiei grupelor.

private List<Integer> validatePersonsIds(List<Integer> list) care verifica daca lista de identificatori data ca si parametru de intrare contine intradevar identificatori ai pacientilor.Metoda returneaza tot o lista de identificatori,dar acestia sunt validati.

private List<Integer> checkExistingEnrollments(int trial_id,List<Integer> list) care verifica daca elemente din lista identificatorilor exista deja inregitrate in tabela cu subiecti.Metoda returneaza o lista cu identificatorii pacientilor care pot fi inserati.

private List<Integer> getListIdsFromFile(BlobDomain patientsFile) care creaza mai intai un fisier microsoft excel din parametrul de intrare patientsFile din care citeste fiecare inregistrare si formeaza o lista de identificatori ai pacientilor pe care o si returneaza.

private List<MedicalRecordsViewRowImpl> applyExclusionFilter( List <MedicalRecordsViewRowImpl> medicalRecords, List <TrialParametersFactorViewRowImpl> paramFactorsExclusion, List <TrialDiseaseFactorsRowImpl> diseaseFactorsExclusion, List <TrialOtherFactorsViewRowImpl> otherFactorsExclusion) care trece toti pacientii din lista medicalRecords prin filtrele de excludere a factorilor de stratificare,factorilor ce privesc bolile interzise in trial si factorilor ce privesc limitarea pacientilor cu valori alea analizelor cuprinse intre limitele stabilite pentru parametrii biologici. Acesta filtrare se face apeland trei metode private de filtrare pe specific de factori.

private List<InclusionScore> applyInclusionFilter( List <MedicalRecordsViewRowImpl> medicalRecords, List <TrialParametersFactorViewRowImpl> paramFactors, List <TrialDiseaseFactorsRowImpl> diseaseFactors, List <TrialOtherFactorsViewRowImpl> otherFactors) care trece toti pacientii din lista medicalRecords prin filtrele de includere a factorilor de stratificare,factorilor ce privesc bolile studiate in trial si factorilor ce privesc includerea pacientilor cu valori alea analizelor cuprinse intre limitele stabilite pentru parametrii biologici. Acesta filtrare se face apeland trei metode private de filtrare pe specific de factori.Dupa realizarea filtrarii se face intersectia listelor rezultate.Aceasta metoda returneaza o lista de obiecte de tipul InclusionScore care contine identificatorul pacientului si scorul obtinut in urma aplicarii filtrelor de incluziune.

private List<InclusionScore> listIntersection (List<InclusionScore> list1, List<InclusionScore> list2) care realizeaza intersectia a doua liste de obiecte de tipul InclusionScore.Rezultatul intersectiei este returnat.

private List<InclusionScore> listIntersection (List<InclusionScore> list1, List<InclusionScore> list2,List<InclusionScore> list3) care realizeaza intersectia a trei liste de obiecte de tipul InclusionScore.Rezultatul intersectie este returnat.

Private List<InclusionScore> filterByOtherInclusionFactors( List <MedicalRecordsViewRowImpl> medicalRecords, List <TrialOtherFactorsViewRowImpl> otherFactors)

Private List<InclusionScore> filterByParamterInclusionFactors( List <MedicalRecordsViewRowImpl> medicalRecords, List <TrialParametersFactorsViewRowImpl> paramFactors)

Private List<InclusionScore> filterByDiseaseInclusionFactors( List <MedicalRecordsViewRowImpl> medicalRecords, List <TrialDiseaseFactorsViewRowImpl> diseaseFactors)

Private List<Integer> refineInclusionList(int trial_id,List<InclusionScore> inclusionList)

Private List <MedicalRecordsViewRowImpl> filterByOtherExclusionFactors(List <MedicalRecordsViewRowImpl> medicalRecords, List <TrialOtherFactorsViewRowImpl> otherFactors)

Private List<MedicalRecordsViewRowImpl> filterByParameterExclusionFactors(List<MedicalRecordsViewRowImpl> medicalRecords, List <TrialParamterersFactorsViewRowImpl> paramFactors)

Private List <MedicalRecordsViewRowImpl> filterByDiseaseExclusionFactors(List <MedicalRecordsViewRowImpl> medicalRecords, List <TrialDiseaseFactorsViewRowImpl> diseaseFactors)

Private boolean checkAnalysis(List<MostRecentAnalysisRowImpl> analysis,int chemical_element_id,BigDecimal lowLimit,BigDecimal highLimit)

Private int analysisScore(List<MostRecentAnalysisRowImpl> analysis, int chemical_element_id,BigDecimal lowLimit,BigDecimal highLimit)

Private boolean checkDisease(List<DiagnosticRecordsViewRowImpl> diagList, int disease_id)

Public int acceptInvitation(int trial_id,String trial_name,int person_id,String lastName,String firstName,String email)

Public int refuseInvitation(int trial_id,String trial_name,int person_id,String lastName,String firstName,String email)

Public int acceptTrialInvitation(int trial_id,String trial_name,int person_id,String lastName,String firstName,String email)

Public int sendTrialInvitation(int trial_id,String trial_name,int person_id,String lastName,String firstName,String email)

Private int getGroupNo(int trial_id)

Public in startTrial(Timestamp startDate)

Public void generateStatistics(int trial_id)

Private List<Statistics> setStatistics(int trial_id,List<MonitorizedParamter> monitParam,List<TrialSubjectsViewRowImpl> subjectsList)

Public void saveTrialsResults(int trial_id)

Private void addStatisticsToTrial(int trial_id,List<Statistics> statistics,int group_no)

Public void cancelTrialDefinition(int trial_id)

Testare și Validare

Aproximativ 5% din total.

Manual de Instalare si Utilizare

Resurse hardare

Pentru dezvoltarea si testarea aplicatiei sunt necesare urmatoarele:

Procesor Intel i3 2.4GHz

Cel putin 4GB memorie RAM sau 8GB memorie RAM in cazul rularii serverului de baza de date pe aceeasi statie de lucru

Cel putin 20GB spatiu de stocare a datelor pe hard disk.

Placa video cu o memorie mai mare decat 64 MB

Pentru utilizarea aplicatiei sunt necesare urmatoarele:

Procesor 1.5GHz

Memorie 1 GB RAM

Placa video 64 MB

Conexiune la o retea intranet sau internet.

Resurse software

Acest proiect a fost dezvoltat în IDE-ul Oracle JDeveloper 11g Release 2 cu ajutorul framework-ului Oracle Application Development Framework care are la bază limbajul de programare Java EE.Acest mediu de dezvoltare rulează atât pe sistemul de operare Windows(versiunea XP sau mai nouă) cât si pe Linux (Ubuntu 10.04 sau mai nouă).Facilitarea implementării funcționalităților de lucru cu fisiere de tip Microsoft Excel este data de librăria JExcel.Cu ajutorul librăriei Java Simplified Encryption am soluționat problema criptării si decriptării parolelor.Incă o librărie pe care utilizat-o este org.apache.commons.io care m-a ajutat la copierea unui flux de intrare(inputstream) într-un flux de ieșire(outputstream).

Pentru persistența datelor este nevoie de o bază de date Oracle 11g, iar pentru rularea aplicației este nevoie de un server Oracle WebLogic 10.3, unde va fi incărcată și mai apoi accesată prin intermediul unui browser.

Manual de instalare a aplicației

Instalarea mediului de dezvoltare Oracle JDeveloper:

Se ruleaza executabilul

Se alege calea unde va fi instalat componenta middleware

Se alege tipul de instalare “Complete” care include si serverul Weblogic integrat.

Se alege calea JDK-ului

Se asteapta mesajul de confirmare a instalarii

Instalarea bazei de date Oracle 11g:

Se ruleaza executabilul

Se selecteaza metoda de instlare “Advanced Installation”

Se specifica calea unde va fi creat directorul “Oracle Inventory” (acest director este recomandat sa fie comun pentru toate aplicatiile oracle instalate)

Se introduc credentialele

Se alege tipul de instalare “Enterprise Edition”

Se specifica calea unde se doreste instalarea bazei de date

Se alege optiunea “Create a Database”

Se alege tipul bazei de date “General Purpose/Transaction Processing”

Se asteapta mesajul de confirmare a instalarii

Instalarea serverului Weblogic:

Se instaleaza mai intai libraria JRockit

Se ruleaza executabilul

Se alege calea unde va fi instalata componenta middleware

Se alege tipul de instalare “Typical”

Se verifica daca libraria JRockit a fost instalat corect (apare o bifa in casuta corespunzatoare)

Se alege directorul unde va fi instalat serverul Weblogic

Se alege optiunea “No” la solicitarea instalarii nodului de management (aceasta selectie face ca aplicatiile sa ruleze pe serverul administrator)

Se asteapta mesajul de confirmare a instalarii

Manual de utilizare a aplicației

Utilizarea aplicației este particularizată pe mai tipuri de utilizatori.Aceste tipuri sunt: coordonator trial,doctor,asistent,administrator de utilizatori,administratorul bazei de date și pacient.

Manual de utilizare comun fiecărui utilizator

Autentificare utilizatorilor se face prin introducerea numelui de utilizator sau a adresei de email si a parolei dupa care se apasa pe butonul “Autentificare”.

În cazul în care se dorește utilizarea aplicației, dar utilizatorul nu este inregistrat atunci din pagina de start se alege optiunea “Înregistrare” care va direcționează pe pagina de înregistrare unde trebuie completat fiecare câmp solicitat.La selectarea unui rol in aplicație diferit de rolul de pacient,sistemul solicită încărcarea unei fișe de acces care va fi ulterior analizată de către administratorul de utilizatori.După completarea fiecărui câmp și încărcarea fișei de acces,acolo unde este cazul,se apasă butonul “Salveaza înregistrarea”.

Fiecare utilizator are posibilitatea de a-și vizualiza profilul acționând butonul “Profil” și de a se deconecta acționând butonul “Deconectare” din momentul în care acesta este autentificat.

Manual de utilizare pentru coordonatorul trialului

Coordonatorul de trialuri are posibilitatea definirii unor noi trialuri, managerierii trialurilor inițiate de acesta și de vizualizare a datelor atât pentru trialurile încheiate cât și pentru cele în desfașurare.

Definirea unui trial nou se realizeaza prin acționarea butonului “Defineste trial” (figura 7.4.2.1) care va direcționează la prima etapa din definirea trialului.

În aceasta etapa trebuie să întroduceți numele și o scurtă descriere a trialului,selectați perioada de desfășurare exprimantă printr-o valoare numerică care reprezinta numărul de luni,selectați tipul si design-ul trialului(aceasta selecție influențeaza pasul următor în care se lanseaza ipoteza trialului),adăugați parametrii care vor fi urmăriți în acest trial prin selectarea parametrului,directia preconizată a acestuia(majorare sau micsoare) și apăsați butonul “Adaugă parametru” (figura 7.4.2.2).Pentru a trece la a doua etapa a definirii se apasa butonul “Pasul urmator”.

Etapa a doua constă în lansarea ipotezei trialului.În funcție de selecția tipului si a design-ului de trial facută la pasul anterior aplicația solicită introducerea denumirii unui singur tratament atunci când testarea se face doar pe un singur grup de subiecți sau denumirea a două tratamente atunci când testarea se face pe două grupuri paralele de subiecți.Tot în această etapă se stabilește numărul minim de subiecți pentru care trialul poate fi considerat valid.După selectarea tuturor parametrilor se apasă butonul “Calculeaza”.Din acest moment se poate trece la următoare etapă folosind butonul “Pasul urmator”.

Etapa a treia fiind opțională.În această se pot selecta cadrele medicale care vor presta servicii in acest trial.Costul total estimat al trialului va depinde și de această selecție.Pentru a trece la următoare etapă apăsați butonul “Pasul urmator”.

În etapa a patra trebuie facută selecția frecvenței tratamentului exprimata printr-o valoare numerică care reprezintă numărul de zile pe săptămână în care se administrează tratamentul.Există și o selecție opțională a echipamentelor folosite în acest trial.Această selecție va avea impact asupra costului total estimat al trialului.Pentru a trece la următoare etapă apăsați butonul “Pasul urmator”.

In etapa a cinea trebuie facuta selectia factorilor de includere si de excludere din trial.Exista o stratificare a factorilor: boli,parametrii si alti factori.La fiecare nivel al stratificarii exista liste de valori pentru selectia factorului dorit si doua butoane.Primul buton semnifica includerea factorului selectat ca fiind factor de includere,iar al doilea buton ca fiind factor de excludere (figura 7.4.2.4).

Figura 7.4.2.4 – Factori includere/excludere din trial

Dupa selectia factorilor se apasa butonul „Start randomizare” care ofera doua variante de randomizare: randomizarea pacientilor din baza de date sau randomizarea a pacientilor dintr-un fisier excel (fisierul trebuie sa contina doar identificatorii persoanelor pe prima coloana).Pentru fiecare varianta de randomizare se aplica filtru de factori definit (figura 7.4.2.5).

La finalul randomizarii pacientilor pentru a trece la următoare etapă apăsați butonul “Pasul urmator”.

Etapa a sasea este si ultima etapa in care gasiti un sumar al datelor introduse si a selectiilor facute in etapele anterioare.Pentru finalize definirea apasati butonul “Salveaza definirea” in caz contrar apasati butonul “Anuleaza definirea”.

Optiunea „Invitatii/inscrieri in trial” ofera posibilitatea trimiterii de invitatii pacientilor pentru trialuri define definite si luarea unei decizii asupra solicitarilor de inrolare primite.Pentru a invita un pacient intr-un trial dati click pe tabul „Invita pacienti”.Din lista trialurilor disponibile apasati butonul „Selecteaza” pentru a marca trial pentru care se trimite invitatia apoi din lista persoanelor disponibile apasati butonul „Trimite invitatie” din dreptul persoanei la care doriti sa trimiteti invitatia.In tabul „Solicitari de inrolare primite” gasiti lista persoanelor care au solicitat inrolarea in trial.Aceasta solicitare poate fi acceptata apasand butonul „Accepta” sau refuzata apasand butonul „Refuza”

Coordonatorul poate sa lanseze sau sa inchida trialurile definite de accesta actionand butonul „Lanseaza/inchide trial” care il va directiona pe pagina corespunzatoare unde exista un tabel cu lista trialurilor definite.Pentru a lansa un trial trebuie mai intai selectata data lansarii apoi se apasa butonul „Lanseaza trial”, iar pentru a inchide trialul se selecteaza data inchiderii apoi se apasa butonul „Inchide trial”.

Optiunea „Trialuri” directioneaza coordonatorul pe pagina care contine lista trialurilor definite ce acesta si datele statistice aferente fiecarui trial.Datele statistice sunt disponibile atat pentru trialurile incheiate cat si pentru cele in desfasurare.In tabelul afisat exista doua butoane pentru fiecare trial.Apasand butonul „Vizualizeaza rezultate” va aparea un panou cu rezultatele partiale sau finale pentru fiecare grup de subiecti.Apasand butonul „Export excel” va genera un fisier cu toate analizele pacientilor pentru acel trial care poate fi salvat in calculatorul personal.Se poate observa statistica pentru fiecare grup in format grafic selectand unul din trialuri din lista disponibila apoi selectand parametrul pentru care se doreste vizualizarea evolutiei,iar la final actiune pe butonul „Afiseaza grafic”.

Cazuri de utilizare pentru doctor

Utilizatorul cu rolul de doctor in aceasta aplicatie are posibilitatea de a gestiona fisele medicale ale pacientilor,vizualiza rezultatele trialurilor finalizate,vizualiza grafic evolutia subiectilor din trialurile in desfasurare si de a adauga analize subiectilor din trial.

Apasand butonul „Informatii pacienti” aplicatia va directioneaza pe pagina de gestiune a fiselor medicale.Pentru persoanele din lista afisata se poate adauga o fisa medicala apasand butonul „Adauga fisa medicala” care va deschide un panou in care se solicita selectia grupei sanguine,numarul de kilograme ale pacientului si optional introducerea unor observatii suplimentare.La finalul introducerii datelor se apasa butonul „Adauga” pentru a salva fisa medicala.In cazul in care exista o fisa medicala creata si se doreste stergerea aceste se apasa butonul „Sterge fisa medicala”.Persoanelor care au fisa medicala definita se pot introduce diagnostice si analize.Introducerea diagnosticelor se face apasand butonul „Adauga diagnostic” care va deschide un panou unde se solicita selectia bolii sau simptomului ,starea acesteia ,data la care s-a facut diagnosticarea si optional se pot introduce alte detalii despre diagnostic dupa care se apasa butonul „Adauga” pentru a salva operatiunea.Diagnosticele care nu mai sunt de actualitate se pot sterge folosind butonul „Sterge diagnostic”.Tot pentru persoanele care au fisa medicala definita se pot adauga inregistrari in buletinul de analize apasand butonul „Adauga analiza” care va deschide un panou unde se solicita selectia parametrului,valoarea acestuia si data analizei dupa care se apasa butonul „Adauga” pentru a salva inserarea.

Apasand butonul „Adauga analize pentru pacienti” aplicatia va directioneaza pe pagina de colectare a analizelor pentru trialurile in desfasurare.Pentru adaugarea unei analize se selecteaza mai intai trialul in cauza din primul tabel apoi se apasa butonul „Adauga analiza” din dreptul persoanei careia i se doreste adaugarea analizei.La actiunea acestui buton se afiseaza un panou unde exista un tabel cu parametrii urmariti ai trialului selectat.Se introduce valoare si data analizei din dreptul parametrului apoi se apasa butonul „Adauga”.

Rezultatele partiale din trialurile in desfasurare se pot vizualiza apasand pe butonul „Trialuri in desfasurare”.Se selecteaza mai intai o inregistrare din tabelul cu trialuri printr-un singur click,apoi se selecteaza parametrul pentru care se va crea graficul din cele doua panouri disponibile pentru fiecare grup si se apasa butonul „Afiseaza grafic”.

Apasand butonul „Trialuri incheiate” aplicatia va directioneaza pe pagina in care puteti vizualiza rezultatele statistice si grafice ale trialurilor.Printr-un singur click pe o inregistrare din tabelul cu trialuri se face actualizarea datelor din panourile cu informatii despre trial si rezultatele statistice aferente.Pentru a vizualiza grafic evolutia pacientilor in trial apasati butonul „Vizualizeaza grafice” care va afisa un panou unde se solicita mai intai selectia parametrului apoi se apasa butonul „Afiseaza grafic” care va genera graficul evolutiei pacientilor pentru parametru selectat.

Manual de utilizare pentru asistent

Utilizatorul cu rolul de asistent in aceasta aplicatie are posibilitatea de a vizualiza rezultatele trialurilor finalizate,vizualiza grafic evolutia subiectilor din trialurile in desfasurare si de a adauga analize subiectilor din trial.

Apasand butonul „Adauga analize pentru pacienti” aplicatia va directioneaza pe pagina de colectare a analizelor pentru trialurile in desfasurare.Pentru adaugarea unei analize se selecteaza mai intai trialul in cauza din primul tabel apoi se apasa butonul „Adauga analiza” din dreptul persoanei careia i se doreste adaugarea analizei.La actiunea acestui buton se afiseaza un panou unde exista un tabel cu parametrii urmariti ai trialului selectat.Se introduce valoare si data analizei din dreptul parametrului apoi se apasa butonul „Adauga”.

Rezultatele partiale din trialurile in desfasurare se pot vizualiza apasand pe butonul „Trialuri in desfasurare”.Se selecteaza mai intai o inregistrare din tabelul cu trialuri printr-un singur click,apoi se selecteaza parametrul pentru care se va crea graficul din cele doua panouri disponibile pentru fiecare grup si se apasa butonul „Afiseaza grafic”.

Apasand butonul „Trialuri incheiate” aplicatia va directioneaza pe pagina in care puteti vizualiza rezultatele statistice si grafice ale trialurilor.Printr-un singur click pe o inregistrare din tabelul cu trialuri se face actualizarea datelor din panourile cu informatii despre trial si rezultatele statistice aferente.Pentru a vizualiza grafic evolutia pacientilor in trial apasati butonul „Vizualizeaza grafice” care va afisa un panou unde se solicita mai intai selectia parametrului apoi se apasa butonul „Afiseaza grafic” care va genera graficul evolutiei pacientilor pentru parametru selectat.

Manual de utilizare pentru administratorul de utilizatori

Administratorul de utilizatori are posibilitatea de a autoriza accesul utilizatorilor, precum acordarea si dealocarea rolurilor in aplicatie.

Autorizarea utilizatorilor se face folosind selectia statusului din lista de valori (figura 7.4.5.1).

Fisa de acces pe baza careia se verifica rolul utilizatorului se poate descarca apasand butonul „Descarca” din dreptul fiecarui utilizator (figura 7.4.5.2).

Fiecare utilizator poate fi sters din baza de date actionand butonul „Sterge utilizator” din dreptul fiecarei inregistrari(figura 7.4.5.3).

Salvarea sau anularea tuturor modificarile savarsite in timpul administrarii utilizatorilor se face actionand butonul „Salveaza modificarile” sau „Anuleaza modificarile” care anuleaza tranzactiile(figura 7.4.5.4).

Manual de utilizare pentru administratorul bazei de date

Administratorul bazei de date are posibilitatea de a face gestiunea inregistrarilor legate de persoane, echipamente medicale si de date medicale (figura 7.4.6.1).

Actionand butonul „Gestiune persoane” aplicatia directioneaza utilizatorul pe pagina corespunzatoare care contine doua tab-uri.

Adaugarea unei persoane in baza de date se face din tab-ul „Persoane” apasand butonul „Adauga persoana”.La actionarea acestui butonul apare panoul care contine toate campurile necesare inserarii unei noi persoane.Dupa completarea fiecarui camp se apasa butonul „Adauga” pentru a salva inserarea sau „Renunta” pentru a anula inserarea.

Stergerea unei persoane din baza de date se face actionand butonul „Sterge persoana” din dreptul inregistrarii.

Modificarile savarsite in lista de persoane pot fi salvate sau anulate folosind butonul „Salveaza modificarile” sau „Anuleaza modificarile”.

Adaugarea unui angajat in baza de date se face din tab-ul „Angajati” apasand butonul „Adauga angajat”,a carui raspuns este afisarea unui panou cu doua optiuni disponibile (7.4.6.2).

Pentru adaugarea unui angajat nou se apasa butonul „Angajat nou” care va afisa in panoul existent campurile necesare definirii angajatului.Dupa completarea tuturor campurilor solicitate se apasa butonul „Adauga” pentru a salva inserarea sau „Renunta” pentru a anula operatiunea.

In cazul in care persoana exista in baza de date se apasa butonul „Cauta persoana in sistem” care va afisa in panoul existent filtrul de cautare al persoanei.Dupa gasirea persoanei dorite si completarea campurilor solicitate se apasa butonul „Adauga” pentru a salva inserarea sau „Renunta” pentru a anula operatiunea.

Actionand butonul „Gestiune echipamente” aplicatia directioneaza utilizatorul pe pagina corespunzatoare.Pentru a adauga un echipament nou se apasa butonul „Adauga echipament” care va afisa un panou cu campurile necesare inserarii echipamentului. Dupa completarea tuturor campurilor solicitate se apasa butonul „Adauga” pentru a salva inserarea sau „Renunta” pentru a anula operatiunea.

Stergerea unui echipament din baza de date se face actionand butonul „Sterge echipament”.

Modificarile savarsite in lista de echipamente pot fi salvate sau anulate folosind butonul „Salveaza modificarile” sau „Anuleaza modificarile”.

Actionand butonul „Gestiune date medicale” aplicatia directioneaza utilizatorul pe pagina corespunzatoare.In aceasta pagina exista doua sectiuni.Prima sectiune contine un tabel cu lista categoriilor de boli,iar a doua sectiune contine lista bolilor din fiecare categorie.Actionand cu un singur click pe o categorie de boli va actualiza in a doua sectiune lista bolilor care fac parte din acea categorie.

O cateogie de boli poate fi adaugata in sistem folosind butonul „Adauga categorie” care va afisa un pop-up un se solicita denumirea categoriei.Dupa completarea informatiei solicitate se apasa butonul „Adauga”

O boala poate fi adauga in sistem urmand doi pasi.Primul pas este de a selecta printr-un singur click categoria din care face parte boala apoi apasand butonul „Adauga boala” care va afisa un pop-up un se solicita denumirea bolii.Dupa completarea informatiei solicitate se apasa butonul „Adauga”.

Pentru a sterge o categorie de boli sau o boala se apasa butonul „Sterge categorie” sau „Sterge boala” din dreptul fiecarei inregistrari.Stergerea unei categorii de boli implica stergerea automata a tuturor bolilor din acea categorie.

Manual de utilizare pentru pacient

In aceasta aplicatie pacientul isi poate vizualiza propria fisa medicala,adauga analize personale si vizualiza evolutia sa din trialul la care este inrolat,management asupra invitatilor pentru trialuri si nu in ultimul rand poate sa vada o statistica sumara a trialurilor incheiate (figura 7.4.7.1).

Pentru a-si putea vizualiza propria fisa medicala pacientul trebuie sa actioneze butonul „Fisa medicala”.

Adaugarea analizelor personale se face actionand butonul „Adauga analize personale” care directioneaza pacientul pe pagina corespunzatoare.In aceasta pagina apar doar parametrii urmariti in trialul la care este inrolat pacientul.Adaugarea efectiva analizei se face introducand valoarea si data analizei din dreptul parametrului apoi se apasa butonul „Adauga analiza”.

Evolutia persoanla poate fi vizualizata apasand butonul „Vizualizare evolutie personala”.Incarcarea cu date a graficului de evolutie se face selectand unul dinre parametrii din lista de valori apoi apasand butonul „Afiseaza grafic”.

Managementul invitatiilor in trialuri poate fi facut apasand butonul „Invitatii/inscrieri in trial”. In aceasta pagina exista doua sectiuni.Prima sectiune contine un tabel cu lista trialurilor care urmeaza sa fie lansate.Apasand butonul „Trimite cerere” disponibil din dreptul fiecarei inregistrari va trimite un e-mail coordonatorului de trial cu solicitarea de inrolare.A doua sectiune contine un tabel cu invitatiile de inrolare in trial primite.Fiecare invitatie poate fi acceptata sau refuzata apasand butonul „Accepta” sau „Refuza”.

Rezultatele din trialurile incheiate se pot vizualiza apasand pe butonul „Vizualizare trialuri incheiate”.Se selecteaza mai intai o inregistrare din tabelul cu trialuri printr-un singur click,apoi se selecteaza parametrul pentru care se va crea graficul din cele doua panouri disponibile pentru fiecare grup si se apasa butonul „Afiseaza statistica”.

Concluzii

Contributie personala

Analiza rezultatelor obtinute

Dezvoltari ulterioare

Un mare plus pentru aceasta aplicatie ar fi extinderea structurilor de date si dezvoltarea interfetei utilizator astfel incat sa suporte toate tipurile de trialuri existente.Exemplu: testarea unor modele noi de atele ghipsate monitorizand evolutia membrelor,testarea unor modele noi de scaune monitorizand evolutia coloanei vertebrale.

Extinderea bazei de date cu informatii despre boli.Fiecare boala sa aiba asociata o lista de parametrii pe care ii impacteaza,o lista cu tratamente deja testate.

Integrarea unei ontologii medicale din care se pot extrage informatii valoroase ca de exemplu: interdictia administrarii anumitor tratamente pentru diferite boli, legaturi complexe intre boli.

Posibilitatea conectarii echipamentelor medicale la aplicatie pentru a prelua automat analizele medicale ale pacientilor.

Generarea automata a concluzilor la finalizarea trialului folosind algoritmi de inteligenta artificiala.Tot prin utilizarea algoritmilor de inteligenta artificiala sau a parsoarelor de texte sa se creeze un modul de extragerea a informatiilor relevante din fise medicale sau alte documente scris in limbaj natural.

Bibliografie

[1] Duncan Mills and Peter Koletzke:Oracle Jdeveloper 11g Handbook:A Guide to Oracle Fusion Web Development

[2] Br. J. Cancer: Design and analysis of randomized clinical trials requiring pronologed observation of each patient Part I – Introduction and design

[3] Br. J. Cancer: Design and analysis of randomized clinical trials requiring pronologed observation of each patient Part II – Analysis and examples

[4] Sam R.Alapati:Oracle WebLogic Server 11g Administration Handbook

[5] Oracle Database 11g Documentation

[6] www.stackoverflow.com

[7] Tutoriale Jdeveloper, http://andrejusb.blogstop.ro/

[8] Chow,Shao and Wang Sample Size Calculation In Clinical Research,Taylor & Francis,NY.(2003) paginile 85-85

[9] Shein-Shung C.,Jun S.,Hansheng Sample Size Calculation in Clinical Trial. New York:Marcel Dekker Inc. 2003.Capitolul 1.

[10] Friedman LM,Furberg CD,DeMets DL. Fundamentals of Clinical Trials.3rd Edition.Springer-Verlag New York,Inc. 1998

[11] Estimari numar de esantioane online, http://www.cct.cuhk.edu.hk/stat/index.htm

[12] Epiinfo, http://wwwn.cdc.gov/epiinfo/

Bibliografie

[1] Duncan Mills and Peter Koletzke:Oracle Jdeveloper 11g Handbook:A Guide to Oracle Fusion Web Development

[2] Br. J. Cancer: Design and analysis of randomized clinical trials requiring pronologed observation of each patient Part I – Introduction and design

[3] Br. J. Cancer: Design and analysis of randomized clinical trials requiring pronologed observation of each patient Part II – Analysis and examples

[4] Sam R.Alapati:Oracle WebLogic Server 11g Administration Handbook

[5] Oracle Database 11g Documentation

[6] www.stackoverflow.com

[7] Tutoriale Jdeveloper, http://andrejusb.blogstop.ro/

[8] Chow,Shao and Wang Sample Size Calculation In Clinical Research,Taylor & Francis,NY.(2003) paginile 85-85

[9] Shein-Shung C.,Jun S.,Hansheng Sample Size Calculation in Clinical Trial. New York:Marcel Dekker Inc. 2003.Capitolul 1.

[10] Friedman LM,Furberg CD,DeMets DL. Fundamentals of Clinical Trials.3rd Edition.Springer-Verlag New York,Inc. 1998

[11] Estimari numar de esantioane online, http://www.cct.cuhk.edu.hk/stat/index.htm

[12] Epiinfo, http://wwwn.cdc.gov/epiinfo/