Academia de Studii Economice [603639]

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Realizarea unui sistem informatic pentru activitatea
unui cabinet medical

Scarlat Adriana -Mihaela

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Cuprins

Introducere ………………………….. ………………………….. ………………………….. ………………………….. …… 4
1. Definirea problemei ………………………….. ………………………….. ………………………….. …………….. 5
1.1. Specificarea cerințelor ………………………….. ………………………….. ………………………….. ……… 6
2. Diagrame ………………………….. ………………………….. ………………………….. ………………………….. . 7
2.1 Diagrama generală a cazurilor de utilizare ………………………….. ………………………….. …………… 7
Diagrama cazului de utilizare realizare prog ramare ………………………….. ………………………….. ……. 9
Diagrama cazului de utilizare consultație ………………………….. ………………………….. ………………….. 9
2.1.2 Descrierea textuală a cazurilor de utilizare ………………………….. ………………………….. ………. 11
Descrierea textuală pentru cazul de utilizare programare ………………………….. ……………………….. 11
Descrierea textuală pentru cazul de utilizare co nsultație ………………………….. ………………………… 12
2.2 Diagrame de activități ………………………….. ………………………….. ………………………….. …………. 13
2.2.1 Diagrama de activitate pentru programare ………………………….. ………………………….. ……….. 13
2.2.2 Diagrama de activitate pentru consultație ………………………….. ………………………….. ………… 14
2.3 Diagrama de clase ………………………….. ………………………….. ………………………….. ………………. 15
2.4 Diagrame de stare ………………………….. ………………………….. ………………………….. ………………. 16
2.4.1 Diagrama de stare pentru Programare ………………………….. ………………………….. ……………… 16
2.4.2 Diagrama de stare pentru utilizator aplicație ………………………….. ………………………….. ……. 17
2.5 Rafinarea diagramelor UML ………………………….. ………………………….. ………………………….. … 18
Rafinarea claselor indusă de structură ………………………….. ………………………….. …………………….. 19
3.Proiectarea sist emului informatic ………………………….. ………………………….. ………………………… 20
3.1. Arhitectura sistemului ………………………….. ………………………….. ………………………….. ………… 20
3.2 Proiectarea bazei de date ………………………….. ………………………….. ………………………….. ……… 21
3.3 Proiectarea modulelor ………………………….. ………………………….. ………………………….. …………. 22
3.4 Proiectarea intrarile – iesirilor , meniurilor ………………………….. ………………………….. …………. 22
Datele de iesire constau in: ………………………….. ………………………….. ………………………….. ……. 24
3.5 Tehnologiile informatice utilizate ………………………….. ………………………….. ……………………… 24
4.Implementarea sistemului informatic ………………………….. ………………………….. …………………… 25
4.1 Prezentare site ………………………….. ………………………….. ………………………….. ……………………. 25
4.2. Prezentare aplicatie desktop ………………………….. ………………………….. ………………………….. … 25
4.2.1 Meniu administrator de sistem ………………………….. ………………………….. ……………………….. 26

Academia de Studii Economice
Baze de date – Suport pentru afaceri

4.4 Plan de mentenanta ………………………….. ………………………….. ………………………….. …………….. 31
4.5 Pl an de audit ………………………….. ………………………….. ………………………….. ………………………. 31

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Introducere

Domeniul medical este unul dintre cele mai importante pentru dezvoltarea unei economii
prospere pentru o țară. Pe fondul descoperirilor, ca urmare a cercetării în domeniu, sectorul
medical a cunoscut în ultimii ani, o creștere semnificativă a calității serviciilor medicale.
Informatica medicală susține ritmul accelerat de dezvoltare și ajută persoanele implicate
prin metode moderne de asistentă și îndrumare în procese.
Astfel, informatica medicală se ocupă cu obținerea și mentenanța resurselor, dispozitivelor
și metodelor necesare pentru a optimiza achiziționarea, stocarea, recuperarea și utilizarea de
informații în domeniul sănătății și biomedicinei în zonele de asistentă și îngrijire medicală,
stomatologie, farmacie, cercetare și asigurare medicală obligatorie.
Utilizarea sistemelor informatice în medicină au ca final beneficiar pacientul: programările
sunt gestionate, docto rul(elementul decizional) are acces neconditionat si imediat la întreg
istoricul pacientului eliminându -se asftel greșeli în planul de tratament, utilizarea sistemelor
expert pentru diagnoză, casieria este gestionata automat, standardizarea si uniformizare a
procedurilor si metodelor.
Toate aceste servicii sunt gândite pentru a oferi un cadru modern de lucru având ca element
central excelența.
În prezent, există o răspândire semnificativă a sistemelor informatice pentru cabinetele
medicale. Acestea sunt mij loace de înregistrare, informare și comunicare a datelor cu privire la
starea de sănătate a populației asistate și la activitatea desfășurată de către medic. Aceste sisteme
susțin funcționalitatea sistemului sanitar, stochează și evaluează activitatea medi cală,
influențează și controlează actul medical, satisfăcând în mare măsură doleanțele în interesele
pacientului.

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Scopul acestei lucrari îl reprezintă susținerea importanței noilor tehnologii informaționale
în sistemul de sănătate precum și conceperea, cre area și implementarea unei noi aplicații
medicale pentru îmbunătățirea și eficientizarea condițiilor de lucru și a calității serviciilor oferite
pacienților la nivelul unui cabinet medical. Proiectul presupune parcurgerea etapelor necesare
realizării unui sistem informatic care oferă suport pentru desfășurarea activitățiilor unui cabinet
medical. Pentru modelarea sistemului se va folosi limbajul UML.

1. Definirea problemei

Pentru a realiza și implementa o aplicație informatică cu success, care să ușureze
activitatea de analiză a datelor despre pacienți din cadrul unui cabinet medical, este util un studio
cât mai amănunțit al sistemul informațional din cadrul acestui domeniu.
În momentul actual, există o largă preocupare atât din partea firmelor producătoare d e soft,
cât și a Ministerului Sănătății pentru crearea de sisteme informatice medicale, în scopul
informatizării cabinetelor medicale și a spitalelor. Ca urmare a implementării acestor sisteme
informatice sunt oferite soluții complexe, în scopul sprijiniri i activității medicale în zone precum
evidența electronică a datelor medicale, crescând astfel calitatea și eficiența activității instituțiilor
și personalului medico -sanitar.
Activitatea desfășurată într -un cabinet de medicină poate fi ușor informatizată , ușurând
astfel în mod vizibil munca personalului.
Activitatea de evidență a pacienților este una dintre cele mai importante activități într -un
cabinet medical, fiind necesare datele personale ale acestora precum și informații referitoare la
situația sănă tății, a consultațiilor și a tratamentelor efectuate. Tot aici intervine și problema
evidenței programărilor și a disponibilității medicilor.
O altă activitate importantă este cea de evidență a angajaților, necesară managerilor pentru
a verifica activitate a acestora, a acorda anumite bonusuri și pentru luarea unor decizii de reduceri
sau măriri de personal. Tot pentru management este vitală evidența veniturilor și a cheltuielilor.
Veniturile provin din plățile efectuate de pacienți, iar cheltuielile din sal arii și din aprovizionările
cu materii prime.

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Scopul lucrării este de a realiza un produs software eficient pentru informatizarea tuturor
acestor activități.
Aplicația ce urmează a fi realizată prezintă trecerea de la metoda tradițională de
organizarea a a ctivității unui cabinet medical, la informatizarea și automatizarea funcțiilor de
gestiune și organizare, ceea ce va conduce la o fluidizare a funcțiilor fiecărui angajat, dar și la
redefinirea funcțiilor și sarcinilor acestora.

1.1. Specificarea cerințelor

Pentru înțelegerea corectă a sistemului informatic dezvoltat este necesară mai întâi
înțelegerea importanței informaților procesate de către cabinetul medical, dar și a fluxurilor care
au loc la nivelul acestuia. Astfel că acesta trebuie să răspundă în tot alitatea necesităților
cabinetului. Sistemul proiectat va fi folosit de către acest cabinet în vederea monitorizării,
analizei și raportării activității.
Etapa de specificare a cerințelor are drept activitate principală identificarea actorilor și a
cazuril or de utilizare și ca scop delimitarea sistemului, definirea actorilor ce vor interacționa cu
sistemul și a funcționalităților ce se așteaptă de la sistem, capturarea și definirea unui glosar de
termeni comuni, esențiali pentru o descriere detaliată a func ționalității sistemului. Rezultatul
acestei etape este diagrama cazurilor de utilizare.
Obiectivul final al acestui proiect software este o aplicație care răspunde tuturor cerințelor
beneficiarului. Prin identificarea și verificarea cazurilor de utilizare se urmărește ca toate
cerințele să fie luate în considerare, pentru o ușoara utilizare a programului.

Academia de Studii Economice
Baze de date – Suport pentru afaceri

2. Diagrame

2.1 Diagrama generală a cazurilor de utilizare

În urma analizei s -a modelat o diagramă principală a cazurilor de utilizare care surpinde
modul în care actorii interacționează cu cabinetul medical, oferind o perspectivă generală asupra
sistemului ce urmează a fi dezvoltat. Aceasta diagramă grupează acțiunile efectuate de către
actorii care participă la diferite activități asupra sistemului informatic.

Fig. 1 – Diagrama generală a cazurilor de utilizare

Actorii identificați în cadrul diagramei sunt:
Administratorul aplicației este cel care gestionează utilizatorii prin crearea conturilor,
acordarea drepturilor de acces la aplicație și gestionarea conturilor existente.
Pacientul este un personaj extern aplicației. El nu interacționează direct cu aceasta, dar
oferă in formații sistemului prin intermediul secretarei. Acesta este cel care poate solicita o
programare și care trebuie să plătească pentru serviciile oferite de cabinet.
Medicul este principalul beneficiar al aplicației, fiind cel care se ocupă de consultarea ș i
tratarea pacienților, iar în urma realizării acestora, este și cel care va comunica secretarei prin

Academia de Studii Economice
Baze de date – Suport pentru afaceri

intermediul aplicației, suma totală pe care pacientul o are de plată. În momentul consultației, va
putea vizualiza toate datele asupra unui pacient, între aga sa istorie medicală.
Secretara are un acces limitat asupra aplicației, principala sa funcție este aceea de a emite
bonul de plată și încasarea contravalorii acestuia. Ea poate vizualiza lista tuturor programărilor și
prin intermediul actorului pacient, care solicită anumite modificări, poate interveni în sistem să le
realizeze.
Managerul este cel care se ocupă de adăugarea anumitor date ce țin de confidențialitatea
conducerii și de asemenea poate vizualiza diferite informații și rapoarte.
În urma aces tor analize precum și a relațiilor care se stabilesc între actorii participanți și
cabinetul medical s -au individualizat următoarele activități pe care le vom modela în continuare
și le vom numi cazuri de utilizare:
– solicitare programare – cu cazurile de utilizare – solicitare reprogramare și solicitare
anulare programare . Între aceste două subcazuri ale cazului de programare se află o
relație de includere, datorat faptului că cele două acțiuni nu se pot realiza în lipsa
programării inițiale.
– verificare disponibilitate – acest caz se află și el în relație de includere cu cazul
“solicitare programare” și face trecerea în sistem de la actorul pacient la actorul secretară.
– confirmă programare
– introduce date personale
– achită consultația
– înregistrare plat ă
– vizualizare date pacient
– adăugă consultatie
– adăugă tratament se află în relație de extindere față de cazul de utilizare “adăugă
consultație", datorită faptului că doctorul poate realiza o consultație, dar nu întotdeauna
este nevoie de un tratament;
– vizualizare preț
– vizualizări informații
– adăugări date
– creare conturi

Academia de Studii Economice
Baze de date – Suport pentru afaceri

– gestiune conturi

Diagrama cazului de utilizare realizare programare

Pacientul existent în baza de date, poate solicita o programare, la o anumită dată și ora.
Secretara este cea care verifică disponibilitatea și poate confirma rezervarea sau oferi alte
sugestii pacientului, însă pentru a avea acces la sistem, aceasta trebuie să se autentifice.
Pacientul, în urma informațiilor primite poate confirma sau refuza programarea. Deasemen ea, el
poate solicita o reprogramare. Similar cu acest caz se află și cazul de solicită anulare. Ambele
cazuri de utilizare, reprogramarea și anularea necesită o confirmare din partea pacientului, lucru
înregistrat de sistem prin intermediul secretarei.

Fig. 2 – Diagrama cazului de utilizare programare

Diagrama cazului de utilizare consultație

În urma programării, pacientul se prezintă la consultație. Acesta poate primi consultație și
fără programare, însă în această situație el va plăti costuri supl imentare. Pentru a realiza
consultația, medicul se autentifică la aplicație. În cazul în care acesta dorește, poate vizualiza
istoricul pacientului. În urma consultației, el stabilește un diagnostic și dacă este necesar și un

Academia de Studii Economice
Baze de date – Suport pentru afaceri

tratament. Pacientul care bene ficiază de consultație va plăti consultația (cash sau card), iar
secretară, va înregistra plata.

Fig. 3 – Diagrama cazului de utilizare consultație -pacient

Academia de Studii Economice
Baze de date – Suport pentru afaceri

2.1.2 Descrierea textuală a cazurilor de utilizare

Descrierea textuală pentru cazul de utilizare programare

Element al cazului de
utilizare Descriere
Cod CU01
Stare Schiță
Scop Gestiunea programărilor pentru un cabinet medical
Nume Realizare programare
Actor principal Pacient
Descriere Presupune realizarea unei programări pentru o consultație
Precondiții Secretara este logată în sistem
Postcondiții Programarea a fost realizată,secretara primind confirmarea/refuzul
programării.
Declanșator Pacientul solicită o programare prin e -mail sau telefonic.
Flux de bază 1. Pacientul furnizează seceretarei data și ora consultației și tipul de
consultație dorită[Punct de extindere CU02 Solicită
reprogramare.Punct de extindere CU03 Solicită anularea programării.].
2.Secretara verifică disponibilitatea medicului.
3.Secretara îl înștiințează pe pacient ca se poate realiza o consultație în
ziua respectivă [Curs alternativ A: Nu există posibilitatea realizării
unei programării conform cerințelor clientului.]
4. Pacientul confirm programarea. [Curs alternativ B: Clientul refuză
progr amarea.]
Fluxuri alternative A.
1. Secretara solicita/ofera alternative.
2. Clientul selectează o alternativă, altfel scenariul se termină.
B.
1. Pacientul refuză programarea și scenariul se încheie.
Relații Se extinde prin CU02 (solicită reprogramare) și CU03 (solicită anulare
programare).
Frecvența utilizării Foarte frecvent
Reguli de afaceri

Fig. 4 – Descierea textuală pentru cazul de utilizare programare

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Descrierea textuală pentru cazul de utilizare consultație

Element al cazului de
utilizare Descriere
Cod CU04
Stare Schiță
Scop Gestiunea consultațiilor
Nume Consultație
Actor principal Pacient
Descriere Realizarea unei consultații
Precondiții Secretara și medicul sunt logați în sistem
Postcondiții Consultația a fost realizată,pacientul fiind diagnosticat.
Declanșator Pacientul solicită o consultație, realizând o programare.
Flux de bază 1. Medicul realizează consultația. [Curs alternativ A: Nu există
programare.]
2.Medicul vizualizează datele despre pacient.
3.Medi cul stabilește un diagnostic.[Punct de extindere
CU10:Pacientului i se recomandă un tratament.]
4. Pacientul achită consultația.
5. Secretara înregistrează plata.
Fluxuri alternative A.
1. Secretara verifică disponibilitatea.
2. Clientul plătește costuri suplimentare.
Relații Se extinde prin CU10 – recomandare tratament.
Frecvența utilizării Foarte frecvent
Reguli de afaceri

Fig.5 – Descrierea textuală pentru cazul de utilizare consultație
Analiza sistemului informatic este o componentă esențială a procesului de realizare a
unui sistem informatic, având ca obiectiv principal cunoașterea sistemului existent și stabilirea
modului în care acesta poate să satisfacă cerințele managementului organizației. În continu are,
am prezentat diagramele de activitate, diagrama de clase și diagramele de stare care ne vor ajuta
la analiza sistemului informatic.

Academia de Studii Economice
Baze de date – Suport pentru afaceri

2.2 Diagrame de activități

Pentru o mai bună înțelegere a operațiilor, în special a celor complexe, se realizează
diagrama de activitate. Aceasta se prezintă sub forma unei scheme logice, care arată fluxurile de
control dintre activități și este folosită pentru a modela aspectele dinamice ale sistemului,
modelarea unui proces efectuându -se pas cu pas.

2.2.1 Diagrama de activitate pentru programare

În momentul în care un pacient dorește o programare la un medic, secretara va introduce
datele în sistemul de programări. Mai întâi aceasta verifică dacă pacientul există în baza de date.
În cazul în care pacientul nu es te înscris, pacientul va furniza informații de identificare, iar
secretara îl va adăuga în baza de date. Dacă datele sunt valide, se va afișa pagina de start pentru
programări. Secretara verifică programul medicului pentru ziua în care pacientul dorește să se
programeze. Pacientul primește informații cu orele libere în ziua respectivă, își alege ora și
confirmă programarea. În cazul în care medicul nu este disponibil în ziua respectivă, pacientul va
solicita programul acestuia pentru altă zi. Programarea va fi înregistrată în baza de date.

Fig.6 – Diagrama de activitate pentru programare

Academia de Studii Economice
Baze de date – Suport pentru afaceri

2.2.2 Diagrama de activitate pentru consultație

Pentru a putea evidenția rolurile implicate în realizarea fiecărei activități, gruparea
activităților executate de același obiect și apartenența activităților la cazurile de utilizare, am
reprezentat aceasta diagramă prin intermediul partițiilor.
Medicul accesează aplicația. Sistemul va afișa pagina de logare, iar medicul își va
introduce datele de identificare. În ca zul în care datele sunt valide, se va deschide aplicația, în
caz contrar, medicul va fi redirecționat pe pagina de logare. Medicul vizualizează lista cu
programări și selectează pacientul pe care urmează să îl consulte. Pacientul prezintă simptomele,
medic ul stabilește diagnosticul, și tratamentul dacă este necesar. După terminarea tratamentului
pacientul va reveni la consult. Consultația este înregistrată în baza de date .

Fig. 7 – Diagrama de activitate pentru cazul de utilizare cnsultație

Academia de Studii Economice
Baze de date – Suport pentru afaceri

2.3 Diagrama de clase

Diagrama de clase este cea mai importantă diagramă în cadrul etapei de analiză, al cărei
scop este de a structura natura statică a claselor.

Fig. 8 – Diagrama de clase
Din această diagramă putem observa legăturile directe dintre cla se.
Clasa Angajati este utilizată pentru a reține datele personale ale acestora.
Clasa Pacient reține datele pacienților înscriși la cabinetul medical împreună cu toate
observațiile și atențiile asupra istoricului medical pe care aceștia le -au avut.
Programare. Această clasă reține detalii asupra programărilor, incluzând detalii asupra
medicului, pacientului, datei și orei la care programarea trebuie să aibă loc.
Clasa Reprogramare, permite pacientului să modifice anumite condiții ale programării
iniția le (doctor, dată, oră).
Fiecărei programare include o consultație, lucru evidențiat în clasa Consultație. În urma
consultației se va stabili un diagnostic care va fi reținut în clasa Diagnostic. Dacă va fi necesar
pacientul va urma la indicațiile mediculu i și un tratament – clasa Tratament, pe baza unei sau
mai multor rețete – clasa Rețeta.
Pacientul va plăti serviciile medicale de care va beneficia. Acest preț total va fi reținut în
clasa Factura, pe baza căreia se va ține o evidență a plăților realizate în clasa Plă ți.

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Această diagramă va fi detaliată în faza de proiectare prin prezentarea multiplicității,
asociațiilor, atributelor și a operațiilor existente la fiecare clasă, atunci putându -se observa mai
bine interacțiunea care există între acestea.
2.4 Diagrame de stare

Diagrama de stări face parte din diagramele de comportament dinamic ale sistemului, fiind
realizată pentru a reflecta evoluția în timp a unui obiect aparținând unei anumite clase. O
diagramă corespunde unei singure clase (stări ale unei singure clase).

2.4.1 Diagrama de stare pentru Programare

Pacientul dorește o programare, moment în care programarea este în curs de editare. În
momentul în care programarea este adăugată în sistem se află în starea de programare în curs de
aprobare. Dacă medicul este disponibil și pacientul este de acord cu programul acestuia
programarea devine programare aprobată, în caz contrar programarea devine programare
neaprobata. Dacă se oferă alternative și sunt acceptate, aceasta va trece din nou la starea î n curs
de editare, în caz contrar va deveni programare refuzată. Dacă pacientul se răzgândește, se poate
reprograma – Reprogramată, sau poate anula programarea – programare anulată. În cazul în care și
pacientul și secretara confirmă programarea aceasta va fi în starea – programare confirmată.

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Fig. 9 – Diagrama de stare PROGRAMARE

2.4.2 Diagrama de stare pentru utilizator aplicație

Utilizatorul nu există în baza de date, el fiind utilizator inexistent. În momentul în care
este creat devine utilizator creat . Prin acordarea de drepturi manageriale, drepturi de medic sau
drepturi de secretar utilizatorul se prezintă în următoarele stări: manager, medic, secretara. În
momentul logării oricărui dintre acești utilizatori, utilizatorul este utilizator logat. Când aceștia se
deloghează ei trec în starea de utilizator delogat.

Fig. 10 – Diagrama de stare UTILIZATOR

Academia de Studii Economice
Baze de date – Suport pentru afaceri

2.5 Rafinarea diagramelor UML

Atât diagramele de clase, cât și cele de interacțiune nu se realizează “dintr -o dată”, ci după
o serie de iterații care presupun rafinarea paralelă a acestora.
Rafinarea diagramelor de clase prin specializare/generalizare
Operațiile de generalizare și specializare a claselor permit crearea de noi clase care nu pot
fi identficate direct prin intermediul documentului de specificare funcțională a sistemului
informatic modelat. Astfel, generalizarea conduce la crearea de noi clase ce vor conține
atributele, operațiile și asocierile commune unui grup de clase deja identificate.

Fig. 11 – Rafinarea clasei Pa cient prin specializare/generalizare

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Fig.12 – Rafinarea clasei Angajati prin specializare/generalizare

Rafinarea claselor indusă de structură
Dacă un obiect al unei clase nu necesită un anumit atribut sau o anumită operație,
identificate în diagrama de clase în fazele timpurii ale analizei, este foarte probabil că acea clasă
trebuie să fie descompusă în două sau mai multe clase. De exemplu, pentru clasa Programare, în
loc de un atribut reprogramare se creează o nouă clasă.

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Fig. 13 – Rafin area claselor indusă de structură

3.Proiectarea sistemului informatic

Proiectarea sistemului informatic este o etapă importantă în realizarea sistemelor
informatice. În cadrul ei se construiește arhitectura noului sistem, se proiectează logic și fizic
componentele unui sistem informatic.
3.1. Arhitectura sistemului

Sistemul informatic face parte din categoria SGBDR (Sistem de Gestiune a Bazelor de
Date Relationale) , va putea fi accesat prin reteaua Internet si va fi realizat intr -o arhitectura pe
trei niveluri (three tier). Nivelurile arhitecturii sunt: nivelul de date, nivelul de aplicatie si nivelul
de prezentare a datelor.
Tehnologiile utilizate pentru realizarea sistemului informatic sunt urmatoarele:
– pentru nivelul de date: sistem de gestiune a bazelor de date SQL Server ;
– pentru nivelul de aplicatie: ASP .NET ,C#;
– pentru nivelul de prezentare a datelor: HTML, CSS (pentru controlul stilurilor la afisare),
Server de web IIS .

Academia de Studii Economice
Baze de date – Suport pentru afaceri

3.2 Proiectarea bazei de date

Baza de date este formata din 9 tabele , dupa cum se observa si in reprezentarea din
figura 14.

Fig. 13 – Schema bazei de date

Tabelele contin informatii cu privire la cabinetul medical, angajatii acestuia, pacienti,
programarile efectuate precum si diagnosticul primit in urma con sultatiei .
Intre tabele exista urmatoarele relatii :
– In cadrul unei specializari pot fi incluse unul sau mai multe servicii ; un serviciu
apartine unei singure specializari;
– Un angajat poate avea o singura specializare; o specializare poate fi detinuta de mai
multi angajati;
– Un pacient poate avea una sau mai multe programari ; o programare este facuta pentru
un singur pacient;
– Un pacient poate face una sau mai multe programari online ; o programare online este
facuta pentru un singur pacie nt;
– O programare poate fi facuta pentru una sau mai multe servicii ; pentru un serviciu se
pot face una sau mai multe programari ; relatia M -M a fost impartita in 2 relatii 1 -M prin crearea
tabelei Programari_servicii;

Academia de Studii Economice
Baze de date – Suport pentru afaceri

– In urma unei programari se pot pune unul sau mai multe diagnostice ; un diagnostic este
pus pentru o singura programare.
3.3 Proiectarea modulelor

Aplicatia software este proiectata intr -o structura modulara, alcatuita din:
– Autentificare
– Programare
– Reprogramare
– Consultație
– Diagnostic ări
– Tratament
– Plata
– Configurări – prin intermediul acestui modul se vor introduce date referitoare
personalului cabinetului medical, date referitoare pacienților cabinetului și date
referitoare materialelor pe care le deține și utilizează cabinetul.
– Listar e – acest modul va permite printarea diferitelor rapoarte.
– Căutarea pacienților – acest modul va permite secretarei căutarea pacienților în funcție
de nume, cât și vizualizarea tuturor informațiilor generale despre pacientul căutat.

3.4 Proiectarea intr arile – iesirilor , meniurilor

In figura 15 se pot observa ierarhiile existente in cadrul aplicatiei.

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Figură 15 Diagramă de structură a ecranului

Figura arată cum decurge procesul de logare al utilizatorilor, modalitatea în care
utilizatorul interacționează cu interfața sistemului informatic în procesul de autentificare. În urma
logării se observă o divizare în alte patru submodule, cel al administratorului, al medicului, al
secretarei și al managerului. Pentru o mai bună înțelegere a subdiviz ării existente, la fiecare
submodul se pot observa anumite operații ce vor putea fi remarcate mai apoi în implementarea
aplicației.
Datele de intrare constau in:
– Date personale pacienti : nume, prenume, CNP , telefon, adresa etc.
– Date personale medici : nu me, prenume, CNP , telefon, adresa etc.
– Date consultatie : data , ora , pacient etc.
– Diagnostic consultatie
– Tratament pacient

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Datele de iesire constau in:
– Istoric programari pacient
– Istoric medical pacient
– Grad de incarcare medici
– Factura

3.5 Tehnologiile informatice utilizate

Pentru asigurarea eficienței, siguranței și flexibilității în dezvoltarea aplicațiilor este
necesar ca la alegerea limbajului de programare să avem în vedere o serie de aspecte, cele mai
importante fiind:
– tipul problemei ce urmează a fi rezolvată;
– cunoștințele utilizatorului;
– tipul echipamentelor de care dispune utilizatorul;
– gradul de dependență față de echipamentul folosit;
– gradul de standardizare a limbajului;
– cerințele de ordin economic;
De asemenea, trebuie să se țină seama de măsura în care limbajul de programare este
convenabil pentru utilizator, fiind esențial ca acesta să asigure ușurința în utilizare, timp redus
pentru prelucrarea datelor, confidențialitate și totodată o securitate corespunzătoare.
Pentru realizarea aplicatiei ce are ca scop gestiunea activitatii cabinetului s -au folosit
doua tehnologii. Pentru modelarea problemei s -a utilizat Visual Paradigm for UML Enterprise
Edition.
Pentru dezvoltarea aplicatiei s -a utilizat Microsoft Visual Studio 2013.
Limbajul de programare folosit pentru realizarea proiectului este limbajul ASP .NET , iar
SGBD -ul folosit SQL Server.
În Visual Paradigm s -au realizat totalitatea schemelor pe baza modelării problemei.
Visual Paradigm for UML este o unealtă vizuală UML CASE care este de mare ajutor în
construirea aplicațiilor într -un mod mult mai rapid, mai bun și mai ieftin. Cu ajutorul acestui

Academia de Studii Economice
Baze de date – Suport pentru afaceri

instrument se pot construi toate modelele de diagrame de modelare, oferindu -se și facilitatea de
generare de cod în diferi te limbaje de programare. În special în cursul fazelor de analiză și
dezvoltare a procesului, Visual Paradigm for UML ajuta la obținerea unui produs de calitate
superioară.

4.Implementarea sistemului informatic

Sistemul informatic proiectat pentru îmbunãtãțirea activitãții unui cabinet medical este
compus din douã pãrți: un site web, la care au acces atât persoanele din interiorul cabinetului cât
și din afara acestuia, și o aplicație desktop, la care au acces doar persoanele din interiorul
cabinetul ui.
4.1 Prezentare site

Site-ul conține patru pagini principale ce pot fi accesate de cãtre orice persoanã:
– Pagina de prezentare a cabinetului care con tine informatii cu privire la cabinet.
– Pagina de contact conține datele de contact ale cabinetului, precum și indicații de
orientare pentru a ajunge la aceasta
– Pagina de prezentare a serviciilor disponibile afișeazã, prin selectarea din tabela
Servicii a bazei de date, informatii despre tariful serviciilor unei anumite specialitati,
– Pagina de efectua re programare ofera pacientilor posibilitatea de a efectua o
programare online pentru o anumita specialitate, programare ce urmeaza a fi confirmata prin
telefon/e -mail de unul din angajatii cabineului medical.
4.2. Prezentare aplicatie desktop

Pentru asig urarea confidențialitãții și securitãții datelor, accesul la aplicație se face în
urma unei logãri, astfel persoanele neautorizate nu au acces la datele companiei, iar persoanele
autorizate au acces la diferite module ale aplicației, în funcție de drepturi le de acces, dupã cum
urmeazã:

Academia de Studii Economice
Baze de date – Suport pentru afaceri

– Administratorul de sistem are acces doar la modulul de introducere/editare
angajati (medic/asistenta) precum si la acordarea drepturilor de acces in aplicatie;
– Medicul are acces la vizualizarea/editarea datelor personale , precum si la
vizualizarea programului pentru ziua respectiva/pentru toata saptamana in curs . De asemenea,
medicul este responsabil si de introducerea diagnosticului si tratamentului pacientului in urma
consultatiei;
– Asistenta are acces la vizualizarea /editarea datelor personale, la
adaugarea/editarea datelor unui pacient, adaugarea/editarea specialitatilor si serviciilor, precum
si la modulul de efectuare programari.

4.2.1 Meniu administrator de sistem

Administratorul de sistem este cel care acordã d repturi de acces utilizatorilor la aplicație.
În momentul în care este introdusã o parolã greșitã, acesta este atenționat iar accesul nu este
permis, dupã cum se observã și în figura 4.1. In momentul în care sunt introduce username -ul și
parola corecte, ac cesul la aplicație este permis, fereastra principalã care apare fiind cea din figura
4.2:

Fig. 4.1 Blocare acces admin

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Fig. 4.2 Meniu administrator

Administratorul de sistem are, de asemenea, rolul de a gestiona datele medicilor si
asistentelor , precum si acordarea drepturilor acestora de acces in aplicatie, dupa cum se poate
observa si in figurile urmatoare.

Adaugare/stergere/vizualizare medic

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Adaugare/stergere /vizualizare asistenta

Academia de Studii Economice
Baze de date – Suport pentru afaceri

4.4 Plan de mentenanta

Serviciul de mentenanta presupune efectuarea unor servicii de intretinere a siteului si a
aplicatiei si actualizarea la zi cu cele mai noi update -uri.
Planul de mentenanta include si :
Modificari efectuate la solicitarea clientului ;
Consultanta specializata;
Implement are module noi;
Update -uri de securitate;
Realizare si integrare module interactive: socializare, blog, forum;
Modificari de aspect;
Optimizare cod sursa;
4.5 Plan de audit

Planul de audit pentru aplicatia realizata contine :
– Analiza tehnologiilor utili zate;
– Analiza accesului in aplicatie :

Academia de Studii Economice
Baze de date – Suport pentru afaceri

Cum este reglementat accesul in aplicatie ?
Cum este monitorizat accesul in aplicatie? Exista jurnale de audit pentru a monitoriza
cine acceseaza aplicatia?
Care sunt setarile de parola aferente aplicatiei?
Accesul utilizatorilor este autorizat și creat corespunzător?
Care sunt riscurile de securitate identificate?
– Analiza modificarilor aduse aplicatiei
Cine si cum initiaza o modificare adusa aplicatiei?
Cine aproba modificarea pentru a fi dezvoltata?
Cine si cum t esteaza modificarile aduse aplicatiei?
Cine si cum monitorizeaza modificarile aduse aplicatiei?
– Analiza stocarii datelor
Cum se realizează backup -ul informațiilor din aplicație? Cât de des este verificat backup –
ul și cum? Cine are acces la ele?
Exista un plan de recuperare in caz de dezastru?