Cuprins Introducere........................................................ 2 1.1.Importanţa temei............................................. 2 1.2. Motivaţia temei............................................. 2 1.3. Scopul...................................................... 2 1.4. Rezultatele preconizate.....................................4 2. Cadrul teoretic şi cercetările anterioare.......................4 2.1.1. La nivel naţional........................................4 2.1.2. La nivel internaţional...................................4 2.1.3. Actualitatea şi relevanţa................................5 2.2. Relaţionarea cu rezultatele cercetărilor anterioare.........7 2.3. Aspecte deficitare din literatură de specialitate...........8 3. Soluţia 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 Interfaţa grafică............................................... 19 Interfaţa comună utilizator-administrator.......................21 Interfaţa utilizator............................................ 23 Definirea activităţilor de întreţinere a funcţionalităţilor proiectului..................................................... 35 Caracter inovativ............................................... 36 4. Concluzii, rezultate, propuneri................................36 Relevanţa în raport cu cheltuielile anterioare şi realitatea economică....................................................... 36 Realismul şi fezabilitatea soluţiei propuse.....................37 1
De la momentul naşterii până la momentul decesului fiecărei persoane îi este atribuit un număr unic de înregistrare.Acesta face parte dintr-o bază de date cu o multitudine de înregistrări.În ultimii 20 de ani s-a încercat colectarea informaţiilor într-un singur loc pentru a facilita accesul medicilor şi a pacienţilor în vederea eficientizării serviciilor medicale. Pentru a pune în legătură simptomatologia medicală, cu informaţiile actuale s-a dorit realizarea unui sistem de diagnosticare la distanţă. Acestă ar facilita accesul pacienţilor la informaţiile medicale şi încadrarea lor într-un program de conştientizare asupra riscurilor şi afecţiunilor.Totodată implementarea soluţiei ar ajuta medicii la identificarea şi eliminarea neconcordanţelor ş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 medicaţia corespunzătoare în cazuri mai uşoare sau returnează un diagnostic şi sugerează un medic competent în domeniul afecţiunii respective.
1.1.Importanţa temei
Tema aleasă doreşte să ofere o imagine aspupa beneficiilor pe care le-ar putea aduce achiziţionarea unui sistem de diagnosticare la distanţă pentru dispozitivele mobile, în acest fel medicii de familie, pacienţii şi familiile lor se pot consulta cu specialiştii noştri şi pot folosi această consultanţă pentru a lua deciziile optime în ceea ce priveşte tratamentul. Istoricul analizelor se păstrează în condiţii de siguranţă deplină, pe perioade nelimitate de timp.
1.2. Motivaţia temei
Prezenta lucrare îşi propune să faciliteze accesul pacienţilor la o bază de informare prin oferirea unei soluţii medicale la distanţă.Varianta propusă oferă posibilitatea informării cu un cost mult mai mic în comparaţie cu celelalte soluţii existente pe piaţă. Această aplicaţie 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 dorinţa sporită de cunoaştere a condus la necesitatea implementării acestei soluţii de diagnosticare la distanţă, prin care toţi utilizatorii pot să cunoască în cel mai scurt timp, cum se situează din punct de vedere al sănătăţii.
2
Această aplicaţie 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 medicaţia corespunzătoare, bazându-ne pe simptomele avute(indiferent dacă pacientul se află într-un loc în care nu poate beneficia imediat de asistenţă medicală).Ideea diagnosticării la distanţă a cunoscut numeroase etape, iar în prezent se doreşte crearea de aplicaţii care să furnizeze potenţialilor pacienţi, informaţii esenţiale despre starea lor de sănătate, precum şi tratamente sau medici care să vindece respectivele afecţiuni.
În prezent, majoritatea ţărilor din lume (în particular şi ţara noastră) sunt confruntate cu schimbări în domeniul sănătăţii. Pe de o parte, dezvoltarea noilor tehnologii generează sporirea sarcinilor de rezolvat de către medici. Pe de altă parte, noile moduri de a trăi şi de a munci conduc la îmbătrânirea populaţiei, iar şubrezirea sănătăţii este în creştere evidentă. În aceste condiţii ţările membre ale UE alocă anual pentru cheltuieli în domeniul sănătăţii peste de 6-7% din produsul intern brut, de exemplu Franţa şi Germania alocă chiar 10%.[3][7]
Cercetările privind aplicaţiile telematice în domeniul medical ar putea contribui semnificativ la rezolvarea problemelor generate de schimbările menţionate mai sus. UE alocă fonduri substanţiale pentru dezvoltarea aplicaţiilor telematice de care să beneficieze toţi cetăţenii. În prezent, Europa este lider mondial în ceea ce priveşte aplicaţiile medicale, bazate pe agende rapide sau pe reţele telematice regionale destinate îngrijirii sănătăţii.
Fig.1 Model de sistem de diagnosticare la distanţă
În fig.1 este prezentat un model de sistem de diagnosticare la distanţă realizat de specialiştii din Franţa, pentru eficientizarea procesului final de diagnosticare.Unele dintre proiectele realizate/ în curs de realizare sunt centrate pe contribuţia aplicaţiilor telematice în lupta împotriva principalelor boli (boli cardiace, cancer etc.) din ţările dezvoltate.
3
1.4. Rezultatele preconizate
Implementarea soluţiei ar eficientiza procesul de informare în domeniul medical, utilizând mai puţine resurse financiare, într-un timp mult mai scurt şi pentru un număr mult mai mare de pacienţi.Crearea unui mediu de informare rapid, simplu de folosit şi în acelaşi timp la un preţ rezonabil pentru beneficiar. Se doreşte schimbarea percepţiei pacienţilor prin familiarizarea acestora cu informaţia electronică şi crearea mentalităţii conform căreia utilizarea aplicaţiilor medicale la distanţă constituie un beneficiu pentru fiecare persoană. Soluţia propusă are ca scop reducerea timpului necesar pentru investigare şi informare cu privire la o anumită afecţiune,indiferent de locul în care se află şi prezentarea acestor informaţii într-o formă automatizată.
2. Cadrul teoretic şi cercetările anterioare
2.1.1. La nivel naţional
În mod paradoxal, România este printre ţările cele mai avansate în conectarea la distanţă pe sistemul de urgenţă, dispunând de sisteme de transmitere imagistică, tomografii computerizate, radiografii de la ambulanţe la spitale şi mai departe, la spitalele regionale pentru păreri avizate. Acest model intra-spitalicesc, de spitale interconectate poate fi completat cu medicina individualizată.
2.1.2. La nivel internaţional
Telemedicina se dezvoltă cu rapiditate ca o aplicaţie de medicină clinică în cadrul căreia informaţia este transferată prin telefon sau internet şi, uneori, prin alte reţele, cu scopul de a oferi consultanţă, diagnoză, tratament la distanţă sau chiar de a efectua examinări şi proceduri medicale.[1] De la sătenii din Africa care acum două secole aprindeau focuri pe coline şi semnalizau astfel străinilor să rămână în afara graniţelor aşezărilor lor pentru a nu se molipsi de diverse boli contagioase şi până la “The Royal Flying Doctor Service of Australia” ce folosea la începutul anilor 1900 emiţătoare radio activate de un dinam cu pedale pentru comunicarea medic-pacient, telemedicina a progresat şi oferă astăzi trei categorii principale de dezvoltare:
1. înmagazinare şi transmitere de date medicale (aşa-numitul “store and forward”, în care datele transmise sunt apoi analizate off-line şi nu necesită prezenţa şi participarea ambelor parţi în acelaşi timp);
2. monitorizare la distanţă în timp real, cunoscută şi ca auto-monitorizare (permite specialiştilor să monitorizeze pacienţii la distanţă folosind diverse aparate, în special pentru boli cronice);
4
3. telemedicina interactivă, care oferă interacţiune în timp real între specialist şi pacient, inclusiv consultaţii telefonice, comunicare online, urmate de tratament la domiciliu.[8][12]
Telemedicina reduce semnificativ numărul de spitalizări, reduce numărul de readmisii în spital după externare, micşorează listele de aşteptare pentru tratamente medicale, economisind astfel resurse importante atât pentru pacienţi (transport, analize, consultaţii), cât şi pentru prestator (medic, clinică, spital). Această tehnologie permite pacienţilor, dar mai cu seamă specialiştilor, să monitorizeze parametrii vitali, să ofere servicii de consultanţă şi tratament în timp real, fără să fie necesar ca pacientul să se deplaseze, reducând astfel anxietatea provocată de vizitele la clinici şi spitale.
Impactul telemedicinei asupra resurselor medicale (paturi de spital, vizite ale pacienţilor externi, facilităţi asistate, monitorizări ECG) este pe măsura 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 relevanţa
În contextul în care în 2010 au fost descărcate 5 miliarde de aplicaţii mobile la nivel mondial (iOS, Android, Windows etc.), iar conform previziunilor, în 2013, numărul 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 aşteptată a sistemelor informatice. Terminalele mobile (iPhone, Android, Windows Phone etc.) dispun de ecrane de dimensiuni mai mici decât cele ale computerelor/laptopurilor şi încorporeza noi funcţionalităţi care încurajează utilizarea acestora de către consumatori (camera foto, GPS, acceloremetru, ecran tactil etc.). Utilizatorii de internet mobil de astăzi comunică, folosesc, lucrează şi se joacă oriunde, oricând ş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ă, aplicaţiile smartphone vor reprezenta un element esenţial în conştientizarea beneficiilor serviciilor de îngrijire medicală prin intermediul telefoniei mobile, situându-le ca sector major în rândul asistenţei medicale. Datorită avalanşei de smartphone-uri pe piaţă şi a capacităţii de extindere a tehnologiei care permite atât medicilor, cât şi pacienţilor să beneficieze de servicii de asistenţă medicală de oriunde.
În primul rând, medicina de laborator se confruntă cu provocarea de creștere a productivității și a eficienței testării, impuse de progresele tehnologice dominante. În timp ce eforturi substanțiale au fost plasate pentru a reduce vulnerabilitatea și a crește calitatea procesului total de testare, există încă dovezi că erorile, incertitudinea și defectele sunt încă prezente în unele etape de diagnostic de laborator [4]. Cunoștințe vaste s-au adunat cu privire la problema de
5
siguranţă a pacienţilor, acestea atestă că marea majoritate a problemelor apar încă în fazele extra-analitice de testare. În timp ce activitățile manuale din etapa preanalitica sunt în mare parte responsabile pentru răspândirea la nivel global, o analiză cuprinzătoare a fazei postanalitice arată că cele mai multe probleme apar în cadrul raportului de laborator [5].Practic, un audit al performanțelor este crucial pentru a permite laboratoarelor să monitorizeze activitatea și asigure cele mai bune practici pentru pacienţi.Interpretarea "clinică" a rezultatelor testelor, este de asemenea, vitală pentru optimizarea procesului decizional de diagnosticare și îmbunătățirea calității de îngrijire [5][6]. Rapoartele, studiile și viața de zi cu zi sugerează că există încă un decalaj inacceptabil în înţelegerea rolului de comunicare a serviciilor de livrare de îngrijire a sănătăţii, inclusiv a datelor de laborator. Organizaţia Mondială a Sănătăţii a creat recent termenul de "mHealth," definit ca "o zonă de sănătate electronică" pentru "furnizarea de servicii de sănătate și de informații pe telefoanele mobile și PDA-uri. Deși o listă completă a tuturor aplicaţiilor este disponibilă în prezent, este lângă scopul acestui raport și ar putea fi inutilă, datorită extinderii neîncetat de aplicații și conținut, este încă demn de remarcat pentru a descrie potențialitatea unora dintre acestea. De asemenea, este ușor de înțeles că hardware-ul este doar o parte de joc, deoarece factorul cheie pentru viitor va fi bogăția de aplicații care sunt dezvoltate pentru aceste platforme.[14]
Tehnologia mobilă are un mare potențial de a revoluționa ştiinţa, medicina şi medicina de laborator, de asemenea, oferă acces permanent la cele mai noi informații medicale, precum urmărirea contiună și verificarea contracției modelelor și înregistrări istorice ar permite medicilor să fie mai eficienţi în activitățile lor de zi cu zi, în timp ce furnizează servicii medicale actualizate pacienţiilor [11]. Mai mult, medicii ar putea avea în curând 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ță, informații pe rezultatele de laborator, e-prescriere, etc) au fost oarecum lente, în ciuda creșterii cererii atât a personalului medical cât și a pacienţilor. Ca atare,"mHealth" ar putea fi o oportunitate pentru pacienți, mai degrabă decât un risc, cu condiția ca toate aplicaţii medicale şi de laborator supuse dezvoltării și formării procesului de revizuire în strânsă cooperare cu profesioniştii 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 entităţile participante.
6
Fig.2 Exemplu de arhitectură a unui sistem de diagnosticare(telefonie mobilă)
În consecinţă, firma de cercetare estimează că până în 2015, numărul 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, susţine că revoluţia mult-aşteptată de telefonie mobilă în domeniul sănătăţii este pe cale să se petreacă, atât ”furnizorii” de asistenţă medicală, cât şi consumatorii îmbrăţişează ideea de a folosi smartphone-urile ca mijloc de îmbunătăţire a asistenţei medicale.În prezent, există 17.000 de cereri mHealth (aplicaţii mobile de îngrijire a sănătăţii) în app store-uri. Aproape jumătate (43%) din aplicaţiile de sănătate 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 plăteşti pentru a descărca.[9][13]
Potrivit raportului, pe măsură ce numărul furnizorilor de asistenţă medicală tradiţională ce vor adera la piaţa aplicaţiilor mobile va creşte, modelele de afaceri se vor extinde cu scopul de a include servicii de asistenţă medicală, publicitate şi venituri din vânzarea medicamentelor.Se pare că cea mai mare parte din venituri va proveni din serviciile legate de telefonia mobilă (46%) şi a vânzărilor de dispozitive (30%), iar download-ul de aplicaţii va reprezenta doar 14%.[13]
2.2. Relaţionarea cu rezultatele cercetărilor anterioare
Cercetările anterioare la care au fost supuse aplicaţiile cu specific medical din întreaga lume, au evidenţiat o serie de beneficii pe care acestea le aduc utilizatorului şi sistemului medical în general.
O parte din aceste avantaje sunt :
7
Ř oferirea de tratament în timp real, prin utilizarea dispozitivelor fără fir;
Ř salvarea vieţii pacienţilor prin intermediul consultaţiilor medicale de la distanţă, atât în caz de urgenţă, cât şi pentru diagnosticarea unor afecţiuni;
Ř accesibilitatea crescută la specialiştii din centrele medicale pentru locuitorii din mediul rural, în ceea ce priveşte diagnosticul şi tratamentul;
Ř facilitarea unor diagnostice precoce şi precise;
Ř optimizarea luării deciziilor medicale şi creşterea calităţii asistenţei medicale printr-o mai bună şi rapidă informare;
Ř creşterea eficienţei în furnizarea serviciilor medicale;
Ř asigurarea rapidă a accesului la istoricul medical al pacienţilor, reducând astfel riscul interacţiunilor medicale negative şi cel al răspunsului slab la tratamentele prescrise;
Ř îmbunătăţirea eficienţei administrative şi o mai bună coordonare în asigurarea asistenţei medicale;
Ř creşterea oportunităţii tratamentului şi scăderea ratei reinternărilor, reducând astfel costurile medicale;
Ř consolidarea stării de sănătate a vârstnicilor ş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 aplicaţii,şi în acest fel orice tentativă de informare asupra beneficiilor şi riscurilor pe care le implică utilizarea acestor aplicaţii.Detalii legate de proiectare şi implementare ar trebui oferite celor ce doresc să implementeze o aplicaţie medicală,deoarece în acest fel ar putea fi evitate numeroase erori de cod,ce pot duce la elaborarea unui plan de medicaţie care poate să pună în pericol viaţa Patientului.Studiile realizate până în prezent se referă la aplicaţii medicale în domeniul cardiologiei sau testează diferite modificări ale dermului.
8
3. Soluţia propusă
Analiză-proiectare, arhitectură, programare
Aplicaţia se doreşte a fi realizată cu ajutorul codului Java, pentru dispozitivele cu sistem de operare Android, având o bază de date unde vor fi stocate date despre medici, tratamente, sfaturi şi boli, prin relaţionarea unor simptome cu bolile care au manifestări asemănătoare.
Stabilirea necesarului de resurse software şi hardware
Din punct de vedere funcţional, proiectul presupune crearea unei interfeţe uşor de utilizat, prin care utilizatorul să aibă acces la informaţiile medicale.Prin selectarea anumitor simptome sau caracteristici ale bolilor aflate în baza de date a aplicaţiei, se va prezenta un diagnostic prezumptiv, menit să descrie posibila tipologie a bolii, tratamentul aferent acesteia şi medicul aflat în cea mai apropiată locaţie, care ar putea să se ocupe de această afecţiune 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 achiziţia de date, analiza datelor şi decizia prin mai multe tehnici şi redirecţionare de date şi feedback.Arhitectura propusă se referă la proiectarea unui instrument flexibil pentru achiziţie de date, management, elaborarea şi decizia potrivite pentru acele sisteme care sunt echipate cu dispozitive uşor de purtat, distribuite la distanţă, în cazul în care o atenţie deosebită este destinată fluxului de informaţii medicale eterogene şi de intercomunicare. În plus, posibilitatea de a opera în timp real, impune cerinţe critice de eficientă pentru fiecare modul creat.
Modul de analiză al server-ului este bazat pe cunoaşterea 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 solicitării utilizatorului, modulul :
(i) va prelua datele relevante din baza de date centrală, aflată la distanţă
(ii) va aplica analiza algoritmilor
(iii) păstrează 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 aplicaţia funcţionează ca sistem destinat clientului în ceea ce priveşte server-ul de module de analiză.
Estimarea necesarului de resurse
În ceea ce priveşte elementele determinate pentru configuraţia unui echipament de prelucrare, ar trebui să avem în vedere:
9
1.Memoria internă
Estimarea necesarului de memorie internă se face pe baza relaţiei 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 execuţia 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 funcţie de echipamentele de intrare-iesire şi de unităţile de memorie externă. Numărul echipamentelor periferice necesare se stabileşte raportându-se la următorii factori:
- fluxurile de intrare-ieşire
- volumul de date ce se cere a fi stocat în memoria externă
- modul de exploatare
- numărul de programe ce se execută în paralel
Dispozitivele portabile trebuie să fie în conformitate cu următoarele caracteristici (ce trebuie adoptate):
(i) Sistem de operare la nivel înalt (Windows Mobile, iOS, Android)
(ii) Ecran mare pentru interfaţa 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 puţin o zi)
(ix) Ergonomie.
Dispozitivul va comunica cu serverul în următoarele situaţii:
· Conexiune bazată pe timp: toate datele necesare analizei de la distanţă, modulele trebuie să fie încărcate. Decompresia datelor este esenţială pentru limitarea timpului
10
de încărcare. Mai mult decât atât, criptarea este obligatorie pentru acordarea confidenţialităţii datelor personale. Autentificare continuă poate fi evitată cu ajutorul certificatelor de autorizate.
· Conexiune de urgenţă: în timpul monitorizării senzorilor, în cazul în care modul de raţionament detectează o condiţie 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), documentaţie, monstre de cod şi tutoriale. Platformele de dezvoltare sprijinite în prezent includ calculatoare bazate pe x86 care rulează Linux (orice distribuţie Linux desktop modernă), Mac OS X 10.4.8 sau mai recent, Windows XP sau Vista. Cerinţele 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), utilizând plug-in-ul Android Development Tools (ADT), deşi dezvoltatorii pot folosi orice editor de text pentru a edita fişiere XML şi Java şi apoi să utilizeze unelte din linia de comandă pentru a crea, construi şi depana aplicaţii Android.
Proiectarea bazei de date
Baza de date este o colecţie 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 menţinute manual sau computerizat, aşa cum este majoritatea bazelor de date folosite în momentul de faţă.
O bază de date este o colecţie de date creată şi menţinută computerizat, care permite operaţii de introducere, ştergere, actualizare şi interogare a datelor.
Metodologia de proiectare, constă într-o abordare structurată, în care se utilizează proceduri, tehnici, instrumente şi documentaţii, pentru a susţine şi facilita procesul de proiectare.O metodologie de proiectare constă în mai multe faze, conţinând etape care îndrumă proiectantul în alegerea tehnicilor adecvate fiecărei 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 cerinţe 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. Distribuția SQLite vine cu un program linie-comandă de sine stătător (sqlite) care poate fi folosit pentru a administra o bază de date SQLite și care servește ca un exemplu despre modul în care trebuie folosită librăria SQLite.
În fig.3 sunt prezentate tabelele bazei de date şi legăturile dintre acestea:
11
- tabela pacient are o legătură de 1: n cu tabela Symptom
- tabela Symptom are o legătură de 1:1 cu tabela Condition_Symtom
- tabela Condition_Symptom are o legătură de n:1 cu tabela Condition
- tabela Condition are o legătură de 1: n cu tabela Specialization_Condition
- tabela Specialization are o legătură de 1: n cu tabela Specialization_Condition
- tabela Specialization are o legătură 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 priveşte datele de intrare, se regăsesc următoarele :Datele utilizatorului :
- Nume şi prenume utilizator
- Parolă
- Id
- Email
Date referitoare la simptomele pentru care este necesar un anumit diagnostic:- Modificări ale temperaturii de bază
12
- Modificări ale ritmului cardiac
- Dureri
- Acuitate vizuală sau auditivă modificată
- Tulburări de echilibru sau de orice altă natură,etc
În momentul în care datele de intrare au fost prezentate,se aşteaptă realizarea unei interogări asupra bazei de date şi returnarea unui rezultat pertinent.Rezultatul va conţine datele de ieşire, care trebuie să fie într-o măsură cât mai obiectivă şi să returneze un diagnostic prezumtiv şi un medic(de preferinţă cel mai apropiat ca locaţie de locul în care se află utilizatorul la acel moment).
Ca date de ieşire vom avea:Date referitoare la diagnostic:
- Tipologia în care se încadrează boala
- Modul în care se manifestă
- Recomandările aferente(în cazul în care este o afecţiune uşoară, se poate recomanda un anumit medicament pentru ameliorarea stării de sănătate; în cazurile mai grave se va returna numele unui medic, specializarea acestuia şi locaţia în care acesta activează, pentru a se facilita accesul la informaţie şi rezolvarea în timp util a problemei de sănătate)
Datele referitoare la medic:- Nume
- Specializarea
- Locaţia (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 agravării acesteia.
Analiza şi proiectarea structurilor de date
Având prezentate mai sus, în linii mari, detaliile sistemului informatic în cauză, următorul pas logic în atingerea ţelului va fi de a analiza structurile de date/entităţile folosite de aplicaţie sau care, deşi nu sunt accesate direct de către aplicaţie, au un aport benefic la structura, funcţionalitatea şi integritatea aplicaţiei.
Tabele aferente structurilor de date vor purta denumirea în engleză a fiecărei entităţi.
O primă entitate ce rezultă din tema problemei este: Medic.
13
Fiind o entitate de bază, aceasta va necesita un număr de câmpuri cu caracter informativ relativ mare, motivul fiind dat felul în care sistemul informatic va funcţiona, faptul că în momentul în care utilizatorul va ajunge în pasul final (diagnosticare încheiată) – acesta va dori să afle, spre exemplu, câteva date de contact ale medicului ce i-a fost recomandat în baza simptomelor descrise.
Câmpul 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 informaţii. Spre exemplu: primele 3 caractere vor reprezenta codul generat de prescurtările spitalului şi numărului deţinut de spitalul la care lucrează medicul afişat de aplicaţie: în cazul în care medicul aparţine unei anumite unităţi medicale, codul rezultat va fi: H0x(unde x reprezintă numărul asignat unităţii medicale în care acesta îşi desfăşoară activitatea).În cazul în care medicul nu este asignat unui spital de urgenţă, se vor preciza caracterele aferente judeţului de care aparţine spitalul la care acesta este angajat. Următoarele 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ă înţelegere.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 specializări sau au doar o parte din subramurile unei anumite specializări) ce preced numărul current(exemplu forma finală: H01DRM0001)
Următoarele câmpuri 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
Câmpuri utilizate:
Cheie primară: SymptomID - tip de dată Integer, auto incrementată, unică, non-nulă
Următoarele câmpuri, 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
Câmpuri utilizate:
Cheie primară: DiagnosticID, tip de dată Integer, auto incrementată, unică, non-nulă
Următoarele câmpuri, cu caracter informativ:14
Diagnostic_name, tip de dată String, lungime fixă de 45 de caractere.
MedicID reprezintă cheia externă şi elementul de legătură cu tabela Medic.
PatientID reprezintă cheia externă şi elementul de legătură cu tabela Patient.
Tabela are o relaţie de n-1 cu tabela Medic .
d) Patient
Câmpuri 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 legătura î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 legătură î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 legătură cu tabela Specialization.
g) Condition
ConditionId: tip de dată String, lungime fixă de 5 caractere
15
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 legătură 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 legătură cu tabela Condition.
SymptomId este cheie externă a tabelei şi element de legătură cu tabela Symptom.
Aplicaţia se doreşte a fi realizată cu ajutorul codului Java, pentru dispozitivele cu sistem de operare android, având o bază de date unde vor fi stocate date despre medici, tratamente, sfaturi şi boli, prin relaţionarea unor simptome cu bolile care au manifestări asemănătoare.
Toate câmpurile destinate importului de date/datelor de intrări vor fi validate şi valorile date vor trebui să fie conforme cu tipul de dată şi dimensiunea impuse la crearea bazei de date. Excepţie fac cele ce vor primi o valoare dintr-un set predefinit de date asupra cărora s-au făcut deja verificările mai sus numite.
Pentru că se doreşte realizarea unei aplicaţii interactive, este necesar să fie precizat şi ciclul de viaţă al unei activităţi, ce descrie starea în care o activitate poate fi la un moment dat.
Următoarele puncte definesc stările în care activitatea se poate regăsi:
· Running - Activitatea a fost creată (onCreate()), pornită (onStart()) şi este afişată pe
ecranul aparatului; în cazul în care activitatea a mai fost utilizată şi aplicaţia a salvat
starea acesteia (onSaveInstanceState()), activitatea este reluată din acel punct
(onRestoreInstanceState() şi onResume()); în această stare utilizatorul interacţionează
cu activitatea prin intermediul interfeţei 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 execuţia
(onResume()) şi este plasată înapoi în prim-plan;
16
· 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 activităţi; deoarece managementul memoriei este un aspect
important pentru sistemul de operare al dispozitivului mobil, procesul care găzduieşte
o activitate întreruptă, oprită sau distrusă, poate fi terminat pentru a elibera memorie
pentru noi activităţi; doar procesele ce gestionează activităţi ce rulează sunt protejate;
Android este o platformă software şi un sistem de operare pentru dispozitive şi telefoane mobile bazată pe nucleul Linux, dezvoltată iniţial de compania Google, iar mai târziu de consorţiul comercial Open Handset Alliance. Android permite dezvoltatorilor să scrie cod gestionat în limbajul Java, controlând dispozitivul prin intermediul bibliotecilor Java dezvoltate de Google. Aplicaţiile scrise în C şi în alte limbaje pot fi compilate în cod maşină ARM şi executate, dar acest model de dezvoltare nu este sprijinit oficial de către Google.
Lansarea platformei Android la 5 noiembrie 2007 a fost anunţată prin fondarea Open Handset Alliance, un consorţiu de 48 de companii de hardware, software şi de telecomunicaţii, consacrat dezvoltării 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 doreşte crearea şi modificarea ulterioară de aplicaţii, pentru sistemul Android, aplicaţia 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
Intrările necesare sistemului vor fi cele cu privire la detaliile pacientului şi anume simptomele pe care acesta le prezintă.Utilizatorul va trebui să completeze unele informaţii generale, pentru a putea afla ce afecţiune prezintă.
Simptome – în cazul în care pacientul resimte mai multe stări ce pot conduce la diverse diagnostice, ele trebuie menţionate în totalitate, deoarece vor ajuta la o mai bună interogare a bazei de date şi la returnarea unui diagnostic prezumptiv cât mai aproape de cel pus de un medic într-un cabinet specializat.
17
Pe baza acestor informaţii, sistemul va putea returna sugestii cu privire la un posibil diagnostic şi eventual unul sau mai mulţi medici ce pot oferi asistenţă pentru condiţia pacientului( în cazul în care pacientul se afla la distanţă egală dintre două localităţi, sistemul va returna doi medici pentru a da posibilitatea pacientului să aleagă variantă care îi este mai utilă).
Acestea din urmă reprezintă datele de ieşire, 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 afişate în format listă iar utilizatorul va putea accesa detaliile fiecăruia, aşa cum sunt stocate în structura de date.
Vor fi afişate:
· Specializarea de care aparţine respectivul simptom
· Lista completă a simptomelor ce stau la baza diagnosticului
· Lista tuturor medicilor ce pot să ofere asistenţă( utilizatorul va putea accesa detaliile fiecărui medic)
Acest formular va putea fi printat conţinând detaliile diagnosticului cât şi cele ale medicului ales.
Formatele de intrare se vor constitui în ferestre individualizate de preluare a datelor şi vor conţine câmpuri “dedicate”. Pentru a asigura concretizarea cât mai amplă a cerinţelor sistemului proiectat, la proiectarea formatelor de ieşire trebuie să se ţină cont atât de principiile, cerinţele legislative, informaţionale şi de proiectare, cât şi de posibilităţile şi restricţiile tehnice.Formatele de ieşire trebuie să fie prezentate într-o formă simplă, inteligibila care să asigure şi facilitatea în utilizare.
Analiza şi proiectarea codurilor
În ceea ce priveşte clasele necesare elaborării codului, acestea sunt următoarele:
· clasa Medic
· clasa Pacient
· clasa Diagnostic
· clasa Simptom
18
În cadrul aplicaţiei, metodele de validare ale datelor folosite vor fi multiple, atât la nivelul bazei de date cât ş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 câmp/coloană, i.e. un câmp de tip integer nu va accepta decât date de tip numeric şi atâta timp cât valoare dată se încadrează în intervalul de valori suportate de tipul respectiv.De asemenea, regulile de validare vor fi impuse şi prin limitarea unui câmp de tip String/Varchar, de exemplu, la un anumit număr 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 priveşte validarea la nivelul aplicaţiei, diferite motode vor fi folosite, începând cu cea mai des întâlnită şi anume verificarea/filtrarea caracterelor. În cazul unor câmpuri destinate datelor de intrare, i.e. forma de adăugare a unui medic, în funcţie de tipul de data folosit, unele caractere vor fi permise, altele nu. O altă regulă importanta implementată în aplicaţie este verificarea cardinalitatii. Va fi folosită atunci când o entitate de tip medic se va adăuga iar regulă impusă va fi ca acesta să aibă cel puţin o specializare. De asemenea, aceasta verificare va fi făcută în cazul diagnosticului, entitate ce vă trebuie să aibă cel puţin un simptom.Verificări de existenţă/consistenţă vor fi făcute în cazul câmpurilor ce necesită o valoare, lucru care la rândul său 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ă, câmpul validat a fost declarat non-nul.Deşi sistemul de gestiune al bazei de dată va face o verificare a tipului de dată atunci când se vor încerca modificări asupra entităţii curente (insert/update), la nivelul aplicaţiei se vor face, de asemenea, astfel de verificări. Utilitatea acestei operaţii 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 adăugare/editare a unui medic, va exista opţiunea de a putea ataşa o poză cu caracter informativ. Cu această ocazie, câteva tipuri de verificări vor fi făcute. În prima fază se va verifica există fişierului ce urmează să fie importat. Următorul pas va fi de a i se verifica dimensiunea (in pixeli ) cât şi spaţiul ocupat pe disk (în kilo octeţi). Ultima verificare va fi făcută pentru a deduce tipul imaginii pentru a se asigura că fişierul în cauză este întradevăr o imagine şi în cazuri speciale, pentru a exclude anumite formate de imagine.
Interfaţa grafică
Dată fiind natura şi rolul interfeţei 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 activităţii.Astfel că în cazul de faţă trebuie luaţi în considerare mai mulţi factori, cum ar fi:
· complexitatea aplicaţiei – o numărul de module şi submoduleo datele afişate , volumul şi importanţa acestora
19
· durata medie pe care un utilizator o petrece în cadrul aplicaţiei· diferenţierea clară a datelor prin folosirea inteligentă a culorilor şi tipurilor de
afişare· diferenţierea clară a informaţiilor importante de cele neimportante sau informative· gradul de cunoaştere a utilizatorului în ceea ce priveşte folosirea unui terminal ce
rulează sistemul de operare Android în general· claritatea şi diferenţierea structurilor şi diverselor activităţi
Factorii care au condus la forma actuală a interfeţei au fost analizaţi în concordanţă cu scopul aplicaţiei. Astfel s-au evaluat diverşi indicatori cum ar fi durata medie a timpului petrecut de către un utilizator / administrator, conectivitatea link-urilor, uşurinţa în înţelegerea structurii, uşurinţa în utilizare, paleta de culori etc.Principalul obiectiv a fost acela de a proiecta interfaţa disponibilă utilizatorului în aşa fel încât utilizatorul să aibă partea de o experienţă cât mai plăcută şi o navigare cât mai eficientă. Începând cu primul pas şi anume autentificarea în aplicaţie până la momentul terminării procesului de diagnosticare, s-au luat în vedere aspecte ca:
- alegerea controalelor potrivite- poziţionarea cât mai potrivită în ecran, ţinând cont de faptul că aplicaţia poate fi rulată
de dispozitive de dimensiuni mici (telefoane mobile/smartphone-uri) până la dispozitive de dimensiuni considerabile (tablete sau chiar smartbook-uri).
- navigarea să se facă în condiţii optime utilizând funcţiile încorporate în dispozitivele Android, cum ar fi: întoarcerea la ecranul precedent, ascunderea aplicaţiei şi revenirea la aceasta sau folosirea gesturilor de atingere (touch gestures).
Acelaşi nivel de atenţie a fost acordat părţii de administrare a conţinutului sistemului informatic. S-a optat pentru un ecran principal ce va avea în componenţa lui toate legăturile către funcţionalităţile aplicaţiei. Acesta va avea un comportament dinamic, ce va permite reconfigurarea sa în funcţie de nivelul de acces al utilizatorului curent. Acest lucru impune faptul că atunci când un utilizator cu drepturi de administrator se va conecta, ecranul principal va afişa toate legăturile către funcţionalităţile aplicaţiei. De asemenea, în cazul opus, legăturile către modulele de administrare vor fi ascunse, lăsând loc celor de bază.
În fig.4 este prezentată schema fluxului informaţional prezentă în cadrul sistemului de diagnosticare la distanţă.Aşa cum se poate vedea, aceasta conţine două interfeţe distincte, fiecare cu rol în administrarea/utilizarea aplicaţiei.
20
Fig.4 Schema fluxului informaţional aferent temei
Interfaţa comună utilizator-administrator
Autentificare
Pentru a se autentifica, utilizatorul va avea la dispoziţie două metode. Prima dintre acestea este aceea de a se autentifica automat fără a fi nevoie de un utilizator în baza de date, acesta folosind unul anonim cu drepturi minime pentru a putea accesa şi folosi funcţia 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ă autentificării) din cadrul sistemului de diagnosticare.
21
Fig.5 Autentificare
1. Ecranul principal
Imediat după ce utilizatorul se va loga (sau va alege varianta anonimă), ecranul principal va fi afişat. În funcţie de rolul utilizatorului curent, aplicaţia va activa sau dezactiva unele funcţii. Există două tipuri de roluri: administrator şi user.
Primul (a) va permite utilizatorului să aibă acces la toate funcţiile aplicaţiei cum ar fi afişarea tuturor user-ilor din aplicaţie, afişarea diagnosticelor şi a simptomelor etc.
Cel de-al doilea (b) va oferi doar funcţii de bază cum ar fi diagnosticarea, afişarea detaliior user-ului curent şi afişarea listei de medici.
În fig. 6-7 sunt prezentate cele două tipuri de roluri, în partea stânga este prezentată autentificarea printr-un id, iar în partea dreaptă este prezentată autentificarea anonimă.
22
Fig.6-7 Ecran principal
Interfaţa utilizator
Reprezintă interfaţa destinată utilizatorului final, acesta putând efectua doar operaţiile de bază ale sistemului informatic precum şi administrarea propriului. Totul începe de la autentificare. Apoi în ecranul principal va putea alege din următoarele:
1. Diagnosticare (Diagnose me)
2. Detaliile mele (My Details)
3. Medici (Medics)
1. Diagnosticare – Diagnose Me
În fig. 8-9 sunt prezentate etapele diagnosticării prin alegerea elementelor dintr-o listă de simptome.
23
Fig.8-9 Diagnosticare prin listă
Imediat după ce butonul „Diagnose Me” va fi apăsat, utilizatorul va fi redirectat pe un alt ecran unde i se vor prezenta două opţiuni pentru putea duce la bun sfârşit diagnosticarea.
a) Diagnosticare prin alegerea simptomelor dintr-o listă
Imediat ce butonul etichetat drept „Pick the symptoms from a list” va fi apăsat, 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 legătură între ele. Dacă utilizatorul va selecta simptome ce nu sunt parte a unui singur diagnostic, atunci toate diagnosticele posibile vor fi afişate în pasul următor. Fiind un ecran unde nu se vor introduce date de la tastatură, nu se vor face validări cu privire la simptome, acestea făcându-se la momentul introducerii în baza de date, folosind ecranul simptome (Symptoms).
Atunci când utilizatorul va avea cel puţin 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ă opţiune este folosită în cazul în care simptomele prezentate nu se regăsesc în lista dată de aplicaţie).
24
Fig. 10-11 Diagnosticare pe baza simptomelor date de la tastatura
Imediat ce butonul etichetat drept „Type the symptoms” va fi apăsat, aplicaţia va comută spre un alt ecran. Cea de-a doua metodă presupune că utilizatorul să introducă de la tastatură datele pe baza cărora se va rula procesul de diagnosticare.
Acesta va putea astfel să introducă una sau mai multe simptome, cu condiţia ca acestea să conţină caractere alfanumerice despărţite prin virgulă.
În acest sens se vor face validări astfel că regulile menţionate mai sus să fie respectate iar procesul de diagnosticare să poate fi executat cu succes.Atunci când utilizatorul va avea cel puţin un simptom introdus, va putea continua procesul.
În fig. 12-13 este prezentată modalitatea de afişare a diagnosticelor şi a medicilor, după selectarea simptomelor şi activarea opţiunii de diagnosticare.
25
Fig.12-13 Prezentarea diagnosticelor şi a medicilor
Odată ce utilizatorul a ales sau a introdus cel puţin un simptom, aplicaţia va interoga baza de date şi va afişa 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 apăsat, aplicaţia va comuta spre un alt ecran ce va afişa, în prima fază, utilizatorul curent în format listă. Acţiunile posibile în această fază sunt fie aceea de a efectua funcţia de apăsare pe numele utilizatorului sau aceea de întoarcere la ecranul precedent, folosind funcţia de întoarcere, implementată implicit pe toate dispozitivele cu android.
Prima acţiune însă, va permite vizionarea şi eventual editarea detaliilor utilizatorului curent. Pot fi actualizate câmpuri ca: nume, prenume, email sau parola.Validări de existenţa vor fi aplicate pentru primele trei câmpuri, întrucât au fost declarate nenule în baza de date. De asemenea, câmpului 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 apăsând pe butonul etichetat „save”.
În fig.14-15 sunt prezentate capturile de ecran aferente opţiunii de afişare a detaliilor pacientului (această formă este utilă doar în cazul în care utilizatorul este autentificat printr-un
26
id ,în cazul în care se foloseşte varianta de utilizare anonimă a aplicaţiei, această opţiune nu există).
Fig.14-15 Detalii pacient
3.Medici
Imediat ce butonul etichetat drept „Medics” va fi apăsat, aplicaţia va comuta spre un alt ecran ce va afişa, în format listă, toţi medici ce au fost introduşi în baza de date.
În acest moment, utilizatorul va putea interoga baza de date, apăsând pe medicul dorit, pentru a viziona detaliile acestuia. Modificarea şi salvarea datelor nu vor fi permise.
Vor fi afişate informaţii cum ar fi: nume, locaţie, adresa de email, seal şi toate specializările deţinute de acesta.
În fig.16-17 sunt prezentate detaliat informaţiile referitoare la medicii pe care aplicaţia îi are în baza de date.
27
Fig.16-17 Detalii medici
Interfaţa administrator
Desigur, un administrator va avea de asemenea acces la funcţia de bază a sistemul informatic şi anume diagnosticarea, scopul fiind acela de a se asigura ca prezenta funcţionalitate rulează în parametrii normali, fără a crea probleme utilizatorilor.
Totodată, acesta va avea parte de o funcţionalitate extinsă, având acces la ecranele de vizionare/editare/adăugare pentru pacienţi, medici, simptome, specializări şi diagnostice.În cele ce urmează vor fi prezentate toate ecranele menţionate mai sus.
1. Pacienţi
Imediat ce butonul etichetat drept „Patients” va fi apăsat, aplicaţia va comută spre un alt ecran ce va afişa toţi utilizatorii introduşi în baza de date, în format listă. Acţiunile posibile în această fază sunt multiple.
În funcţie de durata de apăsare, acţiunile pot fi următoarele:
28
- O simplă apăsare va comuta către alt ecran unde se vor afişa detaliile pacientului respectiv. Pot fi vizionate şi actualizate câmpuri că: nume, prenume, email, rolul,parola sau dacă este activ sau inactiv. Totodată, detaliile pacientului pot fi actualizate şi apoi salvate prin apăsarea butonului „save”.
- O apăsare lungă, ce va face vizibil meniul contextual. Acesta este compus din două funcţii:
o „Delete patient”
§ În prima fază va afişa un mesaj de confirmare(yes/no) iar dacă butonul yes va fi apăsat, pacientul respectiv va fi şters din baza de date.
o „Add patient”
§ Acesta funcţie va comuta către ecranul de detalii ale pacientului, de data aceasta administratorul având posibilitatea de a crea un nou pacient, introducând valori pentru toate câmpurile iar apoi apăsând butonul „save”.
O altă opţiune este cea de întoarcere la ecranul precedent, folosind funcţia de întoarcere, implementata implicit pe toate dispozitivele Android.
Validări de existenţă vor fi aplicate pentru primele trei câmpuri, întrucât au fost declarate non nule în baza de date. De asemenea, câmpului 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 apăsând pe butonul etichetat „save”.
29
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 apăsat, aplicaţia va comuta spre un alt ecran ce va afişa, în format listă, toţi medici ce au fost introduşi în baza de date. Acţiunile posibile în această fază sunt multiple.
În funcţie de durată de apăsare, acţiunile pot fi următoarele:
- O simplă apăsare va comută către alt ecran unde se vor afişa detaliile medicului respectiv. Pot fi vizionate şi actualizate câmpuri că: nume, locaţie, email, seal şi toate specializările sale. Totodată, detaliile medicului pot fi actualizate şi apoi salvate prin apăsarea butonului „save”.
- O apăsare lungă, ce va face vizibil meniul contextual. Acesta este compus din două funcţii:
o „Delete medic”
§ În prima fază va afişă un mesaj de confirmare(yes/no) iar dacă butonul yes va fi apăsat, medicul respectiv va fi şters din baza de date.
o „Add medic”
30
§ Acesta funcţie va comuta către ecranul de detalii ale medicului, de data aceasta însă administratorul având posibilitatea de a crea un nou medic, introducând valori pentru toate câmpurile iar apoi apăsând butonul „save”.
Este prezentă opţiunea de întoarcere la ecranul precedent, folosind funcţia de întoarcere, implementată implicit pe toate dispozitivele Android.
Vor fi afişate informaţii cum ar fi: nume, locaţie, adresa de email şi toate specializările deţinute de acesta. De asemenea noi specializări vor putea fi adăugate sau cele existente pot fi şterse din baza de date.
Validarea de existenţa va fi aplicată pentru câmpul nume întrucât acesta nu trebuie să fie nul. De asemenea, câmpului email şi se va aplica o validare pentru a decide dacă formatul textului introdus corespunde cu tipul valorii (tip de data email).
3.Specializări
Imediat ce butonul etichetat drept „Specializations” va fi apăsat, aplicaţia va comută spre un alt ecran ce va afişa, în format listă, toate specializările ce au fost introduse în baza de date.Acţiunile posibile în această fază sunt multiple.
În funcţie de durată de apăsare, acţiunile pot fi următoarele:
- O simplă apăsare va comuta către alt ecran unde se vor afişa detaliile specializării respective. Poate fi vizionat câmpul descriere. Totodată, detaliile specializării pot fi actualizate şi apoi salvate prin apăsarea butonului „save”.
- O apăsare lungă, ce va face vizibil meniul contextual. Acesta este compus din două funcţii:
o „Add specialization”
Acesta funcţie va comuta către ecranul de detalii ale specializării, de data aceasta însă administratorul având posibilitatea de a crea o nouă specializare, introducând valori pentru toate câmpurile iar apoi apăsând butonul „save”. Validarea de existenţă va fi aplicată pentru câmpul descriere întrucât acesta nu trebuie să fie nul.
31
Fig.19-20 Specializări medici
În fig.19-20 sunt prezentate capturile de ecran aferente prezentării specializărilor medicilor.
4.Diagnostice
Imediat ce butonul etichetat drept „Conditions” va fi apăsat, aplicaţia va comuta spre un alt ecran ce va afişa, în format listă, toate diagnosticele ce au fost introduse în baza de date.Acţiunile posibile în această fază sunt multiple.
În fig.21 este prezentată modalitatea de afişare a informaţiilor, în urma diagnosticării.În prima parte sunt prezentate posibilele diagnostice, iar în a doua parte sunt recomandările în ceea ce priveşte medicii la care ar trebui să se adreseze utilizatorul, în funcţie de specializarea de care aparţin respectivele diagnostice.
32
Fig.21 Rezultat diagnosticare
În funcţie de durata de apăsare, acţiunile pot fi următoarele:
- O simplă apăsare va comuta către alt ecran unde se vor afişa detaliile diagnosticului respectiv. Pot fi vizionate şi actualizate câmpuri ca: nume şi descriere. Desigur, pentru fiecare diagnostic se vor afişa toate simptomele ce fac obiectul lor, iar administratorul va putea edita această listă. Totodată, detaliile diagnosticului pot fi actualizate şi apoi salvate prin apăsarea butonului „save”.
- O apăsare lungă, ce va face vizibil meniul contextual. Acesta este compus din două funcţii:
o „Delete condition”
§ În prima fază va afişa un mesaj de confirmare(yes/no), iar dacă butonul yes va fi apăsat, diagnosticul respectiv va fi şters din baza de date.
o „Add condition”
§ Acesta funcţie va comuta către ecranul de detalii ale diagnosticului, de data asta aceasta administratorul având posibilitatea de a crea un nou diagnostic, introducând valori pentru toate câmpurile iar apoi apăsând butonul „save”. Validarea de existenţă va fi aplicată pentru câmpul nume întrucât acesta nu trebuie să fie nul.
33
Fig.22-23 Condiţii
În fig.22-23 sunt prezentate condiţiile şi detaliile acestora, pe baza cărora interogarea bazei de date va returna un rezultat sau altul.Utilizatorul trebuie să aleagă cu grijă aceste condiţii pentru a evita cazul în care i se va returna un rezultat eronat.
5.Simptome
Imediat ce butonul etichetat drept „Symptoms” va fi apăsat, aplicaţia va comuta spre un alt ecran ce va afişa, în format listă, toate simptomele ce au fost introduse în baza de date.
Acţiunile posibile în această fază sunt multiple. În funcţie de durată de apăsare, acţiunile pot fi următoarele:
- O simplă apăsare va comuta către alt ecran unde se vor afişa detaliile simptomului respectiv. Pot fi vizionate şi actualizate câmpuri ca: descriere şi tip. Totodată, detaliile simptomului pot fi actualizate şi apoi salvate prin apăsarea butonului „save”.
- O apăsare lungă, ce va face vizibil meniul contextual. Acesta este compus din două funcţii:
o „Delete symptom”
34
§ În prima fază va afişă un mesaj de confirmare(yes/no), iar dacă butonul yes va fi apăsat, simptomul respectiv va fi şters din baza de date.
o „Add symptom”
§ Acesta funcţie va comută către ecranul de detalii ale simptomului, de data asta aceasta administratorul având posibilitatea de a crea un nou simptom, introducând valori pentru toate câmpurile iar apoi apăsând butonul „save”.
De aici, utilizatorul poate opta pentru funcţia de întoarcere la ecranul principal, în cazul în care se doreşte ieşirea din meniul curent.Validarea de existenţă va fi aplicată pentru câmpul descriere întrucât 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 adăuga de la tastatură.
Definirea activităţilor de întreţinere a funcţionalităţilor proiectului
35
Activităţile de întreţinere a funcţionalităţilor se referă mai mult la actualizările î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 modificări şi acestea au generat erori în baza de date.
Suportul şi validarea sistemului respectiv sunt realizate de către programator pentru utilizatorul final şi constau în:
· Asistenta şi teste de validare a sistemului,
· Validarea sistemului conform cerinţelor date în specificaţii,
· Rezultatele testărilor vor fi salvate în documente specifice,
· Dacă apare vreun defect pe parcursul funcţionării, problema va fi rezolvată conform proceselor de remediere a defectelor
Caracter inovativ
În agenda Ministerului Sănătății se află propunerea dezvoltării unui sistem de diagnosticare la distanţă ,care ar trebui să fie realizat până la sfârşitul anului 2015, soluţia va fi implementată atât în mediul privat,cât și în mediul public.
Soluția realizată are un caracter inovativ, deoarece implementează un sistem pentru informarea pacienţilor, dar şi a medicilor, în cazul în care utilizatorul se prezintă cu informaţia rezultată, la medic .Acest sistem furnizează informații medicale într-un timp mult mai scurt, facilitând astfel preluarea informațiilor din mediul electronic și schimbarea viziunii utilizatorilor în legătură cu modernizarea sistemului medical .
4. Concluzii, rezultate, propuneri
Relevanţa în raport cu cheltuielile anterioare şi realitatea economică
În ceea ce privește elementele hardware, aplicaţia poate fi implementată pe orice orice dispozitiv mobil ce are sistemul de operare Android, economisind astfel fondurile ce pot fi utilizate pentru dezvoltarea soluției software.Dacă până acum 20 de ani, acest gen de apliicatii erau de neînchipuit, implicând foarte multe costuri pentru cercetare , în acest moment situația se prezintă altfel, pentru că dezvoltarea numeroaselor soluții hardware și software a condus la reducerea costurilor și la descoperirea unor soluții inovative.
36
Realismul şi fezabilitatea soluţiei propuse
Soluția propusă reprezintă un element de actualitate și se bazează pe realizarea unei legături între medici și pacienți prin intermediul aplicaţiei.În statele mult mai dezvoltate implementarea de aplicaţii de acest gen fost deja realizată, chiar dacă, respectivele aplicaţii nu oferă o gamă foarte largă de informații.Din acest motiv soluția propusă este fezabilă, bazându-se pe cercetările anterioare și aducând elemente noi în ceea ce privește modul de utilizare, cantitatea de informații tipurile de utilizatori şi modalitatea de prezentare a informaţiilor.
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 implementării soluţiilor de acest gen.Sistemul de diagnosticare ar reprezenta o modalitate rapidă de informare, dar trebuie să luăm în considerare și categoriile de utilizatori care vor fi dispuși să aloce timp în scopul informării .O primă problemă ce ar putea fi întâmpinată este reprezentată de refuzul pacienților slab pregătiți din punct de vedere profesional, de a utiliza sistemul.În categoria pacienților ce nu vor putea folosi aceste dispozitive intră și persoanele cu deficiențe de vedere, pentru care nu au fost încă implementate soluții specifice.
Recomandări pentru cercetările ulterioare
Cercetările ulterioare ar putea fi centrate pe implementarea de noi funcţionalităţi, cum ar fi un segment care să ofere în cazurile bolilor mai uşoare, medicaţia corespunzătoare.Un alt element ar putea fi facilitarea accesului diferitelor categorii de persoane la informațiile medicale.Un prim pas ar fi reprezentat de introducerea unei funcții robot pentru emiterea informaţiilor, în scopul ajutorării persoanelor cu deficiențe de vedere, făcând astfel legătura dintre pacienții cu afecțiuni ușoare și cei cu afecțiuni grave și cu nevoi speciale.
37
5. Bibliografie
1. Roşca Ion Gh.,Ghilic-Micu Bogdan, Golosoiu-Georgescu Ligia, Năstase Floarea, Stoica
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:
40
Pasul 3:
S-a ales diagnosticarea pe baza listei de simptome, dupa selectarea variantelor corespunzatoare, utilizatorului i se va prezenta un diagnostic.
41
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.
