Un sistem distribuit cu baze de date pentru monitorizarea glaucomului

Introducere

În ziua de astăzi, calculatoarele reprezintă un factor cheie în introducerea tehnologiei în practica medicală clinică. De la primele încercări de introducere a calculatoarele (sfârşitul anilor 80) şi până în prezent, schemele de înregistrare electronică a pacienţilor (EPR) şi sistemele de administrare a bazelor de date medicale (eng. Medical Database Management Systems – MDBMS) au evoluat în permanenţă. Aşa se face ca astăzi, în majoritatea ţărilor europene, serviciile naţionale de sănătate investesc mari sume în tehnologia informaţiei (eng. Information Techonology - IT). Acest lucru avantajează foarte mult medicii, care utilizează din ce în ce mai mult domeniul IT în practica lor medicală.

Peste tot în lume, sistemele de clasificare a pacienţilor (eng. Patient Classification Systems – PCS) au ca scop planificarea, evaluarea, administrarea fondurilor sau controlul resurselor din spitale. Creşterea necontrolată a cheltuielilor medicale de la sfârşitul anilor 80 din US a determinat adoptarea unui sistem de finanţare bazat pe cazuri. Au apărut astfel instrumente de monitorizare a calităţii serviciilor medicale (eng. Diagnostic Related Groups – DRG) care au fost dezvoltate de cercetătorii Universităţii Yale încă de la sfârşitul anilor 60 pentru a ajuta atât medicii cât şi personalul medical. Aceste instrumente s-au dovedit a fi foarte utile şi din anul 1983 au devenit singurul sistem utilizat în domeniul medical din US pentru a plăti spitalele. DRG sunt utilizate astăzi, nu numai pentru a clasifica diferitele tipuri de pacienţi, ci şi pentru a uşura implementarea sistemelor necesare suportului administrativ IT, pentru a crea stimuli economici şi pentru a evalua eficienţa spitalelor. DRG permit clasificarea pacienţilor pe baza diagnosticelor, a analizelor medicale sau a altor tipuri de date (în funcţie de complexitatea cazurilor) şi corelarea tipurilor de pacienţi trataţi de un spital cu cheltuielile necesare [1]. Informaţiile pacienţilor necesare în clasificările DRG sunt vârsta, sexul, perioada internării, diagnosticul principal si cele secundare, tratamentul şi starea de sănătate la externare. Aceste date definesc sistemul de clasificare DRG.

Utilitatea DRG a făcut ca într-un număr mare de ţări sisteme similare să fie implementate. Guvernul României a implementat încă din anul 2002 un sistem de clasificare bazat pe DRG pentru a asigura administrarea spitalelor a căror număr a crescut foarte mult în ultimii ani (276 spitale până în 15 aprilie 2005).

Spitalul Clinic Judeţean din Craiova a fost încadrat printre spitalele importante care au beneficiat de implementarea sistemului încă din faza pilot. Astăzi este utilizată versiunea 4.0 a programului DRGNational care este distribuit prin intermediul agenţiilor judeţene. Înregistrarea electronică a unui pacient (una singură pentru întreaga perioadă în care acesta stă în spital) se face în concordanţă cu noile fişe medicale introduse de Ministerul Sănătăţii şi Familiei. Odată colectate, datele sunt adăugate într-o bază de date care este trimisă lunar către departamentul DRG aflat în Institutul Naţional de Cercetare-Dezvoltare în Sănătate, Bucureşti.

Având disponibil un sistem complet de administrare a bugetelor spitalelor, tendinţa generală a fost de a se trata în cadrul spitalelor doar pacienţii cu boli severe, în timp ce tratamentele comune să fie făcute în afara spitalelor. Pacienţii şi familiile acestora au astfel mai multe responsabilităţi în timpul tratamentului, iar urmărirea modului în care acesta este respectat poate să devinăo sarcină foarte dificilă pentru un medic. În acest caz, o simplă extensie sau o aplicare a unei scheme EPR în cadrul unui sistem informatizat dintr-un spital (eng. Hospital Information System – HIS) nu poate fi posibilă. Experienţa noastră în HIS ne-a arătat că schemele de înregistrare electronică a pacienţilor sunt legate în momentul de faţă numai de administrarea unor lucruri simple cum ar fi programarea consultaţiilor şi nu intervin în procesul clinic sau decizional. Bazele de date demografice pentru pacienţi, cunoscute şi sub numele de sisteme de administrare a pacienţilor (eng. Patient Administration Systems – PAS), nu au capacitatea de a fi partajate sau de a fi exploatate simultan de diferite programe sau de mai multe replici ale aceluiaşi program.

În cazul bolnavilor de glaucom, această limitare a PAS reprezintă cauza imposibilităţii de urmărire a pacienţilor în zona acoperită de Spitalul Clinic de Oftalmologie din Craiova. Această zonă se întinde pe 5 judeţe şi monitorizează în jur de 2000 de pacienţi bolnavi de glaucom. Mulţimea de cabinete oftalmologice private, de clinici şi, implicit, de înregistrări oftalmologice fac din această zonă un mediu distribuit neomogen în care capacităţile cabinetelor sunt limitate şi nu pot administra circulaţia informaţiei pacienţilor.

După cum se poate vedea şi în tabelul şi graficul de mai jos, numărul de cazuri de glaucom creşte uşor în fiecare an. Părerea noastrăeste că această creştere este rezultatul examinărilor mult mai atente care au dus la diagnosticări mult mai precise a cazurilor existente şi nu este cauzată de o creştere semnificativă a numvărului de afecţiuni.

Tabelul 1. Cazurile de glaucom primar cu unghi deschis (eng. Primary Open Angle Glaucoma) GPUD, pe ani.

Figura 1 Procentajul noilor cazuri de GPUD, pe ani.

Numărul mare de cazuri de glaucom şi tratamentul complex ce trebuie aplicat bolnavilor au dus la necesitatea unui sistem informatic care sa-i asiste pe medici în noua situaţie caracterizată prin distribuţia pacienţilor în afara spitalelor. Scopul nostru iniţial a fost dezvoltarea şi implementarea rapidă a unui astfel de sistem care să ajute medicii. Pentru a realiza acest lucru au fost utilizate metode rapide de dezvoltare si programarea extremă.

Material şi metodă

În specificaţiile sistemului nostru, termenul de “glaucom” se referă la un grup de boli care au caracteristici comune : creşterea presiunii intraoculare care duce la atrofierea capului nervului optic şi scăderea câmpului vizual, evoluţie insidioasă, lentă şi absenţa durerii [2] [3]. Tensiunea intraoculară (eng. intraocular pressure - IOP) crescută, comparativ cu toleranţa individuală (limitele normale) conduce la atrofia capului nervului optic şi alterarea câmpului vizual. Glaucomul primar cu unghi deschis (GPUD) este insidios la instalare, cu evoluţie lent progresivă şi fără dureri. Deoarece acuitatea vizuală este în general modificată în stadiile târzii, avansate ale bolii, afecţiunea progreseazăfără simptome evidente pentru pacient [2]. Se estimează că 1-2% din populaţia de peste 40 de ani a judeţului nostru are glaucom primar cu unghi deschis şi că acesta reprezintă 12-15% din cauzele de orbire. Acest lucru subliniază încă o dată importanţa monitorizării corecte a afecţiunii.

Mai mult, o formă particulară a glaucomului primar cu unghi deschis, glaucomul cu tensiune normală (eng. normal tension glaucoma – NTG), denumit şi glaucom cu tensiune scăzută, are ca particularitate faptul că tensiunea intraoculară nu depă şeşte valorile normale, fiind identic cu glaucomul primar în toate celelalte aspecte. În absenţa oricărei deteriorări a acuităţii vizuale şi creşterii presiunii oculare în glaucomul cu tensiune normală, una dintre cele mai importante investigaţii pentru diagnosticul şi stadializarea acestei boli este reprezentată de examinarea şi înregistrarea câmpului vizual, cu aceeaşi importanţă în supravegherea tratamentului medical şi chirurgical [3]. Aceasta necesită de asemenea examinarea completă, partajarea şi revizuirea periodică a informaţiei.

Glaucomul reprezintă o afecţiune foarte gravă care reprezintă un risc pentru persoanele trecute de 60 de ani. Tratamentul medical, dacă este corect, poate duce la încetinirea sau chiar stoparea evoluţiei bolii. Chirurgia (clasică, laser sau cu ultrasunete) reprezintă ultima soluţie care trebuie aplicată. Statisticile arată? că aceasta este aplicată din ce în ce mai rar (ca o urmare a monitorizării mult mai atente şi a aplicării unor noi tipuri de tratamente).

Alte aspecte ale specificaţiilor sistemului nostru:

• Cabinetele oftalmologice sunt dotate cu cel puţin un calculator destul de puternic încât să poată rula un sistem de gestiune a bazelor de date sau cu unul sau mai multe servere. Terminalele vor fi utilizate cu precădere numai pentru afişarea de informaţii.
• O dată pe lună, pacienţii sunt examinaţi si primesc o reţetă gratuită de la acelaşi doctor. Există însă şi posibilitatea ca uneori aceştia săschimbe doctorul – acest lucru duce la o serie de complicaţii care pot deveni critice în cazul unei boli nedescoperite cum este glaucomul.
• Chiar dacă investigaţiile unui pacient pot fi disponibile local (la nivel de clinică sau de cabinet), în acest moment nu există posibilitatea ca ele sa fie accesate din orice cabinet. Din această cauză, tratamentul prescris de un doctor este dependent de fişele medicale anterioare pe care pacientul trebuie să? le păstreze (şi care sunt pierdute uneori).

Toate aceste probleme ne-au condus la concluzia că proiectarea şi implementarea unei noi scheme de înregistrare electronică a pacienţilor bazată pe o bază de date distribuită (PAS) este absolut necesară în monitorizarea glaucomului. Această schemă va permite doctorilor oftalmologi să observe şi să modifice datele şi înregistrările pacienţilor într-o manieră sigură, flexibilă şi eficientă. Proiectarea compactă şi eficientă va permite sistemului nostru (într-o perspectivă mai îndelungată?) să integreze metode de memorare a diferitelor tipuri de imagini medicale şi să dispună de facilităţi moderne de căutare (ex.: căutarea bazată pe conţinut) necesare în monitorizarea şi compararea câmpurilor vizuale din GPUD şi NTG precum şi adăugarea unor noi moduri de asistare a medicului. În acest sens există şi un proiect de cercetare aflat în plină desfăşurare [4].
Specificaţiile structurale derivate din scopurile sistemului sunt:

• Crearea unui sistem informatic distribuit ieftin.
• Asigurarea de suport Web.
• Asigurarea unui nod eficient şi flexibil de a administra datele pacienţilor.
• Să permită medicilor înregistraţi (oftalmologilor) să vadă şi să modifice datele şi înregistrările pacienţilor.
• Să permită extensii viitoare cât şi o utilizare la scară largă fără reducerea drastică a performanţelor în operare şi o creştere exponenţială a costului.

Implementarea corectă a HIS/schemei EPR în cadrul sistemului nostru a fost proiectată să ofere suport pentru:

• Mai mulţi doctori simultan.
• Posibilitate de utilizare of-site.
• Backup pentru date.
• Audit.
• Decizii.
• Rapoarte asupra activităţii, pacienţilor, etc. (care pot fi create în mod automat).

Deoarece informaţiile existente erau împărţite în diferite baze de date, administrate de diferite sisteme de gestiune a bazelor de date care rulează sub diverse sisteme de operare şi pe mai multe calculatoare, singura soluţie a fost proiectarea sistemului software într-o manieră client-server sau distribuită. A trebuit să se ţină cont şi de comunicaţiile între reţele diferite cât şi de asigurarea transparenţei.

Structura logică a sistemului trebuie să păstreze cât mai mult din caracteristicile cheie ale procesului iniţial aşa cum este arătat şi în Figura 2:

Figura 2. Arhitectura sistemului programat.

Nucleul sistemului poate fi văzut ca fiind un sistem distribuit de baze de date care este accesat de un program server care comunică cu mai multe tipuri de clienţi. Acest software, care utilizează infrastructura Internet şi care acceptă cele mai noi tehnologii, se adresează nevoilor urgente de utilizare şi administrare a informaţiilor medicale.

Implementarea sistemului nostru a urmăit ideile expuse mai sus şi, pentru a atinge toate scopurile şi beneficiile proiectului, asigurarea unei proiectări simple şi corecte a sistemului era necesară. Numărul de nivele a fost restrâns la minim – un server central foarte puternic în Clinica de Oftalmologie şi nivelul al doilea constând în calculatoarele existente în cabinetele oftalmologice. Al treilea nivel, constând în calculatoare dispersate care accesează datele prin browserele Web, a fost luat în considerare dar nu a fost încă implementat.

Pentru a pune în practică aceste nivele au fost puse în evidenţă şi funcţiile ce trebuie îndeplinite:

1. Managementul simplu de reţea (eng. back-office), ce trebuie să ţinăcont de medicii şi de pacienţii înregistraţi într-un anumit nod asigurând:

• Administrarea locală a informaţiei în nod: identificarea medicilor si a pacienţilor, diagnosticele şi tratamentele prescrise de-a lungul timpului şi cele curente, etc.
• Statistici cumulate cu privire la pacienţii unui anumit medic sau alte aspecte ca numărul total de pacienţi, costul tratamentului, etc.

2. Distribuţia datelor (eng. data-distribution), ce are în vedere datele adunate din noduri:

• Datele culese de la pacient într-un nod local sunt încărcate, cel puţin o dată pe zi, pe server, fiind astfel disponibile si celorlalte noduri.

Pentru a se obţine această funcţionalitate, baza de date locală dintr-un nod trebuie sa implementeze câteva relaţii minime : pentru pacienţi, medici, tratament curent, istoricul bolilor, consultaţii, etc. Baza de date centrală trebuie să implementeze relaţii adiţionale cum ar fi cele pentru cabinetele deservite, evenimente întamplate în decursul tratamentelor, etc.

Pentru a implementa funcţionalitatea bazelor de date, sistemul de gestiune a bazelor de date trebuie sa suporte tranzacţii. Trebuie avută în vedere şi cantitate mare de date care se vehiculează în reţea în cazul unui număr mare de noduri si consistenţa acestor date. O metoda simplă de verificare poate fi similară cu următoarea : daca o legătură dintr-un table (câmp al unei înregistrări) indică către un alt tabel având o înregistrare corespondentă lipsă atunci un câmp care să indice nevoia de reactualizare a înregistrării trebuie să fie setat. Administrarea unui număr mare de accese concurente şi evitarea coliziunilor au fost luate în considerare la proiectarea soluţiei prin folosirea semafoarelor.

Partea de administrare a comunicaţiilor prezentă în orice sistem de acest tip a fost proiectată dispersat, în sensul că funcţiile sunt distribuite mai multor module (manager de schema, manager de stocare, manager de interogare). De exemplu :

• O parte a serverului ţine evidenţa tuturor datelor ce sunt vehiculate.
• Clienţii sunt implementaţi astfel încât să fie independenţi de platformă (folosind tehnologiile Java).

Proiectarea modului în care datele sunt obţinute/actualizate/analizate a ţinut cont de componentele principale, dintre care cele mai importante sunt:

• Modulul de administrare a aplicaţiei back-office: fiecare medic poate să acceseze datele personale ale oricărui pacient de pe orice calculator care are soft-ul instalat.
• Modulul pentru Internet: permite altor oftalmologi sau pacienţilor săconsulte datele puse la dispoziţie de modulul de administrare a aplicaţiei - back-office (ca de exemplu reţete, tratament prescris, consultaţii, etc.).

O arhitectură pe 3 nivele de tip MVC (Model - View - Controller) a fost utilizată în implementare. Proiectarea MVC este foarte frecventă atunci când se doreşte separarea celor 3 niveluri: view (administreazăpartea grafică), controller (partea de logică a aplicaţiei) şi model (se referă la date şi la comportamentul acestora). Utilizarea acestei arhitecturi în proiectele anterioare ne-a recomandat-o ca fiind soluţie cea mai bună de implementare [5]. O remarcă utilă în înţelegerea abordării noastre: MVC a fost dezvoltat iniţial pentru a mapa datele iniţiale, procesarea şi rezultatele în partea grafică a aplicaţiei (“Input -> Processing -> Output” este echivalent cu “Controller -> Model -> View”).

Figura 3. Arhitectura standard MVC.

Deoarece unul din scopurile implementării noastre a fost să dezvoltăm un sistem unitar care să poată fi cu uşurinţă modificat, extins şi actualizat în viitor, am ales pentru implementarea părţii Web a proiectului tehnologiile Java (Java Server Pages şi Servleţi). Pentru prezentarea informaţiei pe Web s-a ţinut cont de faptul că:

• Datele trebuie săpoată fi accesate de la orice calculator conectat la Internet printr-un protocol securizat (HTTP peste SSL).
• Singurul scop al modului pentru Internet este de a prezenta date.

Unul din obiectivele noastre este să facem trecerea în viitor de la această implementare pilot la un sistem bazat în întregime pe HL7 (Health Level 7). HL7 este utilizat în multe din sistemele medicale actuale fiind şi standardizat [6] şi a fost folosit cu succes în unele din proiectele noastre anterioare. Deoarece atât aplicaţiile existente în cabinetele oftalmologice cât şi bazele de date utilizate de acestea nu foloseau nici un standard medical, am încercat să facem un compromis între utilizarea unor asemenea standarde medical (ca HL7 de exemplu) şi atingerea scopului iniţial ale proiectului. Pentru a facilita trecerea ulterioară la un sistem bazat pe HL7, am ales ca datele vehiculate între server şi clienţi să fie reprezentate în format XML (Extensible Markup Language) deoarece acesta stă şi la baza mesajelor HL7 v3.

Utilizarea Java în implementarea noastră ne va ajuta să integrăm mult mai uşor standardul HL7 în cadrul sistemului nostru prin folosirea HL7 SDK. Acesta reprezintă un set de biblioteci create special pentru a adăuga suport de HL7 aplicaţiilor Java [7].

Arhitectura sistemului software dezvoltat este compusă din 2 module (pentru server şi pentru client) şi este prezentată în Figura 4.

Figura 4. Arhitectura sistemului back-office.

Comunicarea asincronă dintre medici şi pacienţi şi agregarea entităţilor trebuie asigurate: informaţia poate săjungă la un pacient, la un grup de pacienţi sau la toţi pacienţii. Această include nu numai informaţia medicală – pacienţii pot fi informaţi şi despre alte tipuri de evenimente.

Diagrame de utilizare a cazurilor (UML), ca cea din Figura 5, au fost folosite pentru a descrie funcţionalitatea sistemului în momentul strângerii cerinţelor (în interacţiunea dintre membrii echipei de proiectare şi medici).

Aspectele finale ale proiectării au fost cele referitoare la optimizări ca: arhivarea datelor, distrugerea datelor care nu mai prezintă interes, ordonarea datelor pe baza mai multor indecşi pentru a asigura un timp de răspuns mai mic la căutări, etc. Chiar dacă aceste lucruri au fost analizate, ele nu au fost încă implementate.

Figura 5. Diagramă UML pentru colectarea cerinţelor

Rezultate

Tehnologiile alese pentru implementare au fost unele standardizate. Am considerat Microsoft SQL Server 2000 ca fiind cel mai potrivit SGBD (Sistem de gestiune al bazelor de date), iar suportul oferit de Java s-a dovedit suficient de puternic pentru implementarea interfeţelor şi pentru comunicarea distribuită dintre clienţii care rulează local.

Structura bazei de date este de tip relaţional, bazată pe RDBMS (Relational Database Management System). Aşa cum se poate vedea în Figura 4, două arhitecturi diferite pentru bazele de date sunt folosite:

1. Baza de date localăpe server, folosită pentru a aduna informaţii de la toate policlinicile sau cabinetele care se află în sistem şi care este verificată periodic pentru a-i fi asigurată consistenţa.
2. Bazele de date locale la clienţi - instalate şi utilizate de fiecare policlinică sau cabinet.

Principalele legături (relaţii) din în bazele de date locale sunt:

• Pentru pacienţi (Patients).
• Pentru medici (Doctors).
• Pentru tratamentul curent (Prescriptions).
• Pentru bolile cronice (FoundDiseases).
• Pentru consultaţii (Consultations).
• Pentru programări (Appointments).
• Pentru localizarea:

- cabinetului oftalmologic (Location),
- pacienţilor/medicilor (Towns & Counties).

Acestea pot fi detaliate ca:

• USER (id, Firstname, Lastname, sex, Birth date, address, phone1, phone2, email, status)
• Role (id, name)
• USERROLE (Userid, Roleid)
• INVESTIGATION (id, Phisicianid, Patientid, date, Prescriptionid, Diagnisisid, observations, status)
• PRESCRIPTION (Id, Startdate, Enddate, Medicineids, Observations )
• DIAGNOSIS (Id,Name,Observations)

… Sau ca în Figura 6:

Figura 6. Relaţii în bazele de date.

Arhitectura generală a sistemului - proiectată în funcţionalitatea bazei de date distribuită ce trebuie utilizată – este prezentată în următoarea diagramă:

Figura 7. Arhitectura sistemului cu baze de date distribuite.

Relaţiile bazei de date pot fi grupate în scopul de a obţine:

1. Informaţii demografice şi statistice (Demographic Data Block).
2. Informaţii clinice şi statistice – numărul consultaţiilor, bolile tratate, evoluţia bolilor în timp (Clinical Observations Block).
3. Informaţii legate de tratamente şi statistici – medicamentele prescrise ( Pharmacology Block), ş.a.m.d.

Deoarece un sistem de gestiune al bazelor de date distribuit, reprezintă un sistem unitar din punct de vedere logic dar distribuit fizic în nodurile unei reţele, compatibilitatea între server şi implementările bazelor de date locale a trebuit să fie urmărită (ex. structura tabelelor din bazele de date locale şi de pe server sunt similare). Microsoft SQL Server a fost ales datorită faptului că este bun pentru baze de date mari cu multe accese concurente, oferind suport pentru toate operaţiile asupra bazelor de date. Bazele de date locale pot folosi Microsoft Access, MySQL sau Microsoft SQL Server ca SGBD, în funcţie de platforma, numărul de pacienţi şi puterea calculatorului.

Implementarea noastră poate fi descrisă în linii mari ca fiind de tip bottom-up, adică, sistemul se dezvoltă? pornind de la aplicaţii mici şi ajungând la aplicaţii de o funcţionalitate complexă. Cerinţele şi caracteristicile de bază ce rezultă din modul de proiectare a aplicaţiilor locale implementate sunt:

1. Capacitatea de a rula ca o aplicaţie independentă - ex. să ruleze cu sau fără server.
2. Administrarea locală a informaţiilor din nod (privitor la identificarea pacienţilor şi a medicilor, bolile pacienţilor şi tratamentul anterior, deciziile terapeutice curente pentru un pacient).
3. Statistici cumulative (privitoare la toţi pacienţii unui anumit medic, sau alte aspecte ale activităţii cum ar fi: numărul de pacienţi, numărul de consultaţii, evoluţia bolilor etc.).
4. Posibilitatea de a căuta datele pacienţilor într-un mediu distribuit (format din toate calculatoarele al căror software permite această operaţie).

În implementările locale, dezvoltarea rapidă a aplicaţiilor a fost realizată pornind de la scenariile de utilizare (UML), apoi a fost folosită Java datorită:

1. Independenţei de platformă (posibilitatea de folosire pe platforme diferite fără modificări).
2. Facilităţi oferite pentru:

o Statistici grafice.

o Aplicaţiile în reţea.

o Securitatea comunicaţiei.

o Suport pentru bazele de date.

3. Bibliotecile Java conţin clase deja implementate furnizând un GUI (Graphical User Interface) atractiv.
4. Posibilităţile de extindere (Java este un limbaj pur obiectual).

Diagramele cazurilor de utilizare (UML), similare celei descrise în Figura 5, au fost folosite pentru a descrie funcţionalitatea sistemului local la nivelul II.

În ceea ce priveşte modul de implementare a aplicaţiei locale au fost avute în vedere următoarele :

• Interfaţă grafică uşor de utilizat.
• Un grad de securitate ridicat.
• Opţiuni pentru utilizatorii neexperimentaţi sau pentru cei avansaţi.
• Statistici la nivel :

o Local (de cabinet).
o Global (oraş/zonă).

• Soluţii de Backup pentru bazele de date locale.
• Posibilităţi de interogări multiple pentru bazele de date.

De exemplu, înregistrările din baza de date locală se referă la medici, pacienţi, programări, informaţii auxiliare, etc. – accesul la aceste date fiind asigurat numai utilizatorilor înregistraţi.

Datele publice ce aparţin unui anumit doctor pot fi accesate (cu anumit restricţii) de oricine, cele private fiind accesate numai de medicul respectiv sau de un utilizator cu drepturi de administrator. Un nivel suplimentar de securitate este introdus atunci când datele trebuie şterse, adăugate sau modificate în baza de date.

Căutarea pacienţilor se poate face cu uşurinţă atât în baza de date locală cât şi în întregul sistem atunci când opţiunile de căutare sunt setate corespunzător.

Noi informaţii pot fi adăugate bazei de date numai prin intermediul aplicaţiei locale (ca în Figura 8). Această restricţie impune prezenţa bazei de date şi a aplicaţiei locale chiar şi în clinica unde este amplasat serverul (baza de date centrală). Pentru a menţine consistenţa bazei de date au fost făcute ipoteze foarte rezonabile :

• un pacient poate fi consultat de mai multe ori pe zi în acelaşi cabinet sau clinică şi actualizări ale bazei de date locale sunt făcute de fiecare dată;
• un pacient poate merge la alt medic cel mai devreme la o zi după consultaţie, interval în care baza de date centrală va fi actualizată.

Figura 8. Colectarea datelor în aplicaţia locală

Subsistemul local asigura 2 nivele de securitate a datelor (cum se poate vedea şi în Figura 9):

• la nivel de bază de date (definit atunci când baza de date este creată),
• la nivel de aplicaţie (definit de către aplicaţie).

Figura 9. Securizarea datelor.

Transferul informaţiei confidenţiale prin Internet este un proces riscant. Din acest motiv securitatea comunicaţiei a fost avută în vedere: transferul de date între clienţi (cabinete) şi server se va face folosind Secure Sockets Layer Protocol (SSL).

SSL suportă o schemă de autentificare client-server foarte flexibilă şi asigură o comunicare criptată. SSL se constituie într-un nivel intermediar între Transport Control Protocol (TCP) şi protocoalele de la nivelul aplicaţie (HTTP sau SMTP). Este utilizată criptarea folosind chei publice pentru a asigura autentificarea şi cheile private şi semnăturile digitale (certificatele) pentru confidenţialitate şi integritatea datelor. Pentru a beneficia de puterea SSL în sistemul nostru am apelat la librăriile Java Secure Socket Extension (JSSE) care sunt o parte din platforma Java 2 Standard Edition (J2SE) versiunea 1.4.

Concluzii

Sistemul informatic medical prezentat, organizat sub forma unui sistem distribuit, are ca scop monitorizarea pacienţilor cu glaucom fiind proiectat să corespundă standardelor actuale de sisteme medicale. Implementarea de tip bottom-up asigură flexibilitate şi uşurinţa în a anticipa şi dezvolta cerinţe viitoare.

Prin dezvoltarea unui sistem intuitiv având o interfaţă uşor de înţeles şi de utilizat de către medici, asistente şi personalul administrativ, beneficiile unei asemenea abordării sunt:

• Supervizarea tratamentului şi posibilitatea de a schimba păreri între doctori
• Planificarea corectă a controalelor medicale (proba de provocare cu lichis, perimetria – inclusiv perimetria computerizată, oftalmoscopia, retinografia).
• Evitarea unor dezastre terapeutice cauzate de întreruperea tratamentului.
• Îmbunătăţiri ale aspectelor administrative şi decizionale (cu privire la costuri şi întârzieri).

Referinţe