FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT IOAN SLAVICI [612329]

FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI”
TIMIȘOARA
UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA
FACULTATEA DE INGINERIE
DOMENIUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT – ZI

LUCRARE DE DIPLOM Ă

TIMIȘOARA
2019
COORDONATOR ȘTIINȚIFIC ABSOLVEN T
Conf. dr. ing. Ciprian -Bogdan Chirila Julea Daniel

FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI”
TIMIȘOARA
UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA
FACULTATEA DE INGINERIE
DOMENIUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT – ZI

APLICA ȚIE INFORMATICĂ ÎN
DOMENIUL MEDICAL

COORDONATOR ȘTIINȚIFIC ABSOLVENT: [anonimizat]. Ciprian -Bogdan Chirila Julea Daniel

TIMIȘOARA
2019

UNIVERSITATEA DIN ORADEA
FACU LTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației

TEMA _________________

Proiectul de Finalizare a studiilor a student: [anonimizat] : Julea Daniel____________________
1). Tema proiectul ui de finalizare a studiilor :__Aplicație informatică în domeniul
medical ______________ _________________________
2). Termenul pentru preda rea proiectului de diplomă ___15.06.2019 _
3). Elemente inițiale pentru elaborarea proiectului de finalizare a studiilor : __Pentru
realizarea proiectului s -a făcut o documentare în domeniul sistemelor inteligente din domeniul
medica l.
4). Conținutul proiectului de finalizare a studiilor :
Lucrarea este structurata astfel :
_În capitolul 1 avem o introducere ce des crie lucrarea și prezinta conținutul acesteia pe capitole.
_În capitolul 2 avem o prezentare a sistemelor inteligente în general.
_În capitolul 3 avem o prezentare a sistemelor inteligente medicale.
_În capitolul 4 sunt pr ezentate standarde de date m edicale.
_În capitolul 5 este prezentata analiza cerințelor și specifica țiilor.
_În capitolul 6 este prezentat ă proiectare si dezvoltarea aplicației propuse.
_În capitolul 7 sunt prezentate aspecte ale construcției unei aplicații persistente.
_În capitolul 8 se trag concluziile.
5). Material grafic:_ Lucrarea conține material grafic suficient reprezentând diagrame de clase si
cod ale tehnologiilor Java utilizate.
6). Locul de do cumentare pentru elaborarea proiectului de diplomă :
_Documentarea pentru proiect a fost realizat ă la facultate și la biblioteca facult ății.
7). Data emiterii temei _01.10.2018 ____________________________

Coordonatori științifici
(titlul științific și numele) ,
Conf.dr.ing. Ciprian Bogdan Chiril ă

UNIVERSITATEA DIN OR ADEA

FACULTATEA DE INGINERIE ELECTRICĂ
ȘI TEHNOLOGIA INFORMAȚIEI
Adresa Oradea, Cod 410087, Bihor, Romania, Strada Universit ății, nr. 1 ,
Tel/Fax :+40 259/408412, Tel:+40 259/408104; +40 259/408204

REFERAT
PRIVIND PROIECTUL DE DIPLOMĂ
A

ABSOLVENT: [anonimizat] / ABSOLVENT: [anonimizat] : Julea Daniel ………………………

DOMENIUL Calculatoare și tehnologia informației
SPECIALIZAREA Calculatoare
PROMOȚIA 2019

1. Titlul proiectului …Aplicație informatică în domeniul medical
…..………………………………………………………………………………………… …….. .

2. Structura proiectului ………………………………………………………. ……….
….. _În capitolul 1 avem o introducere ce descrie lucrarea și prezinta conținutul acesteia pe
capitole.
_În capitolul 2 avem o prezentare a sistemelor inteligente în general.
_În capitolul 3 avem o prezentare a sistemelor inteligente medicale.
_În capitolul 4 sunt prezentate standarde de date medicale.
_În capitolul 5 este prezentata analiza cerințelor și specificațiilor.
_În capitolul 6 este prezentată proiectare si dezvoltarea aplicației propuse.
_În capitolul 7 sunt prezentate aspecte ale construcției unei aplicații persistente.
_În capitolul 8 se trag concluziile.
…………………………………………………………………………………………………………….. …………………….
3. Apreci eri asupra conținutului proiectului de DIPLOMĂ (finalizare a
studiilor ), mod de abordare, complexitate, actualitate, deficiențe
… Modul de abordare este unul natural. Se face o prezentare a părții teoretice și anume a
tehnologiilor din zona medicala: aplicații inteligente, standarde de stocare a informațiilor
medicale EHR.
Complexitatea lucrării este decentă, logica aplicației este dată de implementarea unui sistem
de gestiune a pacienților și a afecțiunilor acestora.

Tematica lucrării este una actuala, ea îmbină tehnologii Java cu web cu tehnici de persistență bazate
pe MySQL. [12]
Nu sunt deficiențe în etapele de dezvoltare software.
…………………………………………………………………………………………………………….. …………………….
4. Aprecieri asupra proiectului ( se va menționa: numărul titlurilor bibliografice
consultate, frecvența notelor de subsol, calitatea și diversitatea surselor
consultate; modul în care absolventul a prelucrat informațiile din surse teoretice)
…. Lucrarea are un număr de 19 referințe bibl iografice: cărți, manuale și chiar site -uri web. Nu sunt
note de subsol dar candidatul a fost îndrumat in direcția utilizării în text a formulei de citare pe
baza de paranteze drepte.
……………………………………………………………… ……………………………………………………………………
(se va menționa: opțional locul de documentare și modul în care absolventul a realizat
cercetarea menționându -se contribuția autorului)
………………………………….. …………………………………………………………………………………………………….
…………………………………………………………………………………………………………….. ……………. ……………
…………………………………………………………………………………………………………….. ………………………….
…………………………………………………………………………. ………………………………………..
5. Concluzii (coordonatorul proiectului trebuie să aprecieze valoarea proiectului
întocmit, relevanța studiului întreprins, competențele absolventului,
rigurozitatea pe parcursul elaborării proiectului, consecvența și seriozitatea de
care a dat dovadă absolventul pe parcurs)
… Proiectul este bine structurat, este relevant pentru stadiul actual al domeniului în special in cel
al aplicații lor medicale inteligente. Absolventul a dat dovada de pricepere în toate fazele de
dezvoltare a unui proiect software cu consecvență și seriozitate.
…………………………………………………………………………………………….. …………………………………….

6. Redactarea proiectului respectă …întocmai……….. cerințele academice de
redactare (părți, capitole, subcapitole, note de subsol și bibliografie).
7. Consider că proiectul îndeplinește/ nu îndeplinește condiții le pentru susținere în
sesiunea de Examen de LICENȚĂ ( finalizare a studiilor ) din IULIE 2019 și
propun acordarea notei ………………

Oradea,
Data Coordonator științific

Conf.dr.ing. Ciprian Bogdan Chirilă

CUPRINS :

1. INTRODUCERE …………………………………………………… ………… 1
1.1 Tema proiectului ……………………………………………………………………………………………………………. 1
1.2 Motivația …………………………………………………………………………………………………………………………. 2
1.3 Structura lucrării ………………………………………………………………………………………………………………. 2
2. SISTEME INTELIGENTE …………………………………………………. . 4
2.1 Definiția sistemelor inteligente ……………………………………………………………… 4
2.2 Robotul ASIMO ……………………………………………………………………………… 5
2.3 DEVEX – Sistem expert de consiliere privind schimbul valutar ………………………… 9
3. SISTEME INTELIGENTE MEDICALE …………………………………… 16
3.1 Proiectul RECIPE …………………………………………………………………………… 16
3.2 Proiectul VIKI:A Virtual Keyboard Interface for the Handicappe d……………………. 19
3.3 Proiectul Autonomous Life ………………………………………………………………… 20
4. DATE MEDICALE ELE CTRONICE 21
4.1 Concepte generale …………………………………………………………………………… 21
4.1.1 Definirea principalelor concepte legate de datele medicale electronice ……………… 21

4.1.2 Electronic Health Record (EHR) – Prezentare generală …………………………….. 24
4.2. Componentele sistemului de administrație ……………………………………………. 26
4.2.1 Componentele sistemului de laborator ……………………………………………….. 26
4.2.2 Componentele sistemului de radiologie ……………………………………………… 27
4.2.3 Componentele sistemului de farmacie ………………………………………………… 27
4.2.4 Ordine medicale computerizate ………………………………………………………. 27
4.3 Documentația medicală ……………………………………………………………………. 28
5. SPECIFICAȚIILE AP LICAȚIEI …………………………………………… .32
5.1. Schema si descriere a aplicației …………………………………………………………… 32
5.2. Funcționalitățile aplicației ………………………………………………………………… 33
5.3. Diagrama Gant t……………………………………………………………………………. 33
5.4. Analiza de risc ……………………………………………………………………………… 34
6. PROIECTAREA SI DEZ VOLTAREA PLATFORMEI SOFTWARE ….. 36
6.1 Integrarea Java & JESS ……………………………………………………………………. 36
6.1.1 Crearea obiectelor Java ………………………………………………………………… 37
6.1.3 Apelarea metodelor Java ………………………………………………………………. 38
6.1.4 “Nesting ”ul apelul functiilor si “shortcut -ul”………………………………………… 39
6.1.5 Apelarea metodelor statice …………………………………………………………….. 40
6.1.6 Apelarea metodelor get si set ………………………………………………………….. 40
6.1.7 Utilizarea tablourilor …………………………………………………………………… 41
6.1.8 Cum alege Jess intre metodele supraîncărcate ………………………………………. 42
6.1.9 Accesarea datelor membre Java ………………………………………………………. 44
6.1.10 Excepții ………………………………………………………………………………… 45
7. PROIECTAREA SI DE ZVOLTAREA UNEI APLIC AȚII CRUD ………………………. 46

7.1 Conexiunea la baza de date ……………………………………………………………… 46
7.2 Clasa Pacient …………………………………………………………………………….. 47
CONCLUZII …………………………………………………… ………………… 51
BIBLIOGRAFIE …………………………………………………… …………… 52

1

1. Introducere

Evoluția tehnologic ă din ziua de astăzi , precum si procesul de miniaturizare a diferitelor device –
uri sunt prezente in aproape domeniile de activitate de la servicii publice pan ă la art ă si cultur ă.
Acest proces este dublat de introducerea in fiecare dispozitiv a unuia sau mai multor module care
asigur ă autonomia și /sau un oarecare grad de inteligen ță. Este așadar un proces continu u care are
loc și care asigur ă independen ța si funcționarea la standarde înalte .

Acest proces se desfășoară în foarte multe domenii de activitate, mai ales în cel al serviciilor
publice, și chiar și in domeniul asigurării sănătății publice. Sistemele inteligente medicale sunt din
ce in ce mai prezente in cabinetele medicale, si mai ales in secțiile diferitelor sp itale, deși cele mai
multe cadre medicale sunt sceptice la utilizarea acestora.

Dacă pană nu de mult trebuia s ă mergem personal la casa de asigurări de sănătate pentru orice
problem ă, astăzi multe dintre ele se pot rezolva simplu prin accesarea portal ului casei. Cardul
național de sănătate a simplificat mult o mare parte dintre procedurile care aveau loc în sistem și
permite doctorilor s ă colaboreze pentru a indica tratamente de bun ă calitate.

1.1 Tema proiectului

Tema proiectului de diplomă este legat ă de introducerea elementelor de inteligen ță artificială în
sistemele medicale dezvoltate în mod curent. Avem în vedere sistemele inteligente medicale
orientate spre procesarea datelor medicale.

Înregistrările medicale electronice si procesarea lor constituie principalul obiectiv de cercetare al
acestei lucrări de diplomă . Ne interesează ce fel de date introducem în aceste înregistrări , și de
asemenea prezent ăm diferite metode si concepte derivate din acesta. Toate aceste date sunt inserate

2
în baze de date care apoi sunt procesate de către o aplicație Java. Tema proiectului se refer ă așadar
la ce fel de date introducem si cum realizam procesarea elementar ă a acestora. Procesarea
elementar ă înseamnă operațiile CRUD ( Create, Read, Update, Deleter ) care se realizează asupra
datelor.

1.2 Motivația

Aplicația software a fost realizat ă pentru a vedea cum se pot introduce date simple despre un
pacient într-o baza de date și cum acestea se pot procesa în mod inteligent. Scopul a fost de a studia
diferite procese cum au loc în contextul utilizării anumitor tehnologii. Noi utiliz ăm o baz ă de date
MySQL [10] iar datele sunt preluate și operate via Framework ului Hibernate [8]. Aceste date
obținute devin fapte JESS, care apoi sunt preluate de către motorul de inferenț ă JESS pentru a fi
expuse sub diferite forme de procesare , clientului.

Spre deosebire de alte aplicații aceasta combin ă doua tehnologii: programarea orientat ă pe
obiect e si programarea bazat ă pe reguli. Programarea bazat ă pe reguli este întâlnit ă in cadrul
motorului de inferența dezvoltat în JESS care operează asupra datelor. Java este utilizat ă acolo unde
se preiau datele si se oferă spre procesare sistemului inteligent oferit de JESS. Datele sunt preluate
sau introduse într-o baza de date MySQL. [10]

1.3 Structura lucrării

Lucrarea se întinde pe aproximativ 60 de pagini si are șapte capitole.
Primul capitol ne prezint ă conceptul de sistem inteligent, și de asemenea ilustrează cu exemple din
robotic ă si economie, unde poate fi utilizat ă inteligen ța artificial ă în ziua de astăzi .
Cel de -al doilea capitol ne prezint ă în detaliu trei sisteme inteligente dezvoltate pentru un context
medical sau de asigurare a îngrijirii persoanelor la domiciliu. Este vorba de aplicații complexe care
au interfața web, interfața pentru dispozitive mobile, acces la baze date, dar prezint ă inovații si la
nivel de dezvoltare hardware.

3

Al treilea capitol este o incursiune in lumea sistemelor medicale, si se axează pe înregistrările
medicale, ce conțin ele, si cum sunt standardizate datele introduse.
Al patrulea capitol este legat despre cum a fost dezvoltat proiectul nostru de diplomă , ce proceduri
de dez voltare am ales, calendarul de dezvoltare al prototipului software, etc.
Cel de -al cincilea capitol ne arata cum a fost implementat proiectul software, detalii tehnice
necesare pentru ca orice cititor s ă poată dezvolta ceva similar.
În capitolul șase este descrisă proiectarea și dezvoltarea platformei software.
În cel de -al șaptelea capitol se arată cum se poate proiecta și dezvolta o aplicație CRUD.

4

2. Sisteme inteligente

2.1 Definiția sistemelor inteligente
Mai întâi, în vederea înțelegerii ce calific ă un sistem a fi inteligent, vom discuta atât conceptele
"Inteligen ță" cât și "Sistem". Exist ă foarte multe definiții a ceea ce înseamnă inteligen ță.
"Inteligen ța este facultatea de a descoperi proprietățile obiectelor si fenomenelor înconjurătoare
cât și a relațiilor dintre acestea, dublat ă de posibilitatea de a rezolva probleme noi. " [15].O alt ă
definiție se refer ă la abilitatea de a realiza un obiectiv. Cu c ât un sistem poate sa ajungă la obiectiv
mai rapid cu atât se consider ă a fi mai inteligent. În acest caz, putem vorbi despre capacitatea de a
învață sa facă acest lucru.
Dacă ar fi s ă exprim ăm simplu ce înseamnă un sistem , putem asert a că un sistem este o parte
fizică limitat ă a universului.
Analizând cele doua concepte amintite mai sus, se poate exprima ce înseamnă de fapt un sistem
inteligent . Una din cele mai complete definiții asupra ce înseamnă un sistem inteligent îi aparține
lui N.V .Findler : "Un sistem este considerat c ă are proprietatea de inteligen ță, pe baza comportării
sistemului, dac ă se poate adapta singur la situații noi, are capacitatea de a raționa , de a înțelege
legăturile dintre fapte, de a descoperi înțelesuri si de a recunoaște adevărul . De asemenea ne
așteptam ca un sistem inteligent s ă învețe , deci s ă-și îmbunătățească performan țele pe baza
experienței trecute".
Având in vedere aserțiunile de mai sus, putem spune in cuvinte simple ce înseamnă un sistem
inteligent. Așadar , un sistem inteligent este un sistem care are obiective proprii si gândește in

5
vederea ajungerii la obiectiv, luând decizii bazate pe experiențele avute anterior, învățând altfel
spus prin generaliza re.
Unele exemple de sisteme inteligen țe ar putea fi: Google, robo ți, persoane, o afacere etc.
In domeniul IT, de o perioad ă bună de timp au fost concepute programe( aplicații ) care sunt
sisteme inteligente complete. Totuși , nu era suficient ca siste mul inteligent doar s ă afișeze
informații pe un dispozitiv de ieșire cum ar fi monitorul. Se impun niște sisteme complete care s ă
funcționeze in afara calculatorului, ca niște sisteme de sine stătătoare in cadrul uman. Așa a apărut
conceptul de roboti. V om discuta in cele ce urmează așadar despre robo ții humanoizi.
2.2 Robotul ASIMO [16]
Probabil unul dintre cei mai populari robo ți humanoizi este ASIMO conceput de compania
Honda. Motivul pentru care este printre cei mai populari e ste probabil c ă arată foarte bine din punct
de vedere vizual.

6
Figura1. Robot umanoid asistiv

Am arătat că un sistem inteligent are scopul de a -si îndeplini obiectivele. În cazul nostru
particular, obiectivul sistemului nostru, robotul humanoid, este acela de a se comporta c ât mai
natural într-un mediu uman, adică sa interpreteze si sa imite comportamentul uman.
Asimo nu face excepție , si reușește să integreze multe funcționalități ce ajut ă la interpretarea
lucrurilor din afara sistem ului ce conduc către luarea unor decizii. În cele ce vor urma vom prezenta
câteva dintre acestea.
Una dintre ele este "motion detecting", adică cu ajutorul informațiilor vizuale receptate de către
camera, acesta detectează mișcarea unuia, sau a mai mult or obiecte străine sistemului.
De asemenea, in funcție de informația captat ă, acesta o interpretează , luând o decizie asupra
modului de a reacționa la informația primit ă. Astfel, humanoidul reacționează nu doar când
primește o comand ă vocala, ci și când identific ă un comportament uman cunoscut. Astfel, când o

7
persoan ă va întinde mâna sau va face cu mâna, chiar și când indic ă spre ceva robotul va răspunde
în conformitate cu acțiunea analizat ă.
De asemenea, robotul știe să analizeze m ediul înconjurător și obiectele din jur astfel încât
mișcările pe care le va face s ă nu pună in pericol nici pe el, nici persoanele din jur(se ferește de
ciocniri, urc ă pe plan înclinat, scări etc).
Sistemul de distingere a sunetelor a fost de asemenea îmbunătățit de-a lungul timpului, acesta
făcând deosebire între sunete de mediu si sunete umane. Astfel, în cazul în care o persoan ă i se
adresează , humanoidul privește spre acea persoan ă. Un alt exemplu ar fi acela când are loc un sunet
puternic neașteptat , cum ar fi acela când tună sau are loc o coliziune între 2 obiecte, robotul își
ațintește privirea spre zona de interes. Mesajele interceptate sunt analizate si răspunde fie prin
mișcări ale corpului (mișcări ale capul ui, mâini etc.) fie verbal. Din acest punct de vedere poate fi
asemănat cu un chatterbot avansat.
Totodată , una dintre trăsăturile sale uimitoare este aceea de a distinge trăsăturile feței, chiar și a
unei persoane care se mișc ă. În momentul în care po artă o conversație cu cineva, acesta îi
analizează trăsăturile feței si va recunoaște persoana următoarea dată când va vorbi cu ea după
nume (în 2002 putea re ține maxim 10 persoane iar acum capacitatea de stocare a crescut).

8
Figura 2. Activități ale robotului asistiv

Bineînțeles , toate acestea se refer ă la modul în care robotul știe sa interpreteze mediul
înconjurător , evenimentele și persoanele. Pe de alta parte, s -a investit foarte mult în facilitarea
mișcărilor robotului și a le face c ât mai asemănătoare cu mișcările corpului uman. Pentru aceasta
s-au avut în considerare multe aspecte tehnice cum ar fi păstrarea centrului de greutate de -a lungul
mișcărilor , s-a ținut seama și de influen ța degetelor de la picioare în păstrarea echilibrului. Aici
putem aminti și de încheieturile care au fost create pentru a -i da libertate de mișcare . Acestea sunt
cunoscute ca "unghi de libertate" și sunt plasate in zona g âtului, a mâini lor si a picioare lor.
De asemenea, humanoidului îi sunt încorporați o mulțime de senzori pentru a interpreta modul în
care ar trebui s ă facă mișcarea . Exemple de astfel de senzori sunt senzorii de vitez ă (care analizează
viteza cu care ar trebui s ă se deplaseze robotul), senzori la suprafața pământului și senzori
ultrasonici în zona mediana (aceștia ajută la interpretarea mediului înconjurător și crearea unei hărți
în memoria robotului a mediului în care acesta se afl ă) și senzori ai unghiului înche ieturilor (pentru
controlul mișcărilor ).

9
Crearea unui sistem inteligent ca acesta a fost cu atât mai gre u cu cât ține cont și de pământul pe
care calc ă, condiții meteo( vânt), în păstrarea unei poziții de echilibru si a menține o vitez ă de
mișcare corespunzătoare cerinței de a se asemăna comportamentului uman.

2.3 DEVEX – Sistem expert de consiliere privind schimbul valutar .

Sistemul expert DEVEX [17] a fost creat pentru a v ă da sfaturi în legătură cu schimbul valutar și
tranzacțiile comerciale internaționale . A fost dezvoltat la banca Čačanska în Čačak , Iugoslavia. În
conformitate cu clasificarea lui, DEVEX ar putea fi pus în grupul de sisteme expert pentru
dobândirea de cunoștințe într-un subdomen iu al finanțelor , dar poate fi, de asemenea, aplicat
tranzacțiilor exacte de monedă străină pe nivel internațional .
Categoric unul dintre cele mai importante servicii bancare și produse de schimb informațional
este SWIFT – sistemul internațional pentru plățile electronice și expedierea mesajelor.
Instituțiile financiare din toate țările utilizarea SWIFT pentru schimbul valutar și alte tranzacții
financiare. Toate băncile care doresc să facă schimb de informații sau să efectueze operațiuni
bancare rapid și cu acuratețe sunt incluse în Net SWIFT. SWIFT reprezintă standardul mondial în
sectorul bancar
Efectuarea de schimb valutar cu țări străine peste Net SWIFT impune anumite standarde pentru
mesajul compus. Aceste cerințe trebuie să fie construite în sistemele de informații ale băncilor care
se ocupă cu schimbul valutar.
Participanții care iau parte la tranzacțiile comerciale internaționale și la schimbul de informații
pot fi reprezentate ca în graficul de dependență din care urmează . Clientul este o persoana fizică
sau juridică, sau un cetățean străin. Prima banc ă este coordonator de servicii în care clienții au
conturi în valută, și care aceștia își mențin depozitele în valută și cu ajutorul cărora efectuează
operațiuni diferite. Aceste bănci sau orice alte instituții financiare care sunt autorizate s ă efectueze
aceste sarcini au propriile lor conturi valutare la bănci străine, prin care tranzacțiile sunt efectuate
la cererea unui client.
Firmele străine, care acționează ca importatori sau exportatori de bunuri și servicii, au de
asemenea conturi într -o bancă străină, iar în acest fel acestea pot participa la schimbul valutar al

10
băncii de sta rt. Este necesar, de asemenea, o bancă de legătură în lanțul de tranzacție între banca
de sta rt și banca străină.
Prin aceasta banca de legătură, se efectuează întregul schimb valutar între banca de start și banca
străina, sau numai o parte din acest schimb, dacă o bancă nu este bine -cunoscut ă în piața
internațională de afaceri bancare. De exemplu, o banca de start, poate colecta numai depozitele
străine pentru clienții săi prin intermediul băncii de conectare.

Figura 3. Structura sistemului inteligent bancar
În unele tranzacții de afaceri cu moneda străină toți participanții menționați mai sus pot apărea,
în timp ce numai unii dintre ei pot participa doar la unele tranzacții . Plata către o țară străină este o
situa ție în care toții participanți i iau parte. De exemplu, dacă un client trimite o cerere de plată la o
bancă pentru o firmă st răină, banca de start, procesează, oferă resurse, se trimite o comandă la o
bancă străină să ia o sumă in valută din conturile ei și să o treacă în contul firmei străine.
Compararea de valuta la ICM ( Inter-banking Currency Market ) se efectuează numai în tre banca
de start si banca conexiune: banca conexiune procesează toate cererile de cumpărare valută emise
de către clienți și le trimite către ICM, de obicei prin intermediul unui mediator. De exemplu,
mediatorul pentru banca Čačanska (în care este se folosește DEVEX), în astfel de tranzacții este
Banca Națională a Iugoslaviei (NBY). Atunci când o valută este cumpărat, NBY informează banca
de start care face plăți contra valoare (în monedă națională ) și distribuie valoarea clienților conform
cerințelor lor.

DEVEX este destinat pentru a ajuta angajații băncilor care au de efectuat diferite sarcini legate
de tranzacțiile externe către o anumită bancă. Principalul motiv pentru construirea acestui sistem a

11
fost faptul că tranzacțiile străine r eprezintă un grup de sarcini, care sunt foarte importante în
practică, dar în același timp, sunt extrem de complexe. Este foarte dificil să fie implementate într-
un program procedural sau s ă se creeze algoritmi pentru aceste sarcini. Următoarea discuție oferă
o introspectivă către partea euristică asociată cu tranzacțiile către bănci străine, și explică motivele
pentru care s -a folosit un sistem expert.
Tranzacțiile străine sunt o parte (un subsistem) a sistemului de informații la nivel mondial a unei
bănci sau a oricărei alte organizații financiare. Subsistemul este responsabil pentru mai multe
sarcini ( tranzacții ) care sunt efectuate în țară sau cu o țară străină, și care sunt foarte specifice, fie
în documentație , fie în căile lor de comunicare. Mai ex act, sarcinile acestui subsistem includ
schimbul valutar cu tari străine, plățile în valută pentru diferiți clienți și cumpărarea de valută de
pe piața valutară inter -bancară, precum și altele tranzacții de asemenea. Parcurgere acestor sarcini
poate să afectează tranzacțiile de afaceri al unei firme, și de asemenea, economia întregului teritoriu
pe care această bancă o acoperă.
Prin urmare, o atenție deosebită este acordată acestor sarcini în timpul dezvoltării sistemelor de
informații financiare.
În plus, operațiunile de schimb valutar se fac cu o monedă străină la valoarea sa echivalenta în
moneda locală, în ziua de schimb, care este ulterior utilizată pentru efectuarea de diferite declarații .
O altă problemă este faptul că banca d e start poate lucra cu mai multe rate de schimb diferite (cum
ar fi vânzarea valutei pentru numerar, cumpărarea valutei străină cu numerar, vânzarea și
cumpărarea de valută prin intermediul conturilor bancare, rata medie și așa mai departe), dar numai
o rata de schimb poate fi utilizat într -o tranzacție specifică.
Diferite tipuri de tranzacții sunt implicate și ar putea fi realizată în moduri diferite. Problema
principală este de a alege modul cel mai eficient pentru a efectua o tranzacție . De exemplu, pentru
plata către o țară străină DEVEX ia în considerare mai mulți factori, în amănunt :
– Ce surse asigur ă efectuarea plăților ? Are firma un depozit propriu în cont? Dacă nu, atunci firma
poate achiziționa valută de la banca, prin unele firme care rulează afaceri prin intermediul aceleiași
bănci , sau de la ICM, în funcție de valoarea sa echivalentă temporară? sau alte interese de afaceri.
– Ce monedă este cel mai profitabil ă? Dacă o firmă face plăti în Euro, dar are si US $ si RON în
contul său, atunci fir ma va vinde moneda, prin valuta cea mai profitabilă.
– Prin care banca străină se va face plata? Aceasta afectează timpul necesar pentru efectuarea plății .
Banca cea mai convenabilă din străinătate este aceea care este cea mai apropiată de firma străina

12
la care se va face plata, și la care firma de start, are contul său. De asemenea, este important dacă
banca de start dispune de moneda preferată, sau este nevoie de conversie la moneda necesară prin
care trebuie făcută tranzacția . Un alt aspect este dacă firma are monedă la unele bănci străine atunci
când alte resurse vor fi transferate sau dacă firma străina are un cont la banca aceea, astfel încât
resursele ar putea fi transferate, sau trebuie căutată o altă bancă (sau bănci) di n lanțul bancar unde
firma străină are un cont. În acest ultim caz, este important ca banca de start să aibă cont la banca
străină prin care firma de origine efectuează plăti.
Pe lângă cunoștințe de contabilitate (la ce cont poate fi făcută plata și în ce situații , sau ce conturi
vor fi înregistrate , etc), cunoașterea reglementărilor juridice este, de asemenea, necesar în acest
domeniu. În plus, acesta este un domeniu în care reglementările legale au fost în mod constant în
schimbare și trebuie să fie st rict respectate.
Documentația care este necesar ă pentru o anumită operațiune depinde de modul de efectuare a
tranzacției . În cazul în care banca deține moneda preferată, doar ordinul de plată și compensarea
sunt necesare, în caz contrar, banca de origin e trebuie să aibă comenzi suplimentare de conversie,
transfer, etc.
În cazul în care mai multe ordine de plată către țări străine au sosit, iar în momentul acela banca
are resurse limitate, insuficiente pentru a acoperi toate comenzile, atunci treaba an gajatului pentru
a decide care comenzi vor fi acoperite și cele care vor fi amânate (în funcție de prioritățile
acestora). Angajatul poate lua decizii în funcție de diferite criterii: dacă utilizarea de produse este
limitată, sau expediere nu trebuie să f ie întârziată, sau poate o firmă importă mașinării în vederea
îmbunătățirii producției în viitor (peste câteva luni sau ani, caz în care plata poate fi amânată), etc.
Comenzile care au fost prelucrate pot conține erori. Un angajat poate estima dacă aceasta este
doar o greșeală banal ă pe care el poate s ă o corecte ze personal, sau dac ă trebuie să organizeze o
consultare telefonică cu un angajat de la firm ă, sau dacă el trebuie să trimită înapoi cererea la firm ă.
Este posibil ca documentul în sine să nu permită nici o corecție (cifrele cardului de credit de
exemplu).
Aceste cunoștințe pot fi aplicate la tranzacții valutare doar la banca c e, de asemenea, se ocupă,
cu alte servicii, cum ar fi munca de birou, economii le cetățenilor , etc.
Având în vedere complexitatea schimbului valutar prezentat mai sus, rezultă că este foarte greu sa
faci un program procedural care ar face tranzacții , ar pregăti comenzile, ar întocmi documentele
necesare, etc.

13

Criteriile de decizi e construite în DEVEX au fost date de către experți financiari. Figura
următoare prezintă un set final al parametrilor financiari și non-financiari folosiți în DEVEX, care
sunt utilizați drept criterii de evaluare pentru evaluarea priorităților de plată. Contribuția fiecărui
criteriu a fost modelat folosind o valoare de tip întreg pe scară de la 0 la 10, unde 0 este minim și
10 este valoarea maximă.
Valori le concrete depind de acurate țea de plăti și a altor date cu privire la firmele de afaceri într –
o perioadă anterioară.

Nume Descriere Cod

Criteriul financiar

Resursele deținute in
cont Compania are un sold suficient de mare în cont, în
valuta străină necesară efectuării plății
A

Banca poate face

plăți Banca de afaceri are un sold suficient de mare în contul său
într-o bancă străină specifică, în valută străină
necesare pentru plata
B

14
Importanța firmei
pentru bancă Valoarea depozitului firmei (procent din capitalul său)
in banca C1

Venitul băncii obținut de la acea firmă în perioada anterioară
(comisionul băncii pentru fondurile deja realizate
tranzacție cu țări străine)

C2

Cât de repede firma plătește comisionul către bancă C3

Criterii nefinanciare

Tip de bunuri pentru
care
plățile sunt
făcute Depinde de persistența bunurilor: bunuri cu persistență scurtă,
medicamente, produse cu durată mai lungă de persistență,
produse nelimitate de persistență
D

Scopul mărfurilor
importate Mărfuri pentru consumul în masă (mărfuri cu deficit),materiale,
mașini și unelte pentru creșterea producției
E

Importanța firmei
pentru Efectul firmei asupra funcționării altor firme
F1

15
regiunea din care ea
aparține Numărul de persoane din regiune care lucrează pentru firmă
F2

Figura 4. Criteriile pentru determinarea priorităților de plata in DEVEX

Cunoștințele dobândite sunt reprezentate în baza de cunoștințe a sistemului expert DEVEX ca un
set de 320 reguli de producție . Sistemul a fost dezvoltat folosind instrumentul profesion al EXSYS.
Următorul exemplu arată o regulă de producție care calculează valoarea parametrului C2 din figura
de mai sus:

“ IF (ave rage numere of the firm's transactions <=5 AND
the bank's commission acquired from the firm's transactions >= 10.000)
(average number of the firm's transactions >=10 AND
the bank's commission acquired from the firm's transactions <= 10.000) THEN C2:=3 ”

Motor ul de inferen ță DEVEX trage concluzii cu privire la prioritățile efectuării unei plăți
prin aplicarea acestor norme de bază de cunoștințe pentru datele de intrare despre plățile specifice.

16

3. Sisteme inteligente medicale

3.1 Proiectul RECIPE
Proiectul de cercetare RECIPE adopt ă o cercetare metodologic ă hibrid ă, bazând -se pe tehnici
non-empirice. De-a lungul acestui proiect, în primul rând se investighează manual execuția
proceselor si apoi se adaugă mai multe tehnologii pentru fluxul de date pentru a îmbunătăți
procesul.
La fiecare pas al automatizării , fluxul de date medicale sunt prelucrate folosind următoarele
procese: analiza stării proceselor, realizarea unui caz business, neprelucrarea proceselor business,
evaluarea.
In timpul analizei, analistul se concentrează pe puncte slabe din punct de vedere material,
financiar, informațional sau fluxul proceselor. Pentru a justifica orice schimbare in fluxul de date,
trebuie definit un caz business, in care trebuie stipulate costurile, așteptările , riscurile așteptate
propunerii la care trebuie adaptate. RECIPE permite ca procesele sa fie testate manual in domeniul
sănătății pentru a sprijini fezabilitatea si profitul. Îmbunătățirea proceselor se refer ă la faptul c ă
procesele pot fi evaluate si calibrate cu o întârziere virtual ă între operația în execuție și cea
monitorizat ă. Evaluarea îmbunătățirii proceselor are loc prin simpla comparare dintre măsurarea
metric ă după introducerea îmbunătățirii si cea înainte de îmbunătățire . Unele măsurători se refer ă
la calitatea serviciilor, câștiguri , costuri, îmbunătățirea stării pacienților si nivelul adoptării
procesului îmbunătățit .
Pasul 1: Analiza procesului (UMMS). Au fost implementate 3 sisteme:
1) Sistem de management pentru echipamente si provizii
2) Sistemul pentru programări

17
3) Sistemul pentru depistarea dispozitivelor
Pasul 2: Analiza cazului business. Implementarea fluxului de date se bazează pe o analiza detaliat ă
a proceselor dintr -o clinic ă si dezvoltarea unui proces nou. Cercetări considerabile au fost realizate
pentru evaluarea proceselor în clinici, oportunități de priorit izare a țintelor , și analiza celei mai
importante oportunități țintă.
Pasul 3: Îmbunătățiri manual ă a procesului .
Pasul 4: Îmbunătățirea automata a procesulu i in ceea ce privesc proviziile si livrarea instrumentelor
Un prototip al fluxului de date pentru provizii si instrumente a fost implementat folosind
OSWorkflow. OSWorkflow suporta un flux de date bazat pe XML .Acesta permite un fișier simplu
XML sa fi e transmis unui flux de date business. Un prototip al fluxului de date prezinta următorii
pași: Chirurgia este planificat ă, OSWorkflow trimite lista de preferințe chirurgicale asistentelor OR
și le cer sa verifice cart -ul, asistentele răspund cu orice el ement care lipsește , elementele lips ă sunt
raportate camerei cu provizii, camera de provizii ia la cunoștinț ă si duce la îndeplinire cererea,
cererea revine la asistentele OR.

Avantajele software -ului multimedia pentru a dezvolta capacitățile persoanelor cu handicap :
este un mediu audio -vizual, este interactiv, tratamentele sau situațiile pot fi reproduse, aceleași
condiții pot fi reproduse de nenumărate ori ,modul de prezentare este realizat in funcție de
problemele întâlnite ,(mărimea , forma, contrastul, culoarea, înălțimea liniilor, a obiectelor și
fundalul pot fi selectate în funcție de pacient.) poate fi ajustat in funcție de nevoile individuale,
sistemele multimedia au efect pe mai multe sensuri, putând fi eficiente, poate ajuta creativitatea,
poate varia , se pot introduce jocuri în programele multimedia, utilizatorul simte aplicabilitatea , se
poate folosi un feed -back audio motivant, poate fi folosi t fie in mod individual fie în grupuri mici
de terapie.
În cazul copiilor : părinții îl pot folosi cu succes , cel mai important este ca acești copii s ă devin ă
interesați , acest interes s ă și-l păstreze pentru o perioad ă lungă de timp( acesta nu este un lucru ușor
de realizat, dar prezentările multimedia sunt foarte eficiente în acest sens), să fie ca un joc: copilul
să nu considere exercițiul ca o obligație ci să îi plac ă.
Problemele apărute de-a lungul dezvoltării procesului și soluții lor lor:

18
1) Deteriorarea vederii și persoanele cu vedere slab ă – vederea perfect ă este de 1, vederea unei
persoane cu vederea deteriorat ă este de 0.1 si 0.3. Este indicat s ă se traseze contururi groase în jurul
obiectelor. Dac ă aceste persoane disting culorile bine atunci software -ul trebuie s ă aibă și o funcție
de schimbare a culorii obiectelor , a fundalului și de oprire a animație .

2) Persoane ce prezint ă o deteriorare a auzului –copii încă de la vârsta de 3 ani trebuie învăța ți să
vorbească , aceasta continuând și la școală ca o materie obligatori e pe lângă celelalte din program ă.
Dacă îi învăț ăm să vorbească si să își înmulțească vocabularul cu ajutorul jocurilor pe calculator,
le va fi de mare ajutor. Este important ca informațiile noi sa le furnizam foarte grafic, ca un desen.

3) Persoanele cu problem e locomotorii – probabil nu pot folosi mouse -ul sau tastatura , aceștia pot
folosi alte dispozitive de intrare sau dezvoltatorul software -ului trebuie sa cree ze instrumente
special de navigare , de exemplu utilizatorul trebuie s ă folosească un singur switch sau un buton
mare.

4) Persoane cu problem e de vorbire sau fizice – exista software -uri care îi ajut ă în comunicare( în
Ungaria se folosește Bliss -ul pentru a imprima sau trimite mail -uri, pentru a scrie propoziții și
pentru a trimite sms -uri, bazat și pe tehnica de mutare a dreptunghiurilor.)

5) Probleme de dislexie – introducerea unor titluri în text, acest lucru ajut ă oamenii în cazul în care
trebuie s ă citească un text mai lung.

6) Copi ii cu probleme mentale și cei ce au probleme cu învățarea , instrucțiunile și propozițiile trebuie
să fie simple, informația trebuie s ă fie scris ă în propoziții simple.

7) Persoanele cu probleme în deosebirea culorilor – trebu ie să se țină cont de setările de culoare.

19

3.2 Proiectul VIKI:A Virtual Keyboard Interface for the Handicapped [19]

Proiectul VIKI este un mod de a demonstra eficien ța utilizării unui laptop ca fiind o tastatur ă
virtual î pentru a accesa un calculator gazd ă pe care se rulează un software standard. SIL(Laptop
cu o Interfaț ă Specializat ă) furnizează orice conexiune necesar ă pentru dispozitivele asertive și
pentru orice afișaj pe ecran de care are nevoie utilizatorul pentr u a interacționa cu aceste
dispozitive. După introducerea unor date de intrare în SIL, datele sunt trimise apoi în calculatorul
gazd ă in așa fel încât să pară că sunt create de către o combinație standard a tastaturii și a mouse –
ului. Software -ul și hardw are-ul din SIL sunt realizate în funcție de nevoile utilizatorilor, în timp
ce software -ul si hardware -ul din calculatorul gazd ă rămâne neschimbat.
Proiectul VIKI prezint ă 3 faze:
1) Dezvoltarea software -ului necesar pentru ca sistemul SIL s ă mimeze toate metodele de
interacționare necesare unei tastaturi și unui mouse standard, pentru a exista o comunicare între
SIL si sistemul gazd ă printr -o interfața serial ă. Sistemul SIL rulează pe Windows si este creat în
Visual Basic. Cele doua sisteme se conectează prin porturile lor seriale folosind un cablu de
modem. Software -ul VKE oferă utilizatorului o reprezentare a unei tastaturi, pe ecran, care poate
fi manevrat ă fie din tastatura laptopului sau prin așezarea si apăsarea mouse -ului cu ajutorul
dispozitivului laptopului. VKE -ul oferă si un simulator pentru mouse, care va muta cursorul mouse –
ul gazdei în direcția indicat ă. Accesul la bara de meniu a VKE -ului pentru a custom iza controlul,
prin selectarea dispozitivului de intrare principal , setarea culorii fundalului, viteza mouse -ului, etc.
Interacțiunea poate fi realizat ă prin un mod de scanare a tastaturii. În acest mod, dac ă utilizatorul
apasă shift, rândul este selectat si selectarea continua prin apăsarea unui buton de -a lungul rândului .
O a doua apăsarea a șift-ului va selecta cheia ce se transmite computerului gazd ă. Sistemul SIL
poate fi utilizat și ca un sistem de sine stătător în timp ce încă se folosește software -ul VKE. Aceast ă
opțiune permite transmiterea informației către o aplicație ce rulează pe laptop. În urma acestui lucru
VKE -lu obține ID-ul aplicației ceea ce permite VKE -ului s ă transmită date aplicației . Pentru ca
VKE -ul sa realizeze ac easta acțiune trebuie s ă știe către ce aplicație să transmită datele. Acesta
oferă o list ă a tuturor aplicațiilor ce exist ă pe hard -ul laptopului, permițând utilizatorului s ă aleagă
una pentru a o executa. Din partea gazdei , un program TSR(terminate -an-stay-resident) este

20
necesar. Comunicator -ul primește semnale SIL ca date de intrare prin portul serial al gazdei, și
îndreaptă aceste semnale către alte programe ce rulează pe gazdă ca date de intrare. Comunicatorul
trebuie sa aibă control asupra sistemului gazd ă, chiar dacă aplicația software a fost început ă dar
suspendat ă apoi.
2) Înlocuirea comunicării seriale cu o comunicare direct ă cu portul tastaturii sistemului gazd ă,
eliminând astfel nevoia programului de comunicare TSR a gazdei. Acest lucru va face SIL -ul
portabil, permițând -ui SIL -ului s ă se conecteze la orice gazd ă compatibil ă.
3) Înlocuirea conexiunii hard -wire dintre SIL si sistemul gazd ă cu un sistem wireless. Ideea este de a
înlocui o tastatur ă wireless cu un laptop care s ă îndeplin ească aceleași atribuții ca și tastatura.
3.3 Proiectul Autonomous Life

S-au remarcat 6 scenarii in care sa se încadreze persoanele cu dizabilități : apelul vocal, mesajul
existent, mesajele text, „am nevoie de ajutor ”, „m-am pierdut ” , „nu mă simt bine ”.
Din analiza acestor scenarii, nevoile sistemelor de comunicare mobile pentru persoanele cu
dizabilități și pentru persoanele in vârst ă se clasific ă în următoarele categorii:
• Comunicare personal ă: folosit ă pentru persoanele cu probleme locomotorii. Acesta implic ă
imposibilitatea acestor persoane de a se deplasa într-un timp scurt pentru a putea răspunde și modul
de folosire a telefoanelor cu fir.
• Securitate: Persoanele în vârst ă si cele cu probleme locomo torii întâmpina restricții care pot duce
la o situație de potențial risc care cre ște în momentul în care aceștia doresc sa aibă un mod de viață
independent.
• Integrarea social ă. Accesul la educație și pe piața forței de munc ă: în ultimii ani telefoanele cu fir
au permis un acces la informație și la oportunități de angajare prin servicii telematice, ca de
exemplu lucrul prin telefon sau educarea prin telefon a persoanelor cu dizabilități ajutând la
integrarea sociala și autonomie. Telefoanele mobile sunt utile în zonele izolate în care telefonia fix ă
nu exist ă.
• Autonomia: Combinație dintre comunicarea personal ă, securitate si accesul la serviciile integrative
permite persoanelor în vârst ă și celor cu dizabilități să duca un mod de viață indep endent.

21
Asigurarea serviciilor cu ajutorul telefoanelor mobile poate duce la un risc social si etic pentru
persoanele cu dizabilități și pentru persoanele în vârsta . Cele mai critice sunt: izolarea social ă,
pierderea autonomiei personale, pierderea intimității , barierele economice.

4. Date medicale electronice

4.1 Concepte generale

4.1.1 Definirea principalelor concepte legate de datele medicale electronice:

Electronic Health Record este o înregistrare electronică de informații privind sănătatea pacientului,
informații generate de unul sau mai multe evenimente în sistemul de îngrijire al pacientului. Printre
aceste informații sunt incluse: datele demografice ale pacienților, evoluția pacient ului, probleme,
medicamentație, semnele vitale, antecedente medicale, vaccinări, date de laborator, precum și
rapoarte de radiologie. EHR automatizează și simplifica fluxul de lucru medical. EHR are
capacitatea de a genera o înregistrare completă a unui co nsult medical, precum și sprijinirea altor
activități de îngrijire legate direct sau indirect, prin intermediul interfeței , inclusiv suport decizional
bazat pe dovezi, managementul calității și raportarea rezultatelor.
Este important de remarcat faptu l că un EHR este creat și întreținut în cadrul unei instituții, cum
ar fi un spital, clinică sau birou medical. Un EHR nu este o înregistrare longitudinală a tuturor
serviciilor medicale furnizate pentru pacient la toate nivelele de -a lungul timpului. Înre gistrările
longitudinale pot fi păstrate într -un sistem de informații de sănătate la nivel național sau regional.
Electronic Pa tient Record (EPR) este un concept în evoluție definit c a o colecție electronică
sistematică de informații privind sănătate a unui pacient sau a unei populații.

22
Termenii EPR și EMR (Electronic Medical Record) sunt adesea folosiți alternativ, deși se pot
observ a diferențe între aceștia , poate fi definit c a o înregistrare legală a pacientului, creată în spitale
și medii ambul atorii, care este sursă de date pentru EHR. Este important de menționat faptul că un
EHR este generat și menținut în cadrul unei instituții, cum ar fi un spital, clinică, cabinet medical,
pentru a asigur a accesul la informațiile medicale ale pacientului persoanelor interesate de acest
lucru: pacienți, medici, alți îngrijitori, angajați, asiguratori și contribuabili.
Personal Health Record (PHR) este de obicei o înregistrare medicală care este creată și
menținută de către un individ. Un PHR ideal ar o feri un sumar medical complet și exact al istoriei
sănătății unei persoane prin colectarea de date din mai multe surse și oferirea accesului on -line la
aceste informații pentru oricine are acreditările electronice necesare pentru a vizualiză informațiile
dorite.
Termenul “PHR ”a fost aplicat atât la sistemele pe suport de hârtie, cât și celor computerizate. Cu
toate acestea, utilizarea actuală implică de obicei o cerere electronică folosită pentru a colect a și
pentru a stoca date de sănătate. Există mai mu lte definiții ale conceptului, însă cea prezentată mai
sus este cea mai utilizată.
Este important de reținut faptul că PHR nu este identic cu EHR (Electronic Health Record).
Acestea din urmă sunt sisteme software destinate utilizării de către furniz orii de servicii medicale.
La fel c a datele medicale înregistrate pe suport de hârtie, datele conținute de EHR sunt informații
cerute de către lege privind serviciile medicale furnizate de medici pentru pacienți. Nu există nici
o lege care obligă un consum ator sau pacient să stocheze informații de sănătate cu caracter personal
într-un PHR [5].
Continuity of Care Record (CCR) este un standard dezvoltat de mai multe societăți
internaționale pentru normalizarea înregistrărilor medicale. Standardul CCR se d orește un rezumat
clar al stării de sănătate a unui pacient. El reprezintă o modalitate de a cre ea documente flexibile,
care să conțină informații cât mai relevante privind sănătatea pacientului, accesabile în timp util,
precum și o modalitate de a trimite electronic aceste informații de la un îngrijitor la altul.
Acest rezumat trebuie să conțină secțiuni diferite, cum ar fi datele demografice ale pacienților,
informații legate de asigurare, diagnostic și lista de probleme, medicamente, alergii, pre cum și a
planului de îngrijire. Acestea reprezintă un rezumat al datelor privind sănătatea unui pacient, care
poate fi util dacă este disponibil la momentul evaluării clinice. Acest standard este conceput pentru

23
a permite crearea cât mai facilă a rezumatul ui stării medicale a pacientului de către un medic cu
ajutorul unui EHR la finalul evaluării pacientului [6].
Pentru că este exprimat în limbajul standard XML, un CCR are potențialul de a fi creat, citit și
interpretat de către orice aplicație software EHR sau EMR. Un CCR poate fi, de asemenea, exportat
și în alte formate, precum PDF și Office Open XML.
Com puter -based Patient Record(CPR) este o înregistrare electronică a pacientului care este
situată într -un sistem special conceput pentru a sprijini utilizatorii prin accesibilitatea la date
complete și exacte, alerte, memento -uri, sisteme suport de decizie c linică, link -uri la cunoștințe
medicale, precum și alte ajutoare.

CPR poate oferi acces la diverse instrumente medicale (de exemplu: sprijinirea deciziilor
medicale) care pot fi folosite pentru a dezvoltă o perspectivă de ansamblu asupra pacientului.
Acesta include captarea, descrierea, analiz a și evaluarea rezultatelor asociate cu informațiile
disponibile de la laboratoare, radiologie, evaluare și alte dispozitivele medicale.
Relația CPR cu dispozitivele medicale presupune comunicarea datelor de la aceste dispozitive
medicale împreună cu înregistrările medicale, precum și cu mecanisme tipice de intrare și de ieșire.
Computerized Medical Record (CMR) este o înregistrare medicală electronică crea tă într -o
organizație care oferă îngrijire medica lă, cum ar fi un spital sau cabinetul medical. Înregistrările
medicale electronice tind să fie parte dintr -un sistem local st and-alone de informații privind
sănătatea, care permite stocarea, extragerea și modificarea înregistrărilor.
Alții definesc E MR/EHR/CPR pur și simplu că sisteme atotcuprinzătoare a înregistrărilor
privind pacientul și tratamentul acestuia. Gartner definește cinci generații sau nivele de tehnologie
EMR [6], însă doar primele trei prezintă importan ță pentru subiectul abordat. Prima generație de
sisteme de tehnologie a informației medicale furnizează date pentru captare și afișare. EMR din a
două generație sunt cele care permit includerea documentelor scanate și transcrise. A treia generație
este destinată reprezentării datelor medi cale în mod flexibil și facilitează interacțiunea cu aceste
date.
American Health Information Management Association (AHIMA) a publicat rezultatele unei
căutări pe Internet privind managementul informațiilor sănătății pacientului. Căutarea pe Interne t
a returnat următoarele texte sau termeni frecvent citate: Electronic Health Record (EHR),
Electronic Pa tient Record (EPR), Electronic Medical Record (EMR), Personal Health Record

24
(PHR), Continuity of Care Record (CCR), Computer -based Pațient Record (CPR) , Computerized
Medical Record (CMR) și altele. Multe dintre acestea sunt folosite alternativ. Articolul a sugerat
că Deși există diferențe între EHR, CPR, EMR și EPR, toți acești termeni descriu sisteme care
oferă o înregistrare a pacientului structurată, digitală și pe deplin accesibilă [1][5] .
Multe studii desfășurate estimează îmbunătățirea eficienței generale cu aproximativ 6% pe an
atunci când se folosesc înregistrările medicale electronice, față de sistemele pe bază de hârtie.
Pe lângă această sistemele electronice cresc portabilitatea și accesibilitatea documentelor
medicale electronice. Implementarea unui sistem de securitate va diminua posibilitatea pierderilor,
furturilor și a modificărilor față de dosarele medicale stocate pe hârtie.

4.1.2 Electronic Health Record (EHR) [1]– Prezentare generală

Valoarea majoră a sistemelor medicale integrate este faptul că permit captarea de date medicale
că parte a fluxului de lucru global. Un EHR [1] permite administratorului să obțină date pentru
facturare, medicului să observe tendințe în eficientizarea tratamentului, asistenței să raporteze o
reacție adversă, cercetătorului să realizeze mai facil studii medicale. Dacă fiecare dintre acești
profesio niști ar lucra cu date silo (date fără conexiuni între ele, neintegrate), fiecare va avea o
imagine incompletă a stării pacientului. Un EHR integrează datele pentru a deservi nevoi
diferite [4]. Scopul este de a colectă datele o singură data și pentru a fi utilizate de mai multe ori.
O înregistrare electronică medicală poate fi crea tă pentru fiecare serviciu pe care un pacient îl
primește de la un departament auxiliar, cum ar fi cel de radiologie, laborator, farmacie sau c a
rezultat al unei acțiuni ad ministrative (de exemplu, emiterea unei facturi). Unele sisteme medicale
precum AMC (Academic Medical Centers) permit captarea electronică a semnalelor fiziologice (de
exemplu, electrocardiografie), notelor asistentelor, rețetelor medicilor etc. De cele ma i multe ori
aceste înregistrări electronice nu sunt integrate, ci sunt capturate și rămân în sistemele silo (sisteme
incapabile să funcționeze în reciprocitate cu alte sisteme conexe), care au fiecare prop riul lor sistem
de autentificare și de identificare a pacientului [3].
Vânzătorii de sisteme silo pot utiliza standarde diferite pentru vocabulare, pentru identificarea
utilizatorului, precum și pentru identificarea pacienților. Trebuie subliniat faptul că nu există acces
unificat la aceste sisteme. U n utilizator din domeniul medical ar trebui să deschidă o serie de

25
aplicații, să se autentifice în fiecare și apoi să găsească dosarul pacientului în cadrul fiecărei
aplicații pentru a putea vedea dosarul complet al pacientului. În practică, ceea ce se înt âmplă de
multe ori este că datele electronice vor fi trimise prin fax sau imprimate și se atașează dosarului de
hârtie la internarea bolnavului. În cazul în care noi le rezultate electronice sunt disponibile,
rezultatele vechi vor fi actualizate și noi le afecțiuni (de exemplu, alergii) pot fi adăugate. Personalul
medical s -ar putea să nu fie notificat, cu excepția cazului în care este autentificat în sistemul auxiliar
respectiv. Mai mult, datele disparate nu pot fi agregate într -o afișare integrată, cum ar f i foaia de
flux al analizelor medicale.

Dacă personalul medical ar avea acces la un sistem integrat de date, atunci sistemul ar fi în măsură
să afișeze, de exemplu, toate cazurile în care pacienții au fost diagnosticați cu leucopenie, împreună
cu toate cazurile diagnosticate că fiind “număr scăzut de celule albe”, deoarece cele două concepte
ar fi codificate c a și termeni sinonimi. Pentru a rezolvă variațiile de vocabular trebuie utilizat un
sistem structurat de vocabular, iar datele tr ebuie să fie capturate în așa fel încât sistemul să poate
recunoaște termenii apropriați și să îi plaseze în contextul adecvat. Datele pot fi introduse în text
liber (cum ar fi informațiile despre evoluție), într -o formă structurată printr -o lista drop -down, că
imagini, sau că semnale digitale (de exemplu, electrocardiograme) asociate cu meta -date.
O arhitectură integrată po ate fi crea tă pentru a permite schimbul de date între sisteme. Fiecare
sistem își păstrează date proprii la nivel local. Pentru a pa rtaja informațiile pacientului, un sistem
trebuie să permită unui altui sistem să acceseze fișierele sale, iar acesta trebuie să transmită o copie
a dosarului la sistemul care a cerut acest lucru. Odată ce fișierul a fost identificat pentru partajare,
acesta poate fi integrat cu alte fișiere, în funcție de nivelul de interoperabilitate între sistemele
integrare.
EHR -ul[1] descrie integrarea datelor privind asisten ță medicală de la o colecție de sisteme
participante, pentru un singur pacient.
Compon ente cheie ale dosarelor medicale electronice .
Cele mai multe EHR comerciale sunt concepute pentru a combin a datele provenind de la
serviciile auxiliare de dimensiuni mari (farmacie, laborator și radiologie) cu diferite componente
de îngrijire medicală, cum ar fi: rețetele medicilor, înregistrările privind medicamentația
pacientului, observațiile asistentelor. N umărul de componente integrate și facilitățile în oricare
sistem integrat de date depind de structurile de date și de sistemele puse în aplicare de către echipele

26
tehnice. Pot există o serie de furnizori de sisteme auxiliare care nu sunt neapărat integrate în EHR.
Prin urmare, EHR poate import a date din sistemele auxiliare prin intermediul unei interfețe
personalizate sau a unei interfețe care permit personalului medical să acceseze sistemele de tip silo
printr -un portal. C a alternativă EHR -ul poate încorpo ra doar câteva din serviciile auxiliare.

4.2. Componentele sistemului de administrație

Înregistrare, internări, externări, precum și transferuri (prescurtat: RADT – Registration,
Admission, Discharge and Transfer) datele provenite de l a aceste proceduri sunt componente cheie
ale EHR. Aceste date includ informații vitale pentru identificarea și evaluarea pacientului: nume,
date demografice, rude, informații angajator, cerințe ale pacientului etc. Partea de înregistrare din
cadrul unui E HR conține un identificator unic al pacientului, care de obicei constă dintr -o secvența
numerică sau alfanumerica, ușor identificabila și în afar a instituției. Datele RADT permit c a
informațiile personale de sănătate să poată fi utilizate atât în analiză m edicală, cât și în cercetare [5].
Identificatorul unic al pacientului este nucleul unui EHR și face legătură cu toate celelalte părți:
observațiile medicale, teste, proceduri, evaluări, precum și diagnostice ale pacientului.
Identificatorul mai este n umit și numărul medical al pacientului sau index principal al pacientului
(MPI – Main Pa tient Index). Evoluția sistemelor informaționale automatizate au făcut posibilă
utilizarea pe scară largă de către organizații sau instituții a MPI -ului.

4.2.1 Componentele sistemului de laborator
Sistemele de laborator sunt în general sisteme stan d-alone care sunt interfațate cu EHR. De
obicei, există sisteme informatice de laborator (LIS – Laboratory Information System) care sunt
utilizate că hub -uri pentru a integra comenzi și rezultate provenite din instrumente de laborator,
programul de factura re, precum și alte informații administrative. Datele de laborator sunt rareori
integrate în întregime cu EHR, chiar și atunci când LIS este realizat de către același vânzător de
EHR, deoarece multe dispozitive și analizoare care sunt utilizate în procesul de diagnosticare din
laborator nu sunt ușor de integrat în EHR [5]. De exemplu, Corner LIS interfațează cu peste 400 de
instrumente de laborator diferite. Cerner, un furnizor major de LIS și a sistemelor EHR, a raportat

27
că: “60 la sută din instalările sale LIS au fost st and-alone (nu au fost integrate cu EHR) ”. Unele
EHR [4] permit utilizatorului să acceseze modulul LIS de la un link în cadrul interfeței EHR.

4.2.2 Componentele sistemului de radiologie
Sistemele informatice de radiologie (RIS – Radiology Information System) sunt utilizate de către
departamentele de radiologie pentru a pune împreună datele pacientului ce țin de departamentul de
radiologie (de exemplu: interpretări, informații de identificare ale pacientului) cu imagini. RI S
tipice includ: evoluția pacientului, programarea, rapoarte cu rezultate, precum și funcții de urmărire
a imaginilor. Sistemele RIS sunt de obicei utilizate împreună cu sistemul de comunicare al
imaginilor arhivate (PACS – Picture Archiving Communication s Systems) care gestionează
radiografiile digitale. Cele mai multe AMC (Academic Medical Centers) au sisteme RIS. Cu toate
acestea, nu se poate garanta că toate sistemele R IS sunt integrate cu EHR [1].

4.2.3 Componentele sistemului de farmacie
Farmaciile sunt în mare parte automatizate în AMC (Academic Medical Centers) și în spitalele
mari. Dar aceste insule de automatizare, cum ar fi roboții de farmacie pentru scrierea rețetelor sau
formularelor de plată, nu sunt de obicei integr ați cu EHR [2]. Conform unui raport din 2005 în
medie 31% din toate rețele electronice sunt reintroduse în sistemul farmaceutic.

4.2.4 Ordine medicale computerizate

Ordinele medicale computerizate (CPOE – Computerized Physician Order Entry) permite
personalului medical să comande electronic analize de laborator, produse din farmacie și servicii
de radiologie. Sistemele CPOE oferă o gamă largă de funcționalități de la comenzile pentru
farmacie la sisteme mai sofisticate, cum ar fi servicii auxiliare complete prin care se pot coma nda,
alerta, creă seturi de comenzi personalizate, de raportare și de rezultate. Potrivit Klas Enterprises,
un furnizor de date pentru industria informatică din spitale: “doar 4% di n spitale le din SUA folosesc
sisteme CPOE ”.
Această rată lentă de difuzare poate fi parțial cauzată de scepticismul personalului medical cu
privire la valoarea unui CPOE [6]. Deși au fost înregistrate unele succese majore ale CPOE, au fost

28
înregistrate și unele eșecuri notabile. Handler, într -un articol de ansamblu cu privire la CPOE și
sisteme suport de decizie medicală, a declarat: “s-a demonstrat faptul că CPOE reduce erorile legate
de medicație. Cu toate acestea, CPOE și calculele de dozare nu elimi nă în întregime eroarea și pot
introduce noi tipuri de eroare. Astfel s -a demonstrat că pentru dozarea medicamentelor bazată pe
greutate calculatoarele sunt mai rapide în calcule complexe și pot fi mai precise decât calculul de
mână. Cu toate acestea, efe ctul net al CPOE poate să încetinească medicii ”.
4.3 Documentația medicală

Documentația medicală electronică crește valoarea EHR prin furnizarea de captare electronică a
notelor medicale, a evaluărilor pacientului și a rapoartelor medicale, precum și a înregistrării
administrării de medicație (M AR – Medication Administration Rec ords) [3]. Ca și în cazul
componentelor CPOE, implementarea cu succes a unui sistem de documentație medicală trebuie
să coincidă cu reproiectarea fluxului de lucru. Sistemul de documentație medicală are beneficii
substanțiale, astfel că până la 24% din timp ul unei asisten te medicale poate fi salvat.
Exemple de documentație medicală, ce pot fi automatizate [5]:
• Note medicale ale medicilor, asistentelor precum și alte note medicale adiacente;
• Foi de observație (semne vitale, intrări și ieșiri, liste de probleme, M AR);
• Rezumate de externare;
• Transcriere documente manageriale;
• Sumar dosarele medicale;
• Împuterniciri ale deciziilor de asisten ță medicală;
• Diagrame de urmărire a pacientului;
• Dosarele medicale (inclusiv autorizații);
• Credențialele personalului / calificarea personalului și documentarea programărilor;
• Graficul de urmărire a deficiențelor;
• Utilizarea de management.

Dispozitivele medicale pot fi, de asemenea, integrat e in fluxul de informații medicale si utilizate
pentru a genera in timp real alerte datorate modificării stării pacientului. Hugh susține ca “la
Cedars -Sinai Medical Center, Los Angeles, de exemplu, pompele de medicamente intravenoase

29
conectate la sistemul de informații medicale realizează verificare automat ă a dozelor si a
documentației pentru managementul medicației . Toate sistemele de monitorizare fiziologice sunt
în rețea , iar datele privind pacienții pot fi vizualizate pe alte sisteme de informare medi cală din
spital. De la biroul sau, Michael Sabot , MD, poate monitoriza EKG -ul unui pacient folosind un
sistem de vizualizare bazat pe Web, creat la spitalul Cedars -Sinai, care încorporează un produs
comercial ce oferă in timp real informații de la secția de monitorizare intensiv ă și alte secții ”[6].

4. 4 Datele din EMR [4]
• datele demografice ale pacientului (adresa, număr de telefon etc.);
• istoric medical, examinări , rapoarte de urmărire a sănătății și bolii;
• medicamente, lista de alergii, imunizare;
• rezultatele testelor de laborator;
• imagini radiologice, raze X, tomografie computerizata etc.;
• fotografiile de la endoscopie, laparoscopie sau fotografii clinice;
• informații despre medicamente, inclusiv reacții secundare și interferente;
• recomandări pentru situații medicale deosebite;
• înregistrarea listei de programări și a altor memento -uri;
• facturi;
• eligibilitate;
• testamente, împuterniciri .
Două clase specifice de date pot fi stocate in EMR [4]. Acestea se încadrează fie in categoria
monitorizare discret ă, fie în monitorizare continu ă
Monitorizarea discreta poate fi făcută într-o manier ă ad-hoc, asincron ă, pe când monitorizarea
continu ă a unui pacient se efectuează sincron. Marea parte a înregistrărilor pe suport de hârtie sunt
în curs de înlocuire cu înregistrări electronice, unde personalul medical poate introduce informații
manual sau și in mod automat.
Înregistrările medicale electronice sunt întreținut e de către instituția medicala și urmăresc
pacientul pe parcursul tuturor etapelor de diagnosticare și tratament. Mai mult, ace astă înregistrare
medical ă este accesibil ă întregului personalul autorizat. Un be neficiu evident al acestei abordări

30
este faptul c ă spre deosebire de înregistra rea pe hârtie , înregistrarea medicala electronic ă poate fi
accesat ă din mai multe locații diferite.
Pierderea de informații este minimalizată prin utilizarea fișelor medicale electronice, care
stabilesc o abordare uniformă pentru înregistrarea informațiilor pacientului, astfel încât fiecare
departament trebuie să se conformeze anumitor standarde în ceea ce privește tipul și calitatea
informațiilor înregistrate pentru fiecare pacient. În acest mod sunt evitate multe erori de înregistrare
și de transcriere.

4.5 Arhitectur a EMR
Rețeaua simplă este destinată ilustrării localizării relative a hard ware -ului într -o instituție care
conține un CPR (Computer -baset Patient Record). CPR este încorporat în următoarele module:
Web, Aplicație și server de Baze de Date. În această figură, modulul Web și serverele Aplicației
sunt combinate într -un singur eleme nt, o configurație potrivită pentru o întreprindere relativ mică
(nu mai mult de câțiva zeci de utilizatori simultan).
Serverul de Baze de Date oferă acces solicitărilor venite de la Aplicație în urmă interogările
inițiate de utilizatorilor prin inte rmediul unei instanțe Web a aplicației CPR.
Componente client sunt reprezentate prin simbolurile unor calculatoare laptop, wireless.
Pictograma unui client desktop arată posibilă utilizare de către persoane fizice în birouri (de
exemplu: de către med ici, asisten te)[1]. Se presupune că aplicația CPR este accesibilă pe Web astfel
încât clientul să o poată acces a și prin intermediul unei pagini de internet.
În figură este prezentat un client Web, care face o cerere de informații în sistemul CPR. C ererea
este primită de Web/Serverul de Aplicații printr -un simplu POST sau GET. Cererea este deservită
de serverul de aplicații, care, prin prelucrarea ei, determină datele care urmează să fie constitui te,
răspunsul la cererea utilizatorului, apoi transmit e datele la Serverul de Baze de Date, care
gestionează depozitul de date persistente într -un sistem accesibil prin intermediul Structured Query
Language (SQL) [10]. În cele din urmă, datele sunt preluate, s e întorc la Serverul de Aplicație pentru
prelucrare a, formatarea și generarea unei pagini Web care este afișată clientului. Diagrama va fi
extinsă pentru a include datele de intrare, care sunt stocate în cadrul CPR. Dispozitive le medicale
pot interfaț a cu CPR [3] printr -un format bazat pe standarde, precum HL7, sau poate comunic a într-
un format propriu utilizând un anumit tip de procesor intermediar pentru a traduce datele într -o
interfață corespunzătoare și universală.

31
Arhitectur a EHR reprezintă totalitatea componentelor structura le generice din care sunt
construite toate sistemele EHR definite în termenii unui model informațional sau prototip
informațional.
La momentul actual în domeniul automatizării ocrotirii sănătății sunt utilizate două arhitecturi de
bază a sistemelor EHR :
-Sisteme bazate pe un sistem EHR (bazat pe standardul SMV/ISO 18308) central, care stochează
date de la mai multe aplicații independente și care comunică prin mesaje (în baz a standardului
HL7) și ima gini (standardul DICOM) [4].
-Sisteme bazate pe modelul Poenar u, care presupune utilizarea Modelul Informațional de
Referință (RIM), configurat într -un mod flexibil de arhetipuri (Archetypes) și care este realizat din
setul de standarde EN13606/1 -5. Ide ea atractivă a conceptului RIM/Archetypes constă în crearea
unui procesor de obiecte din domeniul sănătății, similar cu procesorul Excel pentru formule și
tabele electronice.
Calitatea datelor (QA)
La oră actuală nu s -a descoperit un sistem software complex care să suporte atât validarea datelor,
cât și modelarea sistemului. Aceste două componente pot fi găsite doar separat, în sisteme diferite.
Erorile în date pot apare din cauza unor bug -uri în sistemul software. Accesul neautorizat la date și
multe alte situații pot fi surse de erori în date. Aceste deficite de siguranță pot fi cruciale pentru
calitatea datelor în anumite domenii, cum ar fi statistica, “clinical trials ” sau telecomunicații. În
plus, în anumite cazuri, chiar dacă datele sunt introd use cu erori, acestea nu poate fi modificate sau
respinse la intrarea în baz a de date. “Curățarea datelor ” (data cleaning) garantează calitatea datelor
după introducerea lor în baz a de date, eliminând din tabele sau modificând acele date care nu sunt
corec te/corespunzătoare/integrale.
Definiție și tipuri de reguli
Calitatea datelor este influențată de diverși factori interni sau externi. Deși constrângerile sunt
implementate în majoritatea sistemelor informaționale, erorile în cadrul datelor persis tă. În
contextul calității datelor sunt analizate toate caracteristicile recomandabile și de dorit ale datelor.
Ideea de bază în procesul de asigurare a calității datelor este calificarea datelor pentru a fi folosite
(“fitness for use ”)[5]. Că dovadă, cali tatea datelor mai este definită și lipsă defectelor intolerabile
în cadrul datelor.

32

5. Specificațiile aplicației
5.1. Schema si descriere a aplicației

Figura 5. Schema sistemului

33

În figura de mai sus este prezentată o schema bloc a sistemului. Aceasta este compusa din mai
multe module ce formează aplicația Java. Administratorul și utilizatorii pot accesa aplicația,
primind informații ca răspuns cerințelor aplicate. Aplicația este compusa din trei entități care
reprezintă modulele principale ale aplicației: management pacienți , boli și investigații . Datele sunt
salvate într-o bază de date de tip MySQL [10] unde se execut ă operațiile de creare, citire, update și
ștergere .
Scopul acestui sistem prezentat este de a simplifica munca cadrelor medicale. Această aplicație
pune la dispoziția medicilor o multitudine de informații despre pacienți , boli și investigațiile
efectuate.

5.2. Funcț ionalitățile aplicației
Aplicația adresată tuturor utilizatorilor interesați prezint ă următoarele funcționalități:
– Adăugarea unui nou pacient.
– Specificarea adresei la care locuiește pacientul.
– Modificarea datelor despre pacient, respectiv adresa acest uia.
– Introducerea unei noi boli despre care pacientul suferă .
– Modificarea ștergerea datelor despre pacient cum ar fi bolile de care suferă , respectiv investigații
medicale.
– Vizualizarea datelor despre un pacient.
– Vizualizarea datelor despre pacienți și bolile asociate.
5.3. Diagrama Gant t
Diagrama Gant t este folosit ă pentru a avea o organizare și o planificare eficient ă a etapelor de
dezvoltare a aplicației.

34
Diagrama Gant t se folosește pentru a planifica proiecte, evenimente și a muncii, în general. În
proiectele software apar probleme ce afectează dezvoltarea produselor cu o anumită frecvență,
cauza fiind aplicarea incorectă a metodelor mecanismelor existente.
Etapele desfășurării unui proiect sunt prezentate în diagrama de mai jos.

Figura 6. Diagrama Gant t
5.4. Analiza de risc
În caz c ă apar unele defecțiuni ale elementelor de interfațare care se pot defecta, se poate proceda
în următorul fel:
1. Riscul situațiilor imprevizibile:

35
Riscul de disponibilitate este riscul asociat pericolelor naturale, dezastrelor, căderilor de sistem
care pot conduce la pierderi definitive ale datelor, aplicațiilor , în absen ța unor proceduri de
monitorizare a activității , a planurilor de refacere în caz de dezastre.
Situațiile neprevăzute mai apar și în urma încărcării de imagini în format necorespunzător sau
introducerea de text cu caractere necunoscute de către sistemul de operare.
2. Defecțiunile la bazelor de date :
În cazul în care baza de date nu mai este funcțional ă, problema trebuie rezolvată într -un timp c ât
mai scurt, deoarece nu vor mai putea fi afișate evenimentele.
Baza de date nu pune la dispoziție un server de back -up la fel ca al aplicațiilor web. Dacă se
introduc spre exemplu obiective turistice care au informații asemănătoare , rezultă o defecțiune
deoarece vor exista obiective identice.
3. Riscul de infrastructură :
Se concretizează în faptul c ă nu este pusa la dispoziție o infrastructura a tehnologiei informației
(software, oameni și procese) pentru a susține nevoile necesare. Mai există riscul de a apărea
probleme legate sistemul de operare un exemplu fiind defectarea telefonului pe partea har dware.
4. Riscurile de conformitate:
Încălcarea regulamentelor ori a politicilor interne ale aplicației.

36
PUNCTE TARI PUNCTE SLABE

– Programator bine pregătit;
– Dispunerea de echipamente de
ultimă generație;
– Implementarea unor procese bine
definite;
– Promovare;
– Apariția recentă pe piață a firmei;
– Programul de lucru;
– Investiție mica;
OPORTUNITĂȚI AMENINȚĂRI

– Concurența foarte crescuta;
– Apariția unui software asemănător cu
acesta ;
– Atracție slaba a posibililor investitori.

6. Proiectarea si dezvoltarea platformei software

6.1 Integrarea Java & JESS

Cele mai importante trăsături a Jess-ului sunt acelea care îi permit sa fie integrat ușor cu Java. De
la codul Java, putem accesa toate părțile librăriilor Jess, astfel încât este foarte ușor sa integr ăm
Jess în orice aplicație Java, serve r, applet sau orice sistem. De asemenea, de la limbajul Jess,
întreaga putere a lui Java este în mod direct disponibil ă.

37
Acest capitol descrie cum putem crea obiecte Java, cum putem apela metodele sale si cum putem
interacționa și în alt mod cu Java fără să scriem cod Java.
Jess este un fel de limbaj de scripting pentru Java . În afară de folosirea Jess -ului pentru
construirea sistemelor bazate pe reguli, putem folosi Jess și pentru interacționarea cu API -ul Java
sau chiar pentru a construi aplicații întregi .
6.1.1 Crearea obiectelor Java

Deși listele sunt folositoare, nu sunt la fel de puternice ca si containerele Map si Set din colecțiile
API din Java. O list ă simpl ă este o bun ă alegere pentru o list ă de cumpărături , dar mai degrabă este
nevoie de ceva ca HashMap pentru a re ține un tabel cu pre țurile pentru cumpărături . HashMap
permite cu ușurință să vedem un preț a oricărui articol din tabel.
Funcția Jess new ne permite sa cre ăm instanțe a claselor Java. De exemplu, putem s ă creăm un
HashMap Java și să îl reținem într-o variabil ă cu următorul apel de funcție :

Jess> (bind ?prices (new java.util.HashMap))
<External -Address:java.util.HashMap>

Jess folosește tipul EXTERNAL_ADDRESS pentru obiectele Jess.Value care rețin obiecte Ja va
arbitrare. Când afișăm un tip EXTERNAL_ADDRESS, putem vedea un string care conține numele
clasei. În schimb ne putem aștepta ca Jess sa apeleze metoda Java to String asupra obiectului
conținut – dacă Jess face asta, oricum ,rezultatul ar fi confuz. Un obiect java.lang.Integer și o
valoare Jess de tipul RU.INTEGER acționează foarte diferit, dar dac ă Jess folosește toString pentru
a afișa obiecte EXTERNAL_ADDRESS, ambele scriu ca un număr .
În Java, putem evita folosirea prefixelor pachetelor cu cheia import. Jess are o funcție import pe
care o putem folosi pentru următoarele :

Jess> (import java.util.*)
TRUE
Jess> (bind ?prices (new HashMap))
<External – Address:java.util.HashMap>

38

Acest exemplu folosește caracterul “*” ceea ce înseamnă “import ă toate clasele din acest pachet ”,
dar se poate de asemenea importa doar o clas ă la un moment dat folosind întregul nume. Ca și în
Java, întregul pachet java.lang este importat implicit, astfel se pot crea ob iectele Integer si String
fără importarea pachetului în mod explicit.
Până acum, am folosit constructorul implicit HashMap. Desigur, se pot crea obiecte folosind și
constructorii altor clase. HashMap are un constructor care ia ca argumente Java int si Java float.
Dacă invoc ăm acest constructor și îi pasăm numere, Jess va face următoarele :

Jess> (bind ?prices (new HashMap 20 0.5))
<External – Address:java.util.HashMap>

Jess, ca orice cod Java, poate invoca doar constructorii publici ai claselor publ ice din alte pachete.
Dacă vrem ca Jess sa fie capabil s ă construiască instanțe a claselor pe care le definim, trebuie s ă
declar ăm si clasa și constructorii publici.
Când apelăm o metod ă Java, Jess convertește argumentele de la tipul de dat ă Jess la tip ul Java.
Când convertim astfel, Jess are unele idei cu tipul țintei (target type). Tipul țintei este tipul Java de
care este nevoie într-o situație dată. În exemplul cu HashMap, tipurile ținta sunt int si float, pentru
ca aceștia sunt tipurile parametrilor formali a singurului constructor HashMap care ia dou ă
argumente. Când pasăm un argument la un constructor sau metod ă Java, Jess are obiectul
java.lang.Class care reprezintă tipul parametrului formal și un obiect java.Value care conține
valoarea pe care am pasat -o și vrea s ă întoarcă conținutul lui Value în ceva asignabil tipului numit
de Class. Deci simbolul TRUE poate fi pasat unei funcții care cere un argument boolean, sau uneia
care are un argument de tipul String, și apelul a r avea succes în ambele cazuri.

6.1.3 Apelarea metodelor Java

Daca avem o referință spre un obiect Java într-o variabila Jess, putem invoca orice metod ă a
obiectului folosind funcția call. De exemplu HashMap.put asociază o cheie cu o valoare, și

39
HashMap.get caută o valoare după o cheie data. În exemplul de mai jos, cheile sunt numele
articolului de cumpărături si valorile sunt pre țurile:
Jess> (call ?prices put bread 0.99)
Jess> (call ?prices put peas 1.99)
Jess> (call ?prices put beans 1.79)
Jess> (call ?prices get peas)
1.99

Primul argument al funcției call este obiectul Java, și al doilea argument este numele metodei
invocate. Celelalte argumente a lui call sunt argumentele pe care le pas ăm metodei Java.
Argumentele sunt convertite la tipul Java.
În acest exemplu am ignorat valoarea returnat ă de metoda HashMap.get si am permis lui Jess
doar s ă o afișeze . Adesea, totuși , dorim s ă facem ceva cu tipul returnat: s ă îl legam la o variabil ă
sau sa apel ăm alt ă metodă asupra lui. Jess convertește valorile returnate a metodelor Java în tipuri
Jess.

6.1.4 “ Nesting ”ul apelul funcțiilor și “shortcut -ul”
Simbolul call din următorul exemplu este puțin distras:
(call ?prices put bread 0.99)
De fapt nu este mai bun decât codul Java echivalent:
map.put( “bread ”, new Double(0.99));
(De fapt codul Jess este mai scurt). Dar totuși , funcția call pare încărcata cu “bagaje ”. Partea bun ă
este ca Jess ne permite s ă omitem:
(?prices put bread 0.99)
Când primul element a unui apel de funcție este un obiect Java, Jess își asum ă o metod ă pentru a
include simbolul call si invoc ă o funcție asupra obiectului. Acest lucru funcționează chiar dac ă
primul element a apelului funcției este un alt apel de funcție :
((bind ?prices (new HashMap)) put bread 0.99)
Aceasta linie de cod creează un HashMap, îl leagă la o variabil ă, si adaugă o pereche
nume/valoare. Trebuie sa fim atenți la apelul funcțiilor “nesting ” în acest fel; combinând logic

40
operații separ ate într-o singura linie de cod ne putem îngreuna înțelegerea problemei. Pentru multe
probleme call este opțional . Putem s ă îl ignor ăm când apelăm metode statice.

6.1.5 Apelarea metodelor statice
Metodele statice a unei clase din Java sunt acele metode care pot fi apelate fără referință la un
obiect specific. Și în codul Java și în codul Jess, putem folosi doar numele unei clase Java pentru
a invoca orice metod ă static ă a sa. Un bun exemplu este metoda java.lang.Thread.sleep:
Jess> (call Thread sleep 1000)
(pause for one second)
Jess>

Nu este nevoie s ă folosim întregul nume java.lang.Thread pentru ca clasele din pachetele
java.lang sunt în mod implicit importate în Jess.
Când apelăm o metoda static ă, trebuie s ă includem numele funcției call; cel mai adesea call este
folosit pentru invocarea metodelor statice. Jess in clude alte funcții , similare cu call, pentru a ne
ajuta s ă invocam alte categorii de metode.

6.1.6 Apelarea metodelor get si set
Obiectele Java speciale numite JavaBeans joaca un rol important în Jess. Astfel, Jess include
multe tool -uri pentru a lucra cu ele. Un ul din aceste tool -uri este o pereche de metode pentru a
simplifica accesul la datele lor. Metode care seamănă cu următoarele de mai jos sunt comune în
majoritatea limbajelor orientate pe obiecte:
public String getName() {
return name;
}
public void setName(String n) {
name = n;
}

41
Adesea sunt numiți accesatori și mutătorii sau getteri și setteri. Sunt foarte comuni în Java și
formează o parte important ă a specificației JavaBeans. Multe din clasele bibliotecilor Java ( în
special din bi bliotecile grafice) folosesc aceast ă metod ă numind -o convenție .
Jess include funcțiile set si get, care pot fi folosite ca o alternativ ă la call pentru setteri si getteri.
Următoarele perechi de apeluri de funcții sunt echivalente:
Jess> (bind ?b (new j avax.swing.JButton))
<External – Address:javax.swing.JButton>
Jess> (?b setText “Press Me ”) ;; sau…
Jess> (set ?b test “Press Me ”)

Jess> (?b getText) ;; sau …
“Press Me ”
Jess> (get ?b text)
“Press Me ”

Numele metodelor getter și setter includ un nume propriu, care este text în acest exemplu. Numele
propriu este pasat ca argument secundar funcțiilor set și get. Pentru a obține numele propriu, trebuie
să mutam prefixul din numele metodei Java și să transform ăm litera majuscul ă inițială a restului
de nume în liter ă mică. Singura excepție este pentru nume ca getURL, unde numele propriu este
URL cu toate literele majuscule. Aceast ă convenție este aceeași ca și cea folosit ă de specificația
JavaBeans.

6.1.7 Utilizarea tablourilor
Tabelul cu pre țurile cumpărăturilor poate fi și o list ă simpl ă de cumpărături . Putem folosi Map
pentru colecția de chei si apoi s ă convertim aceea colecție într-un tablou. Dac ă putem converti acel
tablou la o list ă simpl ă în Jess, putem s ă recre ăm lista de cumpărături .
Jess convertește automat tablouri în liste simple (Values de tipul RU.LIST). Putem folosi metoda
toArray din java.util.Collection pentru a extrage toate cheile din hashMap într-o lista Jess:

Jess> (bind ?grocery -list ((?prices keySet) toArray))

42
(bread peas beans)

Dacă dorim s ă punem lista de cumpărături într-un meniu pop -up, putem s ă consider ăm lista de
articole ca un argument al constructorului clasei javax.swing.JComboBox. JComboBox are un
tablou ca și argument al constructorului, dar Jess convertește automat lista simpl ă înapoi într-un
tablou:

Jess> (import javax.swing.JComboBox)
Jess> 9bind ?jcd (new JComboBox ?grocery -list))
<External -Address:javax.swi ng.JComboBox>

Acest sistem lucrează bine pentru tablouri mici, dar convertirea între tablouri și liste este
ineficient ă pentru tablouri mari, pentru c ă structura de date Jess care reprezintă lista simpl ă trebuie
creat ă sau distrus ă la fiecare conversie. O metod ă mai buna de lucru cu tablourile Java largi este
planificarea unei versiuni Jess. Între timp, dac ă este nevoi e să se lucreze cu tablouri mari în
programele Jess, se poate scrie codul în Java și apoi s ă se apeleze din Jess.
De asemenea Jess nu are o interfaț ă special ă pentru lucrul cu tablouri multidimensionale , deci,
din nou, codul Java poate fi necesar. Se pot scrie și funcții Java normale și apoi s ă le apel ăm folosind
tehnici descrise mai sus, sau putem folosi funcții scrise în Java pentru a extinde însuși limbajul
Jess.
6.1.8 Cum alege Jess între metodele supraîncărcate
În Java nu se poate stoca un float într-un HashMap, dar în Jess se poate stoca un float – pentru c ă
Jess convertește automat numărul pe care noi îl furniz ăm într-un java.lang. Double . În cele mai
multe cazuri, aceast ă conversie este folositoare; dar ocazional cauzează probleme. O problem ă ar
fi când avem nevoi e sa apel ăm o metod ă dintr-un set de metode Java supraîncărcate .
Un nume de metod ă Java se spune ca este supraîncărcat ă dacă metode multiple cu același nume,
dar cu o lista de argumente diferite sunt disponibile pentru același obiect. Un exemplu îl reprezintă
metodele supraîncărcate a lui java.io.PrintWriter.println. Toate aceste metode apar în clasa
PrintWriter:
void println()

43
void println(Boolean x)
void println(char x)
void println(char[] x)
void println(double x)
void println(float x)
void println(int x)
void println(long x)
void println(Object x)
void println(String x)

Când apelăm o metod ă supraîncărcată în codul Java, compilatorul Java alege cea mai specific ă
metod ă supraîncărcată aplicabil ă.
Jess este mai relaxat în a alege între supraîncărcări pentru c ă nu trebuie s ă aibă strict același tip
de informație pe care trebuie s ă îl aibă Java. Un exemplu simplu este: uitând -ne la lista de metode
println supraîncărcate , putem observa versiunea și pentru double și pentru float. Jess are doar un
singur tip de float.
Când apelăm o metod ă supraîncărcată ca println, Jess se uit ă la fiecare supraîncărcare în parte,
încercând sa potrivească tipul parametrului metodei cu tipul argumentelor date. Prima
supraîncărcare pe care o găsește Jess care poate fi invocat ă cu lista de argumen te, va fi apelat ă. Jess
nu caută după o buna potrivire , ci folosește prima potrivire găsit ă.
Adesea, nu contează care set de metode supraîncărcate sunt apelate , un set de metode
supraîncărcate fac de obicei toate același lucru. Acesta este cazul lui ja va.io.PrintWriter.prin tln.
Uneori, se poate s ă dorim o anumita supraîncărcare a unei metode, dar s ă nu poată fi posibil. De
exemplu, dac ă pasăm stringul “TRUE ” unei metode Java care este supraîncărcată să ia fie
argumentul boolean, fie String, este imposibil s ă prevedem care supraîncărcare o va alege Jess. În
aceste cazuri, putem recurge la folosirea unei clase explicite. De exemplu, s ă presupunem c ă în
acest caz dorim s ă invoc ăm supraîncărcarea boolean, d ar Jess apelează pe cea String; creând și
pasând obiectul java.lang.Boolean ar trebui s ă se rezolve problema, pentru c ă Jess va converti
automat java.lang.Boolean la boolean și nu la String.

44
Uneori apelarea metodelor Java nu este suficient ă – se poate s ă fie nevoie s ă se lucreze direct cu
o variabil ă a unui obiect membru sau cu variabile member statice a unei clase. Jess ne permite acest
lucru.

6.1.9 Accesarea datelor membre Java
Unele clase Java au variabile publice cu care s ă fie nevoi e să lucrăm. Uneori sunt obiecte ca
System.out. Ele sunt constante statice ca MAX_PRIORITY în java.lang.Thread sau NORTH în
java.awt.BorderLayout. Bineînțeles , unele clase au variabile membre publice, ca x și y membri ai
java.awt.Point.
Instanțele unei vari abile sunt membre a unei clase care aparțin unor obiecte individuale; fiecare
obiect are propria sa copie a unei instanțe de variabil ă. Jess poate accesa instanțe publice a
obiectelor Java folosind funcțiile get-member și set-member. În acest exemplu, un o biect Point este
alocat și membrii x si y sunt setați și apoi citiți:
Jess> (bind ?pt (new java.awt.Point))
<External – Address:java.awt.Point>
Jess> (set -member ?pt x 37)
37
Jess> (set -member ?pt y 42)
42
Jess> (get -member ?pt x)
37

Funcțiile set-memb er și get-member funcționează și pentru variabilele de clas ă. Variabilele de
clasă sunt numite si variabile statice în Java. Putem accesa variabilele de clas ă folosind numele
unei clase în locul unui obiect ca prim argument pentru set -member și get-member:

Jess> (get -member Sistem out)
<External – Address:java.awt.Point>
Jess> (get -member java.awt.BorderLayout NORTH)
“North ”

45

6.1.10 Excepții
Metodele Java pot semnala erori prin aruncarea unei excepții . O excepție este doar un obiect Java,
și se intenționează a fi tratat ca un mesaj de la codul eșuat la apelant. Când un constructor sau o
metod ă Java arunc ă o excepție , Jess primește sau prinde mesajul și îl face disponibil utilizatorului.
Când Jess prinde o excepție într-o funcție Jess sau metod ă Java, acțiunea sa implicit ă este s ă
printeze un mesaj detaliat în consol ă, incluzând una sau dou ă “stack traces ”. De fiecare dat ă când
se apelează o metod ă care ar putea arunca o excepție , ar trebui s ă se furnizeze un handler pentru a
executa un răspuns . Se poate folosi funcția try. De exemplu, s ă folosim funcția parseInt din clasa
java.lang.integer care arunc ă NumberFormatException dac ă argumentul nu poate fi parsat la un
întreg :
Jess> (deffunction parseInt (?string)
(try
(bind ?i (call Integer parseInt ?string))
(printout t “The answer is ”?i crlf)
catch
(printout t “Invalid argument ” crlf)))
TRUE
Jess> (parseInt “10”)
The answer is 10

46

7. Proiectarea și dezvoltarea unei aplicații CRUD

Aplicațiile CRUD se ocup ă cu procesarea datelor aferente unei aplicații software care necesit ă
salvarea persistent ă a datelor. Salvarea persistent ă a datelor este necesar ă întrucât la închiderea
aplicației datele trebui esc salvate, iar apoi la repornire datele trebui esc din nou reîncărcate .
Acronimul CRUD [14] este prescurtarea pentru CREATE, READ, UPDATE , DELETE .

7.1 Conexiunea la baza de date

Conexiunea la baza de date se realizează cu ajutorul unei clase de tip Singleton așa cum este cea
de mai jos:

Figura 7. Conexiunea la baza de date

47
7.2 Clasa Pacient

Figura 7. Diagrama de clas ă pentru Pacient

48
Func ția care obține toți pacienții din baza de date este ilustrat ă mai jos:

Figura 8. Diagrama de secvenț ă pentru inserarea unui pacient

49
Pentru a insera un pacient se folosește funcția definit ă mai jos astfel:

Figura 9.

50
Pentru modificare vom utiliza:

Figura 10. Modificare pacient

51

Concluzii

Sisteme le inteligente medicale utilizează foarte multe date, cel mai adesea destul de eterogene
atât ca tip c ât și ca semnificație de lucru. Importante sunt în primul rând datele demografice. Aceste
date au fost prelucrate în aplicația software dezvoltat ă.

Înregistrările medicale ne oferă o privire de ansamblu a întregului act medical. S ă utilizam o
astfel de multitudine de date nu era scopul nostru și nici nu avea vreo relevan ță, întrucât aplicația
dezvoltat ă este un prototip, și are mai mult scop de demo , și nu de produs final cea urmează a fi
comercializat ă în industria software de profil.

Java se integrează ușor cu bazele de date MySQL [12], mai ales în prezenta Framework ului
Hibernate [8]. Acesta permite un lucru facil cu datele citite, introduse sau modificate. De asemenea
Java se integrează ușor cu motorul de inferenț ă JESS. Acest motor de inferenț ă permite specificarea
unui set de reguli care asigur ă „inteligen ță” aplicației . În concluzie putem spune c ă utilizarea
împreuna a limbajului Java alături de Hibernate, MySQL [10] si JESS este o rețetă de succes .

52

Bibliografie
[1] Release 1.0.2 openEHR Speci fications, openEHR, 2008.
https://specifications.openehr.org/releases/1.0.2/roadmap.html
[2] ASRO. Asociația de standardizare di Romania. 2007. https://www.asro.ro/
[3] International Medical Informatics Association. The IMIA Vision. 2011. https://www.imia –
medinfo.org/new2/
[4] Traducere: Maria Bratu. Comunicat de presa ISO nr. 1308/2010. ASRO, 2010.
https ://standardizare.wordpress.com/2010/03/30/iso -a-elaborat -un-nou-standard -pentru -o-
utilizare -sigura -a-simbolurilor -referitoare -la-dispozitivele -medicale/
[5] International Electrotechnical Commission. About the IEC. 2011. https://www.iec.ch/about/
[6] CPR -ontology. Introduction. Google code, 2011.
https://code.google.com/archive/p/cpr -ontology/wikis/CPROverview.wiki
[7] https://www.rivm.nl/en/life -cycle -assessment -lca/recipe
[8] WIKIPEDIA, Hibernate
[9] Fundamentals of DataBase Systems, 6th Edition, Elmasri Navathe
[10] Learning MySQL 2nd Edition, Alan Beaulieu
[11] Wikipedia, https://ro.wikipedia.org/wiki/Sistem_de_gestiune_a_bazelor_de_date
[12] Tutorialspoint, https://www.tutorialspoint.com/mysql/index.htm
[13]http://www.scritub.com/stiinta/informatica/baze -de-date/B aze-de-date-
relationale83395.php
[14] https://sites.google.com/site/bazededatemementoadit/5 -baze-de-date-nerelationale
[15] Wikipedia, https://ro.wikipedia.org/wiki/Inteligen%C8%9B%C4%83_artificial%C4%83
[16] https://en.wikipedia.org/wiki/ASIMO
[17] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.3232&rep=rep1&type=pdf
[18] https://www.rivm.nl/en/life -cycle -assessment -lca/recipe
[19]https://www.researchgate.net/pu blication/221100494_ViKI_a_virtual_keyboard_interface_for
_the_handicapped

DECLARAȚIE DE AUTENTICITATE
A
PROIECTULUI DE FINALIZARE A STUDIILOR

Titlul proiectului __Aplicație informatică în domeniul medical_________
_____________________________________________________________

Autorul proiectului _____________________________________________

Proiectul de finalizare a studiilor este elaborat în vederea susținerii examenului
de finalizare a studiilor organizat de către Facultatea
_______________I.E.T.I._________________________ din cadrul Universității
din Oradea, sesiunea________iulie_________ a anului universitar
__2019___________.
Prin prezenta, subsemnatul (nume, prenume, CNP)____________ _______ __
_______Julea ,_Daniel, 1730319343238 _____________________________,
declar pe proprie răspundere că acest proiect a fost scris de către mine, fără nici un
ajutor neautorizat și că nici o parte a proiectului nu conține aplicații sau studii de caz
publicate de alți autori.
Declar, de asemenea, că în proiect nu există idei, tabele, grafice, hărți sau alte
surse folosite fără respectarea legii române și a convențiilor internaționale privind
drepturile de autor.

Oradea,
Data Semnătura