Webová aplikácia pre podporu efektívneho fungovania ambulancie lekára

Transcription

1 Slovenská technická univerzita v Bratislave FAKULTA INFORMATIKY A INFORMAČNÝCH TECHNOLÓGIÍ FIIT Marek Uhlár Webová aplikácia pre podporu efektívneho fungovania ambulancie lekára Bakalárska práca Študijný program: Informatika Študijný odbor: Informatika Miesto vypracovania: Ústav informatiky a softvérového inžinierstva, FIIT STU Bratislava Vedúca práce: Ing. Viera Rozinajová, PhD. máj 2010

2 ANOTÁCIA Slovenská technická univerzita v Bratislave FAKULTA INFORMATIKY A INFORMAČNÝCH TECHNOLÓGIÍ Študijný program: Informatika Autor: Marek Uhlár Bakalársky projekt: Webová aplikácia pre podporu efektívneho fungovania ambulancie lekára Vedúca bakalárskeho projektu: Ing. Viera Rozinajová, PhD. Máj 2010 Informačné technológie markantne zasiahli do vývoja zdravotníctva. Ich pozitívny prínos tu môžeme vidieť takmer vo všetkých oblastiach. V tejto práci je obsiahnutý prierez históriou medicínskej informatiky všeobecne. Väčšiu pozornosť tu venujeme vývoju, rozdeleniu a nasadzovaniu informačných systémov v oblasti zdravotníctva. Snažíme sa tu priblížiť nové iniciatívy a technológie. Priestor je venovaný aj prístupom k tvorbe webových aplikácií. Opisujeme bližšie problematiku starostlivosti o pacientov s diabetom, najmä z ich pohľadu a existujúce webové aplikácie pre nich určené. Cieľom tohto projektu je navrhnúť webovú aplikáciu, ktorá umožní zefektívniť fungovanie ambulancie lekára, konkrétne diabetológa a umožní pacientom ľahší prístup k overeným informáciám. Myslíme si, že práve v tejto oblasti by aplikácia tohto zamerania mohla výrazne zvýšiť kvalitu poskytovanej zdravotnej starostlivosti a zlepšiť samoliečbu pacientov s diabetom.

3 ANNOTATION Slovak University of Technology Bratislava FACULTY OF INFORMATICS AND INFORMATION TECHNOLOGIES Degree Course: Informatics Author: Marek Uhlár Bachelor Theses: Web application to support the effective operation of the doctor ambulance Supervisor: Ing. Viera Rozinajová, PhD. May 2010 Information technologies have strikingly affected the development of health care. Their positive contribution can be seen in almost all areas. We included a general history of medical informatics in this work. We contribute greater attention to development and deployment of information systems for health care. We try to bring new initiatives and technologies related to use of information technology in healthcare. A part is also dedicated to approaches in creating web applications. We describe the issue of care of patients with diabetes from their particular perspective and existing Web applications for them. The aim of this project is to design a Web application that will streamline the operation of the ambulance of a physician, specifically of doctor treating diabetics and allow patients easier access to verified information. We think this is where the application of such an orientation could significantly increase the quality of health care and improve self-treating of patients with diabetes.

4 Poďakovanie Pri vypracovávaní projektu mi pomohlo viacero ľudí, ktorým by som sa chcel prostredníctvom tohto textu srdečne poďakovať. Ďakujem vedúcej môjho bakalárskeho projektu Ing. Viere Rozinajovej PhD, ktorá ma vždy usmernila správnym smerom. Ďakujem môjmu diabetológovi, MUDr. Ľubomírovi Barakovi CSc., ktorý mi dal nápady na niektorú funkcionalitu a je popredným odborníkom vo svojej oblasti. Vďaka smeruje aj ochotným ľuďom z hostingu ktorí mi prostredníctvom ovej podpory pomohli so sprevádzkovaním aplikácie na serveri.

5 Prehlásenie Týmto prehlasujem, že som prácu vypracoval sám, len s pomocou použitej literatúry.... Marek Uhlár

6 Obsah 1 Úvod Analýza História vývoja Medicínskej informatiky a informačných systémov v zdravotníctve Pojmy História Súčasnosť Medicínskej informatiky Dokumenty v zdravotníctve a EMR ehealth, Telemedicína a AHCC Webová aplikácia Definovanie webovej aplikácie Prístupy k tvorbe webových aplikácií Webové služby SOAP WSDL UDDI Opis problematiky a motivácia pre vývoj Prehľad oblasti Dôvody pre vývoj a prínos aplikácie Opis existujúcich webových aplikácií SimpleGlucose Medhelp.org HealthEngage Webová aplikácia pre diabetologickú ambulanciu Špecifikácia vytváranej aplikácie Návrh Prípady použitia pre navrhovanú aplikáciu Architektúra aplikácie Model údajov Grafický návrh Implementácia aplikácie Vývojové prostredie a frejmvork Technológie Webová služba SSIS Viacjazyčnosť Externé knižnice itextsharp asp:chart Podporované prehliadače Overenie Zhodnotenie Zdroje Zoznam príloh A Príloha: Technická dokumentácia A.1 Štruktúra aplikácie i

7 Dialance DialanceBI DrugListWebService DialanceSetup SQL Databázy A.2 Dostupnosť A.3 Otvorenie a spustenie riešenia Softvér Spustenie riešenia B Príloha: Používateľský návod B.1 Všeobecná funkcionalita Prihlásenie do aplikácie Vyžiadanie hesla Registrácia do aplikácie Zmena hesla Zaslanie súkromnej správy Čítanie prijatých a odoslaných správ B.2 Návod pre rolu Doktor Autorizovanie požiadaviek Plánovanie kontrol Dnešné kontroly História vyšetrení Vydanie predpisu História vydaných predpisov Priemerné glykémie Prezrieť graf glykémií B.3Návod pre rolu Pacient Vloženie osobných detailov Plánovanie kontroly Vyžiadanie lekárskeho predpisu Prezeranie predpisov Import hodnôt z glukometra Prezrieť graf glykémií B.4 Návod pre rolu Sestra Vložiť výsledky vyšetrenia ii

8 Zoznam obrázkov obr. 2.1 Ako funguje UDDI. [12] obr. 2.2 Vyplnená strana z papierového Denníku diabetika obr. 2.3 Úvodná stránka SimpleGlucose obr. 2.4 Graf v SimpleGlucose obr. 2.5 Medhelp Diabetes tracker obr. 2.6 Webová verzia HealthEngage Diabetes obr. 3.1 Diagram prípadov použitia pre používateľa obr. 3.2 Diagram prípadov použitia pre pacienta obr. 3.3 Diagram prípadov použitia pre sestru obr. 3.4 Diagram prípadov použitia pre doktora obr. 3.5 Náčrt architektúry aplikácie obr. 3.6 Prvá časť logického modelu údajov obr. 3.7 Druhá časť logického modelu údajov obr. 3.8 Prvá časť fyzického modelu údajov obr. 3.9 Druhá časť fyzického modelu údajov obr Grafický návrh vytváranej aplikácie obr. 4.1 Visual Studio obr. 4.2 Obsah súboru TestPage.aspx obr. 4.3 Kód pridružený k udalosti obr. 4.4 Zmena stránky TestPage obr. 4.5 Správy zasielané medzi webovou službou a aplikáciu obr. 4.6 Prvky naplnené z webovej služby obr. 4.7 Priebeh SSIS balíčku obr. 4.8 Ukážka naviazania na zdroj obr. 4.9 Predpis vygenerovaný aplikáciou obr Graf hodnôt glykémie obr. A.1 Štruktúra projektu Dialance obr. A.2 Konfiguračný súbor pre vytvorenú webovú aplikáciu obr. A.3 DialanceBI projekt obr. A.4 Projekt webovej služby pre poskytovanie zoznamu liekov obr. A.5 Konfiguračný súbor pre vytvorenú webovú službu obr. A.6 Sprievodca inštaláciu vytvorenej webovej aplikácie obr. A.7 Štruktúra databázy Dialance obr. A.8 Štruktúra databázy Drugs obr. A.9 Výber prvkov pri inštalácií MS SQL Server obr. B.1 Menu pre navigáciu obr. B.2 Zaslanie súkromnej správy obr. B.3 Prijaté správy obr. B.4 Autorizácia požiadaviek obr. B.5 Plánovanie kontrol obr. B.6 Dnešné kontroly obr. B.7 História vyšetrení obr. B.8 Predpis receptu obr. B.9 Podrobnosti o predpise obr. B.10 História vydaných predpisov obr. B.11 Priemerné glykémie pacientov obr. B.12 Graf glykemických hodnôt obr. B.13 Formulár na vloženie ďalších detailov iii

9 obr. B.14 Plánovanie vyšetrenia obr. B.15 Import hodnôt z glukometra Zoznam tabuliek tab. 4.1 Ukážka zdrojov tab. 5.1 Aplikačný test pridania pacienta tab. 5.2 Aplikačný test predpísania elektronického receptu tab. A.1 Testovacie kontá vo vytvorenej aplikácií iv

10 1 Úvod Informačné technológie čím ďalej viac zasahujú do všetkých oblastí nášho života. Uľahčujú prístup k informáciám, ich triedenie, úpravu. Prinášajú nové spôsoby medziľudskej komunikácie a socializácie. Jednou zo sfér, kde prináša zavádzanie informačných technológií naozaj relevantný pokrok a úžitok, je zdravotníctvo. Je tu potrebné: - zdieľanie veľkého množstva citlivých informácií - ich bezpečnosť a zálohovanie - rýchla a dostupná komunikácia pacienta so svojím lekárom Splnenie týchto potrieb prostredníctvom informačných technológií bude v konečnom dôsledku viesť k zlepšeniu poskytovanej zdravotnej starostlivosti. Tento dokument je výsledkom bakalárskeho projektu na tému Webová aplikácia pre podporu efektívneho fungovania ambulancie lekára, vypracovaného na Fakulte informatiky a informačných technológií v Bratislave. V dokumente sa snažíme priblížiť informačné technológie v zdravotníctve z rôznych pohľadov, od histórie ich zavádzania, až po novodobý stav a prístupy. Venujeme sa najmä informačným systémom a webovým portálom, ktoré sú najbližšie k zameraniu vytváranej aplikácie. Čitateľ je oboznámený s modernými prístupmi pri tvorbe webových aplikácií a informačných systémov. V dokumente sú jednotlivé prístupy porovnané s ohľadom na vhodnosť použitia v zdravotníckej oblasti. Hlavným cieľom tejto práce je opis návrhu a implementácie webovej aplikácie určenej pre diabetológa, ktorá vychádza z poskytnutej analýzy. 1

11 2 Analýza V rámci tejto kapitoly sa oboznámime s prostredím do ktorého je vyvíjaná aplikácia smerovaná, s technológiami, ktoré použijeme pri vývoji a s existujúcimi aplikáciami podobného zamerania. 2.1 História vývoja Medicínskej informatiky a informačných systémov v zdravotníctve V podkapitole sa budeme venovať histórii informatiky a informačných systémov v zdravotníctve Pojmy Medicínska informatika Medicínska informatika je aplikácia počítačových technológií do všetkých oblastí medicíny zdravotnej starostlivosti, výučby medicíny, a medicínskeho výskumu (Collen, 1977) 1. Zaoberá sa všetkými aspektmi organizácie, analýzy a riadení informácií v zdravotníctve. Napriek tomu, že medicínska informatika zdieľa jej zameranie aj s ďalšími oblasťami zdravotníctva, sú znaky, ktoré ju od nich jednoznačne oddeľujú. Najvýznamnejším je využívanie informačných technológií ako hlavného nástroja pri spravovaní informácií. Informačný systém Systém, ktorého funkciou je zdieľanie, analýza, šírenie a spracovanie informácií. V tejto práci pojem informačný systém vyjadruje systém, ktorý na vykonávanie svojej funkcionality využíva informačné technológie. Mainframe Počítač používaný pre kritické aplikácie, určený na spracovávanie obrovských objemov dát. Väčšinou ide o sálové počítače s enormnou spotrebou, rozmermi a cenou. 1 Collen, M. F.: Preliminary announcement for the Third World Conference...,

12 2.1.2 História Začiatky medicínskej informatiky siahajú do 50-tych rokov 20. storočia, kedy sa v dôsledku rozmachu počítačov začalo experimentovať s ich využitím v dentálnej medicíne. O presadzovanie informačných technológií v tomto období sa zaslúžil najmä Robert Ledley. V roku 1960 založil inštitúciu NBRF (National Biomedical Research Foundation) na propagovanie využívanie počítačov v medicínskom výskume [2]. V 60-tych rokoch 20. storočia na Univerzite v Missouri využíval Dr. Lindberg počítače na spracovanie a organizovanie výstupných dát z jeho zariadenia na štúdium antibiotík. To ho priviedlo k nápadu organizovať pomocou informačných technológií laboratórne reporty v laboratóriu mikrobiológie, keďže tu dochádzalo k častým stratám a zámenám. Vznikol pravdepodobne prvý elektronický laboratórny reportný systém. Pozostával z viacerých častí, bol schopný uchovávať, upravovať a tlačiť reporty. Realizovaný bol aj nápad posielať reporty priamo na oddelenie, kde boli smerované, napriek tomu, že ešte neexistovalo nato určené telekomunikačné zariadenie. Ušetrilo to 20 pracovníkov, ktorí mali dovtedy na starosť túto činnosť. Systém bol neskôr nahradený nástupcom, ktorý využíval počítač IBM 1410 a boli využité jazyky Fortran, COBOL a Autocoder. V dôsledku týchto úspechov bol založený na Univerzite v Missouri Medical Computer Program, ktorý sa venuje rozvoju medicínskej informatiky [4]. Ďalším významným krokom bol MUMPS (Massachusetts General Hospital Utility Multi-Programming System) vyvinutý na Massachusetts General Hospital. Jeho hlavným prínosom oproti predošlým IS v zdravotníctve bolo použitie polí a premenných s variabilnými veľkosťami, čo viedlo k oveľa ľahšej úprave systému pri použití v iných podmienkach. V 70-tych rokoch začal rozmach nasadzovania informačných systémov v nemocniciach (najmä systémy na správu pacientov a laboratórne systémy). Na trhu existovalo viacero alternatív, pričom sa už začalo prihliadať aj na finančnú výhodnosť, návratnosť a jednoduchosť zavedenia systému do prevádzky. Postupné zavádzanie minipočítačov (využitie ako klientske stanice), stále však bol ústrednou výpočtovou jednotkou mainframe. V 80-tych rokoch v zdravotníctve narastala potreba po komplexných integrovaných klinických a finančných informáciách. Začali sa prepájať jednotlivé samostatne fungujúce systémy špecializujúce sa na rôzne činnosti, pričom pracovali nad 3

13 spoločnou databázou pacientov. Bolo to umožnené vďaka zavedeniu mikropočítačov (PC), lokálnej počítačovej siete a distribuovaného spracovania dát [5]. Najviac do očí bijúci rozdiel pri porovnaní roku 1960 a 1987 je oveľa väčšie rozšírenie počítačových zariadení a posun v spôsobe vedeckej práce a podnikania, teraz závislých na automatizovaných informačných systémov pre podporu bežných profesionálnych funkcií. Inak povedané, počítačové systémy teraz naozaj fungujú a množstvo ľudí ich naozaj používa (Lindberg, 1987, s.1) 2. V 90-tych rokoch vývoj smeroval k zavedeniu elektronickej zdravotnej karty. S touto iniciatívou prišiel The Institute of Medicine (IOM). Avšak ku globálnej realizácií tejto myšlienky v tomto období nedošlo. Najvýraznejšou zmenou v oblasti technológií bol rozmach internetu, ktorý zmenil spôsob ako so sebou organizácie komunikovali. Organizácie poskytujúce zdravotnú starostlivosť sa ho snažia využiť na zlepšenie svojich služieb (špecializované portály). Informačné systémy v zdravotníctve pozitívne ovplyvnilo aj výrazne zníženie cien hardvéru. V roku 1990 bola založená nezávislá organizácia AMIA (American Medical Informatics Association). Vznikla zlúčením organizácií American Association for Medical Systems and Informatics (AAMSI), American College of Medical Informatics (ACMI) a Symposium on Computer Applications in Medical Care (SCAMC). Cieľom jej pôsobnosti je vývoj v oblasti medicínskej informatiky a nasadenie poznatkov v praxi. Členstvo je prístupné pre pracovníkov v oblasti medicíny (vrátane vývojárov štandardov), študentov medicíny, alebo firmy z tejto oblasti. Nie je obmedzené krajinou pôvodu. Ponúka aj členstvo pre uchádzačov, ktorí nie sú z medicínskej sféry, s menším rozsahom výhod a možnosťami participácie [1]. V roku 1999 IOM uverejnilo štúdiu, podľa ktorej až úmrtí ročne je spôsobených administratívnymi chybami v zdravotníctve, ktorým sa dalo predísť, napríklad aj zvýšením využívania informačných technológií [6]. Medzi technológie objavené po roku 2000, ktoré priniesli nové možnosti v zdravotníctve a v konečnom dôsledku rozširujú možnosti IS patria PDA, bezdrôtové technológie, rozpoznávanie hlasu a RFID. 2 Lindberg, D. A. B.: In praise of computing,

14 2.2 Súčasnosť Medicínskej informatiky V podkapitole rozoberieme súčasnosť medicínskej informatiky vo svete a na Slovensku. Spomenieme iniciatívy, ktoré sa podnikajú pre informatizáciu zdravotníctva Dokumenty v zdravotníctve a EMR Napriek nesmiernemu pokroku v oblasti vývoja nemocničných informačných systémov a ich nasadzovania do praxe sa stále popri elektronických dokumentoch používajú v zdravotníctve vo veľkej miere dokumenty papierové. Reinhold Haux o množstve vytvorených dokumentov za rok v typickej nemeckej nemocnici: Ročne je približne pacientov hospitalizovaných, ambulantne liečených a napísaných správ o operáciách, prepúšťacích listov, správ z patológie, správ z mikrobiológie, správ z rádiológie a správ z klinickej chémie. Každý rok, spolu s novými záznamami pacientov je vytvorených približne 6 miliónov dokumentov. Uložené v papierovej forme to predstavuje ročne 1500 metrov papierových správ. Často musia byť archivované po dobu viac ako 30 rokov. Pri digitálnom skladovaní je veľkosť týchto dát nahromadených po dobu jedného roka odhadovaná na 5 TB, vrátane digitálnych obrázkov a signálov (Haux, 2004, s.12) 3. Môžeme vidieť, že prechod na elektronické dokumenty, okrem iných výhod, prinesie veľké množstvo ušetreného papiera a skladových priestorov. Aj z tohto dôvodu sa kritickým cieľom dnešnej medicínskej informatiky stáva zavedenie štandardizovanej a certifikovanej EHR (alebo EMR, Elektronická zdravotná karta). Napriek snahám už od 90-tych rokov a iniciatívam organizácií venujúcim sa nasadzovaniu informačných technológií sa nepodarilo zaviesť povinné elektronické karty pacientov. V USA sa snažia podporiť ich rozšírenie zvýšením platieb zdravotníckym inštitúciám, ktoré zavedú certifikované EHR, prípadne znížením platieb pre tie, ktoré to odmietajú. Výkonným nariadením z 27. apríla 2004 vyzval bývalý americký prezident George Bush ml. na celoštátne prijatie interoperabilných EHR do roku Vytvoril novú kanceláriu Národného koordinátora pre zdravie informačných technológií, ktorej vyhlásila zavedenie EHR za národnú prioritu. Jeden zo štyroch častí jej iniciatívy je vytvorenie Celoštátnej siete zdravotníckych informácií (NHIN) na prepájanie EHR, bezpečne vymieňanie informácií o zdraví a doprava elektronických zdravotných údajov k lekárom. 3 Haux, R.: Strategic Information Management In Hospitals...,

15 V EU je zavádzanie EMR jedným z hlavných bodov programu ehealth. Elektronická zdravotná karta by sa mala stať základnou jednotkou, s ktorou by pracovali informačné systémy rôzneho zamerania. Je nutné zabezpečiť jej štandardizovaný formát, zdieľanie a bezpečnosť, keďže údaje v nej obsiahnuté sú citlivého charakteru [8]. Druhým kritickým cieľom v oblasti medicínskej informatiky je využívanie internetu. Nielen na rýchle a jednoduché poskytnutie informácií pre pacienta, ale aj možnosti interagovať s príslušnou zdravotníckou inštitúciou na diaľku. Elektronické objednávanie pacienta na vyšetrenia a konzultácie, on-line konzultácie s lekárom, preberanie výsledkov vyšetrenia, prezeranie svojej zdravotnej dokumentácie, prezeranie overených informácii týkajúcich sa pacientovej choroby a jej liečenia a mnoho ďalších možností zlepšenia zdravotnej starostlivosti, zjednodušenia prislúchajúcej administratívy a výrazného ušetrenia pacientovho času. Ideálnym riešením by pravdepodobne bolo vytvorenie vzájomne interoperabilných webových informačných systémov pre každú ambulanciu a zdravotnícke zariadenie, ktoré by poskytovali potrebnú funkcionalitu. Ich súčasťou by boli webové aplikácie potrebné pre danú doménu (napr. elektronický denník diabetika pre ambulanciu diabetológa). Boli by zdrojom overených informácií pre pacienta, i lekára, pričom citlivé a osobné informácie by boli zabezpečené na potrebnej úrovni. Umožňovali by on-line interakciu medzi príslušnou ambulanciou, zariadením a pacientmi ehealth, Telemedicína a AHCC Je jednou z desiatich súčastí plánu eeuropa 2005 (nástupca eeuropa 2002, program zameraný na internetizáciu európskych občanov a firiem). Cieľom programu ehealth je zaviesť v rámci EU interoperabilné IS systémy pre zdravotníckych profesionálov a pacientov, pričom pozornosť sa má klásť na jednoduchosť, účelnosť a bezpečnosť. ehealth dostáva do centra pozornosti pacienta, okolo ktorého sa majú sústrediť služby poskytované IT. Pre každého pacienta má byť vytvorený elektronický chorobopis (EHR). Ten umožní vyšetrenie u ľubovoľného lekára s prístupom k systému, rýchlejšiu a kvalitnejšiu diagnostiku, jednoduchú dostupnosť informácii pre pacienta a elektronické predpisovanie liekov [8]. 6

16 Ďalšou súčasťou iniciatívy ehealth je telemedicína, ktorá umožní chronický chorým a starším pacientom zvýšiť kvalitu a dostupnosť liečby a informácií. Jedná sa o program v rámci celej EU, čo znamená, že pacientov EHR bude v jej rámci prístupný pre lekárov v ich rodnom jazyku. To povedie k dramatickému zjednodušeniu diagnostiky a liečenie pacienta v zahraničí. V rámci iniciatívy ehealth sa pravidelne konajú konferencie na rôzne témy, ktoré prinášajú informácie z oblasti zavádzania a výskumu IT v oblasti zdravotníctva v rámci EU. Sú tu uvádzané plány ďalšieho postupu a vytýčené ciele v tejto oblasti. Napriek pomalšej penetrácii IT do oblasti zdravotníctva v porovnaní s väčšinou členských štátov sa Slovenská republika aktívne zapája do iniciatív ehealth. Boli vytvorené inštitúcie: - Odbor koordinácie ehealth v rámci NCZI (Národne centru zdravotníckych informácií) - Komisia pre ehealth v pôsobnosti Ministerstva zdravotníctva SR. NCZI vytvorilo v roku 2007 koncepciu Národného zdravotného informačného systému, ktorý ma zahŕňať nasledujúce okruhy: - bezpečná (autorizovaná) elektronická komunikácia (elektronický identifikátor) - elektronická preskripcia a medikácia (elektronický recept) - elektronické zdravotné záznamy - vykazovanie výkonov pre verejné zdravotné poistenie - zber údajov pre zdravotnícku štatistiku. Slovenská republika sa zapojila do celoeurópskeho projektu epsos (Smart Open Services for European Patients), ktorého cieľom je vytvorenie prototypov IS na národnej úrovni. V rámci návrhu týchto IS má byť zabezpečená ich vzájomná interoperabilita, ktorá je potrebná pre následne dosiahnutie dlhodobých cieľov iniciatívy ehealth [9]. Telemedicína je existujúca oblasť, ktorá využíva telekomunikačné technológie na zabezpečenie konzultácií medzi poskytovateľmi zdravotnej starostlivosti a pacientmi na diaľku a medzi špecialistami a všeobecnými lekármi (Wilson, 2003, s.1) 4. Problémom väčšieho rozšírenia telemedicíny je nákladnosť špecializovaných zariadení (napr. zariadenia na telekonferenciu medzi lekárom a pacientom). 4 Wilson E. W.: Asynchronous Health Care Communication,

17 ehealth je pomerne nové odvetvie, ktorého cieľom je sprístupniť medicínske informácie a služby prostredníctvom internetu. ehealth by mal poskytovať obsah, reklamy, klinickú starostlivosť a spojenie so zdravotníkmi, no ukazuje sa, že dnešné ehealth stránky sú obmedzené na medicínsky obsah a reklamu. Veľkú zmenu v oblasti telemedicíny a ehealthu by mala priniesť on-line komunikácia. Poskytovatelia zdravotnej starostlivosti vo vyspelých štátoch sú pod zvýšeným tlakom využívať a webové aplikácie na komunikáciu s pacientmi. Ukazuje sa však, že vývoj v tejto oblasti je oveľa pomalší ako zavádzanie IT v spracovávaní záznamov, katalogizácií, diagnostiky a vnútornej komunikácií. Výraz asynchronous health care communication (AHCC) opisuje medziľudskú, počítačom realizovanú komunikáciu (CMC) medzi poskytovateľmi zdravotnej starostlivosti a ich pacientmi (Wilson, 2003, s.2) 5. Základné AHCC môže byť implementované prostredníctvom existujúceho všeobecne zameraného CMC softvéru obsahujúceho ovú a webovú diskusiu a jednoduché diskusné fórum. Dôvody pre vznik špecializovaného AHCC softvéru: - narábanie s citlivými súkromnými informáciami - komunikácia medzi pacientom a poskytovateľom starostlivosti musí mať určitú požadovanú formu - veľmi špecifické požiadavky pri niektorých poskytovateľoch (pacienti s poškodeným zrakom atď.) V oblasti telemedicíny je možné využitie AHCC zavedenie video odkazov od pacientov pre poskytovateľov a následná možnosť video odpovede (použiteľnejšie oproti živej video komunikácií, kedy musí fyzicky prítomný poskytovateľ, i pacient v dohodnutom čase) [14]. 2.3 Webová aplikácia Podkapitola obsahuje definíciu webovej aplikácie a prístupy k tvorbe webových aplikácií Definovanie webovej aplikácie Webová aplikácia je aplikácia spustiteľná cez internet prostredníctvom webového prehliadača. Od roku 1994, kedy sa internet stal dostupný verejnosti prešiel 5 Wilson E. W.: Asynchronous Health Care Communication,

18 transformáciou z repozitára statických stránok na mocnú platformu pre vývoj a nasadzovanie aplikácií všemožného zamerania. Väčšina adries na internete v dnešnej dobe skrýva programy, ktoré sú spustiteľné prostredníctvom prehliadača a bežia na serveri pričom komunikujú s klientom. Umožňujú klientom komunikovať, kolaborovať, alebo dokonca aktualizovať funkčnosť aplikácie. V prieskume, ktorý zachytil stav vo vývoji webových aplikácií v roku 1999, Fraternali opísal webovú aplikáciu ako hybrid medzi a hypermediálnym a informačným systémom. Ako dôsledok stanovil nasledujúce požiadavky na webovú aplikáciu: - nutnosť manipulácie s štruktúrovanými (napr. databázové záznamy) a zároveň neštruktúrovanými dátami (napr. multimediálny obsah) - podpora prehľadávania obsahu prostredníctvom navigačného rozhrania - vysoký stupeň grafickej kvality - modifikovateľnosť a prípadne dynamické prispôsobovanie sa obsahovej štruktúry, navigačných spôsobov a prezentačných štýlov - podpora proaktívneho správania, t.j. odporúčanie a filtrovanie (Jazayeri,2007,s.2) 6 Trendy v rámci dnešných webových aplikácií do značnej miery zahŕňa termín Web 2.0. Tento termín nepredstavuje nové technické špecifikácie, ale skôr súhrn trendov pri vývoji webových aplikácií a zmien pri ich používaní. Aplikácie v rámci Web 2.0 sú dynamické, reagujú na činnosť klientov a ich používanie je veľmi podobné používaniu stolovej aplikácie [11] Prístupy k tvorbe webových aplikácií Prvým krokom potrebným pre vývoj webových aplikácii bol prechod zo statického zobrazovania webových stránok k dynamickému. Pri statickom zadá klient adresu a je mu zobrazená prislúchajúca stránka. Pri dynamickom je stránka vygenerovaná na serveri na základne požiadaviek a zaslaná klientovi. Nápad dynamicky generovaných stránok viedol k CGI (Common Gateway Interface). Pri CGI aplikáciách je URL zadaná klientom odkazom na skript, alebo skompilovanú aplikáciu nachádzajúci sa na serveri. Tento spôsob začal byť však veľmi nevhodný pre väčšie webové aplikácie, keďže skript / aplikácia na serveri musela zahŕňať biznis logiku spolu s kódom pre generovanie inštrukcií formátujúce vzhľad 6 Jazayeri M.: Some Trends in Web Application Development,

19 a iným potrebným kódom. To ich robilo veľmi neprehľadnými a ich úprava a rozšíriteľnosť bola veľmi náročná. Pokrokom v tejto oblasti bol model, kde sa vytvoria webové stránky obsahujúce časti kódu, ktorý je pri požiadavke vykonaný a jeho výsledky sú vložené do stránky. To síce viedlo k oveľa lepšej znovu použiteľnosti častí stránok a jednoduchšej úprave inštrukcií formátujúcich vzhľad, ale stále bola zložitá úprava kódu, ktorý bol porozhadzovaný v malých kúskoch po jednotlivých stránkach webovej aplikácie. Tieto nedostatky viedli k vývoju modelu, ktorý sa v dnešnej dobe využíva najčastejšie. V tomto modely pozostáva webová aplikácia z: - HTML dát prezentovaných klientovi (inštrukcie pre formátujúce vzhľad a kód, ale ten je obmedzený iba nato, čo sa zobrazuje klientovi) - skriptu na strane klienta, ktorý beží na jeho stanici a klient s ním interaguje (JavaScript, JScript) - skript na strane servera, ktorý komunikuje s databázou (PERL, PHP, Python, Ruby, ASP) Z pohľadu softvérového inžinierstva je na vývoj webových aplikácií veľmi dobre aplikovateľná softvérová architektúra Model-View-Controller. Jednotlivé komponenty pri webovej aplikácií: - Model obvykle triedy v rámci kódu na servery komunikujúce s databázou - Controller logika aplikácie a procesov - View samotné HTML stránky. Existuje veľké množstvo frejmvorkov na vývoj webových aplikácií využívajúcich Model-View-Controller architektúru. Vývoj v oblasti týchto frejmvorkov je rapídny. Stále vznikajú nové a existujúce prechádzajú neprestajnými zmenami a úpravami. Veľkým pozitívom pri vývoji webových aplikácií je, že všetkým klientom je vždy dostupná len jediná verzia. Tá je umiestnená na serveri takže odpadajú problémy s aktualizáciou u klientov a nekompatibilitou jednotlivých verzií. Kladie to však vyššie požiadavky na stabilitu a funkčnosť práve nasadenej verzie. Typické prvky webových aplikácií: - vyhľadávanie pomocou kľúčového výrazu - odkazy na ďalšie zodpovedajúce informácie - authoring spoluúčasť klientov aplikácie na jej obsahu - tagy kategorizácia obsahu používateľmi pomocou jednoslovných poznámok uľahčujúcich vyhľadávanie 10

20 - signály notifikovanie klienta o zmenách, napr. RSS 2.4 Webové služby Slúžia na posielanie správ po počítačovej sieti. Je možné ich využiť napr. na pretvorenie stolovej aplikácie na webovú aplikáciu. Jednotlivé triedy aplikácie si môžu medzi sebou posielať správy po sieti. Vybrané služby, ktoré poskytuje trieda, môžu byť prostredníctvom nich sprístupnené na sieťovej (internetovej) adrese. Webová služba komunikuje prostredníctvom otvorených štandardov. Je samo opisujúca, to znamená, že obsahuje zoznam služieb, ktoré ponúka okoliu. Nie je určená len pre konkrétnu aplikáciu, môže ju využívať ľubovoľná aplikácia. Dá sa povedať, že webové služby slúžia ako univerzálne rozhranie medzi aplikáciami, bez ohľadu na ich hostiteľský systém a implementačný jazyk. Dajú sa však uplatniť aj ako jednoduché jednoúčelové služby dostupné na internete, napr. služba, ktorá príjme teplotu v stupňoch Celzia a ako odpoveď odošle túto teplotu prekonvertovanú do Fahrenheitovej stupnice. Hlavné časti z ktorých sa skladá platforma webových služieb: - SOAP (Simple Object Access Protocol) - UDDI (Universal Description, Discovery and Integration) - WSDL (Web Services Description Language)[12] SOAP Komunikačný protokol slúžiaci na posielanie správ. Na komunikáciu využíva HTTP (je možné využiť aj iné protokoly, napr. SMTP (Simple Mail Transfer Protocol)), ale na rozdiel od RPC (Remote Procedure Call) nepredstavuje bezpečnostné riziko, preto nie je blokovaný z bezpečnostných dôvodov. Dáta ním prenášané sú kódované pomocou XML (Extensible Markup Language). Nie je závislý od hostiteľského programu a jeho implementačného jazyka. Spĺňa teda všetky podmienky pre využitie v rámci platformy webových služieb WSDL Už z názvu je jasné, že ide o jazyk na opis webových služieb. Používateľovi poskytne opis webovej služby a taktiež informácie ako k nej pristupovať. Tento opis má formu dokumentu vo formáte XML. 11

21 2.4.3 UDDI Globálny register pre firmy, ktoré tu môžu zverejňovať svoje webové služby a vyhľadávajú webové služby druhých firiem. Obsahuje informácie o zaregistrovaných službách a tiež ich rozhraniach (vo WSDL). Princíp jeho fungovania je znázornený na obr Registráciu tvoria tri komponenty: - biele strany obsahuje viacjazyčný opis a zameranie firmy, ktorej prislúcha daná služba - žlté strany sprostredkúvajú klasifikáciu služby, alebo firmy na základe štandardných taxonómií - zelené strany opisujú všetky informácie ohľadom prístupu k službe a jej rozhraní obr. 2.1 Ako funguje UDDI. [12] 2.5 Opis problematiky a motivácia pre vývoj Aplikácia opísaná v rámci tohto projektu je špecializovaná na použitie v oblasti diabetológie. V ďalších podkapitolách je opísané fungovanie typickej diabetologickej ambulancie v Slovenskej republike a vzťah diabetológa a pacienta. Ďalej rozoberieme dôvody vyvíjania webovej aplikácie pre ambulanciu diabetológa a jej možný prínos Prehľad oblasti Liečba diabetu je pri maximálnej abstrakcii o udržaní vhodnej hladiny cukru v krvi bez výkyvov. Hlavne faktory, ktoré ju ovplyvňujú sú prijem potravy (zvyšuje), pohybová 12

22 aktivita a aplikácia inzulínu (znižujú). Samozrejme sú tu aj iné ovplyvňujúce faktory (stres, duševná vyrovnanosť atď.). Napriek zdanlivej jednoduchosti je počet výborne kompenzovaných diabetikov minimálny. Úlohou diabetológa je okrem predpisovania potrebných liekov a spotrebného materiálu, najmä naviesť pacienta na správnu cestu, vhodne mu upraviť dávky inzulínu, odporučiť mu množstvá konzumovaného jedla, druhy vhodných potravín a najmä ho postupne priviesť k čo najväčšej samostatnosti. Osobné konzultácie medzi diabetológom a pacientom prebiehajú každé 2 mesiace, pri dobre kompenzovaných pacientoch, až po 2-4 týždne pri zle kompenzovaných. To je pomerne dlhá doba, často sa zvykne niečo zmeniť v živote pacienta, čo si vyžiada zmenu liečby, alebo dôjde k vážnym stavom. Pravidelná konzultácia s doktorom je pri stave pacienta, ktorý sa mení každý deň, nutná. Preto dochádza zo strany pacientov k častým telefonátom diabetológovi (aj vyše 10 medzi kontrolami). Problém vychádzajúci z častej zmeny stavu a zmeny liečby pacienta je aj variabilná spotreba liekov (inzulín, preventívne lieky) a spotrebného materiálu (ihly, prúžky do glukometra). Často dochádza k potrebe predpísania receptu ešte pred najbližšou kontrolou u doktora, čo vyžaduje telefonát a potrebu zájdenia do nemocnice. Pacient si vedie papierový Denník diabetika, kde si každý deň zapisuje namerané hodnoty glykémie, prípadne profily (9 meraní v jeden deň v presne stanovené časy), konkrétne dávky inzulínu a výnimočné situácie s opisom (hyperglykémia, hypoglykémia). Organizácia diabetikov (u nás Diador) pravidelne organizuje akcie pre pacientov, kde ich oboznamuje s novinkami a zaujímavosťami z tejto oblasti. Usporadúva tábory pre deti s diabetom, ale aj zájazdy pre dospelých Dôvody pre vývoj a prínos aplikácie Zlá kompenzácia diabetu vedie k častým pobytom v nemocnici na dlhšiu dobu, k zníženiu kvality života a často aj k dlhodobým následkom. Na druhej strane dobrá kompenzácia umožňuje diabetikovi plnohodnotný život bez zdravotných komplikácií. Liečba je v najväčšej miere v rukách pacienta. Jeho dobrá informovanosť je jednou z kľúčových vecí pre jej úspešnosť. Myslíme si, že overený zdroj informácií dostupný na internete by bol veľkým prínosom pre úspešnú liečbu. Môže ísť základné o informácie, ako čo robiť pri hypoglykémií, alebo hyperglykémií, až po pokročilejšie 13

23 ako týmto stavom predchádzať, ako sa pripraviť na športovú aktivitu, starostlivosť o chodidlá atď. Mohlo by ísť aj o informácie združenia Diador, termíny akcií súvisiacich s diabetom a adresy obchodov predávajúcich dia výrobky. Veľkým prínosom by určite bola aj náhrada papierového denníka (obr. 2.2), za elektronický dostupný na internete. Papierová verzia by sa využívala už iba v prípade, keby sa diabetik dlhšiu dobu nachádzal na mieste bez pripojenia k internetu. Hodnoty glykémií by sa mohli sťahovať priamo z glukometra pomocou pripojenia k PC, čo by obmedzilo ich každodenné prácne zapisovanie. Zaujímavá by bola aj možnosť výsledky zapísane v denníku zverejniť ostatným používateľom, ich diabetológovi a prípadná diskusia. Takto zameraný experiment pod názvom Diabetes Connected Health bol vykonaný v USA. Z komentára Josepha Kvedara, MD: Pilotnej štúdie sa zúčastnilo sedem pacientov s diabetom 2. typu v Massachusetts General Hospital. Účastníci štúdie dostali prístup k zabezpečenej webovej stránke, ktorá skladovala a vytvárala grafy z nameraných hodnôt glukózy štandardným glukometrom, ktoré nahrávali pacienti. Pacienti aj poskytovatelia mali prístup k webu, kde mohla namerané dáta prezerať, analyzovať a diskutovať. Stredná hladina glukózy klesla v priebehu trojmesačného pilotného obdobia, rovnako ako aj hlásené hladiny HbA1c, ktoré ukazujú na úroveň hladiny glukózy v krvi v čase. Poskytovatelia starostlivosti, ktorý sa zúčastnili štúdie uviedli, že Diabetes Connected Health program zvýšil ich dôveru pri úprave liečby prostredníctvom prezerania nameraných hodnôt glukózy uverejnených ich pacientmi ( Monegain B., 2009) 7, vyplýva jednoznačný prínos tejto metódy. Elektronické objednávanie sa na vyšetrenie, konzultácie s doktorom a predpisovanie liekov by prinieslo razantné ušetrenie času pre pacienta a rýchlejšie zodpovedanie jeho otázok a problémov. Tu je však možný problém zoslabenie vzťahu diabetológa s pacientom a zaplavovanie doktora zbytočnými otázkami. Na trhu v súčasnosti existujú aplikácie ponúkajúce niektoré z týchto funkcionalít. Náš prieskum však ukázal, že neexistuje webová aplikácia, ktorá by integrovala kompletnú potrebnú funkcionalitu pre ambulanciu diabetológa. Tiež je problémom, že dostupné aplikácie nie sú lokalizované do slovenčiny, sú často spoplatnené a neprehľadné. 7 Monegain B.: Online diabetes management may result...,

24 obr. 2.2 Vyplnená strana z papierového Denníku diabetika. 2.6 Opis existujúcich webových aplikácií V podkapitole opíšeme existujúce aplikácie, ktoré ponúkajú podobnú funkcionalitu ako aplikácia vyvíjaná v rámci tohto projektu. Zhodnotíme ich pozitíva a negatíva SimpleGlucose Ide o webovú stránku s možnosťou zapisovania nameraných hodnôt glukózy. Dostupná na 14 dní zadarmo na vyskúšanie. Zadané hodnoty sa dajú editovať a tlačiť. Možnosť priradenia poznámok k hodnotám. Možnosť zobrazenia grafov a štatistík z nameraných hodnôt a ich porovnanie s ideálnymi hodnotami. Stránka má aj verziu pre mobilné 15

25 telefóny. Ide o veľmi jednoduchú aplikáciu, navyše s chybami, preto sa nám zdá neadekvátne jej spoplatnenie. Výhody: - veľmi jednoduché použitie - pekné spracovanie prezentácie hodnôt v grafoch Nevýhody: - možnosť zadania nezmyselných hodnôt (napr. glykémia 105) - niekedy zmizne možnosť na pridanie hodnoty (treba sa odhlásiť a znovu prihlásiť) - spôsob zapisovania v podobe políčok predstavujúcich jednotlivé obdobia dňa (ako v Denníku diabetika) považujeme za prehľadnejší, ale na druhej strane ten použitý v tejto aplikácií umožňuje zápis ľubovoľného počtu hodnôt na deň - porovnanie s ideálnymi hodnotami predstavuje len porovnanie priemernej hladiny s ideálnou hladinou a percentuálne vyjadrenie tohto porovnania - nie je možnosť zadávať čísla v európskom formáte, t.j. s čiarkou - viacero chýb obr. 2.3 Úvodná stránka SimpleGlucose. Na obr. 2.3 vidíme úvodnú obrazovku stránky s možnosťou prezerania, zadávania a editácie hodnôt glukózy. Na pravej strane sú štatistiky obsahujúce priemerné denné hodnoty a splnenie cieľa čo značí pomer k ideálnym hodnotám. Na obr. 2.4 vidíme zobrazenie nameraných hodnôt glukózy v priebehu času. 16

26 obr. 2.4 Graf v SimpleGlucose Medhelp.org Všeobecný zdravotnícko-sociálny portál. Obsahuje novinky z oblasti zdravotníctva, používatelia môžu medzi sebou uzatvárať priateľstvá, čo im potom umožňuje vidieť navzájom svoje príspevky do diskusií, zápisky v denníku, uverejnené fotografie, poznámky, výsledky so svojich trackerov, alebo si navzájom dopisovať. Je tu zoznam doktorov, z ktorých, podľa ich špecializácie, má každý pridelené svoje fórum, kde odpovedá na otázky používateľov. Je tu možnosť si pridať do svojho profilu tracker, čo je webová aplikácia na monitoring príslušnej choroby. Je tu aj tracker pre diabetikov. Na obr. 2.5 je zobrazený portál s otvoreným Diabetes trackerom. Výhody: - vzájomné prepojenie používateľov - možnosť položiť otázku odborníkovi v danej oblasti - veľmi podrobne spracovaný tracker pre diabetikov - obsiahla funkcionalita dostupná na jednom mieste Nevýhody: - veľká neprehľadnosť spôsobená reklamami a nekonzistentným výzorom - dlhá doba učenia sa, potrebná pre využitie funkcionality 17

27 obr. 2.5 Medhelp Diabetes tracker HealthEngage Aplikácia slúžiaca primárne na zadávanie a prezeranie hodnôt súvisiacich s diabetom, ktoré sú rozdelené do kategórií: - hodnoty glukózy v krvi - jedlo - lieky - inzulín Súčasne je iba v beta verzii, čo bolo pravdepodobne príčinou jej nestability. Aplikácia obsahuje možnosť diskutovať s ostatnými používateľmi. Je možné si pridať svojho diabetológa ako poskytovateľa zdravotnej starostlivosti, ak je zaevidovaný, čím sa sprístupní možnosť zasielania správ a zdieľanie údajov. Výhody: - stolová aj webová verzia - stravovací plán s databázou jedál a ich kalorickými hodnotami, možnosť pridania nového jedla - zoznam liekov, ktoré používateľ užíva 18

28 - všetky zadané informácie zobrazené v grafoch rôznych druhov - generovanie reportov - sťahovanie nameraných hodnôt priamo z glukometra (musí byť samozrejme podporovaný) Nevýhody: - možno až prílišné množstvo možných zadávaných informácií - webová verzia náročná na výkon procesora - nie je verzia pre mobilné telefóny - časté pády webovej verzie - aplikácia je spoplatnená obr. 2.6 Webová verzia HealthEngage Diabetes. Na obr. 2.6 vidíme webovú aplikáciu HealthEngage Diabetes, konkrétne zobrazenie dávkovania inzulínu v priebehu dní. 19

29 3 Webová aplikácia pre diabetologickú ambulanciu V kapitole opisujeme vyvíjanú aplikáciu. Snažili sme sa dodržať štandardný životný cyklus vývoja aplikácie. 3.1 Špecifikácia vytváranej aplikácie Cieľom vyvíjanej webovej aplikácie v rámci tohto projektu bude zlepšiť fungovanie diabetologickej ambulancie, nielen z hľadiska administratívnych záležitostí, ale najmä zvýšenie kvality starostlivosti o pacientov. Súčasťou aplikácie bude elektronický Denník diabetika, kde bude možné zadávať namerané hodnoty glukózy, dávkovanie inzulínu, prípadne importovať hodnoty z glukometra. Formát denníka bude podobný formátu používanému v Slovenskej republike, na ktorý sú pacienti zvyknutí. Denníky budú dostupné na prezeranie len pre diabetológa a pre pacienta, ktorému prislúchajú. V prípade veľmi zlých výsledkov (časté hypoglykémie, hyperglykémie, prílišná zmena dávok inzulínu) bude doktorovi automaticky poskytnutý na prezretie. Glykemické hodnoty budú pre prehľadnosť zobrazené v grafe. Aplikácia bude mať aj administratívnu časť. Tu bude pre pacientov možné sledovať obsadenosť vyšetrení ich diabetológa, objednávanie na kontroly, vyšetrenia a odbery, vyžiadanie predpísania liekov. Aplikácia bude zobrazovať pacientovi dátum najbližšej kontroly. Bude možnosť zapisovať detaily o vykonanej kontrole pacienta (normálne sa vypisuje do papierového denníka vždy pri kontrole). Takisto bude môcť doktor prezerať kontroly naplánované na aktuálny deň. Pacienti budú navzájom medzi sebou, alebo so svojím diabetológom komunikovať prostredníctvom súkromných správ. Pacienti a diabetológ budú môcť na úvodnú stránku uverejňovať vlastné články, alebo odkazy na existujúce, pričom doktor bude mať možnosť ohodnotiť ich kredibilitu, prípadne ich vymazať, alebo upraviť. Aplikácia bude dostupná na internete. Prístup bude zabezpečený prihlasovacím menom a heslom. Budú existovať tri druhy používateľských účtov: - Hosť (Guest) bez zadania prihlasovacích údajov, dostupné prihlásenie do aplikácie, registrácia alebo obnovenie hesla 20

30 - Pacient práva hosťa a navyše dostupný denník, objednávanie na kontrolu, vyšetrenia, predpisovanie liekov, informácie o najbližšej kontrole, diskusia, zasielanie súkromných správ, import hodnôt z glukometra - Sestra hosť a navyše dostupný denník pacienta, možnosť zapisovania nameraných hodnôt pri vyšetrení - Diabetológ práva hosťa + zasielanie súkromných správ, diskusia, predpisovanie liekov, prezeranie a editácia naplánovaných kontrol, prezeranie denníkov pacientov s možnosťou pridávania poznámok Funkcionalita, ktorá vo vytvorenej verzii pre projekt nebude zahrnutá: - databáza s nutričnými hodnotami jedál - video rozhovor s doktorom a medzi pacientmi. 3.2 Návrh Podkapitola obsahuje prípady použitia, architektúru a model údajov pre vyvíjanú aplikáciu Prípady použitia pre navrhovanú aplikáciu V tejto časti uvedieme prípady použitia pre vyvíjanú aplikáciu. Pre prehľadnosť sú prípady použitia zoskupené podľa hráčov ku ktorým prislúchajú. Títo hráči sú zhodní s rolami v systéme, pričom ešte existuje hráč Používateľ, ktorý je zovšeobecnením každého používateľa aplikácie. Teda aj neprihláseného. Prípady použitia pre používateľa obr. 3.1 Diagram prípadov použitia pre používateľa 21

31 Na obr. 3.1 je zobrazený diagram prípadov použitia pre rolu Používateľa. Opis jednotlivých elementov: - Používateľ hráč predstavujúci zovšeobecnenie každé používateľa aplikácie - UC01 Prihlásenie do systému prípad použitia predstavujúci prihlásenie do systému pre používateľa prostredníctvom mena a hesla, používateľ tým prejde do inej role - UC02 Registrácia - prípad použitia predstavujúci zaregistrovanie používateľa do aplikácie - UC03 Vyžiadanie hesla - prípad použitia predstavujúci vyžiadanie hesla pomocou kontrolnej otázky Prípady použitia pre pacienta obr. 3.2 Diagram prípadov použitia pre pacienta Na obr. 3.2 je zobrazený diagram prípadov použitia pre rolu Pacienta. Opis jednotlivých elementov: 22

32 - Pacient hráč predstavujúci pacienta prihláseného do aplikácie, dedí všetky prípady použitia od Používateľa - UC04 Čítaj správy - prípad použitia predstavujúci čítanie prijatých súkromných správ v systéme - UC05 Prezri odoslané správy - prípad použitia predstavujúci prezeranie odoslaných súkromných správ v systéme - UC06 Pošli správu - prípad použitia predstavujúci prezeranie odoslaných súkromných správ v systéme - UC07 Importuj hodnoty - prípad použitia predstavujúci importovanie hodnôt z textového, alebo xls súboru v požadovanom formáte - UC08 Objednaj na kontrolu - prípad použitia predstavujúci objednanie, alebo žiadosť o zmenu objednávky na kontrolu prostredníctvom aplikácie - UC10 Požiadaj o predpis liekov - prípad použitia predstavujúci možnosť pre pacienta požiadať doktora o elektronický predpis na lieky - UC11 Prezeraj graf - prípad použitia predstavujúci prezeranie grafu glykemických hodnôt - UC12 Prezeraj naplánované kontroly - prípad použitia predstavujúci možnosť prezerať objednávky na kontroly, úroveň detailov závisí od role prihláseného používateľa, napríklad pacient vidí iba obsadenosť ambulancie 23

33 Prípady použitia pre sestru obr. 3.3 Diagram prípadov použitia pre sestru Na obr. 3.3 je zobrazený diagram prípadov použitia pre rolu Sestra. Opis jednotlivých elementov: - Sestra hráč predstavujúci sestru prihlásenú do aplikácie, dedí všetky prípady použitia od Používateľa - UC04 Čítaj správy - prípad použitia predstavujúci čítanie prijatých súkromných správ v systéme - UC05 Prezri odoslané správy - prípad použitia predstavujúci prezeranie odoslaných súkromných správ v systéme - UC06 Pošli správu prípad použitia predstavujúci prezeranie odoslaných súkromných správ v systéme - UC13 Prezeraj dnešné kontroly - prípad použitia predstavujúci prezeranie kontrol pacientov v aktuálny deň 24

34 - UC19 Zadaj namerané hodnoty z vyšetrenia - prípad použitia predstavujúci zadanie nameraných hodnôt z vyšetrenia (hmotnosť, glukóza, hemoglobín, cholesterol do systému) Prípady použitia pre doktora obr. 3.4 Diagram prípadov použitia pre doktora Na obr. 3.4 je zobrazený diagram prípadov použitia pre rolu Doktor. Opis jednotlivých elementov: - Doktor hráč predstavujúci doktora prihlásenú do aplikácie, dedí všetky prípady použitia od Používateľa - UC04 Čítaj správy - prípad použitia predstavujúci čítanie prijatých súkromných správ v systéme - UC05 Prezri odoslané správy - prípad použitia predstavujúci prezeranie odoslaných súkromných správ v systéme 25

35 - UC06 Pošli správu - prípad použitia predstavujúci prezeranie odoslaných súkromných správ v systéme - UC11 Prezeraj graf - prípad použitia predstavujúci prezeranie grafu glykemických hodnôt - UC13 Prezeraj zoznam predpisov - prípad použitia predstavujúci prezeranie vypísaných elektronických predpisov a predpisov, o ktoré žiadajú pacienti - UC14 Prezeraj dnešné kontroly - prípad použitia predstavujúci prezeranie kontrol pacientov v aktuálny deň - UC15 Prezeraj históriu kontrol - prípad použitia predstavujúci prezeranie histórie doteraz vykonaných kontrol - UC16 Schváľ predpis prípad použitia predstavujúci schválenie elektronického predpisu na lieky o ktorý zažiadal pacient - UC17 Vypíš sumár kontroly - prípad použitia predstavujúci vypísanie výsledku vyšetrenia a zhodnotenie stavu kompenzácie - UC18 Vytvor predpis - prípad použitia predstavujúci vytvorenie elektronického predpisu na lieky doktorom Architektúra aplikácie Na obr. 3.5 Náčrt architektúry aplikácie je na diagrame znázornená architektúra aplikácie a interakcia aplikácie s používateľom. Samotná aplikácia sa nachádza na webovom serveri. Skladá sa z prezentačnej vrstvy, väčšina logiky je umiestnená v pridružených súboroch v jazyku C#. Ďalej tu sú SSIS balíčky, ktoré vedia spracovať vstupné súbory v rôznych formátoch a uložiť ich do databázy. 26

36 obr. 3.5 Náčrt architektúry aplikácie Dáta aplikácie sú uložené v relačnej databáze, konkrétne MS SQL Server Na prístup, modifikáciu, alebo vkladanie dát sa využívajú 2 spôsoby: 1. ADO.NET 2. LINQ to SQL databázový mapper, s dátami sa dá pracovať v kóde normálne ako s objektmi Z webovej služby si aplikácia sťahuje zoznam liekov a detaily k nim. Idea je, že webovú službu bude poskytovať iná autorita, ktorá bude poskytovanú databázu liekov pravidelne aktualizovať. Služba sa samozrejme napája na vlastnú databázu, pričom tu je pripojenie realizované len prostredníctvom ADO.NET. Komunikácia je šifrovaná prostredníctvom SSL o sile 128 bitov, pričom na identifikáciu služby, i klientov sa využívajú certifikáty. 27

37 Okrem interného posielania správ v aplikácií je notifikácia používateľa o dôležitých udalostiach realizovaná prostredníctvom zasielania ov, pričom sa využíva SMTP server, ktorý nastavíme v konfiguračnom súbore. Adresy používateľov sú uložené v databáze. Používateľ na prístup k aplikácií využíva webový prehliadač. Do aplikácie je možné importovať namerané hodnoty z glukometra, pokiaľ ten umožňuje ich export do nejakého súboru. Stačí, aby bol v aplikácií prítomný SSIS balíček pre daný glukometer. To prináša ľahkú rozšíriteľnosť pri novom type glukometra, keďže stačí pridať SSIS balíček bez nutnosti zasahovať do kódu Model údajov V tejto podkapitole si opíšeme model údajov vo vyvíjanej aplikácií. Najskôr logický model, ktorý následne pretransformujeme na model fyzický. Logický model údajov. Je model údajov nezávislý od použitej databázovej technológie. Kvôli pomerne veľkému počtu entít (16) sme ho rozdelili na dve časti. Prvá časť obsahuje model týkajúci sa dát o používateľoch, v druhej časti sú obsiahnuté zvyšné entity. Ústrednou a spoločnou entitou v oboch modeloch je aspnet_users. Jej popis je v nasledujúcom texte. obr. 3.6 Prvá časť logického modelu údajov 28

38 Logický model na obr. 3.6 znázorňuje dátové entity, ktoré sa tykajú používateľov a informácií o nich. Entity s názvom v tvare aspnet_(názov entity) sú vygenerované automaticky, vďaka použitiu asp.net členstva. Kľúčovou entitou v modely je aspnet_users. Predstavuje používateľské konto. Ďalšie údaje o používateľovi ako heslo, sú obsiahnuté v entite aspnet_membership. Citlivé údaje sú zašifrované. Nemá k nim prístup ani správca databázy. Tú sme do diagramov s ohľadom na prehľadnosť nezahrnuli. Údaje špecifické pre vyvíjanú aplikáciu sú obsiahnuté v entitách rozdelených podľa roly používateľa. Uvažovali sme o zjednotení tejto entity do jednej, ale takéto riešenie sa nám zdalo prehľadnejšie. Zoznam entít: aspnet_users - ústredná tab. modelu, obsahuje používateľské kontá používateľov bez ohľadu na rolu, je tu atribút UserName uchovávajúci prihlasovacie meno používateľa (UserName) a dátum poslednej aktivity (LastActivityDate) UserDetails - predstavuje detaily o používateľovi (pacientovi), obsahuje odkaz na používateľa ku ktorému detaily prislúchajú (UserID), doktora ku ktorému pacient patrí (DoctroID) a validačný stav v ktorom je jeho konto (UserID) ValidationState - entita predstavuje stav autorizácie detailov pacienta, obsahuje názov stavu (Name) DoctorDetails - predstavuje detaily doktora, obsahuje odkaz na používateľa ku ktorému detaily prislúchajú (UserID), meno (FirstName, LastName) a tituly doktora (HonorificTitlePre, HonorificTitlePost) NurseDetails - predstavuje detaily sestričky, odkaz na používateľa (UserID) a meno (FirstName, LastName) aspnet_roles - obsahuje roly, ktoré sa nachádzajú v aplikácií, významnými atribútmi sú názov (RoleName) a opis roly (Description) aspnet_userinroles - entita, ktorá predstavuje priradenie používateľa do Roly 29

39 obr. 3.7 Druhá časť logického modelu údajov Druhá časť logického modelu údajov obsahuje entity predstavujúce informácie špecifické pre aplikáciu. Dáta sú s používateľmi zviazané prostredníctvom odkazu na entitu aspnet_users. Zoznam entít: Control predstavuje kontrolu pacienta, obsahuje údaje o ktorého pacienta ide (UserID [FK]), u ktorého doktora bola kontrola uskutočnená (DoctorID), všetky údaje namerané na kontrole, názor doktora na kompenzáciu (SubjectiveOpinion), opis klinickej kondície pacienta (ClinicalCondition) a sumár kontroly (Summary), obsahuje príznak, či ide o naplánovanú, alebo už absolvovanú kontrolu (Absolved) 30

40 Presription - predstavuje elektronický recept vydaný doktorom, obsahuje údaj o pacientovi, ktorému bol recept určený (UserID), príznak Authorized pokiaľ o recept požiada pacient (nebol priamo vydaný doktorom), doktor ho musí potvrdiť, unikátny kód receptu (Code), meno vygenerovaného PDF súboru s receptom (PDFFile) a príznak, či bol recept zamietnutý (Denied) DrugInPrescription predstavuje liek, obsahuje odkaz na elektronický predpis do ktorého prislúcha, meno lieku a počet kusov v recepte GlucoseRecord predstavuje nameranú hodnotu glykémie, obsahuje odkaz na pacienta ku ktorému prislúcha a typ glukometra (GlucometerID [FK]), čas odmerania hodnoty (DateTime) a čas importu do aplikácie (DateCreated) Glucometer predstavuje glukometer, medzi atribúty patrí názov glukometra (Name) a cesta k SSIS balíčku slúžiacemu na import hodnôt pre konkrétny typ glukometra Message entita predstavuje internú správu v systéme, atribútmi sú predmet (Subject) a telo správy (Body), odkaz na odosielateľa (Source [FK]) a príjmateľa (Destination [FK]), dátum odoslania správy (DateSend) OutOfOrdinanceDays predstavuje pracovný deň, kedy doktor pre výnimočné okolnosti neordinuje, obsahuje dátum (Date) a odkaz na doktora (DoctorID [FK]) LoggedException predstavuje výnimku vyhodenú v aplikácií, ktorá bola odchytená, atribútmi sú detaily o výnimke (DateThrown, Source, StackTrace, Message) a prípadne odkaz na používateľa pri ktorého činnosti došlo k výnimke Fyzický model údajov Na obr. 3.8 a obr. 3.9 môžeme vidieť logický model údajov pretransformovaný na fyzický model údajov. Program IBM Data Architect nám ponúkol len možnosť transformácie do MS SQL Servera verzie Oproti logickému modelu je doplnený o špecifické informácie pre vybranú databázovú technológiu. 31

41 obr. 3.8 Prvá časť fyzického modelu údajov obr. 3.9 Druhá časť fyzického modelu údajov 32

42 3.3 Grafický návrh Na obr je zobrazený navrhovaný grafický motív vytváranej aplikácie. Dôraz bol kladený najmä na jednoduchosť a prehľadnosť. obr Grafický návrh vytváranej aplikácie 33

43 4 Implementácia aplikácie 4.1 Vývojové prostredie a frejmvork Aplikácia vytváraná v rámci tohto projektu je webová aplikácia s napojením na databázu. Ako implementačný frejmvork sme zvolili ASP.NET vo verzii Aplikáciu implementujeme v prostredí Visual Studio 2008 SP1 (obr. 4.1). obr. 4.1 Visual Studio 2008 Samotné stránky sú zapísane v súboroch s príponou.aspx, sem je odporúčané pri tomto frameworku písať len statický obsah. Napriek tomu, že je možné sem priamo vsunúť obsah dynamický prostredníctvom bloku <% dynamický kód %>, je ho skôr vhodné umiestňovať do samostatného súboru s rovnakým menom, ako súbor ku ktorému prislúcha, s príponou ascx.cs. Ten je doplnený súborom s príponou ascx.desinger.cs, ktorý slúži na správnu funkciu dizajnéra vo vývojovom prostredí pre danú stránku Bližšie si to ukážeme na príklade veľmi jednoduchej stránky. Vzorová stránka sa skladá zo súborov TestPage.aspx a TestPage.aspx.cs. Obsah súboru Vzor.aspx je zapísaný v jazyku XHTML (obr. 4.2), pričom je v ňom obsiahnutý prevažne statický obsah opisujúci prvky nachádzajúce sa na stránke a ich výzor. 34

44 obr. 4.2 Obsah súboru TestPage.aspx Obsah pridruženého súboru TestPage.aspx.cs (obr. 4.3) je napísaný v jazyku C#. Je tu napísaná časť kódu ktorá sa ma vykonať pri kliknutí na tlačidlo Button1. Tento kód sme na akciu kliknutia naviazali v súbore riadkom kódu OnClick= Button1_Click. obr. 4.3 Kód pridružený k udalosti Stránku spustenú v prehliadači pred (vľavo) a po kliknutí na tlačidlo (vpravo) môžeme vidieť na Error! Reference source not found.. obr. 4.4 Zmena stránky TestPage 35

45 4.2 Technológie V tejto podkapitole sa budeme venovať zaujímavým technológiám využitým pri implementácií aplikácie Webová služba Pri implementácií sme vytvorili vlastnú webovú službu s názvom DrugWebService. Webová služba poskytuje zoznam liekov a detail o lieku. Je napojená na vlastnú databázu. Je dostupná na internetovej adrese. V reálnom nasadení a v ideálnom svete by ju poskytovala štátna inštitúcia, pričom jej databáza by bola pravidelne aktualizovaná. Naša aplikácia sa napája na túto službu, ktorú sme zverejnili na internete na adrese: < Pri nasadení aplikácie do reálnej prevádzky by bolo spojenie šifrované prostredníctvom SSL (skúšali sme pri lokálnom testovaní) a na autentifikáciu používateľov, ale aj webovej služby by slúžili obojstranné certifikáty. Z dôvodu uverejnenia aplikácie na voľný hosting, ktorý nám nesprístupňuje všetky potrebné pre takéto zabezpečenie, je spojenie nezabezpečené a služba voľne dostupná každému. Zoznam liekov je zasielaný v XML ako tab. vytiahnutá z databázy. Komunikácia prebieha prostredníctvom protokolu SOAP. Pri žiadosti o informácie o lieku posiela žiadateľ identifikačné číslo lieku, vytiahnuté zo zoznamu liekov. Webová služba naplní týmito informáciami štruktúru a pošle ju v serializovanej podobe žiadateľovi. Ako prebieha táto komunikácia vidíme na obr Horné XML je správa od žiadateľa obsahujúca identifikačné číslo a dolné je odpoveď webovej služby s detailmi o lieku vo verzii SOAP 1.2. Veľkou výhodou je, že opis štruktúry je na strane webovej služby. Takže jej zmena nevyžaduje zmenu aplikácie. Samotné využitie služby v aplikácií nastáva pri predpisovaní liekov. Či už ide o predpisovanie doktorom, alebo o požiadavku o predpis podanú pacientom. Na obr. 4.6 vidíme rozbaľovacie menu naplnené zoznamom liekov z príslušnej služby a detaily o vybranom lieku, na ktorých získanie sa využila druhá metóda poskytovaná službou. 36

46 obr. 4.5 Správy zasielané medzi webovou službou a aplikáciu 37

47 obr. 4.6 Prvky naplnené z webovej služby SSIS Vo všeobecnosti slúži SSIS (obr. 4.7) na migráciu dát. V našej aplikácií sme implementovali využitie SSIS balíčkov pri importe nameraných hodnôt glukózy z glukometra do databázy v aplikácií. Import prebieha v nasledujúcich krokoch: 1. Pripojenie glukometra k PC. 2. Export hodnôt z aplikácie glukometra do súboru, nezáleží na type súboru. 3. Import z tohto súboru do aplikácie. Veľkou výhodou SSIS oproti napríklad využitiu parsera je možnosť pridania podpory nového typu glukometra do aplikácie len pridaním SSIS balíčka. Jeho vytvorenie je veľmi jednoduché a v reálnom nasadení by vo väčšine prípadov pozostávalo len z úpravy niektorého už existujúceho balíčka. Hlavným nastavením balíčka je zdrojové a cieľové pripojenie. V našom prípade je zdrojom súbor podľa typu glukometra a cieľom databáza vyvíjanej aplikácie. Na obrázku obr. 4.7 Priebeh SSIS balíčku je otvorený balíček vo vývojovom prostredí s očíslovanými jednotlivými krokmi: 1. Vytvorenie dočasnej tabuľky, pokiaľ sa nenachádza v databáze. 2. Načítanie údajov zo zdrojového súboru (v tomto balíčku vo formáte xls). Pridanie stĺpca s identifikáciou používateľa. Vloženie do dočasnej tabuľky GlycemiaList$. 3. V tomto kroku sa požadovaným spôsobom prenesú dáta z dočasnej tabuľky do tabuľky s hodnotami glukózy. 38

48 4. Pričom sa vyberú len tie potrebné a dajú sa do požadovaného formátu. Každý balíček je ošetrený voči vkladaniu duplikovaných hodnôt. obr. 4.7 Priebeh SSIS balíčku Viacjazyčnosť Vytvorená webová aplikácia podporuje viacjazyčnosť. Konkrétne zatiaľ ide o anglický a slovenský jazyk. Viacjazyčnosť je realizovaná pomocou tzv. zdrojov. Vo vytvorenej aplikácií ide o dva súbory Resource.resx a Resources.resx.sk. Oba obsahujú rovnaké zdroje, ale ich hodnota je v inom jazyku. Príklad môžeme vidieť v tab Naviazanie na zdroj v zdrojovom kóde môžeme vidieť na obr Jazyk, v ktorom sa stránka zobrazí používateľovi je vybraný na základe jeho nastavenia prehliadača. Je však možne ho aj manuálne prepnúť v aplikácií. Útržok z Resources.resx Útržok z Resources.resx.sk tab. 4.1 Ukážka zdrojov obr. 4.8 Ukážka naviazania na zdroj 39

49 4.3 Externé knižnice V tejto kapitole sú opísané externé knižnice itextsharp Pôvodne vyvíjaná v Jave pod licenciou open-source. My v aplikácií používame verziu pre preportovanú do jazyka C#. Používame verziu V knižnici sme museli spraviť úpravy a znovu ju prekompilovať, aby bola použiteľná po nasadení na server. Využívame ju na generovanie elektronických predpisov. Po vytvorení, alebo autorizovaní predpisu doktorom sa automaticky vytvorí aj PDF súbor s predpisom, ktorý si potom môže pacient, alebo doktor stiahnuť na svoj lokálny počítač. Príklad PDF súboru môžeme vidieť na obrázku obr Prístup k súboru má iba pacient ktorému bol predpis vydaný a doktor. Všetky súbory sú zašifrované 128 bit šifrovaním a prístup k nim je zabezpečený heslom. To je v aktuálne nasadenej verzii spoločné pre všetky predpisy a zmeniteľné pomocou konfiguračného súboru aplikácie. obr. 4.9 Predpis vygenerovaný aplikáciou 40

50 4.3.2 asp:chart Ďalšou knižnicou ktorú využívame v aplikácií je System.Web.DataVisualization.dll. Ide knižnicu priamo od Microsoftu, ktorá bude súčasťou.net frejmvorku verzie 4.0. Keďže my využívame verziu 3.5, musíme ju pridať ako externú. Pridáva do vývojového prostredia prvok asp:chart, ktorý už ako názov naznačuje slúži na vykresľovanie grafov. Ide o veľmi komplexný nástroj. My sme ho využili na vykresľovanie grafov glykemických hodnôt pacientov. Jeho implementáciu v aplikácií vidíme na obr obr Graf hodnôt glykémie 4.4 Podporované prehliadače Aplikácia bola testovaná a korektne funguje v prehliadačoch Internet Explorer verzie 8 a Mozilla Firefox 3.6. Neručíme za korektné fungovanie v iných prehliadačoch. 41

51 5 Overenie Aplikáciu je sme po vývoji celú dôkladne otestovali. Prikladáme dva testy metódou čiernej skrinky, ktoré vidíme na tab. 5.1 a tab ID 1 Názov Pridanie pacienta Účel Overenie správnej funkčnosti zaregistrovania a pridania pacienta do aplikácie Vstupné podmienky Výstupné podmienky Neexistuje pacient s rovnakým prihlasovacím menom Vytvorí sa používateľské konto s právami pacienta. Krok Akcia Očakávaná reakcia 1 Používateľ ide na Používateľovi je zobrazený formulár pre zadanie potrebných informácií na stránku registrácie vytvorenie konta. Konkrétne ide o meno konta, heslo, kontaktný , bezpečnostnú a vpíše údaje otázku a odpoveď. Systém nedovolí zadať konto, ktoré už je v systéme a príliš jednoduché heslo. Heslo a potvrdenie hesla sa nesmú líšiť. Používateľ je upozornení pri nesplnení niektorej podmienky. 2 Používateľ vyplní Aplikácia ho informuje, že jeho konto bude mať plné práva pacienta až po svoje osobné údaje autorizovaní doktorom. Tomu sa automaticky pošle autorizačná správa. a potvrdí ich 3 Doktor autorizuje Používateľské konto dostane v systéme práva pacienta. osobné údaje pacienta 4 Používateľ sa Používateľ má po prihlásení plné práva pacienta prihlási tab. 5.1 Aplikačný test pridania pacienta Skutočná reakcia Rovnaká. Rovnaká. Rovnaká. Rovnaká. ID 2 Názov Predpísanie elektronického predpisu Účel Overenie správnej funkčnosti predpísania elektronického predpisu doktorom. Vstupné podmienky Výstupné podmienky Prihlásený používateľ má práva doktora. Vytvorí sa elektronický predpis. Krok Akcia Očakávaná reakcia 1 Používateľ s právami doktor ide Používateľovi je zobrazený formulár, kde má na výber komu je na stránku predpisovania predpis určený (zoznam jeho pacientov v systéme), zoznam liekov receptov. ktoré môže predpísať a informácie o nich. 2 Používateľ vyberie pacienta, Aplikácia vygeneruje predpis, pričom mu ho umožní prezerať priamo navolí požadované lieky a voľbu v aplikácií, alebo vo formáte PDF. potvrdí. 3 Pacient, ktorému bol predpis Predpis vytvorený v kroku 2 mu je zobrazený a má možnosť ho určený ide prezerať svoje prezrieť. predpisy. 4 Používateľ zvolí možnosť Aplikácia vyžiada heslo k PDF súboru. Ak je správne, je mu prezrieť predpis vo formáte PDF zobrazený daný recept v PDF formáte. tab. 5.2 Aplikačný test predpísania elektronického receptu Skutočná reakcia Rovnaká. Rovnaká. Rovnaká. Rovnaká. 42

52 6 Zhodnotenie V zimnom semestri sme v rámci tohto projektu zozbierali viacero dokumentov týkajúcich sa histórie a súčasnosti medicínskej informatiky. Väčšina z nich bola veľmi zaujímavá a na veľmi dobrej úrovni. Tiež sme študovali viaceré technológie, ako webové služby a aplikácie. Opísali sme motiváciu pre vývoj tejto aplikácie, ktorá pochádza najmä z tohto, že máme k tejto oblasti veľmi blízko. Veľkým prínosom nám bolo vyhľadanie niektorých existujúcich medicínskych webových aplikácií. Mnoho z nich však obsahovalo veľa nedostatkov a zistili sme, že prakticky neexistuje aplikácia, ktorá by sa dala použiť v prostredí, do ktorého je mierená naša aplikácia. Alebo len s veľkými obmedzeniami. V letnom semestri prišiel na rad samotný návrh a implementácia aplikácie. Počas návrh sme používali softvér IBM Rational Software Architect. Osobne máme voči nemu zopár výhrad, ale inak ide o veľmi komplexný nástroj a určite nás pri vytváraní aplikácie neobmedzoval. Na samotný vývoj aplikácie sme použili nástroje od spoločnosti Microsoft. Konkrétne Visual Studio 2008 a MS SQL Motiváciou nám bola známosť prostredia, vynikajúca dokumentácia a niektoré technológie ako napr. SSIS. Aplikáciu sme sa snažili presne ušiť potrebám diabetologickej ambulancie na Slovensku. S daným prostredím máme veľmi bohaté osobné skúsenosti, čo nám veľmi pomohlo vo vývoji, ale najmä nám bolo inšpiráciou. Ako postupne aplikácia rozsahovo rástla, rozhodli sme sa vynechať podľa nás technologicky nezaujímavú funkcionalitu. Konkrétne ide o pridávanie článkov, fórum a správy z Diadoru. Napriek tomu ponúka vyvinutá aplikácia pomerne bohatú funkcionalitu. Je možné posielať súkromné správy v rámci aplikácie, pričom aj ona samotná posiela správy na vyžiadanie autorizácie. Riešenie je pomerne zaujímavé, pričom využívame technológiu AJAX a webové kontroly v rámci asp. Je pripravené na ľahké doplnenie ďalšieho typu správ. Plánovanie na kontroly je zjednodušené, ale stále veľmi praktické. Zaujímavé je riešenie predpisovania receptov, kde na stiahnutie zoznamu liekov využívame technológiu webových služieb. Táto technológia sa nám zdá veľmi dobrá a na vyriešenie tejto činnosti priam ideálna. Umožnila nám vytvorenie úložiska zoznamu liekov, ktorý je dostupný na internete, pričom je nezávislý na platforme. Môžeme ho využiť v ľubovoľnej aplikácií na ľubovoľnej platforme, pokiaľ tá podporuje 43

53 technológiu webových služieb. V reálnom nasadení by navyše bolo možné komunikáciu s webovou službou zabezpečiť pomocou SSL a obojstranných certifikátov. To je veľká výhoda, keďže v prostredí nasadenia vyvíjanej aplikácie sa kladú veľmi vysoké nároky na bezpečnosť. Zo všetkých technológií, s ktorými sme sa pri vývoji tejto aplikácie stretli a naučili do určitej miery pracovať, nás webové služby oslovili najviac. Vidíme v tejto technológii veľký potenciál. Najmä v možnosti zabezpečiť prostredníctvom nej komunikáciu medzi heterogénnymi, už aj existujúcimi aplikáciami. Veľkým prínosom v rámci tohto projektu bolo oboznámenie sa s technológiou SSIS, ktorú využívame na import hodnôt z glukometra do aplikácie. Táto technológia slúži na dátovú migráciu, pričom ponúka nepreberné množstvo vstupných a výstupných formátov. Pridanie nového typu glukometra, je vďaka nej veľmi jednoduché. Importované hodnoty si môžu používatelia prezerať v prehľadnom grafe, pričom grafový prvok je súčasťou.net 4.0. To nám prinieslo mnoho problémov, ale vo výsledku je to presne to, čo sme chceli. Z našej strany hodnotíme vyvinutú aplikáciu veľmi pozitívne. Je presne šitá na mieru prostrediu, kde je smerovaná, ale zároveň dobre rozšíriteľná. Pri jej reálnom nasadení by však bolo nutné ešte implementovať niektorú funkcionalitu. Tá je však implementačne a technologicky nezaujímavá, preto sme sa ju rozhodli vynechať. 44

54 7 Zdroje [1] AMIA Membership Information [online]. Posledný prístup: Dostupné na internete: < [2] Ledley, R. S The story behind the development of the first wholebody computerized tomography scanner as told by Robert S. Ledley [online]. Posledný prístup: Dostupné na internete: < [3] Collen, M. F Preliminary announcement for the Third World Conference on Medical Informatics. [4] Lindberg, D. A. B.: In praise of computing [online]. In: History of Medical Informatics, 1987, s Dostupné na internete: < &CFTOKEN= >. ISBN [5] Lincoln, T. L.: An historical perspective on clinical laboratory information systems [online]. In: History of Medical Informatics, 1987, s Dostupné na internete: < &CFTOKEN= >. ISBN [6] Altman, D. E. et al.: Improving Patient Safety Five Years after the IOM Report [online elektronický časopis]. In: The New England Journal of Medicine, vol. 351, 2004, no.20, p [7] Haux, R. et al.: Strategic Information Management In Hospitals: An Introduction To Hospital Information Systems. 1. rev. vyd. New York, LLC: Springer-Verlag, s. ISBN

55 [8] ehealth zdravie na internete [online]. Posledný prístup: Dostupné na internete: < [9] Národné centrum zdravotníckych informácií [online]. Posledný prístup: Dostupné na internete: < [10] Vermeulen B.: Web Application Technologies. [online]. Dostupné na internete: < [11] Jazayeri M.: Some Trends in Web Application Development. In International Conference on Software Engineering: Future of Software Engineering [online]. New Washington, DC (USA): ACM, 2007 Dostupné na internete: < 69&CFTOKEN= &ret=1#>. ISBN [12] W3C Schools [online]. Posledný prístup: Dostupné na internete: < [13] Monegain B.: Online diabetes management may result in better care, study concludes [online]. Posledný prístup: Dostupné na internete: < [14] Wilson, E. V..: Asynchronous health care communication. In: Communications of the ACM [online elektronický časopis], vol. 46, 2003, no.6, p Dostupné na internete: < = &CFTOKEN= >. 46

56 8 Zoznam príloh Príloha A: Technická dokumentácia Príloha B: Používateľský návod Príloha C: CD nosič. Obsahuje zdrojové kódy pre aplikáciu vrátane webovej služby v rámci jedného riešenia, 2 databázy, inštalačné súbory k ústrednému projektu a dodatočným prvkom, tento dokument v elektronickej forme, testovacie súbory a obsah CD v textovom súbore. 47

57 A Príloha: Technická dokumentácia A.1 Štruktúra aplikácie Vytvorenú webovú aplikáciu tvoria štyri projekty, ktoré sú umiestnené do jedného riešenia. Pre svoju činnosť využíva aplikácia 2 SQL databázy, jednu pre webovú aplikáciu a jednu pre webovú službu. Dialance Ústredný projekt aplikácie. Ide o samotnú webovú stránku. Štruktúru projektu môžeme vidieť na obr. A.1. obr. A.1 Štruktúra projektu Dialance 48

58 Jednotlivé súčasti projektu: Adresár References obsahuje odkazy na knižnice z NET frejmvorku a externé knižnice Adresár WebReferences obsahuje odkaz na webovú službu DrugWebService, ktorú využíva aplikácia Adresár App_GlobalResources obsahuje zdroje pre aplikáciu, v súboroch Language.resx a Language.sk.resk sú uložené anglické a slovenské texty, ktoré zabezpečujú viacjazyčnosť aplikácie Adresár App_Themes obsahuje tému aplikácie, ktorá pozostáva zo súboru Skin1.skin, kde je opísaný výzor niektorých asp prvkov a z klasického CSS súboru obsahujúceho štýly Adresár InfoPages obsahuje informačné stránky Adresár LINQ obsahuje mapovanie na databázu pomocou technológie LINQ Adresár Resources obsahuje obrázky využité v aplikácií Adresár Sitemaps obsahuje mapu stránky pre každú používateľskú rolu v systéme, z tejto mapy sa dynamicky vytvára menu na stránke podľa role používateľa Adresár Tools obsahuje obslužné triedy v jazyku C#, ide o triedy pre zapisovanie výnimiek, posielanie mailov a vytváranie PDF súborov Adresár UserControls obsahuje prvky, predstavujúce štruktúru prijatej internej správy v aplikácií, sú tri typu, ktoré sa dynamicky priraďujú podľa typu správy, sú zložené zo súborov *.aspx, *.ascx.cs a *..ascx.cs.desinger, ktorých význam je opísaný v kapitole implementácia Koreňový adresár obsahuje samotné dynamické webové stránky aplikácie, každá ma klasickú štruktúru *.aspx, *.ascx.cs a *..ascx.cs.desinger, ďalej obsahuje konfiguračný súbor aplikácie Web.config Konfiguračný súbor Web.config Nachádza sa v koreňovom adresári aplikácie a nastavujeme tu hlavné parametre pre stránky. Vybrané najvýznamnejšie časti vidíme na obr. A.2. Ukážka je z konfiguračného súboru umiestneného na hostingu. Vidíme že je vo formáte xml, čo je veľmi prehľadné. 49

59 Jednotlivé časti konfiguračného súboru: connectionstrings obsahuje opis pripojenia na databázu, v ukážkovom súbore je opísané pripojenie k databáze na hostingovom serveri assemblies obsahuje referencie, ktoré sa pripoja pri kompilácií, v ukážke sú len 2 náhodne vybrané referencie mailsettings nastavenie smtp servera, ktorý sa využíva na rozosielanie mailov aplikáciou applicationsettings nastavenia aplikácie, vďaka nim sa aplikácia veľmi jednoducho nastaví pri presune na iný hosting, zmene SQL servera, alebo presune webovej služby, ktorú využíva, pozostáva z viacerých atribútov: a. Dialance_Service_DrugListService adresa webovej služby, ktorú využíva aplikácia na stiahnutie zoznamu liekov b. PDFFilesAbsolutePath cesta na ukladanie receptov v PDF formáte c. SSISPackagesAbsolutePath cesta k SSIS balíčkom pre importovanie hodnôt z glukometra d. SQLServer cesta k MS SQL serveru, ktorý využíva aplikácia e. PDFOwner heslo k vytváraným PDF súborom pre vlastníka f. PDFuser heslo k vytváraným PDF súborom pre používateľa 50

60 obr. A.2 Konfiguračný súbor pre vytvorenú webovú aplikáciu 51

61 DialanceBI Projekt typu Biznis Inteligencie. Jeho obsah vidíme na obr. A.3. V aplikácií používame 2 balíčky v adresári SSIS Packages. Tie manuálne kopírujeme do koreňového adresára aplikácie, kde vytvoríme adresár SSIS. Táto cesta je meniteľná prostredníctvom konfiguračného súboru. obr. A.3 DialanceBI projekt DrugListWebService Projekt predstavujúci webovú službu. Štruktúru projektu vidíme na obr. A.4. Súčasťou projektu sú odkazy na knižnice v adresári References. V tomto projekte využívame iba súčasti.net frejmvorku. Súbor DataSetDrugs.xsd aj s pridruženými súbormi predstavuje napojenie na databázu prostredníctvom technológie datasetov. Služba využíva databázu nezávislú od webovej aplikácie. Súbor DrugDetailStruct.cs obsahuje opis štruktúry predstavujúcej detaily o lieku. DrugListService.asmx s pridruženým súborom asmx.cs predstavuje opis samotnej webovej služby a jej metód. Ďalej je tu súbor ExceptionLogger.cs, ktorý slúži na zápis prípadných výnimiek do databázy. Poslednou položkou v projekte je konfiguračný súbor Web.config. V ňom je možnosť nastaviť pripojenie k SQL serveru. Ukážku vidíme na obr. A.5. obr. A.4 Projekt webovej služby pre poskytovanie zoznamu liekov 52

62 obr. A.5 Konfiguračný súbor pre vytvorenú webovú službu DialanceSetup Projekt, ktorý slúži na jednoduchšiu inštaláciu webovej aplikácie na server. Po skompilovaní vytvorí dva súbory DialanceSetup.msi a setup.exe. Po ich spustení nás prevedie inštalačným sprievodcom. Krok sprievodcu pri vyberaní miesta inštalácie vidíme na obr. A.6. obr. A.6 Sprievodca inštaláciu vytvorenej webovej aplikácie 53

63 SQL Databázy Databáza Dialance Databáza pre webovú aplikáciu. Jej štruktúru vidíme na obr. A.7. V adresári Tables je zoznam dátových entít. Tie sú opísane v podkapitole Model údajov. V adresároch Stored procedures a Scalar-valued functions sú vytvorené procedúry a funkcie pre túto databázu. Zoznam procedúr: dbo.getreceivedmessages procedúra, ktorá vráti tabuľku so zoznamom správ pre zobrazenie na stránke Prijatých správ. Je využitý príkaz UNION pre spojenie troch druhov správ: 1. Autorizácia elektronického predpisu. 2. Autorizácia údajov o pacientovi. 3. Prijatá správa od iného používateľa aplikácie. Zoznam funkcií: dbo.getaccountnamefromuserid vráti meno konta, vstupným parametrom je unikátny identifikátor používateľa dbo.getaverageglymeciafromuserid - vráti priemernú glykémiu, vstupným parametrom je unikátny identifikátor používateľa dbo.getdoctoridfromuserid - vráti unikátny identifikátor doktora, vstupným parametrom je unikátny identifikátor používateľa dbo.getnamefromuserid - vráti meno používateľa, vstupným parametrom je unikátny identifikátor používateľa, pre doktora aj s titulmi dbo.getnamefromuseridreverse - vráti meno používateľa, vstupným parametrom je unikátny identifikátor používateľa 54

64 obr. A.7 Štruktúra databázy Dialance Databáza Drugs Databáza pre webovú službu. Na obr. A.8 vidíme zoznam tabuliek v databáze: dbo.drug entita predstavujúca liek dbo.drugdetails entita predstavujúca informácie o lieku dbo.indicationgroup predstavuje indikačnú skupinu lieku dbo.loggedexception predstavuje informácie o vyhodenej výnimke 55

65 A.2 Dostupnosť obr. A.8 Štruktúra databázy Drugs Webová aplikácia je dostupná na adrese < Daná stránka je naplnená relevantnými údajmi. Prihlasovacie mená a heslá pre testovacích používateľov sú v tab. A.1. Prihlasovacie meno Heslo Rola barak bakalarka** Doktor Marek bakalarka** Pacient janickaja bakalarka** Sestra tab. A.1 Testovacie kontá vo vytvorenej aplikácií Webová služba na adrese < Využili sme služby voľného hostingu. Napriek veľmi ochotnej podpore sa našla funkcionalita, ktorú sme neboli schopný rozbehať. Konkrétne ide o import hodnôt prostredníctvom SSIS balíčkov. Danú funkcionalitu je možné vyskúšať prostredníctvom otvorenia a spustenia riešenia, alebo ju predvedieme na lokálnom PC. A.3 Otvorenie a spustenie riešenia Pre otvorenie a spustenie riešenia so všetkými projektmi je nutné mať nainštalovaný určitý softvér a dodržať určité kroky. Riešenie je možne otvoriť v operačnom systéme vo verzii XP a vyššie. 56

66 Softvér Je potrebné mať nainštalované Visual Studio 2008 vo verzii Professional. Riešenie je pravdepodobne otvoriteľné aj vo verzii Túto možnosť sme však netestovali. Ďalšou podmienkou je mať nainštalovaný.net frejmvork vo verzii 3.5 s SP1. Do neho je potrebné doinštalovať prvok grafu. Inštalačný súbor pre tento prvok je na priloženom CD v adresári Chart Control. Pre spustenie databáz prislúchajúcich k projektu je potrebné mať nainštalovaný MS SQL Server vo verzii 2008, pričom pri inštalácii musíme zahrnúť prvky Business Intelligence Development Studio a Client Tools SDK, ako vidíme na obr. A.9. obr. A.9 Výber prvkov pri inštalácií MS SQL Server 2008 Spustenie riešenia Najprv je potrebné si do PC, na ktorom ideme spustiť riešenie, stiahnuť adresár Dialance z priloženého CD, obsahujúci všetky projekty. Ďalej potrebujeme adresár Databases obsahujúci Databázy pre projekty. Pripojenie databáz: 1. Otvoríme si SQL Management Studio 2. Pravým tlačidlom klikneme na adresár Databases a vyberieme položku Attach 3. V súborovom systéme nájdeme stiahnutý adresár Databases a vyberieme súbor Dialance2.mdf. Potvrdíme. 57

67 Tento istý postup opakujeme pre súbor Drugs.mdf. Následne je potrebné v adresári Dialance, v projekte Dialance (cesta Dialance/Dialance/Web.config) korektne upraviť konfiguračný súbor. Opis jednotlivých položiek je v časti Konfiguračný súbor Web.config. Následne spustíme súbor Dialance.sln v adresári Dialance. Riešenie sa nám automaticky otvorí vo Visual Studiu aj so všetkými projektmi. Riešenie je teraz možné spustiť v móde hľadania chýb na lokálnom web serveri. 58

68 B Príloha: Používateľský návod Návod na používanie aplikácie je rozdelený do štyroch sekcií. Jedna obsahuje návody spoločné pre všetky role v systéme a ostatné tri sú rozdelené podľa rolí v systéme. V aplikácií sa navigujeme pomocou menu v hornej lište, ktoré vidíme na obr. B.1. obr. B.1 Menu pre navigáciu B.1 Všeobecná funkcionalita Prihlásenie do aplikácie Do webového prehliadača zadáme adresu < Do formulára zadáme prihlasovacie údaje a stlačíme tlačidlo prihlásiť. Vyžiadanie hesla V prípade zabudnutia hesla ideme v menu na Konto > Obnova hesla. Zadáme svoje prihlasovacie meno. Ak správne odpovieme na bezpečnostnú otázku, nové heslo nám bude zaslané mailom nastaveným v systéme. Registrácia do aplikácie V menu ideme na Konto -> Registrácia. Vpíšeme potrebné údaje. Pozor heslo musí mať minimálne 8 znakov a z toho minimálne 2 nealfanumerické. Stlačíme tlačidlo vytvoriť používateľa. Budeme presmerovaný na stránku pre zadanie detailov používateľa. Vyplníme vyžiadané detaily a stlačíme tlačidlo vlož. Plné práva pacienta nadobudneme po autorizácií doktorom. 59

69 Zmena hesla V menu Konto -> Zmena hesla môžeme zmeniť terajšieho heslo po jeho zadaní. Zaslanie súkromnej správy V menu Správy -> Pošli správu (obr. B.2). Subjekt a telo sú povinné atribúty (1 a 2). Vyberieme prijímateľa (3). Písmeno za menom označuje rolu. P pacient, N sestra, D doktor. Tlačidlom Pošli správu ju odošleme a budeme presmerovaný na stránku odoslaných správ. obr. B.2 Zaslanie súkromnej správy Čítanie prijatých a odoslaných správ V menu Správy -> Čítaj správy, alebo Správy -> Poslané správy. Ovládacie rozhranie je rovnaké pre prijaté aj odoslané správy (obr. B.3). Vidíme zoznam správ usporiadaný podľa dátumu a meno odosielateľa. Pre prečítanie správy klikneme na daný prúžok (1). 60

70 obr. B.3 Prijaté správy B.2 Návod pre rolu Doktor Autorizovanie požiadaviek Požiadavky na autorizáciu sú medzi prijatými správami (Správy -> Čítaj správy). Autorizácia predpisu je označená modrou farbou (2), autorizácia detailov používateľa farbou tmavo-zlatou(1) ako vidíme na obr. B.4. Požiadavku autorizujeme kliknutím na odkaz autorizovať (3). obr. B.4 Autorizácia požiadaviek 61

71 Plánovanie kontrol V menu Kontrola -> Plánovanie kontroly. Na obr. B.5 vidíme kalendár plánovania (1). Zeleným sú označené ordinačne dni. Ako doktor máte právo nastaviť ľubovoľný deň ako neordinačný (2), alebo ordinačný (3). Predvolene sú všetky pracovné dni ordinačné a víkendy neordinačné. Víkend nejde nastaviť ako neordinačný deň. Pozor, ak sú na daný deň prihlásený pacienti bude im odstránená kontrola. Deň vyberiete kliknutím. Zoznam pacientov prihlásených na vybraný deň (biele písmo) sa nachádza pod kalendárom (4). obr. B.5 Plánovanie kontrol Dnešné kontroly V menu Kontrola -> Dnešné kontroly. Na obr. B.6 na ľavo vidíme zoznam pacientov, ktorí majú dnes kontrolu. Pacienta vyberieme kliknutím. Vybraný pacient je označený 62

72 modrou farbou (1). Po vybratí pacienta môžeme v pravom formulári vypísať informácie o kontrole(2). Uložíme ich tlačidlom Ulož (3). obr. B.6 Dnešné kontroly História vyšetrení V menu Kontrola -> História vyšetrení. Na obr. B.7 je vľavo zobrazený zoznam vyšetrení pacientov zoradený podľa dátumu (1). Po kliknutí na vyšetrenie, vidíme na pravej strane detaily o vyšetrení (2). obr. B.7 História vyšetrení 63

73 Vydanie predpisu V menu Lekárske predpisy -> Vydaj predpis. Na obr. B.8 vidíme rozhranie pre pridanie predpisu. Pre vydanie predpisu vyberieme pacienta (1), následne vyberáme postupne lieky a ich počet (2), pričom tlačidlom Pridaj liek ich zahrnieme do predpisu (3). Tlačidlom Detaily o lieku zobrazíme detaily o práve vybranom lieku (4). Zoznam liekov už pridaných do predpisu (5). Lieky už pridané je možne odstraňovať tlačidlom vymaž (6). Predpis vytvoríme tlačidlom Vydaj predpis (7), údaje vyčistíme tlačidlom vyčisti (8). Po vydaní predpisu sme presmerovaný na stránku, kde vidíme jeho podrobnosti (obr. B.9). Predpis si môžeme stiahnuť vo formáte PDF po kliknutí na linku Stiahnuť v PDF (9). obr. B.8 Predpis receptu 64

74 obr. B.9 Podrobnosti o predpise História vydaných predpisov V menu Predpisy > Prezrieť predpisy. Na obr. B.10 vidíme zoznam vydaných predpisov pod účtom prihláseného doktora, prípadne vyžiadaných predpisov. Predpis je možno prezrieť priamo v aplikácií alebo vo formáte PDF (1). Predpis vo formáte PDF je možné prezrieť iba ak je autorizovaný (2). obr. B.10 História vydaných predpisov 65

75 Priemerné glykémie V menu Kompenzácia pacientov > Priemerné glykémie (obr. B.11). Tu vidíme zoznam našich pacientov a ich priemerné glykémie po dobu 7, 21 a 90 dní. Je tu odkaz na graf glykémií pacienta (1). obr. B.11 Priemerné glykémie pacientov Prezrieť graf glykémií V menu Kompenzácia pacientov -> Prezeraj grafy glykémií môžeme prezrieť graf z hodnôt glykémie pre všetkých nám v systéme priradených pacientov (obr. B.12). X- ová os označuje dátum namerania glykemickej hodnoty, Y-nová samotnú hodnotu. Výber pacienta uskutočníme rozbaľovacím menu (1). Môžeme vybrať tri časové úseky od aktuálneho dátumu dozadu (2), alebo ľubovoľný nami zadaný časový úsek (3). Ak v danom úseku nie sú žiadne záznamy, graf zmizne. obr. B.12 Graf glykemických hodnôt 66

76 B.3Návod pre rolu Pacient Vloženie osobných detailov V menu Konto -> Detaily používateľa (obr. B.13). Ak si vytvoríme konto po prihlásení budeme požiadaný o zadanie osobných detailov. Vypíšeme informácie (1) a doktora ku ktorému sa chceme prihlásiť (2). Následne stlačíme tlačidlo vložiť (3). Teraz musíme čakať na autorizáciu doktorom. Na jej uskutočnenie budeme upozornený mailom, ktorý nám bude doručený na uvedenú adresu pri vytváraní konta. Práva pacienta nadobúdame až po tomto kroku. Každá aktualizácia osobných údajov sa musí taktiež autorizovať. Počas tejto doby nám budú dočasne odobrané práva pacienta ak sme ich predtým mali. obr. B.13 Formulár na vloženie ďalších detailov Plánovanie kontroly V menu Kontrola -> Plánovanie kontroly. Zobrazí sa nám kalendár (obr. B.14), kde zelené dni predstavujú ordinačné dni. Pri každom dni vidíme obsadenosť. Kontrolu môžeme naplánovať kliknutím na tlačidlo Zapísať ma (1). Zrušiť ju môžeme tlačidlom Odpísať ma (2). Naplánovanú môžeme mať len jednu kontrolu. Pri pokuse sa prihlásiť na iný dátum budeme upozornený na jej vymazanie. Nad kalendárom vidíme vysvetlivky a dátum našej naplánovanej kontroly (3). Vybraný deň je označený bielou farbou písma. 67

77 obr. B.14 Plánovanie vyšetrenia Vyžiadanie lekárskeho predpisu V menu Lekárske predpisy -> Vyžiadaj lekársky predpis. Používateľské rozhranie je rovnaké ako pre rolu doktora (obr. B.8). Jediný rozdiel je nemožnosť vybrať pacienta komu je predpis určený. Tým sme automaticky my. Môžeme sa riadiť podľa návodu Vydanie predpisu, s tým rozdielom, že po vyžiadaní predpisu musíme čakať na jeho autorizáciu doktorom. Na túto udalosť budeme upozornený om. Prezeranie predpisov V menu Lekárske predpisy -> Prezri predpisy. Môžeme použiť návod História vydaných predpisov. Uvedené predpisy sú všetky určené pre nás. Import hodnôt z glukometra V menu Denník -> Importuj hodnoty (obr. B.15). V rozbaľovacom menu vyberieme typ glukometra (1). Následne vyberieme súbor, ktorý nám vyexportoval softvér priložený ku glukometru (2). A stlačíme tlačidlo Importuj (3). O úspechu importu sme upovedomený informačnou správou (4). 68

78 obr. B.15 Import hodnôt z glukometra Prezrieť graf glykémií V menu Denník -> Prezri graf. Môžeme použiť návod Prezrieť graf glykémií, s tým rozdielom, že nám nie je umožnené zmeniť pacienta. Tým sme automaticky my. B.4 Návod pre rolu Sestra Vložiť výsledky vyšetrenia V menu Kontrola -> História vyšetrení. Môžeme použiť návod Dnešné kontroly, s tým rozdielom, že nám je umožnené upravovať iba hodnoty namerané pri vyšetrení. 69