UNIVERSITATEA POLITEHNICA BUCUREȘTI

FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE

DEPARTAMENTUL CALCULATOARE

PROIECT DE DIPLOMĂ
Aplicație web pentru gestionarea donării de organe
Versiunea 2021

Diana-Ștefania Coman

Coordonator științific:
Conf. Cornel Popescu

BUCUREŞTI

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

DIPLOMA PROJECT
Web application for organ donation’s management
2021 version

Diana-Ștefania Coman

Thesis advisor:
Conf. Cornel Popescu

BUCHAREST

July 2021
CUPRINS
Sinopsis ...................................................................................................................................... 3
Abstract ...................................................................................................................................... 3
1 Introducere ........................................................................................................................ 4
1.1 Context ........................................................................................................................ 4
1.2 Problema ..................................................................................................................... 4
1.3 Obiective ..................................................................................................................... 6
1.4 Structura lucrării.......................................................................................................... 6
2 Analiza și specificarea cerințelor........................................................................................ 7
3 Abordări existente ........................................................................................................... 10
4 Tehnologiile folosite......................................................................................................... 12
4.1 Baza de date .............................................................................................................. 12
4.1.1 MySQL ................................................................................................................ 12
4.2 Tehnologii folosite pe backend ................................................................................. 12
4.2.1 Java..................................................................................................................... 12
4.2.2 Spring Framework .............................................................................................. 13
4.2.3 Hibernate ........................................................................................................... 14
4.2.4 Maven ................................................................................................................ 15
4.2.5 Postman ............................................................................................................. 15
4.2.6 IntellIJ IDEA Ultimate Edition ............................................................................. 16
4.3 Tehnologii folosite pe frontend ................................................................................ 16
4.3.1 ReactJS ............................................................................................................... 16
4.3.2 Semantic UI ........................................................................................................ 17
5 Proiectarea Aplicației ....................................................................................................... 18
5.1 Baza de date .............................................................................................................. 18
5.2 Backend-ul ................................................................................................................. 21
5.2.1 Securitate, gestionarea erorilor, entități DTO ................................................... 22
5.2.2 Controller, Service, Repository, Domain............................................................ 23
5.3 Frontend-ul................................................................................................................ 27
5.3.1 Partea de autentificare ...................................................................................... 27
5.3.2 Navigarea în aplicație ca și Administrator ......................................................... 28

1
 5.3.3 Navigarea în aplicație ca și Pacient .................................................................... 33
6 Detalii de implementare .................................................................................................. 35
6.1 Implementarea pe partea de backend...................................................................... 35
6.2 Implementarea pe partea de frontend ..................................................................... 42
7 Evaluarea rezultatelor ...................................................................................................... 45
8 Concluzii ........................................................................................................................... 47
9 Bibliografie ....................................................................................................................... 48
10 Anexe ............................................................................................................................... 50

2
SINOPSIS
Această lucrare tratează o problemă prezentă în cadrul instituțiilor medicale, și anume
donarea de organe. Întrucât acest proces este unul implică extrem de mulți factori, atât de
natură tehnică, cât și de natură umană, iar timpul este un element extrem de important, se
propune realizarea unei aplicații care automatizeaza procesul de potrivire a celor care
donează organe (numiți în continuare donatori) cu cei care primesc (numiți în continuare
recipienți).

Ca urmare a realizării aplicației, s-a remarcat că automatizarea acestui proces duce la

rezultate eficiente, dar implicarea umană nu se poate elimina complet, deoarece pot
intervenii mulți factori impredictibili. Cu toate acestea, se poate spune că există îmbunătățiri
evidente, așa cum se va vedea pe parcursul acestei lucrări.

ABSTRACT
This paper deals with a problem that is observed in medical institutions, namely organ
donations. As this process involves multiple factors, both on the technical and human side,
and also time is a very important element, the development of an application managing the
automation of the process of matching people who donate organs (called from now on
donors) and people who are waiting for an organ transplant (called from now on recipients)
is expected.
As a result of the application being implemented, it was noticed that the automation of this
process brings efficient results, but human implication cannot be completely erased, because
there are many impredictible factors that may appear. Even so, it can be said that obvious
improvements may be noticed, as we will see during this paper.

3
1 INTRODUCERE
1.1 Context
În ziua de azi, se remarcă din ce în ce mai multe accidente de natură medicală. Aceste
accidente au mai mult sau mai puțin impact asupra pacienților, în destule cazuri ducând chiar
la moartea acestora. Eroarea umană este una dintre principalele cauze ale acestor accidente,
precum este expus în [1] . De obicei, pe lângă vătămarea pacientului, acestea pot provoca și
daune materiale, pierderi de resurse, și pierdere de timp.

Din păcate, în medicină timpul este unul dintre cele mai importante aspecte, absolut vital în
multe situații. Până și câteva secunde pot avea un impact de multe ori hotărâtor asupra unor
evenimente din cadrul medical.

1.2 Problema
În cadrul donării de organe, există o scurtă fereastră în care se poate efectua transplantul de
un donator declarat decedat la un recipient, iar transportul organelor răpește deja destul
timp, potrivit [2].

În primul rând trebuie definit conceptul de donator decedat. Conform [3], un pacient este
declarat mort atunci când nu mai prezintă activitate celebrală. De asemenea, trebuie să existe
dovezi că moartea sa este ireversibilă. Astfel mai mult de 10 minute de inactivitate celebrală
sunt necesare pentru ca un om să fie declarat decedat, cum se poate vedea în [4].

Pentru a lua un exemplu, în cadrul donării unei inimi timpul în care aceasta poate fi donată
este de aproximativ de la 4 până la 6 ore de la declarea donatorului ca fiind mort din punct
de vedere celebral. Timpul acesta însă va include găsirea unui recipient compatibil, aflat în
capul listei de așteptare pentru o eventuală donație, si de asemenea, realizarea unor teste de
compatibilitate, aducerea pacientului care va primi organul în instituția medicală, și operația
propriu zisă. Acest proces este preluat și descris în mod simplificat din [5].

Acest interval scurt nu permite realizarea greșelilor în acest proces, erorile răpind timp prețios
și ducând deseori la expirarea timpului de viabilitate a organului respectiv, astfel încât nu mai
poate fi utilizat.

Mai jos voi prezenta timpul de valabilitate al organelor cu care am lucrat pentru această
aplicație, conform [6]:

 4-6 ore pentru inimă și plămâni

 8-12 ore pentru ficat
 12-18 ore pentru pancreas
 24-36 ore pentru rinichi
 8-16 ore pentru intestine

4
Printre factorii generali după care se potrivesc organele donatorilor cu cele alea pacienților
se numără: grupa de sânge, caracteristicile de măsură ale corpului (înălțime, greutate),
severiatea stării pacientului (numită în continuare prioritate), distanța dintre instituția
medicală de care aparține donatorul și cea de care aparține pacientul care așteaptă donația,
timpul petrecut pe lista de așteptare, dacă pacientul este disponibil (dacă poate fi sau nu
contactat, dacă poate efectua transplantul de organe în timpul alocat). Informațiile
prezentate în acest paragraf sunt preluate din [7] .

Există și criterii specifice fiecărui organ în mod particular. Potrivit [8, 9], în cazul inimilor și al
plămânilor, din cauza timpului foarte redus în care se pot face transplaturile de la moartea
donatorilor, aceste organe se donează pacienților din apropierea spitalului. De asemenea,
pentru aceste organele dimensiunile corpului sunt foarte importante, întrucât trebuie să
permită plasarea acestora comportabil în cutia toracică a pacientului.

Pentru ficat, conform [9], e foarte importantă starea pacientului, deci cât de gravă este
condiția acestuia, dar și factorii geografici, datorită timpului limitat de valabilitate a organului,
și desigur toate celelalte criterii generale.

La rinichi, potrivit [10], apar și alte criterii, trebuie să existe o potrivire între limfocitele
citocotoxice între donator și pacient, dar și o potrivire între antigenii HLA. Mulți rinichi pot sta
în afara corpului până la 36 de ore, așa că zona geografică este bineînțeles mult mai largă
pentru acestia decât pentru celelalte organe care pot fi donate.

În cadrul pancreasului, parametrii sunt cei generali, însă de multe ori transplantul de pancreas
se deșfășoară concomitent cu cel de rinichi, iar în aceste cazuri este bineînteles necesar ca
condițiile pentru potrivirea rinichilor să fie îndeplinite. În cazul tranaplanturilor de rinichi –
pancreas, antigenii HLA au o importanță majoră, conform [11].

Iar nu în ultimul rând, la intestine, potrivit [7], contează ca donatorul să aibă un corp mai mic
din punct de vedere al dimensiunilor ca pacientul recipient, din cauza micșorării cavității
intestinale la cei care așteaptă un astfel de transplant. De asemenea din cauza posibilității
ridicate de apariție a unei infecții, se dorește ca grupa de sânge între donator și pacient să nu
fie doar compatibilă, ci identică. Tot pentru a preveni apariția unei infecții ulterioare, se
recomandă potrivirea pacienților care nu au fost infectați cu cytomegalovirus și/sau virusul
Epstein Barr cu donatorii neinfectați la rândul lor cu aceste două virusuri.

De menționat este și faptul că, în cadrul pacienților care prezintă nevoia unui singur rinichi, a
unui singur plămăn, dar și a celor care au nevoie doar de o parte de ficat, sau doar de o parte
pancreas există posibilitatea donării de organe din partea unei persoane în viață, de obicei o
cunostiință a pacientului, iar potrivirea între cei doi se va face pe baza unor serii de teste,
potrivit [12].

De multe ori, problemele provin din potrivirile greșite realizate de cadrele medicale, în urma
citirii greșite a unor date, a unor calcule realizate greșit sau a ignorării unor situații particulare

5
specifice anumitor pacienți doar. Până când greseala este identificată, iar organul este
redistribuit, acesta poate să nu mai fie viabil, cum s-a menționat și mai sus.

1.3 Obiective
Prin această aplicație de gestionare a donării de organe, se dorește în primul rând
automatizarea procesului de realizare a potrivirii între donatorii de organe și pacienții de pe
lista de așteptare. De asemenea, se vor gestiona și transplanturi specifice (cele în care o
persoană în viață, donează un organ nevital – precum un rinichi, unei persoane cu care are un
fel de relație de rudenie, sau de amiciție).

Pentru potrivirile realizate după moartea donatorului (cele care nu implică o potrivire
specifică), se vor lua în considerare acei parametri prezentați în secțiunea anterioară a lucrării,
și cei generali, și cei specifici fiecărui organ în parte.

De asemenea, aplicația va trebui să aibă funționalități de mentenanță a pacienților bine puse

la pus, astfel încât să fie ușor de folosit, dar să și semnalizeze eventuale nereguli care pot
apărea în folosirea ei.

1.4 Structura lucrării

În continuare, în această lucrare se vor atinge următoarele puncte de referință, încercând să
descrie cât mai bine anumite criterii importante în dezvoltarea aplicației de față:

 O analizare detaliată a cerințelor aplicației.

 Studiul pieței, pentru a identifica eventuale aplicații similare, dar și ce va aduce nou
aplicația curentă
 Descrierea tehnologiei folosite în realizarea aplicației
 Descrierea soluției propuse.
 Detalii de implementare alea aplicației
 Rezultatele obținute.

6
2 ANALIZA ȘI SPECIFICAREA CERINȚELOR
Am realizat un poll pe marginea subiectului licenței mele, pentru a clarifica care sunt grijile
care pot apărea în cazul donării de organe, și specific în cazul automatizării acestui proces, cu
scopul de avea mai multe perspective și a îmbunătății viziunea mea asupra contextului în care
se va forma aplicația.

La întrebarea „Doriți să deveniți donator de organe după moarte?” s-au obținut următoarele
procente:

Figura 2.1 Grafic cu răspunsurile la întrebarea „Doriți să deveniți donator de organe?”

Astfel se remarcă cum majoritatea oamenilor (66.6%) doresc să devină donatori de organe,
25% nu s-au hotărât încă, iar 8.3% au răspuns „Nu” la întrebarea de mai sus.

În continuare, am pus întrebarea „Există elemente care vă îngrijoreaza legat de donarea de

organe? Dacă da, menționați-le mai jos”. Mai mult de jumătate dintre participanți și-au
exprim at oarecare îngrijorare legată de acest proces. Printre îngrijorările celor care au
completat formularul se numără:

 Gestionarea corectă a donatorilor și a beneficiarilor

 Rapiditatea procesului
 Compatibilitatea și timpul de așteptare
 Abuzuri în scopul donării de organe
 Declararea de moarte celebrală a pacienților în comă care își pot reveni apoi
 Daca organele vor ajunge la cei care au nevoie de ele

După cum se poate observa, în general îngrijorările înclină spre eficiența procesului și
corectitudinea acestuia. Bineînteles, oamenii își doresc ca organele să ajungă la pacienți fără
părtinire, fără bias între acestia. De asemenea, procesul trebuie sa fie cât mai eficient posibil,
pentru a asigura maximizarea beneficiilor asupra persoanei care primește organele, dar și a

7
procesului prin care corpul pacientului va accepta organul donat după transplant, în
săptămânile sau chiar lunile după acesta.

Următoarea întrebare din pollul meu se referă la cum ar prefera audiența să se deșfăsoare
procesul de potrivire între donatori și pacienții de pe lista de așteptare.

Figura 2.2 Metoda preferată de potrivire între pacienți și donori

Astfel, se poate vedea cum în principal, oamenii au preferința majoritară (70.8%) ca

gestionarea să fie făcută de o aplicație de gestiune, cu intervenții minimale din partea cadrului
medical, 25% preferă să fie făcută în totalitate de cadrul medical, iar restul de 4.1% nu se pot
pronunța în această privință.

Ultima întrebare din chestionar face referire la motivarea preferinței pentru alegerea
anterioară. Cei care au ales ca gestionarea să fie făcută de o aplicație de gestiune au prezentat
următoarele motive:

 Subiectivitatea care poate apărea la cadrele medicale

 Rapiditatea pe care o implică o gestiune automatizată
 Se poate lucra cu o cantitate mare de date într-un mod eficient
 Elimină corupția care poate apărea din păcate în acest proces
 Elimină erorile pe care le poate face personalul medical autorizat cu acest proces

Motivațiile celor care au ales gestiunea să se realizeze de către cadrele medicale sunt
următoarele:

 Un cadru medical poate avea o anume intuiție care îi lipseste unei aplicații
 Pot aparea factori particulari de risc, specifici unei anumite situații doar
 Pacienții nu pot fi de încredere să-și introducă datele fără greșeli
 Există situații limită în care gândirea critică poate fi vitală

8
În urma părerilor primite, am stabilit că este cel mai bine să construiesc o aplicație care să
mixeze cele două componente oarecum, astfel încât să existe avantaja pe ambele părți.
Aplicația va avea următoarele cerințe:

 Sistemul va fi unul închis, contul fiecărui pacient va trebuie să primească aprobare de

la un administrator (cadru medical)
 Pacientul va avea funcționalități limitate în cadrul aplicației (să-și schimbe emailul de
contact, să-și vadă detaliile și potrivirile)
 Editarea instituțiilor medicale și a pacienților după ce acestea sunt realizate de către
administratori.
 Potrivire în sine vor fi făcute în mod automatizat.
 Mentenanța potrivilor va fi făcută atât automat cât și de către medicale, însă acestea
nu vor avea drepturi să facă schimbări referitoarea la persoanele implicate în acestea
 Potrivirile se vor face după o paletă mare de criterii, care se vor prezenta în secțiunile
următoare, acestea vor diferi puțin și în funcție de organele după care se vor căuta
potriviri
 Fiecare pacient va fi legat de o instituție, și în funcție de aceasta se vor delimita limitele
geografice în care i se vor căuta potriviri.
 Fiecare instituție medicală are specific un oraș, un județ și o regiune din care face
parte, astfel în funcție de timpul de viabilitate al organelor se vor face potriviri ținând
cont de aceste limite.
 Va exista și o funcționalitate pentru donatorii în viață, care doresc să doneze un organ
nevital unei cunostiințe. Acest proces va fi denumit potrivire specifică.

În acest fel, aplicația se definește ca un sistem închis, securizat. Politica de realizare a

potrivirilor între pacienții de pe lista de așteptare și donatori este una automatizată, ținând
cont de foarte mulți factori. Însă în același timp procesul este supervizat de cadrele medicale
autorizate, acestea putând gestiona anumite situații neprevăzute, fără a avea însă acces
complet la funcționalitatea aplicației. Astfel se garantează îndepărtarea erorilor și a
subiectivității.

9
3 ABORDĂRI EXISTENTE
Există multiple aplicații în mediul online care se ocupă cu gestionarea donării de organe, însă
majoritatea dintre acestea sunt mai mult aplicații de înregistrare a propriei persoane pentru
a-ți done organele, iar potrivirile vor fi făcute intern de cadrele medicale după deces, fără
vreun proces de automatizare.

Am găsit, conform [13], un instrument care realizează potriviri între donatori și pacienții care
sunt pe lista de așteptare pentru a primi un ficat, care se adresează atât donatorilor care își
donează organele după moarte, cât și celor care vor să-și doneze o parte din ficat cât sunt
încă în viață, unor cunostiințe.

Din păcate nu am putut găsi o aplicație disponibilă publicului larg care să facă în mod
automatizat potrivirile între donatori și cei de pe lista de așteptare care așteaptă să primească
un organ. Este posibil firește să existe astfel de automatizări la nivel de spital, în mod intern,
însă ele nu sunt accesibile publicului larg pentru a face o comparație completă. De asemenea,
nu găsesc nimic care să reprezinte o rețea de instituții medicale care este conectată în
gestiunea acestui proces într-un mod automat.

Menționez că în Romania nici măcar înregistrarea online pentru a fi donator de organe nu

este posibilă, procesul trebuie să fie făcut într-o instituție medicală și la Casa Națională De
Asigurări de Sănătate apoi.

Cel mai aproape produs de ceea ce doresc eu să creez, de ceea ce aplicația mea vrea să
reprezinte este realizată de fundația MOHAN1:

Figura 3.1 Aplicația MOHAN pentru donare de organe – Pagina principală

1
https://www.mohanfoundation.org/mobile-apps/organ-donation-helpline-app.asp

10
Mai jos urmează un tabel cu funcționalitățoșe oferite de aplicația MOHAN, în comparație cu
aplicația realizată pentru această lucrare:

Aplicația MOHAN Aplicația mea

Informatii despre donarea de organe X
Referire la donare de organe X X
Referire la donare de piele / globi oculari X
Posibilitatea să te înregistrezi ca donator X X
Posibilitatea să te înregistrezi ca recipient X
Vizualizarea potrivilor X
Potriviri realizate în aplicație X
Proces automatizat X
Acoperire la nivel național al donatorilor X X
Acoperire la nivel național al procesului de X
potrivire al organelor
Tabel 1 Diferențe între aplicația MOHAS si aplicația propusă

Astfel, se poate observa cum aplicația deja existentă studiată este mai mult o aplicație cu
funcție de informare și de înrestrare a donatorilor de organe pentru a fi adăagați într-o bază
de date și gestionați intern.

Se poate observa cum aplicația propusă aduce multe elemente noi prin automatizarea
procesului de donare de organe, și extinde la nivel național funcționalitățile prezentate mai
sus.

11
4 TEHNOLOGIILE FOLOSITE
În implementarea programului s-au folosit multiple tehnologii, alese dupa diverse criterii,
după cum vor fi specificate în continuare.

4.1 Baza de date

4.1.1 MySQL
Baza de date a fost implementată folosing MySQL. MySQL este unul dintre cele mai populare
sisteme de gestiune a bazelor de date, la ora actuallă ocupând prima poziție în această
privință. Cu ajutorul său se pot realiza aplicații în aproape orice limbj de programare de
actualitate.

Am ales această variantă deoarece, conform [14], este o tehnologie open source, ceea ce face
debugging-ul și utilizarea funcționalităților să lucreze la nivel maxim. Poți vedea sursa și să faci
schimbări cum îți dorești. De asemenea, din punct de vedere al securității, MySQL oferă un
strat de protecție pentru a proteja datele, se pot seta permisiuni de accesare, iar parole sunt
encriptate cu algoritmi specifici.

Scalabilitatea este de asemenea un factor important, MySQL poate rula pe diferite servere și
poate scala atât orizontal, cât și vertical. Astfel rularea aplicației pe mai multe servere se poate
face relativ facil. De asemenea, prin sistemul de cache la citirea datelor și prin folosirea
indexilor la cantități mari de date, se garanteză o performanță mărită a aplicației.

Nu în ultimul rând, MySQL este disponibil pe cele mai multe sisteme de operare populare
(Windows, Linux, OS2, Solaris, etc.), și beneficiază de API-uri suport pentru toate limbajele de
programare majore, ceea ce îl face ușor de integrat.

4.2 Tehnologii folosite pe backend

4.2.1 Java
Java este un limbaj de programare orientată pe obiecte, care permite scrierea de aplicații
distribuite. Pentru a rula, foloseste mașina virtuală Java, astfel încât se asigură portabilitea
programelor. Există multiple platforme Java pe care pot fi dezvoltate aplicații, printre care
ediția standard și editia enterprise.

Am ales acest limbaj pentru aplicația mea deoarece, potrivit [15], este ușor de învățat, fiind
un limbaj care derivează din C/C++ și are o sintaxă relativ simplă. De asemenea, este un
tehnologie, care se poate scrie o data și va rula mereu, pe orice sistem, cum menționam și
puțin mai sus. Acest lucru în face o alegere bună pentru foarte multe domenii, printre care:
dezvoltarea de aplicații mobile, dezvoltarea de aplicații web, aplicații care necesită
conectarea la baze de date, aplicații de networking si multe altele.

Multi-threadingul pus la dispoziție de această tehnologie reprezintă și el un avantaj în

alegerea sa. Java folosește un server web multi-threading care procesează cererile pe thread-
uri separate. Astfel se realizează realizarea simultană a mai multor task-uri.

12
Componenta securitate are o importanță uriașă. Java este unul dintre cele mai securizate
limbaje de programare. Are multe API-uri, instrumente de securitate, și un set larg de
protocoale, mecanisme și algoritmi de securitate, punând accent pe criptografie, utilizarea de
chei publice, acces securizat la resurse, procesul de autentificare și de asemenea, comunicare
securizată.

Dar cel mai mare avantaj al limbajului Java sunt bibliotecile și framework-urile în număr
extrem de mare care extind funționalitățile deja existente. Există biblioteci pentru logging,
parsare JSON, parsare XML, parsare HTML, biblioteci criptografice, biblioteci pentru testarea
aplicației etc. Aceste biblioteci fac dezvoltarea aplicațiilor mult mai rapidă și mai eficientă. Iar
framework-urile duc această eficienă la un nivel și mai ridicat.

Un framework reprezintă un pachet software care oferă anumite funționalități generice, fiind
deja implementate, și care pot fi modificate și dezvoltate în continuare de dezvoltatorul
software. Practic se construiesc funcționalități software dezvoltate, având o bază deja
existentă. Printre cele mai folosite framework-uri se numără Spring, Apache Struts, Hibernate,
Grails etc.

Am ales pentru aplicația mea să folosesc framework-ul Spring, așa cum va fi prezentat în
continuare.

4.2.2 Spring Framework

Framework-ul Spring a fost construit pentru ca dezvoltatorul de aplicații să se poate desprinde
de detaliile minore și să se poată concentra pe dezvoltarea aplicației. Această platformă JAVA
oferă suport complet pentru J2EE (Java Enterprise Edition). De asemenea are multe extensii
pentru a face mai ușoară dezvoltarea aplicațiilor de diferite tipuri.

Potrivit [16], printre avantajele utilizării acestui framework se numără:

 Permite ca dependențele aplicației să fiecare create la rulare de framework (Inversion

of Control).
 Există principiul de programare orientată pe aspecte, care permite separarea logicii de
bussines de serciviile sistemului aplicației.
 Conține Spring MVC Framework, pentru contruirea de aplicații bazate pe pattern-ul
MVC.
 Este construit să permită integrarea facilă a altor framework-uri Java, precum
Hibernate, ORM. Nu restricționează în niciun fel ca acestea să fie folosite împreună.
 Are suport pentru testarea aplicației.
 Spring este un framework modular, care iți permite să selectezi exact pe care din
funcționalitățile sale dorești să le folosesti prin modulele sale.

În dezvoltarea aplicației mele am folosit mai multe module Spring (de exemplu Core, Beans,
Security, Data JPA, Web etc.). Voi prezenta în continuare cele mai importante și mai utilizate
dintre ele și motivele pentru care am ales să lucrez cu acestea.

13
Spring Web Services

Spring Web Services este un modul Spring care se ocupă cu înleșnirea dezvoltării de aplicații
în domeniul Web. El asigură practic că regulile de best practice sunt respectate, practic le face
mult mai ușor de realizat. Aderă la politica SOAP, permițând crearea de servicii web flexibile,
prin manipularea XML-urilor.

De asemenea, acesta prezintă suport pentru tehnologiile de tip REST sau MVC, folosite
intensiv în dezvoltarea aplicației mele.

MVC (Model – View – Controller) este un design pattern foarte popular, care realizează
separarea datelor de interfața aplicației într-un mod foarte eficient. La bază folosește
principiul de reutilizare a codului, și are un impact destul de mare asupra timpului de
dezvoltare al aplicației.

REST (Representational State Transfer) este un protocol bazat pe HTTP, care realizează
conexiuni între utilizator și serverul aplicației. Este foarte popular în dezvoltarea de aplicații
web, deoarece oferă suport pentru operațiile CRUD într-un mod simplificat, fără reguli stricte
de limitare (precum serviciul SOAP).

Spring Data JPA

Modulul Spring Data JPA face parte din familia Spring Data. El asigură lucrul cu partea de date
ale aplicației și ajută la dezvoltarea repository-urilor. Face mai ușoară dezvoltarea de aplicații
Spring care lucrează cu tehnologii de accesare a datelor.

Printre principalele avantaje ale utilizării acestui framework se numără faptul că face codul
mult mai ușor de scris și de înteles. Cel care foloselte acest modul Spring trebuie doar să scrie
interfețele de lucru cu bazele de date, să descrie metode costum dacă sunt necesare, scriind
doar cererile sub forma de limbaj specific bazei de date, și Spring va pune la dispoziție
implementarea în mod automat.

Cu ajutorul său, se pot astfel construi aplicații cu foarte multe căi de acces către date, într-un
mod clar și concis, și în plus, decuplat de restul aplicației. Astfel, se pot realiza foarte ușor
modificări în acest context.

4.2.3 Hibernate
Hibernate este un framework Java, utilizat în dezvoltarea de aplicații care comunică cu bazele
de date, simplificând mult acest proces. Framework-ul ales dezvoltă API-ul pus la dispoziție
de Spring Data JPA.

Am ales să lucrez cu Hibernate deoarece este un frame-work open-source, deci dispune de o

documentație foarte bine pusă la punct, dar și de foarte multe instrumente potrivite pentru
debugging și testare, care permit identificarea problemelor care pot apărea pe parcursul
dezvoltării aplicației în mod facil.

14
Nu în ultimul rând un aspect important în reprezintă faptul că este o implementare a JPA. Este
necesar pentru a utilliza Spring Data JPA, fără a defini propriu zis modulele necesare, și a
realiza conexiunea între obiectele create în aplicația în limbajul Java și tabelele din baza de
date MySQL.

4.2.4 Maven
Apache Maven este un utilitare care ajută la contrucția și gestionarea proiectelor software.
Este folosit în principal pentru proiectele în limbajul Java, dar poate fi utilizat și cu alte limbaje
de programare. Ajută în procesul de build al aplicației, dar mai ales și în integrarea
dependențelor acesteia.

Maven se utilizează prin fișiere de tipul XML, cu numele de POM (Project Object Manager).
Fișierul POM contine informații despre modulele și dependențele proiectului, dar și alte
informații folosite la generarea documentației acestuia, inclusiv autorul, drepturile, licența și
alte metadate de acest fel. Maven descarcă în mod dinamic bibliotecile Java și pluggin-urile
Maven specificate in POM, din repositoarele sale, și apoi le stochează local, integrându-le în
proiect în mod automat.

Am ales să folosesc Maven în partea de backend a aplicaței mele deoarece aduce diferite
beneficii, cum ar fi implicarea în procesul de build al aplicațiiei. Maven construiește practic
executabile de diferite tipuri (de exemplu JAR sau WAR) care vor fi rulate apoi. De asemenea
Maven este destul de ușor de utilizat, doar se specifică ce este necesar în fișierul POM și
procesul de configurare se desfășoară automat.

Un alt avantaj îl reprezintă descărcarea automată de biblioteci și pluggin-uri, după

specificațiile scrise în POM la partea de dependințe. Acest lucru economisește foarte mult
timp în configurarea aplicației, și face procesul mult mai simplu. De asemenea, utilizând
Maven, putem specifica ce parte dintr-o anumită bibliotecă sau dintr-un anumit framework
dorim să folosim. De exemplu, daca dorim să utilizăm framework-ul Spring, nu trebuie să
adăugăm toate componentele sale local, putem selecta din acestea. Astfel, se economiseste
timp și spațiu în acest proces.

4.2.5 Postman
Postman este o platformă realizată pentru dezvoltarea și mentenența de API-uri, în special pe
partea de testare a aplicațiilor, testare atât manuală, cât și automată.

Este util și pentru alte caracteristici în dezvoltarea de produse software, cum ar fi: crearea și
publicarea de documentație pentru o aplicație, în formatul limbaj mașină, procesul de
monotorizare al aplicației, prin verificarea performanțelor sale la un interval de timp
prestabilit, și, destul de important și în general motivul pentru care este ales față de alte
produse asemănătoare de pe piață, posibilitatea de a partaja spațiul de lucru cu alți utilizatori
ai aplicației. Acest lucru este folositor bineînteles, în cadrul proiectelor mari, realizate în
echipe cu mulți oameni.

15
Am ales să folosesc acest instrument pentru partea de testare a aplicației mele. Motivația
constă din faptul că se pot testa ușor cererile venite sub format REST, și Postman oferă diferite
funcționalități care înlesnesc tot acest proces, cum ar fi: posibilitatea de salvare a cererilor în
diferite directoare, pentru o bună organizare a testării, funcția de a seta anumite teste să se
repete la un interval de timp, vizualizarea cu ușurință a rezultatelor și a erorilor, într-un limbaj
ușor de citit, care de asemenea poate fi costumizat, și de asemenea, design-ul care face
aplicația ușor de folosit.

4.2.6 IntellIJ IDEA Ultimate Edition

IntelIJ IDEA este un mediu de dezvoltare al aplicațiilor, specific programelor scrise în mai
multe limbaje de programare, dar este folosit pentru a dezvolta software în special în limbajul
Java.

Pentru dezvoltarea aplicației mele, am folosit versiunea Ultimate a IntellIJ. Motivația pentru
care am ales să lucrez în această platforma este reprezentată de numeroasele beneficii pe
care IntellIJ le oferă, precum: debugging automat integrat, conectarea automată cu bazele de
date, integrarea Maven în mod facil, asistență în scrierea codului, suport pentru sistemele de
versionare si integrare.

De asemenea, sugestiile oferite de platformă chiar în timpul scrierii codului, cât și analiza în
amănunt a acestuia, reprezintă un mare avantaj, care înlesnește și precipitează procesul de
dezvoltare.

4.3 Tehnologii folosite pe frontend

4.3.1 ReactJS
ReactJS este o bibliotecă JavaScript open source, utilizată pentru dezvoltarea aplicațiilor pe
partea de front-end. Este folosită în special pentru realizare de interfețe grafice și elementele
de interacțiune cu utilizatorul. Se află în mentenanța Facebook și a unei comunități de
dezvoltatori software și a altor companii.

Am ales să folosesc ReactJS pentru aplicația mea deoarece folosește JavaScript, limbaj cu care
eram deja familiară, și care are multe avantaje în dezvoltarea de aplicații frontend, precum
comunicarea asincronă, viteza mare, simplitate și versabilitate.

Pe lângă asta, conform [17], ReactJS este extrem de ușor de învățat, existând documentații și
foarte multe tutoriale online pentru a te familizariza cu această bibliotecă. De asemenea
foloseste componente reutilizabile, lucru care înleșneste și precipită foarte mult procesul de
dezvoltare al front-end-ului aplicației, dar face și accesibilă conectarea cu backendul, prin
intermediul bibliotecii de JavaScript Axios.

În plus, ReactJS are multe biblioteci adiționale care pot fi adăugate și facilitează scrierea
aplicației.

16
4.3.2 Semantic UI
Semantic UI este un framework ReactJS care aduce imbunatățiri prin simplicarea scrierii
elementelor și integrarea lor în aplicație. Am ales să folosesc acest framework deoarece face
codul mult mai clar și mentenanța și debugging-ul mult mai ușoare.

În plus, înlenește și dezvoltarea aplicației, obținând elemente ușor de modificat într-un timp
mic. Este ușor de utilizat și se poate învăța foarte ușor.

Un alt avantaj major al acestui framework este că oferă elemente cu caracteristici incorporate
pentru dispozitivele mobile.

Am ales să utilizez în proiectul meu două componente ale framework-ului Semantic UI. Prima
dintre ele este reprezentată de Semantic-UI-React, pentru definirea mai ușoară a
componentelor necesare în paginile aplicației. A doua componentă folosită este Semantic-UI-
CSS, utilizată pentru înlesnirea procesului de stilizare a elemetelor definite cu Semantic-UI-
React, dar și cele de tip HTML.

17
5 PROIECTAREA APLICAȚIEI

Aplicația mea prezintă o arhitectură pe 3 nivele, după modelul MVC (Model-View-Controller),

după cum urmează:

 Baza de date, dezvoltată în MySQL – pe post de Model

 Backend-ul, dezvoltat cu Java si Spring – pe post de Controller
 Interfața cu utilizatorul, dezvoltată cu ReactJS – pe post de View

În continuare se vor prezenta în detaliu fiecare dintre aceste trei nivele.

5.1 Baza de date

Entitatea Model folosită în realizarea acestei aplicații, reprezentată de baza de date, este
alcătuită din șase tabele realizate în MySQL, care sunt legate între ele după cum urmează în
cele două imagini de mai jos:

Figura 5.1 Baza de date a aplicației (Partea 1)

18
 Figura 5.2 Baza de date a aplicației (Partea 2)

După cum se poate vedea mai sus, cele sașe tabele modelate p3entru dezvoltarea proiectului
meu sunt:

Tabela Organizations – folosită pentru a reține instituțiile medicale în care se vor desfășura
donările de organe și transplanturile. Are ca și câmpuri id-ul, numele instituției, orașul în care
se află, județul și regiunea. Regiunea se va completa automat în funcției de județul din care
face parte instituția. Am hotărât să împart județele României în patru regiuni, pentru a se
putea desfășura donări de organe în interiorul unei regiuni, pentru cele care au o viabilitate
mai mare, în timpul în care s-ar putea face donația luând în considerare distanța geografică.
Cele 4 regiuni sunt:

 Regiunea 1, alcătuită din județele Alba, Arad, Bihor, Satu Mare, Maramureș, Sălaj, Cluj,
Bistrița-Năsăud, Mureș, Sibiu
 Regiunea 2, alcătuită din județele Suceava, Botoșani, Iași, Neamț, Harghita, Vaslui,
Galați, Covasna, Bacău, Vrancea
 Regiunea 3, alcătuită din județele Timiș, Caraș-Severin, Hunedoara, Golj, Dolj, Vâlcea,
Argeș, Mehedinți, Olt, Teleorman
 Regiunea 4, alcătuită din județele Brașov, Prahova, Dâmbovița, Buzău, Brăila, Ilfov,
București, Tulcea, Constanța, Ialomița, Călărași, Giurgiu

Tabela Users – folosită pentru a reține informații despre utilizatorii aplicației. Conține
informațiile specifice, precum id, username, parola (care va fi encriptată de către backend).
Token-ul va fi generat la autentificare și stocat în aceasta tabelă. De asemenea rolul user-ului

19
va fi stocat aici, dar și rolul pentru care aplică un utilizator, în momentul in care se
înregistrează. Aceste două câmpuri pot avea valorea „Admin” sau „Patient”. Următoarele
câmpuri sunt Patient_role si Patient_id. Patient_Role poate avea valorile „None” (pentru
Admin) și „Donor” sau „Recipient” (pentru Patient). Patient_Id este o cheie străină către
tabela Patients, și face referință la detaliile pacientului. Apoi vin alte detalii specifice userului,
precum numele, prenumele și emailul. Ultimele două câmpuri sunt Active și Organization_Id.
Active arată dacă contul utilizatorului este activ sau nu, iar Organization_Id semnalizează
instituția medicală din care acesta face parte.

Tabela Blacklist_token este folosită pentru a evidenția token-urile care sunt încă valide, dar
au fost dezactivate de utilizator prin procesul de delogare din aplicație, pentru a le menține
inactive până la expirare. Tabela conține si câmpuL „Created_at”, cu format de dată, pentru
a reține data la care s-a adăugat intrarea în tabelă, deoarece se dorește să se steargă regulat
token-urile vechi din tabelă.

Tabela Patients conține detaliile pacienților înregistrați ca donori sau ca recipienți. Conține
tipul pacientului (Donor/Recipient), informații precum vârsta, prioriatatea (in cazul pațienților
de tip Recipient), grupa de sânge, înălțimea și greutatea. Mai conține și statusul, câmp specific
donatorilor și care poate avea valorile „Dead” sau „Alive”. Câmpul „Date_added” face referire
la data adăugării pentru Recipienți și la ce data morții pentru Donorii cu statusul „Dead”.

Câmpul Organization_Id face referire la organizația de care aparține pacientul. Apoi urmează
câmpurile specifice organelor (Heart, Left_lung, Right_lung, Liver, Left_kidney, Right_kidney,
Pancreata și Intestines). Aceste valori sunt de tip Boolean. În cazul în care Donorul poate dona
acel organ sau Recipientul are nevoie de acel organ, aceste câmpuri vor avea valoarea True,
altfel vor avea valoarea False. Câmpurile CMV_Negative și EBM_Negative fac referire la niște
parametrii specifice potrivirilor în care sunt implicați rinichii, și au și ele valori booleene. În
ultimul rând mai există și câmpul Not_Check_Region, tot un Boolean. Acest câmp face referire
la verificarea pentru potriviri pe toatâ regiunea de care aparține spitalul. După un timp,
organele valabile pentru transplantul pe regiune (rinichii, intestinele) nu vor mai putea donate
decât în același județ din cauza distanței geografice.

Tabela Matches conține informații despre potrivirile realizate între pacienții de pe lista de
așteptare și donatori. Câmpurile Recipient_id si Donor_id fac referire la Id-ul userilor implicați
în potrivire. De asemenea, Organization_id reprezintă instituția medicală asociată cu cel care
va primi organul, și în care se va face de obicei transplantul. Se mai rețin de asemenea și
username-ul celor doi pacienți implicați, din motive de accesibilitate a datelor. Câmpul
Confrimed_match ne arată dacă potrivirea este aprobată de cadrele medicale.

Următoarele câmpuri sunt specifice potrivirilor care implică rinichii. Câmpul Is_kidney ne
spune așadar dacă rinichii sunt sau nu implicați in acest proces. Hla_antigens_match și
Negative_lymphocytotoxic_crossmatch sunt câmpuri care simbolizează teste care se fac după
potrivire, pentru a confirma transplantul de rinichi, printre alți factori. Următoarele câmpiri
sunt Transplant_Date, care reprezintă data transplantului, și Transplant_done, care ne arată

20
dacă transplantul s-a finalizat. Urmează cele opt câmpuri care arată pe ce organe s-a facut
potrivirea între recipient și donor (Is_heart, Is_left_lung, Is_right_lung, Is_liver, Is_pancreata,
Is_right_kidney, Is_left_kidney,Is_intestines). Acestea sunt valori booleene, care pot lua
valoarea True dacă organul e implicat în proces și False, în caz contrar. Ultimul câmp din tabelă
este Is_specific și reprezintă dacă potrivirea s-a făcut specific, pe baza unei rude sau
cunostiințe, sau pacientul va primi organul/organele necesare, de la un donator necunoscut,
în urma algoritmului de potrivire pentru acest caz.

Tabela Blacklist conține potriviri între donatori și pacienți de pe lista de așteptare pentru
primirea unui organ care nu s-au înfăptuit. În unele cazuri pot exista motive pentru care după
potrivire, aceasta să nu poată fi confirmată. Motivele pot varia: un test poate arăta de fapt
invaliditatea unui organ, cei doi pot să nu fie compatibili în urma unor teste de laborator
făcute între cei doi, recipientul să nu poate fi contactat sau să nu poată ajunge la spital în timp
util penru transplant. Astfel procesul nu poate fi contiunuat, iar în urma stergerii potrivirii se
vor adăuga date în această tabelă, pentru a reține ca este nepotrivită. Acest lucru împiedică
la scanarea pentru o nouă potrivire, să se facă aceeași ca cea de dinainte.

5.2 Backend-ul
Partea de backend a aplicației este realizată în limbajul Java și cu ajutorul framework-ului
Spring. Aceasta urmează la rândul ei anumite patten-uri, pentru a asigura o funcționare
performantă a aplicației, după cum va urma mai jos.

Schema generală a aplicației este următoarea:

Figura 5.3 Schema generală a backend-ului aplicaței

Se poate vedea cum aplicația este împărțită în mai multe clase și pachete, legate unele de
altele prin anumite funcții.

21
5.2.1 Securitate, gestionarea erorilor, entități DTO
În primul rând se poate cum există un layer de securitate, reprezentat de clasa
WebSecurityConfig și pachetul security. Clasa WebSecurityConfig adaugă header-ul CORS
aplicației noastre, asigurând acces limitat la căile aplicației, cât și setarea căilor care se vor
accesa liber, fără permsiuni de logare. Pentru accesarea căilor securizarte se va folosi JWT
Token.
Pachetul security conține două fișiere, astfel:

Figura 5.4 Pachetul security

Astfel se poate vedea cum JWTAuthorizationFilter cu filtrarea cererilor, validarea tokenurilor

și verificarea acestora. JWTLoginController este conceput pentru a intercepta și executa
cererile de pe căi care nu au nevoie de acces autorizat: autentificarea și înregistrarea
utilizatorilor și resetarea parolei pe email.

Pachetul Dto (Data Transfer Object) se asigură de transportul datelor din frontend in backend
prin Body-ul cererilor, definind acele entități. Este folosit în general pentru a nu trimite
parolele care parametrii, ci în Body-ul cererii.

Figura 5.5 Pachetul Dto

După cum este menționat și mai sus, m-am conentrat pe cererile care implică parola ca și
parametru, și anume: autentificare, înregistrare și resetarea parolei.

Următorul pachet este pachetul error, în care s-a definit comportamentul aplicației în cadrul
apariției de comportament neprevăzut, în cadrul cererilor cu parametrii gresiți sau care

22
cauzează probleme. Toate acestea sunt făcute din punct de vedere HTTP, deci răspunsurile se
vor trimite direct pe server.

Figura 5.6 Pachetul error

Clasa ExceptionHandler face posibilă personalizarea mesajelor de eroare, iar clasa

ProblemConfiguration face posibilă serializarea răspunsului Java în răspuns HTTP.

Celelalte clase definesc răspunsurile personalizate, astfel: AuthentificationException pentru

erori de autentificare, EntityNotFoundException pentru când entitățile cerute de front-end
nu sunt găsite, iar BadRequestException pentru celelalte erori care pot apărea.

5.2.2 Controller, Service, Repository, Domain

Următoarele pachete sunt legate între ele, reprezentând implementări ale pattern-urilor
Controller, Service, Repository, Domain si DAO (Data Access Object) – alcătuit din Domain și
Repository. Acestea au rolul de a împărți funcționalitățile aplicații pe layere, pentru a face
scrierea, înțelegerea și debugging-ul aplicaței mai ușoare și mai eficiente.

Figura 9 Legătura între pachetele domain, repository, service și controller

23
Se observă cum această legătură între entitățile din figura 9 merge în direcția Controller ->
Service -> Repository -> Domain.

Controller-ul este o entitate cu rolul de a acționa ca o poartă între cererile HTTP primite de la
front-end și funcționalitățile backend-lui. Preia cererea, o corelează cu una din metodele
declarate, apelează mai departe controller-ul și așteaptă un răspuns de la acesta, pe care în
va trimite mai departe către front-end.

Figura 5.7 Clasele de tip controller

Există așadar trei clase de tip Controller:

 UserController, care primește cereri legate de utilizatorii aplicației (în afară de cele de
autentificare și înregistrare, care au fost descrise la partea de securitate)
 Match Controller, care preia cereri legate de potrivirile dintre donatori și recipienți
 OrganizationController, care primește request-uri în legătură cu gestionarea
instituțiilor medicale

Operațiile sunt vizibile în figura 5.7, în principal sunt operații de creare, modificare, stergere
și afișare a datelor, dar și lucruri mai specifice, precum aprovarea unui user și adăugarea
rolului său, confirmarea unei potriviri, delogarea din aplicație a utilizatorului sau adăugarea
detaliilor specifice pacienților.

Controller-ul va întoarce către frontend un răspuns de tip HTTP, fie cu detaliile trimise de
Service în format JSON, fie în cazul în care se produce vreo eroare sau vreo excepție, se va
întoarce aceasta, cu codul său specific, și un mesaj personalizat, pentru ca front-end-ul să
gestioneze apoi situația respectivă.

24
 Figura 5.8 Clasele de tip Service

Clasele de tip Service se ocupa cu logica de business a aplicației, el este cel care se ocupă cu
modificarea propriu zisă a datelor aplicației sau cu apelul de Repository-uri, care la rândul lor
au acces direct la date.

Există 5 interfețe care au fost mai departe extinse în clase care implementează metodele
definite în acestea, și o clasă numită EmailConfiguration. EmailConfiguration și EmailService
definesc setările de mesagerie prin email ale aplicației și personalizare formatului sub care
vor fi trimise emailurile.

În BlacklistTokenService este definită o metodă pentru mentenanță, pentru a sterge din

tabela Blacklist_token, la fiecare 24 de ore, token-urile vechi, deja expirate.

OrganizationService și MatchService definesc metode care vor prelucra datele din tabelele
Match și Organization, ca și modifcări, stergeri sau alte operații precum aprobarea potrivirilor.

Clasa UserService prezintă metode care vor avea impact pe tabelele Users și Patients,
realizând multe operații care vor avea impact asupra utilizatorilor aplicației, precum crearea
userilor, stergerea, resetarea parolei, schimbarea emailului, updatarea detaliilor specifice
userilor și a celor specifice pacienților, aprobarea conturilor și ala mai departe.

25
 Figura 5.9 Clasele de tip Repository

Repository-urile au rolul de executa operațiile pe baza de date. Ele extind interfața JPA a
framework-ului Spring, și metodele definite ori sunt deja implemetate de JPA, ori cu Query-
uri definite și personalizate.

Există câte o interfață de tip Repository pentru fiecare tabelă din baza de date, definind astfel
operații simple pe baza de date, care vor fi apelate din clasele de tip Service.

Figura 5.10 Clasele din pachetul domain

26
Pachetul domain prezintă entitățile definite pentru a reprezenta tabele din baza de date a
aplicației, și pentru a lucra în unele situații direct pe acestea.

Interfețele de tip Repository și clasele din pachetul domain formează împreună patternul DAO
(Data Access Object), care, așa cum sugerează și numele, lucrează direct pe baza de date a
aplicației.

5.3 Frontend-ul
Partea de frontend a aplicației mele prezintă mai multe pagini legate între ele.

5.3.1 Partea de autentificare

Figura 5.11 Partea de autentificare

În Figura 5.11 sunt prezentate legăturile între paginile de autentificare în aplicație.

Login este pagina cu care se deschide aplicația. Există câmpuri în care poți introduce
username-ul și parola, iar în caz că sunt corecte, vei fi condus către pagina MyAccount a
aplicației, care e și homepage-ul pentru utilizatorii logați. De acolo sau din orice altă pagină în
care utilizatorul se află fiind logat, poate accesa meniul aplicației și să apese opțiunea de
logout, fiind condus înapoi la pagina de login.

În pagina de login mai există două butoane: unul care va redirecționa către pagina de register,
unde se pot intreduce date pentru a te înregistra în aplicației. Celelalt buton duce către pagina
în care poți cere resetarea parolei: trebuie să se introducă emailul cu care este asociat contul
utilizatorului în aplicației, iar acesta va primi un mesaj pe adresa de email cu un link pentru
resetarea parolei.

27
Pagina MyAccount prezintă opțiuni diferite în funcției de rolul utilizatorului în aplcației,
administratorii vor avea acces la anumite resurse, iar pacienții la altele. Această pagină va
conține informații despre utilizatorul curent.

Figura 5.12 Homepage-ul aplicației

Pentru utilizatorii cu drepturi de administrator, cum apare și în Figura 5.12, va conține

informații de genul nume, prenume, email, instituția din care face parte utilizatorul și rolul
acestuia. De asemenea din această pagină, după cum se poate vedea, există opțiunea de
schimbare a adresei de email.

Iar pentru cei de tip Patient, pe lângă aceste lucruri, va mai conține și detaliile specifice
pacienților, precum vârstă, status, prioritate, grupă de sânge, ce tip de pacient este (donor
sau recipient), înălțime, greutate, etc..

5.3.2 Navigarea în aplicație ca și Administrator

Ca și Administrator, utilizatorii logați au acces la meniul care duce la diferite paginii ale
aplicației din orice pagină a acesteia. Meniul pentru Administratori, prezentat în Figura 16
conține patru opțiuni: Institutions, Users, Matches și Logout.

28
 Figura 5.13 Meniul aplicației

Se poate vedea cum, accesând opțiunile meniului, se pot accesa paginile Institutions List,
Users List. Matches List, sau se poate realiza delogarea, ca și utilizator cu drepturi de
administrator. Trebuie menționat că meniul este valabil în fiecare pagină a aplicației, în care
utilizatorul este logat, dar pentru simplificarea graficelor, nu-l voi mai reprezenta în
următoarele pagini.

Figura 5.14 Navigarea din pagina MyAccount

De asemenea, apăsând pe iconița de Home din oricare pagină a aplicației va atrage după sine
redirecționarea către pagina de MyAccount, fapt care, din nou, nu va fi reprezentat pentru
simplificarea graficelor realizate.

Pe lângă opțiunile oferite de meniu, în pagina MyAccount se mai poate accesa opțiunea
Change Email, care va redirecționa aplicația către această opțiune, în care utilizatorul își poate
schimba emailul, completând un formular care cere parola contului și noua adresă de email
pe care utilizatorul dorește să o asocieze cu contul său.

29
Mai jos se vor detalia cum sunt construite paginile care pot fi accesate din meniul aplicației,
cu excepția paginii de logout, care a fost deja prezentată mai sus.

Figura 5.15 Navigarea din pagina Institutions List

Figura 5.15 arată paginile ce pot fi accesate din pagina numită Institutions List. În Institutions
List, se pot vedea instituțiile înregistrate în aplicație. Există și un buton pentru a crea o
instituție nouă, iar fiecare instituției din listă prezintă butoane de stergere a instituției, lucru
care se va întâmpla fără redirecționări, printr-un pop-up în cadrul paginii curente, dar și de
vizualizare a acelei instituției, de editare sau de vizualizare a utilizatorilor înregistrați în acea
instituției. Aceste opțiuni vor redirecționa aplicația către alte pagini după cum se poate vedea
mai sus, cu funcționalitățile promise.

Pagina Create Institution conține un formular în care se vor scrie numele instiituției, orașul
din care face parte și județul, urmând ca regiunea să fie adăugată în partea de backend a
aplicației, în mod automat.

Pagina View Institution prezintă informații precum: ID-ul instituției (este necesar pentru
înregistrarea în aplicație a utilizatorilor noi), numele instituției, orașul și județul acesteia,
precum și regiunea sa.

Pagina Edit Institution permite editarea numelui, orașului și județului instituției medicale. Și
aici regiunea se va seta automat, în backend-ul aplicației.

Institution Users List conține o listă cu utilizatorii înregistrați în acea instituție. Pe această
pagină putem apăsa pe butonul Add Admin, și să introducem un admistrator nou în acea
instituție, introducând email, username, nume și prenume urmând ca acesta să folosească
funcția de „Forgot Password” pentru a-și seta parola în apllicație. De asemenea în această

30
pagină administratorul poate apăsa pe utiliatori pentru a le vedea detaliile, fără a avea însă
drept de editare sau stergere la o instituție de care nu aparține.

Figura 5.16 Navigarea din pagina Users List

Users List este o pagină în care există lista cu utilizatorii care fac parte din instituția medicală
a administratorului. Utilizatorii prezintă următoarele detalii în cadrul listei: nume, username,
rolul, si dacă sunt sau nu activi în aplicație.

Astfel fiecare utilizator din listă poate avea următoarele butoane: buton de aprobare a
contului (pentru utilizatorii care nu sunt în activi), buton de stergere al utilizatorului, și buton
de editare a detaliilor acestuia, pentru utilizatorii cu rol de pacient. Primele două acțiuni se
desfășoară în aceeași pagină, fără redirectionare, iar ultima dintre ele va conduce spre pagina
de editare, în care se pot adăuga și modifica detalii specifice pacientului, precum grupă de
sânge, vârstă, data morții pentru donatorii decedați, data adăugării pentru pacienți de tip
recipient, prioritatea, organele de care pacientul are nevoie sau pe care le donează, etc.

Apăsând pe oricare din utilizatorii din lista dată va duce la o pagină în care se vor putea
vizualiza detaliile acestuia, atât pentru admistratori cât și pentru pacienți. De aici se poate
alege, pentru cei din urmă, să se selecteze una dintre cele două opțiuni: Add Specific Match
și Search for Matches. Prima variantă va redirecționa administratorul către o pagină în care
se cere completarea numelui de utilizatorul al donatorului sau a recipientului cu care se va
face potrivirea, și care firește va avea tipul opus față de utilizatorul selectat pentru acest
proces. De notat este că, în cadrul pacienților recipient se acceptă doar donatorii în viață în
acest caz, care doresc să doneze specific către acel pacient un organ nevital (de exemplu: o
cunostiință sau o rudă).
31
Opțiunea Search for Matches va conduce la o pagină unde se pot căuta și forma potriviri prin
intermdiul unui algoritm care va ține cont de toți factorii specifici unui astfel de proces.
Potrivirile formate vor putea fi vizualizate de administrator, accesând opțiunea Matches din
meniul aplicației. Această opțiune nu va ține cont de donatorii înca în viață care sunt
înregistrați în aplicație.

De asemenea, se poate accesa opțiunea de a se crea utilizatori, atât de tip pacienți, cât și de
tip administrator. Pentru pacienți există un formular care cere numele, prenumele,
username-ul și rolul. Pentru cei de tip administrator, se va mai cere și adresa de email, pentru
a se putea seta parola prin intermediul acesteia. În cadrul pacienților, crearea unui cont de un
administrator se va face în general pentru donatorii decedați sau pacienții în stare foarte
gravă, care nu-și pot crea singuri un cont la acel moment.

Figura 5.17 Navigarea din pagina Matches List

În pagina cu lista de potriviri se pot vedea potrivirile în care sunt implicați pacienții instituției
medicale din care aparține administratorul logat în aplicație. În listă fiecare potrivire are
anumite detalii incluse, precum numele de utilizator al celor doi pacienți implicați și dacă a
primit confirmarea din partea cadrelor medicale.

Din nou, fiecare potrivire prezintă 3 butoane, de confirmare a acesteia, de stergere și de

editare a sa. Confirmarea și stergerea se vor desfășura, ca și în cadrul celorlalte liste din
aplicație, fără redirecționare, printr-un pop-up de confirmare.

Opțiunea de editare a potrivirii va redirecționa aplicația către o pagină în care se va putea

edita potrivirea aleasă. În această pagină se poate adăuga data transplantului, confirmarea că
acesta s-a realizat, iar în cadrul în care potrivirea aceea implica donarea unui rinichi, pagina
va prezenta opțiunea de adăugare a detaliilor necesare pentru testarea compatibilității în
cadrul acestor organe.

32
Într-ul final, apăsând pe una din potrivirile din listă, va conduce la o pagină în care se vor putea
vedea detaliile potrivirii, fiind cele care au fost menționate și în cadrul editării acesteia, și, în
plus, numele de utilizator al pacienților implicați.

5.3.3 Navigarea în aplicație ca și Pacient

Pacienții au mai puține privilegii ca Admistratorii în cadrul aplicației, din cauza nivelului de
securitate necesar în cadrul unui astfel de proces.

În primul rând, meniul pentru pacienți este mult mai restrâns, așa cum se poate vedea în
Figura 5.18.

Figura 5.18 Navigarea din pagina Matches List

Astfel, se poate observa cum din pagina de Home a aplicației se pot accesa doar 3 opțiune:
schimbarea mailului și logout, care sunt general valabile, și opțiunea de a-ți vedea propriile
potrivire.

Figura 5.19 Navigarea din pagina Home pentru pacienți

33
Astfel, Pagina de MyAccount pentru utilizatorii de tip Pacient va conține atât informații
specifice de cont, precum email, sau username, cât și informații legate de rolul avut, precum
grupa de sânge, vârstă, status, înălțime, greutate, etc..
Din această pagină, există opțiunea de schimbare a emailului. Ca și în cadrul administratorului,
dacă această opțiune este selectată, va conduce la o pagină cu un fomular cerând parola și
noul cont dorit de utilizator.
Din meniu, din cele două opțiuni se poate selecta cea de logout, care va produce delogarea
din aplicație și redirecționarea către pagina de login, din nou identic cu ce se întâmplă cu
administratorul în acest caz.
Ultima opțiune disponibilă din meniu, My Matches, va conduce utilizatorul spre o pagină în
care se găseste o listă cu potrivirile curente ale acestuia. Din listă se va vedea dacă potrivirea
a fost sau nu confirmată încă. Apăsând pe o potrivire, pacientul este condus către pagina în
care poate vedea detaliile acesteia, precum data la care se va face transplantul, detaliile
specifice pentru rinichi, în cadrul în care acestiu sunt implicați, etc.
Prin urmare, se poate afirma încă o dată ca uilizatorii cu rol de pacient au mult mai puține
drepturi în cadrul aplicației. Acest lucru produce securizarea aplicaței dintr-un anumit punct
de vedere, asigurând că nimic nu se paote întâmpla fără ca persoane cu expertiză medicală să
fie implicate, dar în același timp refuzându-le și acestora accesul deplin la procesele din
spatele aplicației, pentru a evita anumite conflicte.

34
6 DETALII DE IMPLEMENTARE
În proiectarea aplicației s-au întâlnit dificultăți în unele cazuri, atât în cazul dezvoltării pe
partea de backend, cât și a celei pe frontend. De asemenea, există firește unele aspecte
notabile, care se cer a fi menționate, atât pentru a întelege legica din spatele unor lucruri, cât
și pentru a pune în evidență și a întelege mai bine proiectul ca un total.

6.1 Implementarea pe partea de backend

Așa cum s-a menționat în capitolul anterior, pentru date și repository-uri s-au folosit folosit
framework-urile Spring Data JPA și Hibernate. Interfață disponibilă prin acestea conține
metode deja declarate, pentru majoritatea operațiilor simplu pe baze de date, precum
creerea unui element, obținerea, modificarea sau stergerea unui element după id,
vizualizarea tuturor elementelor din acea tabelă. Pentru lucrurile mai aparte, mai complexe
s-au folosit cereri personalizate, precum în Figura 6.1.

Figura 6.1 Metode personalizate în Repository

Mai sus sunt prezentate anumite metode din clasa UserRepository, spre exemplificarea felului
în care sunt făcute operațiile direct pe baza de date, folosind adnotația Query și scriind cereri
direct în limbajul MySQL. Spre exemplu, în metoda findWaitingUsersByOrganizationId se va
întoarce o listă cu toți utilizatorii aplicației (toate coloanele din tabele Users) dintr-o
organizație specificată prin cadrul unui parametru dat, care așteaptă să le fie activat contul,
nefiind încă activi în aplicație.

Interesant este și cum a fost adăugat un filtru de securitate în aplicație, folosind CORS. CORS
(Cross-Origin Resource Sharing) este un mecanism prin care se poate controla și limita accesul
la unele date ale unei aplicații. CORS a fost folosit în cadrul aplicației pentru a permite doar
utilizatorilor înregistrați să acceseze majoritatea elementelor din cadrul resurselor aplicației.
COSR a fost introdus în aplicația mea utilizând partea de Spring Web Security din cadrul
framework-ului Spring.

35
 Figura 6.2 Utilizarea CORS

Se poate observa cum se setează layerul de JWTAuthorizationFilter peste aplicație, care va fi

descris mai jos, împreună cu cel de autentificare prin username și parolă. Apoi se exclud din
această configurație cele trei metode care nu au nevoie de securizate, procele de
autentificare în aplicație, înregistrare și resetare a parolei pe email.

Figura 6.3 JWTAuthetificationFilter

36
Layerul de JWTAuthorizationFilter, prezentat în figura 6.3, asigură verificarea, validarea și
integritatea cererilor venite de pe server, ținând cont și de procesul de delogare din aplicație.

Crearea tokenurilor se vor face la logarea userilor în aplicației, în cazul în care credințialele
introduse sunt corecte.

Figura 6.4 Generarea token-urilor

Cum este expus și în figura 6.4, token-urile au nevoie de o cheie secretă, de o cheie de
identificare, de permisiunile utilizatorului, cât și de username-ul acestuia, de data la care se
generează, de un algoritm de generare (în cadrul aplicației mele se folosește algoritmul
HS512) , și de o dată de expirare. Toate aceste elemente fac ca acesta să fie aproape imposibil
de spart prin brute-force, token-ul fiind foarte lung și folosind encriptări. În cadrul aplicației
mele, un token va fi valabil timp de o oră.

O altă problemă apărută în cadrul folosirii token-rilor face referire la procesul de delogare din
aplicație al utilizatorului. Prin felul în care token-urile sunt folosite în mod universal, în
momentul în care un utilizator se deloghează din aplicație, acesta doar nu mai are acces la
token-ul cu care folosea elementele dorite. Însă token-ul este încă valid pentru o perioadă de
timp, ele nu pot fi expirate manual, ci vor expira doar atunci când trece perioada lor de
valabilitate. Acest lucru nu este foarte sigur, deoarece cineva poate accesa acel token în timp
util, în special prin sistemul de cache al unui browser web.

Aici intervine tabela Blacklist_Token, în care vor fi reținute token-urile utilizatorilor care s-au
delogat din aplicației, împreună cu dara creării acestora, pentru o perioadă de timp.

37
 Figura 6.5 Verificarea token-urilor

Se observă cum la verificarea token-urilor, se ține cont de tabela Blacklist_Token, în cazul în

care token-ul cu care se face cererea este prezent în acea tabelă, token-ul va fi declarat invalid
de către filtru.

Această metoda de a verifica token-urile mai ridica o problemă totuși. Dacă presupunem că
mulți utilizatori vor utiliza aplicația, vor exista multe cereri de delogare, prin urmare vor exista
foarte multe intrări în tabela Blacklist_Token, lucru care va îngreuna enorm operațiile pe
această tabelă, respectiv în cadrul procesului de autentificare, unde se verifică daca tokenul
este prezent în tabelă. Astfel, trebuie ca datele să fie curătate la un anumit interval, mai ales
pentru că după o oră token-ul va expira de la sine, și nu va mai fi nevoie de prezența sa în
tabelă.

Figura 6.6 Curățarea tabelei Blacklist_token

Astfel, se remarcă cum la fiecare 24 de ore, se sterg toate datele din tabelă, fără cele din
ultima oră, considerând ca acelea ar putea conține încă token-uri valabile.

În continuare unele metode definesc operații suficient de simple: crearea de entități,

stergerea lor, modificări simple, sau vizualiarea unor date. Alte metode reprezintă o
combinație de astfel de operații simple. Au existat și metode mai greu de implementat, mai
complexe. Printre acestea se numără și resetarea parolei, prin email.

38
În primul rând, utilizatorul trebuie sa facă cerere să primească prin email un link de resetare
a parolei. Un cont de gmail este configurat în aplicație, setat pentru a trimite mesaje.

Figura 6.7 Setarea trimiterii de email-uri

În figura 6.7 se poate observa cum, cu ajutorul serviciului JavaMailSender, se pot seta
parametrii emailului care se dorește trimis (destinatar, expeditor, subiect, și corpul mesajului)
și se poate trimite emailul propriu-zis.

Figura 6.8 Trimiterea link-ului de resetare a parolei

Precum se poate vedea în Figura 6.8, trimiterea emailului se realizează pe un thread nou.
Acest lucru se întamplă deoarece, întrucât serverele de gmail pot fi mai mult sau mai puțin
ocupate, procesul poate dura destul de mult, chiar mai mult de 20 secunde, și nu se dorește
blocarea aplicației din această cauză.

39
În final, după ce utilizatorul primește pe mail linkul de resetare al parolei, accesându-l va fi
trimis într-o pagină în care își poate introduce noua parolă, și confirmarea acesteia. Procesul
din spate este ilustrat în figura 6.9.

Figura 6.9 Resetarea parolei

Se observă cum mai întăi se obține numele de utilizatorul a celui care a făcut cererea, apoi se
verifică dacă username-ul este unul valid. După aceasta se validează dacă parola are formatul
necesar (parola trebuie să conțină minim 8 caractere, dintre care o literă mare, o literă mică,
un număr și un caracter special. Apoi se verifică dacă parola corespunde cu introducerea sa
încă o dată, în câmpul alocat pentru asta.

În cazul în care una din aceste verificări nu se validează, se trimite către frontend un mesaj de
eroare în format HTTP (în acest caz un BadRequestException). Aceste erori se vor trimite
peste tot în aplicație unde apar neregului. BadRequestException este o eroare mai generală,
existând și AuthentificationException (pentru probleme de autentificare) și EntityNotFound
(pentru când nu se pot întoarce datele cerute).

Mai jos voi exemplifica eroarea de tip BadRequestException:

Figura 6.10 BadRequestException

40
Deci se va crea o eroare de tip „Bad Request” cu statusul UNAUTHORIZED și mesajul dat ca
parametru.

În cazul în care nu există erori, controllerul va trimite către frontend un răspuns în format
JSON, cu statusul 200 (OK).

Figura 6.11 Cererea datelor unui utilizator în Controller

Precum este exemplificat în figura 6.11, cu ajutorul bibiliotecii GSON, se va converti răspunsul
trimis de service cererii din Controller, în obiect String cu formatul JSON, și se va întoarce către
către server.

Probabil cea mai provocatoare parte a realizării aplicației a fost reprezentată de realizarea
algoritmului de potrivire între donori și recipienți, ținând cont de toți factorii evidențiați în
capitolele anterioare.

În anexele 1, 2, 3 și 4 sunt expuse metodele folosite pentru acest proces.

În Anexa 1, este prezentată modalitatea cum se realizează căutarea de potriviri pentru donori.
Se ține cont de poziția geografică, căutând mai întâi în aceeși instituție, apoi în același oraș, și
dacă organele care au rămas o permit, în același județ și regiune. Se ordonează recipienții în
funcție de prioritate și data adăugării, iar apoi se verifică celelaltă criterii comparând
donatorul cu recipientul, cu funcția isMatch, prezentată în Anexa 3.

În Anexa 2, se află metoda similară pentru recipienți, se ține cont din nou de poziția
geografică, și se verifică celelalte aspecte cu funcția isMatch.

Anexa 3 prezintă funcția isMatch, în care se verifică dacă donorul are toate organele necesare
recipientului, și celelalte aspecte, precum greutate, grupă de sânge, înălțime, detaliile
specifice rinichilor, etc.

Anexa 4 arată modalitatea prin care se realizează controlul grupei de sânge.

41
Problema ridicată de această abordare a provenit din faptul că, în momentul în care nu se
poate confirma o potrivire, în urma stergerii acesteia și reîncercarea căutării de potriviri, de
cele mai multe ori se obține din nou un match între aceeași utilizatori.

Figura 6.13 Adăugarea perechilor în Blacklist

Pentru a rezolva acest lucru s-a creat o tabelă Blacklist, și la stergerea potrivirilor, se va reține
aici perechea de utilizatori pentru a se evita acest caz, cum se poate vedea în figura 6.13.
Tabela va fi golită pe parcursul plecării recipientilor din organizația, pentru a evita
aglomerarea cu timpul.

6.2 Implementarea pe partea de frontend

Pe partea de frontend, implementarea s-a făcut definind fiecare pagină, anumite elemente
fiind mai ușoare definit, iar altele, mai dificile.

În primul rând, validarea datelor introduce în formulare s-a făcut în funcții, prin erori și
avertizări afișate apoi pe câmpuri.

Figura 6.14 Verificări pe frontend

42
În figura 6.14 se poate observa funcția de salvare a datelor introduce la schimbarea adresei
de email. Se fac verificări pentru a avea date concrete, și se afișează utilizatorului prin
variabilele error.

Figura 6.15 Gestionarea erorilor venite de la backend

În continuare în figura 6.15, este vizibil cum frontend-ul gestionează erorile semnalate de
backend, afișând din nou erorile pe câmpurile formularului, pentru a putea fi gestionate de
utilizatorul care încearcă să își schimbe emailul.
Un alt lucru de menționat este procesul de delogare din aplicație. Pe lângă momentul în care
se deloghează utilizatorul din butonul de logout, la fiecare cerere, cum se poate vedea și în
exemplul de mai sus, se verifică dacă există vreo eroare și dacă aceasta provine de la faptul
că token-ul a expirat.

Figura 6.16 Procesul de logout

43
În figura 6.16 e reprezentat procesul de logout, se observă cum se face cerere de logout, apoi
se redirecționează aplicația către pagina de login.
O altă problemă apărută pe partea de frontend a fost la afișarea listelor. Mai exact, în
momentul în care există foarte multe elemente de afișat într-o listă, durează mult până se
găsește intrarea căutată. De aceea s-a decis să se introducă un filtru în listele care pot ajunge
să conțină foarte multe intrări.

Figura 6.17 Filtru pe lista cu utilizatorii unei instituții

Ca exemplu, așa cum este vizibil și în figura 6.17, pentru listele cu utilizatori, se pot filtra
rezultatele după nume de utilizator, status, rol, nume și prenume. Aceste lucruri pot fi utile
atât atunci când se caută un user anume, cât și atunci când se caută un grup: de exemplu când
se dorește să se verifice utilizatorii care așteaptă aprobarea de a utiliza aplicația.
Per total, pe frontend au contat mult micile detalii, pentru a realiza o interfață cât mai clară
și ușor de utilizat.

44
7 EVALUAREA REZULTATELOR
Testarea aplicației s-a realizat în trei feluri: în Postman și Java (pentru backend) și direct din
browserul web (pentru frontend).

În cazul testării în Postman, procesul a fost unul manual, s-au testat cererile care se fac de la
frontend către backend, în diferite forme, pentru a vedea dacă toate excepțiile ce pot apărea
pe parcurs sunt bine gestionate.

Figura 7.1 Exemplu de testare în Postman

După cum se vede în exemplul din figura 7.1, în Postman se pot testa nu doar cazurile bune,
dar și cele care ridică probleme, precum încercarea de logare cu un nume de utilizator care
nu se află în baza de date.

În cadrul testării automate realizate în Java, s-au definit o serie de teste la nivelul claselor de
tip Service, pentru a verifica diferite funcționalități.

Figura 7.2 Exemplu de testare în Java

45
Asa cum se poate vedea în figura 7.2, testarea în Java a permis de asemenea și verificarea
cazurilor bune, dar și a excepțiilor.

Pe frontend testarea s-a făcut din browser, așa cum s-a explicat și mai sus, pentru a permite
interacțiunea cu interfața și a verifica factorii care contează în acest domeniu: responsive-
ness-ul, portabilitatea etc.

Per total, se poate spune că aplicația își îndeplinește cerințele stabilite la începutul acestei
lucrări: este un sistem închis, în care utilizatorii obișnuiți au foarte puține drepturi, totul fiind
administrat de utilizatorii cu rol privilegiat.

De asemenea, aplicația reusește să creeze potriviri între pacienții de tip recipient și cei de tip
donor, atât în mod specific, dar și, cel mai important, în mod automat pentru potrivirile la
care este necesară o căutare în sistem.

Există procese automate de mentenență (de exemplu, curățarea datelor vechi din baza de
date a aplicației) care permin aplicației să aibă o funcționare optimă și îmbunătățesc
performața acesteia.

Un punct slab al aplicației ar putea fi reprezentat de autentificarea cu username și parolă pe

bază de JWT Token, având în vedere că securitatea sistemului este extrem de importantă. O
autentificare în 2 pași ar fi și mai potrivită, pentru a spori securitatea.

Din păcate, deoarece nu există sisteme de acest gen pe piață (sau cel puțin, nu disponibile
publicului larg) nu este posibilă realizarea unei comparații un sistem asemănător.

46
8 CONCLUZII
Digitalizarea lumii se întâmplă fără îndoială constant, aproape fiecare domeniu de activittate
umană încearcă să automatizeze și să scaleze procesele, acolo unde există această
posibilitate.

Pe plan medical, mai ales în România, există mii de astfel de posibilități, în special ținând cont
de precipitarea cu care astfel de lucruri se întâmplă de obicei.

Aplicația prezentată în această lucrare încearcă să dovedească că procesul acesta vine cu

multe avantaje, principalul fiind chiar câștigarea timpului. Ori în medicină în special, timpul
este un element de maximă importanță și orice câștig în acest sens ar trebui să fie binevenit.

Prin felul în care gestionează atât combinația între expertiza umană și avantajele lumii
digitale, acest proiect prezintă automatizare acolo unde este necesar, dar și prelucrare a
indivizilor umani pentru a lansa un proces cu beneficii multiple.

Sistemul închis și felul în care aplicația își gestionează utilizatorii este de asemenea un factor
de luat în seamă, potrivit în opinia mea pentru un astfel de proces.

Mentenanța automată și filtrarea elementelor în unele dintre procese asigură evitarea

supraîncărcării și irosirii timpului în căutarea unor date, câștigând din nou ce este cel mai
important: timp.

Nu în ultimul rând, automatizarea procesului de căutare a potrivirilor este marele atu al

aplicației, punctul principal cum s-ar spune.

În concluzie, consider că aplicația de față îndeplinește scopul pentru care a fost creată: o
încercare de gestionare a donării de organe în instituțiile medicale. Firește, există multe
lucruri care pot fi îmbunătățite, dar, în opiinia mea, lucrul cel mai important este că dovedește
că, și în domeniul medical, există posibilitatea ca oamenii să colaboreze cu mașinile la un nivel
cât mai înalt.

47
9 BIBLIOGRAFIE

[1] M. A. Makari și M. Daniel, „Medical error—the third leading cause of death in the US,”
The BMJ, vol. 353, nr. 8056, pp. 21-39, 2016.

[2] H. K. S. Saidi RF, „Challenges of organ shortage for transplantation: solutions and
opportunities,” Int J Organ Transplant Med, vol. 5, nr. 3, pp. 87-96, 2014.

[3] R. Beyar, „Challenges in Organ Transplantation,” Rambam Maimonides Med J, vol. 2, nr.
2, 2011.

[4] R. M. M. J. Verheijde JL, „Recovery of transplantable organs after cardiac or circulatory

death: transforming the paradigm for the ethics of organ donation,” Philos Ethics
Humanit Med, vol. 2, nr. 8, 2007.

[5] E. M. Hsich, „Matching the Market for Heart Transplantation,” Circulation: Heart Failure,
vol. 9, nr. 4, pp. 951-964, 2016.

[6] N. Lanesse, „How Long Can Organs Stay Outside the Body Before Being Transplanted? -
LiveScience,” 29 12 2019. [Interactiv]. Available: https://www.livescience.com/how-
long-can-donated-organs-last-before-transplant.html. [Accesat 13 6 2021].

[7] U.S. Government, „organdonor.gov,” 6 6 2020. [Interactiv]. Available:

https://www.organdonor.gov/about/process/matching.html. [Accesat 12 6 2021].

[8] H. C. e. al., „Donor heart and lung procurement: A consensus statement,” The Journal
Of Heart And Lung Transplantation, vol. 39, nr. 6, pp. 501-517, 2021.

[9] V. J. V. J. R. M. Reddy MS, „Matching donor to recipient in liver transplantation:

Relevance in clinical practice.,” World J Hepatol, vol. 5, nr. 11, pp. 603-611, 2013.

[10] B. H.-K. J. v. d. K. A. W. W. W. Kristiaan Glorie, „Allocation and matching in kidney

exchange programs,” Transplant International, vol. 27, nr. 4, pp. 333-343, 2014.

[11] J. M. P. M. C. T. S. D.-M. P. M. L. H. B. G. M. Thierry Berney, „Impact of HLA matching on

the outcome of simultaneous pancreas–kidney transplantation,” Nephrology Dialysis
Transplantation, vol. 20, nr. suppl_2, pp. ii48-ii53, 2005.

[12] U.S. Government, „organdonor.gov,” 6 6 2020. [Interactiv]. Available:

https://www.organdonor.gov/about/process/living-donation.html. [Accesat 13 6
2021].

48
[13] R. B. O. F. J. D. R. J. D. P. J. B. Halldorson, „D-MELD, a Simple Predictor of Post Liver
Transplant Mortality for Optimization of Donor/Recipient Matching,” American Journal
Of Transplantation, vol. 9, nr. 2, pp. 318-326, 2009.

[14] T. Branson, „8 Major Advantages of Using MySQL - DataMation,” 16 11 2016.

[Interactiv]. Available: https://www.datamation.com/storage/8-major-advantages-of-
using-mysql/. [Accesat 11 6 2021].

[15] A. Davies, „Why Should You Use Java for Your Backend Infrastructure? -
DevTeam.Space,” 24 9 2020. [Interactiv]. Available:
https://www.devteam.space/blog/why-should-you-use-java-for-your-backend-
infrastructure/. [Accesat 24 6 2021].

[16] K. Chandrakant, „Why Choose Spring as Your Java Framework? - Baeldung,” 13 12 2019.
[Interactiv]. Available: https://www.baeldung.com/spring-why-to-choose. [Accesat 10 6
2021].

[17] N. Pandit, „What and Why React.js - C-SharpCorner,” 10 2 2021. [Interactiv]. Available:
https://www.c-sharpcorner.com/article/what-and-why-reactjs/. [Accesat 10 6 2021].

49
10 ANEXE
Anexa 1 – Potrivirile pentru donori

50
51
Anexa 2: Potrivirile pentru recipienți

52
53
Anexa 3: Verificări între donor și recipient

54
Anexa 4: Verificarea grupei de sânge

55
56