1

Cuprins

Introducere............................................................................................................................................. 2
1.1.Importana temei ......................................................................................................................... 2
1.2. Motivaia temei ........................................................................................................................... 2
1.3. Scopul .......................................................................................................................................... 2
1.4. Rezultatele preconizate .............................................................................................................. 4
2. Cadrul teoretic i cercetrile anterioare .......................................................................................... 4
2.1.1. La nivel naional .................................................................................................................. 4
2.1.2. La nivel internaional .......................................................................................................... 4
2.1.3. Actualitatea i relevana ...................................................................................................... 5
2.2. Relaionarea cu rezultatele cercetrilor anterioare ................................................................ 7
2.3. Aspecte deficitare din literatur de specialitate....................................................................... 8
3. Soluia propus .................................................................................................................................. 9
Analiz-proiectare, arhitectur, programare ................................................................................. 9
Stabilirea necesarului de resurse software i hardware ............................................................. 9
Estimarea necesarului de resurse ................................................................................................. 9
Proiectarea bazei de date ............................................................................................................ 11
Analiza i proiectarea formatelor de intrare-iesire ...................................................................... 17
Interfaa grafic ............................................................................................................................... 19
Interfaa comun utilizator-administrator ................................................................................... 21
Interfaa utilizator ........................................................................................................................... 23
Definirea activitilor de ntreinere a funcionalitilor proiectului ......................................... 35
Caracter inovativ ............................................................................................................................. 36
4. Concluzii, rezultate, propuneri ...................................................................................................... 36
Relevana n raport cu cheltuielile anterioare i realitatea economic ....................................... 36
Realismul i fezabilitatea soluiei propuse .................................................................................... 37
Aspecte critice legate de punerea n practic ................................................................................ 37
Recomandri pentru cercetrile ulterioare ................................................................................... 37
5. Bibliografie ....................................................................................................................................... 38
6. Anexe ................................................................................................................................................ 40
2



Introducere

De la momentul naterii pn la momentul decesului fiecrei persoane i este atribuit un
numr unic de nregistrare.Acesta face parte dintr-o baz de date cu o multitudine de
nregistrri.n ultimii 20 de ani s-a ncercat colectarea informaiilor ntr-un singur loc pentru a
facilita accesul medicilor i a pacienilor n vederea eficientizrii serviciilor medicale. Pentru
a pune n legtur simptomatologia medical, cu informaiile actuale s-a dorit realizarea unui
sistem de diagnosticare la distan. Acest ar facilita accesul pacienilor la informaiile
medicale i ncadrarea lor ntr-un program de contientizare asupra riscurilor i
afeciunilor.Totodat implementarea soluiei ar ajuta medicii la identificarea i eliminarea
neconcordanelor i la punerea unui diagnostic ntr-un timp mult mai scurt, prin verificarea
datelor i la accesarea diagnosticului medical electronic cu acordul pacientului.Sistemul face
trimitere la medicaia corespunztoare n cazuri mai uoare sau returneaz un diagnostic i
sugereaz un medic competent n domeniul afeciunii respective.
1.1.Importana temei

Tema aleas dorete s ofere o imagine aspupa beneficiilor pe care le-ar putea aduce
achiziionarea unui sistem de diagnosticare la distan pentru dispozitivele mobile, n acest fel
medicii de familie, pacienii i familiile lor se pot consulta cu specialitii notri i pot folosi
aceast consultan pentru a lua deciziile optime n ceea ce privete tratamentul. Istoricul
analizelor se pstreaz n condiii de siguran deplin, pe perioade nelimitate de timp.

1.2. Motivaia temei

Prezenta lucrare i propune s faciliteze accesul pacienilor la o baz de informare prin
oferirea unei soluii medicale la distan.Varianta propus ofer posibilitatea informrii cu un
cost mult mai mic n comparaie cu celelalte soluii existente pe pia. Aceast aplicaie
propune un mod diferit de prezentare a datelor, ntr-un timp foarte scurt i cu resurse limitate.

1.3. Scopul

Progresul rapid n medicin i dorina sporit de cunoatere a condus la necesitatea
implementrii acestei soluii de diagnosticare la distan, prin care toi utilizatorii pot s
cunoasc n cel mai scurt timp, cum se situeaz din punct de vedere al sntii.
3


Aceast aplicaie propune o variant modern de diagnosticare la distan, folosind un
dispozitiv mobil, putem afla n cel mai scurt timp dac suferim de o anumit boal i care ar fi
medicul sau medicaia corespunztoare, bazndu-ne pe simptomele avute(indiferent dac
pacientul se afl ntr-un loc n care nu poate beneficia imediat de asisten medical).Ideea
diagnosticrii la distan a cunoscut numeroase etape, iar n prezent se dorete crearea de
aplicaii care s furnizeze potenialilor pacieni, informaii eseniale despre starea lor de
sntate, precum i tratamente sau medici care s vindece respectivele afeciuni.
n prezent, majoritatea rilor din lume (n particular i ara noastr) sunt confruntate cu
schimbri n domeniul sntii. Pe de o parte, dezvoltarea noilor tehnologii genereaz
sporirea sarcinilor de rezolvat de ctre medici. Pe de alt parte, noile moduri de a tri i de a
munci conduc la mbtrnirea populaiei, iar ubrezirea sntii este n cretere evident. n
aceste condiii rile membre ale UE aloc anual pentru cheltuieli n domeniul sntii peste
de 6-7% din produsul intern brut, de exemplu Frana i Germania aloc chiar 10%.[3][7]
Cercetrile privind aplicaiile telematice n domeniul medical ar putea contribui semnificativ
la rezolvarea problemelor generate de schimbrile menionate mai sus. UE aloc fonduri
substaniale pentru dezvoltarea aplicaiilor telematice de care s beneficieze toi cetenii. n
prezent, Europa este lider mondial n ceea ce privete aplicaiile medicale, bazate pe agende
rapide sau pe reele telematice regionale destinate ngrijirii sntii.

Fig.1 Model de sistem de diagnosticare la distan
n fig.1 este prezentat un model de sistem de diagnosticare la distan realizat de specialitii
din Frana, pentru eficientizarea procesului final de diagnosticare.Unele dintre proiectele
realizate/ n curs de realizare sunt centrate pe contribuia aplicaiilor telematice n lupta
mpotriva principalelor boli (boli cardiace, cancer etc.) din rile dezvoltate.
4


1.4. Rezultatele preconizate

Implementarea soluiei ar eficientiza procesul de informare n domeniul medical, utiliznd
mai puine resurse financiare, ntr-un timp mult mai scurt i pentru un numr mult mai mare
de pacieni.Crearea unui mediu de informare rapid, simplu de folosit i n acelai timp la un
pre rezonabil pentru beneficiar. Se dorete schimbarea percepiei pacienilor prin
familiarizarea acestora cu informaia electronic i crearea mentalitii conform creia
utilizarea aplicaiilor medicale la distan constituie un beneficiu pentru fiecare persoan.
Soluia propus are ca scop reducerea timpului necesar pentru investigare i informare cu
privire la o anumit afeciune,indiferent de locul n care se afl i prezentarea acestor
informaii ntr-o form automatizat.
2. Cadrul teoretic i cercetrile anterioare
2.1.1. La nivel naional
n mod paradoxal, Romnia este printre rile cele mai avansate n conectarea la distan pe
sistemul de urgen, dispunnd de sisteme de transmitere imagistic, tomografii
computerizate, radiografii de la ambulane la spitale i mai departe, la spitalele regionale
pentru preri avizate. Acest model intra-spitalicesc, de spitale interconectate poate fi
completat cu medicina individualizat.

2.1.2. La nivel internaional
Telemedicina se dezvolt cu rapiditate ca o aplicaie de medicin clinic n cadrul creia
informaia este transferat prin telefon sau internet i, uneori, prin alte reele, cu scopul de a
oferi consultan, diagnoz, tratament la distan sau chiar de a efectua examinri i proceduri
medicale.[1] De la stenii din Africa care acum dou secole aprindeau focuri pe coline i
semnalizau astfel strinilor s rmn n afara granielor aezrilor lor pentru a nu se molipsi
de diverse boli contagioase i pn la The Royal Flying Doctor Service of Australia ce
folosea la nceputul anilor 1900 emitoare radio activate de un dinam cu pedale pentru
comunicarea medic-pacient, telemedicina a progresat i ofer astzi trei categorii principale
de dezvoltare:
1. nmagazinare i transmitere de date medicale (aa-numitul store and forward, n care
datele transmise sunt apoi analizate off-line i nu necesit prezena i participarea
ambelor pari n acelai timp);
2. monitorizare la distan n timp real, cunoscut i ca auto-monitorizare (permite
specialitilor s monitorizeze pacienii la distan folosind diverse aparate, n special
pentru boli cronice);
5


3. telemedicina interactiv, care ofer interaciune n timp real ntre specialist i pacient,
inclusiv consultaii telefonice, comunicare online, urmate de tratament la
domiciliu.[8][12]
Telemedicina reduce semnificativ numrul de spitalizri, reduce numrul de readmisii n
spital dup externare, micoreaz listele de ateptare pentru tratamente medicale, economisind
astfel resurse importante att pentru pacieni (transport, analize, consultaii), ct i pentru
prestator (medic, clinic, spital). Aceast tehnologie permite pacienilor, dar mai cu seam
specialitilor, s monitorizeze parametrii vitali, s ofere servicii de consultan i tratament n
timp real, fr s fie necesar ca pacientul s se deplaseze, reducnd astfel anxietatea provocat
de vizitele la clinici i spitale.
Impactul telemedicinei asupra resurselor medicale (paturi de spital, vizite ale pacienilor
externi, faciliti asistate, monitorizri ECG) este pe msura celui asupra bolilor cronice
(diabet, hipertensiune). Procesul de acceptare i extindere a folosirii acestor tehnologii este un
rezultat iminent al valorii "medicinei wireless" n domeniul medical n general i n
cardiologie i boli cronice n special.[13][17]

2.1.3. Actualitatea i relevana
n contextul n care n 2010 au fost descrcate 5 miliarde de aplicaii mobile la nivel mondial
(iOS, Android, Windows etc.), iar conform previziunilor, n 2013, numrul acestora va ajunge
la 21 de miliarde, nu mai putem trece cu vederea suporturile mobile. Acestea au devenit
instrumentele de marketing cele mai apropiate de utilizatori/consumatori i reprezint
prelungirea ateptat a sistemelor informatice. Terminalele mobile (iPhone, Android,
Windows Phone etc.) dispun de ecrane de dimensiuni mai mici dect cele ale
computerelor/laptopurilor i ncorporeza noi funcionaliti care ncurajeaz utilizarea
acestora de ctre consumatori (camera foto, GPS, acceloremetru, ecran tactil etc.). Utilizatorii
de internet mobil de astzi comunic, folosesc, lucreaz i se joac oriunde, oricnd i pe
orice suporturi mobile (telefoane smartphone i tablete precum iPad).[15][16][18]
Conform raportului Global Mobile Health Market Report 2010-2015 realizat de
Research2guidance - o firm german de cercetare de telefonie mobil, specializat n
asisten medical de telefonie mobil, aplicaiile smartphone vor reprezenta un element
esenial n contientizarea beneficiilor serviciilor de ngrijire medical prin intermediul
telefoniei mobile, situndu-le ca sector major n rndul asistenei medicale. Datorit avalanei
de smartphone-uri pe pia i a capacitii de extindere a tehnologiei care permite att
medicilor, ct i pacienilor s beneficieze de servicii de asisten medical de oriunde.
n primul rnd, medicina de laborator se confrunt cu provocarea de cretere a productivitii
i a eficienei testrii, impuse de progresele tehnologice dominante. n timp ce eforturi
substaniale au fost plasate pentru a reduce vulnerabilitatea i a crete calitatea procesului total
de testare, exist nc dovezi c erorile, incertitudinea i defectele sunt nc prezente n unele
etape de diagnostic de laborator [4]. Cunotine vaste s-au adunat cu privire la problema de
6


siguran a pacienilor, acestea atest c marea majoritate a problemelor apar nc n fazele
extra-analitice de testare. n timp ce activitile manuale din etapa preanalitica sunt n mare
parte responsabile pentru rspndirea la nivel global, o analiz cuprinztoare a fazei
postanalitice arat c cele mai multe probleme apar n cadrul raportului de laborator
[5].Practic, un audit al performanelor este crucial pentru a permite laboratoarelor s
monitorizeze activitatea i asigure cele mai bune practici pentru pacieni.Interpretarea
"clinic" a rezultatelor testelor, este de asemenea, vital pentru optimizarea procesului
decizional de diagnosticare i mbuntirea calitii de ngrijire [5][6]. Rapoartele, studiile i
viaa de zi cu zi sugereaz c exist nc un decalaj inacceptabil n nelegerea rolului de
comunicare a serviciilor de livrare de ngrijire a sntii, inclusiv a datelor de laborator.
Organizaia Mondial a Sntii a creat recent termenul de "mHealth," definit ca "o zon de
sntate electronic" pentru "furnizarea de servicii de sntate i de informaii pe telefoanele
mobile i PDA-uri. Dei o list complet a tuturor aplicaiilor este disponibil n prezent, este
lng scopul acestui raport i ar putea fi inutil, datorit extinderii nencetat de aplicaii i
coninut, este nc demn de remarcat pentru a descrie potenialitatea unora dintre acestea. De
asemenea, este uor de neles c hardware-ul este doar o parte de joc, deoarece factorul cheie
pentru viitor va fi bogia de aplicaii care sunt dezvoltate pentru aceste platforme.[14]
Tehnologia mobil are un mare potenial de a revoluiona tiina, medicina i medicina de
laborator, de asemenea, ofer acces permanent la cele mai noi informaii medicale, precum
urmrirea contiun i verificarea contraciei modelelor i nregistrri istorice ar permite
medicilor s fie mai eficieni n activitile lor de zi cu zi, n timp ce furnizeaz servicii
medicale actualizate pacieniilor [11]. Mai mult, medicii ar putea avea n curnd posibilitatea
de a efectua o analiz imagistic medical i de a transmite deciziile de diagnostic direct din
cabinetul lor, pe telefonul pacientului. Cu toate acestea, sarcinile de diagnosticare reale (de
exemplu, valorile de referin, informaii pe rezultatele de laborator, e-prescriere, etc) au fost
oarecum lente, n ciuda creterii cererii att a personalului medical ct i a pacienilor. Ca
atare,"mHealth" ar putea fi o oportunitate pentru pacieni, mai degrab dect un risc, cu
condiia ca toate aplicaii medicale i de laborator supuse dezvoltrii i formrii procesului de
revizuire n strns cooperare cu profesionitii din domeniul medicinei de laborator.
n fig.2 se poate observa modalitatea n care se prezint arhitectura specific telefoniei mobile
i modul n care se realizeaz transferul datelor ntre entitile participante.

7



Fig.2 Exemplu de arhitectur a unui sistem de diagnosticare(telefonie mobil)

n consecin, firma de cercetare estimeaz c pn n 2015, numrul celor ce vor utiliza
serviciile de ngrijire medical cu ajutorul telefonului mobile va ajunge la 500 de
milioane.eful departamentului de cercetare la research2guidance, Ralf Jahns-Gordon,
susine c revoluia mult-ateptat de telefonie mobil n domeniul sntii este pe cale s se
petreac, att furnizorii de asisten medical, ct i consumatorii mbrieaz ideea de a
folosi smartphone-urile ca mijloc de mbuntire a asistenei medicale.n prezent, exist
17.000 de cereri mHealth (aplicaii mobile de ngrijire a sntii) n app store-uri. Aproape
jumtate (43%) din aplicaiile de sntate disponibile n prezent vizeaz furnizorii de servicii
i cadrele medicale. Acest lucru se reflect n faptul c doar 26% sunt gratuite, n timp ce
restul de 74% se bazeaz pe modelul business premium sau plteti pentru a descrca.[9][13]
Potrivit raportului, pe msur ce numrul furnizorilor de asisten medical tradiional ce vor
adera la piaa aplicaiilor mobile va crete, modelele de afaceri se vor extinde cu scopul de a
include servicii de asisten medical, publicitate i venituri din vnzarea medicamentelor.Se
pare c cea mai mare parte din venituri va proveni din serviciile legate de telefonia mobil
(46%) i a vnzrilor de dispozitive (30%), iar download-ul de aplicaii va reprezenta doar
14%.[13]
2.2. Relaionarea cu rezultatele cercetrilor anterioare

Cercetrile anterioare la care au fost supuse aplicaiile cu specific medical din ntreaga lume,
au evideniat o serie de beneficii pe care acestea le aduc utilizatorului i sistemului medical n
general.
O parte din aceste avantaje sunt :
8



oferirea de tratament n timp real, prin utilizarea dispozitivelor fr fir;
salvarea vieii pacienilor prin intermediul consultaiilor medicale de la distan, att n
caz de urgen, ct i pentru diagnosticarea unor afeciuni;
accesibilitatea crescut la specialitii din centrele medicale pentru locuitorii din mediul
rural, n ceea ce privete diagnosticul i tratamentul;
facilitarea unor diagnostice precoce i precise;
optimizarea lurii deciziilor medicale i creterea calitii asistenei medicale printr-o
mai bun i rapid informare;
creterea eficienei n furnizarea serviciilor medicale;
asigurarea rapid a accesului la istoricul medical al pacienilor, reducnd astfel riscul
interaciunilor medicale negative i cel al rspunsului slab la tratamentele prescrise;
mbuntirea eficienei administrative i o mai bun coordonare n asigurarea
asistenei medicale;
creterea oportunitii tratamentului i scderea ratei reinternrilor, reducnd astfel
costurile medicale;
consolidarea strii de sntate a vrstnicilor i asigurarea de ngrijire preventiv, prin
monitorizare medical la domiciliul acestora, efectuat de la distan.[18]

2.3. Aspecte deficitare din literatur de specialitate

n literatura de specialitate nu exist foarte multe studii realizate pe aceast tipologie de
aplicaii,i n acest fel orice tentativ de informare asupra beneficiilor i riscurilor pe care le
implic utilizarea acestor aplicaii.Detalii legate de proiectare i implementare ar trebui oferite
celor ce doresc s implementeze o aplicaie medical,deoarece n acest fel ar putea fi evitate
numeroase erori de cod,ce pot duce la elaborarea unui plan de medicaie care poate s pun n
pericol viaa Patientului.Studiile realizate pn n prezent se refer la aplicaii medicale n
domeniul cardiologiei sau testeaz diferite modificri ale dermului.



9


3. Soluia propus
Analiz-proiectare, arhitectur, programare

Aplicaia se dorete a fi realizat cu ajutorul codului Java, pentru dispozitivele cu sistem de
operare Android, avnd o baz de date unde vor fi stocate date despre medici, tratamente,
sfaturi i boli, prin relaionarea unor simptome cu bolile care au manifestri asemntoare.
Stabilirea necesarului de resurse software i hardware

Din punct de vedere funcional, proiectul presupune crearea unei interfee uor de utilizat, prin
care utilizatorul s aib acces la informaiile medicale.Prin selectarea anumitor simptome sau
caracteristici ale bolilor aflate n baza de date a aplicaiei, se va prezenta un diagnostic
prezumptiv, menit s descrie posibila tipologie a bolii, tratamentul aferent acesteia i medicul
aflat n cea mai apropiat locaie, care ar putea s se ocupe de aceast afeciune sau s pun un
diagnostic medical 100% sigur.
Din punct de vedere general, o arhitectur mobil omniprezent este format din diferite
module wireless cooperante, n scopul de a efectua achiziia de date, analiza datelor i decizia
prin mai multe tehnici i redirecionare de date i feedback.Arhitectura propus se refer la
proiectarea unui instrument flexibil pentru achiziie de date, management, elaborarea i
decizia potrivite pentru acele sisteme care sunt echipate cu dispozitive uor de purtat,
distribuite la distan, n cazul n care o atenie deosebit este destinat fluxului de informaii
medicale eterogene i de intercomunicare. n plus, posibilitatea de a opera n timp real,
impune cerine critice de eficient pentru fiecare modul creat.
Modul de analiz al server-ului este bazat pe cunoaterea modular care s permit o evaluare
obiectiv i cantitativ a datelor i suport de decizie, ce prevede avertismente i feedback. La
configurarea treptelor fixe de timp sau ca urmare a solicitrii utilizatorului, modulul :
(i) va prelua datele relevante din baza de date central, aflat la distan
(ii) va aplica analiza algoritmilor
(iii) pstreaz rezultatele analizelor ntr-un raport specific n baza de date
centralizat.Poate fi configurat un sondaj pentru analizarea i raportarea la un
anumit interval de timp fix sau la cererea utilizatorului. n acest mod aplicaia
funcioneaz ca sistem destinat clientului n ceea ce privete server-ul de module
de analiz.

Estimarea necesarului de resurse
n ceea ce privete elementele determinate pentru configuraia unui echipament de prelucrare,
ar trebui s avem n vedere:
10




1.Memoria intern
Estimarea necesarului de memorie intern se face pe baza relaiei de calcul:
M = M1+M2, unde:
M = necesarul total de memorie,
M1 = necesarul de memorie pentru folosirea sistemului de operare ales,
M2 = necesarul de memorie pentru execuia programelor aplicative.
Formula pentru necesarul de memorie intern pentru programe aplicative este:
M2 = max(Ma,Mb, ..,Mn).

2.Estimarea necesarului de echipamente periferice ale sistemului central de prelucrare

Se realizeaz n funcie de echipamentele de intrare-iesire i de unitile de memorie extern.
Numrul echipamentelor periferice necesare se stabilete raportndu-se la urmtorii factori:
- fluxurile de intrare-ieire
- volumul de date ce se cere a fi stocat n memoria extern
- modul de exploatare
- numrul de programe ce se execut n paralel
Dispozitivele portabile trebuie s fie n conformitate cu urmtoarele caracteristici (ce trebuie
adoptate):
(i) Sistem de operare la nivel nalt (Windows Mobile, iOS, Android)
(ii) Ecran mare pentru interfaa utilizator (3-9 cm)
(iii) Touch screen
(iv) Memorie intern + card SD (2 GBS)
(v) Puternic intern CPU (400-600 MHz)
(vi) Conexiune WiFi/3G pentru comunicare cu servere la distan
(vii) Conexiune Bluetooth / Zigbee pentru comunicarea cu senzori portabili
(viii) Baterie de lung durat(1 autonomie de cel puin o zi)
(ix) Ergonomie.
Dispozitivul va comunica cu serverul n urmtoarele situaii:
Conexiune bazat pe timp: toate datele necesare analizei de la distan, modulele
trebuie s fie ncrcate. Decompresia datelor este esenial pentru limitarea timpului
11


de ncrcare. Mai mult dect att, criptarea este obligatorie pentru acordarea
confidenialitii datelor personale. Autentificare continu poate fi evitat cu ajutorul
certificatelor de autorizate.
Conexiune de urgen: n timpul monitorizrii senzorilor, n cazul n care modul de
raionament detecteaz o condiie specificat, care sugereaz o urgen, trimite datele
colectate la serverul central, n scopul de a primi evaluarea clinic i planificarea
tratamentului.
SDK-ul Android include un set complet de instrumente de dezvoltare. Acestea includ un
program de depAnare, biblioteci, un emulator de dispozitiv (bazat pe QEMU), documentaie,
monstre de cod i tutoriale. Platformele de dezvoltare sprijinite n prezent includ calculatoare
bazate pe x86 care ruleaz Linux (orice distribuie Linux desktop modern), Mac OS X 10.4.8
sau mai recent, Windows XP sau Vista. Cerinele includ, de asemenea, Java Development Kit,
Apache Ant, i Python 2.2 sau o versiune ulterioar. Mediul de dezvoltare (IDE) suportat
oficial este Eclipse (3.2 sau mai recent), utiliznd plug-in-ul Android Development Tools
(ADT), dei dezvoltatorii pot folosi orice editor de text pentru a edita fiiere XML i Java i
apoi s utilizeze unelte din linia de comand pentru a crea, construi i depana aplicaii
Android.
Proiectarea bazei de date

Baza de date este o colecie de date corelate din punct de vedere logic, care reflect un
anumit aspect al lumii reale i este destinat unui anumit grup de utilizatori. Bazele de date
pot fi create i meninute manual sau computerizat, aa cum este majoritatea bazelor de date
folosite n momentul de fa.
O baz de date este o colecie de date creat i meninut computerizat, care permite operaii
de introducere, tergere, actualizare i interogare a datelor.
Metodologia de proiectare, const ntr-o abordare structurat, n care se utilizeaz proceduri,
tehnici, instrumente i documentaii, pentru a susine i facilita procesul de proiectare.O
metodologie de proiectare const n mai multe faze, coninnd etape care ndrum proiectantul
n alegerea tehnicilor adecvate fiecrei etape a proiectului; de asemenea l ajut la: planificare,
administrare, control i evaluarea proiectelor de dezvoltare a bazelor de date. n final are loc o
abordare structurat de analiz i modelare a unui set de cerine privind BD, ntr-o manier
standardizat i organizat.
SQLite este o mic bibliotec C care implementeaz un motor de baze de date SQL
ncapsulat, ofer posibilitatea de a o stoca n diverse sisteme i necesit zero-configurare.
Distribuia SQLite vine cu un program linie-comand de sine stttor (sqlite) care poate fi
folosit pentru a administra o baz de date SQLite i care servete ca un exemplu despre modul
n care trebuie folosit librria SQLite.
n fig.3 sunt prezentate tabelele bazei de date i legturile dintre acestea:
12


- tabela pacient are o legtur de 1: n cu tabela Symptom
- tabela Symptom are o legtur de 1:1 cu tabela Condition_Symtom
- tabela Condition_Symptom are o legtur de n:1 cu tabela Condition
- tabela Condition are o legtur de 1: n cu tabela Specialization_Condition
- tabela Specialization are o legtur de 1: n cu tabela Specialization_Condition
- tabela Specialization are o legtur de 1: n cu tabela Medic_Specialization
- tabela Medic are o legatura de 1:n cu tabela Medic_Specialization

Fig.3 Schema bazei de date
n ceea ce privete datele de intrare, se regsesc urmtoarele :
Datele utilizatorului :
- Nume i prenume utilizator
- Parol
- Id
- Email
Date referitoare la simptomele pentru care este necesar un anumit diagnostic:
- Modificri ale temperaturii de baz
- Modificri ale ritmului cardiac
13


- Dureri
- Acuitate vizual sau auditiv modificat
- Tulburri de echilibru sau de orice alt natur,etc
n momentul n care datele de intrare au fost prezentate,se ateapt realizarea unei interogri
asupra bazei de date i returnarea unui rezultat pertinent.Rezultatul va conine datele de ieire,
care trebuie s fie ntr-o msur ct mai obiectiv i s returneze un diagnostic prezumtiv i
un medic(de preferin cel mai apropiat ca locaie de locul n care se afl utilizatorul la acel
moment).
Ca date de ieire vom avea:
Date referitoare la diagnostic:
- Tipologia n care se ncadreaz boala
- Modul n care se manifest
- Recomandrile aferente(n cazul n care este o afeciune uoar, se poate recomanda
un anumit medicament pentru ameliorarea strii de sntate; n cazurile mai grave se
va returna numele unui medic, specializarea acestuia i locaia n care acesta activeaz,
pentru a se facilita accesul la informaie i rezolvarea n timp util a problemei de
sntate)
Datele referitoare la medic:
- Nume
- Specializarea
- Locaia (adresa complet pentru o mai bun informare a pacientului)
- Parafa
n cazul n care simptomele indic o urgen medical, se recomand prezentarea la medicul
specificat n cel mai scurt timp pentru rezolvarea problemei i evitarea agravrii acesteia.

Analiza i proiectarea structurilor de date

Avnd prezentate mai sus, n linii mari, detaliile sistemului informatic n cauz, urmtorul pas
logic n atingerea elului va fi de a analiza structurile de date/entitile folosite de aplicaie
sau care, dei nu sunt accesate direct de ctre aplicaie, au un aport benefic la structura,
funcionalitatea i integritatea aplicaiei.
Tabele aferente structurilor de date vor purta denumirea n englez a fiecrei entiti.
O prim entitate ce rezult din tema problemei este: Medic.
14


Fiind o entitate de baz, aceasta va necesita un numr de cmpuri cu caracter informativ
relativ mare, motivul fiind dat felul n care sistemul informatic va funciona, faptul c n
momentul n care utilizatorul va ajunge n pasul final (diagnosticare ncheiat) acesta va
dori s afle, spre exemplu, cteva date de contact ale medicului ce i-a fost recomandat n baza
simptomelor descrise.
Cmpul de tip cheie primar, denumit n cazul nostru MedicID, va necesita un tip de date de
tip String, cu lungime fix 10, ce va fi compus din sub-structuri ce vor oferi anumite
informaii. Spre exemplu: primele 3 caractere vor reprezenta codul generat de prescurtrile
spitalului i numrului deinut de spitalul la care lucreaz medicul afiat de aplicaie: n cazul
n care medicul aparine unei anumite uniti medicale, codul rezultat va fi: H0x(unde x
reprezint numrul asignat unitii medicale n care acesta i desfoar activitatea).n cazul
n care medicul nu este asignat unui spital de urgen, se vor preciza caracterele aferente
judeului de care aparine spitalul la care acesta este angajat. Urmtoarele 3 caractere vor
reprezenta specializarea i va trebui s reflecte un cod specificat n cadrul structurii de date
denumit Specialization( exemplu: Dermatologie -> DRM).n cazul n care specializarea
respectiv include mai multe subramuri, acestea vor fi precizate pentru o mai bun
nelegere.Utilizatorul trebuie informat despre eventualele aspecte care pot reprezenta aspecte
importante n cazul n care diagnosticul reflect faptul c ar trebui s se intervin n cel mai
scurt timp.Restul de 4 caractere vor fi folosite drept paraf, n format string, cu zero-uri i
caractere(n cazul medicilor care au mai multe specializri sau au doar o parte din subramurile
unei anumite specializri) ce preced numrul current(exemplu forma final: H01DRM0001)
Urmtoarele cmpuri vor fi folosite cu caracter informative, cum ar fi:
Name: tip de dat String cu lungime fix de 50 de caractere.
Location : tip de dat String cu lungime fix de 100 de caractere.
Seal : tip de dat String cu lungime fix de 4 caractere
b) Symptom
Cmpuri utilizate:
Cheie primar: SymptomID - tip de dat Integer, auto incrementat, unic, non-nul
Urmtoarele cmpuri, cu caracter informativ:
Type: tip de data String, cu o lungime fix de 40 de caractere.
Description: tip de data String, cu o lungime fix de 100 de caractere.
c) Diagnostic
Cmpuri utilizate:
Cheie primar: DiagnosticID, tip de dat Integer, auto incrementat, unic, non-nul
Urmtoarele cmpuri, cu caracter informativ:
15


Diagnostic_name, tip de dat String, lungime fix de 45 de caractere.
MedicID reprezint cheia extern i elementul de legtur cu tabela Medic.
PatientID reprezint cheia extern i elementul de legtur cu tabela Patient.
Tabela are o relaie de n-1 cu tabela Medic .
d) Patient
Cmpuri utilizate:
Cheie primar: PatientID, tip de dat Integer, auto incrementat, unic, non-nul
Name: tip de dat String, lungime fix de 45 de caractere
Surname: tip de dat String, lungime fix de 45 de caractere
Email: tip de dat String, lungime fix de 50 de caractere
IsActive: tip de dat String, lungime fix de 3 caractere
LastLogin: tip de dat date, lungime fix de 8 caractere
Role: tip de dat String, lungime fix de 30 de caractere
Password: tip de dat String, lungime fix de 45 caractere
SymptomID este cheie extern i legtura ntre aceast tabel i tabela Symptom.
e) Specialization
SpecializationId: tip de dat String, lungime fix de 5 caractere
Description: tip de dat String, lungime fix de 100 caractere
SpecializationId este cheie extern a tabelei Medic_Specialization i element de legtur ntre
cele dou tabele.
f) Specialization_condition
Specialization_condition_id: tip de dat String, lungime fix de 5 caractere
Specialization_id: tip de dat String, lungime fix de 5 caractere
Condition: tip de dat String, lungime fix de 60 caractere
SpecializationId este cheie extern a tabelei i element de legtur cu tabela Specialization.
g) Condition
ConditionId: tip de dat String, lungime fix de 5 caractere
16


Name: tip de dat String, lungime fix de 100 de caractere
Description: tip de dat String, lungime fix de 150 de caractere
ConditionId este cheie primar a tabelei i element de legtur cu tabela
Specialization_condition.
g) Condition_symptom
Condition_symptom_id: tip de dat String, lungime fix de 10 caractere
ConditionId: tip de dat String, lungime fix de 5 caractere
SymptomId: tip de dat String, lungime fix de 5 caractere
ConditionId este cheie extern a tabelei i element de legtur cu tabela Condition.
SymptomId este cheie extern a tabelei i element de legtur cu tabela Symptom.
Aplicaia se dorete a fi realizat cu ajutorul codului Java, pentru dispozitivele cu sistem de
operare android, avnd o baz de date unde vor fi stocate date despre medici, tratamente,
sfaturi i boli, prin relaionarea unor simptome cu bolile care au manifestri asemntoare.
Toate cmpurile destinate importului de date/datelor de intrri vor fi validate i valorile date
vor trebui s fie conforme cu tipul de dat i dimensiunea impuse la crearea bazei de date.
Excepie fac cele ce vor primi o valoare dintr-un set predefinit de date asupra crora s-au
fcut deja verificrile mai sus numite.
Pentru c se dorete realizarea unei aplicaii interactive, este necesar s fie precizat i ciclul de
via al unei activiti, ce descrie starea n care o activitate poate fi la un moment dat.
Urmtoarele puncte definesc strile n care activitatea se poate regsi:
Running - Activitatea a fost creat (onCreate()), pornit (onStart()) i este afiat pe
ecranul aparatului; n cazul n care activitatea a mai fost utilizat i aplicaia a salvat
starea acesteia (onSaveInstanceState()), activitatea este reluat din acel punct
(onRestoreInstanceState() i onResume()); n aceast stare utilizatorul interacioneaz
cu activitatea prin intermediul interfeei dispozitivului (tastatur, touchscreen,
display);
Paused - Activitatea pierde prim-planul (onPause()), deoarece o alt activitate este
executat, cum ar fi o fereastr de dialog; de asemenea, n cazul n care aparatul intr
n modul sleep, activitatea este oprit temporar; activitatea i poate relua execuia
(onResume()) i este plasat napoi n prim-plan;
17


Stopped Activitatea nu este mai n uz i pentru c este oprit (onStop()) nu este
vizibil; pentru a fi reactivat (ea deja exist), activitatea trebuie s fi repornit
(onRestart() i onStart()) i reluat (onResume());
Destroyed Activitatea este distrus (onDestroy()) i memoria s eliberat, deoarece
nu mai este necesar sau sistemul are nevoie de memorie suplimentar pentru rutinele
proprii sau pentru alte activiti; deoarece managementul memoriei este un aspect
important pentru sistemul de operare al dispozitivului mobil, procesul care gzduiete
o activitate ntrerupt, oprit sau distrus, poate fi terminat pentru a elibera memorie
pentru noi activiti; doar procesele ce gestioneaz activiti ce ruleaz sunt protejate;
Android este o platform software i un sistem de operare pentru dispozitive i telefoane
mobile bazat pe nucleul Linux, dezvoltat iniial de compania Google, iar mai trziu de
consoriul comercial Open Handset Alliance. Android permite dezvoltatorilor s scrie cod
gestionat n limbajul Java, controlnd dispozitivul prin intermediul bibliotecilor Java
dezvoltate de Google. Aplicaiile scrise n C i n alte limbaje pot fi compilate n cod main
ARM i executate, dar acest model de dezvoltare nu este sprijinit oficial de ctre Google.
Lansarea platformei Android la 5 noiembrie 2007 a fost anunat prin fondarea Open Handset
Alliance, un consoriu de 48 de companii de hardware, software i de telecomunicaii,
consacrat dezvoltrii de standarde deschise pentru dispozitive mobile. Google a lansat cea mai
mare parte a codului Android sub licen Apache, o licen de tip free-software i open
source.
Pentru c se dorete crearea i modificarea ulterioar de aplicaii, pentru sistemul Android,
aplicaia va putea fi modificat pentru portarea acesteia pe versiuni mai noi ale sistemului de
operare sau pentru accesul de pe dispozitive mobile cu sistem de operare diferit.


Analiza i proiectarea formatelor de intrare-iesire

Intrrile necesare sistemului vor fi cele cu privire la detaliile pacientului i anume simptomele
pe care acesta le prezint.Utilizatorul va trebui s completeze unele informaii generale,
pentru a putea afla ce afeciune prezint.
Simptome n cazul n care pacientul resimte mai multe stri ce pot conduce la diverse
diagnostice, ele trebuie menionate n totalitate, deoarece vor ajuta la o mai bun interogare a
bazei de date i la returnarea unui diagnostic prezumptiv ct mai aproape de cel pus de un
medic ntr-un cabinet specializat.
18


Pe baza acestor informaii, sistemul va putea returna sugestii cu privire la un posibil
diagnostic i eventual unul sau mai muli medici ce pot oferi asisten pentru condiia
pacientului( n cazul n care pacientul se afla la distan egal dintre dou localiti, sistemul
va returna doi medici pentru a da posibilitatea pacientului s aleag variant care i este mai
util).
Acestea din urm reprezint datele de ieire, prezentate n format electronic, cu care
utilizatorul/pacientul se poate prezenta la medicul recomandat, iar acesta i poate pune
diagnosticul final mult mai repede, cu ajutorul datelor prezente n raportul sau formularul
electronic.
Diagnosticul - dac pe baza simptomelor date vor rezultate mai multe posibile diagnostice,
acestea vor fi afiate n format list iar utilizatorul va putea accesa detaliile fiecruia, aa cum
sunt stocate n structura de date.
Vor fi afiate:
Specializarea de care aparine respectivul simptom
Lista complet a simptomelor ce stau la baza diagnosticului
Lista tuturor medicilor ce pot s ofere asisten( utilizatorul va putea accesa detaliile
fiecrui medic)
Acest formular va putea fi printat coninnd detaliile diagnosticului ct i cele ale medicului
ales.
Formatele de intrare se vor constitui n ferestre individualizate de preluare a datelor i vor
conine cmpuri dedicate. Pentru a asigura concretizarea ct mai ampl a cerinelor
sistemului proiectat, la proiectarea formatelor de ieire trebuie s se in cont att de
principiile, cerinele legislative, informaionale i de proiectare, ct i de posibilitile i
restriciile tehnice.Formatele de ieire trebuie s fie prezentate ntr-o form simpl, inteligibila
care s asigure i facilitatea n utilizare.



Analiza i proiectarea codurilor
n ceea ce privete clasele necesare elaborrii codului, acestea sunt urmtoarele:
clasa Medic
clasa Pacient
clasa Diagnostic
clasa Simptom
19


n cadrul aplicaiei, metodele de validare ale datelor folosite vor fi multiple, att la nivelul
bazei de date ct i la nivel de cod surs.La nivel de baza de date, regulile vor fi destul de
stricte i vor fi impuse fie de tipul de data dat unui anumit cmp/coloan, i.e. un cmp de tip
integer nu va accepta dect date de tip numeric i atta timp ct valoare dat se ncadreaz n
intervalul de valori suportate de tipul respectiv.De asemenea, regulile de validare vor fi
impuse i prin limitarea unui cmp de tip String/Varchar, de exemplu, la un anumit numr de
caractere. Astfel, sistemul de gestiune al bazei de date nu va accepta valori ce nu sunt
conforme cu tipul i lungimea/dimensiunea dat sau implicit.
n ceea ce privete validarea la nivelul aplicaiei, diferite motode vor fi folosite, ncepnd cu
cea mai des ntlnit i anume verificarea/filtrarea caracterelor. n cazul unor cmpuri
destinate datelor de intrare, i.e. forma de adugare a unui medic, n funcie de tipul de data
folosit, unele caractere vor fi permise, altele nu. O alt regul importanta implementat n
aplicaie este verificarea cardinalitatii. Va fi folosit atunci cnd o entitate de tip medic se va
aduga iar regul impus va fi ca acesta s aib cel puin o specializare. De asemenea, aceasta
verificare va fi fcut n cazul diagnosticului, entitate ce v trebuie s aib cel puin un
simptom.Verificri de existen/consisten vor fi fcute n cazul cmpurilor ce necesit o
valoare, lucru care la rndul su determina dac entitatea curent poate fi salvat sau nu.
Cazul de fa este o consecin a faptului c n baza de date, pentru entitatea curent, cmpul
validat a fost declarat non-nul.Dei sistemul de gestiune al bazei de dat va face o verificare a
tipului de dat atunci cnd se vor ncerca modificri asupra entitii curente (insert/update), la
nivelul aplicaiei se vor face, de asemenea, astfel de verificri. Utilitatea acestei operaii este
de a evita erorile generate de sistemul de gestiune al bazei de date i pentru a-i asigura
utilizatorului un sistem stabil.n cazul aspectului de adugare/editare a unui medic, va exista
opiunea de a putea ataa o poz cu caracter informativ. Cu aceast ocazie, cteva tipuri de
verificri vor fi fcute. n prima faz se va verifica exist fiierului ce urmeaz s fie importat.
Urmtorul pas va fi de a i se verifica dimensiunea (in pixeli ) ct i spaiul ocupat pe disk (n
kilo octei). Ultima verificare va fi fcut pentru a deduce tipul imaginii pentru a se asigura c
fiierul n cauz este ntradevr o imagine i n cazuri speciale, pentru a exclude anumite
formate de imagine.

Interfaa grafic

Dat fiind natura i rolul interfeei grafice i anume aceea de mediu de comunicare ntre
utilizator i sistemul informatic, aceasta joac un rol extrem de important n procesul de
utilizare i administrare i poate duce la eficientizarea activitii.
Astfel c n cazul de fa trebuie luai n considerare mai muli factori, cum ar fi:

complexitatea aplicaiei
o numrul de module i submodule
o datele afiate , volumul i importana acestora
20


durata medie pe care un utilizator o petrece n cadrul aplicaiei
diferenierea clar a datelor prin folosirea inteligent a culorilor i tipurilor de
afiare
diferenierea clar a informaiilor importante de cele neimportante sau informative
gradul de cunoatere a utilizatorului n ceea ce privete folosirea unui terminal ce
ruleaz sistemul de operare Android n general
claritatea i diferenierea structurilor i diverselor activiti

Factorii care au condus la forma actual a interfeei au fost analizai n concordan cu scopul
aplicaiei. Astfel s-au evaluat diveri indicatori cum ar fi durata medie a timpului petrecut de
ctre un utilizator / administrator, conectivitatea link-urilor, uurina n nelegerea structurii,
uurina n utilizare, paleta de culori etc.Principalul obiectiv a fost acela de a proiecta interfaa
disponibil utilizatorului n aa fel nct utilizatorul s aib partea de o experien ct mai
plcut i o navigare ct mai eficient.
ncepnd cu primul pas i anume autentificarea n aplicaie pn la momentul terminrii
procesului de diagnosticare, s-au luat n vedere aspecte ca:
- alegerea controalelor potrivite
- poziionarea ct mai potrivit n ecran, innd cont de faptul c aplicaia poate fi rulat
de dispozitive de dimensiuni mici (telefoane mobile/smartphone-uri) pn la
dispozitive de dimensiuni considerabile (tablete sau chiar smartbook-uri).
- navigarea s se fac n condiii optime utiliznd funciile ncorporate n dispozitivele
Android, cum ar fi: ntoarcerea la ecranul precedent, ascunderea aplicaiei i revenirea
la aceasta sau folosirea gesturilor de atingere (touch gestures).

Acelai nivel de atenie a fost acordat prii de administrare a coninutului sistemului
informatic.
S-a optat pentru un ecran principal ce va avea n componena lui toate legturile ctre
funcionalitile aplicaiei. Acesta va avea un comportament dinamic, ce va permite
reconfigurarea sa n funcie de nivelul de acces al utilizatorului curent. Acest lucru impune
faptul c atunci cnd un utilizator cu drepturi de administrator se va conecta, ecranul
principal va afia toate legturile ctre funcionalitile aplicaiei. De asemenea, n cazul opus,
legturile ctre modulele de administrare vor fi ascunse, lsnd loc celor de baz.
n fig.4 este prezentat schema fluxului informaional prezent n cadrul sistemului de
diagnosticare la distan.Aa cum se poate vedea, aceasta conine dou interfee distincte,
fiecare cu rol n administrarea/utilizarea aplicaiei.
21



Fig.4 Schema fluxului informaional aferent temei

Interfaa comun utilizator-administrator

Autentificare
Pentru a se autentifica, utilizatorul va avea la dispoziie dou metode. Prima dintre acestea
este aceea de a se autentifica automat fr a fi nevoie de un utilizator n baza de date, acesta
folosind unul anonim cu drepturi minime pentru a putea accesa i folosi funcia de
diagnosticare. A doua metod implica folosirea unui utilizator salvat deja n baza de date.
n fig.5 este prezentat o captur de ecran (aferent autentificrii) din cadrul sistemului de
diagnosticare.
22



Fig.5 Autentificare

1. Ecranul principal
Imediat dup ce utilizatorul se va loga (sau va alege varianta anonim), ecranul principal va fi
afiat. n funcie de rolul utilizatorului curent, aplicaia va activa sau dezactiva unele funcii.
Exist dou tipuri de roluri: administrator i user.
Primul (a) va permite utilizatorului s aib acces la toate funciile aplicaiei cum ar fi afiarea
tuturor user-ilor din aplicaie, afiarea diagnosticelor i a simptomelor etc.
Cel de-al doilea (b) va oferi doar funcii de baz cum ar fi diagnosticarea, afiarea detaliior
user-ului curent i afiarea listei de medici.
n fig. 6-7 sunt prezentate cele dou tipuri de roluri, n partea stnga este prezentat
autentificarea printr-un id, iar n partea dreapt este prezentat autentificarea anonim.

23



Fig.6-7 Ecran principal

Interfaa utilizator

Reprezint interfaa destinat utilizatorului final, acesta putnd efectua doar operaiile de baz
ale sistemului informatic precum i administrarea propriului. Totul ncepe de la autentificare.
Apoi n ecranul principal va putea alege din urmtoarele:
1. Diagnosticare (Diagnose me)
2. Detaliile mele (My Details)
3. Medici (Medics)

1. Diagnosticare Diagnose Me
n fig. 8-9 sunt prezentate etapele diagnosticrii prin alegerea elementelor dintr-o list
de simptome.
24



Fig.8-9 Diagnosticare prin list
Imediat dup ce butonul Diagnose Me va fi apsat, utilizatorul va fi redirectat pe un alt
ecran unde i se vor prezenta dou opiuni pentru putea duce la bun sfrit diagnosticarea.
a) Diagnosticare prin alegerea simptomelor dintr-o list
Imediat ce butonul etichetat drept Pick the symptoms from a list va fi apsat, utilizatorului i
se vor prezenta sub forma unei liste toate simptomele salvate n acel moment n baza de date.
n acel moment, acesta poate selecta un sau mai multe simptome, ce pot avea sau nu legtur
ntre ele. Dac utilizatorul va selecta simptome ce nu sunt parte a unui singur diagnostic,
atunci toate diagnosticele posibile vor fi afiate n pasul urmtor. Fiind un ecran unde nu se
vor introduce date de la tastatur, nu se vor face validri cu privire la simptome, acestea
fcndu-se la momentul introducerii n baza de date, folosind ecranul simptome (Symptoms).
Atunci cnd utilizatorul va avea cel puin un simptom selectat, va putea continua procesul.
b) Diagnosticare pe baza simptomelor date de la tastatur
n fig.10-11 este prezentat modalitatea n care utilizatorul poate alege s tasteze
simptomele pe care le prezint(aceast opiune este folosit n cazul n care simptomele
prezentate nu se regsesc n lista dat de aplicaie).
25



Fig. 10-11 Diagnosticare pe baza simptomelor date de la tastatura

Imediat ce butonul etichetat drept Type the symptoms va fi apsat, aplicaia va comut spre
un alt ecran. Cea de-a doua metod presupune c utilizatorul s introduc de la tastatur datele
pe baza crora se va rula procesul de diagnosticare.
Acesta va putea astfel s introduc una sau mai multe simptome, cu condiia ca acestea s
conin caractere alfanumerice desprite prin virgul.
n acest sens se vor face validri astfel c regulile menionate mai sus s fie respectate iar
procesul de diagnosticare s poate fi executat cu succes.Atunci cnd utilizatorul va avea cel
puin un simptom introdus, va putea continua procesul.
n fig. 12-13 este prezentat modalitatea de afiare a diagnosticelor i a medicilor, dup
selectarea simptomelor i activarea opiunii de diagnosticare.

26




Fig.12-13 Prezentarea diagnosticelor i a medicilor

Odat ce utilizatorul a ales sau a introdus cel puin un simptom, aplicaia va interoga baza de
date i va afia o list cu posibile diagnostice i o list cu medicii ce au competente n
domeniul respectiv.
a) Detaliile Mele My Details
Imediat ce butonul etichetat drept My Details va fi apsat, aplicaia va comuta spre un alt
ecran ce va afia, n prima faz, utilizatorul curent n format list. Aciunile posibile n aceast
faz sunt fie aceea de a efectua funcia de apsare pe numele utilizatorului sau aceea de
ntoarcere la ecranul precedent, folosind funcia de ntoarcere, implementat implicit pe toate
dispozitivele cu android.
Prima aciune ns, va permite vizionarea i eventual editarea detaliilor utilizatorului curent.
Pot fi actualizate cmpuri ca: nume, prenume, email sau parola.Validri de existena vor fi
aplicate pentru primele trei cmpuri, ntruct au fost declarate nenule n baza de date. De
asemenea, cmpului email i se va mai aplica o validare pentru a decide dac formatul
textului introdus corespunde cu tipul valorii (tip de data email).Orice modificare poate fi
salvat n baza de date apsnd pe butonul etichetat save.
n fig.14-15 sunt prezentate capturile de ecran aferente opiunii de afiare a detaliilor
pacientului (aceast form este util doar n cazul n care utilizatorul este autentificat printr-un
27


id ,n cazul n care se folosete varianta de utilizare anonim a aplicaiei, aceast opiune nu
exist).


Fig.14-15 Detalii pacient


3.Medici
Imediat ce butonul etichetat drept Medics va fi apsat, aplicaia va comuta spre un alt ecran
ce va afia, n format list, toi medici ce au fost introdui n baza de date.
n acest moment, utilizatorul va putea interoga baza de date, apsnd pe medicul dorit, pentru
a viziona detaliile acestuia. Modificarea i salvarea datelor nu vor fi permise.
Vor fi afiate informaii cum ar fi: nume, locaie, adresa de email, seal i toate specializrile
deinute de acesta.
n fig.16-17 sunt prezentate detaliat informaiile referitoare la medicii pe care aplicaia i are
n baza de date.

28



Fig.16-17 Detalii medici


Interfaa administrator

Desigur, un administrator va avea de asemenea acces la funcia de baz a sistemul informatic
i anume diagnosticarea, scopul fiind acela de a se asigura ca prezenta funcionalitate ruleaz
n parametrii normali, fr a crea probleme utilizatorilor.
Totodat, acesta va avea parte de o funcionalitate extins, avnd acces la ecranele de
vizionare/editare/adugare pentru pacieni, medici, simptome, specializri i diagnostice.n
cele ce urmeaz vor fi prezentate toate ecranele menionate mai sus.
1. Pacieni
Imediat ce butonul etichetat drept Patients va fi apsat, aplicaia va comut spre un alt ecran
ce va afia toi utilizatorii introdui n baza de date, n format list. Aciunile posibile n
aceast faz sunt multiple.
n funcie de durata de apsare, aciunile pot fi urmtoarele:
29


- O simpl apsare va comuta ctre alt ecran unde se vor afia detaliile pacientului
respectiv. Pot fi vizionate i actualizate cmpuri c: nume, prenume, email, rolul,parola
sau dac este activ sau inactiv. Totodat, detaliile pacientului pot fi actualizate i apoi
salvate prin apsarea butonului save.
- O apsare lung, ce va face vizibil meniul contextual. Acesta este compus din dou
funcii:
o Delete patient
n prima faz va afia un mesaj de confirmare(yes/no) iar dac butonul
yes va fi apsat, pacientul respectiv va fi ters din baza de date.
o Add patient
Acesta funcie va comuta ctre ecranul de detalii ale pacientului, de data
aceasta administratorul avnd posibilitatea de a crea un nou pacient,
introducnd valori pentru toate cmpurile iar apoi apsnd butonul
save.
O alt opiune este cea de ntoarcere la ecranul precedent, folosind funcia de ntoarcere,
implementata implicit pe toate dispozitivele Android.
Validri de existen vor fi aplicate pentru primele trei cmpuri, ntruct au fost declarate non
nule n baza de date. De asemenea, cmpului email i se va mai aplica o validare pentru a
decide dac formatul textului introdus corespunde cu tipul valorii (tip de data email).Orice
modificare poate fi salvat n baza de date apsnd pe butonul etichetat save.

30



Fig.18 Inregistrare pacient
n fig.18 este prezentat modul n care se creaz un nou utilizator.

1. Medici
Imediat ce butonul etichetat drept Medics va fi apsat, aplicaia va comuta spre un alt
ecran ce va afia, n format list, toi medici ce au fost introdui n baza de date. Aciunile
posibile n aceast faz sunt multiple.
n funcie de durat de apsare, aciunile pot fi urmtoarele:
- O simpl apsare va comut ctre alt ecran unde se vor afia detaliile medicului
respectiv. Pot fi vizionate i actualizate cmpuri c: nume, locaie, email, seal i toate
specializrile sale. Totodat, detaliile medicului pot fi actualizate i apoi salvate prin
apsarea butonului save.
- O apsare lung, ce va face vizibil meniul contextual. Acesta este compus din dou
funcii:
o Delete medic
n prima faz va afi un mesaj de confirmare(yes/no) iar dac butonul
yes va fi apsat, medicul respectiv va fi ters din baza de date.
o Add medic
31


Acesta funcie va comuta ctre ecranul de detalii ale medicului, de data
aceasta ns administratorul avnd posibilitatea de a crea un nou medic,
introducnd valori pentru toate cmpurile iar apoi apsnd butonul
save.
Este prezent opiunea de ntoarcere la ecranul precedent, folosind funcia de ntoarcere,
implementat implicit pe toate dispozitivele Android.
Vor fi afiate informaii cum ar fi: nume, locaie, adresa de email i toate specializrile
deinute de acesta. De asemenea noi specializri vor putea fi adugate sau cele existente pot fi
terse din baza de date.
Validarea de existena va fi aplicat pentru cmpul nume ntruct acesta nu trebuie s fie nul.
De asemenea, cmpului email i se va aplica o validare pentru a decide dac formatul textului
introdus corespunde cu tipul valorii (tip de data email).


3.Specializri

Imediat ce butonul etichetat drept Specializations va fi apsat, aplicaia va comut spre un
alt ecran ce va afia, n format list, toate specializrile ce au fost introduse n baza de
date.Aciunile posibile n aceast faz sunt multiple.
n funcie de durat de apsare, aciunile pot fi urmtoarele:
- O simpl apsare va comuta ctre alt ecran unde se vor afia detaliile specializrii
respective. Poate fi vizionat cmpul descriere. Totodat, detaliile specializrii pot fi
actualizate i apoi salvate prin apsarea butonului save.
- O apsare lung, ce va face vizibil meniul contextual. Acesta este compus din dou
funcii:
o Add specialization
Acesta funcie va comuta ctre ecranul de detalii ale specializrii, de
data aceasta ns administratorul avnd posibilitatea de a crea o nou
specializare, introducnd valori pentru toate cmpurile iar apoi apsnd
butonul save. Validarea de existen va fi aplicat pentru cmpul
descriere ntruct acesta nu trebuie s fie nul.

32



Fig.19-20 Specializri medici

n fig.19-20 sunt prezentate capturile de ecran aferente prezentrii specializrilor medicilor.

4.Diagnostice

Imediat ce butonul etichetat drept Conditions va fi apsat, aplicaia va comuta spre un alt
ecran ce va afia, n format list, toate diagnosticele ce au fost introduse n baza de
date.Aciunile posibile n aceast faz sunt multiple.
n fig.21 este prezentat modalitatea de afiare a informaiilor, n urma diagnosticrii.n prima
parte sunt prezentate posibilele diagnostice, iar n a doua parte sunt recomandrile n ceea ce
privete medicii la care ar trebui s se adreseze utilizatorul, n funcie de specializarea de care
aparin respectivele diagnostice.
33



Fig.21 Rezultat diagnosticare

n funcie de durata de apsare, aciunile pot fi urmtoarele:
- O simpl apsare va comuta ctre alt ecran unde se vor afia detaliile diagnosticului
respectiv. Pot fi vizionate i actualizate cmpuri ca: nume i descriere. Desigur, pentru
fiecare diagnostic se vor afia toate simptomele ce fac obiectul lor, iar administratorul
va putea edita aceast list. Totodat, detaliile diagnosticului pot fi actualizate i apoi
salvate prin apsarea butonului save.
- O apsare lung, ce va face vizibil meniul contextual. Acesta este compus din dou
funcii:
o Delete condition
n prima faz va afia un mesaj de confirmare(yes/no), iar dac butonul
yes va fi apsat, diagnosticul respectiv va fi ters din baza de date.
o Add condition
Acesta funcie va comuta ctre ecranul de detalii ale diagnosticului, de
data asta aceasta administratorul avnd posibilitatea de a crea un nou
diagnostic, introducnd valori pentru toate cmpurile iar apoi apsnd
butonul save. Validarea de existen va fi aplicat pentru cmpul
nume ntruct acesta nu trebuie s fie nul.
34




Fig.22-23 Condiii

n fig.22-23 sunt prezentate condiiile i detaliile acestora, pe baza crora interogarea bazei de
date va returna un rezultat sau altul.Utilizatorul trebuie s aleag cu grij aceste condiii
pentru a evita cazul n care i se va returna un rezultat eronat.

5.Simptome
Imediat ce butonul etichetat drept Symptoms va fi apsat, aplicaia va comuta spre un alt
ecran ce va afia, n format list, toate simptomele ce au fost introduse n baza de date.
Aciunile posibile n aceast faz sunt multiple. n funcie de durat de apsare, aciunile pot fi
urmtoarele:
- O simpl apsare va comuta ctre alt ecran unde se vor afia detaliile simptomului
respectiv. Pot fi vizionate i actualizate cmpuri ca: descriere i tip. Totodat, detaliile
simptomului pot fi actualizate i apoi salvate prin apsarea butonului save.
- O apsare lung, ce va face vizibil meniul contextual. Acesta este compus din dou
funcii:
o Delete symptom
35


n prima faz va afi un mesaj de confirmare(yes/no), iar dac butonul
yes va fi apsat, simptomul respectiv va fi ters din baza de date.
o Add symptom
Acesta funcie va comut ctre ecranul de detalii ale simptomului, de
data asta aceasta administratorul avnd posibilitatea de a crea un nou
simptom, introducnd valori pentru toate cmpurile iar apoi apsnd
butonul save.
De aici, utilizatorul poate opta pentru funcia de ntoarcere la ecranul principal, n cazul n
care se dorete ieirea din meniul curent.Validarea de existen va fi aplicat pentru cmpul
descriere ntruct acesta nu trebuie s fie nul.


Fig.24-25 Simptome

n fig.24-25 sunt prezentate simptomele i detaliile acestora, pe care pacientul le poate
vizualiza i aduga de la tastatur.
Definirea activitilor de ntreinere a funcionalitilor proiectului

36


Activitile de ntreinere a funcionalitilor se refer mai mult la actualizrile n baza de
date.Acest pas este realizat de utilizator, dar poate fi n sarcina unui administrator specializat,
n cazul n care utilizatorul a ncercat s fac diferite modificri i acestea au generat erori n
baza de date.
Suportul i validarea sistemului respectiv sunt realizate de ctre programator pentru
utilizatorul final i constau n:
Asistenta i teste de validare a sistemului,
Validarea sistemului conform cerinelor date n specificaii,
Rezultatele testrilor vor fi salvate n documente specifice,
Dac apare vreun defect pe parcursul funcionrii, problema va fi rezolvat
conform proceselor de remediere a defectelor


Caracter inovativ

n agenda Ministerului Sntii se afl propunerea dezvoltrii unui sistem de diagnosticare la
distan ,care ar trebui s fie realizat pn la sfritul anului 2015, soluia va fi implementat
att n mediul privat,ct i n mediul public.
Soluia realizat are un caracter inovativ, deoarece implementeaz un sistem pentru
informarea pacienilor, dar i a medicilor, n cazul n care utilizatorul se prezint cu
informaia rezultat, la medic .Acest sistem furnizeaz informaii medicale ntr-un timp mult
mai scurt, facilitnd astfel preluarea informaiilor din mediul electronic i schimbarea viziunii
utilizatorilor n legtur cu modernizarea sistemului medical .

4. Concluzii, rezultate, propuneri
Relevana n raport cu cheltuielile anterioare i realitatea economic

n ceea ce privete elementele hardware, aplicaia poate fi implementat pe orice orice
dispozitiv mobil ce are sistemul de operare Android, economisind astfel fondurile ce pot fi
utilizate pentru dezvoltarea soluiei software.Dac pn acum 20 de ani, acest gen de apliicatii
erau de nenchipuit, implicnd foarte multe costuri pentru cercetare , n acest moment situaia
se prezint altfel, pentru c dezvoltarea numeroaselor soluii hardware i software a condus la
reducerea costurilor i la descoperirea unor soluii inovative.
37



Realismul i fezabilitatea soluiei propuse

Soluia propus reprezint un element de actualitate i se bazeaz pe realizarea unei legturi
ntre medici i pacieni prin intermediul aplicaiei.n statele mult mai dezvoltate
implementarea de aplicaii de acest gen fost deja realizat, chiar dac, respectivele aplicaii
nu ofer o gam foarte larg de informaii.Din acest motiv soluia propus este fezabil,
bazndu-se pe cercetrile anterioare i aducnd elemente noi n ceea ce privete modul de
utilizare, cantitatea de informaii tipurile de utilizatori i modalitatea de prezentare a
informaiilor.


Aspecte critice legate de punerea n practic

Un aspect critic legat de punerea n practic este modul n care sistemul public va putea
suporta costurile implementrii soluiilor de acest gen.Sistemul de diagnosticare ar reprezenta
o modalitate rapid de informare, dar trebuie s lum n considerare i categoriile de
utilizatori care vor fi dispui s aloce timp n scopul informrii .O prim problem ce ar putea
fi ntmpinat este reprezentat de refuzul pacienilor slab pregtii din punct de vedere
profesional, de a utiliza sistemul.n categoria pacienilor ce nu vor putea folosi aceste
dispozitive intr i persoanele cu deficiene de vedere, pentru care nu au fost nc
implementate soluii specifice.

Recomandri pentru cercetrile ulterioare

Cercetrile ulterioare ar putea fi centrate pe implementarea de noi funcionaliti, cum ar fi un
segment care s ofere n cazurile bolilor mai uoare, medicaia corespunztoare.Un alt
element ar putea fi facilitarea accesului diferitelor categorii de persoane la informaiile
medicale.Un prim pas ar fi reprezentat de introducerea unei funcii robot pentru emiterea
informaiilor, n scopul ajutorrii persoanelor cu deficiene de vedere, fcnd astfel legtura
dintre pacienii cu afeciuni uoare i cei cu afeciuni grave i cu nevoi speciale.


38


5. Bibliografie

1. Roca Ion Gh.,Ghilic-Micu Bogdan, Golosoiu-Georgescu Ligia, Nstase Floarea, Stoica
Marian, Zamfir Gabriel: Informatic : Societatea informaional. E-serviciile, Bucureti,
Editura Economic, 2006.
2. Paul Pocatilu: Programarea dispozitivelor mobile, Bucureti, Editura ASE , 2012.
3. Williams P, Nicholas D, Huntington P, Gunter B: Doc.com: reviewing the literature on
remote health information provision. Aslib Proc 2002, 54:127-141.
4. Plebani M, Lippi G. To err is human. To misdiagnose might be deadly. Clin Biochem
2010;43:13.
5. Plebani M, Lippi G. Improving the post-analytical phase. Clin Chem Lab Med
2010;48:4356.
6. Lippi G, Fostini R, Guidi GC. Quality improvement in laboratory medicine: extraanalytical
issues. Clin Lab Med 2008;28:28594.
7. Murray E, Lo B, Pollack L, Donelan K, Catania J, White M, Zapert K, Turner R: The
impact of heath information on the Internet on the physician-patient relationship. Arch Intern
Med 2003,163:1727-1734.
8. Murray E, Lo B, Pollack L, Donelan K, Catania J, Lee K, Zapert K,Turner R: The impact
of heath information on the Internet on health care and the physician-patient relationship:
National US survey among 1.050 U. S. physicians. J Med Internet Res2003, 5:e17
[http://www.jmir.org/2003/3/e17].
9. NLM 2004, Medline Thesaurus, updated 16 Aug, U.S. National Library of Medicine
(NLM), viewed 30 June 2003,
<http://www.nlm.nih.gov/mesh/MBrowser.html>.
10. Cochrane Collaboration, viewed 25 Oct 2004,
<http://www.cochrane.org/>.
11. Burdette SD, Herchline TE, Oehler R. Practicing medicine in a technological age:using
smartphones in clinical practice. Clin Infect Dis 2008;47:11722.
39



12. Health Services/Technology Assessment Text (HSTAT), updated 13 Dec 2004, National
Library of Medicine, viewed 23 Dec 2004,
<http://www.ncbi.nlm.nih.gov/books/bv.fcgi?rid=hstat>.
13. A. O'Rourke 1998, Seminar 3: An Introduction to Evidence-Based Practice,updated 10
Apr 1998, viewed 11 Oct 2004,
<http://www.shef.ac.uk/uni/projects/wrp/sem3.html>.

14. M. N. K. Boulos, S. Wheeler, C. Tavares, and R. Jones, "How smartphones are changing
the face of mobile and participatory healthcare: an overview, with example from eCAALYX,"
Biomedical engineering online, vol. 10, p. 24, 2011.
15. M. Satyanarayanan, "Fundamental challenges in mobile computing," 1996, pp. 1-7.
16. Department of Health: Patient and public involvement in the new NHS,London 1999.
17. Department of Health: Supporting people with long term conditions. London 2005.
18. Nettleton S, Burrows R, O'Malley L: The mundane realities of the everyday lay use of the
Internet for health, and their consequences for media convergence. Sociol Health & Illn
2005,27:972-992.
19. ClinicalTrials.gov, updated 06 Aug 2004, National Library of Medicine, viewed 23 Dec
2004,
<http://clinicaltrials.gov/ct/gui>.
20. Barry Burd:Beginning Programming with Java, 2nd Edition, Published by Wiley
Publishing, Inc.
21.http://www.itcsolutions.eu/2011/08/31/tutorial-android-1-instrumente-necesare-si-
configurare-mediu-de-lucru/
22. http://developer.android.com/develop/index.html
40




6. Anexe

Exemplu de diagnosticare:
Pasul 1:
La pasul 1,se alege optiunea corespunzatoare,in functie de rezultatul dorit de utilizator.


Pasul 2:
Pornind de la ideea de diagnosticare, se va alege una din optiunile prezentate mai jos:
41




Pasul 3:
S-a ales diagnosticarea pe baza listei de simptome, dupa selectarea variantelor
corespunzatoare, utilizatorului i se va prezenta un diagnostic.


42


Pasul 4:
La ultimul pas se vor afisa diagnosticul/diagnosticele si recomandarile aplicatiei in ceea ce
priveste medicii la care ar trebui sa se adreseze utilizatorul.