UNIVERSITATEA POLITEHNICA BUCUREȘTI

FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE

DEPARTAMENTUL CALCULATOARE

PROIECT DE DIPLOMĂ
Blockchain pentru date medicale
Versiunea 2021

Tudor-Răzvan Gheorghe

Coordonator științific:
Prof. habil. dr. ing. Dobre Ciprian

BUCUREŞTI

2021
 UNIVERSITY POLITEHNICA OF BUCHAREST
FACULTY OF AUTOMATIC CONTROL AND COMPUTERS
COMPUTER SCIENCE DEPARTMENT

DIPLOMA PROJECT
Blockchain for medical records
2021 Version

Tudor-Răzvan Gheorghe

Thesis advisor:
Prof. habil. dr. ing. Dobre Ciprian

BUCHAREST

2021
CUPRINS
Sinopsis ...................................................................................................................................... 3
Abstract ...................................................................................................................................... 3
1 Introducere ........................................................................................................................ 4
1.1 Context ........................................................................................................................ 4
1.2 Problema ..................................................................................................................... 4
1.3 Obiective ..................................................................................................................... 4
1.4 Structura lucrării.......................................................................................................... 4
2 Analiza și specificarea cerințelor........................................................................................ 5
2.1 Specificarea problemei ................................................................................................ 5
2.2 Plan de lansare ............................................................................................................ 6
2.3 Lista de funcționalități ................................................................................................. 7
2.4 Ansamblu proiect ........................................................................................................ 8
3 Studiu de piață / Abordări existente.................................................................................. 8
3.1 Abordări existente ....................................................................................................... 8
3.1.1 Regina Maria ........................................................................................................ 8
3.1.2 Medicover ............................................................................................................ 9
3.1.3 STATUS ............................................................................................................... 10
3.2 Tehnologii multiplatformă versus native .................................................................. 11
3.3 Tehnologii multiplatformă disponibile ...................................................................... 11
3.3.1 React Native ....................................................................................................... 11
3.3.2 JavaScript ........................................................................................................... 12
3.3.3 Ionic .................................................................................................................... 12
3.3.4 HTML & HTML5 .................................................................................................. 13
3.3.5 CSS ...................................................................................................................... 13
3.3.6 Xamarin .............................................................................................................. 13
3.3.7 C# ....................................................................................................................... 14
3.3.8 Flutter................................................................................................................. 14
3.3.9 Dart .................................................................................................................... 14
3.4 Compararea tehnologiilor ......................................................................................... 15
3.4.1 Performanţă ....................................................................................................... 15

1
 3.4.2 Reutilizarea codului............................................................................................ 17
3.4.3 Popularitate in randul programatorilor ............................................................. 17
3.4.4 Alegerea tehnologiilor ....................................................................................... 18
4 Soluția propusă ................................................................................................................ 18
4.1 Arhitectura MediBlock .............................................................................................. 18
4.2 Diagramă de activitate .............................................................................................. 19
4.3 Structura aplicației mobile ........................................................................................ 20
4.3.1 Componente ...................................................................................................... 20
4.3.2 Servicii ................................................................................................................ 21
4.3.3 Modele ............................................................................................................... 22
4.3.4 Ecrane ................................................................................................................ 22
4.4 Alegerea paletei de culori ......................................................................................... 23
5 Detalii de implementare .................................................................................................. 24
5.1 Etapele dezvoltării ..................................................................................................... 24
6 Scenariu de utilizare......................................................................................................... 26
7 Evaluarea rezultatelor ...................................................................................................... 31
7.1 Modul de testare ....................................................................................................... 32
7.2 Instrumente de testare și rezultatele acestora ......................................................... 32
7.2.1 Performanță ....................................................................................................... 32
7.2.2 CPU Profiler ........................................................................................................ 33
7.2.3 Memorie............................................................................................................. 33
7.2.4 Dimensiunea aplicației ....................................................................................... 34
8 Concluzii ........................................................................................................................... 35
8.1 Dezvoltări ulterioare ................................................................................................. 35
9 Anexe ............................................................................................................................... 37

2
SINOPSIS
Conform „European Health Index”, România ocupă penultimul loc în clasamentul sistemelor
de sănătate din Europa. Principalele metrici la care statul roman are rezultate negative sunt
prevenția bolilor și accesarea online a datelor. Echipa MediBlock propune dezvoltarea unei
aplicații de stocare sigură a datelor medicale. Componenta mobilă a aplicației oferă
utilizatorilor șansa de a accesa istoricul medical oricând, crescând astfel acuratețea
informațiilor pe care aceștia le oferă doctorilor în timpul vizitelor medicale. Având în vedere
securitatea datelor, dar și un cost redus al stocării, acestea vor fi salvate într-un mediu
blockchain-hybrid.

ABSTRACT
According to the "European Health Index", Romania occupies the second to the bottom place
in the ranking of health systems in Europe. The main metrics at which Romania has negative
results are disease prevention and online data access. The MediBlock team proposes the
development of a secure medical data storage application. The mobile component of the
application gives users the chance to access their medical history at any time, thus increasing
the accuracy of the information they provide to the doctors during medical visits. Given the
security procedures and the cost-efficient storage, the data will be saved in a blockchain-
hybrid environment

3
1 INTRODUCERE
1.1 Context
Mediblock este o aplicație în care datele pacienților sunt stocate într-un mediu blockchain-
hybrid. Pe lânga back-end, programul prezintă o componentă mobilă pentru pacienți, dar și
una web pentru doctori. Motivația dezvoltării acestei aplicații a reprezentat-o dorința de a
ajuta la digitalizarea sistemului medical.

Lucrarea de diplomă se concentrează asupra componentei mobile a aplicației.

1.2 Problema
Aplicația MediBlock oferă soluții asupra lipsei unui sistem de date medicale centralizat,
încercând să creeze o modalitate ca pacienții să aiba acces la istoricul lor medical complet.

Proiectul de diplomă se axează pe problema accesării datelor medicale într-un mod facil.

1.3 Obiective
Scopul întregului proiect este realizarea integrării cu mai multe spitale și clinici din România,
oferind pacienților un istoric medical unificat. În mod particular, obiectivele dezvoltării
componetei mobile constau în crearea unui program rapid și ușor de utilizat, care să aibă un
public țintă cât mai mare.

1.4 Structura lucrării

Primul capitol oferă informații despre problema pe care proiectul dorește să o abordeze, dar
și despre soluțiile propuse.

Capitolul 2 relevă o analiză amănunțită asupra sistemului de sănătate din România, oferind
apoi trei etape ale dezvoltării aplicației.

Capitolul 3 prezintă un studiu de piață descriind principalii competitori, dar și tehnologiile

disponibile pentru rezolvarea problemei.

Capitolul 4 evidențiază arhitercura întregii aplicații, detaliând apoi structura componentei

mobile.

Capitolul 5 descrie etapele dezvoltării programului. În plus, sunt expuse dificultăți de

implementare întâmpinate, cât și soluțiile descoperite.

Capitolul 6 prezintă un scenariu de utilizare al aplicației.

Capitolul 7 evaluează rezultatele testelor de performanță la care a fost supusă componenta

mobilă a aplicației.

Capitolul 8 sumarizează lucrarea de diplomă. De asemenea, este prezentat un plan al

dezvoltării ulterioare a aplicației.

4
Capitolul 9 conține bibliografia folosită pentru obținerea de infomații în scopul redactării
lucrării de diplomă.

2 ANALIZA ȘI SPECIFICAREA CERINȚELOR

Proiectul de diplomă este o parte a unei lucrări mai complexe, realizată în cadrul Innovation
Labs, împreună cu Condruz Cristian și Terente Irina. A fost urmărită dezvoltarea unei aplicații
în care utilizatorii își pot accesa întreg istoricul medical, indiferent de clinica de care aparțin,
cu principalul scop de a diminua erorile medicale precum comunicarea ineficientă dintre
medic și pacient.

2.1 Specificarea problemei

Health Consumer Powerhouse (HCP) compară și monitorizează sistemele de sănătate din 35
de țări, incluzând toate statele membre ale Uniunii Europene și Canada.HCP a emis primul
„Euro Health Consumer Index” (Health Consumer Powerhouse, 2018) în anul 2005. Un an mai
târziu, a început să ofere recomandări de politici naționale pentru reformă, precum și
instrumente pentru a ajuta consumatorii. Indicii de performanță în anumite nevoi de asistență
medicală oferă informații guvernelor și sistemelor de sănătate cu privire la modul de
îmbunătățire a asistenței medicale. Comisia Europeană consideră că EHCI este cea mai
informativă și influentă evaluare a asistenței medicale europene.

Metodologia de măsurare a indecșilor permite consumatorilor să evalueze performanțele

asistenței medicale. Există indici de măsurare pentru boli de inimă, diabet, HIV, cancer la sân,
vaccinuri și informații despre pacienți.

După o analiză a sistemelor de sănătate în anul 2018, conform „Euro Health Consumer Index”,
România se află la coadă, ocupând poziția 34 din 35. Unul dintre indicatorii la care România a
primit calificativul “Nesatisfăcător” are în vedere posibilitatea de a accesa online datele
medicale ale pacienților, observându-se în figura 1.

Figura 1 EuroHealth Consumer Index 2018

În plus, lipsa prezenței în online a sistemului medical influențează negativ și prin alți factori
precum aglomerarea în spitale din cauza timpului mare de așteptare, suprasolicitarea
personalului cu birocrația necesară pentru o vizită la spital, costul ridicat pentru stocarea

5
datelor, dar și deteriorarea acestora atunci când sunt păstrate în format fizic. De asemenea,
acuratețea diagnosticului scade deoarece doctorul, neavând istoricul pacientului la
dispoziție, trebuie să se încreadă în faptul că acesta a reținut în mod corect informațiile
primite de la alți doctori și că nu au fost întâmpinate erori în comunicare.

Același studiu relevă și faptul că spitalele din România nu au infrastructura necesară pentru
a putea trata pacienții care sunt diagnosticați cu boli în stadii avansate, rezultatul observat
în figura 2 fiind nefavorabil pentru aceștia în majoritatea cazurilor. Astfel, având acces la
întregul istoric al pacientului, se pot realiza predicții pe baza prelucrării datelor sale, având
șansa să prevină diverse boli înainte de a se ajunge la complicații.

Figura 2 EuroHealth Consumer Index 2018

2.2 Plan de lansare

Echipa a creat inițial trei scenarii pentru lansarea aplicației. Primul scenariu se referea la un
proiect internațional, în care doctorii aveau acces la datele medicale ale unui pacient,
indiferent dacă acesta ar fi fost sau nu cetățean al țării respective. Avantajul unei astfel de
aplicații este sugerat de disponibilitatea unui istoric al pacientului oriunde în lume, scris în
limba engleză, prin care, în cazul în care un individ ar trebui să viziteze un spital, doctorii ar
avea informații utile despre acesta, cum ar fi alergii sau alte afecțiuni ce i-ar pune viața în
pericol. Problema principală a acestui scenariu este dat de normele prelucrării datelor cu
caracter personal. Articolul 45 1 , alineatul 1 al legii GDPR afirmă că transferul datelor cu
caracter personal către o altă țară sau către o organizație internațională este aprobat de către
Comisie doar dacă această consideră că există un nivel adecvat de protecție al datelor.
Rigurozitatea acestor legi constrânge astfel și funcționalitățile aplicației.

Al doilea scenariu a luat în considerare o colaborare cu CNAS pentru a crea o aplicație oficială,
utilizând datele stocate de această instituție pentru a efectua istoricul medical al fiecărui
cetățean român. Marele impediment al acestei idei este istoricul statului când este vorba de
realizarea unui sistem informatic pentru registrele de sănătate. Statul român a avut mai multe

1
https://www.privacy-regulation.eu/ro/45.htm

6
încercări eșuate de a digitaliza sistemul medical, astfel, o nouă investiție este puțin probabilă
în viiitorul apropiat.

Ultimul scenariu are în vedere un model business to business în care clienții vor fi clinicile
private din România. Statisticile arată că doar un procent de 2% dintre cetățenii români au o
asigurare privată de sănătate, iar, dintre cei care o fac, majoritatea au contract cu clinicile
respective prin angajator. În mod normal, dacă un individ decide să se mute de la o clinică
privată la alta, acesta nu își va putea transferă și istoricul medical. Astfel, acest scenariu
presupune crearea unui șablon universal pentru păstrarea și afișarea datelor pacienților,
făcând posibil transferul de informații între clinici. Fiind păstrate doar pe teritoriul României,
datele pot fi anonimizate și utilizate pentru cercetare dacă și pacientul este de acord cu acest
lucru.

După o analiză amănunțită a celor trei scenarii, împreună cu echipa și mentorii asignati de
către programul Innovation Labs, a fost luată hotărârea de a începe dezvoltarea aplicației
luând în calcul ultimul scenariu, acesta concentrându-se pe nevoile medicilor din clinicile
private. După lansarea MVP-ului, se va încerca integrarea cu diferite spitale din România,
încercând astfel o evoluție naturală spre al doilea scenariu.

2.3 Lista de funcționalități

MVP-ul aplicației mobile prezintă următoarele funcționalități:

1. Înregistrare utilizator.
2. Autentificare în aplicație. După ce utilizatorul a introdus o dată credenţialele, acesta
are posibilitatea de a se autentifica doar prin intermediul datelor biometrice.
3. Pacienții își pot vizualiza istoricul medical, dar și observații adăugate de doctori.
4. Generarea de grafice pe baza istoricului analizelor de sânge.
5. Generarea unui cod QR pentru a putea împărtăși datele cu cadre care nu utilizează
aplicația.
6. Calculator pentru indicele de masă corporală.
7. Dacă telefonul este capabil de acest lucru, utilizatorul își poate activa logarea folosind
datele biometrice.
8. Oscilarea între o temă normală și una “dark mode”.

Datele necesare pentru înregistrarea utilizatorilor sunt numele, prenumele, CNP-ul, e-mailul,
numărul de telefon, data nașterii și parola.

Pentru autentificarea în aplicație este nevoie de e-mail și parolă. Sesiunea va fi menținută

activă prin autorizarea cu tokeni JWT.

Pagina pacientului va fi disponibilă pentru vizualizare abia după autentificare. Sunt afișate
detaliile utilizatorului, istoricul medical, graficele analizelor de sânge şi un calculator al
indicelui de masă corporală.

7
Pentru funcționalități viitoare echipa a luat în calcul anonimizarea datelor în scopul de a fi
trimise către centrele de cercetare contra cost. Utilizatorii care sunt de acord cu prelucrarea
datelor primesc o parte din suma respectivă. De asemenea, o altă idee pentru viitor este
adăugarea de predicții pe analizele de sânge utilizând algoritmi de Machine Learning.

2.4 Ansamblu proiect

Proiectul este împărțit astfel:

• Condruz Cristian: back-end;

• Terente Irina: front-end, aplicație web pentru doctori;
• Gheorghe Tudor-Razvan: front-end, aplicatie mobilă pentru pacienți.

Lucrarea propusă se va adresa în continuare părții de mobile a proiectului.

3 STUDIU DE PIAȚĂ / ABORDĂRI EXISTENTE

În această lucrare vor fi menționate abordările existente care dispun de aplicație mobilă. Nu
există nicio aplicație activă pentru spitalele publice, astfel, studiul de piață se va concentra pe
clinicile private sau aplicații „third-party”.

3.1 Abordări existente

3.1.1 Regina Maria

Rețeaua privată de sănătate Regina Maria a fost fondată în anul 1995, fiind prima clinică
privată din România. În prezent rețeaua deține 33 de locații în 10 județe, dar se află în
parteneriat și cu alte 180 de clinici.

Compania a creat o aplicație mobilă complexă, numită „Contul meu REGINA MARIA”, oferind
facilități precum accesul la dosarul medical complet, istoricul pacientului, convorbiri cu
medicii, plata facturilor și programarea vizitelor online. Pe lângă serviciile de baza, Regina
Maria prezintă și o funcție interactivă care își încurajează utilizatorii la activitate fizică,
transformând kilometri parcurși de aceștia în reduceri către pachetele pe care le oferă clinică.

La pornire, aplicația prezintă meniul principal al utilizatorului, observându-se în figura 3 o listă

a tuturor funcționalităților. Interfața este minimalistă și ușor de navigat.

8
 Figura 3 Pagini Aplicație Regina Maria

3.1.2 Medicover
Medicover este un furnizor de servicii medicale, aflându-se pe piață din România de 23 de
ani. Compania dispune de o rețea de 37 de clinici în 14 județe, dar și de peste 200 de clinici
partenere și două spitale. În prezent există peste 70.000 de abonați, 70% dintre
abonamentele de sănătate fiind plătite de către companii pentru angajați.

Medicover a dezvoltat o aplicație mobilă pentru sistemele de operare Android și iOS. Conform
site-ului clinicii 2 , aplicația prezintă următoarele funcționalități: programarea la consultații,
accesarea rezultatelor analizelor medicale din trecut, adresarea de întrebări către medici prin
intermediul unui chat, cât și un istoric al vizitelor la clinică.

În figura 4 sunt evidențiate paginile principale ale aplicației. Pagina de start este una simplă,
intuitivă, prezentând un meniu prin care utilizatorul poate naviga în restul aplicației.

2
https://www.medicover.ro/ghidul-medicover/aplicatia-mobila/

9
 Figura 4 Pagini Aplicație Medicover

3.1.3 STATUS
Competitorul direct al aplicației prezentate în lucrarea de diplomă este STATUS 3 , fiind o
aplicație generală, neaparținând unei clinici private, prin care doctorii și pacienții pot
interacționa. Aceasta oferă patru profiluri principale: pacient, furnizor de servicii medicale,
companie de asigurări de sănătate și doctor.

Avantajul aplicației STATUS pentru pacienți este că oferă o baza de date comună cu întreg
istoricul medical al utilizatorilor, independent de clinică în care consultațiile sau analizele au
fost efectuate. În plus, pacientul își poate monitoriza ușor analizele cu ajutorul graficelor
realizate de către aplicație. De asemenea, în cazul nevoii unei consultații rapide, utilizatorul
poate intra în contact cu un cadru medical direct din aplicație prin intermediul unui chat. Un
alt avantaj al acestei aplicații este relevat de adaptabilitatea acesteia, oferind un jurnal prin
care utilizatorul își poate ține evidența simptomelor infecției COVID-19. Funcționalitățile
prezentate pot fi observate în figura 5

3
https://www.status-online.com/ro

10
 Figura 5 Pagini Aplicație STATUS

3.2 Tehnologii multiplatformă versus native

Primul pas în dezvoltarea aplicației este deciderea asupra tehnologiei folosite. Echipa a
hotărât utilizarea unei tehnologii multiplatformă în locul realizării a două aplicații native,
pentru Android, respectiv iOS.

Avantajele unei astfel de alegeri poate fi argumentată de următorii factori. În primul rând,
timpul de lansare al aplicației ar fi cu mult redus. Resursele și intervalul de timp necesar
pentru crearea unei aplicații multiplatformă vor fi diminuate, dar și mai eficient utilizate din
punct de vedere financiar, în comparație cu realizarea a două aplicații independente.
Deoarece bugetul este cel care subvenționează proiectul respectiv, dacă acesta nu este
suficient de mare pentru a crea două aplicații native, o singură aplicație multiplatformă poate
reprezenta un beneficiu important, în special pentru companiile start-up.

În al doilea rând, ea va facilita o acoperire mai largă a publicului. Aplicațiile multiplatformă

pot ajunge la un public mai larg decât o aplicație nativă, indiferent de calitatea experienței
oferite.

De asemenea, ea reprezintă o alegere bună pentru aplicațiile ușor de construit, dacă

arhitectura aplicației, precum și designul interfeței cu utilizatorul sunt simple.

3.3 Tehnologii multiplatformă disponibile

3.3.1 React Native

React Native este un framework de JavaScript ce randeaza aplicațiile mobile multiplatformă
în mod nativ. Framework-ul are la bază React, biblioteca de JavaScript creată de Facebook
pentru realizarea interfețelor de utilizator.

11
Majoritatea codului poate fi distribuit între platforme, astfel, realizarea simultană a unei
aplicații Android și a uneia iOS devine facilă. React Native suportă momentan doar
dezvoltarea aplicațiilor iOS și Android, dar are un ridicat potențial de extindere și către alte
platforme.

Aplicațiile dezvoltate cu React Native sunt realizate prin combinarea JavaScript cu o extensie
de sintaxă a acestuia, numită JSX, asemănătoare cu XML. JSX a fost creat cu scopul de a
optimiza codul în timpul compilării, codul generat rulând mult mai rapid decât un cod
echivalent scris exclusiv în JavaScript.

View 4 este componenta indispenasbilă a React Native pentru crearea unei interfețe de
utilizator, fiind un container care suportă modificarea aspectului și funcționalității sale prin
folosirea a diverse componente precum cele de stil, de aliniere sau de accesibilitate.

3.3.2 JavaScript
JavaScript este un limbaj de programare procedurală, suportând și programarea orientată pe
obiect folosind conceptul prototipurilor. Acest limbaj este cel mai des utilizat în scriptarea
paginilor web permițând implementarea caracteristicilor complexe precum conținutul care se
actualizează dinamic, animarea imaginilor sau controlul multimedia.

Tehnologiile web standard sunt create cu ajutorul a 3 limbaje: HTML, CSS și JavaScript.
Acestea sunt considerate că fiind mai multe straturi dintr-un întreg. JavaScript reprezintă
stratul cel mai de jos, ocupându-se în mare parte de funcționalitățile programului.

Limbajul prezintă caracteristici aparte. Fiind slab tipat, variabilele nu sunt definite cu tipuri,
funcțiile nu au tip de retur, iar parametrii nu au tipul afișat. De asemenea, ordinea în care sunt
definite funcțiile nu este relevanță deoarece JavaScript este un limbaj interpretat.

3.3.3 Ionic
Ionic este un SDK open-source creat de către Drifty pentru dezvoltarea aplicațiilor mobile
hibride. Acesta a fost lansat în 2013, prima versiunea fiind compatibilia doar cu AngularJS și
Apache Cordova. Versiunile mai noi realizează integrarea și cu alte framework-uri pentru
interfață precum Angular, Vue.js sau React, dar permit și folosirea sa de sine stătătoare, fără
a utiliza vreun framework. Ionic prezintă o bilbiotecă vastă de front-end, oferind șansa
construirii unor interfețe de utilizator performante și cu design plăcut. Acesta utilizează
tehnologii web precum CSS, HTML5 sau Sass.

Ionic este una dintre cele mai populare tehnologii pentru dezvoltarea aplicațiilor
multiplatformă, existând peste 5 milioane de programatori din peste 200 țări ce îl utilizează.
Popularitatea ridicată este datorată în mare parte de faptul că programatorii web, având deja
experiență de lucru în tehnologiile utilizate de Ionic, pot face trecerea uşor la dezvoltarea
aplicațiilor mobile multiplatformă.

4
https://reactnative.dev/docs/view

12
De asemenea, la fel ca majoritatea tehnologiilor multiplatformă populare, Ionic permite
dezvoltarea aplicațiilor utilizând o singură bază de cod, reducând semnificativ cantitatea și
timpul de lucru ale programatorilor.

3.3.4 HTML & HTML5

HTML este un limbaj de marcare folosit pentru a aplica convenții de aspect și formatare a unui
document text. Acesta face textul interactiv și dinamic, având, de exemplu, posibilitatea să îl
transforme în imagini, tabele sau link-uri.

HTML a fost creat în anul 1989 de către Tim Berners-Lee ca soluție a problemei de comunicare
întâmpinată de către oamenii de știință aflați în diferite zone ale globului, aceștia fiind nevoiți
să trimită un număr semnificativ de date în format electronic. Majoritatea funcţionalităţilor
se puteau regăși și în alt limbaj, numit SGML, dar HTML s-a remarcat prin crearea de „linkuri
hypertext”, permițând o legătură rapidă între documentele de pe internet.

HTML5 este cea mai nouă revizuire a limbajului de marcare HTML, dezvoltat de către World
Wide Web Consortium. Principala funcționalitate a acestui limbaj este suportul nativ audio și
video în browser, nemaifiind nevoie ca acestea să utilizeze alte plug-in-uri. Această alegere a
fost făcută datorită dezvoltării continue a pieței de telefonie mobilă deoarece nu existau plug-
in-uri valabile și pentru telefoane.

3.3.5 CSS
Cascading Style Sheets(CSS) este un standard creat pentru formatarea unor documente scrise
în limbaje de marcare precum HTML, XML sau diferite dialecte ale acestuia. CSS este unul din
cele trei tehnologii de bază utilizate pentru dezvoltarea Web, alături de JavaScript și HTML.

Scopul limbajului este de a crea o separație dintre aspect și conținut. Acesta interacționează
cu elementele HTML și specifică stilul documentului prin elemente precum așezarea în pagină,
fontul textului sau culorile utilizate.

Prima versiune de CSS, Cascading Style Sheets level 1, a fost lansată în Decembrie 1996 ca o
recomandare a Wide Web Consortium. În această versiune, CSS era descris ca pur și simplu
un model de formatare vizuală a tagurilor HTML.

3.3.6 Xamarin
Xamarin este o platformă open-source utilizată pentru realizarea de aplicații performante
pentru iOS, Android și Windows cu ajutorul framework-ului .NET. Xamarin împarte 90%5 din
codul aplicațiilor în cadrul tuturor platformelor mobile, oferind posibilitatea programatorilor
de a scrie întregul cod într-un singur limbaj de programare, C#, reducând costurile dezvoltării,
dar și timpul finalizării aplicațiilor.

Având la baza sa framework-ul .NET, Xamarin se ocupă automat de anumite sarcini precum
alocarea și eliberarea memoriei, dar și interoperabilitatea cu alte platforme. Totodată,

5
https://docs.microsoft.com/en-us/xamarin/get-started/what-is-xamarin

13
platforma permite utilizarea de biblioteci ce aparțîn altor limbaje precum Objective-C, C, C++
sau Java, profitând astfel de biblioteci dezvoltate pentru aplicații native.

Aplicațiile Xamarin.Android compilează din cod C# într-un limbaj intermediar, care este la
rândul său compilat „Just-in-Time” în cod nativ de asamblare. Pe de altă parte, aplicațiile
Xamarin.iOS sunt compilate „Ahead-of-Time” din cod C# direct în cod nativ de asamblare.

3.3.7 C#
C# este un limbaj de programare orientată pe obiect, open-source, puternic tipat, lansat de
către Microsoft în 2001, utilizat pentru crearea de aplicații performante și robuste în
ecosistemul .NET. Sintaxa limbajului are influențe din C++, Java și Pascal.

C# este un limbaj multiplatformă, fiind utilizat pentru dezovltarea aplicațiilor pe Windows,

Linux, Mac și alte platforme. Acest limbaj interzice conversiile de tipuri, fiind susceptibile la
erori precum pierderea de date, codul devenind mai sigur.

Limbajul este recunoscut pentru eficiența sa. Managementul memoriei este automat,
eliberând programatorii de responsabilitatea de a aloca și elibera memoria manual. Totodată,
codul C# este compilat într-un limbaj intermediar, standard, independent de sistemul de
operare sau de arhitectura sistemului.

3.3.8 Flutter
Flutter este un „Software Development Kit”(SDK) open-source, creat de Google pentru a
dezvolta aplicații mobile, desktop și web utilizând același cod. Flutter a fost lansat oficial în
Decembrie 2018 și a prins rapid popularitate în rândul programatorilor datorită performanței
ridicate și a design-ului natural, comparabile cu cele ale aplicațiilor native.

Ideea principală din spatele Flutter este reprezentată de utilizarea widgeturilor. Combinând
diferite widgeturi se ajunge la construirea unor interfețe de utilizatori complexe. În Flutter
orice este un widget, de la elementele structurale la cele stilistice sau de aspect, acoperind
astfel aproape toate aspectele dezvoltării. Pe lângă varietatea mare de widgeturi oferite de
Flutter, acesta permite de asemenea și crearea lor de la zero.

Arhitectura Flutter oferă și funcția de „Hoț reload”. Această relevă posibilitatea de a vedea
modificările codului asupra aplicației în timp real, micșorând astfel din timpul de lucru,
totodată mărind și productivitatea programatorului.

3.3.9 Dart
Dart este un limbaj de programare orientată pe obiecte, creat de Google în scopul dezvoltării
aplicațiilor rapide pe diverse platforme. Acest limbaj este cel mai des utilizat împreună cu
Flutter SDK în vederea realizării aplicațiilor multiplatformă.

14
Dart este un limbaj care acceptă atât stilul slab tipat, cât și pe cel puternic tipat. Limbajul
prezintă și „sound null safety”6, o proprietate prin care valorile nu pot fi niciodată nule decât
dacă este specificat explicit de către programator.

Tehnologia compilatorului Dart permite rularea codului pentru aplicații mobile și desktop în
modul nativ, incluzând o mașînă virtuală ce oferă atât compilare „just-in-time”(JIT), cât și
compilare „ahead-of-time”(AOT) pentru a produce cod mașină.

3.4 Compararea tehnologiilor

3.4.1 Performanţă
Metricile prezentate mai jos sunt preluate din studiul „An empirical investigation of
performance overhead in cross-platform mobile development frameworks”( Biørn-Hansen,
et al., 2020).

Nu au fost găsite studii relevante care să includă și tehnologia Xamarin, astfel, platforma a
fost omisă în testele de performanță

3.4.1.1 Timpul de completare

Timpul de completare reprezintă durata dintre apelul unei funcții de pe front-end și răspunsul
primit. Răspunsurile sunt observate în figura 5, unitatea de măsură fiind milisecunda.

Figura 6 Tabel Timp de completare Biørn-Hansen

Dintre aplicațiile multiplatformă, Flutter răspunde cel mai rapid în medie, cu rezultate de
aproape două ori mai bunedecât React Native și de aproximativ 3 ori mai bune decât Ionic.

3.4.1.2 Utilizarea memoriei RAM

Figura 6 relevă utilizarea memoriei în megabytes în timpul rulării testelor de performanţă.

6
https://dart.dev/null-safety

15
 Figura 7 Tabel Utilizarea memoriei RAM Biørn-Hansen

Rezultatele acestui studiu arată că React Native utilizează cel mai eficient memoria, având de
asemenea și cele mai consistente rezultate, abaterea standard(SD) fiind cea mai mică.

Totuși, analizând diferența dintre memoria utilizată atunci când aplicația rulează și atunci
când aceasta este inactivă, Flutter consumă cea mai puțînă memorie în plus, după cum se
poate observa în figura 7.

Figura 8 ComputedRAM Biørn-Hansen

3.4.1.3 Performanta CPU

Performanța CPU este relevată în figura 9 calculând procentul de putere de procesare
consumat de către aplicație în timp ce aceasta rulează.

Figura 9 Tabel Performanţă CPU Biørn-Hansen

16
Toate tehnologiile au o performanță asemănătoare, însă Flutter are cele mai bune și
consistente rezultate.

3.4.2 Reutilizarea codului

Reutilizarea codului reprezintă un avantaj al tehnologiilor multiplatformă, permițând astfel
un timp de lansare al produsului semnificativ mai scurt.

3.4.2.1 Flutter
Flutter permite un procent ridicat al reutilizării, acesta având posibilitatea să folosească atât
sisteme de design care oferă un aspect nativ aplicațiilor iOS sau Android, cât și unul adaptabil
care poate fi folosit pentru ambele sisteme de operare,numit „Material Design”7.

3.4.2.2 React Native

React Native oferă de asemenea componente ce pot fi utilizate de sistemele de operare în
mod implicit, având astfel un procent ridicat al reutilizării codului, ajungând până la peste
90%.

3.4.2.3 Ionic
Ionic permite cea mai mare reutilizare a codului dintre toate platformele, procentul ajungând
până la 98%. Acest fapt este datorat conceptului de a crea o aplicație web care poate
funcționa pe orice tip de platformă, având numele de „Progressive Web App”.8

3.4.2.4 Xamarin
Codul scris în C# poate fi reutilizat pe Android, Windows și iOS, cu ajutorul Xamarin.Forms9,
atât timp cât există aceleași funcționalități pe toate sistemele de operare. Reutilizarea codului
poate ajunge până la 96%.

3.4.3 Popularitate in randul programatorilor

Stack Overflow este un site web cu peste 14 milioane de utilizatori, creând cea mai mare
comunitate online de programatori. În fiecare an, un chestionar intitulat „Developer Survey”10
este oferit membrilor cu scopul de a colecta informații despre utilizatorii acestei comunități,
dar și pentru a observa tendințele pieței.

În „2020 Developer Survey”, la categoria pentru cele mai populare Framework-uri, React
Native este cea mai populară tehnologie multiplatformă pentru dezvoltarea aplicațiilor
mobile, fiind folosită de către 11.8% dintre utilizatorii site-ului. Pe locul 2 se află Flutter, cu
6.6%, iar, pe următorul loc, Xamarin cu 6.0%, după cum poate fi observat în figura 9.

7
https://material.io/design/introduction
8
https://ionicframework.com/pwa
9
https://docs.microsoft.com/en-us/xamarin/get-started/what-is-xamarin-forms
10
https://insights.stackoverflow.com/survey/2020#technology-platforms-professional-developers5

17
 Figura 10 „Other Frameworks, Libraries, and Tools”11

La categoria pentru cele mai bine cotate limbaje de programare, limbajele principale utilizate
de programele multiplatformă disponibile, Dart, C# și JavaScript au avut o poziție
asemănătoare în clasament, avantajul fiind cel al limbajului creat de Google. [Figura 1112]

3.4.4 Alegerea tehnologiilor

În urma analizelor prezentate anterior a fost luată decizia de a dezvolta aplicaţia mobilă
utilizând SDK-ul Flutter. Această tehnologie a avut cele mai bune rezultate şi detine o
comunitate numeroasă şi activă. În plus, Flutter oferă o documentaţie detaliată şi bine
structurată, atrăgând astfel numeroşi programatori începători.

Principalul dezavantaj al acestei tehnologii este performanța sub media celorlalte platforme
atunci când aplicația conține un număr ridicat de animații, dar, având în vedere că MediBlock
urmărește dezvoltarea unei interfețe simple, această problemă poate fi ignorată.

4 SOLUȚIA PROPUSĂ
4.1 Arhitectura MediBlock
Arhitectura aplicației a fost realizată în urma ședințelor cu echipa și mentorii din programul
Innovation Labs. Ideea principală a constat în dezvoltarea a două componente diferite legate
la același back-end, una dintre ele fiind proiectată pentru a fi folosită de către medici, iar cea
de-a doua de către pacienți. Scopul principal al acesteia este de a fi ușor de utilizat și cât mai
intuitivă, dar și de a conține doar funcționalitățile de bază, evitând astfel scăderea
performanței sau obținerea unui program care să ocupe prea mult spațiu de stocare.

11
https://insights.stackoverflow.com/survey/2020#technology-other-frameworks-libraries-and-tools
12
https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages

18
 Figura 12 Arhitectura întregii aplicaţii

Componenta mobilă a aplicației comunică cu back-endul prin intermediul Internetului,

făcând cereri HTTP pentru a verifica și autentifica utilizatorii, iar mai apoi pentru a
recepționa datele pacienților. Pentru o experiență a utilizatorului calitativă, Flutter dispune
de diferite pachete, precum Flutter Session. Acesta oferă posibilitatea unui utilizator de a
rămâne conectat in aplicație fără a introduce credențialele de fiecare dată când dorește să
se autentifice. Totuși, pentru păstrarea datelor în siguranță, programul folosește și pachetul
“Local Auth”, permițând astfel conectarea cu ajutorul amprentei.

În plus, există pachete cu rol de a eficientiza sarcinile programatorilor. Flutter Secure

Storage este un modul prin care datele sunt stocate sigur, acestea fiind întâi criptate și după
salvate ca o pereche “cheie-valoare”.

4.2 Diagramă de activitate

Diagrama de activitate este o variantă a diagramei de stare, scoțând în evidenţă controlul
execuţiei de la o activitate la alta pas cu pas, pentru o mai bună înțelegere a unor procese
complexe.

Figura 13 prezintă o aplicație cu un flux de lucru simplu, liniar, gândit pentru a putea fi utilizat
cu ușurință de orice individ, indiferent de nivelul de pricepere atunci când vine vorba de
tehnologie.

19
 Figura 13 Workflow pentru partea mobilă a aplicației

4.3 Structura aplicației mobile

Pentru a putea separa funcționalitatea de design, dar și pentru a putea reutiliza codul eficient,
programul a fost împărțit în servicii, componente și ecrane.

4.3.1 Componente
Componentele sunt bucăți de cod ce creează elemente ale interfeței, cu principalul scop de a
putea fi reutilizate în interiorul programului. Flutter oferă o gamă variată de componente în
mod implicit, intitulate „Material Components widgets” 13 , prezentând, de asemenea, și
oportunitatea de a crea componente personalizate printr-o îmbinare a mai multor widgeturi
oferite de către SDK.

Aplicația MediBlock utilizează 7 componente personalizate, acestea fiind icoane, butoane sau
alte elemente de design care apar în program în repetate rânduri, oferind coerență aplicației.
După cum se observă in figura 14, programul prezintă 2 componente generale, găsite pe
majoritatea ecranelor, dar și 5 care sunt utilizate doar pentru calculatorul de indice de masă
corporală.

13
https://flutter.dev/docs/development/ui/widgets/material

20
 Figura 14 Listă Componente și Exemple

4.3.2 Servicii
Serviciile reprezintă seturi de funcționalități software care pot fi utilizate pentru îndeplinirea
scopurilor prevăzute. În cadrul dezvoltării aplicației au fost implementate 4 servicii, iar, în
plus, pentru a putea folosi autentificarea cu ajutorul datelor biometrice, a fost utilizat api-ul
„Local Auth”, oferit de Flutter. Aceste servicii sunt evidențiate în figura 15.

Figura 15 Servicii

4.3.2.1 Autentificare
Serviciul intitulat “AuthService” se ocupă de înregistrarea sau autentificarea utilizatorilor în
aplicație, făcând cereri HTTP către back-end. Sunt oferite 2 funcții, denumite “login” și
“register” care au ca parametri informațiile completate de către utilizator în formularele
pentru crearea unui cont nou sau pentru conectarea într-un cont existent. Metodele fac cereri
de tip “GET” primind apoi un răspuns pozitiv sau negativ de la server. În plus, în urma unei
autentificări reușite, server-ul întoarce și un token JWT care va fi utilizat de-a lungul sesiunii.

4.3.2.2 Obținere date pacienți

Datele pacienților sunt obținute efectuând cereri HTTP autorizate cu token-ul JWT returnat în
momentul autentificării în aplicație. De asemenea, acest serviciu preia datele în format JSON
și le prelucrează pentru a putea fi afișate apoi pe pagina pacientului.

4.3.2.3 Generare QR
“Generate QR” preia un url care, la accesare, prezintă datele medicale pacientului. Acest url
are ca parametru id-ul utilizatorului, preluat după ce token-ul JWT a fost decodificat. Adresa
este apoi convertită într-un cod QR, înlăturând astfel practica de a partaja informații sensibile

21
printr-un e-mail. Mai mult, valabilitatea acestor date este temporară, codul QR expirând după
o zi. Figura 16 relevă codul de bare generat.

Figura 16 Cod QR generat

4.3.2.4 BMI Calculator Brain

Funcția preia datele completate de către utilizator pe ecranul “Bmi_Input_Page” și transmite
înapoi valoarea rezultată în urma unui calcul matematic bazat pe formula standard de
măsurare al indicelui de masă corporală (1).
𝑔𝑟𝑒𝑢𝑡𝑎𝑡𝑒(𝑘𝑔)
2
(1)
î𝑛ă𝑙ț𝑖𝑚𝑒(𝑐𝑚)
( )
100

4.3.3 Modele
Am creat o clasă care să rețină informațiile despre utilizator, acestea fiind primite in format
JSON după ce a fost făcută o cerere de tip GET. Datele sunt apoi structurate aici pentru o
utilizare mai facilă în restul codului, fiind nevoie de acestea pe mai multe ecrane.

4.3.4 Ecrane
Ecranele sunt la rândul lor create din mai multe componente, întregul rezultat fiind interfața
pe care utilizatorul o va folosi. Aplicația prezintă 7 ecrane, relevate în figura 17.

Figura 17 Ecrane
22
 • Welcome - pagina de start a aplicației în care utilizatorul poate alege dacă vrea sa se
înregistreze sau să iși acceseze contul;
• Register_Page - Pagina este utilizată pentru crearea unui un cont nou;
• Login_Page - Pagina permite autentificarea în aplicație folosind e-mailul și parola;
• User_Page - După introducerea unor credențiale valide, utilizatorul va fi
redirecționat pe pagina sa, având un meniu în bara lateral cu restul ecranelor pe care
le poate accesa;
• Bmi_Input_Page - Ecran în care se poate calcula indicele de masă corporală;
• Bmi_Result_Page - Pagina în care vor fi afișate rezultatele calculatorului BMI;
• Settings_Page - Permite activarea unor preferințe precum autentificarea cu date
biometrice, acordul de a primi notificări sau modificarea temei aplicației;
• Medical_Records_Page - Oferă informații cu privire la datele medicale ale
utilizatorului.
• Charts_Page – Sunt afișate graficele analizelor de sânge.

4.4 Alegerea paletei de culori

Studiul culorilor si impactul acestora asupra vietilor indivizilor au fost timp îndelungat
subiecte de cercetare pentru oamenii de stiinta. Intr-un studiu realizat de Sarah E. Babin
(2013), rezultatele experimentului au demonstrat o conexiune intre culoare și dispoziție,
astfel determinând o paletă de culori utilizată într-un mediu medical, cu care populația ar fi
cea mai confortabilă. Deoarece culorile au o acoperire profundă în psihologia publicului,
alegerea schemei potrivite de nuanțe pentru interfața aplicației a fost făcută considerând
descoperirile din studiul menționat anterior. În primul rând, paleta de culori trebuie să fie
echilibrată. Aceasta înseamnă că nu poate exista surplus de culoare și nici o gamă de nuanță
neutră nu poate prelua spectrul. Tonurile mai reci, cum ar fi albastru și verde, sunt
recomandate pentru efectul calmant și confortabilitatea pe care le oferă pacienților.
Combinația dintre aceste tonuri naturale și culori reci poate face un spațiu să pară curat și
controlat. Acestea fiind spuse, schema aleasă pentru aplicație constă in albastru-verde-alb.
Pentru pacienții cu sensibilitate la lumină, a fost creat “dark mode”, înlocuind albul cu negru
și albastru cu violet deoarecele majoritatea utilizatorilor cu această problemă sunt persoane
în vârstă. ,,De obicei, adulții mai în vârstă au nevoie de ochelari de lectură pentru a vedea
distanțe apropiate și sunt mai sensibil la strălucire. Vederea culorilor rămâne destul de
normală, dar obiectivul (corneea) ochiului se ingalbeneste treptat. Aceste modificari duc la
schimbări în percepția culorii. Albastrul și verdele par mai asemănătoare; albastrul arată mai
întunecat, iar violetul apare mai mult ca roșul. Viziunea nocturnă scade pe măsură ce lansetele
primesc mai puțină lumină, ceea ce rezultă, de asemenea în mai multă împrăștiere a luminii
și sensibilitate redusă.” (Portillo, 2009: 144)

23
5 DETALII DE IMPLEMENTARE
5.1 Etapele dezvoltării
Prima etapă a presupus crearea unui logo și alegerea unei scheme de culori potrivite. După o
perioadă de studiu a cerințelor utilizatorilor, a fost programată o sesiune în care membrii
echipei au prezentat propunerile lor. În final, s-a decis în unanimitate utilizarea unei scheme
din trei culori pentru tema principală, compusă din albastru, alb și verde, iar, pentru cea
întunecată, primele două culori au fost înlocuite cu negru și violet. De asemenea, logo-ul ales
a fost cel creat de Irina Terente, vizibil în figura 18.

Figura 18

Următorul pas l-a reprezentat planificarea interfeței pentru partea mobilă a aplicației. S-a
urmărit în primul rând ca aceasta să fie cât mai ușor de înțeles, astfel că am optat pentru
pagini simple, cu puține butoane și care oferă un număr limitat de funcționalități, evitând
confuziile. Inițial, a fost creat design-ul pentru pagina de start şi cele de autentificare, iar,
adițional, au fost realizate și cele două teme.

Primul impediment întâlnit a fost încercarea de a schimba tema aplicației în timpul unei
sesiuni active. Pentru a înlocui pachetul de culori a fost utilizată o variabilă de tip Boolean
care își modifica valoarea o dată cu apăsarea unui buton. Deși acesta era apăsat și valoarea
variabilei se schimba, tema rămânea aceeași ca în momentul pornirii aplicației. Soluția
descoperită a fost utilizarea widgetului StreamBuilder14. Acesta primește un flux de
evenimente și își modifică starea cu fiecare eveniment nou. Am creat un flux de date de tip
Boolean, prezentat în figura 19. Pentru a putea porni aplicația fără probleme, valoarea
inițială fluxului este starea programului în momentul în care utilizatorul l-a închis ultima
oară.

Figura 19 StreamBuilder

În continuare, a fost creat serviciul de autentificare, pentru a avea certitudinea că integrarea

cu back-endul este posibiliă. În interesul îndeplinirii obiectivului, a fost utilizat pachetul

14
https://api.flutter.dev/flutter/widgets/StreamBuilder-class.html

24
Dio15, un client HTTP pentru limbajul Dart. În figura 20 este evidențiată funcția de conectare
în aplicație. Răspunsul cererii de tip POST va conține un cod de stare, iar, dacă acesta este
pozitiv, în răspuns va exista și un token JWT care va fi utilizat pentru autorizarea
următoarelor cereri. Token-ul este salvat cu ajutorul “Flutter Secure Storage” deoarece este
o informație importantă și trebuie păstrată cât mai sigur.

Figura 20 Snippet Login

Ulterior, au fost efectuate interfețele celorlalte pagini. Au fost întâmpinate dificultăți în

incercarea de a-i oferi utilizatorului opțiunea de a avea o poză de profil. Utilizând pachetul
ImagePicker16, a fost necesară utilizarea unei poze temporare, pe post de “buffer”, până
când utilizatorul o alegea pe cea dorită din galerie. În lipsa acestei poze “buffer”, aplicația nu
putea să ruleze, generând erori. Pentru a soluționa problema, a fost nevoie de a adăuga o
imagine de tip “User Avatar” în directorul ce conține și restul resurselor precum logo-ul sau
font-ul textului, mărind astfel spațiul de stocare a componentei mobile. Lista acestor
resurse este observată în Figura 21.

Figura 21 Director Resurse

Pe urmă, am realizat mecanismul de rutare. Widgetul Navigator este oferit implicit de

Flutter și prezintă o modalitate ușoară de traversare de la o pagină la alta. Widgetul are

15
https://pub.dev/packages/dio
16
https://pub.dev/packages/image_picker

25
opțiunea de a furniza nume rutelor, fiind mai ușoară referirea acestora în cod. În figura 22 se
pot observa rutele pentru ecranele aplicației mobile.

Figura 22

Următoarea etapă a fost reprezentată de înfăptuirea celorlalte trei servicii și anume cel de
obținere a istoricului medical al pacientului, calculatorul indicelui de masă corporală și
generatorul de cod QR.

Implementarea celui dintâi a constituit un obstacol deoarece, încercând descărcarea datelor

într-un mod asincron și asteptând după răspunsul cererii de tip GET, a fost necesară
folosirea widgetului FutureBuilder17. Acesta permite construirea unui widget în viitor, după
ce datele necesare au fost obținute. În momentul în care un câmp de date lipsește, acesta va
fi înlocuit cu un String “_” la momentul afișării pe ecran pentru buna funcționare a
programului.

Pentru a realiza tabelul ce investighează analizele de sânge, a fost utilizat pachetul

“fl_chart”18, oferind o interfață plăcută și accesibilă. Datele folosite pentru crearea tabelului
au fost preluate cu ajutorul serviciului prezentat anterior.

În final, ultima sarcină a constituit-o elaborarea paginii de setări, prin care utilizatorul își
poate personaliza experiența în cadrul aplicației. Provocarea a fost reținerea setărilor alese
de către utilizator, acestea revenind la modul implicit o dată cu repornirea aplicației. Soluția
a fost utilizarea pachetului “Shared Preferences”19 care stochează datele sub forma unor
perechi cheie-valoare. Același pachet a fost folosit și pentru a putea păstra poza de profil
aleasă de către utilizator.

6 SCENARIU DE UTILIZARE
O dată cu lansarea aplicației, utilizatorul va observa o pagină simplă, în mijlocul căreia se află
logo-ul MediBlock, după cum se poate observa în figura 23. Ajungând la următorul ecran,
utilizatorul are două variante: înregistrare sau autentificare.

17
https://api.flutter.dev/flutter/widgets/FutureBuilder-class.html
18
https://pub.dev/packages/fl_chart
19
https://pub.dev/packages/shared_preferences

26
 Figura 23 Pagină de Start

Figura 24 relevă faptul că pentru crearea unui cont nou, pe lângă un e-mail valid și alegerea
unei parole, este nevoie de date personale precum CNP-ul, numele, prenumele, numărul de
telefon și data nașterii.

Figura 24 Creare Cont

După ce contul a fost creat, autentificarea se face prin e-mail și parolă, iar, după prima
înregistrare, devine disponibilă și autentificarea cu date biometrice, fapt sugerat de figura 25.

27
 Figura 25 Autentificare

Pagina utilizatorului prezintă informații de bază despre pacient, cum ar fi numele, vaccinuri
făcute în ultimu an, alergii, grupa sanguina și, dacă există, afecțiuni importante. În figura 26
este vizibil și un meniu prin care utilizatorul poate accesa restul paginilor din aplicație. De
asemenea, utilizatorul are opțiunea de a-și alege o poză de profil, apasând pe imaginea
circulară din meniu, fiind redirecționat către galeria de fotografii a telefonului pentru a putea
alege o nouă imagine.

Figura 26 Meniu Utilizator

Cu scopul de a prezenta și restul funcționalităților, se va presupune că utilizatorul a avut cel

puțin o vizită medicală, informațiile fiind prezentate în figura 27.

28
 Figura 27

“Medical Records” este funcționalitatea principală a aplicaţiei. Pe pagina afișată in figura 28

este prezent istoricul medical al pacientului, observându-se diagnosticul și tratamentul oferit
de doctorul care l-a consultat.

Figura 28 Istoric medical

“Charts” evidențiază într-un mod clar evoluția rezultatelor analizelor unui individ, oferind
posibilitatea doctorilor de a putea observa potențiale nereguli și de a preveni o înrăutățire a
situației. Un grafic ce măsoară fibrinogenul poate fi vizualizat în figura 29.

29
 Figura 29 Grafic

Pagina “BMI Calculator” oferă posibilitatea utilizatorului de a-și calcula indicele de masă
corporală, acesta fiind un indicator al grăsimii corporale pentru majoritatea persoanelor.
Calculatorul este folosit pentru a identifica acele categorii de greutate care pot duce la
probleme de sănătate. Interfața este intuitivă, fiind prezent un glisor pentru înălțime, dar și
butoane pentru greutate și vârstă, după cum se poate constata în figura 30.

Figura 30 Calculator BMI

“Settings” este pagina prin care utilizatorul își poate personaliza experiența. Pe acest ecran
sunt prezente butoane de comutare, prin care utilizatorul poate activa sau dezactiva funcții
precum primirea notificărilor pe e-mail, utilizarea amprentei pentru autentificare sau
schimbarea din tema implicită în cea întunecată. Diferența cromaticii este remarcată în figura
31.

30
 Figura 31 Setări

7 EVALUAREA REZULTATELOR
Aplicația a fost testată pe un dispozitiv fizic Samsung Galaxy A12, având versiunea 10 a
sistemului de operare Android, memoria RAM de 4GB și o memorie internă de 64 GB. Pentru
rularea aplicației pe telefon a fost necesară activarea modului “Opțiuni Dezvoltator” și
permiterea depanării prin USB. De asemena, au fost acordate permisiunile accesului pozelor
din galerie, utilizării camerei, dar și folosirii datelor biometrice.

Examinarea aplicației nu poate fi realizată în modul de depanare, astfel, ea trebuie rulată în

“modul profil”, aici fiind disponibile diverse funcționalități în plus ce permit analizarea
problemelor de performanță. Pentru a activa acest mod trebuie creat un fișier json care să
specifice clar felul în care va rula programul. Figura 32 ilustrează fișierul “launch.json”
implementat pentru aplicația mobilă MediBlock.

Figura 32 launch.json

31
7.1 Modul de testare
Pentru testarea aplicației a fost repetat scenariul de utilizare, creând conturi diferite și
accesând fiecare funcționalitate a aplicației pe rând pentru a putea observa dacă aceasta va
oferi rezultate constante.

Primele teste au prevăzut crearea unui cont nou introducând datele în mod corect din prima
încercare, iar restul au fost realizate în așa fel încât toate validările impuse la creare și
autentificare să eșueze initial, pentru a observa comportamentul aplicației în situații limită.

7.2 Instrumente de testare și rezultatele acestora

DevTools20 este o suită de instrumente pentru Dart și Flutter, acoperind categorii precum
inspecția aspectului sau de măsurare a perfomanței și a utilizării memoriei. DevTools rulează
în browser, oferind funcționalități suplimentare care nu sunt practice de afișat într-un IDE.

7.2.1 Performanță
În meniul “Performanță” este prezentă în mod grafic informația despre cadrele din aplicație
și evenimentele efectuate în mod cronologic.

Din graficul aflat în figura 33 se poate observa că aplicația păstrează un număr mediu de 53
de cadre per secundă(FPS), fiind foarte aproape de cele 60 promise de Flutter. În aceeași
diagramă sunt evidențiate cadrele în care programul se mișcă într-un timp mult mai lent decât
în medie. Repetând efectuarea testelor cu opțiunea “Track widget builds” activată, au fost
deduse cele două componente care încetinesc aplicația și anume calendarul din ecranul de
înregistrare împreună cu butonul care schimbă tema acesteia. Atunci când butonul pentru
schimbarea temei este activat, culorile tuturor componentelor din aplicație sunt modificate,
fiind astfel sursa care scade semnificativ performanța programului. Pentru a demonstra
această ipoteză, a fost efectuat un test în care temele au fost interschimbate în continuu.
Rezultatele sunt vizibile in figura 34 unde majoritatea interacțiunilor sunt considerate încete,
iar media a scăzut la 32 de cadre per secundă.

Figura 33 Performanță Scenariu Utilizare

20
https://flutter.dev/docs/development/tools/devtools/overview

32
 Figura 34 Performanță Interschimbare Teme

7.2.2 CPU Profiler

Instrumentul CPU Profiler permite înregistrarea și analizarea unei sesiuni din programul
dezvoltat. Ordonând descrescător după durata fiecărei acțiuni, funcțiile care relevă
funcționalitatea calendarului apar primele, indiferent de sesiunea analizată. Figura 35
evidențiază metodele care au avut cel mai ridicat timp de răspuns.

Figura 35

7.2.3 Memorie
Pagina furnizează informații despre modul în care este folosită memoria la un moment dat.
Sunt colectate statistici de utilizare de la mașina virtuală, fiind afișate în două diagrame:
memoria Dart și memoria Android. Evenimentele petrecute în timpul interacțiunii cu aplicația
sunt colectate împreună cu memoria în aceeași diagramă. Se observă o legend a graficului în
figura 36 pentru a putea interpreta datele. Metricile prezente în grafic relevă consumarea
constantă și parametrii normali a memoriei.

Figura 36 Memorie Dart

33
De altfel, utilizarea memoriei RAM poate fi descoperită cu ajutorul dispozitivului pe care a
fost testată aplicația, relevându-se în figura 37 că programul MediBlock foloseste în medie
115 MB. Utilizarea maximă are o valoare aproape dublă, ajungând la 219MB.

Figura 37

7.2.4 Dimensiunea aplicației

Aplicațiile Flutter ocupă mai mult spațiu decât cele native doarece “motorul” Flutter are
dimensiuni ridicate21. Deși aplicația MediBlock prezintă un număr redus de funcționalități,
este evidențiat în figura 38 că aceasta ocupă în total 78 MB după instalare. Pentru măsurarea
APK-ului, este nevoie de instrumentul “App Size”, regăsit in Dart DevTools. După motorul
aplicației, pachetul implicit Flutter ocupă cel mai mult spațiu de stocare, având 3MB. Figura
39 dezvăluie faptul că pachetele instalate adițional pentru eficientizarea dezvoltării aplicației
ocupă în total mai puțin de 2MB.

Figura 38

21
https://flutter.dev/docs/resources/faq#how-big-is-the-flutter-engine

34
 Figura 39

De asemenea, un alt factor care contribuie la dimensiunea aplicației este dat de stocarea
locală a datelor necesare în comunicarea cu serverul. Mai mult, aplicația reține preferințele
utilizatorului, cum ar fi imaginea de profil aleasă, tema pe care o utilizează, dar și modurile
prin care autentificarea este posibilă.

8 CONCLUZII
Scopul echipei MediBlock a fost definit de încercarea îmbunătățirii sistemului medical din
România, contribuind la digitalizarea acestuia. Componenta mobilă a aplicației MediBlock are
în vedere perfecționarea experienței utilizatorului (UX), prezentând o soluție eficientă și
rapidă pentru verificarea istoricului medical.

Aplicația îndeplinește toate funcționalitățile care au fost propuse în capitolul 2 al acestei

lucrări. În urma testelor de performanță prezentate în capitolul anterior, aceasta a avut
rezultate pozitive și uniforme, fiind astfel pregătită pentru lansarea pe piață.

Programul este receptiv, nu există întreruperi, iar interfața este minimalistă pentru a oferi o
experiență cât mai plăcută utilizatorului, dar și pentru a atrage o audiență cât mai ridicată. Pe
deasupra, dimensiunea aplicației este asemănătoare cu programele concurente prezentate
în capitolul 3, ocupând mai mult spațiu decât Medicover, dar mai puțin decât Regina Maria.

8.1 Dezvoltări ulterioare

Graficele de performanță relevă faptul că trebuie luate măsuri cu privire la widgetul “Date
Picker”, prin care utilizatorul își setează data nașterii utilizând o componentă de tip calendar.
În momentul actual nu există un alt pachet alternativ care poate fi folosit, astfel, o soluție ar
fi implementarea manuală a unei componente formată din trei butoane de tip “drop-down”
care vor avea valori prestabilite.

O dată cu creșterea numărului de utilizatori al aplicației este recomandată creșterea bugetului

pentru testare, fiind nevoie de instrumente specializate pentru a asigura buna funcționare a
programului și a menține satisfacția clienților.

Recenziile și sugestiile aduse de noii utilizatori vor fi un factor important privind actualizările
de interfață sau dezvoltarea unor funcționalități adiționale. Totuși, scopul principal va fi
crearea unui model de predicție pe baza analizelor de sânge pentru a putea preveni potențiale
complicații.
35
 Bibliografie

1. Andreas Biørn-Hansen, C. R. T.-M. G. T. A. M. G. G., 2020. An empirical investigation

of performance overhead in cross-platform mobile development frameworks.

2. Babin, S. E., 2013. Color Theory: The Effects of Color in Medical Environments. 115 ed.
s.l.:Honors Thesis.

3. Health Consumer Powerhouse, 2018. Health Consumer Powerhouse. [Interactiv]

Available at: https://healthpowerhouse.com/media/EHCI-2018/EHCI-2018-index-
matrix-A3-sheet.pd
[Accesat 10 May 2020].

4. Margaret Portillo, P., 2009. Color Planning for Interiors: An Integrated Approach to
Color in Designed Spaces. s.l.:s.n.

36
9 ANEXE

Figura 9 „Most Loved, Dreaded, and Wanted Languages”

37