FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT IOAN SLAVICI TIMIȘOARA [612330]
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]. Ciprian -Bogdan Chirila Julea Daniel
TIMIȘOARA
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 sistemulu i 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
1. Introducere
Evoluția tehnologica din ziua de astăzi , 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 dispo zitiv a unuia sau mai multor module care
asigura autonomia si / sau un oarecare grad de inteligenta. Este așadar un proces continu care are
loc care asigura independen ta si funcționarea la standarde înalte .
Acest proces se desfășoară in foarte multe dom enii de activitate, mai ales in cel al serviciilor
publice, si chiar si 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 spitale, deși
cele m ai multe cadre medicale sunt sceptice la utilizarea acestora.
Daca pana nu de mult trebuia sa mergem personal la casa de asigurări de sănătate pentru orice
problem a, astăzi multe dintre ele se pot rezolva simplu prin accesarea portalului casei. Cardul
național de sănătate 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 licență este legata de introducerea ele mentelor de inteligenta artificială in
sistemele medicale dezvoltate in mod curent. Avem in vedere sistemele i nteligente medicale
orientate spre procesarea datelor medicale.
Înregistrările medicale electronice si procesarea lor constituie principalul obi ectiv de cercetare al
acestei lucrări de licență . Ne interesează ce fel de date introducem in aceste înregistrări , si de
asemenea prezentam diferite metode si con cepte derivate din acesta. Toate aceste date sunt
inserate in baze de date care apoi sunt proc esate de către o aplicație Java. Tema proiectului se
refera așadar la ce fel de date introducem si cum reali zam procesarea elementara a acestora.
Procesarea eleme ntara înseamnă operații le CRUD (Create, Read, Update, Delete) care se
realizează asupra datelo r.
1.2 Motivația
Aplicația software a fost realizata pentru a vedea cum se pot introduce date simple des pre un
pacient într-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 context ul utilizării anumitor tehnologii. Noi utilizam o baza
de date MySQL iar datele sunt preluate si operate via frameworkului Hibernate. Aceste date
obținute devin f apte JESS, care apoi sunt preluate de către motorul de inferență JESS pentru a fi
expuse sub d iferite forme de procesare clientului.
Spre deosebire de alte aplicații aceasta combina doua tehnologii: programarea orientata obiect si
programarea bazata pe reguli. Programarea bazata pe reguli este întâlnită in cadrul motorului de
inferență dezvoltat in JESS care operează asupra datelor. Java este utilizata acolo unde se preiau
datele si se oferă spre pro cesare sistemului inteligent oferit de JESS. Datele su nt preluate sau
introduse într-o baza de date MySQL.
1.3 Structura lucrării
Lucrarea se întinde pe aproximativ 60 de pagini si are cinci capitole.
Primul capitol ne prezinta conc eptul de sistem in teligent, si de asemenea ilustrează cu exemple
din robot ica si economie, unde poate fi utilizata inteligenta artificiala in ziua de astăzi .
Cel de -al doilea capitol ne prezinta in detaliu trei sisteme inteligente dezvoltate pentru un context
medical sau d e asigurare a îngrijirii persoanelor la domiciliu. Este v orba de aplicații complexe
care au interfața web, interfața pentru dispozitive mobile, acces la baze date, dar prezinta inovații
si la nivel de dezvoltare hardware.
Al treilea capitol este o incursi une in lumea sistemelor medicale, si se axează pe înregistrările
medicale, ce conțin ele, si cum sunt standardizate dat ele introduse.
Al patrulea ca pitol este legat despre cum a fost dezvo ltat proiectul nostru de licență , 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 t ehnice
necesare pentru ca orice cititor sa poată dezvolta ceva similar.
2. Sisteme i nteligente
2.1 Definiția sistemelor inteligente
Mai întâi, in vede rea înțelegerii ce califica un sistem a fi inteligent , vom discuta atât
concept ele "Inteligenta " cat si "Sistem". Exista foarte multe definiții a ceea ce înseamnă
inteligenta. "Inteligen ta este facultatea de a descoperi proprietățile obiectelor si fenomenelor
înconjurătoare cat si a relațiilor dintre acestea, dublata de posibilitatea de a rezolva probleme noi.
"[1]. O alta definiție se refera l a abilitatea de a realiza un obiect iv. Cu cat un siste m poate sa
ajungă la obiectiv mai rapid cu atât se considera a fi mai inteligent. In acest caz, putem vorbi
despre capacitatea de a învață sa facă acest lucru.
Daca ar fi sa exprimam simplu ce înseamnă un sistem , putem aserta ca un sist em este o
parte fiz ica limitata 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 int eligent ii
aparține lui N.V .Findle r: "Un sistem este considerat ca are proprietatea de inteligenta, pe baza
comportării sistemului, daca se poate adapta singur la situații noi, are capacitate a de a raționa , de
a înțele ge legăturile dintre fapte, de a desc operi înțelesuri si de a recunoaște adevărul . De
asemen ea ne așteptam ca un sistem inteligent sa învețe , deci sa -si îmbunătățească performantele
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 si stem inteligent es te un sistem care are obiective proprii si gândește
in vederea ajungerii la obiectiv, luând decizii bazate pe experiențele avute anterior , învățând
altfel spus prin generalizare.
Unele exemple de sist eme inteligente ar putea fi: Google, r oboti, persoane, o afacere etc.
In domeniul IT, de o perioada buna de timp au fost concepute programe( aplicații ) care
sunt sisteme inteligente complete. Totuși , nu era suficient ca sistemul inteligent doar sa afișeze
informații pe un dispozitiv de ieșire cum ar fi monito rul. Se impun niște sisteme complete care sa A comentat [DJ1]: In bibliografie
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. Vom discuta in cele ce urmează așadar despre robotii humanoizi.
2.2 Rob otul ASIMO
Prob abil unul dintre cei mai populari roboți humanoizi este ASIMO conceput de
compania Honda. Motivul pentru care este printre cei mai popula ri este probabil ca arata foarte
bine din punct de vedere vizua l.
Fig. 1
A comentat [CBC2]: Figurile trebuiesc numerotate
Am arătat ca un sistem in teligent are scop ul de a -si îndeplini obiectivele. In cazul nostru
particular, obiectivul sistemului nost ru, robotul humanoid, este acela de a se comporta cat mai
natur al intr-un mediu uman, adică sa interpreteze si sa imite comportamentul uman.
Asimo nu face excepție , si reușește sa integreze multe funcționalități ce ajuta la
interpretarea lucrurilor din af ara sistemului ce conduc către luarea unor decizii. In cele ce vor
urma vom prezenta câteva dintre acestea.
Una d intre ele este "motion detecting", adică cu ajutorul informațiilor vizuale receptate de
către camera, acesta detectează mișcarea unuia, sau a mai multor obiecte străine sistemului.
De asemenea, in funcție de informația captata, acesta o interpretează , luând o decizie
asupra modului de a reacționa la informația primita. Astfel, humanoidul reacționează nu doar
când primește o comanda vocala, ci si când identifica un comportament uman cunoscut. Astfel,
când o persoana va întinde mana sau va face cu mana, chiar si când indica spre ceva robotul va
răspunde in con formitate cu acțiunea analizata.
De asemenea, robotul știe sa analizeze mediul înconjur ător si obiectele din jur astfel încât
mișcările pe care le va face sa nu pună in pericol nici pe el, nici persoan ele din jur (se ferește de
ciocniri, urc a pe plan incli nat, scări etc).
Sistemul de distingere a sunetelor a fost de asemenea îmbunătățit de-a lungul timpului,
acesta făcând deosebire intre sunete de mediu si sunete umane. Astfel, in cazul in care o persoan a
i se adresează , humanoidul privește spre persoana. U n alt exemplu ar fi acela când are loc un
sunet puternic neașteptat , cum ar fi acela când tuna sau are loc o coliziune intre 2 obiecte, robotul
ațintindu -și privirea spre zona de interes. Mesajele inter ceptate sunt analizate si răspunde fie prin
mișcări ale corpului ( mișcări ale capului, mâini etc.) fie verbal. Din acest punct de vedere poat e
fi asemănat cu un chatterbot avansat.
Totodată , una dintre trăsăturile sale uimitoare este aceea de a distinge trăsăturile fetei,
chiar si a unei persoa ne care se mișcă . In momentul in care poarta o conversație cu cineva, acesta
ii analizează trăsături le fetei si va recunoaște persoana următoarea data când va vorbi cu ea după
nume(in 2002 putea retine maxim 10 pers oane iar acum capacitatea de stocare a cr escut).
Fig.2
Bineînțeles , toate acestea se refera la modul in care robotul știe sa interpreteze mediul
înconjurător , evenimentele si persoanele. Pe de alta parte, s -a investit foarte mult in facilitarea
mișcărilo r robotului si a le face cat mai asemănătoare cu mișcările corpului uman. Pe ntru aceasta
s-au avut in considerare multe aspecte tehnice cu m ar fi păstrarea centrului de greutatea de -a
lungul mișcărilor , ba s -a ținut seama si de influenta degetelor de la pi cioar e in păstrarea
echilibrului. Aici pu tem aminti si de încheieturile care au fost create pentru a -i da libertate de
mișcare . Acestea su nt cunoscute ca "unghi de libertate" si sunt plasate in zona gatului, mâini si
picioare.
De asemenea, humanoidului ii sunt încorporați o mulțime de senzori pentru a interp reta
modul in care ar trebui sa facă mișcarea . Exemple de astfel de senzori sunt sen zorii de
viteza(care analizează viteza cu care ar trebui sa se deplaseze robotul), senzori la suprafața
pământului si senzo ri ultrasonici in zona mediana( aceștia ajuta la i nterpretarea mediului
înconjurător si crearea unei harți in memoria robotului a medi ului in care acesta se afla) si
senzori ai unghiului încheieturilor (pentru controlul mișcărilor ).
Crearea unui siste m int eligent ca acesta a fost cu atât mai grea cu cat tine cont si de
pămâ ntul pe care calca, condiții meteo( vânt), in păstrarea unei poziții de echilibru si a menține o
viteza de mișcare corespun zătoare cerinței de a se asemăna 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 legătură cu schimbul valutar
si 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 sis teme 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 tarile utiliz ează 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 reprezintă standardul
mondial în sectorul bancar
Efectuarea de schimb valutar cu țări străine peste Net SWIFT impune anumite standa rde
pentru mesajul c ompus. Aceste cerințe trebuie să fie construite în sistemel e de informații ale
băncilo r 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 graficu l de dependență din care urmează . Clientul este o
persoana fizică sau juridică, sau un cetățean străin. Prima banca este coordonator de servicii în
care clienții au conturi în valută, si care aceștia își mențin depozitele în valută și cu ajutorul
cărora ef ectuează operațiuni diferite. Aceste bănci sau orice alte instituț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țu l de tranzacție între
banca de start ș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țion ală 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.
Fig. 3
În unele tranzacții de af aceri cu moneda străina 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ți participanții iau parte. De exemplu, dacă un client tr imite o
cerere de plată la o bancă pe ntru 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.
Cumpărarea de valuta la ICM ( Inter-banking Currency Market ) se efectuează numai între
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, medi atorul pentru banca Čačanska (în care este se folosește 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 sa rcini
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ă moti vele 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 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ă afecteze 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 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ă ban ca 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
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 uti lizat î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 considera re mai mulți factori, în
amănunt :
– 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 bănci , sau de la IC M, în funcție de valoarea sa echivalentă temporară? sau
alte interese de afac eri.
– 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 firm a 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 c ontul 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ă firm a
are monedă la unele bănci străine atunc i când alte re surse 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 căutată o altă
bancă (sau bănci) din lanțul bancar unde firma s tră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 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 înregistrate , 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 c are este neces ara pentru o anumită operațiune depinde d e modul de
efectuare a tranzacției. În cazul în care banca deține mon eda prefe rată, doar ordinul de plată și
compensarea sunt necesare, în caz contrar, banca de origine trebuie să aibă comenzi suplimen tare
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 comenz i 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ă impo rtă
mașinării în vederea îmbunătățirii producției în vii tor (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 corec teze personal, sau daca trebuie să
organizeze o consultare telefonică cu un angajat de la firma, sau dacă el t rebuie să trimită înapoi
cererea înapoi la firma. 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 va lutare 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 preze ntat mai sus, rezultă că este foarte greu
sa faci un p rogram procedural care ar face tranzacții, ar pregăti comenzile, ar întocmi
documentele necesare, etc.
Criteriile de decizie construite în DEVEX au fost date de către experți financiari. Figura
următoa re prezintă un set final al parametrilor 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 p e 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 deținute 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 Banca de afaceri are un sold suficient de mare în contul său B
plăți într-o bancă străină spec ifică, în valută străină
necesare pentru plata
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 a nterioară
(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
făcute Depind e 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 Mărfuri pentru consumul în masă (mărfuri cu deficit), repro -E
importate mate riale,
mașini și unelte pentru creșterea producției
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.4 Criteriile pentru det erminarea priorităților de plata in DEVEX
Cunoștințele dobândite sunt rep rezentate î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
profesional 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 transa ctions >= 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ățile efectuării unei plăți prin
aplicarea acestor norme de bază de cunoștințe pentru datele de intrare despre plățile specifice.
A comentat [DJ3]:
A comentat [DJ4]:
3. Sisteme inteligen te medicale
3.1 Proiectul RECIPE
Proiectul de cercetare RECIPE adopta o cercetare metodologica hibrida, bazându -se pe tehnici
non-empiric e. De -a lungul acestui proiect , în pri mul rând se investighează manual execuția
proceselor si apoi se adaugă mai multe tehnologii pentru flux ul de date pe ntru a îmbunătăți
procesul.
La fiecare pas al automatizării , fluxul de date medicale sunt prelucrat e folosind urm ătoarele
procese: analiz a stării proceselor , realizarea unui caz business, reprelucrarea procese lor business
,evaluarea.
In timpul analize i, analistul se concentrează pe puncte slabe din punct de vedere material ,
financiar , informațional sau fluxul proceselor. Pentru a jus tifica orice schimbare in fluxul de
date, trebuie definit un caz business ,in care trebuie stipulate costu rile, așteptările ,riscurile
așteptate a propunerii la care trebuie adaptate. RECIPE permite ca procesele sa fie t estate
manual in domeniul sănătății pentru a sprijini fezabilitatea si profitul. Îmbunătățirea proceselor
se refe ra la faptul ca procesele pot fi evaluate si calibrate cu o întârziere virtual a intre operația in
execuție si cea monitorizata. Evaluarea îmbu nătățirii proceselor are loc prin simpl a comparare
dintre măsurarea metrica după introducerea îmbunătățirii si cea înainte de îmbunătățire . Unele
măsurători se refera la calitatea serviciilor, câștiguri ,costuri , îmbunătățirea stării pacienților si
nivelu l adoptării procesului îmbunătățit .
Pasul 1 :Analiza procesului ( UMMS ). Au fost implementate 3 sisteme :
1) Sistem de mana gement pentru echipamente si provizii
2) Sistemul pentru programări A comentat [DJ5]: RECIPE=?
A comentat [DJ6]: UMMC =?
3) Sistemul pentru depistarea dispozitivelor
Pasul 2:Analiza cazului busine ss. Implementarea fluxului de date se bazează pe o analiza
detaliata a proceselor dintr -o clinica si dezvoltarea unu i proces nou. Cercetări consid erabile au
fost realizate pentru evaluarea proceselor in clinici , oportunități de prioritizare a țintelor, si
analiza celei mai importante oportunități țintă.
Pasul 3:Imbunatatir ea 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 inst rumente a fost implementat folosind
OSWorkflow .OSWorkflow suporta un flux de date bazat pe XML .Acesta permite un fișier
simplu XML sa fie transmis unui flux de date business. Un prototip al fluxului de date prezinta
următorii pași: Chirurgia este pla nificata, OSWorkflow trimite lista de preferințe chirurgicale
asistentelor OR si le cer sa verifice cart -ul, asistentele răspund cu orice element care lipsește ,
elementel e lipsa sunt raportate camerei cu provizii, camera de provizii ia la cunoștința si du ce la
îndeplinire cererea, cererea revine la asistent ele OR.
Avantajele software -ului multimedia pentru a dezvolta capacitățile persoanelor cu
handicap :
este un mediu aud io-vizual, este interactiv, tratamentele sau situațiile pot fi reproduse , aceleași
condiții pot fi reproduse de nenumărate ori ,modul de pr ezentare este realizat in funcție de
problemele întâlnite ,(Mărimea , forma, c ontrastul ,culoarea, înălțimea liniilor , a obiectelor si
fundalul pot fi selectate in funcție de pacient.) poate fi ajustat in funcție de nevoile individuale,
sistemele multimedi a au efect pe mai multe sensuri , putând fi eficiente, poate ajuta creativitat ea,
poate varia, se pot introd uce jocuri in programele multimedia, utilizatorul simte aplicabilitatea,
se poate folosi un fe ed-back audio motivant, poate fi folosit fie in mod indiv idual fie in grupuri
mici de terapie.
In cazul copiilor : părinții îl pot fol osi cu succes ,cel mai impor tant este ca acești copii sa devina
interesați , acest interes sa si -l păstreze pentru o perioa da lunga de timp(Acesta nu este un lucru
ușor de realiza t ,dar prezentările multimedia sunt foarte eficiente in acest sens.),sa fie ca un joc:
copilul sa nu consi dere exercițiul ca o obligație ci sa ii placa.
Problemele apărute de-a lungul dezvoltării procesului si soluțiilor lor A comentat [DJ7]:
1) Deteriorarea vederii si persoa nele cu vedere slaba – vederea perfecta este de 1,vederea
unei persoane cu v ederea deteriorat a este de 0 .1 si 0.3.Est e indicat sa se traseze contururi
groase in jurul obiectelor. Dacă aceste persoane disting culorile bine atunci software -ul
trebuie sa aibă si o funcție de schimbare a culorii obiectelor si a fundalului si de oprire a
animației .
2) Persoane ce pr ezinta o dete riorare a auzului –copii încă de la vârsta de 3 ani trebuie
învățați sa vorbeasc ă ,aceasta continuând si la scoală ca o materie obligatori i pe lângă
celelalte din programa. Dacă ii învățam sa vorbească si sa își înmulțească vocabularul cu
ajutorul jocurilo r 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 prob leme locomotorii – probabil nu pot folosi mouse -ul sau tastatura ,
aceștia pot folosi alte dispozitive de intrare sau dezvoltatorul software -ului trebuie sa
creeze instrumente special de naviga re , d e exemplu utilizatorul trebuie sa folosească un
singur switch sau un buton mare.
4) Persoane cu problem e in vorbire sau fizice – exista software -uri care ii ajut a in
comunica re(in Ungaria se folosește Bliss -ul pentru a imprima, a trimite mail -uri , pe ntru a
scrie propoziții 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 citească un text mai lung.
6) Copii cu problem e mentale si cei ce au probleme cu învățarea ,instrucțiunile si
propozițiile trebuie sa fie simple, informația trebuie sa fie scris a in propoziții simple.
7) Persoanele cu pr obleme in deosebirea culorilor – trebuie sa se tina cont de setările de
culoare.
3.2 Proiectul VIKI:A Virtual Keyboard Interface for th e Handicapped
Proiectul VIKI este un mod de a demonstra eficienta utilizării unui laptop ca fiind o tas tatura
virtual a pentru a accesa un calculator gazda pe care se rulează un software stand ard.
SIL(Laptop cu o Interfață Specializata) furnizează orice conexiune necesara pentru dispozitivele
asistive si pentru orice afișaj pe ecran de care are nevoie util izatorul pentr u a interacționa cu
aceste dispozitive. După introducerea unor date de intr are in SI L, datele sunt trimise apoi in
calculatorul gazda in așa fel încât sa para ca sunt create de către o combinație standard a
tastaturii si a mouse -ului. Software -ul si hardware -ul din SIL sunt realizate in funcție de nevoile
utilizatorilor ,in tim p ce software -ul si hardware -ul din calculatorul gazda rămâne neschimbat.
Proiectul VIKI prezinta 3 faze:
1) Dezvoltarea software -ului necesar pe ntru ca sistemul SIL sa mime ze toate metod ele de
interacționare necesare unei tastaturi si unui mouse standard, pe ntru a exis ta o
comunicare intre SIL si sistemul gazda printr -o interfață serial a. Sistemul SIL rulează pe
Windows si este creat in Visual Basic. Cele doua sisteme se conectează prin p orturile lor
seriale folosind un cablu de modem. Software -ul VKE oferă utilizatorului o reprezentare
a unei tastaturi , pe ecran, care poat e fi manevrata fie din tastatura laptopului sau prin
așezarea si apăsarea mouse-ului cu ajutorul dispozi tivului laptop ului. VKE -ul ofera si un
simulator pentru mouse, care va muta cursor ul mouse -ul gazde i in direcția indicata.
Accesul la bara de meniu a VKE -ului pentru a „customiza ” controlul, prin selectarea
dispozitivului de intrare principal ,setarea culorii f undalului, vit eza mouse -ului,etc.
Interacțiunea poate fi realizata prin un m od de scanare a tastaturii. În acest mod, daca
utilizatorul apasă shift, rândul este selectat si selectarea continua prin apăsarea unui
buton de -a lungul rândului a doua apăsarea a shift-ului v a selecta cheia ce se transmite
computerului gazda. Sistemul S IL poate fi utilizat si ca un sistem de sine stătător in timp
ce încă se folosește software -ul VKE. Aceasta opțiune permite transmiterea informației
către o aplicație ce rulează pe laptop. In ur ma acestui lucru VKE -ul obține ID-ul
aplicației ceea ce perm ite VKE -ului sa transmită date aplicației . Pentru ca VKE -ul sa
realizeze acea sta acțiune trebuie sa știe către ce aplicație sa transmită datele. Acesta ofera
o lista a tuturor aplicații lor ce exis ta pe hard -ul laptopului, permițând utilizatorului sa
aleag ă una pentru a o executa. Din partea gazdei , un program TSR(terminate -and-stay-
resident) este necesar. Comunicator -ul primește semnale SIL ca date de intrare prin portul
serial al gazdei ,si îndreaptă aceste semnale către alte programe ce rulează pe gazda ca
date de intrare. Comunicator -ul trebuie sa aibă control asupra sistemului gazda, chiar
daca aplicația software a fost începuta dar suspendata apoi.
2) Înlocuirea comunicării seriale cu o c omunicare dire cta cu portul tastaturii sistemului
gazda , eliminân d astfel nevoia programului de comunicare TSR a gazdei. Acest lucru va
face SIL -ul po rtabil, permițându -i SIL-ului sa se conecteze la orice gazda compatibila.
3) Înlocuirea conexiunii hard ware dintre SIL si sistemul gazda cu un sistem wireless. Ideea
este de a înlocui o tastatura wireless cu un laptop care sa îndepline ască aceleași atribuții
ca si tastatura.
3.3 Proiectul Autonomous Life
S-au remarcat 6 scenarii in c are sa se încadreze persoane le cu dizabilități : apelul vocal, mesajul
existent, mesajele text, „am nevoie de ajutor”, „m -am pie rdut” , „nu mă simt bine”.
Din analiza acestor scenari i ,nevoile sistemelor de comunicare mobile pentru persoanele cu
dizabilități si pentru persoanele in vârsta se clasific a in următoarele categorii:
• Comunicare personala : folosita pentru persoanele cu p robleme locomotorii. Acesta
implica imposibilitatea ace stor persoane de a se deplasa intr -un timp scurt pentru a putea
răspunde si modul de folosire a telefo anelor cu fir.
• Securitate: Persoanele în vârstă si cele cu prob leme locomotorii întâmpina restricții care
pot duce la o situație de potențial risc care creste in momentul in care aceștia doresc sa
aibă un mod de viată independen t.
• Integrarea sociala. Accesu l la educație si pe piața forței de munca in ultimii ani
telefoanele cu fir au permis un acces l a informație si la oportunități de angajare prin
servi cii telematice ,ca de exemplu lucrul prin telefon sau educarea prin telefon a
persoanelor cu dizabilități ajutând la integrarea sociala si autonomie. Telefoanele mobile
sunt utile in zonele izolate in care telefonia fixa nu exista.
• Autonomia: Combinație dintre comunicarea personala, securitate si accesul la serviciile
integrative per mite persoanelor in vârsta si celor cu dizabilități sa duca un mod de viață
independ ent.
Asigurarea serviciilor cu ajutorul telefoanelor mobile poate duce la un risc social si eti c pentru
persoanele cu dizabilități si pentru persoanele in vârsta . Cele mai critice sunt: izolarea soci ala,
pierderea autonomiei personale, pierderea intimităț ii, barierele economice.
4. Date medicale electronice
4.1 Concepte gen erale
4.1.1 Definirea principalelor concepte legate de datele medical e electronice:
Electroni c Health Recor d[2] este o înregistrare electronică lon gitudinală 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 demografic e ale pacie nților,
evoluția pacientului, probleme , medicamentație, semnele vitale, ant ecedente 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 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 faptul că un EHR este creat și întreținut în cadrul u nei
instituții, cum ar fi un spital, clinică sau cabinet medical . Un EHR nu este o înregistrare
longitudinală a tuturor serviciilor medicale furnizate pentru pacient la toa te nivelel e de-a lungul
timpului. Înregistrăril e longitudinale pot fi păstrate într -un sistem de informații de sănătate la
nivel național sau region al.
Electronic Pa tient Record (EPR) este un concept în evoluție definit că o colecție
electronică sis tematică d e informații privind sănătatea unui p acient 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 pacie ntului, creată
în spitale și medii ambulatorii, care este sursă de date pentru E HR. 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ți ile medicale ale pacientului persoanel or
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 pent ru 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 da te de sănătate. Există mai multe defi niții ale conceptului, însă cea pre zentată 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 destinat e utilizării de către furnizorii de s ervicii
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 info rmaț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 medic ale. Standardul CCR se dorește un
rezumat clar al stării de sănătate a u nui pacient. El reprezintă o modalitate de a cre ea 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 modalitate de a trimite electronic a ceste 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, me dicamente, alergii,
precum și a planu lui de îngrijire. Acestea reprezin tă 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 cre area cât mai facilă a rezumatului stării medi cale a pacientului de
către un med ic 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 ori ce 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) [6] este o înregistrare electronică a pacientului
care este situată într -un sistem spe cial concep ut pentru a sprijini utilizator ii 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 med icale (de exemplu: sprijinirea decizi ilor
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 labor atoare , 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 meca nisme tipice de
intrare și d e ieșire.
Computerized Medical Record (CMR) este o înregistrare medicală electronică crea tă
într-o organizație care oferă îngrijire medicală, c um ar fi un spital sau cabinetul medical.
Înregistrările medicale electronice tind să fie parte dintr -un sis tem l ocal s tand-alone de informații
privin d sănătatea, care permite sto carea, 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 niv ele de
tehnologie EMR, însă doa r 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ă gene raț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 Assoc iation (AHI MA) a publi cat 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 (EP R), El ectronic Me dical 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 imati v 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 sist em de secur itate va d iminua 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 c aptarea 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 eficientizarea tratamentului, asistenței să
raporteze o reacție adversă, ce rcetă torul ui să real izeze 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 eserv i
nevo i diferit e. Scopul este de a colectă datele o singură data și pentru a fi utilizate de mai multe
ori.
O înregistrare electronică me dicală poate fi creață pentru fie care serviciu pe care un
pacient îl primește de la un departament auxiliar, cum ar fi cel de ra diologie, 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 ocardiogr afie), notelor asistentelor, rețetelor medicilor etc. De cele
mai multe ori aceste înregistrări electronice nu sunt integrate, c i sunt capturate și rămân în
sistemele silo (sisteme incapabile să funcționeze în reciprocitate cu alte sist eme c onexe) , care au
fiecare prop riul lor sistem de autentificare și de identificare a pacientului.
Vânzătorii de sisteme silo pot utiliza sta ndarde diferite pentru vocabulare, pentru
identificarea utilizatorului, precum și pentru identificarea pacie nților. Trebuie subl iniat faptul că
nu există acces unificat la aceste sisteme. Un utilizator din domeniul medical ar trebui să
deschidă 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 rezultate le electro nice
sunt d isponibile, 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 disparat e nu pot fi agregate într -o
afișare integrată, cum ar fi foaia de flux al analizelor medicale.
Dacă personalul medical a r 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 a fiind număr ul scăzut de celule a lbe”, deoar ece cele
două concepte ar fi codificate că și termeni sinonimi. Pentru a rezolvă variațiile de vocabular
trebuie utilizat un sis tem 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țiile despre e voluț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ă poate fi crea tă 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 ident ificat 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 c omponente
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
sistem integrat de date depind de struct urile 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 personalizat e sau a unei interfețe care permit personalului medical să acceseze
sistemele de tip silo printr -un portal. Că alternativă E HR-ul poate incorpora doar câteva din
serviciile auxiliare.
4.2. Componentele sistemului de adm inistrați e
Î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 i denti 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 alfanumer ica, 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 face legătu ră cu 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 I ndex) . Evoluția sistemelor 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 „stand alone” care sunt i nterfaț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, p recum ș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 dispozitive și analizoare care sunt utilizate în proce sul 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 Infor mation 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 i nclud : 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
gestion ează 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
Farmac iile 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 u nui r aport di n
2005 în medie 31% din toate rețetele electronice sunt reintroduse în sistemul farmaceutic.
4.2.4 Ordine me dicale computerizate
Ordinele medicale computerizate (CPOE – Computerized Physician Order Entry)
permite per sonal ului m edical 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 comp lete prin c are se pot
comanda , 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 CPO E”.
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. Han dler, î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 n oi 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, efectul net al CPOE poate să
încet inească med icii”.
4.3 Documentația medicală
Documentația medicală electronică crește valoarea EHR prin furnizarea de captare
electronică a notelor medicale, a evaluărilor pacient ului și a rapoartelor medicale, precum și a
înregist rării admin istră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ă c u reproiectarea fluxului de lucru. Sistemul de documentație medicală ar e
beneficii substa nț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 o bserv ație (semne v itale, intrări și ieșiri, liste de probleme, M AR);
• Rezumate de externare;
• Transcriere documente manageriale;
• Sumar dosarele medicale;
• Împuterniciri ale decizi ilor de asistentă medicală;
• Diagrame de urmărire a pacien tului;
• Dosarele medicale (in clusiv autorizații);
• Credenț ialele 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 f luxul de informați i medicale si utilizate
pentru a genera in timp real alerte datorate modificării stării pacientului. Haugh susține ca “la
Cedars -Sinai Medical Center, Los Angeles, de exemplu, pompele de medicamente intravenoase
conectate la s istemul de informații medicale realizează verificare automata a dozelor si a
documentației pentru managementul medicației . Toate sistemele de monitorizare fiziologice sunt
in rețea , iar datele priv ind pacienții 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 încorporează un produs
comercial ce ofera in timp real informații de la secția de mo nitor izare intensi va si alte secții ”.
4. 4 Datel e din EMR
• datele demografice ale pacientului (adresa, număr de telefon etc.);
• istoric medical, examinări , rapoarte de urmărire a sănătății si bolii;
• medicamente, lista de alergii, imunizare;
• rezultatele testelor de labor ator;
• imagini radiologice, raze X, tomografie computerizata etc.;
• fotografiile de la endoscopie, laparoscopie sau fotografii clinice;
• informații despre medicamente, inclusiv reacții secundare si interferente;
• recoman dări pentru situații medicale deoseb ite;
• înregistrarea listei de programări si a altor memento -uri;
• facturi;
• eligibilitate;
• testamente, împuterniciri .
Doua clase specifice de date pot fi stocate in EMR. Acestea se încadrează fie in categoria
monitorizare di screta, fie in mo nitorizare co ntinua.
Monitorizarea discreta poate fi făcută într-o maniera ad -hoc, asincrona, pe când
monitorizarea continua a unui pacient se efectuează sincron. Marea parte a înregistrărilor pe
suport de hârtie sunt in curs de înlocuire cu înregistrări electronice , unde personalul medical
poate introduce informații manual sau si in mod automat.
Înregistrările medicale electronice sunt întreținute de către instituția medicala si urmăresc
pacientul pe parcursul tuturor etapelor de dia gnosticare s i tratament. Mai m ult, acesta înregistrare
medicala este accesibila întregului personalul autorizat. Un beneficiu evident al acestei abordări
este faptul ca spre deosebire de înregistra pe hârtie , înregistrarea medicala electronica poate fi
accesata din m ai mu lte locații 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 conformez e anu mitor standard e î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 destina tă ilustrări i loc alizării relat ive a hardware -ului într -o
întreprindere care conține un CPR (Computer -based Pa tient 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 sun t combinate î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 utilizator ilor prin intermediul unei instanțe Web a aplicației CPR.
Componente client sunt reprezentate prin simbolurile unor calculatoare laptop, wireless.
Picto grama unui client desktop arată posibilă utilizare de către perso ane fizice în birouri (de
exempl u: 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 informații în si stemul 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 utilizatorului, ap oi 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 p relucrarea 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 baza t pe standarde, pre cum 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 structurate generic din ca re 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 E HR :
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 pr ocesor 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 s istemului. 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 sa u respinse la intra rea în bază de date. “ Curățarea 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 t ipuri 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 analiza te toate caracteris ticile 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ă defectelo r
intolerabile în c adrul datelor.
5. Specificațiile aplicației
5.1. Schema si descriere a aplicației
Fig. 5 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 J ava. 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 su nt salvate într-o bază de date de tip MySQL unde se executa operațiile de
creare, citire, update si ștergere .
Scopul acestui sistem prezentat este de a simplif ica munca cadrelor medicale. Această
aplicație pune la disp oziția medicilor o multitudine de in formații despre pacienți , boli si
investigațiile efectuate.
5.2. Funcționalitățile aplicației
Aplicația adresată tuturor utilizatorilor interesați prezinta urm ătoarele funcționalități:
– Adăugarea unui nou pacient.
– Spec ificarea adresei la care locuiește pacientul.
– Modificarea / ștergerea datelor despre pacient, respectiv adresa acestuia.
– 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 si bolile asociate.
5.3. Diagrama Gantt
Diagrama Gantt este folosita pentru a ave a o organizare și o planificare eficienta a
etapelor de dez voltare a aplicaț iei.
Diagrama Gantt se folosește 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 de sfășurării unui proiect sunt prezentate în diagrama de mai jos.
Fig.6 Diagrama Gantt
5.4. Analiza de risc
În caz ca apar unele defecțiuni ale elemente lor de interfațare care se pot defecta, se poate
proceda in următorul fel:
1. Riscul situațiilo r imprevizibile:
Riscul de disponibilitate este riscul asociat pericolelor naturale, dezastrelor, căderilor de sistem
care pot conduce la pierderi definitive ale da telor, aplicațiilor , în absenta unor proceduri de
monitoriz are a activității , a planurilor de re facere în caz de dezastre.
Situațiile neprevăzute mai apar si in urma încărcării de imagini în format necorespunzător sau
introducerea de text cu caractere necu noscute de către 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 dispoziție un server de back -up la fel ca al aplicaț iilor web. Dacă s e
introduc spre exem plu 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 ca 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
hardware.
4. Riscurile de conformitate:
Încălcarea regulamentelor o ri a politicilor int erne 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;
– Investiție mica;
OPOR TUNITĂȚI AMENINȚĂRI
– Concurența foarte crescuta;
– Apariția unui software
asemănător cu acesta ;
– Atracție slaba a posibililor
investitori.
Fig.7
6. Proiect area si d ezvolt area platformei software
6.1 Integrarea Java & JESS
Cele mai importante trăsături a Jess -ului sunt acelea care ii 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
integram Jess in orice aplicație Java, serv let, applet sau orice sistem . De asemenea, de la limbajul
Jess, întreaga 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 interacționa si in alt mod cu Java fără sa scriem cod Java.
Jess e ste un fel de limbaj de scripting pentru Java. Înafara de folosirea Jess -ului pentru
construirea sistemelor bazate pe reguli, putem folosi Jess si pentru interacționarea cu API -ul Java
sau chiar pentru a construi aplicații întregi .
6.1.1 Crearea obiectelo r Java
Deși 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 d e cumpărături , dar mai
degrabă este nevoie de ceva ca HashMap pentru a retine u n tabel cu preturile pentru cumpărături .
HashMap permite cu ușurință sa vedem un preț a oricărui articol din tabel.
Funcția Jess new ne permite sa cream instanțe a claselor Java . De exemplu, put em sa
cream un HashMap Java si sa îl reținem într-o variabila 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.Val ue care rețin
obiecte Java arbitrare. Când afișăm un tip EXTER NAL_ADDRESS, pute m vedea un string care
conține numele clasei. In schimb ne putem aștepta ca Jess sa apeleze metoda Java toString asupra
obiectului conținut – daca Jess face asta, oricum , rezul tatul ar fi confu z. Un obiect
java.lang.Integer si o valoare J ess de tipul RU.I NTEGER acționează foarte diferit, dar daca Jess
folosește toString pentru a afișa obiecte EXTERNAL_ADDRESS, ambele scriu ca un număr .
In Java, putem evita folosirea prefixelor pachetelor cu cheia import. Jess are o funcție
import pe ca re o putem folosi pentru următoarele :
Jess> (import java.util.*)
TRUE
Jess> (bind ?prices (new HashMap))
<External – Address:java.util.HashMap>
Acest exemplu folosește caracterul “*” ceea ce înseamnă “importa toa te clasele din acest
pachet”, dar se poate de asemenea impo rta doar o clasa la un moment dat folosind întregul nume.
Ca si in Java, întregul pachet java.lang este importat implicit, astfel se pot crea obiectele Integer
si String fără importarea 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 constr uctor si ii pasam nu mere, Jess va face următoarele :
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 construiască instanțe a claselor pe care le definim,
trebuie sa declaram si clasa si constructorii publici.
Când apelam o metoda Java, Jess convertește argumentele de la tipul de data Jess la tipul
Java. Când convertim astfel, Jess are un ele idei cu tipul țintei (target type). Tipul țintei este tipu l
Java de care es te nevoie într-o situație data. In exemplul cu HashMap, tipurile țintă sunt int si
float, pentru ca aceștia sunt tipurile parametrilor formali a singurului constructor HashMap c are
ia doua argument e. Când pasam un argument la un constructo r sau metoda Java , Jess are obiectul
java.lang.Class care reprezintă tipul parametrului formal si un obiect java.Value care conține
valoarea pe care am pasat -o si vrea sa întoarcă conținutul lui Value in ceva asign abil tipului
numit de Class. Deci simbolul TRUE poate si pa sat unei funcții care cere un argument boolean,
sau uneia care are un argument de tipul String, si apelul ar avea succes in ambele cazuri.
6.1.3 Apelarea metodelor Java
Daca avem o referința spre un obiect Java într-o variabila Jess, pu tem invoca orice
metoda a obiectului folosind funcția call. De exemplu HashMap.put asociază o cheie cu o
valoare, si HashMap.get caută o valoare după o cheie data. In exemplul de mai jos, cheil e sunt
numele articolu lui de cumpărături si valorile sunt pret urile:
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 funcției call este obiect ul 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 permis lui
Jess doar sa o afișeze . Adesea, totuși , dorim sa facem ceva cu tip ul returnat: sa îl legam la o
variabila sau sa apelam alta metoda asupra lui. Jess convertește valorile returnate a metodelor
Java in tipuri Jess.
6.1.4 “Nesting”ul apelul funcțiilor si “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ăr cata cu “bagaje”.
Partea buna este ca Je ss ne permite sa omitem:
(?prices put bread 0.99)
Când primul element a unui apel de funcție este un obiect Java, Jess își asuma o metoda
pentru a include simbolul call si invoca o funcție asupra obiectului. Acest lucru funcționează
chiar daca primul ele ment 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 variabila, si adaugă o pereche
nume/va loare. Trebuie sa fim atenți la apelul funcțiilor “nesting” in acest fel; combinând logic
operații separate într-o singura linie de cod ne putem îngreuna înțelegerea problemei. Pentru
multe probleme call este opțional . Putem sa îl ignoram când apelam metode statice.
6.1.5 Ape larea metodelor statice
Metodele statice a unei clase din J ava sunt acele metode care pot fi apelate fără referință
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 întregul nume java.lang.Thread pentru ca clasele din pachetele
java.lang sunt in mod implicit i mportate in Jess.
Când apelam o metoda statica, trebuie sa inc ludem numele funcției call; cel mai adesea
call este folosit pentru invocarea metodelor statice. Jess include alte funcții , similare cu call,
pentru a ne ajuta sa invocam alte categorii de metod e.
6.1.6 Apelarea m etodelor 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 date le lor. Metode care seamănă cu următoarele 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 numiți accesatori si mutători sau getteri si setteri. Sunt foa rte comuni in Java
si formează o parte imp ortanta a specificați ei JavaBeans. Multe din clasele bibliotecilor Java (in
special din bibliotecile grafice) folosesc aceasta metoda numind -o convenție .
Jess include funcțiile set si get, care pot fi folosite ca o alternative la call pentru setteri si
getteri. Următoarele perechi de apeluri de funcții 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 M e”)
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 funcțiilor set si get. Pentru a obține nume le
propriu, trebuie sa mutam prefixul din numele metodei Ja va si sa transformam litera majuscula
inițiala a restului de nume in litera mica. Singura excepție este pentru nume ca getURL, unde
numele propriu este URL cu toate literele maj uscule. Aceasta conv enție este aceeași ca sic ea
folosita de specificația JavaB eans.
6.1.7 Utilizarea tablourilor
Tabelul cu preturile cumpărăturilor poate fi si o lista simpla de cumpărături . Putem folosi
Map pentru colecția de chei si apoi sa convertim aceea colecție int-un tablou. Daca putem
converti acel tablou la o lista simpla in Jess, putem sa recream lista de cumpărături . A comentat [DJ8]:
Jess convertește automat tablouri in liste simple (Values de tipul RU.LIST). Putem folosi
metoda toArray din java.util.Collecti on p entru a extrage toate cheile din hashMap într-o lista
Jess:
Jess> (bind ?gr ocery-list ((?prices keySet) toArray))
(bread peas beans)
Daca dorim sa punem lista de cumpărături intr-un meniu pop -up, putem sa consideram
lista de articole ca un argument al co nstructorului clasei javax.swing.JComboBox. JComboBox
are u n tablou ca si ar gument al constructorului, dar Jess convertește automat lista simpla înapoi
intr-un tablou:
Jess> (import javax.swing.JComboBox)
Jess> 9bind ?jcd (new JComboBox ?grocery -list))
<External -Address :javax.swing.JComboBox>
Acest sistem lucrează bine pentru ta blouri mici, dar convertirea intre tablouri si liste este
ineficienta pentru tablouri mari, pentru ca structura de date Jess care reprezintă lista simpla
trebuie creata sau di strus a la fiecare co nversie. 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 Je ss.
De asemenea Jess nu are o interfață speciala pentru lucrul c u tablouri multidimensionale ,
deci, din nou, codul Java poate fi necesar. Se pot scrie si funcții Java normale si apoi sa le apelam
folosind tehnici descrise mai sus, sau putem folosi funcții scrise in Java pentr u a extinde însuși
limbajul Jess.
6.1.8 Cum alege Jess intre metodele supraîncărcate
In Java nu se poate stoca un float intr -un HashMap, dar in Jess se poate stoca un float –
pentru ca Jess convertește automat numărul pe care noi îl furnizam intr-un java.l ang.Double. In
cele mai multe cazuri, aceast a conversie este folositoare; dar ocazional cauzează probleme. O
problema ar fi când avem nevoia sa apelam o metoda dintr -un set de metode Java supraîncărcate . A comentat [DJ9]:
Un nume de metoda Java se spune ca este supraîncărc ată daca metode multiple cu același
nume, da r cu o lista de a rgumente 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 in
clasa PrintWriter:
void p rintln()
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)
Când apelam o metoda supraîncărcată in codul J ava, compilatorul Java alege cea mai
specifi ca metoda supraîncărcată aplicabila.
Jess este mai relaxat in a alege intre supraîncărcări pentru ca nu trebuie sa aibă strict
același tip de informație pe care trebuie sa îl aibă Java. Un exe mplu simplu este: uitând-ne la lista
de metode println supraîncărcate , putem obs erva versiunea si pentru double si pentru float. Jess
are doar un singur tip de float.
Când apelam o metoda supraîncărcată ca println, Jess se uita la fiecare supraîncărcare in
parte, încercând sa potrivească tipul parametrului metodei cu tipul argumentelo r date. Prima
supraîncărcare pe care o găsește Jess care poate fi invocata cu lista de argumente, va fi apelata.
Jess nu caută după o buna potrivire , ci folosește prima potrivire găsita .
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 java.io.PrintWriter.prinln.
Uneori, se poate sa dorim o anumita supraîncărcare a unei metod e, dar sa nu poată fi posibil. De
exemplu, daca pasam strin gul “TRUE” unei m etode Java care este supraîncărcată sa ia fie
argumentul boolean, fie String, este imposibil sa prevedem care supraîncărcare o va alege Jess.
In aceste cazuri, putem recurge l a folosirea unei clas e explicite. De exemplu, sa presupunem ca
in acest caz dorim sa invocam supraîncărcarea boolean, dar Jess apelează pe cea String; creând si
pasând obiectul java.lang.Boolean ar trebui sa se rezolve problema, pentru ca Jess va converti
autom at java.lang.Boo lean 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 membre statice a unei clase. Jess ne
permite acest lu cru.
6.1.9 Accesarea datelor membre Java
Unele clase Java au va riabile 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. Bineînțeles , unele clase au va riabile membre publice, ca x si y membri
ai java.awt.Point.
Instanțele unei variabile sunt membre a unei clase care aparțin unor obiecte individuale;
fiecare obiect are propria sa copie a unei instanțe de variabila. Jess poate accesa instanțe publice
a obi ectelor Java folosind funcțiile get-member si set -member. In acest exemplu, un obiect Point
este alocat si membrii x si y sunt setați si apoi citiți:
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
Funcțiile set-member si get -member funcționează 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 argumen t 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 Excepții
Metodele Java pot semna la erori prin ar uncarea unei excepții . O excepție este doar un
obiect Java, si se intenționează a fi tratat ca un mesaj de la codul eșuat la apelant. Când un
constructor sau metoda Java arunca o excepție , Jess primește sau prinde mesajul si îl face
dispon ibil utilizatoru lui.
Când Jess prinde o excepție într-o funcție Jess sau me toda Java, acțiunea sa implicita este
sa printeze un mesaj detaliat in consola, incluzând una sau doua “stack traces”. De fiecare data
când se apelează o metoda care ar putea arunc a o excepție , ar trebui sa se furnizeze un handler
pentru a executa un răspuns . Se poate folosi funcția try. De exemplu, sa folosim funcția parseInt
din clasa java.lang.integer care arunca NumberFormatException daca argumentul nu poate fi
parsat la un întreg :
Jess> (deffu nction 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 dezvo ltare a unei aplicații CRUD
Aplicațiile CRUD se ocupa cu proces area datelor afer ente unei aplicații software care necesita
salvarea persistenta a datelor. Salvarea persistenta a datelor este necesara întrucât la închider ea
aplicației datele trebuiesc salv ate, iar apoi la repo rnire datele trebuiesc din nou reîncărcate .
Acronimul CRUD este prescurtarea pentru CREATE, READ, UPDATE.
6.2.1 Conexiunea la baza de date
Conexiunea la baza de date se realizează cu ajutorul unei clase de tip Singleton așa cum e ste cea
de mai jos:
public class Conexion {
private Connectio n 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.printStackTra ce();
}
}
public static Conexion getInstance(){
if(instance ==null ){
instance =new Conexion();
}
return instance ;
}
public Connection getConnection(){
return connection ;
}
}
6.2.2 Clasa Pacient
Fig.8
Functia care obține toți pacienții din baza de date este ilustrata mai jos:
Fig.9
Pentru a inser a un pacient se folosește funcția definite mai jos astfel:
Fig.10
Pentru modificare vom utiliza:
Fig.1 1
Pentru a șterge un pacient vom folosi :
Fig.12
6.2.3 Clasa Reposito ry
Fig.13
A comentat [CBC10]: Trebuiesc separa te capitol ele de proiect are
de cele de impleme ntare.
Concl uzii
Sisteme i nteligente medicale utilizează foarte multe date, cel mai adesea destul de eterogene atât
ca tip cat si ca semnificație de lucru. Importante sunt in primul rând datele demografice. Aceste
date au fost prelucrate in aplicația software dezvol tata de către noi.
Înregistrările medicale ne oferă o privire de ansamblu a întregului act medical. Sa utilizam o
astfel de multitudine de date nu era scopul nostru si nici nu avea vreo relevanta întrucât aplicația
dezvoltata este un prototip, si are mai mult scop de dem o, si nu de produs final ca re urmează a fi
comercializata in industria software de profil.
Java se integrează ușor 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
integrează ușor cu motorul de inferent JESS. Acest motor de inferență permite spe cificarea unui
set de reguli care asigura „|inteligenta” aplicației . In con cluzie putem spune ca utilizarea
împreuna a limbajului Jav a alături de Hiber nate, MySQL si JESS este o rețeta de succes .
Bibliografie
[1] https://ro.wikipedia.org/wiki/Inteligen%C8%9B%C4%83 .
A comentat [CBC11]: Mai multa bibliografi e.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT IOAN SLAVICI TIMIȘOARA [612330] (ID: 612330)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.