Sistem de gestiune a datelor medicale ale pacienților [623899]

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

PROIECT DE DIPLOMĂ
Sistem de gestiune a datelor medicale ale pacienților

Student: [anonimizat] : S.l. dr. ing. Șerban OPRI ȘESCU

București
iulie 2018

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

Cuprins

CAPITOLUL 1. INTRODUCERE ………………………….. ………………………….. …………………….. 4
1.1 Justificarea temei ………………………….. ………………………….. ………………………….. ……… 4
1.2 Justificarea medicala ………………………….. ………………………….. ………………………….. …. 5
1.2.1 Evoluția sistemelor informatice naționale ………………………….. ………………………. 5
1.2.2 Stadiul actual in Romania ………………………….. ………………………….. ……………….. 6
1.2.3 Informații statistice ale sistemului medical din Romania ………………………….. …. 7
1.2.4 Ce își propune acest proiect ………………………….. ………………………….. …………….. 7
CAPITOLUL 2. Studiu comparativ ………………………….. ………………………….. ……………………. 8
2.1 Soluții brevetate ………………………….. ………………………….. ………………………….. ……….. 8
2.1.1 SYSTEM AND USER IN TERFACE FOR USE IN PROVIDING MEDICAL
INFORMATION AND HEALTH CARE DELIVERY SUPPORT (US 6,551,243 B2) [5]
8
2.1.2 INTEGRATED MEDICAL SOFTWARE SYSTEM [6] ………………………….. …. 9
2.1.3 INTEGRATED MEDICAL SOFTWARE SYSTEM WITHENHANCED
PORTABILITY [7] ………………………….. ………………………….. ………………………….. ……….. 10
2.2 Soluții comercializate ………………………….. ………………………….. ………………………….. 11
2.2.1 Power Hospital ………………………….. ………………………….. ………………………….. … 11
2.2.2 Infoworld – Hospital Manager [9] ………………………….. ………………………….. …… 11
CAPITOLUL 3. Descrierea soluției ………………………….. ………………………….. …………………. 12
3.1 Limbaje de programare ………………………….. ………………………….. ………………………… 12
3.1.1 Java ………………………….. ………………………….. ………………………….. ………………… 12
3.1.2 Javascript și TypeScript ………………………….. ………………………….. ………………… 13
3.1.3 Baza de date ………………………….. ………………………….. ………………………….. ……. 14
3.2 Arhitectura sistemului ………………………….. ………………………….. ………………………….. 15
3.2.1 Sistem național ………………………….. ………………………….. ………………………….. … 15
3.2.2 Arhitectura aplicației pe trei niveluri ………………………….. ………………………….. . 16
3.2.3 Model View Controller (MVC) Design Pattern ………………………….. …………….. 17
3.3 Comunicarea între nivele ………………………….. ………………………….. ……………………… 18
3.3.1 Comunicare asincron ………………………….. ………………………….. …………………….. 19
3.3.2 Microservicii ………………………….. ………………………….. ………………………….. …… 20
3.4 Instalarea frameworkurilor folosite ………………………….. ………………………….. ……….. 21
3.4.1 Instalarea Spring Boot ………………………….. ………………………….. …………………… 21
3.4.2 Instalarea bazei de date ………………………….. ………………………….. …………………. 21

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

3.4.3 Instalarea Ang ular 5 ………………………….. ………………………….. ……………………… 22
3.5 Descrierea componentelor ………………………….. ………………………….. ……………………. 22
3.5.1 Pacient ………………………….. ………………………….. ………………………….. ……………. 22
3.5.2 Fisa Medicala ………………………….. ………………………….. ………………………….. ….. 23
3.5.3 Utilizator ………………………….. ………………………….. ………………………….. …………. 23
3.5.4 Etaj, Salon și Pat ………………………….. ………………………….. ………………………….. . 24
3.5.5 Serviciile ………………………….. ………………………….. ………………………….. …………. 24
3.5.6 Controllerele ………………………….. ………………………….. ………………………….. ……. 24
3.6 Interfața Angular ………………………….. ………………………….. ………………………….. …….. 24
3.6.1 Model ………………………….. ………………………….. ………………………….. …………….. 24
3.6.2 Componente ………………………….. ………………………….. ………………………….. ……. 25
3.6.3 Services ………………………….. ………………………….. ………………………….. ………….. 25
3.6.4 Rutele ………………………….. ………………………….. ………………………….. …………….. 25
3.7 Programarea aplicațiilor ………………………….. ………………………….. ………………………. 26
3.7.1 Structura proiec tului ………………………….. ………………………….. ……………………… 26
3.7.2 Autentificare ………………………….. ………………………….. ………………………….. ……. 26
3.7.3 Fisa medicala ………………………….. ………………………….. ………………………….. …… 27
3.7.4 Căutare pacient ………………………….. ………………………….. ………………………….. … 27
3.7.5 Afișare Etaje, Saloane, Paturi ………………………….. ………………………….. …………. 27
3.8 Dinamica aplicației ………………………….. ………………………….. ………………………….. …. 28
3.8.1 Ecranul de întâmpinare ………………………….. ………………………….. ………………….. 28
3.8.2 Căutare ………………………….. ………………………….. ………………………….. …………… 28
3.8.3 Fisa Medicala ………………………….. ………………………….. ………………………….. ….. 28
3.8.4 Meniul Etaje ………………………….. ………………………….. ………………………….. ……. 30
3.8.5 Externarea ………………………….. ………………………….. ………………………….. ……….. 30
3.9 Securitatea ………………………….. ………………………….. ………………………….. …………….. 30
3.9.1 SSL ………………………….. ………………………….. ………………………….. ………………… 30
3.9.2 Rețea LAN ………………………….. ………………………….. ………………………….. ………. 30
3.9.3 Cheie publica – cheie privata ………………………….. ………………………….. …………. 30
3.9.4 Criptarea bazei de date ………………………….. ………………………….. ………………….. 30
CAPITOLUL 4. Concluzii ………………………….. ………………………….. ………………………….. …. 31
CAPITOLUL 5. Bibliografie ………………………….. ………………………….. ………………………….. . 32
CAPITOLUL 6. Anexa ………………………….. ………………………….. ………………………….. ………. 34
6.1.1 Structura bazei de date ………………………….. ………………………….. ………………….. 34
6.1.2 Structura fișierelor ………………………….. ………………………….. ………………………… 35
6.1.3 Interfața grafica ………………………….. ………………………….. ………………………….. .. 36

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

4

CAPITOLUL 1. INTRODUCERE

1.1 Justificarea temei

In secolul XXI sectorul IT & C face parte dintre domeniile cu cea mai r apida creștere,
pentru a tine pasul cu evoluția hardware ritmul de inovare este accelerat, in fiecare an apar noi
Framework -uri, noi versiuni ale limbajelor de programare existente. Un alt factor major al
dezvoltării îl reprezintă apariția dispozitivelor p ortabile (tablete, telefoane și laptopuri) .

Internetul este un domeniu într -o continua și rapida dezvoltare, după cum putem observa
din figura 2, gradul de accesare al internetului este într -o creștere exponențială, acest lucru fiind
ajutat și de impactu l pe care dispozitivele mobile îl au asupra pieței, in 2016 traficul de internet
de pe dispozitive mobile a depășit traficul de pe desktopuri. [1] [2]
Acest proiect își propune realizarea unui sistem inteligent de gestionare a datelor
medicale ușor portabil pe diverse sisteme, din acest motiv am decis sa folosesc ca un sistem de
tipul Microservicii care este capabil sa comunice prin protocol HTTP cu o gama larga de
dispozitive. Fiind foarte ușor de in tegrat într-un sistem mobil (tablete sau telefoane mobile),
personalul medical poate accesa sistemul direct de pe un dispozitiv mobil având acces imediat
la informațiile dorite .
Fig. 1.2.1 .2 Evoluția traficul desktop si mobil [2] Fig. 1.2.1 .1 Evoluția traficului de internet mobil
[1]

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

5

1.2 Justificarea medicala
1.2.1 Evoluția sistemelor informatice naționale

Inițial Siste mele informatice pentru spitale au fost introduse in anii 60 pentru a servi
parții financiare, acest lucru se datora in principal costurilor foarte mari dar și lipsa
infrastructurii informatice. [3]
In anii 80 odată cu evoluț ia tehnologiei , apariția rețelelor locale (LAN) și calculatoarelor
personale au început sa apară rețele locale in interiorul spitalelor . Apariția rețelelor cu arie larga
(WAN) a facilitat procesul de comunicare între site-urile spitalelor, punând astfel ba zele
sistemelor de distribuție a datelor medicale . Totuși nu a fost suficient a doar existenta acestui
sistem , apărând problema compatibilității datelor medicale între diversele entități medicale.
Pentru a rezolva aceasta problema a apărut ca o ne cesitate standardul internațional Health Level
Seven (Hl7). Acesta propune folosirea unui sistem standardizat de trimitere a datelor medicale
cu caracter personal, ducând astfel la o mai buna comunicare între entitățile medicale.
Adoptarea acestui standard a dus la începerea construirii unor sistemele informatice medicale
la nivel național.
Guvernul Noii Zeelande a introdus pentru prima data un sistem național de indexare al
datelor medicale ale pacienților , presupunând ca fiecare cetățean va avea un număr unic de
identificare pe care vor fi stocate toate datele medicale . Acest sistem de indexare previne
duplicarea datelor medicale , îmbunătățește securitate și oferă o platforma de acces la nivel
național pentru analiza datelor. Pentru ca acest sistem sa funcționeze , entitățile medicale
funcționează ca protectori ai datelor .
In mod tradițional datele medicale ale pacienților sunt deținute de entitatea care a
asigurat serviciul medical . Pentru a trimite aceste date medicale sunt folosit standarde precum
HL7 sau Fast He althcare Interoperability Resources (FHIR), insa chiar și cu aceste standarde
apar unele probleme in ceea ce privește validarea datelor și maparea lor într-un mod eficient.
Soluția propusa a fost realizarea unui sistem centralizat național cu care sa comu nice
toate entitățile medicale. Astfel oric ine asigur ă un serviciu medical comunic ă informația la nivel
național , iar aceast ă informație este disponibil ă imediat . Totuși se ridica noi probleme și
dificultăți în ceea ce privește scalabilitatea și asigurarea unui sistem rapid și eficient.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

6

Un sistem centralizat trebuie să ofere următoarele servicii
• Asigurarea unui tratament colaborativ
• Asigurarea finanțării pentru nevoile pacienților
• Managem entul stării de sănătate al populației
• Analize de tipul BigData
• Medicina de precizie

1.2.2 Stadiul actual in Romania
In momentul de fata fiecare spital are libertatea de a alege ce sistem informatic folosește,
nefiind însă implementat un sistem centralizat al datelor pacienților, acest lucru duce la mai
multe probleme. In pri mul rând medicii, in formularea unui diagnostic, se bazează exclusiv pe
anamneza, pe documentele din arhiva spitalului sau cele aduse de pacient. Având un sistem
centralizat la dispoziție aceste informații pot fi accesate de pe un server central, știind cu
certitudine istoricul medical are pacientul.
In al doilea rând necesitatea trecerii datelor pe hârtii sau in buletine speciale îngreunează
actul medical iar accesul la informații se face cu mare dificultate, trebuind ținuta o evidenta
precisa a locurilor unde depozitate, fapt ce creste costurile logistice.
O dificultate des întâlnita in rândul cadrelor medicale este volumul mare de informații
care trebuie completate de mana și de multe ori redundant, de exemplu observațiile
investigațiilor medicale trebu ie trecute și in fisa medicala. La fiecare fisa de prezenta, internare
și externare trebuie completate sau transcrise anumite informații, care cu ajutorul unui sistem
informatic pot fi copiate imediat într -o baza de date. Spre exemplu pentru fiecare fisa m edicala
este necesara completarea unui rubrici cu informații despre pacient, nume, prenume, data
nașterii, email, telefon… etc. Date care pot fi completate automat de sistem evitând astfel
redundanta.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

7

1.2.3 Informații statistice ale sistemului medical din R omania

Conform Institului National de statistica, in anul 2016 in Romania au funcționat 59957
de unități sanitare, dintre care 567 spitale și 146 de policlinici. Activând un număr de 57304
medici, 122792 asistenți medicali și 17180 farmaciști. [4]
In 2016 au fost 3949800 de persoane care au fost internate in spitale sau au beneficiat
de servicii medicale. Analizând aceste date putem sa observam necesitatea tinerii unei evidente
a pacienților ajutând astfel îmbunătățirea condi țiilor medical și facilitând actul medical. [4]

1.2.4 Ce își propune acest proiect
Acest sistem își propune realizarea unui sistem informatic care sa ofere un acces rapid
la informațiile personale și la istoricul medical paciențilo r. Un aspect important al acestui sistem
este portabilitate, facilitând astfel accesul la informații atât de pe sisteme desktop dar și de pe
sistemele mobile (tablete sau telefoane inteligente). Accesul la informații trebuie sa fie sigur și
rapid, personal ul medical trebuie sa aibă acces la informații pacientului in cel mai scurt timp
posibil. Sistemul trebuie sa fie unul intui tiv și ușor de folosit pentru tot personalul din aparatul
medical
O alta problema pe care acest sistem își propune sa o rezolve est e tinerea unei evidente
a gradului de ocupare a paturilor din spital, ușurând accesul al informații logistice despre gradul
de ocupare al saloanelor, ce paturi ocupa pacienții… etc.
Aceste aspecte propun o abordare dinamica a actului medical, timpi red uși de așteptare
pentru consult și tinerea unei evidente naționale a pacienților.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

8

CAPITOLUL 2. Studiu comparativ

2.1 Soluții brevetate
2.1.1 SYSTEM AND USER INTERFACE FOR USE IN PROVIDING MEDICAL
INFORMATION AND HEALTH CARE DELIVERY SUPPORT (US 6,551,243 B2)
[5]

Este un sistem informatic destinat cadrelor medical, menit sa fie accesat din mai multe
sursa. Acest sistem include un sistem de comunicare cu dispozit ivele medical dar și un sistem
de comunicare cu baza de date a spitalului pentru fisele pacienților. Acest sistem poate avea și
o component care analizează datele stocate pentru ca identifica metode alternative de tratament.
Printr -o interfața grafica personalul medical
accesează sistemul software care livrează datele
cerute. Acest sistem este capabil sa proceseze și sa
introducă într -o baza de date prescripții medicale,
diagnostice și analize.

Fig. 2.1.1 .1

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

9

2.1.2 INTEGRATED MEDICAL SOFTWARE SYSTEM [6]
Este un sistem medical pentru gestionarea pacienților care integrează mai multe aspecte
ale sistemului medical, printre modulele disponibile de afla: sistem pentru programări,
înregistrarea pacienților, informații privind statusul de asigurat dar și datele pentru facturare.
Acest sistem are construit un modul care ii permite administratorului sa configureze
șabloanele aplicației , acestea fiind folosite pentru generarea documentelor. Aceste șabloane și
documente sunt gândite sa se asemene cat mai mult cu c ele tipărite pe foi, fiind mult mai ușor
de completat de către cadrele medicale. In unele situații informațiile sunt pre populate evitând
astfel redundanta completării .
Sistemul își propune reducerea constărilor pentru clinica datorita creșterii acurateței
generării fac și monitorizarea cheltuielilor, reducerea costurilor cu stocarea informațiilor
medicale. Totodată îmbunătățește calitatea serviciului medical oferind alerte atunci când exista
conflicte între medicație și istoricul pacientului.

Fig. 2.1.2 .1

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

10

2.1.3 INTEGRATED MEDICAL SOFTWARE SYSTEM WITHENHANCED
PORTABILITY [7]
Este un pachet software care integrează mai multe aspecte ale practicii medicale,
incluzând programări , informații despre asigurarea medicala, date despre pacient și informații
despre tratamente. Sistemul isi propune sa folosească resursele manuale pentru a gestiona mai
bine fluxul de date permițând portabilitatea sistemului, fiind configurabil sa îndeplinească
cerințele oricărui sistem indiferenta de mărimea acestuia
Sistemul integrat este instalat pe un dispozitiv portabil, acesta putând fi configurat sa
ruleze fara a fi nevoie de instalarea softwareului. O alta componenta configurabila este
comunicarea cu un server central atunci când sunt livrate datele de logare in sistem

Fig. 2.1.3 .1

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

11

2.2 Soluții comercializate
2.2.1 Power Hospital

Power Hospital este un sistem informatic integrat, structurat modular, ce asig ura un
management eficient al tuturor departamentelor unui spital. Power Hospital se adresează atât
spitalelor de stat cat și celor private, permițând evidenta completa a pacienților , personalului,
resurselor, gestiunilor și tuturor celorlalte compartiment e administrative ale spitalului, cu
accentul pe calculul corect al costurilor spitalizării și pe stocarea tuturor informațiilor
medicale in dosarul electronic al pacientului. [8]
Astfel serviciul oferit de Softtech este un pach et complet pe capabil sa ofere servicii pentru:
• Internări – Externări
• Administrare IT
• Statistica
• Secții
• Prescriere rețete electronice
• Laborator

2.2.2 Infoworld – Hospital Manager [9]

Compania Info World furnizează soluții informat ice integrate pentru sectorul de
sănătate compatibile cu cerințele tuturor prestatorilor de servicii medicale. Încă de la înființarea
sa în anul 2000, Info World este cel mai important producător de software medical din
România, fiind recunoscut ca o forț ă inovativă pe piața națională și internațională.
Hospital Manager este un pachet software care oferă :
– Integrare printr -o interfața desktop și servicii web;
– permite înregistrarea pacientului în spital pe parcursul tuturor etapelor: ambulator , serviciu
internări, camera de gardă, UPU/CPU, secție cu paturi, secție de internare de zi;
– permite urmărirea costurilor pe pacient / medic / departament atât în ambulator cât și pe
durata spitalizării;
– permite generarea de rapoarte specifice fiecărui compartiment / dep artament, precum și
raportările către CNAS / CJAS, DSP, SNSMPPDSB, autoritățile locale.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

12

CAPITOLUL 3. Descrierea soluției

Pentru a crea un sistem informatic de gestiune a informațiilor medicale trebuie sa ținem
cont de mobilitatea pe care o putem oferii utilizatori lor, de aceea sistemul va avea doua
componente, una mobila și una desktop. Varianta desktop va fi folosita in cazurile când medicul
este la birou, întocmește rapoarte, adaugă analize și mobilitatea nu este o necesitate, varianta
mobile va fi folosita atunc i când se consulta pacientul, când se fac turele, in cazul secțiilor UPU
când informația trebuie accesata într -un timp scurt.
Acesta aplicația va dispune de următoarele componente:
– extragerea informațiilor medicale ale pacientului
– întocmirea de fise medi cale (prezenta, internare, externare)
– adăugarea de tratamente și diagnostice pentru pacient
– tinerea evidentei semnelor vitale (curba febrila) pentru pacienții internați
– tinerea evidentei analizelor
– tinerea evidentei gradului de ocupare al spitalului
3.1 Limbaj e de programare
Aceasta aplicație este una de tip Cloud Service care va rula pe un server de tip Apache.
Principalul limbaj de programare folosit este Java cu frameworkul Spring MVC, asta este folosit
pentru a realiza logica aplicației.
Pentru interfața g rafica aceasta aplicație utilizează doua tipuri de terminale, pentru
stațiile de lucru de tip desktop se va realiza in Angular și Electron , iar pentru stațiile de lucru
mobile se va folosi o aplicație Cordova .
3.1.1 Java
Java este un limbaj de programare o rientat pe obiecte lansat in anul 1996 de către firma
Sun Microsistems. Ideea centrala a limbajului a fost „Scrie o data, rulează peste tot”, însemnând
ca programele Java pot fi portate pe orice sistem de operare. Acest lucru i -a adus limbajului o
populari tate nemaiîn tâlnita , devenind in scurt timp limbajul numărul unu la nivel global.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

13

Limbajul Java are propria structura, sintaxa și paradigma de programare. Este un limbaj
derivat din C, utilizând aceeași structura de blocuri. Fiecare program de Java este inclus in
pachete, aceste pachete sunt mecanismul de namespaceing al limbajului. [10]
Java este un limbaj care necesita compilare , codul este verificat și transformat in
bytecode . Aceste seturi de instrucțiuni sunt rulate de J VM, Java Virtual Ma chine, JVM in sine
este un ecosistem folosit de mai mult e limbaje de programare, cu o popularitate mare, din acest
motiv exista o baza de date considerabila de librarii care pot fi folosit in realizarea proiectelor.
Principalul avantaj a l JVM este ca poate fi folosit pe toate platformele sistemelor de operare,
ducând la o acoperire foarte buna a pieței .
Spring Framework este o platforma care folosește limbajul de programare Java. Spring
oferă o infrastructura bogata in module și caracteristici pentru a elimina etapa de dezvoltare a
infrastructurii și a oferi utilizatorilor oportunitatea de a se co ncentra doar pe partea de aplicație .
Spring Framework pe rmite folosirea “plain old Java objects” (POJO) pentru d ezvoltarea
serviciilor industriale, aceste capabilități se aplica pentru Java SE și Java EE. Spring oferă o
gama larga de servicii, Spring Boot, Spring Security, Spring Cloud, Spring Data. [11]
Spre deosebire de alte limbaje de programare folosite tradițional in mediul Web, Java
are avantajul folosirii programării cu ajutorul firelor de execuție . Împreună cu folosirea unor
servicii web REST asycnron se pot realiza aplicații dinamice și ușor scalabile.

3.1.2 Javascr ipt și TypeScript
JavaScript este un limbaj introdus in anul 1995 ca o soluție pentru crearea paginilor
web. In timp limbajul a fost adoptate de toate browserele fiind folosit in principal pentru a
realiza elemente dinamice in interiorul paginilor HTML. JavaScript este un limbaj extrem de
flexibil , ușor de folosit și compilat in momentul rulării de către browser [12]
Noile versiuni de JavaScript, ES5 și ES5 aduc îmbunători substanțiale lucru ce a dus la
o extindere a limbajului in afara paginilor web. In 2009 a apărut NodeJS, un framework
JavaScript conceput sa ruleze pe server , iar dezvoltările recente au permis folosirea jav ascript
pentru aplicații native desktop.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

14

Ca o ex tindere a JavaScript a apărut TypeScript, un superset al JavaScript care introduce
necesitatea specificării tipurilor de variabile, eliminând astfel erorile de gestionare incorecta a
funcțiilor din interiorul progra melor.
Angular este un framework de javascript folosit pentru realizarea interfețelor grafice.
Are la baza platforma Angular dezvoltata de compania Google. Angular are la baza TypeScript
care oferă o structura clara și ușor de înțeles . Pentru realizarea unei interfețe grafice se pot
folosit alte frameworkuri de javascript care au rolul de a face o punte între limbajele web și
sistemele de operare. Electron este un astfel de framework , foarte ușor de folosit care are la
baza Chromium , care primite utilizarea unui mediu similar browserului Chrome.
Un avantaj al folosirii Elec tron pentru aplicații desktop este ca puteam sa accesam
apelurile de sistem, astfe l aplicația poate avea un aspect nativ.
3.1.3 Baza de date

„MySQL este cea mai populară bază de date open source din lume. Prin performanța
dovedită, fiabilitate și ușurință de utilizare, MySQL a devenit cea mai importantă bază de date
pentru aplicațiile bazat e pe web, utilizată de companii de renume, cum ar fi Facebook,
Twitter, YouTube și toate cel cinci site -uri web de top. De asemenea, este o alegere foarte
populară ca bază de date integrată, distribuită de mii de furnizori și producători de software.”
[13]
Avânda in vedere tipul aplicației , cea mai buna varianta de realizare a fost folosirea
uneai baze da date distribuite și pentru aceasta lucrare s-a ales folosirea bazei de date MySQL
produsa de către Oracle . Caracterul open -source, performantele oferite dar și ușurința folosirii
au fost criteriile decizional e.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

15

3.2 Arhitectura sistemului
3.2.1 Sistem național
Acest sistem este realizat pentru a comunica datele standardizat in cadrul unui sistem
de gestionare a datelor medical e la nivel național .

In Fig. 3.2.1 .2 este descrisa schema de principiu a s istemului național pentru
gestionarea datelor medicale . Fiecare entitate medicala va avea la dispoziție un server local ,
toate di spozitivele aplicațiile vor fi configurate sa comunice doar cu serverul de care aparțin.
Cat timp datele sunt in lucru ele sunt stocate pe serverul local, ulterior când acestea sunt
externate, vor fi trimise către serverul central.
In continuare aceasta lu crare se axeaza pe realizarea unei aplicatii destinat spitalelor și
determinarea componentelor necesare pentru functionare eficienta a acestora.

Fig. 3.2.1 .1

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

16

3.2.2 Arhitectura aplicației pe trei niveluri

Arhitectura pe trei niveluri reprezintă structura (framework) fun damentala pentru
modulul de design logic. Aceasta arhitectura
împarte componentele unei aplicații in trei
niveluri de servicii, nivelul de date, nivelul de
logica al aplicației și nivelul prezentare. [14]
Aceste niveluri nu re prezintă o
diferențiere la nivel fizic ci o diferențiere a
modului cum lucrează componentele aplicației.
Nivelul prezentare

Reprezintă nivelul cel mai apropiat de
utilizator, acesta este reprezentat printr -o
interfața grafica (GUI) sau o pagina web. I nformațiile sunt preluate de la nivelul de logica a
aplicației și sunt afișate dinamic in cazul unui paginii web in format HTML/CSS. Tot prin
intermediul nivelului de prezentare utilizatorul poate sa solicite sau sa trimite comenzi
aplicației.
Nivelul Log ica Aplicației

Este cel mai complex nivel, furnizează principalele servicii ale aplicației, livrarea
datelor pentru nivelul prezentare dar și manipularea datelor venite de la nivelul prezentare.
Acest nivel este format din mai multe componente care pot f i reutilizate pentru mai multe
aplicații.
Nivelul de Date

Acest nivel este reprezentat accesul către sistemele de gestiune a bazelor de date (SQL,
noSQL), este accesat de către nivelul de logica al aplicației și folosit pentru interogarea bazelor
de da te. Acest nivel este accesat specific in funcție de cerințele clientului.

Fig. 3.2.2 .1 Arhitectura aplicației pe trei
niveluri

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

17

3.2.3 Model View Controller (MVC) Design Pattern

Design Pattern este un termen folosit in ingineria software ce face referire la o soluție
arhitecturala reutilizabilă pentru rezolvarea anumitor
probleme.
Arhitectura MVC a fost inițial introdusa de limbajul
de programare Smalltalk in anii 70, dorind sa introducă o
separare a componentelor esențiale de interfețele grafice. In
timp aceasta arhitectura a devenit o practica comuna in
limbaj ele de programare orientate pe obiecte (Java, PHP,
C#… etc.). [15]
Acest design pattern implementează direct
arhitectura de pe trei niveluri, separând aplicația in
componente precum: Controller,Model,View.

Model
Este com ponenta ce coincide nivelului de date, este o clasa care gestionează
comunicarea cu baza de date pentru o componenta specifica, de exemplu obținerea datelor
despre Pacienți .
View
Face parte din componentele nivelului de prezentare, sunt pagini Web care afișează
datele obținute de la nivelul de logica a aplicației. In interiorul paginilor de tip View se găsesc
formulare prin care se trimit date către server.
Controller

Este componenta a nivelului de logica a aplicației, aceste componente preiau request ul,
il analizează și asigura manipularea datelor, interacțiunea cu Modelele, prelucrează datele
venite de la client și trimit datele către componente View .

Fig. 3.2.3 .1 MVC Design Pattern [16]

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

18

Avantajele MVC
1. Arhitectura MVC ușurează gestionarea complexității aplicației, atribuind roluri
preci se componentelor
2. Este ideal programatorilor care doresc un control deplin asupra comportamentului
aplicației
3. Ușurința gestionarii request -urilor venite de la client printr -un singur controller, un
controller poate asigura funcționarea mai multor pagini de View
4. Asigura un suport bun pentru test-driven development (TDD).
5. Este ușor de folosit in cadrul proiectelor complexe. [16]

3.3 Comunicarea între nivele
Comunicarea între Nivelul Prezentare și Nivelul Logica Aplicație se face pri n folosirea
protocolului REST – JSON
Apărut la începutul anilor 2000 ca urmare a crizei de scalabilitate din sistemele Web,
protocolul REST ( Representational State Transfer) definit de către Roy Fielding , este adoptat
ca standard al industriei de servic ii Web. Acesta foloseste standardele HTTP 1.1 și Uniform
Resource Identifiers (URI) pentru a oferi o baza de comunicare între diverse aplicații . [17]
In cadrul acestui proiect s -au folosit verbele HTTP: GET, POST, PUT, DELETE, pentru
realizarea operațiilor CRUD (Create Read Update Delete), datele trimise fiind in formatul
JSON ( JavaScript Object Notation ).
– GET – folosit pentru cererea datelor
– POST – folosit pentru insert in baza de date
– PUT – folosit pentru update in baza de d ate
– DELETE – folosit pentru a șterge elemente din baza de date
Un e xemplu de JSON returnat de un API REST GET la accesarea URI:
http://localhost:8080/user/profile pentru a obține informații despre utilizatorul logat cu sesiunea
actuala este :
{"id": 1,"date": 1483221600000 ,"observations ": "none" ,"code ": "TS2017" ,"status ": 1,"user": {"id": 1,"username "
: "stefan" ,"firstName ": "Stefan
Daniel" ,"lastName ": "Nedelcu" ,"email ": "stefff.94@gmail.com" ,"phone ": "723524257" ,"job": null,"enabled ": tr
ue,"authorities ": [{"authority ": "ROLE_MEDIC" }],"accountNonExpired ": true,"credentialsNonExpired ": true,"
accountNonLocked ": true}},

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

19

3.3.1 Comunicare asincron

Cu ultimele versiuni alea Java Script s-a introdus posibilitatea de a realiza operații
asincron. Acesta paradigma vine in rezol varea probleme i când un request durează foarte mult
pana este finalizat .
Atunci când apelezi o funcție care necesita un timp lung de rulare, spre exemplu
extragerea datelor dintr -o baza de date, pagina se blochează cat timp se așteaptă răspunsul de
la funcția apelata. Acest mod de programare este des întâlnit in mediul web si putem vedea ca
paginile se încarcă atunci când au toate datele disponibile
In modelul a sincron aceast a problema este rezolvata si permită paginii sa ruleze in
continuare cat timp este așteptat răspunsul de la funcție . Când răspunsul este primit ,
progr amul este informat si informația este accesata in pagina.

Fig. 3.3.1 .1 Comparație program sincron vs asincron [12]

In Fig. 3.3.1 .2 observam ca pro cesul asincro n este mult mai rapid decât procesul
sincron folosind un singur fir de execuție . Acest principiu duce la fluidizarea aplicațiilor si
aduce timp de așteptare mult mai reduși . In general este evitata programarea firelor de
execuție deoarece este un proces dificil si greu de co ntrolat.
Programarea asincro na poate fi comparat cu procesul de comand ă la restau rant,
chelnerul ia comanda , iar clientul in baza promisiunii c a își va prim i mâncarea la un moment
dat își continua activitățile de socializare. Atunci când mâncarea este pregătită , chelnerul de
întoarce la masa și îi servește clientului ma sa.
Pentru a lucra asincron in JavaScript ne folosim de componentele numite Promise.
Acestea sunt funcții speciale care realizează requesturi de timp asincron și când am mesajul
final, notifica programul si ii trimite datele.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

20

Pentru crearea promisiunilor de foloseste codul din exe mplul urmator : [12]
function storage(nest, name) {
return new Promise(resolve => {
nest.readStorage(name, result => resolve(result));
});
}
storage(bigOak, "enemies") .then(value => console.log("Got", value));

Angular trimite toate requesturile către server folosind metoda asincron si le afișează in
pagina atunci când sunt ga ta, in acest tim p interfața grafica este activa , iar utilizatorul nu resimte
sacadări in ac est proces.
3.3.2 Microservicii

Microserviciile vin ca o soluție dezvoltarea
aplicațiilor industriale multiplatforma. In programarea
clasica monolitica a tunci când dezvolți o aplicație
trebuie sa ti cont pe ce platforma va rula. Principala
problema a modelului monolitic este dificultatea mare de
scalare , pentru a rezolva problema volumul ui mare de
cereri .
Soluția propusa de arhitectura micro serviciilor
este crearea unor seturi de servicii cat mai independente .
Spre exemplu intr -un sistem național ne dorim sa
realizam servici care vor fi conectate la baze de date
specifice , toate fisele medicale vor fi ținute intr-o baza
de date, datele personale ale pacienților in alta baza de
date, pentru informații despre tratamente , investigații si
diagnostice se va folosi alta baza de date . [18]
Utilizând mai multe baze de dat e oferă posibilitatea de aplicației sa tina ma i multe
cone xiuni simultan , reducând astfel rata de cădere a sistemului.

Fig. 3.3.2 .1 Arhitectura microservicii

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

21

3.4 Instalarea frameworkurilor folosite
3.4.1 Instalarea Spring Boot

In primul rând sistemul trebuie sa aibe instalat Java Develop ment Kit (JDK) 8+ și un
server Apache Tomcat. Folosind mediul de dezvoltare integrat (IDE) Intelij, facem un proiect
nou din meniul File -> New -> Project. Din lista din stânga alegem un proiect de tipul Spring
Initializr, apăsam butonul Next, alegem numele proiectului și versiunea dorita și apăsam Next.
In următorul pas alegem dependințele care vor fi instalate cu ajutorul Maven. Alegem un proiect
de tipul Web.

Fig. 3.4.1 .1

3.4.2 Instalarea bazei de date
In cadrul acestui proiect folosim o baza de date MySQL, descărcam de pe internat kit –
ul de instalare pe care îl instalam local, împreună cu software -ul MySQL Workbench.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

22

3.4.3 Instalarea Angular 5

Pentru instalarea Framework -ului de Angular este
necesara instalarea pe mașină a mediului de dezvoltare
Node.js și npm.
Pasul 1. Odată instalat npm, se deschide
consola și se instalează global sistemul CLI (command
line interface) al Framework -ului
npm install -g @angular /cli
Pasul 2 este crearea proiectului, acesta pas se
realizeaz ă folosind CLI -ul cu comanda:
ng new hospitalapp -client
Pasul 3 Se rulează aplicația pentru a verifica
daca instalarea a decurs normal
cd hospitalapp -client
ng serve –open
Aplicația va rula pe localhost, postul 4200 (http://localhost:4200/). Daca aplicaț ia este
instalata corect, se va deschide o pagina ca in Fig. 3.4.3 .2.

3.5 Descrierea componentelor
Pentru început trebuie sa divizam aplicația in componente numite entități, aceste entități
vor avea un rol speci fic. Deoarece Java este un limbaj obiect orientat, trebuie ca fie componenta
sa fie o clasa cu proprietăți și metode.
3.5.1 Pacient
In centrul aplicației se afla clasa Pacient, proprietatile acesteia sunt: id, cnp, firstName,
lastName, email, phone, job, birthd ate, sex, statusAsigurat, bloodType, chronicDiseaseList,
allergicDiseaseList, vaccineList și medicalFormList.
Informațiile despre telefon, email, job sunt utile pentru pre completarea fiselor
medicale, eliminând acest aspect pacienții și medicii câștigă tim p important.
Fig. 3.4.3 .1 Ecran intampinare Angular

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

23

Aplicația folosește liste și entități separate pentru alergii, diagnostice cronice și
vaccinuri pentru a ușura accesul la informații , evitând astfel nevoia de a căuta aceste date in
fisele medicale ale pacientului.
3.5.2 Fisa Medicala

Toate interac țiunile Pacientului cu sistemul medica sunt intermediate de fise medicale,
Medicii sunt cei care au dreptul de deschidă fise de consult.
O fisa de consult conține un id local dar și un id (code) folosit la nivel național, acesta
este un hash format din mai multe date unice fisei mediale, astfel la nivel național nu vor exista
duplicări ale aceluiași cod de înregistrare.
Într-o fisa medicale sunt salvate observațiile la fiecare nivel (fisa de prezenta, fisa de
internare, fisa de externare) dar și momentele d e timp când a fost inițiat procesul, când a fost
întocmită fisa de prezenta, când s -a realizat internarea.
Fisa medicala tine date despre Utilizatorul (Medicul) care administrează fisa, pacientul
căruia ii aparține, o lista cu paturile in care a fost pacientul m utat, este o lista deoarece pacientul
poate fi mutat între diverse secții și este important sa menținem un istoric al pacienților care
ocupa fiecare pat, mai ales pentru determinarea gradului de ocupare al spitalului.
Într-o fisa medicala se vor retine lis te despre diagnosticele care au fost pune in acea fisa
medicala, lista de tratamente care i -au fost administrate, semnele vitale luate la anumite
momente de timp și liste cu investigațiile la care a fost supus.
3.5.3 Utilizator
Sunt utilizatorii aplicației, aceștia au diverse roluri (medic, asistent, laborator) avand
acces la diverse componente in baza acestui rol.
Accesul la aplicație este restricționat, doar persoanele care au cont pot accesa sistemul
pe baza unei parole. Parolele sunt criptate cu ajutorul metodei
BCryptPasswordEncoder::encode.
Într-un sistem național utilizatorii, personalul ui medical, vor fi adăugați inițial de către
Ministerul Sănătății sau Colegiul Medicilor, ulterior când ei sunt angajați la un spital,
administratorul sistemului acelui spital va extrag e datele utilizatorului din serverul național .
Astfel inclusi v datele utilizatorului sunt disponibile in întreg sistemul.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

24

3.5.4 Etaj, Salon și Pat
Aceste componente sunt folosite pentru a asigura o buna gestionare a gradului de
ocupare al spitalului și a avea o evidenta clara a paturilor ocupate.
Fiecare componenta are o proprietate de activ/inactiv, aceasta proprietate este utila
pentru a sti daca din anumite motive unele secții sunt închise sau daca paturile sunt ocupate.

3.5.5 Serviciile
O alta parte importanta de componente este reprezentată de servicii, clase folosite de
controllerele pentru a realiz a interacțiunea cu Nivelul de Date. Aceste servicii accesează
componentele DAO ( Data Access Object ) care comunica cu baza de date, interacțiunea este
intermediata folosind Hibernate ORM .
3.5.6 Controllerele

Sunt componentele care gestionează request -urile ve nite de la interfața grafica Angular.
Ele sunt împărțite in funcție de entitățile pe care le gestionează, spre exemplu
MedicalFormsController care preia toate request -urile și gestionează informațiile pentru fisele
medicale. Controllerele folosite in inter acțiunea cu interfața grafica folosesc adnotația
@RestController, urmat de adnotația @RequestMapping, care oferă calea unde trebuie trimis
requestul (ex: „/medical -forms”)
3.6 Interfața Angular
In ceea ce priveste interfata grafica, componentele ei sunt împărț ite in 3 categorii:
components, models și services.
3.6.1 Model
Sunt echivalentul entitățil or din aplicația Spring, împart aceleași proprietăți și tipuri de
date. Aceste tipuri de date sunt importante deoarece Angular fiind scris in TypeScript toate
interacțiune cu aceste variabile trebuie sa se potrivească ca tip de date.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

25

3.6.2 Component e
Sunt grupuri de pagini TypeScript , html și css (stilul) cores punzătoare unei p agini.
Paginile .ts exporta o clasa care gestionează comportamentu l paginii, fiecare metoda a acestei
clase poate fi accesata din View, iar proprietățile clasei se găsesc ca variabile in View.
Folosind comanda „import {} from ’’ ” se includ dependințele clasei.
3.6.3 Services

Sunt clase care se folosesc de protocolul HTTP pen tru a trimite request -uri către
serviciul REST.
Fiecare metode a unei clase accesează o anumita ruta care trimite mesajul, valorile sunt
convertite in șiruri JSON folosind metoda JSON.stringfy. Este important ca in headerul
mesajului sa specificam Content -Type ca application/json.
3.6.4 Rutele

Pentru a folosi mai multe componente in pagina ele trebuie accesate separat, acest
proces de acces se r ealizeaza definirea unor rute. Rutele pe care se bazează aplicația se
inițializează în fișierul app -routing.module.ts din folderul app. Rutele sunt un vector de tipul
Routes , in care specificam calea si componenta pe care vrem sa o apelam .
{ path: 'login', component: LoginComponent },
Pentru a fi folosite de aplicație trebuie sa le exportam folosim codul:
@NgMo dule({
exports: [RouterModule],
imports: [RouterModule.forRoot(appRoutes)]
})
export class AppRoutingModule { }

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

26

3.7 Programarea aplicațiilor
3.7.1 Structura proiectului

Intr-un proiect Spring Boot tot codul aplicației
se găsește in folderul
src/main/java /com .stefan.hospitalmanager . In acest
folder trebu ie sa a vem o compartimentare a
elementelor așa cum se poate observa in Fig. 3.7.1 .1
HospitalmanagerApplication este clasa
principala care declanșează aplicația . In aceasta clasa
declaram elementele Bean necesare si inițializam
serviciul de stocare.
Structura folderelor este fix si urmează ghidul
de folosire al Spring Boot .

Folderele din proiect si scopul lor sunt descrise in Tabel 3.7.1 .3:

Folder Scop
confg fișierele de configurare a aplicației
controller controllerele aplicației
dao data access object, clase care descriu relația obiectelor cu baza de date
entity entitățile , modelele obiectelor folosite in aplicație
helper fișierele care rolul de a aduce funcții suplimentare
service Interfețele si clasele care comunica cu baza de date
Tabel 3.7.1 .4
In cazul Angular, proiectul fișierele aplicației se găses c in src/app, unde am creat pentru
o mai buna organizare încă trei foldere components, models si services .

3.7.2 Autentificare
Când utilizatorul intra in aplicați e, in interfata Angular de inițializează componenta de
login , iar la trimiterea formularului prin app.service. ts sendCredential (credentials) se trimit e
către server unu request de tipul post in car e includem datele speci ficate de utilizator.
Acest request e ste trimis catre /in dex, de unde este preluat de componenta de
securitate (config /SecurityConfig) care verifica autenticitatea utilizatorului .
Configurarile s tandard sunt include in functia configure descrisa in continuar e. In
aceasta s pecificam rutele de login si log out dar s i ca permitem accesul in aplicație doar pe
baza autentificării .

Fig. 3.7.1 .2 Struct ura fișierelor spring

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

27

@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests().
antMatchers(PUBLIC_MATCHERS).
permitAll().anyRequest().authenticated();
http
.csrf().disable().cors().disable()

.formLogin().failureUrl("/in dex?error").defaultSuccessUrl("/user/profile").loginPage("/index").permitAll()
.and()
.logout().logoutRequestMatcher(new
AntPathRequestMatcher("/logout")).logoutSuccessUrl("/index?logout").deleteCookies("remember –
me").permit All()
.and()
.rememberMe();
}
Daca u tilizatorul este autentificat acesta este redirect către pagina de control
(/dashboard) folosind componenta dashboard . Când aceas ta se inițializează , aplicația apelează
doua servicii getUserMedicalForms si getUserMedicalFormsPacients prin care completam
tabelul cu fise medicale. Pentru a monitoriza se tipuri de fise scoatem folosim variabila status
prin care trimitem un cod către server, pe baza acestui cod , serviciul returnează fisele
medicale .
3.7.3 Fisa m edicala
3.7.4 Căut are pacient
3.7.5 Afișare Etaje, Saloane, Paturi

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

28

3.8 Dinamica aplicației
Pentru a accesa sistemul utilizatorii sunt întâmpinați de pagina de autentificare unde
trebuie sa introdu că username și parola.
3.8.1 Ecranul de întâmpinare
Fiecare medic este întâmpinat de o lista cu fisele medicale active
pe care le are in gestiune, din partea dreapta sus se poate selecta tipul de
fise medicala care va fi afișat (fise prezenta, internări, fisele externate,
cele ac tive sau toate fisele) . Din aceasta lista meciul poate vedea numele
pacientului, data cand a fost creata fisa si diagnosticul.
3.8.2 Căutare
Odată autentificati in sistem utilizatorii au la dispoziție in partea
stânga meniul unde se afla opțiunile pentru a accesa funcțiile aplicației,
pentru căutarea unui pacient se va folosi meniul Search , prin
introducerea CNP -ului p acientului sau a numelui se vor caută datele
medicale ale pacientul . Prima data se verifica daca pacientul este internat
in spital, daca nu es te internat, se trimite o cerere către serve rul național
pentru a obține informațiile actualizate.
Când datele cu fost primite se va încarcă o pagina pentru
vizualizarea acestora. In partea superioara a paginii se găsesc
informațiile personale ale pacientului dar și o lista cu informații vitale
(grupa de sânge, boli cronice, alergii și vaccinuri făcute).
Din pagina cu datele medicale ale pacientului, medicul are la
dispoziție opțiunea „Adaugă Fisa Medicala” prin care se va crea in
sistem o intrare pentru Consultări.

3.8.3 Fisa Medicala
In partea superioara se afla informațiile personale ale pacientului care in mod normal
trebuie completate de către pacient.
Fig. 3.8.2 .1Diagrama
de proces a aplica ției

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

29

In a doua parte apare câmpul „Diagnostic prezumtiv” care va fi completat de către medic
cu observațiile rezultate in urma consultului. In aceasta fisa m edicala pot fi adăugate
diagnostice apăsând butonul + din partea dreapta.
Cod Diagnostic reprezintă codul CIM asociat la nivel Mondial acelui diagnostic. Este
important pentru trimiterea către CNAS, numele diagnosticului și daca este cronic sau alergie,
aceste doua opțiuni sunt folosite pentru adăugare la listele pentru accesare rapidă in pagina
pacientului
Similar cu diagnosticele, pentru tratamente trebuie completat codul CIM, numele și
frecventa cu care este administrat, aceasta frecventa este utila as istentelor care administrează
tratamentele pacienților, odată setat tratamentul apar doua butoane, primul este folosit pentru a
tine evidenta administrării tratamentelor, va fi apăsat de către asistente atunci când
administrează un tratament, in acel pe se rver se creează un log pentru administrare tratament
cu timestamp -ul și persoana care l -a administrat.
In cazul Investigațiilor, Medicii solicita o investigație, completează numele și codul
CIM, împreună cu observațiile. Ulterior asistentele, duc pacientu l să facă investigația sau
recoltează probele biologice, in cazul probelor biologice trebuie completat și codul de bare al
flaconului, pentru a păstra o evidenta clara. După ce analizele au recoltate ele sunt trimise către
laborator unde vor fi procesate.
Adunarea informațiilor despre semnele vitale este un factor important in realizarea unui
diagnostic, in partea din dreapta sus de afla buton „Curba febrila” care deschide secțiunea
pentru analizarea și adăugarea semnelor vitale. Aceste informații sunt co mpletate de care
asistentele medicale in fiecare zi.
Daca pacientul trebuie internat se folosește opțiunea „Internează”. In acest moment de
adaugă in baza de date momentul când s -a cerut internarea, iar medicul trebuie sa repartizeze
pacientul într -un pa t (aceasta opțiune apare sub secțiunea de observații).
In secțiunea de sus găsim opțiunea „Curba febrila” un set important de parametrii
fiziologici care se monitorizează constant pe perioada internării. Pentru ușurarea analizei aceste
date sunt afișate in f orma de grafice, se poate observa ușor evoluția stării de sănătate a
pacientului.
Doua componente importante din meniu sunt „Recoltare Analize” și „Analize”
drepturile de acces ale acestora sunt împărțite de asistente respectiv lucrătorii de laborator. In

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

30

meniul de Analize laboratorul vede ce analize au ajuns și trebuie prelucrate, in momentul când
laboratorul deschide analize se marchează timpul „ Data începere prelucrare” , aceștia pot adăuga
observații, folosite de medici in determinarea diagnosticului, ac estea apar și pe fisa se externare
și pot adăuga documente (RMN, Fise de analize, radiografii… etc.). Aceste documente apar in
fisa medicala și pot fi accesate de către medici.

3.8.4 Meniul Etaje
Este folosit in momentul când medicii fac turele in spital, acest meniul este intuitiv și
medicului îi este ușor sa navigheze între etaje, saloane și paturi. In dreptul paturilor ocupate
este afișat numele pacientului și un buton către fisa medicala a acestuia. Pe baza acestei
componente se pot realiza rapoarte statistice despre gr adul de ocupare al spita lului.
3.8.5 Externarea
In momentul când medicul externează pacientul, in controllerul pentru fisele medicale
se apelează metoda pushDataToMainframe, care trimite toate datele despre pacient actualizate
către serverul central, cel administrat de CNAS. Fișierele se transmit prin protocol FTP către
un server special care stochează fișiere .
3.9 Securitatea
3.9.1 SSL
3.9.2 Rețea LAN
3.9.3 Cheie publica – cheie privata
3.9.4 Criptarea bazei de date

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

31

CAPITOLUL 4. Concluzii

Aceasta aplicație are un poten țial foarte mare de a ușura munca personalului medical,
eliminând necesitatea de a parcurge pași suplimentari. Aplicația este intuitivă și ușor de folosit,
având funcții de baza pentru funcționarea normala într -un spital. Medicii au acces foarte ușor
la informațiile medicale ale pacienților, astfel se mărește gradul de siguranță al diagnosticelor
și erorile medicale pot fi mai ușor evitate, având la dispoziție toate informațiile necesare pentru
stabilirea diagnosticului.
Beneficiile aplicației se resimt în actul medical, pacienții nu mai trebuie sa completeze
informații redundante, timpii de așteptare sunt mult mai mici și interacțiunea cu medicul este
una mult mai bună.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

32

CAPITOLUL 5. Bibliografie
[1] Statista. Global mobile data traffic from 2016 to 2021 (in exabytes per month). statista.com.
[Interactiv] 01 February 2017. https://www.statista.com/statistics/271405/global -mobile -data-traffic –
forecast/.
[2] Statcounter. Mobile and tablet internet usage exceeds desktop for first time worldwide.
[Interactiv] 1 November 2016. [Citat: 07 May 2018.] http://gs.statcounter.com/press/mobile -and-
tablet -internet -usage -exceeds -desktop -for-first-time-worldwide.
[3] orionhealth.com. The evolution of Hospital Information Systems. orionhealth.com. [Interactiv]
[Citat: 21 June 2018.] https://orionhealth.com/uk/knowledge -hub/blogs/the -evolution -of-hospital –
information -systems/.
[4] Statistica, Institutul National de. [Interactiv] [Citat: 2 7 Noiembrie 2017.]
http://statistici.insse.ro/shop/index.jsp?page=tempo2&lang=ro&context=30.
[5] Siegfried Bocionek, Nuernberg (DE), Margo Hanslik, Erlangen (DE) și Siegfried Russwurm,
Michelau (DE). SYSTEM AND USER INTERFACE FOR USE. US 6,551,243 B2 Unite d States, 22
April 2003.
[6] W. Thomas Green, Jr., Carrollton, GA (US), și alții. INTEGRATED MEDICAL SOFTWARE.
US 7,716,072 B1 United States, 11 May 2010.
[7] W. Thomas Green, Jr., Carrollton, GA (US), și alții. INTEGRATED MEDICAL SOFTWARE
SYSTEM WITHENHAN CED PORTABILITY. US 8,050,938 B1 United States, 1 November 2011.
[8] Softeh. SISTEM INFORMATIC PENTRU SPITAL. Softeh Plus. [Interactiv] [Citat: 07 May
2018.] http://www.softeh.ro/produse/sanatate/sistem -informatic -pentru -spital/.
[9] INFO WORLD S.R.L. Hosp ital Manager. [Interactiv] INFO WORLD. [Citat: 07 May 2018.]
http://www.infoworld.ro/ro/hospital -manager/.
[10] J Steven Perry. Introduction to Java programming – Java language basics. www.ibm.com.
[Interactiv] IBM, 19 July 2010. [Citat: 22 June 2018.]
https://www.ibm.com/developerworks/java/tutorials/j -introtojava1/index.html.
[11] Rod Johnson, Juergen Hoeller , Keith Donald. Spring Framework Reference Documentation.
2004 -2013.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

33

[12] Haverbeke, Marijn. Eloquent JavaScript 3rd edition.
[13] Oracle. Cea mai populară bază de date open source din lume. oracle.com. [Interactiv] [Citat: 24
June 2018.] https://www.oracle.com/ro/mysql/index.html.
[14] Microsoft. Using a Three -Tier Architecture Model. msdn.microsoft. [Interactiv] Microsoft.
[Citat: 01 May 2018.] htt ps://msdn.microsoft.com/EN –
US/LIBRARY/WINDOWS/DESKTOP/MS685068(V=VS.85).ASPX.
[15] Deacon, John. Model -View -Controller (MVC) Architecture. [Interactiv] August 1995.
http://www.rareparts.com/pdf/MVC.pdf.
[16] MSDN Microsoft. ASP.NET MVC Overview. msdn.micro soft.com. [Interactiv] [Citat: 01 May
2018.] https://msdn.microsoft.com/en -us/library/dd381412(v=vs.108).aspx.
[17] Masse, Mark. REST API Design Rulebook. 2012.
[18] http://microservices.io. Pattern: Microservice Architecture. Microservice Architecture.
[Interactiv] http://microservices.io/patterns/microservices.html.

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

34

CAPITOLUL 6. Anexa

6.1.1 Structura bazei de date

Fig. 6.1.1.1

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

35

6.1.2 Structura fișierelor

.

Fig. 6.1.2 .1 Strunctura fisiere Angular 5 Fig. 6.1.2 .2 structura fisiere Sping Boot

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

36

6.1.3 Interfața grafica

Fig. 6.1.3 .1

Fig. 6.1.3 .2

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

37

Fig. 6.1.3 .3

Fig. 6.1.3 .4

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

38

Fig. 6.1.3 .5

Fig. 6.1.3 .6

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

39

Fig. 6.1.3 .7

Fig. 6.1.3 .8

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

40

Fig. 6.1.3 .9

Fig. 6.1.3 .10

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

41

Fig. 6.1.3 .11

Fig. 6.1.3 .12

Universitatea POLITEHNICA din București
FACULTATEA DE INGINERIE MEDICALĂ

42

Fig. 6.1.3 .13