1.Introducere ………………………….. ………………………….. ………………………….. …………………………….. [626442]
UNIVERSITATEA POLITEHNICA BUCUREȘTI
FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
DEPARTAMENTUL CALCULATOARE
PROIECT DE DIPLOMĂ
Gestiune servicii medicale
Coordonator științific:
Prof. Florin R ădulescu
Absolvent: [anonimizat]
2013
Cuprins
1.Introducere ………………………….. ………………………….. ………………………….. ………………………….. …………………. 3
2.Arhitectura aplicației ………………………….. ………………………….. ………………………….. ………………………….. ……. 5
2.1 Arhitectura Client/Server ………………………….. ………………………….. ………………………….. ……………………. 5
2.2 Arhitectura logică ………………………….. ………………………….. ………………………….. ………………………….. ….. 5
3. Proiectarea bazei de date ………………………….. ………………………….. ………………………….. ………………………….. 7
3.1 Descrierea bazei de date ………………………….. ………………………….. ………………………….. ……………………… 7
3.2 Diagrama relațiilor ………………………….. ………………………….. ………………………….. ………………………….. . 11
4. Descrierea tehnologiilor utilizate ………………………….. ………………………….. ………………………….. …………….. 13
4.1 Java EE și Java SE ………………………….. ………………………….. ………………………….. ………………………….. . 13
4.2 Spring Framework ………………………….. ………………………….. ………………………….. ………………………….. .. 13
4.3 Java Persistence API ………………………….. ………………………….. ………………………….. ………………………… 15
4.4 Hibernate ………………………….. ………………………….. ………………………….. ………………………….. ……………. 18
4.5 Oracle ………………………….. ………………………….. ………………………….. ………………………….. ………………… 18
4.6 Ma ven………………………….. ………………………….. ………………………….. ………………………….. ………………… 18
4.7 Apache Tomcat ………………………….. ………………………….. ………………………….. ………………………….. …… 19
4.8 JavaServer Pages ………………………….. ………………………….. ………………………….. ………………………….. …. 19
4.8 HTML, CS S ………………………….. ………………………….. ………………………….. ………………………….. ……….. 20
4.9 JavaScript, jQuery, Ajax ………………………….. ………………………….. ………………………….. …………………… 20
4.10 Hypertext Transfer Protocol ………………………….. ………………………….. ………………………….. …………….. 21
5. Descrierea aplica ției ………………………….. ………………………….. ………………………….. ………………………….. ….. 22
5.1 Modulul admin ………………………….. ………………………….. ………………………….. ………………………….. ……. 22
5.2 Modulul secretar ………………………….. ………………………….. ………………………….. ………………………….. ….. 25
5.3 Modulul medic ………………………….. ………………………….. ………………………….. ………………………….. ……. 29
5.4 Modulul asistent ………………………….. ………………………….. ………………………….. ………………………….. ….. 31
5.5 Modulul laborant ………………………….. ………………………….. ………………………….. ………………………….. …. 31
5.6 Mo dulul medic imagistică ………………………….. ………………………….. ………………………….. …………………. 33
5.7 Modulul client ………………………….. ………………………….. ………………………….. ………………………….. …….. 34
6. Detalii de implementare ………………………….. ………………………….. ………………………….. …………………………. 35
6.1 Nivelele aplicației ………………………….. ………………………….. ………………………….. ………………………….. … 35
6.2 Fișiere de configurare ………………………….. ………………………….. ………………………….. ……………………….. 36
7. Concluzii și îmbunătățiri viitoare ………………………….. ………………………….. ………………………….. …………….. 38
8. Bibliografie și referințe ………………………….. ………………………….. ………………………….. ………………………….. 39
8.1 Referințe ………………………….. ………………………….. ………………………….. ………………………….. …………….. 39
8.2 Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ………… 39
9. Anexa: Listing aplicație ………………………….. ………………………….. ………………………….. …………………………. 40
Adela -Mihaela Alecu
2
Figura 1: Procesarea cererilor HTTP de către DispatcherServlet ………………………….. ………………………….. ………… 5
Figura 2: Relațiile dintre tabelele bazei de date ………………………….. ………………………….. ………………………….. … 12
Figura 3: Logare ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 22
Figura 4: Pagina de afișare a locațiilor ………………………….. ………………………….. ………………………….. ……………… 23
Figura 5: Pop -up ștergere ………………………….. ………………………….. ………………………….. ………………………….. ….. 24
Figura 6: Editare locație ………………………….. ………………………….. ………………………….. ………………………….. …….. 24
Figura 7: Pacienți ………………………….. ………………………….. ………………………….. ………………………….. ……………… 26
Figura 8: Adăugare programare ………………………….. ………………………….. ………………………….. ………………………. 27
Figura 9: Calendar ………………………….. ………………………….. ………………………….. ………………………….. …………….. 27
Figura 10: Vizualizare programări ………………………….. ………………………….. ………………………….. ……………………. 28
Figura 11: Detalii plată ………………………….. ………………………….. ………………………….. ………………………….. ………. 28
Figura 12: Afișa re programări în modulul medic ………………………….. ………………………….. ………………………….. .. 29
Figura 13: Adăugare consultație ………………………….. ………………………….. ………………………….. ……………………… 30
Figura 14: Afișare analize în modulul asistent ………………………….. ………………………….. ………………………….. …… 31
Figura 15: Afișare analize în modulul laborant ………………………….. ………………………….. ………………………….. ….. 32
Figura 16: Completare rezultate analize ………………………….. ………………………….. ………………………….. …………… 32
Figura 17: Afișare programări în modulul medic imagistică ………………………….. ………………………….. …………….. 33
Figura 18: Servicii de imagistică recomandate ………………………….. ………………………….. ………………………….. ….. 33
Figura 19: Editare consultație imagistică ………………………….. ………………………….. ………………………….. ………….. 33
Figura 20: Istoric medical pacient ………………………….. ………………………….. ………………………….. ……………………. 34
Figura 21: Detalii consulta ție ………………………….. ………………………….. ………………………….. ………………………….. 34
Gestiune servicii medicale
3
1. Introducere
Lucrarea de față are ca temă “Gestiunea serviciilor medical e” și își propune îmbunătăț irea
eficie nței serviciilor puse la dispoziție în cadrul unui lanț de clinici medicale. Aplicația vine atât î n
ajutorul personalu lui angajat, cât și în ajutorul pacienț ilor.
Aplicația prezentată este o aplicație web care poate fi rulată folosind orice navigator cum ar
fi Interne t Explorer, Mozilla sau altele asemănătoare celor menț ionate. Datorită acestui fapt, față de
o aplicație d esktop, comunicarea î ntre diferit ele sedii ale clinicilor va fi îmbunătățită, acestea avâ nd
acces la un set de date manipulat prin intermediul unei baze de date Oracle.
Pentru a crește încrederea pacienților în serviciile oferite și pentru a le demonstra c ă în
centrul întregii activități se află mulțumirea clientului, aplicația pune la dispoziția pacienț ilor
posibilitatea de a avea acces la toate informaț iile referitoare la serviciile care le -au fost oferite, la
tratamentele prescrise , la analizele recomand ate ș i rezultatele lor. Astfel, pacientul nu este
condiț ionat de serviciile din cadrul clinici i, are posibilitatea de a renunța la acestea î n orice moment
sau de a cere o altă opinie medicală de la un medic din afara clinicii. Acest fapt reprezintă un plus
față de majoritatea aplicațiilor existen te deja î n domeniu l medical. Din propria experiență, nu am
întâlnit până acum o clinică în care să am ac ces complet la informaț iile referitoare la istoricul meu
medical . Majoritatea clinicilor oferă d oar posibilitat ea de a vizualiza rezultatele analizelor de
laborator realizate. Pentru binele pac ientului, indicat ar fi ca toată informația să fie transparen tă,
astfel încâ t un alt medic, din afara clinicii să nu fie nevoit să supună clientul unor investigaț ii pentru
care rezultatele există deja, sau unui tratamen t pe care acesta deja l -a mai fă cut și care i -ar putea
dăuna. Trebuie ținut cont de faptul că pacienții sunt personae fără prea multe cunoștiințe î n
domeniul medical. De ace ea, existen ța unui istoric med ical, ar ajuta viitorii medici î n ofer irea unor
servicii de calitate în funcție de nevoile pacientului și totodată ar scuti pacienț ii de reluar ea unor
investigații la care deja au fost supuș i.
Sistemul prezent are o interfață p rietenoasă , simplă , intuitivă, astfel încât factorul uman să
poată interacționa cu aceasta într -un mod câ t mai facil. Utilizatorii aplicației nu trebuie să dețină
decât informaț ii de bază despre utilizarea unui calculator și despre navigarea î n cadrul unui site web.
Pentru fiecare tip de util izator, produsul conț ine un modul separat car e are ca rol punerea la
dispoziție în timp real a acțiunilor necesare satisfacerii tuturor necesităț ilor acestuia. Aplicația î și
propune să ofere suport pentru toate operațiile care se pot desfășura î n cadrul un ei clinici medicale,
ea fiind dedicată urmă toarelor tipuri de utilizatori: medici, m edici din centrele de imagistică ,
personalul responsabil cu recoltarea probelor pentru analize , medici responsabili cu interpretarea
rezultatelor a cestora, personalul de la recepț ie, administratorul clinicilor și pacienț i. Pentru ușurința
utiliză rii, accesul la fiecare dintre modulele aplicaț iei se va face prin autentificare , fiecare utilizator
având acces doar la modulul dedicat rolului său î n cadrul clinicii.
Aplicația de față își propune urmă toarele:
Creș terea accesibilității: În cazul unei aplicaț ii de tip desktop, aceasta trebuie să fie instalată
pe calculatorul de pe care utilizatorul va lucra , accesul la informaț ie fiind dependent de
stația de lucru ș i de orele de prog ram. În cazul acestei aplicații, nu este necesară instalarea,
ci doar existenț a unei conexiuni la interne t, utilizatorul nemaifiind condiț ionat de
calculatorul personal . În plus, aceasta va putea fi accesată î n orice moment al zilei.
Asigurarea securităț ii, prin autentificare a pe bază de utilizator și parolă .
Adela -Mihaela Alecu
4
Micșorarea timpilor de lucru: Me dicii au acces la toate informaț iile relevante cu privire la
pacient pe un singur ecran, prin accesarea istoricului medical al acestuia . Nu va mai fi
necesar transferu l dosarelor fizice și căutarea î n acestea.
Îmbunătățirea decizi ilor medicale: Având acces la consultațiile și tratamentele anterioare,
medicii pot găsi anumite corelații cu simptomele prezente, crescând astfel șansa ca
diagnosticul stabilit și tratamentul p rescris să fie cele corecte.
Simplificarea mentenanței: Administratorul va avea acces la toate informațiile necesare
administrării clinicilor, acestea fiind grupate pe următoarele categorii: locații, angajați,
specialități servicii, specialități angajați ș i program. Administratorul va fi singurul care va
avea drepturi de adăugare,editare și ștergere asupra acestora.
Reținerea unui volum ridicat de date: pentru fiecare consultație se vor reține în baza de
date: observațiile medicului, tratamentul prescris, m odul și durata de administrare a
acestuia, serviciile puse la dispoziție în cadrul consultației, analizele de laborator prescrise și
serviciile de imagistică recomandate.
Îmbunătățirea sistemului de plată a serviciilor: pentru fiecare consultație în parte se va
calcula automat suma pe care pacientul va trebui să o achite la ieșirea din cabinet, iar
marcarea achitării acesteia se va realiza printr -un singur click.
Gestiune servicii medicale
5
2. Arhitectura aplicației
2.1 Arhitectura Client/Server
Orice aplicație w eb obișnuită presupune existenț a a trei componente: un server web, un
server de aplicație ș i un server de baze de date. Fiecare dintre aceste component e captează
mesajele ce conț in cereri care trebuie executate, printr -un anumit port TCP/IP .
Prelucrarea un ei cereri începe cu emiterea acesteia de către browser pentru o anumită
resursă . Cererea este apoi preluată de că tre serverul web pe portul 80, urmând să fie transmisă apoi
de către aplicaț ia existent ă pe server că tre serverul de baze de date. Odată ce ră spunsul este
asamblat, acesta este trimis î napoi la browser -ul de la care a provenit.
În cazul aplicației de față serverul web folosit este Apache Tomcat 6.0 .29, iar ca server de
baze de date s -a folosit Oracle11g.
2.2 Arhitectura logică
Aplicația are la b ază modelul architectural MVC(Model View Controller). Acest model vine
în ajutorul dezvoltării aplicaț iilor complexe, deoarece real izează o bună separare a celor trei
componente, făcând mult mai ușoară organizarea codului, î ncapsularea acestuia în funcții și
dezvoltarea sa ulterioară :
Componenta Model este componenta responsabilă cu m anipu larea datelor cu care lucră m.
Componenta View se referă la ceea ce vedem î n browser .
Componenta Controller este cea care asigură control ul asupra paginilor care se afișeaz ă în
browser în funcție de link -ul accesat ș i asupra datelor din model care vor fi accesate.
În centr ul acestei arhitecturi, se află un DispatcherServlet care are rolul de a manipula toate
cererile și răspunsurile de tipul HTTP. Workflow -ul pro cesării cer eriilor de că tre Dispa tcherServlet
este reprezentat î n figura de mai jos [1]:
Figura 1: Procesarea cererilor HTTP de către DispatcherServlet
Adela -Mihaela Alecu
6
Evenimentele corespunzătoare unei cereri HTTP, așa cum se obser vă și î n Figura 1 sunt [1]:
După primirea unei cereri HTTP, DispatcherServlet consultă HandlerMapping pentru a apela
component a Control ler necesară .
Componenta Controller primește cererea și apelează meto dele de tipul service
corespunză toare, folosind metodele GET si POST .
Dispa tcherServlet, cu ajutorul componentei ViewResolver va alege view -ul corespunză tor
cererii .
Odată ce view -ul este ales, DispatcherServlet va pasa datele din component a Model view –
ului, afișându -se astfel în browser informaț iile din view -ul ales.
Gestiune servicii medicale
7
3. Proiectarea bazei de date
Aplicația de față are în fundal o bază de date implementată pe un server de baze de date
Oracle. Î n continuare voi prezenta structura bazei de date precum și o diagramă a relațiilor î ntre
tabele le compo nente, pentru o mai bună î nțelegere a acestora.
3.1 Descrierea bazei de date
3.1.1 Clinical_services
Tabela clinical_services conține informaț iile referitoa re la servicile puse la dispoziție î n cadrul
clinicilor medicale. Aceste servicii pot fi de trei fel uri: analize de laborator( cele care tre buie făcute î n
cadrul laboratoarelor ex istente), servicii de imagistică (cele care trebuie fă cute în cadrul centrelor de
imagistică) și serviciile care nu se încadrează î n nici una din primele 2 categorii (c ele care pot fi puse
la dispoziție de medic î n cadrul policlinicii și nu necesită o recomandare).
Coloanele tabelei sunt:
– clinicalServiceI d number(19): este cheia primară a tabelei și conț ine i d-ul serviciului pus la
dispoziț ie;
– name varchar(255 char): numele serv iciului pus la dispoziț ie;
– duration number(10): câmp folosit în cazul în care serviciul constă într -o analiză de
laborator, reprezentând durata necesară obț inerii rezultatului aferent analizei ;
– unit varchar(255 char): câmp folosit în cazul în care serviciu l constă într -o analiză de
laborat or, pentru a reține unitatea de mă sură aferentă anali zei respective;
– price float(126): prețul serviciului pus la dispoziț ie;
– serviceSpecialityId_F K number(19): este cheie externă ș i face legă tura cu ta bela
services_special ities, conținâ nd categoria de servicii din c are face parte serviciul de față .
3.1.2 Services_specialities
Tabela services_specialities conține informaț iile referitoare la categoriile de servicii pe care
clinica le poate pune la dispoziția clientului. Tabel a conț ine urm ătoarele coloane:
– serviceSpecialityI d number(19): este cheie primară și conț ine id -ul categoriei ;
– name varchar(255 char): numele categoriei ;
– type varchar(255 char): tipul categoriei. Acesta poate avea 3 valori: Labo rator, Policlinica și
Imagis tica;
3.1.3 Users_specialities
Tabela users_specialities conține specialitățile pe care le pot avea angajaț ii din cadrul
clinicilor. Coloanele acesteia sunt:
– userSpecialityI d number(19): este cheie primară și conține id -ul specialităț ii;
– name varc har(255 c har): numele specialităț ii;
– type va rchar(255 char): tipul sp ecialităț ii. Acesta poate lua va lorile: Laborator(pentru
angajații care se ocupă de recoltarea probelor ș i interpretarea lor), Policlinica(pentru
angajații care se ocupă de realizarea consultaț iilor), Imagistica(pentru a ngajații care se ocupă
Adela -Mihaela Alecu
8
de serviciile de imagistică) și Alte le(pentru angajații care nu se î ncadrează î n nici una din
categoriile anterioare).
3.1.4 Programs
Tabela programs conț ine toate program ele de lucru posibile pentru toți anga jații clinicilor.
Coloanele acesteia sunt:
– programI d number(19): este cheia primară și conț ine id -ul programului ;
– day varchar(255 char): ziua în cadrul săptămâ nii;
– startime number(10): ora de î nceput ;
– endtime number(10): ora de sfârș it;
3.1.5 Offices
Tabel a offices conț ine in formaț ii despre toate sed iile existente. Coloanele acesteia sunt:
– officeI d number(19): este cheia primară și conține id -ul locaț iei;
– address varchar(255 char): adresa locaț iei;
– descrip tion varchar(255 char): o scurtă descriere a locaț iei;
– name varchar( 255 char): numele locaț iei;
– picture varchar(25 5 char): numele pozei corespunzătoare locaț iei;
– type varchar(255 char): tipul locaț iei. Acesta poate lua v alorile: Laborator, Imagistica ș i
Policlinica .
3.1.6 Users
Tabela users conține toate in formaț iile des pre toți angajaț ii din toate sed iile. Coloanele
acestei tabele sunt:
– userI d number(19): este cheia primară și reprezintă id-ul angajatului ;
– cnp varchar(255 char): codul numeric personal al angajatului ;
– firstName varchar(255 char): prenumele a ngajatului ;
– lastN ame varchar(255 char): numele angajatului ;
– hiredate timestamp(6): data angajă rii;
– phoneNumber varchar(255 char): numă rul de telefon al angajatului ;
– picture varchar(25 5 char): numele pozei corespunză toare angajatului ;
– username varchar(255 c har): numele de uti lizator necesar pentru logarea în aplicaț ie a
angajatului. Implicit acesta va fi de forma: lastName.firstName, putâ nd fi schimbat ulterior ;
– password va rchar(255 char): parola folosită împreună cu username -ul pentru logarea în
aplicaț ie. Implicit aceasta va fi: lastName.ultimele 6 cifre din codul numeric personal ;
– role varchar(255 char): coloana în care se reț ine rolul angaja tului. Acesta poate avea valori le:
Medic, Asistent(cel care se ocupă de prelevarea probelor pentru analizele de labo rator),
Laborant(cel care se ocupă cu interpretarea probelor recolt ate), Secretar(cel care se ocupă
cu primirea pacienților, adăugarea de rezervări ș i de clienț i noi) și Admin(cel care realizează
operaț ii de administrare) ;
– officeId_FK number(19): este chei e externă și face legătura cu tabela offices, conținând id -ul
locației în care lucrează angajatul .
Gestiune servicii medicale
9
3.1.7 Pacients
Tabela pacients conține informaț iile des pre toț i pacientii clinicii, avâ nd urmă toarele
coloane:
– pacientI d number(19): este cheie primară ș i reprezintă id-ul pacientului ;
– address varchar(255 char): adresa pacientului ;
– birthday timestamp(6): data naș terii;
– cnp varchar(255 char): codul numeric personal al pacientului ;
– phoneNumber varchar(255 char): numă rul de telefon ;
– firstName varchar(255 char): n umele pacientului ;
– lastName varchar(255 char): prenumele pacientului ;
– email varchar(255 char): adresa de email a pacientului ;
– startDate timestsamp(6): data înscrierii pacientului î n cadrul clinicii ;
– username varchar(255 char): numele de utilizator folosit de pacient la logare, pen tru a avea
acces la istoricul să u medical. Implicit, numele de utilizator este de forma:
lastName.firstName, acesta putâ nd fi schimbat ulterior ;
– password varchar(255 char): parola, care este necesară pentru a permite logarea
pacientului. Implicit, parola va fi: frstN ame.ultimele 6 cifre din codul numeric personal.
3.1.8 Reservations
Tabela reservations conține informaț iile necesar e pentru realizarea unei programări .
Coloanele acesteia sunt:
– reservationId number(19): este c heie prim ară și reprezintă id -ul programării ;
– reservationDate timestam p(6): data pentru care a fost făcută programare a;
– reservationHour numbe r(10): ora pentru care a fost făcută programarea ;
– reservationMinute number(10): minutul din cadrul orei pentru care a fost făcută
programarea ;
– status var char(255 char): statusul programării . Acesta poate avea două valori: noua(la
crearea programării ), prezent(atunci când pacientul se prezi ntă pentru programare );
– officeId_F K number(19): este cheie externă ș i face legătura cu tabela offices, conținând id -ul
locației unde pacientul va trebui să se prezinte pentru programarea făcută ;
– pacientId_F K number(19): este cheie externă și face legătura cu tabela pacients, conținând
id-ul pacientului care dorește să facă programarea ;
– userId_F K number(19): este cheie externă și f ace legătura cu tabela users, conținâ nd id -ul
mediculu i la care pacientul va trebui să se prezinte .
3.1.9 Consultations
Tabela consultations conține informațiile despre toate consultaț iile realizate. Coloanele
acesteia sunt:
– consultationI d number(19): este cheie primară și reprezintă id -ul consultaț iei;
– consultationData timestamp(6) : data în care s -a făcut consultaț ia;
– consultationHour number(10): ora la care pacientul a fost consultat ;
– consultationMinute number(10): minutul din cadru l orei, la care a fost realizată consultaț ia;
Adela -Mihaela Alecu
10
– observation clob: observaț iile notate de me dic privind starea pacientului și concluziile în
urma consultaț iei;
– treatment clob: tratamentul prescris de medic, î n urma con sultaț iei;
– pacientId_FK: este cheie externă și face legă tura cu tabela pacients, reprezentâ nd id -ul
pacient -ului care a fost consultat ;
– userId_FK: este cheie externă, fă când legă tura cu tabela users și reprezintă id-ul use r-ului
care a realizat consultaț ia.
3.1.10 Services_list
Tabela services_list conține informaț ii despre serviciile puse la dispoziție de medic în cadrul
unei consultații. Aceasta conține urmă toarele coloane:
– serviceListI d number(19): este cheia primară ș i reprezin tă id-ul serviciului;
– serviceLis tData timestamp(6): data î n care serviciul a fost pus la d ispoziț ie;
– consultationId_F K number(19): este cheie externă și face legă tura cu tabela consultations,
reprezentând id -ul consultației în cadrul că reia serviciul a fost oferit de că tre medic ;
– clinicalServiceId_F K number(19): este cheie externă și face legă tura cu tabe la
clinical_services, reprezentâ nd id -ul serviciului oferit de medic în cadrul consultaț iei.
3.1.11 Medical_imaging
Tabela m edical_imaging cuprinde informaț iile despre servi ciile de imagistică recomandate
de medic în cadrul unei consultaț ii. Col oanele acestei tabele sunt:
– medicalImagingI d number(19): este cheie primară și reprezintă id-ul servi ciului ;
– medical ImagingData timestamp(6): data î n care pacientul a beneficiat de serviciul de
imagistică ;
– observation clob: observațiile care pot fi fă cute de cel care pune la dispoziție serviciul de
imagistică pacientului ;
– status varchar(255 char): statusul în care se află serviciul recomandat. Acesta poate lua
valorile: recomandat( inițial), editat(atunci când pacientul se prezintă și se adaugă
observații), terminat(atunci câ nd pacientul p ărăsește încăperea, odată ce a bene ficiat de
serviciul de imagistică recomandat );
– clinicalServiceId_FK number(19) : este cheie externă, fă când legătura cu tabela
clinical_services ;
– consultatioId_F K number(19): este cheie exte rnă și face legă tura cu tabela consultations,
reprezentând id -ul consultației în cadrul căreia serviciul de imagistică a fost recomandat.
3.1.12 Laboratory_analysis
Tabela lab oratory_analysis conț ine analizele recomandate de medic în cadrul consultațiilor ,
având urmă toarele coloane:
– laboratoryAnalyzeI d number(19): este cheia primară și reprezintă id-ul analizei ;
– laboratoryAnalyz eData timestamp(6): data recoltă rii probelor ;
– maxV alue float(126): valoarea maximă corespunzătoare vârstei ș i sexului pacientului ;
– minV alue float(126): valoarea minimă corespunzătoare vârstei ș i sexului pacientului ;
– value float(126): rezultatul mă surat ;
Gestiune servicii medicale
11
– status varchar(255 char): statusul î n care se află analiza recomandată . Acesta poat e avea
valorile: recomandat(inițial), recoltat(at unci când pacientul se prezintă pentru recoltarea
probelor) și terminat(la obț inerea rezulta tului analizei) ;
– clinicalServiceId_FK number(19) : este cheie externă fă când legă tura cu tabela
clinical_services;
– consultationId_FK number(19) : este cheie externă ș i face legă tura cu tabela consultations,
reprezentând id -ul consultației în cadrul căreia analiza a fost recomandată .
3.1.13 Payments
Tabela payments conț ine datele d espre plățile pe care pacienții trebuie să le realizeze p entru
servici ile puse la dispozi ție. Coloanele acestei tabele sunt:
– paymentId: este cheie primară și reprezintă id -ul plăț ii;
– paymentDate timestamp(6): data în care plata a fost realizată de că tre client ;
– status varchar(255 char): statusul plăț ii. Acesta poate fi: neachitat(iniț ial), ach itat(după
efectuarea plaț ii);
– type varchar(255 char): tipul servici ilor pentru care pacientul trebuie să plătească . Acesta
poate avea valorile: Imagistica(pentru s erviciile de imagistică ), Laborator( pentru analizele de
laborator) ș i “servicii_oferite” pent ru serviciile de care pacientul a beneficiat în cadrul
consultației, fără a fi necesară o recomandare;
– consultationId_F K number(19): este cheie externă ș i face l egătura cu tabela consultations,
reprezentând id -ul consultației în cadrul că reia serviciile pentru care pacientul trebuie să
plătească au fost recomandate sau oferite ;
– pacientId_F K number(19): este cheie externă și face legă tura cu tabela pacients,
repre zentâ nd id-ul pacientului care trebuie să plă tească ;
– total float(126): reprezintă valoarea total ă a serviciilor oferite și recomandate în cadrul
consultaț iei;
– leftToPay float(126): reprezintă suma care trebuie plătită de pacient.
3.2 Diagrama relațiilor
În figura de mai sus, sunt reprezentate rela țiile dintre cele 13 tabele necesare pentru
dezvoltare a acestei aplicații:
n:1 = relație many -to-one
n:n = relație many -to-many
1:n = relație one -to-many
1:1 = relație one -to-one
Adela -Mihaela Alecu
12
Figura 2: Relațiile dintre tabelele baz ei de date
Gestiune servicii medicale
13
4. Descrierea tehnologiilor uti lizate
4.1 Java EE ș i Java SE
Pentru dezvoltarea acestei aplicaț ii, am folosit ca limbaj de programare Java, acesta fiind un
limbaj orientat pe obiecte, f oarte des folosit pentru aplicaț ii web.
Există patru platforme ale limbajului de programare Java:
Java SE (Java Platform, Standard Edition)
Java EE (Java Platform, Enterprise Edition)
Java ME(Java Platform, Micro Edition)
JavaFX
În cadrul acestui proiect, plat formele folosite sunt: Java SE și Java EE .
4.1.1 Java SE
Api-ul Java SE pune la dispoziție functi onalițăț iile de bază ale limbajului de programare Java,
definind atât tipuri și obiecte de bază ale limbajului , cât și clase de nivel î nalt folosite pentru
securitate, a cces la baze de date , parsare XML etc.
În plus, față de API -ul de bază , platform a JAVA SE pune la dispoziție o mul titudine d e
tehnologii de implementare, tool-uri de dezvoltare, precum ș i alte bibl ioteci ș i toolkit -uri folosite
frecvent în aplicaț iile Java .
4.1.2 Java EE
Platforma Java EE extinde Platforma Java SE, punând la dispoziție un API pentru maparea
relațională a obiectelor, arhitecturi distribuite și pe mai multe niveluri, câ t și pentru servicii web.
Aplicaț iile create fol osind Java EE poartă denumirea de “aplicaț ii enterprise” . Caracter isticile
principale ale acestor a, cum su nt securitatea și fiabilitatea, determină creșterea complexității lor.
Platforma Java EE este proiectată pentru a reduce complexitat ea de dezvoltare a unei aplicaț ii
enterprise , prin API -ul și mediul de rulare puse la dispoziție, astfel încâ t dezvoltator ii să se poată
concentra pe funcț ionalitate.
4.2 Spring Framework
Spring este un framework de dezvoltare open source, fiind cel mai folosit la momentul actual
pentru aplicaț iile enterprise .
4.2.1 Avantaje
Câteva dintre avantajele folosirii acestui frame work sunt [1]:
Permite dezvoltarea aplicaț iilor enterprise folosind POJO( Plain Old Java Object ): nu mai este
necesar un container EJB( Enterprise JavaBeans ), ca de exemplu un server de aplicații, având
însă opțiunea de a folosi un container servlet robust c um ar fi Tomcat .
Chiar dacă numărul de pachete ș i clase este substanțial, trebuie să avem grijă doar de cele
care ne inter esează, putând să le ignoră m pe restul .
Foloseș te tehnologii deja existe nte, ca de exemplu: framework -uri ORM, framework -uri
pentru lo gare, JEE, Quartz, timere JDK.
Este un framework web MVC( Model View Controller ) bine construit, reprezentând o
alternativă pentru Struts sau alte framework -uri web mai puț in populare .
Adela -Mihaela Alecu
14
4.2.2 Arhitectura
Din punct de v edere ar hitectural, Spring conț ine mai multe module, oferind posibilitatea de
a le folosi doar pe cele necesare aplicaț iei. Cele aproximativ 20 de module puse la dispoziț ie, sunt
grupate după cum urmează [1]:
Data Access Integration conț ine modulele: JDBC, ORM, OXM, JMS ș i modulele de Tranzac ție
Web (MVC/Remoting) conține modulele : Web, Web -Servlet, Web -Struts ș i Web -Portlet ;
Core Container conț ine modulele: Core, Beans, Context ș i Expression Language ;
Diverse: modu lele AOP, Instrumentation, Web ș i Test .
4.2.3 Adnotă ri
Una dintre tehnologiile cu care S pring se identifică foart e mult este injectarea dependinț elor
(DI). Atunci câ nd scriem o ap licație Java foarte complexă , clasele aplicației ar trebui să fie câ t mai
independente posibil de alte clase, pentru a fac ilita reutilizarea lor, precum ș i pentru ușurința
testă rii. Injectarea dependințe lor face posibilă utilizarea claselor împreună, menținându -le în acelaș i
timp independente.
Începâ nd cu Spring 2.5 a devenit posibilă folosirea adnotă rilor pentru a configura injectarea
dependinț elor. Pentr u folosir ea acestora, este necesară activarea lor în fiș ierul de configurare Spring
(applicationContext.xml)
<context:annotation -config />
În cadrul aplicației de față, am folosit următoarele adnotă ri:
@Autowired poate fi folosită pe metoda “set”, pe const ructor, p e un anumit câ mp sau pe o
proprietate ;
@Controller indică faptul că respectiva clasă joacă rolul unui controller ;
@RequestMapping este folosită pentru a mapa un URL fie la o întreagă clasă , fie la o
anumită metodă ;
@RequestMapping(method = Reques tMethod.GET) este folosită pentru a declara metoda
ca metodă principal ă a controller -ului pentru cereri de tipul HTTP GET ;
@Service indică faptul că respectiva clasă joacă rolul unui serviciu ;
@Repository indică faptul că respectiva clasă funcționează ca o component ce va fi injectată
automat ;
@Transactional definește limite tranzacționale ș i reguli pe un bean sau/ și pe metodele sale.
Pentru folosirea acestei adnotări este necesară activarea ei în fiș ierul de configurare
Spring(applicationContext.xml)
<bean id="transactionManager"
class="org.springframework.orm.jpa.JpaTransactionManager" >
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>
<tx:annotation -driven />
@Override verifică faptul că metoda este o suprascriere și cauzează o eroare de compilare
dacă metoda nu este ga sită în una din clasele părinte sau în una din interfeț ele
implementate ;
@SuppressWarnings folosită pentru a supr ima warning -urile necontrolate î n Java ;
@RequestParam leagă un parametru cerut de parametrul unei metode ;
Gestiune servicii medicale
15
@ModelAttribute poate fi folosit pe o me todă sau pe un parametru. Atunci când se aplică
pe o metodă, are rolul de a preîn cărca modelul cu valoarea î ntoarsă de metodă . Când se
aplică pe un parametru, se leagă un atribut al modelului de parametru .
4.3 Java Persistence API
JPA ofera dezvoltatorilor de aplicaț ii Java p osibilitatea de a gestiona relaț iile dintre datele
aplicaț iei. JPA este un API superior API -ului JDBC ș i ascunde complexitatea de utilizator, spre
deosebire de JDBC. [2]
În cazul acestei a plicații, baza de date este una relațională , tabelele componente fiind
reprezentate cu ajutor ul entităților, fiecare proprietății a entității reprezentând o coloană dintr -o
tabelă .
4.3.1 Cerinț e pentru clasa entitate
O clasa e ntitate trebuie să respecte u rmătoarele cond iții [2]:
Clasa trebuie să fie adnotată cu javax.persistence.Entity .
Clasa trebuie să conțină un constructor public s au protected fără argumente. Pe lângă
acesta, clasa mai poate conține și alț i constructori .
Clasa, metod ele sau var iabilele n u trebuie să fie declarate cu atributul final .
Entitățile pot extinde atât clase entitate cât ș i clase non-entitate, iar clasele non -entitate pot
extinde clase entitate .
Variabilele trebuie declarate cu atributul private ,protected sau package -private și po t fi
accesate direct d oar prin metodele clasei entitate.
Exemplu de clasa entitate :
@Entity
@Table(name = "programs" )
public class Program {
@Id
@GeneratedValue (strategy = GenerationType. SEQUENCE , generator =
"programs_SEQ_GEN" )
@SequenceGenerator (name = "programs_SEQ_GEN" , sequenceName =
"programs_SEQ" , allocationSize = 1, initialValue = 1)
private Long programId ;
@NotEmpty
private String day;
@Min(8)
@Max(20)
private Integer startTime ;
@Min(8)
@Max(20)
private Integer endTime;
@ManyToMany
@JoinTable (name = "users_programs" , joinColumns = @JoinColumn (name =
"programId" ), inverseJoinColumns = @JoinColumn (name = "userId" ))
private List<User> users;
}
Adela -Mihaela Alecu
16
Pentru exemplul de ma i sus, pentru fiecare variabilă în parte sunt definite metode get și
set.
4.3.2 Chei primare în entităț i
Fiecare entitate trebu ie să aibă un id entificator unic(o cheie primară ). Aceasta poate fi
simplă sau compusă. Pentru aplicaț ia mea, am folosit chei primare sim ple. Pentru a indica faptul că o
variabilă este cheie primară trebuie utilizată adnotarea javax.persistence.Id . Așa cum se poate
observa și î n exemplul de la 4.3.1, pentru cheia primară am mai folosit și adnotă rile:
@GeneratedValue : utilizată pentru a atribui un numă r de ordine generat variabilei
@SequenceGenerator: utilizată pentru a defini un obiect secvență .
– sequenceNa me: numele secvenț ei;
– allocationSize: valoarea cu care secvenț a este incrementată pentru fiecare linie din
tabelă;
– initialValue: valoarea inițială.
4.3.3 Multiplicitatea
Relațiile între entităț i pot fi de patru tipuri:
One-to-one: Fiecare instanță a entit ății este legată de o singură instanță a unei alte entităț i.
Pentru a defini o relaț ie de a cest tip se foloseș te adnotarea javax.persistence.OneToOne
One-to-many : O instanță a entității poate fi legată de mai multe instan țe ale altor entități.
Pentru acest tip de relație trebuie folosită adnotarea javax.persistence.OneToMany
Many -to-one: Mai multe instanțe ale unei entități pot fi legate la o singură instanță a altei
entităț i. Pentru această relaț ie este necesară folosirea adnotă rii javax.persistence.Many ToOne
Many -to-many: Mai multe instanț e ale unei entităț i pot fi legate la mai multe instanț e ale
unei alte entități. Pentru acest tip de relație trebuie folosită adnotarea
javax.persistence.ManyToMany
4.3.4 Dire cția î n relațiile dintre entităț i
Relațiile dintre entități pot fi atât unidirecționale, cât și bidirecț ionale .
În cazul unei relații bidirecționale, partea inversă a relației trebuie să facă referire la partea
sa folosind elementu l mappedBy al adnotă rii @OneToOne, @OneToMany sau @ManyToMany .
Exemp lu:
În cazul unei relații unidirecț ionale, doar una din entități are o relaț ie sau o proprietat e care
face referire la cealaltă entitate.
4.3.5 Adnotă ri În fișierul Pacient.java:
@OneToMany (mappedBy = "pacient" )
private List<Reservation> reservations ;
În fiș ierul Reservation.java:
@ManyToOne
@JoinColumn (name = "pacientId_FK" )
private Pacient pacient;
Gestiune servicii medicale
17
Pe lângă adnotările prezentate în subcapitolele anterioare, în cadrul acestei aplicații am
mai folosit și următoarele adnotă ri puse la dispoziț ie de JPA :
@Table : specifică tabela primară pentru entitatea adnotată;
@JoinColumn : specifică cheia străină a tabelei care se află în relație cu tabela curentă ;
@JoinTable : folosită în maparea relaț iilor: many -to-many, on e-to-many/many -to-one
undidirecț ionale, many -to-one/one -to-many bidirecționale, one -to-one unidirecționale și
bidirecț ionale . Folosită pentru a indica numele tabelei care va realiza “join -ul” dintre alte
două tabele .
@Lob: specifică faptul că variabila respectivă trebuie să fie reț inută într-un obiect
Blob (Binary Large Object) sau î ntr-un obiect Clob (Character Large Object) în funcț ie de tipul
acesteia .
4.3.6 Administrarea entităț ilor
Administrarea entităț ilor se face folosind un manager de tranzacții , care este reprezentată
de javax.persistence.EntityManager .
API-ul En tityManager permite crearea și eliminarea instanțelor entităților, găsirea entităț ilor
pe baza cheii primare a acestora și realizarea interogă rilor.
Pentru a obține o insta nță EntityManager, este necesară injectarea unei entități manager î n
component a aplicaț iei. Exemplu :
4.3.7 Java Persistence Query Language
JPQL(Java Persistence Query Language) este un limbaj de interogare folosit pentru realizare a
accesu lui la datele din baza de date î ntr-un mod similar cu SQL (Structured Query Language). JP QL
este portabil, permițând că utarea de entități într -un mod i ndependent de mecanismul folosit pentru
stocarea acestora. JPQL este o extensie a limbajului EJB QL(Eneterpris e JavaBe ans query language),
adăugând operații precum: ștergeri ș i update -uri multi ple, operații de combinare, proiecții și
subinterogări. Interogă rile JPQL pot fi declarate static î n metadata sau construite dinamic î n cod. [3]
În cazul aplicației de față , intero gările au fost construite di namic î n cod, folosind metoda
javax.persistence.Query.createQuery . Parame trii de interogare sunt prefixați cu două puncte(:).
Pentru a realiza legătura între un parametru și valoarea dorită a acestuia am folosit metoda:
javax.p ersistence.Query.setParameter(String nume, Obiect valoare).
Exemplu :
@PersistenceContext
EntityManager em;
@SuppressWarnings ("unchecked" )
@Override
public List<Pacient> findByName(String firstName, String lastName) {
Query query = getEm()
.createQuery(
"select s from Pacient s where s.firstName like
:firstName and s.las tName like :lastName" );
query.setParameter( "firstName" , firstName);
query.setParameter( "lastName" , lastName);
List<Pacient> resultList = query.getResultList();
return resultList; }
Adela -Mihaela Alecu
18
În exemplul de mai sus, se extrag toți pacienții care au numele “lastName” ș i prenumele
“firstName” .
4.4 Hibernate
Hibernate este o libră rie ORM (Object Relational Mapping) open source pentru limbajul de
programare Java . Rolul acesteia î n cadru l aplicaț iei este de a realiza maparea claselor Java definite î n
cadr ul nivelului “domain” al aplicației î n tabele ale bazei de date. Coloanele tabelelor vor fi
reprez entate de variabile le definite în cadrul fiecă rei clase. Această mapare poate fi realiza tă fie prin
intermediul unui fiș ier de configurar e XML, fie prin folosirea adnotă rilor, pentru această aplicaț ie
folosindu -se cea de -a doua variant ă.
Prin intermediul adnotărilor, Hibern ate poate realiza și restricț ii asupra valorilor coloanelor
din tabele, prin component a Hibernate Validator. În cadrul acestu i proiect, au fost folosite
următoarele adnotă ri:
@Min : valoarea minimă admisă;
@Max : valoarea maximă admisă;
@NotEmpty : șirul treb uie să nu fie nul l;
@NotNull : valoarea trebuie să fie diferită de nu ll;
@Email : valoarea trebuie să respecte formatul corespunză tor unei adrese de email .
Hibernate, permite utiliza rea a 2 concepte: lazy loading ș i eager loading, varianta implicită
fiind c ea de lazy loading. Lazy lo ading are rolul de a amâna inițializarea unui obiect, până în
momentul î n care acesta este întradevăr necesar. Acest lucru are ca efect îmbu nătățirea timpilor de
răspuns în cazul interogă rii bazei de date.
4.5 Oracle
Pentru acea stă aplicaț ie, am folosit ca server de baze de date, serverul Oracle , acesta fiind
un server care permite gestiunea bazelor de date relaț ionale.
Ținând cont de rolul aplicației, putem să facem presupunerea că în timp, se va ajunge la
existența unui volum foarte mare de informații. Oracle, spre deosebire de alte servere de baze de
date suportă baze de date de orice dimensiuni , acestea putând ajunge chiar ș i la dimensiuni de
ordinu l gigaocteților.
Un alt aspect care a contribuit la alegerea serverului Orac le a fost faptul ca acesta suportă
conectarea simultană a mai multor utilizatori, minimizând posibilele conflicte.
Având în vedere că aplicația presupune ș i reținerea de date personale despre clienți și
angajați, și securitatea datelor a trebuit luată în cons iderare la alegerea serverului, Oracle fiind
renumit la acest capitol.
4.6 Maven
Pentru managementul ș i compilarea aplicaț iei, am folosit tool -ul open source Maven. Primul
pas î n crearea proiectului a constat în rularea următoarei comenzi în linia de c omandă :
mvn archetype:generate \
-DgroupId=ro.adal.HealthyPlus -DartifactId=HealthyPlus \
-DarchetypeArtifactId=maven -archetype -webapp
Gestiune servicii medicale
19
Această comandă are ca rezultat crearea fișierului de configurare pom.xml ș i a directorului
HealthyPlus, cu următoarea structură :
src/test/java : sursele pentru teste ;
src/test/resources : resursele pentru teste (fișierul log4j.xml) ;
src/main/ java: sursele apli cației ș i ale bibliotecilor ;
src/main/resources : resursele aplicației ș i ale bibliotecilor (fișierele applicati onContext.xml,
jdbc.properties ș i log4j.xml) ;
src: conț ine toate sursele necesare pentru compilarea proiectului ;
target : direct or în care se reț ine tot outputul rezultat în urma compilă rii;
pom.xml : reprezintă componenta de bază în lucrul cu Maven, conținând toate informaț iile
importante referitoare la proiect ca de exemplu plugin -urile care trebuie folosite de procesul
de compila re.
Pentru compilarea și rularea aplicației am folosit urmă toarele 2 comenzi:
mvn clean install : aceasta comandă are ca rezultat ștergerea fiș ierelor g enerate la
compilarea anterioară și împachetarea aplicaț iei sub forma unei arhivei WAR , care se va
regăs i în folderul target (HealthyPlus.war) .
mvn tomcat:run : rulează proiectul rezultat la pasul anterior pe un server Tomcat .
4.7 Apache Tomcat
Pentru ace st proiect am folosit ca server web Apache Tomcat 6.0.29 datorită faptului că
acesta este un server open source care oferă suport pentru pagini JSP(JavaServer Pages), acesta
permiț ând totodată o integrare uș oara cu tool -ul Maven.
Odată ce serverul T omcat este pornit, folosind comanda mvn tomcat:run, aplicația va putea
fi disponibilă prin navigarea î n oric e browser la : http://localhost:8080/ HealthyPlus .
Componentele Apache Tomcat sunt [4 ] :
Catalina : este containerul pentru servleți și implementează specificaț iile Sun Microsystem
pentru servleți ș i pentru pagini JSP( JavaServer Pages).
Coyote : realizează conexiunea î ntre c omponentele HTTP. Coyote ascultă conexiunile pe un
port TCP și transmite cererile că tre Tomcat Engine pentru procesarea acestora, urmând să
trimită răspunsurile că tre client.
Jasper : are rolul de a pa rsa fiș ierele JSP pentru a fi compilate în cod java ca servleț i. La
runtime, Jasper determină modificările din fisierele JSP și le recompilează .
4.8 JavaServer Pages
Pentru dezvoltarea pă rții grafice, am ales folosirea tehnologiei JSP. Aceasta combină
elem entele de HTML ș i XML cu servleturile ș i tehnologiile JavaBeans.
Tehnologia JSP facilitează crearea de conți nut dinamic pe partea de ser ver a paginilor Web,
fiind asemănă toare cu tehnologia ASP (Active Sever Page) de pe platform a Microwoft Windows ș i cu
PHP(PHP: Hypertext Preprocessor), care este independent de platform ă. JSP este o soluț ie Java
pentru programarea pe partea de sever, fiind o alternativă la CGI -urile clasi ce(Common Cateway
Interface). [5 ]
Adela -Mihaela Alecu
20
Principal ul avantaj al paginilor JSP, față de servlet uri îl reprezintă separare a conț inutului
HTML static de cel dinamic. În cazul servleturilor, dacă se modifică orice element referitor la design –
ul paginii, acel servlet va trebui recompilat.
Paginile JSP sunt executate pe partea de server, în cazul de faț ă Tomcat. Acestea vor fi
stocate î n directorul /src/main/webapp/WEB -INF/views al proiectului, fiind grupate în funcție de
modulele prezentate î n capitolul 5.
Paginile JSP ale acestui proiect vor conț ine și elemente corespunză toare JSTL(JSP Standard
Tab L ibrary) pentru crearea formularelor. Acestea au fost folosite pe ntru o implementare
transparentă a componentei view, care să permită ușurința transmiterii datelor că tre component a
controller.
4.8 HTML, CSS
Pentru a oferi un aspect cât mai plă cut aplicaț iei am folosit elemente de HTML( HyperText
Markup Language ) și CSS( Cascading Style Sheets ). Dezvoltarea interfeț ei grafice a avut ca punct de
plecare temp late-ul INADMIN, pus la dispoziț ie de INDEZINER. Acesta a fost modificat pentru a
răspunde nevoilor lucrăr ii curent e.
În cadrul proiectului, ele mentele de HTML sunt utilizate î n interiorul paginilor .jsp, ia r
elementele CSS sunt definite în cadrul a 2 fiș iere de stil:
datePicker.css: elemente de stil sp ecifice calendarului;
style.css: elemente de stil comune t uturor paginilor .jsp pentru formulare, meniu, butoane
etc.
4.9 JavaScript, jQuery, Ajax
JavaScript este un limbaj de scr ipting folosit foarte frecvent în paginile Web pentru a adăuga
funcț ionalitate, pentru validarea formularelor, pentru a realiza comuni carea cu serverul și multe
altele. În această aplic ație, am folosit JavaScript pentru:
confirmarea inițiativei de a ș terge u n element, î n cadrul modulului admin ;
afișarea unui calendar, care să permită selectarea datei (zi, luna) folosit la completarea
datelor de tipul “Date” din baza de date .
Conform site -ului oficial, jQuery este o bibliotecă JavaScript mică din punct de vedere al
dimensiunii, rapidă , care pune la dispoziț ie o gamă variată de funcționalităț i. Aceasta permite ca
operaț ii precum manipular ea documentelor HTML, m anipularea evenimentelor, animații ș i
Ajax (Asynchronous JavaScript and XML ) să se realizeze mult mai sim plu prin intermediul unui API
ușor de folosit, care funcționează într -o multitudine de browsere.[6 ]
Așadar, putem spune că jQuer y rezolvă problema compatibilității î ntre diferitele browsere
existente și permite obținererea funcționalităț iilor dorite folosind un volum mai mic de muncă , decât
ar fi necesar în cazul utiliză rii limbajului JavaScript.
În cadrul proiectului de față , am folosit jQuery ș i Axaj pentru:
ștergerea multiplă a elementelor selectate î n cadrul modului de administrare ;
afișarea programului de lucru corespunzător unui medic și a unui buton de Submit, în funcț ie
de ziua din calendar selectată .
Gestiune servicii medicale
21
4.10 Hypert ext Transfe r Protocol
HTTP( Hypertext Transfer Protocol ) este protocolul cel mai des f olosit pentru accesarea
informațiilor pă strate pe servere WWW( World Wide Web ). Acesta funcționează prin transferul de
cereri și răspunsuri între client ș i server.
HTTP pune la disp oziție o metodă de comunicare prin care paginile pot fi accesate pe propria
unitate de lucru, chiar dacă acestea se află pe o stație aflată la distanță . Modul de funcț iona re al
acestui protocol este următorul: în prima etapă, adresa este convertită de prot ocolul DNS într -o
adresă IP. Apoi, ca ră spuns la cererea HTTP -GET urmează transferul prin protocolul TCP pe por tul 80
al serverului HTTP. Pe lângă informaț ia standard, pachetul HTTP poate con ține și informaț ii
suplimentare în antetul să u, ca de exemplu: in dicații pentru browser, limba dorită etc. În urma
cererii HTT P-GET, serverul va trimite un răspuns cu datele cerute, răspunsul putând conține: pagini
HTML cu fișiere atașate ca imagini, fiș iere CSS, scripturi , dar pot fi ș i pagini generate dinamic. În cazul
în care cererea nu poate fi soluționată, serverul trimite ca ră spuns un mesaj de eroare. Modul exact
de desfășurare a acestui flux(cerere și ră spuns) este stabilit în specificaț iile HTTP.
HTTP pune la dispoziție două metode pentru transferul argumentelo r:
metoda “GET”: se dorește transferul datelor în combinație cu o cerere pentru o resursă.
Această meto dă foloseș te partea de cerere URI(Uniform Resourse Identifiers) cu simbolul ?.
Pentru transferul unei lis te de parametrii, cerera va conț ine perechi de v alori separate prin
“&”, acestea fiind de forma: “nume parametru = valoare parametru” . Totuși, numă rul
paramet rilor este limitat de faptul că lungimea maxima a URL-ului rezultat nu are voie să
depășească 2048 de caractere .
metoda “POST”: se dorește tra nsferul datelor în combinație cu o cerere specială . Această
metodă este mult mai sigură decâ t metoda “GET” deoarece pa rametrii acesteia nu sunt
salvați în istoria browser -ului sau î n log -uri.
Adela -Mihaela Alecu
22
5. Descrierea aplica ției
Aplica ția este formată din 7 module, corespunzătoare tipurilor de utilizatori posibili ai
aplicației:
Administratori
Clienți
Medici
Personalul responsabil cu întâmpinarea clienților
Personalul responsabil cu recoltarea analizelor
Personalul responsabil cu complet area rezultatelor analizelor
Personalul responsabil cu punerea la dispoziție a servic iilor de imagistică
Pentru utilizarea aplicației, este necesară logarea folosind numele de utili zator și parola
corespunzătoare, dupa cum se observă î n figura 3:
Figur a 3: Logare
În cazul î n care ut ilizatorul introduce datele greșit, acesta va fi înști ințat prin afiș area
mesajului “ Utilizator invalid sau parola invalida ”. În cazul î n care datele introdus e sunt core cte,
utilizatorul va fi redire cționat către pagin a corespunzătoare rolului să u în aplicaț ie.
5.1 Modulul admin
Modulul admin este modulul responsabil cu buna administrare a cli nicilor. Acesta pune la
dispoziția administratorului operații de adă ugare, editare, vizualiz are detalii, șter gere, ș tergere
multiplă, căutare dupa câmpuri relevante pentru urmă toarele categorii:
Locaț ii
Specialități angajaț i
Specialităț i servicii
Angajaț i
Servicii
Program
Gestiune servicii medicale
23
Figura 4: Pagina de afișare a locaț iilor
Toate paginile .jsp principale corespunzăt oare acestui modul respectă urmă torul ș ablon:
În partea superioară a paginii se află meniul, prin intermediul c ăruia administratorul poate
naviga între diferitele pagini corespunză toare categoriilor specificate mai sus (Figura 4 ).
În par tea din stânga există mai multe z one în care administratorul poate adăuga text pentru
căutarea î n baza de date, aceste zone fiin d diferite pentru fiecare pagină corespunză torare
meniului . De exemplu, î n Figur a 4 administratorul poate că uta locațiile dupa nume sau după
tipul acestora.
În partea din dreapta se afișează sub forma unui tabel toate intră riile din baza de date
corespunză toare paginii accesate, sau doar acele intră ri care corespund valorilor introdus e
pentru că utare. Așa cum se poate obsera din F igura 4 , fiecare linie din tabel va corespunde
unei intră ri din baza de date. Tabelul poate conține pe lângă informațiile din baza de date și
urmă toarele butoane:
– Detalii : În cazul î n care tabela are multe coloane, doar o pa rte dintre acestea vor fi
afișat e în tabel, iar res tul vor putea fi disponibile prin apă sare a acestui buton, care
realizează o redirecț ionare către o pagină ce conține toate informaț iile.
– Imagine : La apă sarea acestui buton , administratorul va fi redirecționat către o altă
pagină din care poate sele cta poza dorită , din orice locaț ie de pe c alculator, aceasta
fiind salvată (la apă sarea butonul ui Submit ) pe staț ia unde se află serverul .
– Edit: La apă sarea acestui but on, utilizatorul va fi redirecționat către o altă pagina în
care vor fi afișa te toate informațiile referitoare la elementu l respectiv . Acestea pot
fi modificate, iar modifică rile pot fii salvate la apă sarea butonului Submit .
Adela -Mihaela Alecu
24
– Delete : La apă sarea acestui buton, va apă rea un pop -up prin care admi nistratorul
poate să confirme sau să an uleze acțiunea de ș tergere (Figura 5 ):
Figura 5: Pop -up ștergere
Partea inferioară a paginii conț ine 3 elemente:
– Butonu l “Adaugare element nou” : la apă sarea acestuia administratorul va fi
redirecționat către o pag ină în care poat e completa informaț iile referitoare la
elementu l pe care doreș te să îl adauge, acesta fiind adăugat la apă sarea butonului
“Sub mit”. În cazul î n care i nformațiile adăugate nu respectă tipul coloanelor din
tabelă , sau dacă nu sunt completate toate informații le necesare, la apă sarea
butonul ui “Submit” utilizatorul va rămâne tot în pagina de adăugare. În cazul în care
adăugarea se poate realiza cu succ es, utilizatorul va fi redirecționat către pagina în
care sunt afișate toate intrările din tabelă .
– Butonul “St erge elementele” : a șa cum se obseră și î n Figura 4 , în dreptul fiecărui
element din tabelul în care se listează toate el ementele, se află un checkbox pentru
selectarea elementului respectiv . La apă sarea butonului “Sterge elementele” , vor fi
șterse toate e lementele selectate .
– Numerele paginilor: Pentru a evita încărcarea excesivă a paginilor, pentru afiș area
elementelor am fo losit conceptul de paginare. Astfel, pe fiecare pagină vor fi afișate
decât 10 elemente, restul putâ nd fi ac cesate prin butoanele core spunză toare
paginilor .
În Figura 6 este ilustrat un exemplu de pag ină pentru editarea unui element . Aceasta este
identică din punct de ve dere structural cu pagina de adă ugare a elementului.
Figura 6: Editare locație
Gestiune servicii medicale
25
Modulul adm in, are 6 intrări în meniu corespunză toare categoriilor specificate anterior:
Locatii: la apasarea acestei intră ri, utilizatorul este redirecționat către o pagina în care se
afișează toate locațiile în care se gă sesc sedii ale cl inicii. De asemenea, acesta are și
posibilitatea de a căuta și afișa locațiile după numele sau după tipul lor(Imagistica,
Laborator, Policlinica) .
Specialitati Angaja ti: prin accesarea acestei intră ri din meniu , administratorul este
redirecționat către o pagină în care se afișează to ate specialitățile angajați lor, ca de
exemplu: Medicina Generala, Medicina de Laborator, Anatomo -Patologie etc. Ca și în cazul
locațiilor, utilizatorul poate căuta și afișa specialităț iile după numele sau după tipul lor
(Policlinica, Imagistica, Laborator, Altele) .
Specialitati Servicii: prin apăsarea acestei opț iuni din meni u, administratorul este
redirecționat că tre o pa gină în care se afișează toate specialităț iile servici lor care pot fi puse
la dispoziție î n cadrul c linicilor. Administratorul are și pos ibilitatea de a căuta și vizualiza
specialităț iile după nume sau după tipul lor(Policlinica, Imagistica, Laborator) .
Angajati : prin intermediul acestei intră ri din m eniu, utilizatorul este redirecționat către
pagina în care se afișează toți angajații din t oate sediil e existente. În cadrul acestei pagini,
există și posibilitatea de a căuta și afișa angajații după : nume, prenu me, numele locației în
care lucrează, data angajării ș i rolul acestuia(Medic, Asistent, Laborant, Secretar, Admin) .
Servicii: la apă sarea acestei opț iuni din meni u, administratorul este redirecționat către o
pagină în care se afișează toate serviciile medicale care pot fi puse la d ispoziție î n cadrul
clinicilor. Rezultatele afișate pot fi limitate prin căutarea după: numele serviciului, prețul
acestuia, numele specialităț ii din care face parte, unitatea de măsură și durata pentru
serviciile de tipul analizelor de laborator . Pentru a evita interogările inutile că tre baza de
date, am realizat o validare a valorilor inserate în câmpurile pe ntru căutare. De exemplu:
pentru preț, pot fi inserate decât valori numerice, care să conțină cel mult un punct, iar
acesta să nu fie pe prima poziț ie.
Program: prin accesarea acestei intră ri din m eniu, utilizatorul este redirecționat către o
pagină în ca re sunt afiș ate toate tipurile de programe de lucru pentru toți angajaț ii clinicilor.
Programul de lucru va putea fi de Luni până Sâmbătă î ntre orele 8 -20. În cadrul ac estei
pagini, utilizatorul are și posibilitatea de a căuta și afiș a program ele dupa ziua de lucru, ora
de început și ora de șfârș it.
5.2 Modulul secretar
Acest modul pune la dispoziție diferite acț iuni pentru pers onalul responsabil cu
întâmpinarea pacienților î n cadrul cent relor medicale , prin intermediul celor patru intră ri din meniu:
Pacien ti, Vizualizare Programari, Adaugare Programari, Incasari.
5.2.1 Pacienț i
Prin accesarea butonului “Pacienti” din meniu, utilizat orul va fi redirecț ionat către o pagină
în care vor fi afișați toti pacienții clinicii (Figura 7 ).
Adela -Mihaela Alecu
26
Figura 7: Pacienți
Aceasta pagină permite următoarele operaț ii:
Adăugarea unui nou pacient prin apă sarea butonului “Adaugare element nou” ;
Căutarea unui pacient după numele ș i prenumele acestuia ;
Vizualizarea detaliilor despre un pacient ;
Editarea inform ațiilor corespunză toare unui pacient ;
5.2.2 Adăugare programari
În cazul programărilor, am presupus că un client poate să solicite fie o programare la un
anumit medic, f ie o programare pentru o anumită specializare. Din acest motiv, utilizator ul va avea
posibilitatea de a căuta ș i de a vizualiza medicii în funcț ie de numele sau de specialităț iile lor.
Pentru fiecare medic, se va afișa și locația în care acesta poate fi găsit, precum și tipul
locaț iei(Policl inica, Imagistica, Laborator). În cazul în care cli entul dorește informaț ii suplimentare
despre un anumit medic, utilizatorul va putea apăsa butonul de “detalii” care î l va redirecționa către
o pagină în care vor fi afișate toate informaț iile despre medicul respectiv.
Pentru adăugarea unei programări, în d reptul fiecărui medic se va găsi butonul “Adauga” , la
apăsarea căruia utilizatorul va fi redirecț ionat într-o pagină nouă î n care trebuie completate
următoarele câ mpuri:
Numele pacientului ;
Prenumele pacientului ;
Data nașterii: în cazul în care există mai mulți pacienți cu același nume și prenume, distincția
între ei se va face pe baza zilei de naș tere.
După completarea acestor informa ții, utilizatorul va apasa butonul “Submit ”. În cazul î n care
informaț iile introduse sunt core cte, utilizatorul va fi redir ecționat către pagina din F igura 8.
În caz cont rar, utilizatorul va fi redirecționat către aceași pagină, pentru a î ncerca să
introducă niș te date valide.
Gestiune servicii medicale
27
Figura 8: Adăugare programare
După cum se observă din Figura 8 , utilizato rul a re posibilitatea de a renunț a la
adăugarea unei noi programări, prin apă sarea butonului “Cancel” . În acest caz, el va fi redirecționat
către pagina corespunzătoare intră rii “Adaugare programari” din meniu.
Pentru a selecta data în care se dorește r ealizarea unei programări, utilizatorul trebuie fie să
scrie data rezervării în câmpul corespunzător acesteia, fie să acționeze prin click acea zona, caz în
care va apă rea un pop -up cu un ca lendar ca cel din Figura 9.
Figura 9: Calendar
După specificarea datei, la apă sarea butonului “Cauta” va fi afișată o listă cu orele din data
respectiv ă, la care medicul este disponibil , precum ș i butonul “Submit” . Pentru adă ugarea
Adela -Mihaela Alecu
28
programării, va fi necesară selectarea unui element din acea lista și apă sarea butonului “Submit” .
Intervalul dintre orele la care se poate face o programare la un medic este de 30 de minute.
5.2.3 Vizualizare programă ri
La accesarea intră rii “Vizualizare programari” din me niu, utilizatorul va fi redirecționat căt re
o pagină în care vor fi afiș ate toate programă rile exis tente, sub forma unui tabel ca în Figura 10.
Figura 10: Vizualizare programări
Utilizator ul va avea posibilitatea de a căuta toate programările unui pacient după numele și
prenumele acestuia. Anularea unei programări se va face prin apă sarea butonului “Sterge”
corespunză tor. La sosirea unui client care are o programare, utilizatorul va apă sa butonul “Prezent”
pentru inștiinț area medicului.
5.2.4 Incasari
Prin intermediu l acestei opț iuni din meniu, utilizatorul poate să verifice su ma pe care un
pacient trebuie să o plă teasca pent ru serviciile puse la dispoziție î n cadrul clinicii. Desemenea el
poate să marcheze faptul că acea sumă a fost achitată prin apă sarea butonului “ Platit”
corespunzător acesteia. Î n plus, pentru fieca re intrare, utilizatorul are opț iunea de a vizualiza
infor mații suplimentare prin apă sarea butonului “Detalii”, c are va avea ca rezultat red irecționarea
către o pagină nouă , ca cea din Figura 11.
Figur a 11: Detalii plată
Gestiune servicii medicale
29
Așa cum se obseră și în Figura 11 , o plată are a sociate 2 sume , acestea putâ nd avea valori
diferite :
Suma totală : Pentru fiecare consultație, se generează o singură plată care este modificată pe
parcurs. Iniț ial, suma totală va fi reprezentată de cos tul serviciilor puse la dispoziție în cadrul
unei consultaț ii. Dacă în cadrul consultației, medicul a recomandat și realizarea unor analize,
odată ce pacientul s -a prezentat pentru recol tarea analizelor, la suma to tală se mai adaugă ș i
costul acestor analize. La suma totală, se poate adăuga de asemenea ș i costul se rviciilor de
imagistică recomanda te de medic, daca pacientul hotărăște să le facă .
Plata: reprezintă suma pe care pacientul trebuie să o achite. După achi tare, valoarea acestui
câmp devine 0.
5.3 Modulul medic
Acest modul pune la dispoziț ia medicilor toate acțiunile necesare pentru af larea
informațiilor despre paci enți și pentru adăugarea de noi consultaț ii.
5.3.1 Programari
Prin accesarea acestei pagini, utilizatoru l poate vizualiza toate programă rile din ziua curentă ,
sub forma unui tabel ca cel din Figura 12 .
Figura 12: Afișare programări în modulul medic
Pentru fiecare pro gramare, medicul are la dispoziție următoarele opț iuni:
Anularea prin apă sarea butonului “Anuleaza”: daca în 10 minute de la ora stabilită pacientul
nu se prezintă , este responsabilitatea medicului să anuleze programarea .
Adăugarea unei consultaț ii noi . La apă sarea butonului “Consult atie noua” medicul este
redirecționat către o pagină ca cea din Figura 13 , în care trebuie să completeze urmă toarele
câmpuri:
– Observaț ii: În această zonă, medicul poate să introducă informaț ii precum
simptomele pacientulu i, posibile diagnostice, felul î n care a evoluat boala sau o rice
alte informaț ii relevante.
– Tratament : În această zonă, medicul trebuie să noteze tratamentul recomandat,
durata ș i modul de administrare.
– Servicii oferite: La apăsarea acestei zone, se afișează o listă cu toate serviciile de
tipul “Policlinica” sau “Imagi stica” din care medicul poate să selecteze mai multe.
Acestea reprezintă serviciile pe c are el le -a oferit pacientului în cadrul consultaț iei
Serviciile sunt gru pate pe categorii, iar pentru ușurință medicul poate scrie numele
servic iului sau o part e din nume, afișându -i-se toate serviciile care corespund cu
textul introdus.
Adela -Mihaela Alecu
30
– Analize de laborator: Reprezint ă analizele pe care medicul le poate recomanda
pacientului . Modul de selectare a acestora este asemănă tor cu cel de la selectarea
serviciilor ofe rite.
– Servicii imagistică : medicul poate recomanda pacientului 1 sau mai multe servicii de
tipul “Imagistica” . Modul de alegere a acestora este identic cu cel de la selectarea
servicilor folosite .
Pentru zona în care se selectează serviciile o ferite, anali zele de laborator ș i serviciile
de imagistică, în cazul în care medicul iși dă seama ca a selectat un element greșit, acesta poate fi
înlăturat cu ușurință din listă , prin apăsarea “X -ului” care î i corespunde. După selectarea unui
eleme nt, acesta nu va ma i fi listat î n lista cu toate elementele din care se poate alege.
Figura 13: Adăugare consultație
Editarea consultației adă ugate : dacă nu a fost încă adaugată o consultație noua, la apă sarea
acestui buton medicul este redirecți onat către pagina î n care sunt afisate toate
programariile, ca în Figura 12. Î n caz contrar, medicul va fi redirecționat către o pagină î n
care va avea p osibilitatea de a edita toate câ mpuril e specificate la pasul anterior și de a salva
modificările prin a păsarea butonului “Submit” .
Vizualizarea istoricului medical al pacientului pe numele căruia a fost fă cută programarea
La apă sarea acestui buton, me dicul va fi redirecționat că tre o pagina ca cea din Figura 20 .
Gestiune servicii medicale
31
Terminarea consultaț iei, moment în care se ca lculează automat sum a pe care pacientul va
trebui să o plătească pentru s erviciile puse la dispoziț ie.
5.3.2 Pacienț i
Prin intermedi ul acestei pagini, medicul are și opțiunea de a adăuga o consultație, chiar dacă
nu există o programare în ziua curentă pe ntru pacientul pe care dorește să îl consulte. Această
pagină este necesar ă pentru cazul în care un pacient se prezintă în clinică și dorește să fie consultat.
În cazul în care medicul este disponibil în momentul respectiv, pacientul poate să benef icieze d e
serviciile acestuia. Î n caz contrar, acesta are posibilitatea de a iș i face o programare pentru altă zi.
Structura acestei pagini, este asemănă toare cu cea preze ntată la punctu l 5.3.1 Programă ri.
5.4 Modulul asistent
Acest modul este folosit de personalu l responsabil cu recoltarea analizelo r recomandate.
Pagina corespunză toare acestui modul este prezentată în Figura 14.
Figura 14: Afișare analize în modulul asistent
Pentru ușurință, utilizatorul poate să caute analizele re coma ndate pentru un pacient după
numele ș i prenumele acestuia.
După prelevarea p robelor, utilizatorul trebuie să apese butonul “Re coltat” pentru a marca
faptul că acestea au fost recoltate.
5.5 Modulul laborant
Acest modul este destinat medicilor care au ca misiune interpretarea probelor recoltate.
În pagina principală vor fi afișate sub formă tabelară toate consultațiile în cadrul că rora
medicii au recomandat an alize de laborator (Figura 15 ).
Adela -Mihaela Alecu
32
Figura 15: Afișare analize în modul ul laborant
Dupa cum se observă și în Figura 15 , utilizatorul are posibilitatea de a căuta dupa numele ș i
prenumele pacientului.
Pentru fiecare consultație, utilizatorul va putea să adauge rezultatele analizelor măsurate
prin apă sarea butonului “Edit”, c are are ca rezultat redirectarea către o pagina ca cea din F igura 16 .
Figura 16: Completare rezultate analize
Pentru fiecare analiza î n parte, utilizatorul va trebui să adauge valoarea minimă, valoarea
maximă și valoarea măsur ată. Î n secț iunea “De talii generale” din Figura 16 observ ăm că se afișează
sexul și vârsta pacientului că ruia i -au fost recoma ndate analizele. Aceste informaț ii sunt necesare,
deoarece pentr u multe analize, valorile minimă,maximă ș i norma lă sunt dependete de ele.
Gestiune servicii medicale
33
5.6 Modulul medic imagistic ă
Acest modul este dedicat utilizatorilor res ponsabili cu punerea la dispoziție a servicilor de
imagistică . Prin logare, me dicii din centrele de imagistică vor fi redirecționați către o pagină în care
vor fi afișate toa te programările din ziua curentă, sub formă de tabel ca în Figura 17:
Figura 17: Afișare programări în modulul medic imagistică
Pentru fiecare programare, medicul va putea să realizeze următoarele operaț ii:
Să anuleze programar ea prin apă sarea butonului “Anuleaza” ;
Să vizualizeze istoricul medical al pacientului prin apă sarea butonului “Istoric medical” ;
Să vizualizez e toate serviciile de imagistică recoma ndate pacientului curent: la apă sarea
butonului “Recomanda ri”, utilizatoru l va fi redirecționat către o pagină în care sunt afiș ate
toate recomandă rile, sub forma un ui tabel ca cel din Figura 18.
Figura 18: Servicii de imagistică recomandate
Așa cum se observă și în Figura 18 , pentru fiecare serviciu recomandat vor fi afișate
următoarele informaț ii: medicul care a realizat recomandarea, data î n care a fost recomandat
serviciul, numele serviciului și statusul î n care se află acesta: “recomandat” sau “editat” .
Prin apă sarea butonului “Editare” medicul v a fi r edirecționat către o pagină nouă în care va
putea să adauge informaț ii referitoare la ce a observat î n urma serviciului de imagistică, ca cea din
Figura 19:
Figura 19: Editare consultație imagistică
Adela -Mihaela Alecu
34
Prin apă sarea butonului “Terminare” , se marchează faptul că pacientul a bene ficiat de
serviciul recomandat și se actualizează suma pe care acesta va trebui să o achite pentru serviciul pus
la dispoziț ie.
5.7 Modulul client
Prin intermediul acestui modul, cl ientul are posibili tatea de a avea acces la istoricul să u
medical. Pent ru ca acest lucru să fie posibil, clientul trebuie să se autentifice folosind numele de
utilizator ș i parola asociate. Daca datele introduse sunt corecte, el va fi redirecționat că tre o pagin ă
identică cu cea din F igura 20. Practic, toate informaț iile despre istoricul medical pe care le poate
vizua liza un medic, sunt accesibile ș i pacientului.
Figura 20: Istoric medical pacient
În ca drul acestei pagini, v or fi afișate sub fo rmă tabelară toate consultaț iile pacientului.
Pentru fiecare consultație în parte, aș a cum se observă și în Figura 20, se va afișa data în care a fost
făcută , medicul car e a realizat -o, utilizatorul având totodată posibilitatea de a afla detalii
suplimenta re prin apă sarea butonului “Detalii”. La apă sarea acestuia, el va fi redirecționat î ntr-o
pagină ca cea din Figura 21:
Figura 21: Detalii consulta ție
Gestiune servicii medicale
35
6. Detalii de implementare
6.1 Nivelele aplicaț iei
Pentru integrarea cu arhit ectura MVC, respectiv Client -Server, la nivel logic s -a ales o
implementare a aplicației structurată pe 5 nivele:
Nivelul domain : clasele definite î n cadr ul acestui nivel vor fi mapate î n tabele ale bazei de
date, iar variabilele din cadr ul acestor clase vor fi mapate î n coloane ale tabelelelor din baza
de date. Acest lucru es te realizat prin folosirea libră riei Hibernate, care este o libră rie Java
ORM(Object -Relational M apping), prin intermediul adnotă rilor.
De exemplu , definirea clasei de mai jos va avea ca rezulta t obț inerea tabelei “programs” î n
baza de date , coloanele acesteia fiind illustrate în Figura 22 :
Figura 22: Tabela programs
Nivelul dao: î n cadrul aces tui nivel, pentru fiecare tabelă din baza de date există definite:
– O interfaț ă, în cadrul căreia se definesc operaț iile standard care pot fi realizate pe
obiectul din model corezpunză tor tabelei ; @Entity
@Table(name = "programs" )
public class Program {
@Id
@GeneratedValue (strategy = GenerationType. SEQUENCE , generator =
"programs_SEQ_GEN" )
@SequenceGenerator (name = "programs _SEQ_GEN" , sequenceName = "programs_SEQ" ,
allocationSize = 1, initialValue = 1)
private Long programId ;
@NotEmpty
private String day;
@Min(8)
@Max(20)
private Integer startTime ;
@Min(8)
@Max(20)
private Integer endTime;
@ManyToMany
@JoinTable (name = "users_programs" , joinColumns = @JoinColumn (name =
"programId" ), inverseJoinColumns = @JoinColumn (name = "userId" ))
private List<User> users;
Adela -Mihaela Alecu
36
– O clasă, care implemen tează interfața de mai sus, fiind responsabilă cu obț inerea
datelor din baza de date .
În plus, pe acest niv el se mai găsește și interfața GenericDao î n care sunt definite
operaț iile care su nt comune tuturor obiectelor ș i clasa Gen ericDaoImpl care o implementează .
În Figura 23 se poate observa un exemplu al modului în care interacționează elementele
acestui nivel cu elementele din nivelul domain.
Figura 23: Exemplu de interacțiune între nivelul dao și nivelul domain
Nivelul service: pentru fie care tabelă din baza de date există definită o interfață și o clasă
care o implementează . Pe lângă aceste a, mai sunt definite și interfața GenericService ș i clasa
GenericServiceImpl care o i mplementează . Rolul acestu i nivel este de a realiza operaț ii de
nivel superior, prin coordonarea obiectelor din nivelul domain. În cad rul acestui nivel, se
realizează și demarcarea tranzacț iilor, pentru a asigura faptul că oper ațiile realizate sunt
atomice. În caz contrar, operaț iile concurente pot aduce aplicația într -o stare inconsistentă .
Nivelul view : Acest nivel, este nivelul prin care utilizatorul interacționează cu logica
aplicației. În cadrul acestuia, sunt definite toate fiș ierele .jsp coresp unzătoare paginilor din
aplicaț ie, ce pot fi accesate de utilizator. Aceste pagini sunt grupate în funcție de modulele
prezentate î n capitolul 5. Descrierea aplicaț iei.
6.2 Fișiere de configurare
Pentru integrarea tuturor tehnologiilor utilizate la dezvolt area aplicaț iei, este necesară existenț a
următoarelor fiș iere de configurare :
web.xml : conține informații de configurare ș i de implemen tare pentru componentele
aplicaț iei w eb, ca de exemplu: primul pas necesar pentru a putea utiliza Spring MVC este
definirea unui D ispatcherServlet în acest fiș ier:
Gestiune servicii medicale
37
applicationContext.xml : activează modulul Application Context al framework -ului Spring. În
acest fiș ier este con figurat pachetul d e bază pentru rezolvarea depende nțelor, sunt
configurate modalităț i ce activează folosirea adnotă rilor și sunt definite urmă toarele bean –
uri: bean pentru stabilirea conexiunii cu baza de date, bean pentru gestionarea tranzacț iilor,
bean p entru upload -ul de fiș iere și pentru citirea prop rietăț ilor d e conectare la baza de date
din fisierul jdbc.properties .
jdbc.properties : conține informaț iile necesare pentru accesul la baza de date :
log4j.xml : prin intermedi ul acestui fiș ier, se r ealizează configurarea utilitarului de logging
log4j . Acesta conț ine mai multe nivele de log: OFF, FATAL, ERROR, WARN, INFO, DEBUG,
TRACE. În cazul aces tei aplicații, log4j a fost configurat să logheze doar mesajele
corespunză toare nivelului “info” sau ni velelor superioare .
pom.xml : conț ine detaliile de configurare a proiectului folosite de Maven. În proiectele
obișnuite, toate librăriile și fișierele .jar necesare sunt adă ugate manual la proiec t. În
proiectele dezvoltate folosind Maven, acestea sunt adă ugate la proi ect automat, pe baza
acestui fiș ier de configurare. În contextul acestui fisie r, bibliotecile și fiș ierele .jar sunt
cunoscute ca dependenț e. Exemplu de depende nță:
<servlet>
<servlet-name>appServlet </servlet-name>
<servlet-
class>org.springframework.web.servlet.Dispatch erServlet </servlet-class>
<init-param>
<param-name>contextConfigLocation </param-name>
<param-value>/WEB-INF/spring/appServlet/ servlet-
context.xml </param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<!– Oracle –>
<dependency >
<groupId>com.oracle </groupId>
<artifactId >ojdbc6</artifactId >
<version>11.2.0</version>
</dependency > jdbc.driverClassName= oracle.jdbc.driver.OracleDriver
jdbc.databaseurl= jdbc:oracle:thin:@127.0.0.1:1521:ORACLE
jdbc.username= scott
jdbc.password= 1234
Adela -Mihaela Alecu
38
7. Concluzii și îmbunătățiri viitoare
La momentul actual, există numeroase aplicații care vin în ajutorul domeniului medical, însă
este necesar ca acestea să fie din ce î n ce mai c omplexe, astfel încât să răspundă tuturor nevoilor
existente. Prin intermediul lucrării de față , s-a realizat dezvoltarea unei aplicații destu l de
cuprinză toare din punct de vedere al functionalității, flexibilă, ușor de folosit ș i cu o capacitate mare
de stocare a informaț iilor.
Pentru a facilita accesarea aplicației de un număr cât mai mare de utilizatori, în orice
moment al zilei, și de pe or ice stație de lucru, soluția abordată a fost dezvolta rea unui produs de
tipul aplicaț ie web, acesta fiind dedicat atât personalului clinicilor, cât și pacienț ilor.
Sistemul de față, aduce un plus față de majoritatea aplicațiilor existente în acest domeniu ,
prin încrederea pe care o inspiră pacienților: toate informaț iile despre un pacient care pot fi accesate
de un m edic, sunt disponibile și pacientului prin autentificarea pe bază de nume de utilizator și
parolă . Astfel, pacientul are libertatea de a alege serviciile din cadrul clin icii pentru calitatea acestora
și nu datorită faptului că alegerea une i alte clinici ar presupune pierderea de timp ș i bani pentru
repetarea unor investigaț ii.
În ceea ce priveș te proiectarea bazei d e date, aceasta a fost realiza tă astfel încât adăugarea
unor îmbunătățiri viitoare să nu necesite modifică ri majore.
În viitor, se doreș te crearea unui site de prezentare web, astfel încât pacienții să poată vedea
toate informaț iile referitoare la clinici: locații, specializă ri, medici , programul de lu cru, serviciile puse
la dispoziție și preț ul acestora. La momentul actual, am presupus că accesul la aceste informaț ii se
face telef onic sau prin intermediul broș urilor de prezentare. Printr -un astfel de site, clienții ar put ea
să își procu re singuri informațiile ș i să facă singuri rezervă ri.
O altă posibilă îmbunătăț ire, ar fi posibilitatea ca pacien ții să benefi cieze de consult la
domiciliu, în cazurile î n car e deplasarea acestora la clinică ar fi greu de realizat. Aceasta ar presupune
existența unor cadre medicale care să lucreze pe teren, a unui sistem prin care să se verifice locaț ia
acestora și care să notifice medicul care se află cât mai aproape de locaț ia pacientului.
În prezent, în cazul în care un pacient doreș te schimbarea numelui de utilizator sau a parolei,
sau în cazul î n care aceste date a u fost uitate, el este nevoit să sune la clinică pentru rezolvare a
problemei. Pe viit or, se dorește ca pacientul să î și poată modifica datele de acces sau să le poată
recupera prin primirea un ui mail.
Gestiune servicii medicale
39
8. Bibliografie și referinț e
8.1 Referințe
[1] tutorialspoint.com. Spring Framework 3.1 Tutorial.
http://www.tutorialspoint.com/spring/spring_tutorial.pdf , Iunie 2013
[2] docs.oracle.com. Introduction to the Java Persistence API.
http://docs.oracle.com/javaee/6/tutorial/doc/bnbpz.html , Iunie 2013
[3] docs.oracle.com. JPQL Language Reference.
http://docs.oracle.com/cd/E28613_01/apirefs.1211/e24396/ejb3_langref.html , Iunie 2013
[4] http://tomcat.apa che.org/ . Iunie 2013
[5] Ștefan Tanasă, Cristian Olaru,Ștefan Andrei. Java de la 0 la expert. Polirom 2003
[6] jquery.org. jquery Core. https://jquery.org/ . Iunie 2013
8.2 Bibliografie
1. Kevin Roebuck. Spring Framewor k: High -impact Strategies – What You Need to Know:
Definitions, Adoptions, Impact, Benefits, Maturity, Vendors . Mai 2013
2. maven.apache.org. Maven Getting Started Guide. http://maven.apache.org/guides/getting –
started/index.html#What_is_Maven . Mai 2013
3. Gavin King, Christian Bauer, Max Rydahl Andersen, Emmanuel Bernard, and Steve Ebersole.
HIBERNATE – Relational Persistence for Idiomatic Java. Mai 2 013
4. http://www.springsource.org/ . Iunie 2013
Adela -Mihaela Alecu
40
9. Anexa: Listing aplicație
9.1 Interfața ReservationDao .java
package ro.adal.HealthyPlus.dao;
import java.util.Date;
import java.util.List ;
import ro.adal.HealthyPlus.domain.Reservation;
import ro.adal.HealthyPlus.generic.dao.GenericDAO;
public interface ReservationDAO extends GenericDAO<Reservation> {
public List<Reservation> findByPacientNameStatus(String firstName, String lastName, Stri ng status);
public List<Reservation> findByStatus(String status);
public List<Reservation> findByMedicDate(Long id, Date reservationDate);
public List<Reservation> findByMedicStatusDate(Long id,String status1, String status2, Date
reservationDate);
}
9.2 Clasa ReservationDaoImpl .java
package ro.adal.HealthyPlus.dao.impl;
import java.util.Date;
import java.util.List;
import javax.persistence.Query;
import org.springframework.stereotype.Repository;
import ro.adal.HealthyPlus.dao.ReservationDAO;
import ro.adal.HealthyPlus.domain.Reservation;
import ro.adal.HealthyPlus.generic.dao.GenericDAOImpl;
@Repository
public class ReservationDAOImpl extends GenericDAOImpl<Reservation> implements
ReservationDAO {
public ReservationDAOImpl() {
super (Rese rvation. class );
}
@Override
@SuppressWarnings ("unchecked" )
public List<Reservation> findByPacientNameStatus(String firstName, String lastName, String status) {
Gestiune servicii medicale
41
Query query = getEm().createQuery(
"select s from Reservation s join s.pacient p wher e p.firstName ="
+ ":firstName and p.lastName = :lastName and s.status =
:status" );
query.setParameter( "firstName" , firstName);
query.setParameter( "lastName" , lastName);
query.setParameter( "status" , status);
List<Reservation> resultList = qu ery.getResultList();
return resultList;
}
@Override
@SuppressWarnings ("unchecked" )
public List<Reservation> findByStatus(String status) {
Query query = getEm().createQuery(
"select s from Reservation s where s.status = :status" );
query.setPa rameter( "status" , status);
List<Reservation> resultList = query.getResultList();
return resultList;
}
@Override
@SuppressWarnings ("unchecked" )
public List<Reservation> findByMedicDate(Long id, Date reservationDate) {
Query query = getEm().creat eQuery(
"select s from Reservation s where s.reservationDate = :reservationDate
and s.user.userId = :id" );
query.setParameter( "id", id);
query.setParameter( "reservationDate" , reservationDate);
List<Reservation> resultList = query.getResultList() ;
return resultList;
}
@Override
@SuppressWarnings ("unchecked" )
public List<Reservation> findByMedicStatusDate(Long id, String status1,
String status2, Date reservationDate) {
Query query = getEm().createQuery(
"select s from Reservation s where s.reservationDate = :reservationDate
and s.user.userId = :id and" +
" (s.status = :status1 or s.status = :status2) " );
query.setParameter( "id", id);
query.setParameter( "reservationDate" , reservationDate);
query.setParameter( "status1" , statu s1);
query.setParameter( "status2" , status2);
List<Reservation> resultList = query.getResultList();
Adela -Mihaela Alecu
42
return resultList;
}
}
9.4 Interfața Reservation Service .java
package ro.adal.HealthyPlus.service;
import java.util.Date;
import java.util.List;
import ro.adal.HealthyPlus.domain.Reservation;
import ro.adal.HealthyPlus.generic.service.GenericService;
public interface ReservationService extends GenericService<Reservation> {
public List<Reservation> findByPacientNameStatus(String firstName, String l astName,String status);
public List<Reservation> findByStatus(String status);
public List<Reservation> findByMedicDate(Long id, Date reservationDate);
public List<Reservation> findByMedicStatusDate(Long id, String status1,
String status2, Date r eservationDate);
}
9.5 Clasa Reservation ServiceImpl .java
package ro.adal.HealthyPlus.service.impl;
import java.util.Date;
import java.util.List;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
import ro.adal.HealthyPlus.dao.ReservationDAO;
import ro.adal.HealthyPlus.domain.Reservation;
import ro.adal.HealthyPlus.generic.service.GenericServiceImpl;
import ro.adal.HealthyPlus.servi ce.ReservationService;
@Service
public class ReservationServiceImpl extends GenericServiceImpl<Reservation>
implements ReservationService {
private ReservationDAO dao;
public ReservationDAO getDao() {
Gestiune servicii medicale
43
return dao;
}
@Autowired
public Reservatio nServiceImpl(ReservationDAO dao) {
super (dao);
this.dao = dao;
}
@Override
@Transactional
public List<Reservation> findByPacientNameStatus(String firstName, String lastName, String status) {
return dao.findByPacientNameStatus(firstName, lastName , status);
}
@Override
@Transactional
public List<Reservation> findByStatus(String status) {
return dao.findByStatus(status);
}
@Transactional
@Override
public List<Reservation> findByMedicDate(Long id, Date reservationDate) {
return dao.find ByMedicDate(id, reservationDate);
}
@Transactional
@Override
public List<Reservation> findByMedicStatusDate(Long id, String status1,
String status2, Date reservationDate) {
return dao.findByMedicStatusDate(id, status1, status2, reservationDate);
}
}
9.6 Clasa ReservationController .java corespunzătoare modul ului secretar
package ro.adal.HealthyPlus.controller.secretar;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Calendar;
import java.util.Date;
import java.util .List;
import java.util.StringTokenizer;
import javax.servlet.http.HttpSession;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
Adela -Mihaela Alecu
44
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.propertyeditors.Custo mDateEditor;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.annotation.InitBinder;
import org.springframework.web.bind.annotation .RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.ResponseBody;
import ro.adal.HealthyPlus.domain.Pacient;
import ro.adal.HealthyPlus.domain.Program;
import ro.adal.HealthyPlus.domain.Reservation;
import ro.adal.HealthyPlus.domain.User;
import ro.adal.HealthyPlus.service.PacientService;
import ro.adal.HealthyPlus.service.ReservationService;
import ro.adal.HealthyPlus.serv ice.UserService;
@Controller
@RequestMapping (value = "/secretar/new_reservation" )
public class ReservationController {
private final static Logger logger = LoggerFactory
.getLogger (ReservationController. class );
@Autowired
ReservationService reserv ationService ;
@Autowired
UserService userService ;
@Autowired
PacientService pacientService ;
@RequestMapping (value = "/list_all" )
public String list_all(Model model) {
List<User> users = userService .findByRole( "Medic" );
model.addAttribute( "list_all" , users);
return "secretar/new_reservation/list_all" ;
}
@RequestMapping (value = "/details" )
public String details(Long medicId, Model model) {
User user = userService .findByIdNotLazy(medicId);
model.addAttribute( "details" , user);
return "secretar/new_reservation/details" ;
}
@RequestMapping (value = "/search_name" )
Gestiune servicii medicale
45
public String search_name(String name, Model model) {
List<User> users = userService .findByLastName(name);
model.addAttribute( "listElem" , users);
return "secretar/new_res ervation/search" ;
}
@RequestMapping (value = "/search_userSpeciality" )
public String search_userSpeciality(String userSpeciality, Model model) {
List<User> users = userService
.findAllByUserSpecialityName(userSpeciality);
model.addAttribute( "listElem" , users);
return "secretar/new_reservation/search" ;
}
@RequestMapping (value = "/add1" )
public String add1(String medicId, Model model, HttpSession session) {
Reservation reservation = new Reservation();
Long id = Long. parseLong (medicId);
User user = userService .findByIdNotLazy(id);
model.addAttribute( "medic" , user);
model.addAttribute( "reservation" , reservation);
return "secretar/new_reservation/add1" ;
}
@RequestMapping (value = "/add" )
public String add(Long medicId, Model model , HttpSession session) {
if (session.getAttribute( "pacientFirstName" ) != null
&& session.getAttribute( "pacientLastName" ) != null
&& session.getAttribute( "pacientBirthDay" ) != null
&& session.getAttribute( "pacientCnp" ) != null) {
String url = "redirect:/secretar/new_reservation/add1?medicId="
+ medicId;
return url;
} else {
model.addAttribute( "medicId" , medicId);
return "secretar/new_reservation/add" ;
}
}
@RequestMapping (value = "/search_pacient" , method = RequestMethod. POST )
public String search_pacient(String firstName, String lastName, Date it,
Long medicId, Model model, HttpSession session) {
List<Pacient> pacients = pacientService .findByBirthDayName(it,
firstName, lastName);
if (pacients.size() != 0) {
session.setAttribute( "pacientFirstName" , firstName);
session.setAttribute( "pacientLastName" , lastName);
session.setAttribute( "pacientBirthDay" , it);
session.setAttribute( "pacientCnp" , pacients.get(0).getCnp());
Adela -Mihaela Alecu
46
String url = "redirect:/secretar /new_reservation/add1?medicId="
+ medicId;
return url;
} else {
String url = "redirect:/secretar/new_reservation/add?medicId="
+ medicId;
return url;
}
}
@SuppressWarnings ("deprecation" )
@RequestMapping (value = "/getfree" , method = RequestMethod. POST )
public @ResponseBody
List<String> getFree( @RequestParam (value = "dateVal" ) String dateVal,
@RequestParam (value = "medicId" ) Long medicId, Model model) {
Date date = new Date (dateVal);
Calendar cal = Calendar. getInstance ();
cal.setTime(date);
int d = cal.get(Calendar. DAY_OF_WEEK );
String day = getDayAsAString(d);
User user = userService .findByIdNotLazy(medicId);
List<Program> programs = user.getPrograms();
boolean hasProgram = false ;
Integer startTime = null;
Integer endTime = null;
List<Integer> reservationHoursFree = new ArrayList<Integer>();
List<Integer> reservationMinutesFree = new ArrayList<Integer>();
List<String> reservationsPosibilities = new ArrayList<String>();
Integer i, j;
for (Program p : programs) {
logger .info( "are program " + p.getDay());
if (p.getDay().equals(day)) {
hasProgram = true ;
startTime = p.getStartTime();
endTime = p.getEndTime();
break ;
}
}
if (hasProgram) {
// extrag toate posibilitatile
for (i = startTime; i < endTime; i++) {
reservationHoursFree.add(i);
reservationMinutesFree.add(0);
reservationHoursFree.add(i);
reservationMinutesFree.add(30);
}
// extrag toate rezervarile deja facute
List<Reservation> reservatio ns = reservationService
.findByMedicDate(medicId, date);
Gestiune servicii medicale
47
Boolean ok;
Integer hour, minute;
Reservation r;
String p = "";
for (i = 0; i < reservationHoursFree.size(); i++) {
ok = false ;
hour = reservationHoursFree.get(i);
minute = reservationMinutesFree.get(i);
for (j = 0; j < reservations.size(); j++) {
r = reservations.get(j);
if (hour == reservations.get(j).getReservationHour()
&& minute == reservations.get(j)
.getReservationMinute())
ok = true ;
}
if (ok == false ) {
p = reservationHoursFree.get(i).toString() + ":"
+ reservationMinutesFree.get(i).toString();
reservationsPosibilities.add(p);
}
}
logger .info( "Start: " + startTime + " End: " + endTime);
} else {
return new ArrayList<String>();
}
return reservationsPosibilities;
}
private String getDayAsAString( int i) {
String result = "";
switch (i) {
case Calendar. MONDAY :
result = "Luni" ;
break ;
case Calendar. TUESDAY :
result = "Marti" ;
break ;
case Calendar. WEDNESDAY :
result = "Miercuri" ;
break ;
case Calendar. THURSDAY :
result = "Joi" ;
break ;
case Calendar. FRIDAY :
result = "Vineri" ;
break ;
case Calendar. SATURDAY :
result = "Sambata" ;
Adela -Mihaela Alecu
48
break ;
case Calendar. SUNDAY :
result = "Duminica" ;
break ;
default :
break ;
}
return result;
}
@RequestMapping (value = "/cancel" )
public String cancel(Model model, HttpSession session)
{
session.removeAttribute( "pacientFirstName" );
session.removeA ttribute( "pacientLastName" );
session.removeAttribute( "pacientBirthDay" );
session.removeAttribute( "pacientCnp" );
return "redirect:/secretar/new_reservation/list_all" ;
}
@RequestMapping (value = "/doreservation" )
public String doReservation(Date i t, Long medicId, String reservationHour,
Model model, HttpSession session) {
if (reservationHour == null) {
model.addAttribute( "medicId" , medicId);
return "redirect:/secretar/new_reservation/add1" ;
}
StringTokenizer strtk = new StringTokeni zer(reservationHour, ":");
String Hour = " ", Minute = " ";
Integer aux = 0;
while (strtk.hasMoreElements()) {
if (aux == 0)
Hour = strtk.nextElement().toString();
else
Minute = strtk.nextElement().toString();
aux++;
}
Reservati on reservation = new Reservation();
reservation.setReservationDate(it);
reservation.setReservationHour(Integer. parseInt (Hour));
reservation.setReservationMinute(Integer. parseInt (Minute));
reservation.setStatus( "noua" );
String cnp = (String) se ssion.getAttribute( "pacientCnp" );
Pacient pacient = pacientService .findByCnp(cnp).get(0);
reservation.setPacient(pacient);
User user = userService .findByIdNotLazy(medicId);
Gestiune servicii medicale
49
reservation.setUser(user);
reservation.setOffice(user.getOffice());
session.removeAttribute( "pacientFirstName" );
session.removeAttribute( "pacientLastName" );
session.removeAttribute( "pacientBirthDay" );
session.removeAttribute( "pacientCnp" );
reservationService .saveOrUpdate(reservation);
logger .info(medicId + " " + reservationHour + " " + it);
return "redirect:/secretar/new_reservation/list_all" ;
}
@InitBinder
protected void initBinder(WebDataBinder binder) {
SimpleDateFormat dateFormat = new SimpleDateFormat( "MM/dd/yyyy" );
CustomDateEditor editor = new CustomDateEditor(dateFormat, true );
binder.registerCustomEditor(Date. class , editor);
}
}
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: 1.Introducere ………………………….. ………………………….. ………………………….. …………………………….. [626442] (ID: 626442)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.