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

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 LICENȚĂ

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

TIMIȘ OARA
2019

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

APLICAȚII ALE SISTEMELOR
INTELIGENTE ÎN MEDICINĂ

COORDONATOR ȘTIINȚIFIC ABSOLVENT: [anonimizat]

2019

Cuprins:
1.Introducere …………………………………………………………………………………………………………………..5
1.1Tema proiectului ……………………………………………………………………………………………………..5
1.2 Motivatia ……………………………………………………………………………………………………………….6
1.2Structua lucrarii ……………………………………………………………………………………………………….6
2.Sisteme inteligente …………………………………………………………………………………………………………8
1.1 Definitia sistemelor inteligente ………………………………………………………………………………..8
1.2 Robotul ASIMO ……………………………………………………………………………………………………..9
1.3 DEVEX – Sistem expert de consiliere privind schimbul valutar …………………………………..12
3.Sisteme inteligente medicale …………………………………………………………………………………………19
2.1 Proiectul RECIPE …………………………………………………………………………………………………19
2.2 Proiectul VIKI:A Virtual Keyboard Interface for the Handicapped ………………………………22
2.3 Proiectul Autonomous Life ……………………………………………………………………………………..23
3. Date medicale electronice …………………………………………………………………………………………..25
3.1 Concepte generale …………………………………………………………………………………………………25
3.1.1 Definirea principalelor concepte le gate de datele medicale electronice: ………………….25
3.1.2 Electronic Health Record (EHR) – Prezentare generală …………………………………………..28
3.2. Componentele sistemului de administrație …………………………………………………….30
3.2.1 Componentele sistemului de laborator ……………………………………………………………….30
3.2.2 Componentele sistemului de radiologie ……………………………………………………….31
3.2.3 Componentele sistemului de farmacie ………………………………………………………..31
3.2.4 Ordine medicale computerizate …………………………………………………………………31
3.3 Documentatia medicală ………………………………………………………………………………….32
4. Specificațiile aplicatiei …………………………………………………………………………………………………36
4.1. Schema si descriere a aplicației ………………………………………………………………………………36
4.2. Funcționalitățile aplicației ………………………………………………………………………………………37
4.3. Diagrama Gantt …………………………………………………………………………………………………….37
4.4. Analiza de risc ………………………………………………………………………………………………………38
5.Proiectarea si dezvoltare a platformei software …………………………………………………………….40
5.1 Integrarea Java & JESS …………………………………………………………………………………………..40
5.1.1 Crearea obiectelor Java …………………………………………………………………………………….40
5.1.3 Apelarea met odelor Java …………………………………………………………………………………..42
5.1.4 “Nesting”ul apelul functiilor si “shortcut -ul” ………………………………………………………43
5.1.5 Apelarea metodelor statice ………………………………………………………………………………..43

5.1.6 Apelarea metodelor get si set …………………………………………………………………………….44
5.1.7 Utilizarea tablourilor ………………………………………………………………………………………..45
5.1.8 Cum alege Jess intre metodele supraincarcate ……………………………………………………..46
5.1.9 Accesarea datelor membre Java …………………………………………………………………………47
5.1.10 Exceptii ………………………………………………………………………………………………………..48
5.3. Proiectarea si dezvoltarea unei aplicatii CRUD ………………………………………………………..49
5.3.1 Conexiunea la baza de date ………………………………………………………………………………49
5.3.2 Clasa Pacient ………………………………………………………………………………………………….50
5.3.3 Clasa Repositoy ……………………………………………………………………………………………..55
Concluzii ……………………………………………………………………………………………………………………….56
Bibliografie …………………………………………………………………………………………………………………..57

A comentat [CBC1]:

1. Introducere

Evolutia tehnologica din ziua de astazi, precum si procesul de miniaturizare a diferitelor device-
uri sunt prezent e in aproape domeniile de activitate de la servicii pu blice pana la arta si cultura.
Acest proces este dublat de introducerea in fiecare dispozitiv a unuia sau mai multor module care
asigura autonomia si / sau un oarecare grad de inteligenta. Este asadar u n proces continu care are
loc care asigura independen ta si functionarea la standarde inalte.

Acest proces se desfasoara in foarte multe domenii de activitate, mai ales in cel al serviciilor
publice, si chiar si in domeniul asigurarii sanatatii publice. Sistemele inteligigente medicale sunt
din ce in ce mai prezente in cabinetele medicale, si mai ales in sectiile diferitelor spitale, desi
cele mai multe cadre medicale sunt sceptice la utilizarea acestora.

Daca pana nu de mult trebuia sa mergeme personal la casa de asigurari de sanatate pentru orice
problem a, astazi multe dintre ele se pot rezolva simplu prin accesarea portalului casei. Cardul
national de sanatate a simplificat mult o mare parte dintre procedurile care aveau loc in sistem si
permite docto rilor sa colaboreze pentru a indica tratamente de buna calitate.

1.1 Tema proiectului

Tema proiectului de licenta este legata de introducerea elementelor de inteligenta aritificiala in
sistemele medicale dezvoltate in mod curent. Avem in vedere sistemele i nteligente medicale
orientate spre procesarea datelor medicale.

Inregistrarile medicale electrtonice si procesarea lor constituie principalul obiectiv de cercetare al
acestei lucrari de licenta. Ne intereseaza ce fel de date introducem in aceste inregis trari, si de
asemenea prezentam diferite metode si con cepte derivate din acesta. Toate aceste date sunt
inserate in baze de date care apoi sunt procesate de catre o aplicatie Java. Tema proiectului se

refera asadar la ce fel de date introducem si cum reali zam procesarea elementara a acestora.
Procesarea elementara inseamna operatiile CRUD (Create, Read, Update, Delete) care se
realizeaza asupra datelor.

1.2 Motivatia

Aplicatia software a fost realizata pentru a vedea cum se pot introduce date simple des pre un
pacient intr -o baza de date si cum acestea se p ot procesa in mod inteligent. Scopul a fost de a
studia diferite procese cum au loc in contextul utilizarii anumitor tehnologii. Noi utilizam o baza
de date MySQL iar datele sunt preluate si operate via frameworkului Hibernate. Aceste date
obtinute devin f apte JESS, care apoi sunt prelauate de catre motorul de inferenta JESS pentru a fi
expuse sub diferite forme de procesare clientului.
Spre deosebrire de alte aplicatii aceasta combina doua tehnologii: programarea orientata obiect si
programarea bazata pe reguli. Programarea bazata pe reguli este intalnita in cadrul motorului de
inferenta dezvoltat in JESS care opereaza asupra datelor. Java este utilizata acolo unde se preiau
datele si se ofera spre pro cesare ssitemului inteligent oferit de JESS. Datele su nt preluate sau
introduse intr -o baza de date MySQL.

1.3 Structua lucrarii

Lucrarea se intinde pe aproximativ 60 de pagini si are cinci capitole.
Primul capitol ne prezinta conc eptul de sistem in teligent, si de asmenea ilustreaza cu exemple
din robot ica si economie, unde poate fi utilizata inteligenta artificiala in ziua de astazi.
Cel de -al doilea capitol ne prezinta in detaliu trei sisteme inteligente dezvoltate pentru un context
medical sau d e asigurare a igrijirii persoanelor la domiciliu. Este v orba de aplicatii complexe
care au interfata web, interfata pentru dispozitive mobile, acces la baze date, dar prezinta inovatii
si la nivel de dezvoltare hardware.
Al treilea capitol este o incursiune in lumea sistemelor medicale, si se axeaza pe inregis trarile
medicale, ce contin ele, si cum sunt standardizate datle introduse.

Al patrulea capitol este legat despre cum a fost devoltat proiectul nostru de licenta, ce proceduri
de dezvoltare 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 sa poata dezvolta ceva similar.

2. Sisteme inteligente

2.1 Definitia sistemelor inteligente
Mai in tai, in vederea intelegerii ce califica un sistem a fi inteligent, vom discuta atat
conceptele "Inteligenta" cat si "Sistem". Exista foarte multe definitii a ceea ce inseamna
inteligenta. "Inteligen ta este facultatea de a descoperi proprietatile obiectelor si fenomenelor
inconjuratoare cat si a relatiilor dintre acestea, dublata de posibilitatea de a rezolva probleme noi .
"(https://ro.wikipedia.org/wiki/Inteligen%C8%9B%C4%83 ).O alta definitie se refera l a abilitatea
de a realiza un obiect iv. Cu cat un siste m poate sa ajunga la obiectiv mai rapid cu atat se
considera a fi mai inteligent. In acest caz, putem vorbi despre capacitatea de a invata sa faca
acest lucru.
Daca ar fi sa exprimam simplu ce inseamna un sistem , putem aserta ca un sist em este o
parte fizica limitata a universului.
Analizand cele doua concepte amintite mai sus, se poate exprima ce inseamna de fapt un
sistem inteligent .Una din cele mai complete definitii asupra ce inseamna un sistem int eligent ii
apartine lui N.V .Findle r: "Un sistem este considerat ca are proprietatea de inteligenta, pe baza
comportarii sistemului, daca se poate adapta singur la situatii noi, are capacitatea de a rationa, de
a intelege legaturile dintre fapte, de a desco peri intelesuri si de a recunoaste adevarul. De
asemen ea ne asteptam ca un sistem inteligent sa invete, deci sa- si imbunatateasca performantele
pe baza experientei trecute".
Avand in vedere asertiunile de mai sus, putem spune in cuvinte simple ce inseamna un
sistem inteligent. Asadar, un si stem inteligent es te un sistem care are obiective proprii si gandeste
in vederea ajungerii la obiectiv, luand decizii bazate pe experientele avute anterior, invatand
altfel spus prin generalizare.
Unele exemple de sistem e inteligente ar putea fi: Google, r oboti, persoane, o afacere etc.
In domeniul IT, de o perioada buna de timp au fost concepute programe(aplicatii) care
sunt sisteme inteligente complete. Totusi, nu era suficient ca sistemul inteligent doar sa afiseze A comentat [DJ2]: In bibliografie

informatii pe un dispozitiv de iesire cum ar fi monito rul. Se impun niste sisteme complete care sa
functioneze in afara calculatorului, ca niste sisteme de sine statatoare in cadrul uman. Asa a
aparut conceptul de roboti. V om discuta in cele ce urmeaza asadar despre robotii humanoizi.
2.2 Rob otul ASIMO
Prob abil unul dintre cei mai populari robotoi humanoizi este ASIMO conceput de
compania Honda. Motivul pentru care este printre cei mai populari este probabil ca arata foarte bine din punct de vedere vizual .

Fig . 1

A comentat [CBC3]: Figurile trebuiesc numerotate

Am aratat ca un sistem in teligent are scop ul de a -si indeplini obiectivele. In cazul nostru
particular, obiectivul sistemului nostru, robotul humanoid, este acela de a se comporta cat mai
natura l intr -un mediu uman, adiaca sa interpreteze si sa imite comportamentul uman.
Asimo nu face exceptie, s i reuseste sa integreze multe functionalitati ce ajuta la
interpretarea lucrurilor din afara sistemului ce conduc catre luarea unor decizii.In cele ce v or
urma vom prezenta cateva dintre acestea.
Una d intre ele este "motion detecting", ad ica cu ajutorul i nformatiilor vizuale receptate de
catre camera, acesta detecteaza motiunea unuia, sau a mai multor obiecte straine sistemului.
De asemenea, in functie de informatia captata, acesta o interpreteaza, lu and o decizie
asupra modului de a rea ctiona la informa tia primita. Astfel, humanoidul reactioneaza nu doar
cand primeste o comanda vocala, ci si cand identifica un comportament uman cunoscut. Astfel,
cand o persoana va intinde mana sau va face cu mana, chiar si cand indica spre ceva robotul va
raspunde in conformitate cu actiunea analizata.
De asemenea, robotul stie sa analizeze mediul inconjurator si obiectele din jur astfel incat
miscarile pe care le va f ace sa nu puna in pericol nici pe el, nici persoan ele din jur(se fereste de
ciocniri, urc a pe plan incli nat,scari etc).
Sistemul de distingere a sunetelor a fost de asemenea imbunatatit de- a lungul timpului,
acesta facand deosebire intre sunete de mediu s i sunete umane. Astfel, in cazul in care o persoan a
i se adreseaza, humanoidul priveste s pre persoana. U n alt exemplu ar fi acela cand are loc un
sunet puternic neasteptat, cum ar fi acela cand tuna sau are loc o coliziune intre 2 obiecte, robotul atintind u-si privirea spre zona de interes. Mesajele inter ceptate sunt analizate si raspunde fie prin
miscari ale corpului ( miscari ale capului, maini etc.) fie verbal. Din acest punct de vedere poate
fi asemanat cu un chatterbot avansat.
Totodata, una dintre tr asaturile sale uimitoare este aceea de a distinge trasaturile fetei,
chiar si a unei persoane care se mi sca. In momentul in care poarta o conversatie cu cineva, acesta
ii analizeaza trasaturile fetei si va recunoaste persoana urmatoarea data cand va vorbi cu ea dupa nume(in 2002 putea retine maxim 10 pers oane iar acum capacitatea de stocare a cr escut).

Fig.2

Bineinteles, toate acestea se refera la modul in care robotul stie sa interpreteze m ediul
inconjurator, evenimentele si persoanele. Pe de alta parte, s -a investit foarte mult in facilitarea
miscariilor robotului si a le face cat mai asemanato are cu miscar ile corpului uman. Pentru
aceasta s -au avut in considerare multe aspecte tehnice cum ar fi pastrarea centrului de greutatea
de-a lungul miscarilor, ba s -a tinut seama si de influenta degetelor de la picioar e in pastrarea
echilibrului. Aici pu tem aminti si de incheieturile care au fost create pentru a- i da libertate de
miscare. Acestea sun t cunoscute ca "unghi de libertate" si sunt plasate in zona gatului, maini si
picioare.
De asemenea, humanoidului ii sunt incorporati o multime de sonzori pe ntru a interpreta
modul in care ar trebui sa faca miscarea. Exemple de astfel de senzori sunt senzorii de viteza(care analizeaza viteza cu care ar trebui sa se deplaseze robotul), senzori la suprafata
pamantului si senzo ri ultrasonici in zona mediana(acestia ajuta la i nterpretarea mediului
inconjurator si crearea unei harti in memoria robotului a mediu lui in care acesta se afla) si
senzori ai unghiului incheiturilor(pentru controlul miscarilor).

Crearea unui sistem int eligent ca acesta a fost cu atat mai grea cu cat tine cont si de
pamantul pe care calca, conditii meteo(vant), in pastrarea unei pozit ii de echilibru si a mentine o
viteza de miscare corespunzatoare cerintei de a se asemana comportamentului uman.

2.3 DEV EX – Sistem expert de consiliere pri vind schimbul valutar

Sistemul expert DEVEX a fost creat pentru a va da sfaturi în legatur ă cu schimbul valutar
si tranzacțiile comerciale internaționale. A fost dezvoltat la banca Čačanska în Cacak, 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 subdome niu 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 s 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 do resc să facă schimb de informații sau să efectueze
operațiuni bancare rapid și cu acuratețe sunt incluse în Net SWIFT. SWIFT reprezinta 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 sistemel e de informații ale
băncilot 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 reprez entate ca in graficul de dependență din care urmeaza. Clientul este o
persoana fizică sau juridică, sau un cetățean străin. Prima banca este coordonator de servicii in
care clientii au conturi în valută, si care aceștia își mențin depozitele în valută și c u ajutorul
carora efectuează operațiuni diferite. Aceste bănci sau orice alte i nstituții financiare care sunt
autorizate sa efectueze aceste sarcini au propriile lor conturi valutare la bănci străine, prin care
tranzacțiile sunt efectuate la cererea unui c lient.

Firmele străine, care acționează ca importatorii sau exportatorii de bu nuri și servicii, au
de asemenea conturi într -o bancă străină, iar in acest fel acestea pot participa la schimbul valutar
al băncii de start. Este necesar, de asemenea, o bancă de legătură în lanțul de tranzacție între
banca de start și banca străină.
Prin aceasta banca de legătură, se efectuează intregul 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.

În unele tranzacții de afaceri cu moneda stăină toti participanții menționați mai sus pot
apărea, în timp ce numai unii dintre ei pot participa doar la unele tr anzacții. Plata către o țară
străină este o situație în care toți participanții ia parte. De exemplu, dacă un client trimite o cerere
de plată la o bancă pentru o firmă străină, banca de start, procesează, oferă resurse, și 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.
Cumpararea de valuta la ICM ( Inter-banking Currency Market ) se efectuează numai între
banca de start si banca conexiune: banca conexiune proceseaza 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 foloseste DEV EX), î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 e ste destinat pentru a ajuta angajații băncilor care au de efectuat diferite sar cini
legate de tranzac țiile externe către o anumită bancă. Principalul motiv pentru construirea acestui
sistem a fost faptul că tranzacțiile străine reprezintă un grup de sarcin i, care sunt foarte
importante în practică, dar în același timp, sunt extrem d e complexe. Este foarte dificil să fie
implementate intr -un program procedural sau sa 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ă motive le 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 organi zații financiare. Subsistemul este responsabil pentru mai
multe sarcini (tran zacț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 exact, sarcinile acestui
subsist em includ schimbul valutar cu țări 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ă afecteaze 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 dezvoltarii
sistemelor de informații financiare.
În plus, operațiunile de schimb valuta r se fac cu o monedă străină la valoar ea 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 de start poate lucra cu mai multe rate de
schimb diferi te (cum ar fi vânzarea valutei pentru numerar, cumpărarea valutei străină cu 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 sp ecifică.
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 in considerare mai mulți factori, în
amanunt:
– Ce surse asigura efectuarea plăților? Are firma un depozit propriu in cont? Dacă nu,
atunci firma poate achiziționa valută de la banca, prin unele firme care ruleaz ă afaceri prin

intermediul aceleiași banci, sau de la IC M, în funcție de valoarea sa echivalentă temporară? sau
alte interese de afacer i.
– Ce monedă este cel mai profitabil? Dacă o firmă face plăți în Euro, dar are si US $ si
RON în contul său, atunci firma va vinde moneda, prin valuta cea mai profitabilă.
– Prin care banca străină se va face plata? Aceasta afectează timpul necesar pen tru
efectuarea plății. Banca cea mai convenabilă din străinătate este aceea care este cea mai
apropiată de firma străina 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 facută 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, a stfel încât resursele ar putea fi transferate, sau trebuie cautată o altă
bancă (sau bănci) din lanțul bancar unde firma străină are un cont. În acest ultim caz, este important ca banca de start să aiba cont la banca străină prin care firma de origine ef ectuează
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 inregistrate, etc), cunoașterea reglementărilor jur idice este, de asemenea, necesar în
acest domeniu. În plus, acesta este un dom eniu în care reglementările legale au fost în mod
constant în schimbare și trebuie să fie strict respectate.
Documentația care este necesara pentru o anumită operațiune depinde d e modul de
efectuare a tranzacției. În cazul în care banca deține mon eda prefer ată, doar ordinul de plată și
compensarea sunt necesare, în caz contrar, banca de origine 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 in momentul acela
banca are resurse limitate, insuficiente pentru a acoperi toate comenzile, atunci treaba angajatului
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 dife rite criterii: dacă utilizarea de
produse este limitată, sau expediere nu trebuie să fie întârziată, sau poate o firmă importă
mașinări î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ă banala pe care el poate sa o corectateze personal, sau daca trebuie să

organizeze o consultare telefonică cu un angajat de la firma, sau dacă el t rebuie să trimită înapoi
cererea inapoi la firma. Este posibil ca documentul în sine să nu permită nici o corecție (cifrele
cardului de credit de exemplu).
Aceste cunoștinte pot fi aplicate la tranzacții valutare doar la banca care, de asemenea, se
ocupă, cu a lte servicii, cum ar fi munca de birou, economiile 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 intocmi
documentele necesare, etc.

Criteriile de decizie construite în DEVEX au fost date de către experți financiari. Figura
urmatoare prezintă un set final al parametrilorl financiari ș i non -financiari folosiți în DEVEX,
care sunt utilizați drept criterii de ev aluare 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 v aloarea maximă.
Valori concrete depinde de acuratețea de plăți și a altor d ate cu privire la firmele de
afaceri într -o perioadă anterioară.

Nume Descriere Cod

Criteriul financiar

Resursele detinute in
cont Compania are un sol d 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

Importanța firmei
pentru bancă Valoarea depozitului f irmei (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 re alizate
tranzacție cu țări străine)

C2

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

Criterii nefinanciare

Tip de bunuri
pentru care
plățile sunt
facute Depinde de persistența bunurilor: bunuri cu persistență scu rtă,
medicamente, produse cu durată mai lungă de persistenț ă,
produse nelimi tate-persistență
D

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

Importanța firmei
pentru
în regiunea din care
ea aparține Efectul firmei asupra funcționării altor firme
F1

Numărul de persoane din regiune care lucrează pentru firmă
F2

Fig.3 Criteriile pentru determinarea prioritatilor de plata in DEVEX

Cunoștințele dobândite sunt repr ezentate î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 professional EXSYS. Următorul exe mplu arată o regulă de producție care calculează valoarea
parametrului C2 di n figura de mai sus:

“ IF (average number 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 t ransactions >=10 AND
the bank's commission acquired from the firm's transact ions <= 10.000) THEN
C2:=3”

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

3. Sisteme inteligente medicale

3.1 Proiectul R ECIPE

Proiectul de cercetare RECIPE adopta o cercetare metodologica hibrida, bazandu -se pe tehnici
non-empirice.De- a lungul acestui proiect ,in pri mul rand se investigeaza manual executia
proceselor si apoi se adauga mai multe tehnologii pentru flux ul de date pe ntru a imbunatatii
procesul.
La fiecare pas al automatizarii, fluxul de date medicale sunt prelucrate folosind urmatoarele
procese:analiz a starii proceselor art, realizarea unui caz business, reprelucrarea proceselor
business ,evaluarea.
In timpul analize i ,analistul se concentreaza pe puncte slabe din punct de vedere material ,
financiar ,informational sau fluxul proceselor. Pentru a jus tifica orice schimbare in fluxul de
date,trebuie definit un caz business ,in care trebuie stipulate costu rile, astepta rile ,riscurile
asteptate apropunerii la care trebuie adaptate. RECIPE permite ca procesele sa fie testate manual
in domeniul sanatatii pentru a sprijini fezabilitatea si profitul.Imbunatatirea proceselor se refe ra
la faptul ca procesele pot fi evaluate si calibrate cu o intarziere virtual intre operatia in executie
sic ea monitorizata.Evaluarea imbunatatirii proceselor are loc prin simpl a comparare dintre
masurarea metrica dupa introducerea imbunatatirii si ea i nainte de imbunatatire.Unele m asuratori
se refera la calitatea serviciilor,castiguri ,costuri ,imbunatatirea starii pacientilor si nivelul
adoptarii procesului imbunatatit.
Pasul 1 :Analiza procesului ( UMMS ). Au fost implementate 3 sisteme :
1) Sistem de management pentru echipamente si pr ovizii
2) Sistemul pentru programari
3) Sitemul pentru depistarea dispozitivelor
Pasul 2:Analiza cazului business. Implementarea fluxului de date se baze aza pe o analiza
detaliata a proceselor dintr -o clinica si dezvoltarea unu i proces nou.Cercetari consid erabile au A comentat [DJ4]: RECIPE=?

A comentat [DJ5]: UMMC =?

fost realizate pentru evaluarea proceselor in clinici ,oportunitati de prioritizare a tintelor ,si
analiza celei mai importante oportunitati tinta.
Pasul 3:Imbunatatiri manuala a procesului
Pasul 4:Imbunatatirea a utomata a procesului in ceea ce privesc pr oviziile 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 fisier
simplu XML sa fie transmis unui flux de date business.Un prototip al fluxului de date prezinta urmatorii pasi:Chirurgia este planificata,OSWorkflow trimite lista de preferinte c hirurgicale
asistentelor OR si le cer sa verifice cart -ul,asistentele raspund cu orice element care
lipse ste,elementel e lipsa sunt raportate camerei cu provizii,camera de provizii ia la cunostiinta si
duce la indeplinire cererea,cererea revine la asistent ele OR.

Avantajele software -ului multimedia pentru a dezvolta capacitatile persoanelor cu
handicap:
este un mediu audio -vizual,este interactiv,tratamentele sau situatiile pot fi reproduse , aceleasi
conditii pot fi reproduse de nenumarate ori ,modul de pr ezentare este realizat in functie de
problemele intalnite,(Marimea, forma, c ontrastul ,culoarea, inaltime a liniilor , a obiectelor si
fundalul pot fi selectate in functie de pacient.) poate fi adjustat in functie de nevoile individuale,sistemele multimedia au efect pe mai multe sensuri ,putand fi eficiente,poate ajuta
creativitat ea, poate varia,se pot introd uce jocuri in programele multimedia,utilizatorul simte
aplicatibilitatea,se poate folosi un feed -back audio motivant, poate fi folosit fie in mod indiv idual
fie in grupuri mici de terapie.
In cazul copiilor : parinti il pot fol osi cu success ,cel mai impor tant este ca acesti copii sa devina
interesatisi acest interes sa si- l pastreze pentru o perioada lunga de timp(Acesta nu este un lucru
usor de realizat ,dar prezentarile multimedia sunt foarte eficiente in acest sens.),sa fie ca un
joc:copilul sa nu consi dere exerciti ul ca o obligatie ci sa ii placa.
Problemele aparute de- a lungul dezvoltarii procesului si solutiilor lor
1) Deterioararea vederii si persoanele cu vedere slaba – vederea perfecta este de 1,vederea
unei persoane cu v ederea deterioarata este de 0 .1 si 0.3.Est e indicat sa se traseze
contururi groase in jurul obiectelor.Daca aceste persoane disting culorile bine tunci

software -ul trebuie sa aiba si o functie de schimbare a culorii obiectelor si a fundalului si
de oprire a animatie .

2) Persoane ce pr ezinta o dete riorare a auzului –copii inca de la varsta de 3 ani trebuie
invatati sa vorbeasca ,aceasta continuand si la scoala ca o materie obligatori i pe langa
celelalte din programa.Daca ii invatam sa vorbeasca si sa isi in multeasca vocabularul cu
ajutorul jocurilo r pe calculator ,le va fi de mare ajutor.Este important ca informatiile noi
sa le furnizam foarte graphic,ca un desen.

3) Persoanele cu prob lem loco -motorii – probabil nu pot folosi mouse -ul sau tastaura ,
acestia po t folosi alte dispositive de in trare sau dezvoltatorul software -ului trebuie sa
creeze instrumente special de navigare , de exemplu utilizatorul trebuie sa foloseasca un
singur switch sau un buton mare.

4) Persoane cu problem e in vorbire sau fizice – exista software -uri care ii ajuta in
comunica re(in Ungaria se foloseste Bliss -ul pentru a imprima,a trimite mail- uri , pentru a
scrie propozitii si pentru a trimite sms -uri ,bazat si pe tehnica de mutare a
dreptunghiurilor.)

5) Probleme de dislexie – introduce rea unor titluri in text , a cest lucru aju ta oamenii in cazul
in care trebuie sa citeasca un text mai lung.

6) Copii cu probleme mentale si cei ce au probleme cu invatarea ,instruct iunile si
propozitiile trebuie sa fie simple, informatia trebuie sa fie scris a in propozitii simple.

7) Persoanele cu pr obleme in deosebirea culorilor – trebuie sa se tina cont de setarile de
culoare.

3.2 Proiectul VIKI:A Virtual Keyboard Interface for th e Handicapped

Proiectul VIKI este un mod de a demonstra eficienta utilizari i unui laptop ca fiind o tas tatura
virtuala pentru a accesa un calculator gazda pe care se ruleaza un software standard.SIL(Laptop cu o Interfata Specializata) furnizeaza orice conexiune necesara pentru dispozitivele asistive si
pentru orice afisaj pe e cran de care are nevoie util izatorul pentr u a interactiona cu aceste
dispozitive.Dupa introducerea unor date de intrare in SIL, datele sunt trimise apoi in calculatorul
gazda in a sa fel incat sa para ca sunt create de catre o combinatie standard a tastaur ii si a mouse –
ului.Software -ul si hardware -ul din SIL sunt realizate in functie de nevoile utilizatorilor ,in timp
ce solfware- ul si hardware -ul din calculatorul gazda ramane nes chimbat.
Proiectul VIKI prezinta 3 faze:
1) Dezvoltarea software- ului necesar pe ntru ca sistemul SIL sa mime ze toate metod ele de
interactionare necesare unei tastaturi si unui mouse standard, pentru a exista o
comunicare intre SIL si sistemul gazda printr -o interfata seriala.Sistemul SIL ruleaza pe
Windows si este creat in Visual Bas ic.Cele doua sisteme se conecte aza prin p orturile lor
seriale folosing un cablude modem.Software -ul VKE ofera utilizatorului o reprezentare a
unei tastaturi , pe ecran, care poat e fi manevrata fie din tastatura laptopului sau prin
asezarea si apasarea mou se-ului cu ajutorul dispozi tivului laptopului.VKE -ul ofera si un
simulator pentru mouse,care va muta cursorul mouse -ul gazdei in directia
indicata.Accesul la bara de meniu a VKE -ului pentru a costumiza controlul, prin
selectarea dispozitivului de intrare principal ,setarea culorii f undalului, viteza mouse-
ului,etc.Interactiunea poate fi realizata prin un mod de scanare a tastaturii.In acest mod,
daca utilizatorul apasa shift,ran dul este selectat si selectarea continua prin apasarea unui
buton de -a lungul randului.O a doua apasarea a s hift-ului v a selecta cheia ce se transmite
computerului gazda. Sistemul SIL poate fi utilizat si ca un sistem de sine statator in timp
ce inca se fo loseste software -ul VKE.Aceasta optiune permite transmiterea informatiei
catre o aplicatie ce ruleaza pe laptop. In ur ma acestui lucru VKE -ul obtine ID -ul
aplicatiei ceea ce permite VKE -ului sa transmita date aplicatiei.Pentru ca VKE -ul sa
realizeze acea sta actiune trebuie sa stie catre ce aplicatie sa transmita datele.Acesta ofera
o lista a tuturor aplicatiil or ce exis ta pe hard -ul lapropului,permitand utilizatorului sa
aleaga una pentru a o executa.Din partea gazdei ,un program TSR(terminate- and-stay-

resident) este necesar.Comunicator -ul primeste semnale SIL ca date de intrare prin
portulserial al gazdei ,si indreapta aceste semnale catre alte programe ce ruleaza pe gazda
ca date de intrare.Comunicator -ul trebuie sa aiba control asupra sistemului gazda, chiar
daca aplicatia software a fost inceputa dar suspendata apoi.
2) Inlocuirea comunicarii seriale cu o comu nicare dire cta cu portul tastaturii sistemului
gazda , eliminand astfel nevoia programului de comunicare TSR a gazdei.Acest lucru va
face SIL -ul po rtabil, permitandu- i SIL -ului sa se conecteze la orice gazda compatibila.
3) Inlocuirea conexiunii hard -wire dintre SIL si sistemul gazda cu un sistem wireless.Ideea
este de a inlocui o tastatura wireless cu un laptop care sa indeplineasca aceleasi atributii
ca si tastatura.
3.3 Proiectul Autonomous Life

S-au remarcat 6 scenarii in care sa se incadreze persoanele cu dizabilitati:apelul vocal,mesajul
existent, mesajele text, „am nevoie de ajutor”, „m -am pierdut” , „nu ma simt bine”.
Din analiza acestor scenari i ,nevoile sistemelor de comunicare mobile pentru persoanele cu
dizabilitati si pentru persoanele in vars ta se clasific a in urmatoarele categorii:
• Comunicare personala : folosita pentru persoanele cu probleme locomotorii.Acesta implica imposibilitatea ace stor persoane de a se deplasa intr -un timp scurt pentru a putea
raspunde si modul de folosire a telefo anelor cu fir.
• Securitate:Persoanele invarsta si cele cu probleme locomotorii intampina restrictii care pot duce la o situatie de potential risc care creste in momentul in care acestia doresc sa
aiba un mod de viata independent.
• Integrarea sociala.Accesu l la educatie si pe piata fortei de munca:In ultimii ani
telefoanele cu fir au permis un acces la informatie si la oportunitati de angajare prin servi cii telematice ,ca de exemplu lucrul prin telefon sau educarea prin telefon a
persoanelor cu disabilitati a jutand la i ntegrarea sociala si autonomie.Telefoanele mobile
sunt utile in zonele izolate incare telefonia fixa nu exista.

• Autonomia:Combinatie dint re comunicarea personala,securitate si accesul la serviciile
integrative per mite persoanelor in varsta s i celor cu dis abilitati sa duca un mod de viata
independent.
Asigurarea serviciilor cu ajutorul telefoanelor mobile poate duce la un risc social si eti c pentru
persoanele cu diazabilitati si pentru persoanele in varsta.Cele mai critice sunt: izolarea
sociala,pierderea autonomiei personale, pierderea intimitatii, barierele economice.

4. Date medicale electronice

4.1 Concepte gen erale

4.1.1 Definirea principalelor concepte legate de datele medical e electronice:

Electronic H ealth Recor d este o înregistrare electronică longitudinală de informații privind
sănătatea pacientului, informații generate de unul sau mai multe e venimente în sistemul de
îngrijire al pacientului. Printre aceste informații sunt incluse: datele demografice ale pacienților,
evoluția pacientului, probleme, medicamentație, semnele vitale, antecedente medicale, vaccinări,
date de laborator, precum și rap oarte de radiologie. EHR automatizează și simplifica fluxul de
lucru medical. EHR are capacitatea de a gener a o înregis trare completă a unui consult medical,
precum și sprijinirea altor activitati 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 faptul 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 toa te nivelele de-a lungul
timpului. Înregistrările longitudinale pot fi păstrate într -un sistem de informații de sănătate la
nivel național sau regional.
Electronic Pațient Record (EPR) este un concept în evoluție definit că o colecție
electronică sis tematică de informații privind sănătatea unui pacient sau a unei populații.
Termenii EPR și EMR (Electronic Medical Record) sunt adesea folosiți alternativ, deși
se pot observă diferențe între aceștia. poate fi def init că o înregistrare legală a pacientului, cre ață
în spitale și medii ambulatorii, 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ă accesul la informațiile medicale ale pacientului pesoanelor
interesate de acest lucru: pacienți, medici, alți îngrijitori, angajați, asiguratori și contribuabi li.
Personal Health Record (PHR) este de obicei o înregistrare medicală care este creată și
menținută de către un individ. U n PHR ideal ar oferi un sumar medical complet și exact al
istoriei sănătății unei persoane prin colectarea de date din mai mul te surse și oferirea accesului
on-line la aceste informații pentru oricine are acreditările electronice nece sare 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ă și
pentru a stoca date de sănătate. Există mai multe definiții ale conceptului, însă cea prezentată mai
sus este cea mai utilizată.
Este important de reț inut faptul că PHR nu est e identic cu EHR (Electronic Health
Record). Acestea din urmă sunt sisteme software destinate utilizării de către furnizorii de servicii
medicale. La fel că 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 o bligă un consumator sau pacient să stocheze informații de sănătate cu
caracter personal într -un PHR.
Continuity of Care Re cord (CCR) este un standard dezvoltat de mai multe societăți
internaționale pentru normalizarea înregistrări lor medical e. Standardul CCR se dorește un
rezumat clar al stării de sănătate a unui pacient. El reprezintă o modalitate de a creă documente
flexibi le, care să conțină informații cât mai relevante privind sănătatea pacientului, accesabile în
timp util, pre cum și o mo dalitate de a trimite electronic aceste informații de la un îngrijitor la
altul.
Acest rezumat trebuie să conțină secțiuni diferit e, cum ar fi datele demografice ale
pacienților, info rmații legate de asigurare, diagnostic și lista de prob leme, medic amente, alergii,
precum și a planului de îngrijire. Acestea reprezintă un rezumat al datelor privind sănătatea unui pacient, care poate f i util dacă este disponibil la momentul evaluării clinice. Acest standard este
conceput pentru a permite crearea cât mai facilă a rezumatului stării medicale a pacientului de către un medic cu ajutorul unui EHR la finalul evaluării pacientului.

Pentr u 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 s oftware EHR sau EMR. Un CCR poate fi, de
asemenea, exportat și în alte formate, precum PDF și Office Open XML.
Computer -based Patient Record(CPR) este o înregistrare electronică a pacientului care
este situată într -un sistem spe cial concep ut pentru a sprijini utilizatorii prin accesibilitatea la date
complete și exacte, alerte, memento -uri, sisteme suport de decizie clinică , link -uri la cunoștințe
medicale, precum și alte ajutoare.

CPR poate oferi acces la diverse instrument e medicale (de exemplu: sprijinirea deciziilor
medicale) care pot fi folosite pentru a dezvoltă o perspectivă de ansamblu asupra pacientului. Acesta include captarea, descrierea, analiză ș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 ac este
dispozitive medicale împreună cu înregistrările medicale, precum și cu mecanisme tipice de intrare și d e ieșire.
Computerized Medical Record (CMR) este o înregistrare medicală electronică creață
într-o organizație care oferă îngrijire medicală, cum ar fi un spital sau cabinetul medical.
Înregistrările medicale electronice tind să fie parte dintr -un sis tem local s tând-alone de informații
privind sănătatea, care permite stocarea, extragerea și modificarea înregistrărilor.
Alții definesc EMR/EHR /CPR pur și simplu că sist eme atotcuprinzătoare a înregistrărilor
privind pacientul și tratamentul acestuia. Gartner de finește cinci generații sau nivele de
tehnologie EMR, însă doar primele trei prezintă importantă pentru subiectul abordat. Prima generați e de sisteme de tehnologie a informației medicale furnizează date pentru captare și
afișare. EMR din a două generație sunt cele c are permit includerea documentelor scanate și
transcrise. A treia generație este destinată reprezentării datelor medicale în m od flexibil și
facilitează interacțiunea cu aceste date.
American Health Information Management Association (AHI MA) a publicat rezultatele
unei căutări pe Internet privind managementul informațiilor sănătății pacientului. Căutarea pe Internet a retu rnat următoarele texte sau termeni frecvent citate: Electronic Health Record
(EHR), Electronic Pațient Recor d (EPR), El ectronic Medical Record (EMR), Personal Health
Record (PHR), Continuity of Care Record (CCR), Computer -based Pațient Record (CPR),

Comput erized 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ă.
Multe studii desfășurate estimează îmbunătățirea eficienței generale cu aprox imativ 6%
pe an atunci cand se folosesc înregistrările medicale electronice, față de sistemele pe bază de
hârtie.
Pe langa această sistemele elctronice cresc portabilitatea ș i accesibilitatea documentelor
medicale electronice. Implementarea unui sist em de secur itate va diminua posibilitatea
pierderilor, furturilor și a modificărilor față de dosarele medicale stocate pe hârtie.

4.1.2 Electro nic Health Record (EHR) – Prezentare generală

Valoarea majoră a sistemelor medicale integrate es te faptul c ă permit captarea de date
medicale că parte a fluxului de lucru global. Un EHR permite administratorului să obțină date
pentru facturare, medicului să observe tendințe în eficentizarea tratamentului, asistenței să
raporteze o reacție adversă, cercetătorulu i să realiz eze mai facil studii medicale. Dacă fiecare
dintre acești profesioniș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 d eservi
nevoi diferite. 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ță pentru fie care serviciu pe care un
pacient îl primește de la un departament auxiliar, cum ar fi cel de radiologie, laborator, farmacie
sau că rezultat al unei acțiuni administrative (de exemplu, emiterea unei facturi). Unele sisteme medicale precum AMC (Academic Medical Centers) permit captarea electronică a semnalelor
fiziologice (de exem plu, electr ocardiografie), notelor asistentelor, rețetelor medicilor etc. De cele
mai 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 sist eme conexe) , care au
fiecare propiulul lor sistem de autentificare și de identificare a pacientului.
Vânzătorii de sisteme șilo pot utiliza sta ndarde diferite pentru vocabulare, pentru
identificarea utilizatorului, precum și pentru identificarea pacienților. Tr ebuie subl iniat faptul că
nu există acces unificat la aceste sisteme. Un utilizator din domeniul medical ar trebui să A comentat [DJ6]: ?

deschida o serie de 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 f ax sau imprimate și se
atașează dosarului de hârtie la internarea bolnavului. În cazul în care noi rezultatele electro nice
sunt disponibile, rezultatele vechi vor fi actualizate și noi alerte (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, date le disparate nu pot fi agregate într -o
afișare integrată, cum ar fi 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 ca zurile în care pacienții au fost diagnosticați cu leucopenie,
împreună cu toate cazurile diagnosticate că fiind “numar scăzut de celule alb e”, deoar ece cele
două concepte ar fi codificate că și termeni sinonimi. Pentru a rezolvă variațiile de vocabular trebuie utili zat un sistem structurat de vocabular, iar datele trebuie 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 tiile des pre evoluți e), într -o formă structurată printr -o
lista drop -down, c a imagini, sau c a semnale digitale (de exemplu, electrocardiograme) asociate
cu m eta-date.
O arhitectură integrată pote fi creat ă pentru a permite schimbul de date între sisteme. Fiecare
sistem păstre ază dat e proprii la nivel local. Pentru a partaja informațiile pacientului, un sistem
trebuie să permită unui altui sistem să accesez e fișierele sale, iar acesta trebuie să transmită o
copie a dosarului la sistemul care a cerut acest lucru. Odată ce fișier ul 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 descrie integrarea datelor privind asistentă medicală de la o colecție de sist eme
participan te, pentru un singur pacient.
Componente cheie ale dosarelor medicale electronice
Cele mai multe EHR comerciale sunt concepu te pentru a combină datele provenind de la
serviciile auxiliare de dimensiuni mari (farmacie, laborator și r adiologie) cu diferite componente
de îngrijire medicală, cum ar fi: rețetele medicilor, înregistrările privind medicamentația
pacientului, observați ile asistentelor. Numărul de componente integrate și facilitățile în oricare A comentat [DJ7]: ?

sistem integrat de date depind de structurile de date și de sistemele puse în aplicare de către
echipele tehnice. Pot există o serie de furnizori de sisteme auxiliare care nu sunt neapărat
integrate în EHR. Prin urmare, EHR poate importă date din sistemele auxiliare prin intermediul
unei interfețe personalizate sa u a unei interfețe care permit personalului medical să acceseze
sistemele de tip șilo printr -un portal. Că alternativă E HR-ul poate incorpora doar câteva din
serviciile auxiliare.

4.2. Componentele sistemului de adm inistrație

Înregistrare, internări, externări, precum și transferuri (prescurtat: RADT – Registration,
Admission, Discharge and Transfer)} datele provenite de la aceste proceduri sunt componente
cheie ale EHR. Aceste date includ informații vitale pentru identi ficarea și evaluarea pacientului:
nume, date demografice, rude, informații angajator, cerințe ale pacientului etc. Partea de înregist rare din cadrul unui EHR conține un identificator unic al pacientului, care de obicei
constă dintr -o secvenț a numerică sau alfanumerica, ușor identificabila și în afară instituției.
Datele RADT permit că informațiile personale de sănătate să poată fi utili zate atât în analiză
medicală, cât 'și în cercetare.
Identificatorul unic al pacientului este nucleul unui EHR și f ace legătură c u toate
celelalte părți: observațiile medicale, țeste, proceduri, evaluări, precum și diagnostice ale pacientului. Ident ificatorul mai este numit și numărul medical al pacientului sau index principal
al pacientului (MPI – Main Pațient Index) . Evoluția sis temelor informaționale automatizate au
făcut posibilă utilizarea pe scară largă de către organizații sau instituții a MP I-ului.

4.2.1 Componentele sistemului de laborator
Sistemele de laborator sunt în general sisteme s tan-dalone car e sunt interfațate cu EHR.
De obicei, există sisteme informatice de laborator (LIS – Laboratory Information System) care
sunt utiliza te că hub- uri pentru a integra comenzi și rezultate provenite din instrumente de
laborator, programul de fac turare, precum și alte informații administrative. Datele de laborator
sunt rareori integrate în întregime cu EHR, chiar și atunci când LIS este real izat de către același
vânzător de EHR, deoarece multe dispositive și analizoare care sunt utilizate în procesul de

diagno sticare din laborator nu sunt ușor de integrat în EHR. De exemplu, Cerner LIS interfațează
cu peste 400 de instrumente de laborator di ferite. Cerner, un furnizor major de LIS și a
sistemelor EHR, a raportat că: “60 la sută din instalările sal e LIS au fost stând -alone (nu au fost
integrate cu EHR)”. Unele EHR 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 – Radiolo gy Information System) sunt utilizate
de către departamentele de radiologie pentru a pune împreună datele pacientului ce țin de
depart amentul de radiologie (de exemplu: interpretări, informații de identificare ale pacientului)
cu imagini. RIS tipice includ : evoluția pacientului, programarea, rapoarte cu rezultate, precum și
funcții de urmărire a imaginilor. Sistemele RIS sunt de obicei u tilizate împreună cu sistemul de
comunicare al imaginilor arhivate (PACS – Picture Archiving Communications Systems) care
gestionează radiografiile digitale. Cele mai multe AMC (Academic Medical Centers) au sisteme
RIS. Cu toate acestea, nu se poate garan ta că toate sistemele RÎS sunt integrate cu EHR.

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 r oboții de farmacie pentru scrierea
rețetelor sau formularelor de plată, nu sunt de obicei integrați cu EHR. Conform unui r aport din
2005 în medie 31% din toate r etele electronice sunt reintroduse în sistemul farmaceutic.

4.2.4 Ordine me dicale computerizate
Ordinele medicale computerizate (CPOE – Computerized Physician Order Entry)
permite personal ului 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 aux iliare complete prin care se pot
comada, alertă, creă seturi de comenzi personalizate, de raportare și de rezultate. Potrivit Klas

Enterprises, un furnizor de date pentru industria informatică din spitale: “doar patru la sută de
spitale 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. Deși au fost înregistrate unele succese majore ale
CPOE, au fost înregistrate și unele eșecuri notabile. Handler, într -un ar ticol 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
elimină în întregime eroarea și pot introduce noi ti puri 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, efectul net al CPOE poate să
încet inească medicii”.
4.3 Documentatia medicală

Documentația medicală electronică crește valoarea EHR prin furnizarea de captare
electronică a notelor medicale, a evalu'arilor pacient ului și a rapoartelor medicale, precum
precum și a înregist rării administră rii de medicație (M AR – Medication Administration
Records) . Că ș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 ben eficii substanțiale, astfel că până la 24% din timpul unei asistențe
medicale poate fi salvat. Exemple de documentație medicală, ce pot fi automatizate:
• Note medicale ale med icilor, 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;
• Inputerniciri ale decizi ilor de asistentă medicală;
• Diagrame de urmărire a pacien tului;
• Dosarele medicale (inclusiv autorizații);
• Credentialele personalului / calificarea personalului și documentarea programărilor;

• Graficul de urmărire a deficiențelor;
• Utilizarea de man agement.

Dispozitivele medicale pot fi, de asemenea, in tegrate in fluxul de informatii medicale si utilizate
pentru a genera in timp real alerte datorate modificarii starii pacientului. Haugh sustine ca “la Cedars -Sinai Medical Center, Los Angeles, de exemplu, pompele de medicamente intravenoase
conectate la s istemul de inform atii medicale realizeaza verificare automata a dozelor si a
documentatiei pentru managementul medicatiei. Toate sistemele de monitorizare fiziologice sunt
in retea, iar datele priv ind pacientii pot fi vizualizate pe alte sisteme de informa re medicala din
spital. De la biroul sau, Michael Shabot, MD, poate monitoriza EKG -ul unui pacient folosind un
sistem de vizualizare bazat pe Web, creat la spitalul Cedars -Sinai, care incorporeaza un produs
comercial ce ofera in timp real informatii de la sectia de monitor izare intensiva si alte sectii”.

4. 4 Datel e din EMR
• datele demografice ale pacientului (adresa, numar de telefon etc.);
• istoric medical, examinari, rapoarte de urmarire a sana tatii si bolii;
• medicamente, lista de alergii, imunizare;
• rezultatele test elor de laborator;
• imagini radiologice, raze X, tomografie computerizata etc.;
• fotografiile de la endoscopie, laparoscopie sau fotografii clinice;
• informatii despre medicamente, inclusiv reactii secundare si interferente;
• recomandari p entru situatii me dicale deosebite;
• inregistrarea listei de programari si a altor memento -uri;
• facturi;
• eligibilitate;
• testamente, imputerniciri.
Doua clase specifice de date pot fi stocate in EMR. Acestea se incadreaza fie in categoria
monitorizare di screta, fie in mo nitorizare continua.
Monitorizarea discreta poate fi facuta intr -o maniera ad -hoc, asincrona, pe cand
monitorizarea continua a unui pacient se efectueaza sincron. Marea parte a inregistrarilor pe

suport de hartie sunt in curs de inlocui re cu inregistrar i electronice, unde personalul medical
poate introduce informatii manual sau si in mod automat.
Inregistrarile medicale electronice sunt intretinuta de catre institutia medicala si urmaresc
pacientul pe parcursul tuturor etapelor de dia gnosticare si tra tament. Mai mult, acesta inregistrare
medicala este accesibila intregului personalul autorizat. Un beneficiu evident al acestei abordari
este faptul ca spre deosebire de inregistre a pe hartie, inregistrarea medicala electronica poate fi
accesata din mai mu lte locatii diferite.
Pierderea de informații este minimalizată prin utilizarea fișelor medicale electronice,
care stabilesc o abordare uniformă pentru înregistrarea informațiilo r pacientului, astfel încât
fiecare departament trebuie să se conformeze anu mitor 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ă EMR
Rețeaua simplă este destinată ilustrării loc alizării relative a hardware -ului într -o
întreprindere care conține un CPR (Computer -based Pat ient Record). CPR este încorporat în
următoarele module: Web, Aplicație și server de Baze de Date. În această figură, modulul Web și
serverele A plicației sunt co mbinate într -un singur element, o configurație potrivită pentru o
întreprindere relativ mică (nu mai mult de câțiva zeci de utilizatori simultan).
Serverul de Baze de Date o feră acces solicitărilor venite de la Aplicație în urmă
interogările inițiate de utilizatorilor prin intermediul unei instanțe Web a aplicației CPR.
Componente client sunt reprezentate prin simbolurile unor calculatoare laptop, wireless.
Picrograma unui client desktop arată posibilă utilizare de către perso ane fizice în bir ouri (de
exemplu: de către medici, asistențe). Se presupune că aplicația CPR este accesibilă pe Web astfel
încât clientul să o poată accesă și prin intermediul unei pagini de inter net.
În figură este prezentat un client Web, care f ace o cerere de i nformații în sistemul CPR.
Cererea 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
constituie răspuns ul la cererea uti lizatorului, apoi transmite datele la Serverul de Baze de Date,
care gestionează depozitul de datele persistente într -un sistem accesibil prin intermediul
Structured Query Language (SQL). În cele din urmă, datele sunt preluate, să întorc l a Serverul de

Aplicație pentru prelucrarea 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 cadr ul CPR.
Dispozitive medicale pot interfață cu CPR printr -un format bazat pe standarde, precum HL7, sau
poate comunică într -un format propriu utilizând un anumit tip de procesor intermediar pentru a
traduce datele într -o interfață corespunzătoare și univer sală.
Arhitectură EHR reprezintă totalitatea componen telor structurte 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 oc rotirii 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 ă
standardului HL7) și imagini (standardul DICOM). Sisteme bazate pe m odelul OpenEHR, care presupune utilizarea Modelul Informațional
de Referință (RIM), configurat într -un mod flexibil de arhetipuri (Archetypes) și care este
realizat din setul de st andarde EN13606/1- 5. Ideea atractivă a conceptului RIM/Arch etypes
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 desco perit un sistem software complex care să suporte atât
valid area 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 er ori în date. Aces te 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, chia r dacă datele sunt introduse cu erori, acestea
nu poate fi modificate sau res pinse la intrarea în bază de date. “Curatarea datelor” (data cleaning)
garantează calitatea datelor după introducerea lor în bază de date, eliminând din tabele sau
modificând acel e date care nu sunt corecte/corespunzătoare/integrale.
Definiție și tipur i 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 persistă. În

contextul calității datelor sunt analizate t oate 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”). Că dovadă, calitatea datelor mai este definită și li psă defectelor
intolerabile în cadrul datelor.

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

Figura 4.1 Schema sistemului

În figura de mai sus este prezentată o schema bloc a sistemului. Aceasta este compusa
din mai multe module ce f ormează aplicația Java. Administratorul și utilizatorii pot accesa

aplicația, primind informatii ca raspuns cerintelor aplicate. Aplicația este compusa din trei
entităti care reprezinta modulele principale ale aplicației: management pacien ti, boli și
investigatii. Datele sunt salvate intr -o bază de date de tip MySQL unde se executa operațiile de
creare, citire, update si stergere.
Scopul acestui sistem prezentat este de a simplif ica munca cadrelor medicale. Această
aplicație pune la dispoziția medicilor o multitudine de informații despre pacienti, boli si
investigatiile efectuate.
5.2. Funcționalitățile aplicației
Aplicația adresată tuturor utilizatorilor interesați prezinta urm ătoarele funcționalități:
– Adaugarea unui nou pacient.
– Spec ificarea adresei l a care locuieste pacientul.
– Modificarea / stergerea datelor despre pacient, respectiv adresa acestuia.
– Introducerea unei noi boli despre care pacientul sufera.
– Modificarea / ster gerea datelor despre pacient cum ar fi bolile de care sufer a, respectiv
investigatii medicale.
– Vizalizarea datelor despre un pacient.
– Vizualizrarea datelor despre pacienti si bolile asociate.
5.3. Diagrama Gantt
Diagrama Gantt este folosita pentru a avea o organizare și o planificare eficienta a
etapelor de dezvoltare a aplicați ei.
Diagrama Gantt se foloseste pentru a planifica proiecte, evenimente și a muncii, în
general. În proiectele software apar probleme ce afectează dezvoltarea produselor cu o anu mită
frecvență, cauza fiind aplicarea incorectă a metodelor mecanismelor exi stente.
Etapele desfășurării unui proiect sunt prezentate în diagrama de mai jos.

Figura Diagrama Gantt
5.4. Analiza de risc

În caz ca apar unele defecțiuni ale elementelor de interfațare care se pot defecta, se poate
proceda in urmatorul fel:
1. Riscul situațiilor imprevizibile:
Riscul de disponibilitate este riscul asociat pericolelor naturale, dezastrelor, căderilor de sistem care pot conduce la pierderi definitive ale datelor, aplicațiilor, în absenta unor proceduri de
monitoriz are a activității, a planurilor de refacere în caz de dezastre.
Situațiile neprevăzute mai apar si in urma încărcarii de imagini în format necorespunzător sau introducerea de text cu caractere necu noscute de catre sistemul de operare.

2. Defecțiunile la baz elor de date :
In cazul in care baza de date nu mai este funcționala, problema trebuie rezolvată într -un timp
cat mai scurt, deoarece nu vor mai putea fi afișate evenimentele.
Baza de date nu pun e la dispozitie un server de back -up la fel ca al aplicaț iilor web. Dacă s e
introduc spre exemplu obiective turistice care au informatii asemanatoare, rezultă o defecțiune
deoarece vor exista obiective identice.
3. Riscul de infrastructură :
Se concretizează în faptul ca nu este pusa la dispozitie 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
hardware.
4. Riscurile de conformitate:
Incălcarea regulamentelor o ri a politicilor interne ale aplicației.
PUNCTE TARI PUNCTE SLABE

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

– Concurența foarte crescuta;
– Aparitia unui software asmenator
cu acesta ;
– Atractie slaba a posibililor
investitori.

6. Proiectarea si d ezvolt area platformei software

6.1 Integrarea Java & JESS

Cele mai i mportante trasaturi a Jess -ului sunt acelea care ii permit sa fie integrat usor cu
Java. De la codul Java, putem accesa toate partile librariilor Jess, astfel incat este foarte us or sa
integram Jess in orice aplicatie Java, servel, applet sau orice sistem . De asemenea, de la limbajul
Jess, intreaga putere a lui Java este in mod direct disponibila.
Acest capitol descrie cum putem crea obiecte Java, cum putem apela metodele sale si
cum putem interactiona si in alt mod cu Java fara sa scriem cod Java.
Jess e ste un fel de limbaj de scripting pentru Java. Inafara de folosirea Jess -ului pentru
construirea sistemelor bazate pe reguli, putem folosi Jess si pentru interactionarea cu API -ul Java
sau chiar pentru a construi aplicatii intregi.
6.1.1 Crearea obiectelo r Java

Desi listele sunt folositoare, nu sunt la fel de puternice ca si containerele Map si Set din
colectiile API din Java. O lista simpla este o buna alegere pentru o lista de cumparaturi, dar mai
degraba este nevoie de ceva ca HashMap pentru a retine un tabel cu preturile pentru cumparaturi.
HashMap permite cu usurinta sa vedem un pret a oricarui articol din tabel.
Functia Jess new ne permite sa cream instante a claselor Java. D e exemplu, putem sa
cream un HashMap Java si sa il retinem intr -o variabila cu urmatorul apel de functie:
Jess> (bind ?prices (new java.util.HashMap))
<External -Address:java.util.HashMap>

Jess foloseste tipul EXTERNAL_ADDRESS pentru obiectele Jess.Value care retin
obiecte Java arbitrare. Cand afisam un tip EXTER NAL_ADDRESS, pute m vedea un string care
contine numele clasei. In schimb ne putem astepta ca Jess sa apeleze metoda Java toString asupra
obiectului continut – daca Jess face asta, oricum , rezultat ul ar fi confuz. Un obiect

java.lang.Integer si o valoare J ess de tipul RU.I NTEGER actioneaza foarte diferit, dar daca Jess
foloseste toString pentru a afisa obiecte EXTERNAL_ADDRESS, ambele scriu ca un numar.
In Java, putem evita folosirea prefixelor pachetelor cu cu cheia import. Jess are o functie
import pe care o putem folosi pentru urmatoarele:

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

Acest exemplu foloseste caracterul “*” ceea ce inseamna “importa toate clasele din acest
pachet”, dar se poate de asemenea impo rta doar o clasa la un moment dat folosind intregul nume.
Ca si in Java, intregul pachet java.lang este importat implicit, astfel se pot crea obiectele Integer
si String fara impor tarea pachetului in mod explicit.
Pana acum, am folosit con structorul implic it HashMap. Desigur, se pot crea obiecte
folosind si constructorii altor clase. HashMap are un constructor care ia ca argumente Java int si
Java float. Daca invocam acest construct or si ii pasam numere, Jess va face urmatoarele:
Jess> (bi nd ?prices (new H ashMap 20 0.5))
<External – Address:java.util.HashMap>

Jess, ca orice cod Java, poate invoca doar constructorii publici ai claselor publice din alte
pachete. Daca vrem ca Jess sa fie capabil sa construiasca instante a cleselor pe care le definim, trebuie sa declaram si clasa si constructorii publici.
Cand apelam o metoda Java, Jess converteste argumentele de la tipul de data Jess la tipul
Java. Cand convertim astfel, Jess are unele idei cu tipul tintei (target type). Tipul tintei este tipu l
Java de care es te nevoie intr -o situatie data. In exemplul cu HashMap, tipurile tinta sunt int si
float, pentru ca acestia sunt tipurile parametrilor formali a singurului constructor HashMap care
ia doua argumente. Cand pasam un argument la un constructo r sau metoda Java, Jess are obiectul
java.lang.Class care reprezinta tipul parametrului formal si un obiect java.Value care contine
valoarea pe care am pasat -o si vrea sa intoarca continutul lui Va lue in ceva asignabil tipului

numit de Class. Deci simbolul TRUE poate si pa sat unei functii care cere un argument boolean,
sau uneia care are un argument de tipul String, si apelul ar avea success in ambele cazuri.

6.1.3 Apelarea metodelor Java

Daca ave m o referinta spre un obiect Java intr -o variabila Jess, putem invoca orice
metoda a obiectului folosind functia call. De exemplu HashMap.put asocieaza o cheie cu o
valoare, si HashMap.get cauta o valoare dupa o cheie data. In exemplul de mai jos, cheile s unt
numele articolului de cumparaturi si valorile sunt preturile:
Jess> (cal l ?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 functiei call este obiectul Java, si al doilea argument este numele
metodei invocate. C elelalte argument e a lui call sunt argumentele pe care le pasam metodei Java.
Argumentele sunt convertite la tipul Java.
In acest exemplu am ignorat valoarea returnata de metoda Hashmap.get si am p ermis lui
Jess doar sa o afiseze. Adesea, totusi, dorim sa facem ceva cu tip ul returnat: sa il legam la o
variabila sau sa apelam alta metoda asupra lui. Jess converteste valorile returnate a metodelor
Java in tipuri Jess.

6.1.4 “Nesting”ul apelul funct iilor si “shortcut -ul”
Simbolul call din urmatorul exemplu este putin distr as:
(call ?prices put bread 0.99)
De fapt nu este mai bun decat codul Java echivalent:
map.put(“bread”, new Double(0.99));
(De fapt codul Jess este mai scurt). Dar totusi, func tia call pare incarcata cu “bagaje”.
Partea buna este ca Je ss ne permite sa omitem:
(?prices put bread 0.99)

Cand primul element a unui apel de functie este un obiect Java, Jess isi asuma o metoda
pentru a include simbolul call si invoca o functie asupra obiectului. Acest lucru functioneaza
chiar daca primul element a apelului f unctiei este un alt apel de functie:
((bind ?prices (new HashMap)) put bread 0.99)
Aceasta linie de cod creaza un HashMap, il leaga la o variabila, si adauga o pereche
nume/valoa re. Trebuie sa fim atenti la apelul functiior “nesting” in acest fel; combin and logic
operatii separate intr -o singura linie de cod ne putem ingreuna intelegerea problemei. Pentru
multe probleme call este optional. Putem sa il ignoram cand apelam metode st atice.

6.1.5 Apelarea metodelor statice
Metodele statice a unei clase din J ava sunt acele metode care pot fi apelate fara referinta
la un obiect specific. Si in codul Java si in codul Jess, putem folosi doar numele unei clase Java
pentru a invoca orice metoda statica a sa. Un bun exemplu este metoda java.lang.Thr ead.sleep:
Jess> ( call Thread sleep 1000)
(pause for one second)
Jess>
Nu este nevoie sa folosim intregul nume java.lang.Thread pentru ca clasele din pachetele
java.lang sunt in mod implicit impo rtate in Jess.
Cand apelam o metoda statica, trebuie sa inc ludem numele func tiei call; cel mai adesea
call este folosit pentru invocarea metodelor statice. Jess include alte functii, similare cu call, pentru a ne ajuta sa invocam alte categorii de metode.

6.1.6 Apelarea metodelor get si set

Obiectele Java special e numite JavaBean s joaca un rol important in Jess. Astfel, Jess
include multe tool- uri pentru a lucra cu ele. Una din aceste tool -uri este o pereche de metode
pentru a simplifica accesul la datele lor. Metode care seamana cu urmatoarele de mai jos sunt
comune in majoritate a limbajelor orientate pe obiecte:
public String getName() {
return name;
}

public void setName(String n) {
name = n;
}
Adesea sunt numiti accesatori si mutatori sau getteri si setteri. Sunt foarte comuni in Java
si formeaza o parte imp ortanta a specifi catiei JavaBeans. Multe din clasele bibliotecilor Java (in
special din bibliotecile grafice) folosesc aceasta metoda numind -o conventie.
Jess include functiile set si get, care pot fi folosite ca o alternative la call pentru setteri si
getteri. Urmatoarele perechi de apeluri de functii sunt echivalente:
Jess> (bind ?b (new javax.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 te xt)
“Press Me”

Numele metodelor getter si setter includ un nume propriu, care este text in acest exemplu.
Numele propriu este pasat ca argument secundar functiilor set si get. Pentru a obtine numele propriu, trebuie sa mutam prefixul din numele metodei Jav a si sa transformam litera majuscula
initiala a restului de nume in litera mica. Singura exceptie este pentru nume ca getURL, unde numele propriu este URL cu toate literele majuscule. Aceasta conventie este aceeasi ca sic ea
folosita de s pecificatia JavaB eans.

6.1.7 Utilizarea tablourilor

Tabelul cu preturile cumparaturilor poate fi si o lista simpla de cumparaturi. Putem folosi
Map pentru colectia de chei si apoi sa convertim aceea colectie int -un tablou. Daca putem
converti acel tablou la o lista simpla in Jess, putem sa recream lista de cumparaturi.

Jess converteste automat tablouri in liste simple (Values de tipul RU.LIST). Putem folosi
metoda toArray din java.util.Collection p entru a extrage toate cheile din hashMap intr -o lista
Jess:

Jess> (bind ?gr ocery -list ((?prices keySet) toArray))
(bread peas beans)

Daca dorim sa punem lista de cumparaturi intr -un meniu pop -up, putem sa consideram
lista de articole ca un argument al co nstructorului calsei javax.swing.JComboBox. JComboBox
are u n tablou ca si ar gument al constructorului, dar Jess converteste automat lista simpla inapoi
intr-un tablou:

Jess> (import javax.swing.JComboBox)
Jess> 9bind ?jcd (new JComboBox ?grocery -list))
<External -Address:javax.swing.JComboBox>
Acest sistem lucrea za bine pentru ta blouri mici, dar convertirea intre tablouri si liste este
ineficienta pentru tablouri mari, pentru ca structura de date Jess care reprezinta lista simpla trebuie creata sau distrus a la fiecare conversie. O metoda mai buna de lucru cu tablo urile Java
largi este planificarea unei versiuni Jess. Intre timp, daca este nevoia sa se lucreze cu tablouri
mari in programele Jess, se poate scrie codul in Java si apoi sa se apeleze din Jess.
De asemenea Jess nu are o interfata speciala pentru lucrul cu tablouri mutlidi mensionale,
deci, din nou, codul Java poate fi necesar. Se pot scrie si functii Java normale si apoi sa le apelam
folosind tehnici descrise mai sus, sau putem folosi functii scris e in Java pentru a extinde insusi
limbajul Jess.
6.1.8 Cum alege Jess intre m etodele supraincarcate

In Java nu se poate stoca un float intr -un HashMap, dar in Jess se poate stoca un float –
pentru ca Jess converteste automat numarul pe care noi il furnizam intr-un java.lang.Double. In
cele mai multe cazuri, aceast a conversie este f olositoare; dar ocazional cauzeaza probleme. O
problema ar fi cand avem nevoia sa apelam o metoda dintr -un set de metode Java supraincarcate.

Un nume de metoda Java se spune ca e ste supraincarcata daca metode multiple cu acelasi
nume, da r cu o lista de a rgumente diferite sunt disponibile pentru acelasi obiect. Un exemplu il
reprezinta metodele supraincarcate a lui java.io.PrintWriter.println. Toate aceste metode apar in
calsa Prin tWriter:
void println()
void println(Boolean x)
void printl n(char x)
void pr intln(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)
Cand apelam o metoda supraincar cata in codul Java, compilatorul Java alege cea mai
specifi ca metoda suprain carcata aplicabila.
Jess este mai relaxat in a alege intre supraincarcari pentru ca nu trebuie sa aiba strict
acelasi tip de informatie pe care trebuie sa il aiba Java. Un exemplu simplu este: uitandu- ne la
lista de metode println suprainc arcate, putem obs erva versiunea si pentru double si pentru float.
Jess are doar un singur tip de float.
Cand apelam o metoda supraincarcata ca println, Jess se uita la fiecare supraincarcare in
parte, incercand sa portiveasca tipul parametrului metodei cu tipul argumentelo r date. Prima
supraincarcare pe care o gaseste Jess care poate fi invocata cu lista de argumente, va fi apelata.
Jess nu cauta dupa o buna portivire, ci foloseste prima portivire gasita.
Adesea, nu conteaza care set de metode supraincarcate sunt apelate; un set de metode
supraincarcate fac de obicei toate acelasi lucru. Acesta este cazul lui java.io.PrintWriter.prinln.
Uneori, se poate sa dorim o anumita supraincarcare a unei metod e, dar sa nu poata fi posibil. De
exemplu, daca pasam stringul “TRUE” unei m etode Java care este supraincarcata sa ia fie
argumentul boolean, fie String, este imposibil sa prevedem care supraincarcare o va alege Jess.
In aceste cazuri, putem recurge la fol osirea unei clase explicite. De exemplu, sa presupunem ca

in acest caz dorim sa invocam supraincarcarea boolean, dar Jess apeleaza pe cea String; creand si
pasand obiectul java.lang.Boolean ar trebui sa se rezolve problema, pentru ca Jess va converti
autom at java.lang.Boolean la boolean si nu la String.
Uneori ape larea metodelor J ava nu este suficienta – se poate sa fie nevoie sa se lucreze
direct cu o variabila 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 c u care sa fie nevoia sa lucram. Uneori sunt obiecte
ca System.out. Ele sunt constante statice ca MAX_PRIORITY in java.lang.Thread sau NORTH
in java.awt.BorderLayout. Bineinteles, unele clase au variabile membre publice, ca x si y membri
ai java.awt.Point.
Instantele unei variabile sunt membre a unei clase care apartin unor obiecte individuale;
fiecare obiect are propria sa copie a unei instante de variabila. Jess poate accesa instan te publice
a obiectelor Java folosind functiile get -member si set -member. In acest exemplu, un obiect Point
este alocat si membrii x si y sunt setati si apoi cititi:
Jess> (bind ?pt (new java.awt.Point))
<External – Address:java.awt.Point>
Jess> (set -membe r ?pt x 37)
37
Jess> (set -member ?pt y 42)
42 Jess> (get -member ?pt x)
37

Functiile set- member si get -member functioneaza si pentru variabilele de clasa.
Variabilele de clasa sunt numite si variabile statice in Java. Putem accesa variabilele de clasa
folosind numele unei clase in locul unui obiect ca prim argument pentru set -memb er si get –
member:

Jess> (get -member System out)

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

6.1.10 Exceptii
Metodele Java pot semnala erori prin aruncarea unei exceptii. O exceptie este doar un
obiect Java, s i se intentioneaza a fi tratat ca un mesaj de la codul esuat la apelant. Cand un
constructor sau metoda Java arunca o exceptie, Jess primeste sau prinde mesajul si il face
disponibil utilizatorului.
Cand Jess prinde o exceptie intr -o functie Jess sau me toda Java, actiunea sa implicita este
sa printeze un mesaj detaliat in consola, incluzand una sau doua “stack traces”. De fiecare data
cand se apeleaza o metoda care ar putea arunc a o exceptie, ar trebui sa se furnizeze un handler
pentru a executa un raspuns. Se poate folosi functia try. De exemplu, sa folosim functia parseInt
din clasa java.lang.integer care arunca NumberFormatException daca argumentul nu poate fi
parsat la un intr eg:
Jess> (deffunction parseInt (?string)
(try
(bind ?i (call Integer pa rseInt ?string))
(printout t “The answer is ”?i crlf)
catch
(printout t “Invalid argument” crlf)))
TRUE
Jess> (parseInt “10”)
The answer is 10

6.2. Proiectarea si dezvoltare a unei aplicatii CRUD

Aplicatiile CRUD se ocupa cu proces area datelor afer ente unei aplicatii software care necesita
salvarea persistenta a datelor. Salvarea persistenta a datelor este necesara intrucat la inchiderea
aplicatiei datele trebuiesc salvate, iar apoi la repornire datele trebuiesc din nou reincarcate.
Acronimul CRUD e ste prescurtarea pentru CREATE, READ, UPDATE.

6.2.1 Conexiunea la baza de date

Conexiunea la baza de date se realizeaza cu ajutorul unei clase de tip Singleton asa cum este c ea
de mai jos:
public class Conexion {

private Connection connection= null;
public static Logger logger=Logger. getAnonymousLogger();
private static Conexion instance= null;
private Conexion(){
String dataBase= "jdbc:mysql://localhost/pacients";
String user="root";
String parola="";
try{
Class.forName ("com.mysql.jdbc. Driver");
connection = DriverManager.getConnection( dataBase, user, parola);
if(connection !=null)
logger.info("Conectiune reusita !!!!");
else
logger.info("Conexioune nereusita!!");
}catch(Exception e){
e.printStackTrace();
}
}
public static Conexion getInstance(){
if(instance== null ){
instance =new Conexion();
}
return instance;
}
public Connection getConnection(){
return connection;
}

}

6.2.2 Clasa Pacient

Functia care obtine toti pacientii din baza de date este ilustrata mai jos:

Pentru a insera un pacient se foloseste functia definite mai jos astfel:

Pentru modificare vom utiliza:

Pentru a sterge un pacient vom folosi :

6.2.3 Clasa Repositoy
A comentat [CBC8]: Trebuiesc separate capitol ele de proiectare
de cele de impleme ntare.

Concl uzii

Sisteme i nteligente medicale utilizeaza foarte multe date, cel mai adesea detul de eterogene atat
ca tip cat si ca semnificatie de lucru. Importante sunt in primul rand datele demografice. Aceste
date au fost prelucrate in aplicatia software dezvol tata de catre noi .

Inregistrarile medicale ne ofera o privire de ansamblu a intregului act medical. Sa utilizam o
astfel de multitudine de date nu era scopul nostru si nici nu avea vreo relevanta intrucat aplicatia
dezvoltata este un prototip, si are mai mult scop de dem o, si nu de produs final cae urmeaza a fi
comercializata in industria software de profil.

Java se integreaza usor cu bazele de date MySQL, mai ales in prezenta frameworkului Hibe rnate.
Acesta permite un lucru facil cu datele citite, intr oduse sau modific ate. De asemenea Java se
integreaza usor cu motorul de inferent JESS. Acest motor de inferenta permite speificarea unui
set de reguli care asigura „|inteligenta” aplicatiei. In con cluzie putem spune ca utilizarea
impreuna a limbajului Java alaturi de Hiber nate, MySQL si JESS este o reteta de suces.

Bibliografie

A comentat [CBC9]: Mai multa bibliografi e.