Centrul medical privat "Galenus" din Târgu Mureş a fost dat în folosinţă la începutul anului 2006, cuprinzând un ambulator de specialitate, un mic spital dotat cu sală de operaţii chirurgicale şi un laborator de analize medicale, la care s‐a adăugat în 2007 un centru de imagistică. Centrul a fost echipat de compania IBS cu toate ingredientele unei "clădiri inteligente" şi a fost dotată cu o reţea bazată pe servere Linux şi staţii de lucru Windows XP. În privinţa softului de evidenţă, Galenus a optat pentru dezvoltarea unei soluţii proprii, care să ofere flexibilitatea necesară şi opţiunile de creşte re graduală odată cu creşterea numărului de clienţi.

Varianta tehnologică pentru aplicaţia de evidenţă medicală a fost una bazată pe tehnologii web open source, care să asigure accesul tuturor utilizatorilor asupra unei colecţii unice de date. Serverul central este un sistem Linux care rulează toate componentele aplicaţiei, constând dintr‐o bază de date PostgreSQL şi un server de aplicaţie Zope (care asigură şi rolul de server HTTP). Staţiile de lucru se conectează la aplicaţie prin intermediul unui simplu browser (s‐a ales Mozilla Firefox pentru uniformitate, dar nimic nu împiedică folosirea altor browsere care rulează JavaScript).

Soluţia software a fost dezvoltată pornind de la un framework aplicativ general (Weber) realizat de Intraweb Software, care implementează nativ o serie întreagă de funcţionalităţi generice, cum ar fi administrarea colecţiilor ierarhice, fluxul documentelor, gestiunea utilizatorilor şi drepturilor pe bază de roluri şi poziţionare în schema de personal. Întreaga aplicaţie foloseşte un dicţionar unic de date, pe baza căruia imaginile şi formularele corespunzătoare obiectelor din colecţiile de date şi a documentelor sunt generate automat (în funcţie de drepturile utilizatorilor). Dicţionarul de date este cheia flexibilităţii sistemului, deoarece în cele mai multe cazuri o simplă modificare în acesta determină schimbarea comportamentului şi/sau aspectului obiectelor vizate.

O facilitate specială a framework‐ului permite folosirea unor aşa‐numite proprietăţi, care se comportă la fel ca şi câmpurile de date (pot fi chiar compuse, de tip articol), dar au în plus posibilităţi de propagare controlată în structurile arborescente (toate colecţiile de date un caracter ierarhic nativ). De exemplu, pentru un grup de analize (o ramură a arborescenţei) se pot preciza în nodul rădăcină aparatul care le procesează, recipientul în care se colectează probele şi alte proprietăţi, care sunt automat "moştenite" de analizele grupului (care au însă posibilitatea de a le suprascrie). Mai important este că adăugarea unor proprietăţi nu afectează structura bazei de date -- se foloseşte o structură unică de stocare, astfel încât e suficientă adăugarea descrierii în dicţionarul de date.

Pentru aplicaţia implementată la Galenus s‐a pornit de la o metaforă sugestivă, familiară oricărui utilizator: fluxul de documente. Practic, tot ce vede un utilizator obişnuit (fără drepturi de administrare) sunt imagini de documente, care pot fi editate şi care acceptă comenzi care, eventual, le trec dintr‐o stare în alta. De exemplu, atunci când un pacient solicită (la recepţie sau telefonic) o programare pentru o consultaţie, recepţionera are deja imaginea programărilor în ziua indicată pentru medicul sau specialitatea solicitată (pe cuante de timp, calculate în funcţie de durata medie a unei consultaţii) şi, dacă un interval este liber, creează o fişă de consultaţie care iniţial este în starea draft. Identificarea pacientului (după elemente ale numelui sau CNP) şi eventual introducerea sa în baza de date se face printr‐un mecanism Ajax, astfel încât utilizatorul nu părăseşte imaginea documentului. Când pacientul se prezintă la centrul medical pentru consultaţie, recepţionera identifică pacientul (sau eventual îl introduce în baza de date, deoarece în cazul programărilor prin telefon programarea nu este legată de un pacient din baza de date) şi trece fişa de consultaţie în starea intrat. Din acest moment, medicul poate completa fişa de consultaţie, cu informaţiile medicale corespunzătoare: diagnostic principal (conform clasificării CIM10, disponibilă tot printr‐un mecanism Ajax), explicaţii sau diagnostice secundare precum şi manoperele efectuate. Când medicul încheie consultaţia, fişa trece în starea arhivat şi asupra ei nu mai pot fi făcute modificări. Când pacientul a terminat consultaţia (sau consultaţiile), se prezintă din nou la recepţie, unde recepţionera are acces la "tichetul" (un alt document) care l‐a însoţit pe pacient, unde sunt consemnate toate manoperele şi preţurile corespunzătoare (pot fi diferite în funcţie de medic) precum şi totalul de plată (care poate fi diferit de suma preţurilor manoperelor, în cazul în care intervine un contract dintre Galenus şi o terţă parte -- de pildă o societate de asigurări). De remarcat faptul că medicul are o imagine diferită asupra documentului decât recepţionera (datorită rolului diferit). De exemplu, medicul care efectuează consultaţia are acces la istoricul medical al pacientului (consultaţii, analize, notele consemnate de medici etc.).

Dacă în cazul secţiei de laborator şi a centrului de imagistică există şi varianta (de rezervă) a procedurilor manuale, pentru partea de laborator aplicaţia este mission‐critical. În această zonă complexitatea este sporită, numărul de pacienţi este de ordinul sutelor în zilele de vârf şi în joc intră şi aparatele moderne care realizează analizele. Şi în acest caz, fluxul începe la recepţie (exceptând cazurile în care recoltările de fac în teritoriu), cu un draft al buletinului de analize. Spre deosebire de ambulator, aici se consemnează şi analizele ce se cer efectuate, astfel încât preţul este determinat în această fază. De asemenea, se determină intervalele de referinţă pentru fiecare analiză (sunt proprietăţi ale analizelor) în funcţie de vârstă şi sex. Odată ce pacientul a plătit, buletinul trece în faza intrat (devine vizibil în worklist‐ul laboratorului) iar pacientul primeşte o versiune a buletinului de analize (o fişă de lucru, care cuprinde şi explicaţiile privind preţurile şi motivele pentru care anumite analize sunt compensate şi altele nu) cu care se prezintă la laborator pentru recoltarea probelor. Numărul de registru (exprimat şi ca un cod de bare pe buletin) devine identificatorul buletinului, iar la recoltare buletinul trece în starea recoltat. Trecerea în starea recoltat determină o serie de operaţii suplimentare, cum ar fi imprimarea etichetelor cu coduri de bare pentru marcarea recipienţilor, pregătirea programelor pentru aparate şi consemnarea informaţiilor într‐un index general destinat statisticilor). Aparatele identifică probele şi, eventual, solicită aplicaţiei codurile interne ale testelor ce trebuie efectuate. Odată ce se obţin rezultatele, acestea sunt transmise aplicaţiei (prin intermediul unor programe de comunicaţie realizate de IntegraSoft), iar aplicaţia le procesează în continuare: se identifică buletinul, se efectuează eventual calcule (pot fi expresii sau chiar programe Python ataşate analizelor), se asociază rezultatele cu analizele şi se compară cu valorile de referinţă, asociind marcajele L (low), H (high) sau "*" după cum rezultatele se situează sub sau peste valorile normale (asteriscul marchează rezultatul "pozitiv"). Desigur, rezultatele analizelor pot fi şi editate, deoarece nu toate analizele sunt realizate de aparate (de pildă cele de microbiologie). Buletinul trece automat în starea complet atunci când toate analizele au rezultate (o facilitate nu neapărat necesară, dar eficientă) urmând ca medicul responsabil să le vizeze (ceea ce se traduce prin trecerea buletinului în starea arhivat şi închiderea accesului la document).

Din motive de eficienţă, unele operaţii (vizualizări sau actualizări) din laborator se abat de la metafora documentului. De exemplu se pot vizualiza şi edita doar anumite analize, în formă tabelară -- facilitate utilă pentru introducerea manuală a unor serii de rezultate sau pentru a permite medicului o viziune de ansamblu a rezultatelor pe anumite analize.

Aplicaţia oferă utilizatorilor autorizaţi o serie întreagă de statistici şi rapoarte, începând cu cele de ansamblu (care oferă imaginea activităţii într‐un o zi sau într‐o perioadă), până la cele mai specializate. O componentă importantă este cea referitoare la contracte şi colaborări. Complexitatea aplicaţiei nu permite o descriere cuprinzătoare în aceste pagini, dar concluzia este că softurile open source şi tehnologiile web oferă deja toate ingredientele necesare dezvoltării unor aplicaţii complexe şi, totodată, uşor de administrat.