Masarykova univerzita
Fakulta informatiky
Æ
Aspekty získávání klientských dat dotykovým zařízením
Bakalářská práce
Mariusz Kotas
Brno, leden 2015 Prohlášení
Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Mariusz Kotas
Vedoucí práce: prof. RNDr. Václav Matyáš, M.Sc., Ph.D.
i Shrnutí
Tato práce pojednává o možnostech využití dotykových zařízení v procesu zís- kávání a pořizování pacientských dat v nemocničních informačních systémech. Teoretická část prezentuje pojem nemocniční informační systém a elektronická zařízení s dotykovým ovládáním. V praktické části je přiblížen aktuální nemoc- niční systém POWERNIS/SSB společnosti SEACOMP s.r.o. Výstupem práce je mj. webová aplikace, která rozšiřuje stávající POWERNIS/SSB. Tato nová apli- kace, určená primárně pro tablety, si nabídkou možnosti jednoduchého a rychlého přístupu k pacientským datům odkudkoliv v nemocnici klade za cíl zefektivnit práci zdravotního personálu.
ii Klíčová slova
Webové rozhraní, dotykové zařízení, nemocniční informační systém, POWER- NIS/SSB, SEACOMP s.r.o.
iii Poděkování
Rád bych poděkoval panu prof. RNDr. Václavu Matyášovi, M.Sc., Ph.D. za od- borné vedení této bakalářské práce. Poděkování patří rovněž vedení společnosti SEACOMP s.r.o. za možnost realizace bakalářské práce v praxi a všem kole- gům této společnosti, kteří mi při návrhu webové aplikace poskytli množství neocenitelných rad.
iv Obsah
1 Úvod ...... 1 2 Nemocniční informační systém a jeho aktuálně dostupná řešení 2 2.1 Nemocniˇcníinformaˇcnísystém ...... 2 2.2 Dotyková zaˇrízenípro bezdrátové pˇripojenív NIS ...... 2 2.2.1 Tablet ...... 3 2.2.1.1 Tablet PC ...... 3 2.2.1.2 Post-PC tablet ...... 4 2.2.2 Chytrý telefon ...... 4 2.3 NIS na zaˇrízeníchs dotykovým ovládáním pro bezdrátový pˇrenos ...... 5 2.3.1 Medeor ...... 5 2.3.2 MedicalSys ...... 6 2.3.3 GaiaEHR ...... 6 3 Nemocniční informační systém POWERNIS/SSB ...... 8 3.1 SpoleˇcnostSEACOMP s.r.o...... 8 3.2 SouˇcasnýPOWERNIS/SSB ...... 8 3.2.1 .NET ...... 10 3.2.2 SSB ...... 10 4 Analýza požadavků ...... 12 4.1 Vize ...... 12 4.2 Funkˇcnípožadavky ...... 12 4.3 Nefunkˇcnípožadavky ...... 14 5 Výběr vhodných technologií ...... 15 5.1 Backend ...... 15 5.1.1 Apache a REST služba ...... 15 5.1.2 Vestavěný webový server ...... 17 5.1.3 IIS a SSBTcpCommunicator ...... 17 5.1.3.1 ASP.NET ...... 18 5.2 Frontend ...... 19 5.2.1 AJAX ...... 19 5.2.2 jQuery ...... 19 5.2.3 Bootstrap ...... 21 6 Návrh aplikace ...... 23 6.1 Použité nástroje ...... 23 6.1.1 Visual Studio 2013 ...... 23 6.1.2 pgAdmin ...... 23 6.1.3 Fiddler ...... 24
v 6.2 Architektura aplikace ...... 24 6.2.1 SSBCore ...... 25 6.2.2 SSBWebCore ...... 25 6.2.2.1 SSB_ORM ...... 25 6.2.3 NISWebCore ...... 27 6.2.4 PowernisWebSite ...... 27 6.3 Grafické uživatelské rozhraní ...... 27 7 Implementace ...... 28 7.1 SSB ORM ...... 28 7.1.1 Generování kódu pro entity ...... 28 7.1.2 Získání dat ze serveru ...... 29 7.1.3 Spouštění metod na serveru ...... 29 7.2 Autorizace a autentizace uživatel ˚u ...... 29 7.3 Inversion of Control a Dependency injection ...... 30 7.3.1 Ninject ...... 30 7.4 Jednotkové testování ...... 30 8 Závěr ...... 32 Přílohy A Uživatelské rozhraní existujícího POWERNIS/SSB klienta .... 36 B Uživatelské rozhraní nového webového POWERNIS/SSB klienta 41
vi 1 Úvod
Obrovský rozvoj a rozšíření elektronických zařízení s dotykovým ovládáním, mezi něž řadíme mobilní telefony a tablety, měly v posledních letech významný vliv na jejich integraci i do jiných oblastí než jenom zábavních. Nacházejí uplat- nění například v pedagogice, kde učitelům pomáhají ve výuce, nebo v průmyslu, kde zjednodušují a urychlují obsluhu specializovaných aplikací. Tato bakalář- ská práce se věnuje zapojení těchto zařízení s dotykovým ovládáním do oblasti zdravotnictví. Před čtyřmi lety byl pro zefektivnění nemocničních procesů vytvořen společ- ností SEACOMP s.r.o. nemocniční informační systém POWERNIS/SSB. V sou- časné době lze klientskou část systému používat pouze na stolním nebo přenos- ném počítači s použitím klávesnice a myši. V případě, že chce zdravotní personál aktualizovat údaje o pacientovi v systému, musí se od pacienta přesunout k po- čítači, anebo všechno zapisovat na papír a později tyto údaje zadat dodatečně do systému. Pokud by chtěl data o vyšetřovaném pacientovi získat, musí si je obstarat před pacientovým příchodem nebo se opět vzdálit od pacienta během vyšetření. Tento proces je zdlouhavý a neefektivní. Proto bylo vedením společ- nosti navrhnuto rozšíření systému o možnost jednoduchého a rychlého přístupu k pacientským datům odkudkoliv v nemocnici. Hlavním cílem této práce je tedy vytvořit aplikaci, která zjednodušuje získá- vání a pořizování pacientských dat. Primárně je určena pro tablety. V teoretické části bude obecně přiblížen pojem nemocniční informační sys- tém. Dále bude pojednáno o některých elektronických zařízeních s dotykovým ovládáním a budou představeny tři současné nemocniční informační systémy, které je možné pomocí těchto zařízení ovládat. V praktické části bude prezentována společnost SEACOMP s.r.o. a její aktu- ální nemocniční informační systém POWERNIS/SSB. Bude zde popsán průběh vytváření webové aplikace, od počáteční vize, přes analýzu, až po návrh a im- plementaci. Tato bakalářská práce, která rozšiřuje současný existující nemocniční infor- mační systém POWERNIS/SSB, je tedy praktickým návodem, jak v dnešní době pomocí moderních technologií zjednodušit a zefektivnit práci zdravotnímu per- sonálu v oblasti získávání dat pacientů.
1 2 Nemocniční informační systém a jeho aktuálně do- stupná řešení
Informačním systémem (IS) obecně označujeme uspořádání vztahu mezi lidmi, datovými a informačními zdroji a technologickými prostředky a metodami, které zabezpečují sběr, přenos, zpracování a uchování dat. Takový soubor může být kromě původní standardní papírové podoby automatizovaný pomocí výpočetní techniky. [1] Jednou z oblastí, které se zavedení a realizace informačních systémů prostřed- nictvím informačních technologií a s využitím elektronických zařízení dotýká, je zdravotnictví. V případě nemocnic hovoříme o tzv. nemocničních informačních systémech. V této kapitole je obecně pojednáno o nemocničním informačním systému. Jsou zde přiblížena elektronická zařízení s dotykovým ovládáním pro bezdrátové připojení nacházející uplatnění v těchto systémech a prezentovány tři současné nemocniční informační systémy, které mohou na těchto dotykových zařízeních fungovat.
2.1 Nemocniční informační systém
Nemocniční informační systém (NIS) je vnitřní informační systém představující provozní řešení nemocnice. Poskytuje evidenci pacientů, podporuje celý proces jeho léčby – od jeho přijetí, přes stanovení diagnózy, terapeutické procesy, až po jeho propuštění včetně vyúčtování poskytnuté zdravotní péče. Jeho hlavní funkcí je usnadnit řízení celé nemocnice. Systém také poskytuje evidenci zdravotnických materiálů a orientaci na veškerý management. [2] Existuje několik různých druhů nemocničních informačních systémů. Každá nemocnice využívá svůj vlastní NIS, který je založen na konkrétních požadavcích a organizaci daného zařízení. Kromě sběru, přenosu, zpracovávání a uchovávání potřebných dat patří mezi další požadavky rychlost, aby bylo možné personálu co nejvíce usnadnit práci, a jednoduchost, aby se s tímto informačním systémem mohl rychle naučit zacházet veškerý kompetentní personál zdravotního zařízení. [3]
2.2 Dotyková zařízení pro bezdrátové připojení v NIS
V nynějším nemocničním prostředí se přenos a výměna dat v rámci NIS uskuteč- ňuje prostřednictvím počítačových sítí mechanicky (metalickým nebo optickým kabelem) nebo pak bezdrátovým přenosem. Mezi zařízení používaná běžně pro
2 2. Nemocniční informační systém a jeho aktuálně dostupná řešení bezdrátové připojení k síti řadíme přenosné počítače, stolní počítače, kapesní počítače, osobní digitální asistenty (PDA), mobilní telefony aj. [4] V současnosti dochází k prudkému nárůstu užívání elektronických zařízení s dotykovým ovládáním, a to i v oblasti zdravotnictví. Za tato dotyková za- řízení považujeme zařízení využívající elektronický vizuální displej (dotykovou obrazovku – touchscreen), která dokážou detekovat přítomnost a místo dotyku na zobrazovací ploše. Dotyk se uskutečňuje prstem, rukou nebo pomocí dalších pasivních objektů, např. pomocí stylusu. Mezi běžně dostupná a používaná elektronická dotyková zařízení pro bezdrá- tové připojení, která nacházejí uplatnění i v NIS, patří tablety a chytré telefony (smartphone).
2.2.1 Tablet
Tablet je přenosný počítač bez klávesnice s dotykovým displejem o velikosti 7 - 10 palců. Od tradičních počítačů a notebooků se liší implementací. Místo fyzické (klasické) klávesnice se často používá virtuální klávesnice na obrazovce nebo psaní pomocí stylusu. Tablety nacházejí využití jako multimediální zařízení, např. k prohlížení webu, čtení komplexních PDF a ovládání jiných zařízení. Od roku 2011 jsou na trhu dva zřetelně odlišné druhy tabletů – tablet PC (tradiční tablet PC) a Post-PC tablet. Rozdíl mezi těmito dvěma druhy tabletů je v jejich operačních systémech (OS) a hardwarovém vybavení.
2.2.1.1 Tablet PC
Tablet PC je přenosný plně funkční osobní počítač s dotykovým displejem a s nainstalovaným klasickým desktop operačním systémem. Tento koncept byl v roce 2000 předložen společností Microsoft – původní název tablet PC se týkal tabletu o velikosti osobního počítače s libovolným operačním systémem. Tablet PC obsahuje procesor, operační paměť a pevný disk, je možné k němu přes sběrnice USB a FireWire připojit běžné periferie, operační systém Windows umožňuje spouštění běžných Windows aplikací. Tablety PC jsou převážně založeny na x86 architektuře IBM-PC a používají mírně upravený operační systém osobního počítače (např. starší Windows nebo Linux Ubuntu) podporující jejich dotykové obrazovky místo tradičních displejů, myší a klávesnic. Ovládání na ploše OS vyžaduje přesnost pro výběr ovládacích prvků, proto musí být klasický tablet PC řízen stylusem. Tablet používající stylus na rozdíl od tabletů s prstem řízenými obrazovkami má často implementované rozpoznávání rukopisu. Tuto dualitu odstranil nový Windows 8, který pomocí prostředí Modern UI unifikuje ovládání na těchto dvou platformách (myš a klá-
3 2. Nemocniční informační systém a jeho aktuálně dostupná řešení vesnice, popř. stylus vs. dotykové ovládání). [5] Mezi nejznámější současné tradiční tablety PC řadíme Microsoft Surface Pro, Lenovo IdeaPad, Acer Iconia Tab a další.
2.2.1.2 Post-PC tablet
Post-PC tablety jsou tablety s mobilními operačními systémy (tzv. mobilní tablety s operačním systémem), které již nepodporují procesory Intel x86 a OS Micro- soft Windows, tzv. Wintel, ale používají procesory ARM a různé OS. Post-PC tablety běžně používají místo jednoduchých odporových dotykových obrazovek řízených stylusem kapacitní dotykové obrazovky s podporou vícedotykového ovlá- dání. Mezi nejčastěji používané operační systémy, které jsou založeny na unixo- vých operačních systémech, patří Android a iOS. Mezi operační systémy založené na Windows NT (verze 6.2 a vyšší) řadíme Windows RT. Některé tablety mají kompatibilitu s 3G technologií. Mezi tyto tablety patří iPad Apple s operačním systémem iOS, Samsung Galaxy Tab s operačním systémem Android, Microsoft Surface s operačním sys- témem Windows RT aj.
2.2.2 Chytrý telefon
Chytrý telefon patří dnes mezi jeden z nejžádanějších produktů spotřební elek- troniky. Jedná se o dotykový mobilní telefon využívající pokročilý mobilní ope- rační systém a aplikační rozhraní, které umožňuje instalaci a úpravy programů. Mezi takové operační systémy patří iOS, Android, Windows Mobile, Firefox OS, Symbian OS, BlackBerry OS, PalmOS, Tizen aj. Chytrý telefon se se svými parametry i dovednostmi stále více přibližuje po- čítači. Operační systémy jako iOS, Android, Windows Mobile, PalmOS, Bada a MeeGo poskytují možnost instalace aplikací třetích stran, které pak určují mož- nosti chytrého telefonu. Ve většině případů lze aplikace stáhnout v internetových obchodech společností, které provozují operační systém (např. Apple App Store a Google Play), přímo ze stránek výrobce a v desktopových operačních systémech. Společnost Apple však povoluje instalaci aplikací pouze ze svého AppStore a pro instalaci aplikací mimo AppStore je potřeba telefon jailbreakovat, tzn. mobilní telefon iPhone softwarově upravit. Další výhodou chytrých telefonů je nabídka velkého množství aplikací – her, prohlížečů aj. Za nevýhody chytrých telefonů patří neustálá rizika nedostatečného zázemí programového a fyzického provedení. Displej spotřebovává hodně energie, a proto je kratší výdrž baterie než u starších mobilních telefonů. Další nevýhodou je rozměr a cena samotného přístroje a přídavných programů, která se odvíjí od
4 2. Nemocniční informační systém a jeho aktuálně dostupná řešení každé nové technologie. Mobilní operační systémy jsou stejně jako desktopové náchylné na viry, avšak riziko infikace chytrého telefonu virem bývá sníženo na minimum striktní kontrolou nabízeného softwaru ze strany výrobců. Výrobou těchto telefonů se zabývá velké množství firem. Mezi nejznámější výrobce chytrých telefonů patří HTC, Siemens, Nokia, Motorola a Apple.
2.3 NIS na zařízeních s dotykovým ovládáním pro bezdrátový přenos
V této části jsou prezentovány některé konkrétní současné NIS, které je možné ovládat pomocí elektronických zařízení s dotykovým ovládáním pro bezdrátový přenos, konkrétně prostřednictvím běžných tabletů pro osobní použití. Jedná se o tuzemské systémy MEDEOR, MedicalSys a zahraniční systém GaiaEHR.
2.3.1 Medeor NIS Medeor je komerční informační systém vyvinutý společností Datasys určený pro zdravotnická zařízení včetně nemocničních. Je vybudován na centralizova- ném principu a umožňuje velmi rychlé zapojení dalších uživatelů. NIS Medeor používá tyto technologie:
• operační systém Linux – distribuce Debian, který je zdarma, ale existuje i možnost komerční podpory, jedná se o jednu z nejkvalitnějších distribucí na současném trhu,
• Apache HTTP Server,
• programovací jazyk PHP,
• relační databázový server PostgreSQL – server je v distribuci zdarma, ale existuje i možnost komerční podpory, je kvalitativně srovnatelný s nej- většími komerčními RDB,
• internetový prohlížeč (MS IE 5.5, Firefox 2.0 a vyšší).
Použité technologie dovolují snadnou vzdálenou správu systému, umožňují up- grade funkcí bez narušení provozu a jsou open source, což výrazně ovlivňuje implementační i provozní náklady. Komunikace mezi prohlížečem klienta a sys- témem je zabezpečena. NIS Medeor umožňuje komplexní objednávkový systém, administraci lůžko- vého a ambulantního provozu aj. Systém je přizpůsoben českému zdravotnictví, takže podporuje komunikaci s ÚZIS (Ústav zdravotnických informací a statistiky
5 2. Nemocniční informační systém a jeho aktuálně dostupná řešení
ČR), automatické měsíční vykazování na pojišťovny, sběr informací v průběhu hospitalizace, automatické vytvoření povinných formulářů apod. Vzhledem k tomu, že systém obsahuje webové rozhraní, lze ho používat na dotykových zařízeních. Není však prokázáno, zda je pro dotykové ovládání nějakým způsobem optimalizován – jestli je ovládání systému bez klávesnice a myši reálné v praxi. [6]
2.3.2 MedicalSys
NIS MedicalSys je intranetový zdravotnický informační systém vyvinutý marke- tingovou agenturou Pevnina CZ a je určen pro ordinace, laboratoře i polikliniky. Systém je v provozu od roku 2008, prošel několika inovacemi a byl rozšířen. Je určen především k provozu na vnitřních chráněných sítích a postaven na uni- kátním řešení vzdáleného přístupu – jednotliví lékaři, pracoviště a zdravotnická zařízení mohou spolupracovat bez ohledu na to, zda sídlí ve vedlejší místnosti nebo v jiném městě. Technologie použité při tvorbě MedicalSysu umožňují provoz bez dalších dodatečných nákladů na hardware. Systém MedicalSys funguje jako intranetová aplikace v prostředí Unix/Linux na agenturou dodaném zařízení, které je konfigurováno s ohledem na zásadně vyšší bezpečnost. Umožňuje funkce jako vedení databáze pacientů, výkazů pro zdravotní pojišťovny, komplexní fulltextové vyhledávání požadovaných informací, tvorby výkazů a výplatnic, komunikaci s ÚZIS aj. Tento lékařský software je nezávislý na operačním systému či síťovém nasta- vení, může být využíván na Windows i na Linuxu. Data lze načítat i přes mobilní telefony. [7]
2.3.3 GaiaEHR
NIS GaiaEHR je jedním ze současných zahraničních volně dostupných nemocnič- ních informačních systémů. Projekt se původně rozvětvil ze známého OpenEMR v září 2009 jako Mitos HER – Ernestem J. Rodriguezem a Hectorem „Gino“ Riverou. Po několika letech byl tento projekt a repozitář zdrojových kódů pře- jmenován na GaiaEHR . V současnosti je systém GaiaEHR stále vyvíjen a rozši- řován. Aplikace je postavena na Linuxu, webovém serveru Apache, databázi MySQL a využívá programovací jazyk PHP (společně označované jako LAMP nebo LAMPS). Jako většina LAMP návrhů může GaiaEHR fungovat v Linux, Unix, BSD, Mac OS X a Microsoft prostředí. Celé uživatelské rozhraní po straně kli- enta je vyvinuto pomocí technologie Sencha Ext JS. Tento framework se používá
6 2. Nemocniční informační systém a jeho aktuálně dostupná řešení pro dosažení moderního vzhledu a technologie web 2.0. NIS GaiaEHR je určen např. pro elektronické lékařské záznamy, vedení zdra- votnické dokumentace a účetnictví. Není však specializovaný pro české zdravot- nictví. [8]
7 3 Nemocniční informační systém POWERNIS/SSB
V této kapitole je představen nemocniční informační systém POWERNIS/SSB vytvořený společností SEACOMP s.r.o., jejíž hlavní vývojovou strategií je pro- dukovat efektivní, stabilní a transparentní software založený na nejmodernějších technologiích. [9]
3.1 Společnost SEACOMP s.r.o.
Společnost SEACOMP s.r.o., která byla založena v roce 1997, nabízí softwarové služby orientované na design, vývoj, implementaci a údržbu rozsáhlých infor- mačních systémů založených na nejmodernějších programovacích technikách a technologiích. Kromě produkování (návrhů) informačních systémů pro strojí- renský a logistický průmysl, systémů správy podnikové dokumentace a správu budov, systémové integrace, outsourcingu softwarového vývoje a intranetového řešení nabízí společnost informační systémy pro zdravotnické subjekty. Jedním z nich je i nemocniční informační systém POWERNIS/SSB. [9]
3.2 Současný POWERNIS/SSB
Nemocniční informační systém POWERNIS/SSB byl vytvořen v roce 2010 spo- lečností SEACOMP s.r.o. se záměrem vyprodukovat informační systém k ze- fektivnění nemocničních procesů. Současný NIS POWERNIS/SSB obsahuje 13 modulů (jednotlivá oddělení a procesy), které v sobě zahrnují jednotlivé speci- fické modality a funkcionality:
• Personalistika – slouží ke konfiguraci systému.
• Číselníky – obsahuje číselná data, např. směrovací čísla obcí a konfliktní skupiny výkonů.
• Oddělení AZP – umožňuje vykazování pojišťoven a tvorbu podkladů pro vyúčtování nemocniční péče.
• Statistiky – poskytuje přehled statistik podle zadaných parametrů, např. podle provedených výkonů.
• Evidence pacientů – slouží k evidenci pacientských dat, např. Modul pro centrální příjem pacientů pokrývá vyhledání pacienta podle jména, příjmení nebo rodného čísla, vložení nového pacienta do systému, edi- taci údajů o pacientovi, zařazení pacienta do fronty daného oddělení
8 3. Nemocniční informační systém POWERNIS/SSB
nemocnice a plánování návštěvy pacienta na jednotlivých odděleních nemocnice.
• Ambulance – reflektuje funkcionalitu nemocničního informačního sys- tému z pohledu ambulantního oddělení, např. vložení diagnóz, výkonů, editaci karty pacienta, vytvoření žádanky pro laboratoř, hospitalizaci a pro další odborná vyšetření.
• Hospitalizace – slouží pro hospitalizační oddělení nemocnice a podpo- ruje procesy a činnosti jako příjem pacienta, vytvoření závěrečné zprávy, přeložení pacienta, stanovení diety, vložení a editaci diagnóz, vložení a editaci výkonů, vložení a editaci ZUM, ZULP, editaci anamnéz, editaci pacientova denního dekurzu, medikace a životních funkcí, plánování ope- race, vytvoření žádanky pro ambulantní vyšetření, pro vyšetření v OKBH (Oddělení klinické biochemie a hematologie) a další odborné vyšetření, čtení laboratorních výsledků a srovnání s minulými výsledky, vytvoření a tisk tiskopisů, plánování obsazenosti lůžkového oddělení a rezervaci lůžek.
• OKBH – poskytuje automatizaci provozu laboratoře.
• Sklad – obsahuje funkcionalitu potřebnou pro objednávky, příjem zboží, inventuru aj.
• Lékárna – umožňuje spolupráci s modulem pro skladové hospodářství.
• Operační sály – poskytuje funkcionalitu potřebnou pro plánování operací a úkony s tím související.
• Radiologie – obsahuje oddělení Evidenci radiologie a slouží k poskyto- vání funkcionality potřebné pro vyšetření pacientů a zpracování výsledků na pracovištích Rentgenu a sonografie (RTG/SONO), Počítačové tomo- grafie (CT) a Magnetické rezonance (MR).
• Dokumentový sklad – zprostředkovává administrativní činnost v oddělení (recepty, žádanky atd.). [10]
Aktuální nemocniční informační systém POWERNIS/SSB je vytvořen pomocí platformy .NET s využitím programovacího jazyka C# a pomocí firemního fra- meworku Seacomp System Builder (dále jen SSB).
9 3. Nemocniční informační systém POWERNIS/SSB
3.2.1 .NET
.NET je vývojová platforma vytvořená společností Microsoft v roce 2002. Tato platforma se skládá z runtime prostředí CLR (Common Language Runtime) a sady tříd, které zajišťují vysokoúrovňový přístup k funkčnosti operačního sys- tému. Tyto třídy jsou umístěny v příslušných knihovnách (assemblies), z nichž vývojář používá pouze potřebné komponenty platformy. Ke spuštění aplikací vy- tvořených pomocí této technologie je zapotřebí, aby měl uživatel nainstalované prostředí .NET. Tato platforma není svázaná s jedním programovacím jazykem, k programo- vání na .NET může být použit každý jazyk, který splňuje její normy. Jedním s nejpřizpůsobivějších jazyků pro tuto platformu, a tím také jedním z nejčastěji používaných jazyků, je obecně, ale i v případě současného systému POWER- NIS/SSB, jazyk C#. Kód vytvořený na této platformě je přeložen do tzv. me- zijazyka CIL (Common Intermediate Language), který je spouštěn přes CLR na daném systému. Kromě toho je každá metoda třídy při prvním použití kompilo- vaná do strojového kódu. Pro každé další použití této metody je využíván takto zkompilovaný kód – tato technika se nazývá JIT (Just-In-Time compilation). Tento přístup vyústil v multiplatformní řešení. Aplikace už nevyužívají přímo WinAPI (metody vystavené přímo operačním systémem), takže je lze spustit v každém systému obsahujícím runtime prostředí. Uživatel tak nemusí nutně používat OS Windows, poněvadž jazyk C# a celá tato platforma jsou standar- dizované. Vhodnou alternativou je platforma Mono, kterou lze pak použít jak na systému Windows, tak na Linuxu, iOS a Androidu. Vývojář používající platformu .NET nemusí řešit bezpečnost a správu pa- měti, protože to zajišťuje CLR. Důležitou roli ve správě paměti hraje Garbage Collector – mechanismus odstraňující nadbytečné objekty (neobsahující jakou- koliv referenci), a tím uvolňující paměť. Tyto operace jsou obvykle prováděny automaticky a nepotřebují od programátora nic jiného než dobře napsaný kód. [11]
3.2.2 SSB
SSB neboli Seacomp System Builder představuje framework společnosti SEA- COMP s.r.o. Tento framework umožňuje velmi rychlé vytváření informačních systémů s architekturou klient-server. Server i klient je postaven na platformě .NET. Klient pro vytvoření grafického uživatelského rozhraní používá technologii Windows Forms. Server běží jako služba Windows. Klienti zasílají požadavky na server a ten je vhodně vyřizuje. K datům má přístup pouze server. Pro komunikaci mezi serverem a klienty byl vytvořen modul SSBTcpCommu-
10 3. Nemocniční informační systém POWERNIS/SSB nicator. Ten zajišťuje jak přijímání dat, tak i jejich zasílání. Na každém serveru a všech klientech je spuštěna jedna nebo více instancí tohoto modulu. Každá instance je nakonfigurovaná tak, aby propojovala právě dva uzly (klient-server nebo server-server). Prvotní informace o klientovi získává server po vyslání prvního požadavku pro přihlášení uživatele. Po úspěšném přihlášení server klienta zaregistruje a udržuje s ním spojení, dokud se klient neodpojí. Komunikace mezi dvěma uzly probíhá zcela šifrovaně. Pokud klient zasílá svůj první požadavek pro přihlášení, musí zaslat ve stejném požadavku svůj veřejný klíč. Server vygeneruje nový klíč pro symetrické šifrování, tento klíč zašifruje přijatým veřejným klíčem klienta a odešle mu zprávu zpět. Klient pomocí svého privátního klíče dešifruje tuto zprávu. Prostřednictvím takto získaného klíče pak symetricky šifruje všechny budoucí požadavky na server. Je to velmi důležité, protože s každým požadavkem se zasílají přihlašovací údaje uživatele, aby nebylo možné podvrhnout zasílanou zprávu. Vytváření desktopových klientů je velmi zjednodušené tím, že je v tomto frameworku většina věcí konfigurovatelná. Systém vytvořený pomocí SSB neob- sahuje velké množství kódů, ale obsahuje mnoho dat v konfigurační databázi. V této databázi jsou uloženy záznamy, které rozhodují o tom, jak aplikace vypadá a jakou poskytuje funkcionalitu. Každý dotaz do databáze je uložen v tabulce „queries“, v systému je označen jako SSBQuery. Každá metoda (sql příkaz insert, update, delete nebo nějaká uložená procedura) je uložená v tabulce „methods“ (SSBMethod). Záznam v tabulce dotazů může mít na sebe navázané různé zá- znamy z tabulky metod (pomocí cizích klíčů). Jejich prostřednictvím je možné za běhu aplikace vygenerovat například grafickou tabulku (SSBClientPlugin), která bude zobrazovat data z vybraného dotazu, a vykreslí nad tabulkou tlačítka pro každou navázanou metodu. Takto je vytvořena část aplikace bez napsání je- diného řádku kódu. Tento SSBClientPlugin můžeme zobrazovat uživateli přímo anebo ho připojit k jiným zasuvným modulům (pluginům), které mezi sebou spolupracují, a vytvořit tak nový komplexní SSBClientPlugin.
11 4 Analýza požadavků
Cílem této práce je implementovat nového klienta pro stávající nemocniční in- formační systém POWERNIS/SSB, konkrétně pak zobrazování pacientských dat uživatelům. Počítá se však s možným budoucím rozšířením pro zadávání údajů do systému, popřípadě s celkovým přenesením stávajícího desktopového klienta do webového prostředí. Aplikace musí být kompatibilní s různými dotykovými přístroji a musí při- stupovat k nemocniční databázi pacientů. Klient bude uživatelům umožňovat vyhledávání pacientů v databázi, rychlý přístup k hospitalizovaným pacientům a zobrazování pacientských dat (více v kapitole 4.1). Aby nevznikla nutnost implementovat aplikaci na každý druh dotykového zařízení, bude se jednat o webovou aplikaci přístupnou přes kterýkoliv prohlí- žeč. K aplikaci půjde přistupovat také skrze notebook nebo stolní počítač, ale primárně je určena pro tablety, proto bude optimalizovaná pro dotykové ovládání.
4.1 Vize
Systém bude využívat zdravotnický personál – lékaři a zdravotní sestry. Základní vize využití rozšíření systému je především ve specifických případech použití – při vizitách lékařů na pokojích pacientů, kdy lékař nemusí používat papírovou kartu pacienta, ale využívá její elektronickou formu na tabletu, který si nosí s sebou. Zdravotní sestry pak mají pořád u sebe k dispozici na svém dotykovém zařízení aktuální informace o všech pacientech na daném oddělení.
4.2 Funkční požadavky
Funkční požadavky specifikují požadované funkce, které má systém zajišťovat. Vytvoření diagramu případů užití je jedna z možností, jak tyto funkční požadavky zachytit. Tento diagram obsahuje čtyři komponenty – hranici systému, aktéry (role, přidělené uživatelům systému), případy užití (funkce, které může daný aktér vykonávat) a relace (vztah mezi aktérem a případem užití). Funkční požadavky na tento vyvíjený systém zobrazuje diagram případů užití aplikace (viz obrázek 4.1). Hlavním a v této verzi systému jediným aktérem je zdravotnický personál. Ten představuje každého uživatele, který má přístup do systému a má pravo- moce k zobrazení a administraci pacientských dat. Jedná se o lékaře, zdravotní sestry atd.
12 4. Analýza požadavků
Obrázek 4.1: Případy užití.
Zdravotnický personál může vykonávat následující funkce:
• zobrazit osobní údaje pacienta – důležité údaje jako rodné číslo, jméno, příjmení, druh pojištění, aktuální pojišťovnu atd.,
• zobrazit anamnézu pacienta – používané léky, cave, alergie a návyky,
• zobrazit kartu pacienta – seznam všech ambulancí, konsilií, hospitalizací a jejich lékařské zprávy,
• zobrazit denní dekurz – denní záznam o hospitalizaci a životních funk- cích,
• zobrazit laboratorní výsledky vyšetření – výsledky z OKBH (Oddělení klinické biochemie a hematologie) a z transfúzní služby,
13 4. Analýza požadavků
• zobrazit radiologické výsledky – RTG (rentgenové vyšetření), CT (počí- tačová tomografie), MR (magnetická rezonance), SONO (ultrazvuk).
4.3 Nefunkční požadavky
Nefunkční požadavky specifikují omezující podmínky na vyvíjený systém nebo na proces vývoje. Mezi nefunkční požadavky na navrhovaný systém patří tyto:
• aplikace bude obsahovat webové rozhraní,
• aplikace bude komunikovat s existujícím nemocničním informačním sys- témem (POWERNIS/SSB) a bude získávat pomocí jeho serveru poža- dovaná data,
• webové rozhraní aplikace bude optimalizované pro dotykové ovládání,
• aplikace bude primárně určena pro používání z tabletů.
Funkční a nefunkční požadavky na vyvíjený systém v jazyce UML (Unified Mo- deling Language) jsou stanoveny společností SEACOMP s.r.o. a jejím klientem.
14 5 Výběr vhodných technologií
K vytvoření příslušné webové aplikace je součástí strategie vhodná volba použi- tých technologií. V této kapitole jsou podrobně prezentovány zvolené technologie pro backend a frontend požadované aplikace.
5.1 Backend
Pojem backend pochází z oblasti programování webových aplikací a označuje část webové aplikace sloužící ke zpracování dat – zpracovává obsah, který se zobrazuje ve frontendu (viz kapitola 5.2). Koncept backend-frontend je nejčas- tějším schématem, podle kterého se v současnosti vytvářejí webové aplikace s dynamickým obsahem. [12] Níže je přiblížena nabídka technologií, kterých je možné využít ke komunikaci se stávajícím systémem v backendu navrhované webové aplikace (viz obrázek 5.1). V nově vytvářené webové aplikaci lze použít tyto existující systémové kom- ponenty (viz obrázek 5.1, označeno zelenou barvou):
• POWERNIS/SSB jádro – multiplatformní jádro je postaveno na plat- formě .NET, je napsáno v jazyce C# a využívá různé přídavné pluginy (např. plugin pro komunikaci s databází, logovací plugin a plugin pro komunikaci s klienty).
• Listener plugin a Transmitter plugin – v nejnovější verzi systému tyto dva druhy pluginu zastupuje SSBTcpCommunicator plugin. Ten zajišťuje obousměrnou komunikaci mezi dvěma uzly (viz kapitola 3.2.2).
• SSB Desktop klient – jedná se o stávající desktopovou aplikaci postave- nou na technologii WinForms, která využívá pro komunikaci se serverem výše popsaný SSBTcpCommunicator plugin.
5.1.1 Apache a REST služba REST (Representational State Transfer) je softwarová architektura, která po- máhá při vytváření distribuované aplikační architektury. Tato architektura je od- lehčenou verzí SOAP [13]. Data se místo formátu XML nejčastěji zasílají ve for- mátu JSON. Architektura REST používá HTTP požadavky pro dotazy (GET), vytvoření nebo úpravu dat (POST, PUT), nebo smazání dat (DELETE). REST zavádí pojmy jako bezstavová komunikace (jednotlivé požadavky na server –
15 5. Výběr vhodných technologií
Obrázek 5.1: Výběr backend řešení.
HTTP requesty spolu nejsou nijak svázány, server neví, zda jsou od téhož uži- vatele a zda spolu nějak souvisejí [14]), a jednotné rozhraní API (Application Programming Interface). Charakteristickou vlastností této architektury je „res- tové” (RESTful) rozhraní webové služby, ve kterém na rozdíl od klasického vo- lání GET, POST, PUT nebo DELETE nejsou parametry pro dané volání služby vkládány v prostoru pro parametry, ale jsou umísťovány v cestě URL [15]. Apache HTTP Server je softwarový webový server s otevřeným kódem pro GNU/Linux, BSD, Solaris, Mac OS X, Microsoft Windows a další platformy, který aktuálně dodává prohlížečům na celém světě většinu internetových stránek [16]. Ve vytvářené webové aplikaci by bylo možné rozšířit stávající server o REST službu (viz obrázek 5.1, označeno červenou barvou), pomocí které by bylo možné získávat nebo měnit požadovaná data s využitím velmi využívaného a všeobecně známého protokolu HTTP. Toto řešení se jeví jako výhodné, poněvadž REST služba umožňuje komu-
16 5. Výběr vhodných technologií nikaci s jakýmkoliv klientem, který umí využívat HTTP protokol (většina sou- časných zařízení) a který zná strukturu nabízeného API. Pro tuto službu by mohla být zvolena technologie WebAPI (Open Source novinka od Microsoftu) fungující také pod Mono projektem a server by tak zůstal stále multiplatformní. WebAPI je část frameworku .NET, jednalo by se tedy o jednoduchou integraci do stávajícího serveru. V případě navrhované aplikace je možné využít REST služby dvěma způ- soby. Při prvním z nich by se klient musel pomocí webového prohlížeče připojit přímo na POWERNIS/SSB server a získal by první webovou stránku, která by obsahovala velké množství JavaScript kódů (jednalo by se o tzv. tlustého kli- enta). Jakákoliv další komunikace by probíhala pomocí AJAX dotazu z prohlížeče klienta na REST službu běžící na serveru. Toto řešení nazýváme Single Page Ap- plication (SPA). Druhou možností je zprovoznit zvolený webový server (Apache, IIS atd.) a na něm vytvořit webovou aplikaci, která by data z POWERNIS/SSB serveru získávala pomocí REST služby, ale prohlížečům klientů by servírovala standardní webové stránky (HTML+CSS+JS, statické nebo dynamické). Jazyk a technologie webové aplikace by byly závislé od zvoleného webového serveru, např. PHP, Java, Ruby, Python a C#. Z hlediska implementace jsou řešení o rozšíření stávajícího serveru o REST službu časově náročná, proto v navrhované webové aplikaci nejsou využita.
5.1.2 Vestavěný webový server
Dalším řešením backendu navrhované aplikace je využití vestavěného webového serveru (viz obrázek 5.1, označeno oranžovou barvou). Klient by se pomocí prohlížeče připojoval přímo na POWERNIS/SSB server a ten by mu servíroval webové stránky. Díky tomu, že by byl tento webový server vestavěný v POWER- NIS/SSB serveru, získávala by se data velice jednoduše, ať už použitím exis- tujícího pluginu SSBTcpCommunicator nebo vytvořením nového jednoduchého TransmitterPluginu. Vestavěný webový server by musel být postaven na frameworku .NET. Exis- tuje několik Open Source řešení, např. Kayak, NHttp nebo Nancy. Jedná se však o velmi experimentální projekty, které jsou momentálně určeny spíše pro akade- mické účely než pro reálné využití. Tato technologie není ve vytvářené webové aplikaci použita z důvodu složitosti a velké náročnosti na implementaci.
5.1.3 IIS a SSBTcpCommunicator
V případě nově vytvářené webové aplikace se jako nejjednodušší a nejrychlejší ře- šení pro získávání dat ze serveru jeví použití stávajícího SSBTcpCommunicatoru
17 5. Výběr vhodných technologií
(podrobněji viz kapitola 3.2.2), takže volba technologie pro backend musí být svázaná s platformou .NET. Jako vhodné se nabízí využití technologie ASP.NET WebForms nebo ASP.NET MVC (o těchto dvou technologiích blíže pojednává kapitola 5.1.3.1). Abychom mohli použít ASP.NET WebForms nebo ASP.NET MVC pro tvorbu webových aplikací na této platformě, musíme zvolit externí webový server a s POWERNIS/SSB serverem komunikovat po síti. Webovou aplikaci vytvořenou pomocí některé z těchto technologií lze hostovat primárně pouze na webovém serveru IIS a operačním systému z rodiny Windows od společnosti Microsoft. Existují konkurenční webové servery pro hostování ASP.NET aplikací (např. Ul- tiDev Web Server Pro), avšak tyto technologie ke svému běhu stejně potřebují některý z operačních systémů Windows. Toto řešení backendu je ideální z mnoha důvodů. Není třeba nijak upra- vovat existující POWERNIS/SSB server. Pro komunikaci mezi servery bude využit existující plugin SSBTcpCommunicator, takže nebude potřeba vytvářet nový komunikační plugin. Webový server může běžet na jiném fyzickém zařízení než POWERNIS/SSB server, díky čemuž v případě neoprávněného přístupu na webový server nebudou citlivá pacientská data kompromitována. Další výhodou je skutečnost, že s frameworkem .NET a jazykem C# jsou velice dobře obezná- meni všichni členové týmu společnosti SEACOMP s.r.o., který POWERNIS/SSB server vyvíjí.
5.1.3.1 ASP.NET
Technologie ASP.NET je součást frameworku .NET (blíže viz kapitola 3.2.1). V současné době existují dva koncepty této technologie – ASP.NET WebForms a ASP.NET MVC. Ve verzi WebForms, která byla vytvořena v roce 2002, se přes modelování uživatelského rozhraní (UI) pomocí hierarchie serverových objektů ovládacích prvků snaží Microsoft skrýt jak HTML, tak HTTP včetně jeho bezstavovosti. Každý ovládací prvek si s využitím mechanismu ViewState udržuje svůj stav mezi požadavky, automaticky generuje svůj HTML kód a umožňuje automatické propojení klientských událostí (např. kliknutí na tlačítko) s obslužným kódem na serveru. V důsledku toho se technologie Web Forms stala obří abstraktní vrstvou s úkolem vytvořit klasické, událostmi řízené grafické uživatelské rozhraní (GUI) pro webové aplikace. V roce 2007 Microsoft představil zcela novou Open Source platformu MVC postavenou na jádru ASP.NET. Byla to reakce na vývoj nových webových tech- nologií a reakce na kritiku verze WebForms. Platforma ASP.NET MVC imple- mentuje softwarovou architekturu MVC (model-view-controller, česky model-
18 5. Výběr vhodných technologií pohled-řadič), která poskytuje velmi dobrou separaci úkolů. Tato platforma je postavena na skupině nezávislých komponentů kompatibilních s rozhraním .NET nebo postavených na abstraktních třídách, a proto lze jednoduše nahradit sys- tém směrování, řadič nebo jinou část vlastní implementací. Pro ASP.NET MVC je prioritou vytváření čistého a dodržování standardního HTML kódu. V tomto projektu je možnost uplatnit oba výše zmíněné koncepty technologie ASP.NET. Ve vytvářené aplikaci je však využito modernější platformy ASP.NET MVC, a to z důvodu čistého architektonického návrhu, velké podpory pro auto- matizované testování (unit testing) a lepší kompatibility mezi prohlížeči. Volbu této technologie ovlivnil i fakt, že ASP.NET MVC využívá skutečnou, bezstavo- vou povahu HTTP. [17]
5.2 Frontend
Jako frontend (opak backendu) se označuje část webové aplikace, která slouží k označení části webu (stránek) viditelné jeho návštěvníkům. Na rozdíl od bac- kendu bývá frontend většinou lépe propracován, a to zejména z hlediska přístup- nosti, použitelnosti a vzhledu [12]. Vytvářená aplikace využívá pro webový frontend technologii AJAX, pomoc- nou knihovnu jQuery a framework Bootstrap.
5.2.1 AJAX
AJAX (Asynchronous JavaScript and XML) je obecné označení technologie pro vývoj interaktivních webových aplikací umožňujících uživateli měnit obsah strá- nek bez nutnosti znovu načítat celou stránku. Díky přednosti této interakce mezi uživatelem a webovým serverem jsou operace s webovou aplikací dynamičtější. Ve vytvářené aplikaci je použito technologie AJAX všude tam, kde je potřeba načítat nebo upravovat data v databázi, a to z důvodu příjemnějšího a praktič- tějšího užívání samotným uživatelem. [18]
5.2.2 jQuery jQuery je javascriptová knihovna s širokou podporou prohlížečů, umožňující po- měrně jednoduchý a rychlý způsob, jak vytvořit dynamické webové aplikace bez generování komplexního kódu. Tato knihovna klade důraz na interakci mezi Ja- vaScriptem a HTML [19]. Nejnovější verzí je jQuery 2.1.0. Knihovna jQuery nabízí mimo jiné i použití následujících funkcí:
• manipulace objektovým modelem dokumentu DOM,
19 5. Výběr vhodných technologií
• zpracování atributů u HTML značek (tagů),
• změna stylů u HTML značek,
• efekty – dynamické animace,
• AJAX – asynchronní dotazy.
Ve zpracovávané aplikaci jsou použity tyto rozšiřující moduly vytvořené pomocí knihovny jQuery:
• Select2 – nahrazuje výchozí pole se seznamem (select box), podporuje vyhledávání a nekonečné rolování výsledků, zajišťuje kompatibilitu mezi prohlížeči.
Obrázek 5.2: Select2.
• DataTables – nahrazuje výchozí tabulky, přidává funkcionalitu asyn- chronního načítání dat pomocí technologie AJAX, vyhledávání v tabulce na klientovi (bez dotazu na server), řazení v jednotlivých sloupcích apod.
• Ladda-Bootstrap – rozšiřuje tlačítka o indikátor načítání, pomocí něhož má uživatel po stisknutí tlačítka ihned zpětnou vazbu a vidí, že aplikace provádí zadaný příkaz. Grafický styl tohoto rozšiřujícího modulu nava- zuje na framework Bootstrap, který je rovněž používaný v této aplikaci (viz kapitola 5.2.3).
Obrázek 5.3: Ladda-Bootstrap.
• Datepicker-Bootstrap – zjednodušuje výběr hodnoty konkrétního data, které uživatel nemusí vypisovat na klávesnici, ale může k zadání jeho
20 5. Výběr vhodných technologií
údaje použít číselnou hodnotu z nabídky vyskakovacího okna. Stejně jako v předchozím modulu je zachována grafická jednota s frameworkem Bootstrap.
Obrázek 5.4: Datepicker-Bootstrap.
Všechny tyto moduly mají otevřené zdrojové kódy a jsou uvolněné pod li- cencemi, které je umožňují použít i pro komerční účely.
5.2.3 Bootstrap Bootstrap je jednoduchý a volně dostupný soubor nástrojů pro vytváření mo- derního webu a webových aplikací a nesporně náleží k lídrům na poli frontend frameworků [20]. Byl vytvořen v roce 2010 tehdejšími vývojáři společnosti Twit- ter. Myšlenka tohoto frameworku je poměrně jednoduchá – navíc přidává a aplikuje flexibilní pravidla CSS pro rychlou tvorbu grafického vzhledu webové aplikace a podporuje vývoj responzivního web designu. CSS zahrnuje většinu HTML značek, z nichž některé obsahují už předdefinované styly (značky zod- povědné za formátování textu), u jiných je třeba zvolit požadovanou kombinaci předpřipravených tříd. V Bootstrap frameworku obecně platí, že celé uživatelské rozhraní je navr- ženo jako tabulka. Každou úroveň (celá stránka, jednotlivé elementy atd.) lze rozdělit na maximálně 12 sloupců a nekonečný počet řádků. Použitím vhodných CSS tříd je možné určit, kolik sloupců obsahuje daný element v kontejneru, přičemž prvky ve sloupcích mohou být seskupeny horizontálně v řadách. [21] Responzivnost je zajištěna výběrem vhodné definované velikosti pro každý sloupec. Tyto velikosti určují, jestli pro aktuální šířku zařízení (prohlížeče) bude tento sloupec viditelný. Na výběr máme: • „xs“ – velmi malý (menší než 768px),
• „sm“ – malý (vetší nebo rovno 768px),
• „md“ – střední (vetší nebo rovno 992px),
21 5. Výběr vhodných technologií
• „lg“ – velké (vetší nebo rovno 1200px).
Pokud například zvolíme pro dva sloupce ve stejném řádku velikost „md“, hod- noty v těchto sloupcích na všech prohlížečích se šířkou rovnou nebo větší 992 pixelů budou zobrazeny vedle sebe, ale na prohlížečích s menší šířkou budou tyto hodnoty zobrazeny pod sebou.
Obrázek 5.5: Bootstrap – rozložení.
Framework Bootstrap je ve vytvářené aplikaci používán při vytváření grafic- kého uživatelského rozhraní.
22 6 Návrh aplikace
V této kapitole je prezentován návrh aplikace, jejímž cílem je zefektivnit stáva- jící nemocniční informační systém POWERNIS/SSB, konkrétně pak zobrazování pacientských dat uživatelům. V kapitole jsou popsány použité nástroje, archi- tektura aplikace a grafické uživatelské rozhraní.
6.1 Použité nástroje
Při vývoji této webové aplikace jsou použity nástroje Visual Studio 2013 Express for Web, pgAdmin a Fiddler.
6.1.1 Visual Studio 2013
Visual Studio (VS) je vývojové prostředí od společnosti Microsoft. Slouží k vy- tváření konzolových aplikací a aplikací s grafickým uživatelským rozhraním jako jsou Windows Forms, WPF, ASP.NET aj. Integrovaný ladicí nástroj (debug- ger) pracuje jak na úrovni zdrojového kódu, tak na úrovni stroje. Visual Studio obsahuje editor kódu podporující technologii IntelliSense a mechanismy refakto- rování. Při vývoji jsou použity tyto doplňky pro Visual Studio:
• NuGet Package Manager – volně dostupný správce balíčků (knihoven) pro .NET Framework.
• Productivity Power Tools – rozšiřuje VS o nové funkcionality a zjedno- dušuje práci s tímto programem.
• Web Essentials – pomáhá při webovém vývoji, propojuje prohlížeč s VS a umožňuje vyvíjení webových aplikací v prohlížeči.
• CodeMaid – zajišťuje jednotné formátování zdrojových kódů.
6.1.2 pgAdmin
Desktopová aplikace pgAdmin je administrační nástroj pro PostgreSQL databázi. Program má grafické rozhraní, jedná se o náhradu za konzolovou aplikaci psql. V současné době je možné v programu spravovat databáze, vytvářet a upravovat databázové objekty, editovat uložené procedury atd.
23 6. Návrh aplikace
6.1.3 Fiddler
Fiddler je ladící nástroj pro HTTP komunikaci. Po zapnutí zachytává všechny HTTP požadavky vycházející z počítače a zaznamenává odpovědi. Díky tomu lze zjistit, jaká reálná data byla posílaná např. mezi prohlížečem a webovým serverem. Tento nástroj velmi zjednodušuje práci s AJAX technologií.
6.2 Architektura aplikace
Pro lepší udržovatelnost, rozšiřitelnost a pro možné budoucí znovuvyužití kódu je aplikace rozdělena na vrstvy (v tomto případě je vrstva pouze abstrakce DLL knihovny). Každá vrstva má svou jedinečnou funkčnost a své opodstat- nění. Jedná se o vrstvy SSBWebCore, NISWebCore a PowernisWebSite. Pro vývoj aplikace existují ještě další dvě vrstvy – SSBWebCore.Tests a NISWeb- Core.Tests, které seskupují unit testy pro vrstvu SSBWebCore a NISWebCore. Vyvíjená aplikace využívá existující knihovny SSBTcpCommunicator (viz kapi- tola 3.2.2) a SSBCore.
Obrázek 6.1: Vrstvy a jejich závislosti.
Obrázek 6.1 graficky znázorňuje závislosti mezi vrstvami (knihovnami), ze- leně jsou označeny existující komponenty. Stereotyp <
24 6. Návrh aplikace
6.2.1 SSBCore Stejná verze této knihovny je použita jak na serveru, tak i v klientské aplikaci. Obsahuje především všechny potřebné třídy pro komunikaci, aby odcházející a přicházející data bylo možné ve formátu xml serializovat a deserializovat stejně na serveru i klientovi. Dále obsahuje rozhraní k používaným pluginům (SSBIT- ransmitterPlugin, SSBIListenerPlugin, SSBIDataPlugin aj.) a obecnou platformě nezávislou funkčnost, např. načítání a aktivování pluginů.
6.2.2 SSBWebCore Knihovna SSBWebCore využívá SSBCore a SSBTcpCommunicator pro komuni- kaci s existujícím SSB serverem. Nemusí to být striktně POWERNIS/SSB server, knihovna nabízí možnost získat data z jakéhokoliv serveru, který je postaven na technologii SSB. To umožňuje využití této knihovny i v jiných systémech. SSBWebCore obsahuje generické třídy RepositoryRemote a RepositoryLocal. Pomocí RepositoryRemote je možné z vyšších vrstev jednoduše získávat a upra- vovat data na serveru bez detailní znalosti komunikace (více v kapitole 6.2.2.1). RepositoryLocal nabízí možnost lokálního testování vyvíjené webové aplikace bez přístupu k externímu SSB serveru. Získaná data přicházejí ze serveru ve formátu tabulky (.NET třída – Sys- tem.Data.DataTable), se kterým se obtížně pracuje ve webovém prostředí. Op- timálnější v tomto případě by byl objektový přístup, proto byla implementována komponenta SSB_ORM, která vytváří specifický objekt pro každý řádek a tyto objekty seskupuje do kolekce.
6.2.2.1 SSB_ORM ORM (object-relationnal mapping) je technika, která má za cíl umožnit auto- matický převod dat mezi relační databázi a objektově orientovaným programo- vacím jazykem. V prostředí .NET existují volně dostupná řešení, např. Entity Framework nebo nHibertane. Každý z těchto produktů ke své práci potřebuje přímý přístup do databáze. U této vyvíjené aplikace lze přistupovat pouze k ob- jektu DataTable, který získáme ze serveru, proto byl vytvořen SSB_ORM zajiš- ťující vytvoření objektu pro každý řádek z tabulky, která je ve formátu objektu DataTable. SSB_ORM před zkompilováním aplikace se pro každý požadavek (SSBQuery), který může aplikace poslat na server, pomocí reflexe vygeneruje třída (C# kód). Kterákoliv vrstva na vyšší úrovni než SSBWebCore pak používá tuto vygenero- vanou třídu.
25 6. Návrh aplikace
Příklad: V systému (v konfigurační databázi na straně serveru) je nakonfigurovaná SSBQuery se jménem „NIS.Pacient“, která obsahuje SQL dotaz. Tento SQL dotaz vrací sloupce „id“, „jmeno“, „prijmeni“, „datnar“. Před prvním použitím ve webové aplikaci SSB_ORM vygeneruje třídu pro tuto SSBQuery (viz obrázek 6.2). V systému se potom všude pracuje s kolekcí objektů typu NISPacient. SSB_ORM obsahuje implementaci generického rozhraní IRepository
Obrázek 6.2: Vygenerovaný kód.
26 6. Návrh aplikace
Obrázek 6.3: Používání IRepository.
6.2.3 NISWebCore V NISWebCore se nachází celá doménová logika aplikace. Obsahuje všechny pomocí SSB_ORM vygenerované doménové entity (např. NISPacient, viz kapi- tola 6.2.2.1). Tato vrstva získává a aktualizuje data v databázi pomocí vrstvy SSBWebCore (viz obr. 6.3), zajišťuje specifické formátování dat, validaci aj. Tato data pak nabízí všem vrstvám na vyšší úrovni, v tomto případě vrstvě PowernisWebSite. Na této vrstvě existuji třídy, tzv. fasády (návrhový vzor Façade), které zajiš- ťují již zmiňovanou doménovou funkcionalitu systému.
6.2.4 PowernisWebSite S vrstvou PowernisWebsite komunikují všichni uživatelé, jedná se o přístupový bod do systému. Tato vrstva je postavena na platformě ASP.NET MVC. Im- plementuje uživatelské rozhraní aplikace pomocí technologie HTML, CSS a Ja- vascript. Zpracovává přicházející požadavky od klientů (prohlížeče uživatelů), vrací jim odpovědi. Pro každý požadavek volá funkci (popř. skupinu funkcí) z vrstvy NISWebCore a vrácená data z této funkce (popř. skupiny funkcí) přetváří v od- pověď, kterou zasílá zpátky klientovi.
6.3 Grafické uživatelské rozhraní
Vyvíjená aplikace se snaží ve velké míře převést existující desktopové řešení informačního systému POWERNIS/SSB do webového prostředí, a to z důvodu, že tento existující systém je už pár let v provozu a jeho uživatelé, pro které bylo toto uživatelské rozhraní značně optimalizováno, umí již se systémem pracovat. V příloze A se nacházejí obrázky, na kterých jsou znázorněny části z exis- tujícího systému POWERNIS/SSB, které mají mít své ekvivalenty ve webové aplikaci.
27 7 Implementace
7.1 SSB ORM
V technologii ASP.NET MVC a typovaném jazyce C# je žádoucí, aby se s daty pracovalo jako s objekty. Proto jsem navrhl vytvořit vlastní jednoduché řešení ORM (viz kapitola 6.2.2.1). Dosud se v SSB systému využívaly pouze objekty DataTable, které v sobě zahrnují jak definici sloupců, tak všechny řádky. Pokud chceme přistupovat k specifickému řádku a získat hodnotu z nějakého sloupce, musíme definovat index řádku a název sloupce (textové označení). Toto řešení je velmi nepraktické, protože nemáme žádnou podporu od vývojového prostředí. Další nevýhodou tohoto řešení je identifikace chyby, neboť v případě překlepu v textovém označení nezjistíme tuto chybu v době kompilace, jak jsme u ty- povaných jazyků zvyklí, ale teprve až za běhu aplikace. Z toho důvodu jsem se rozhodl, že každý řádek bude reprezentován jedním objektem (entitou) a tabulka bude kolekcí těchto objektů. Třídy pro tyto objekty je nutné vytvořit před pou- žitím v systému, a aby je nemusel vývojář vytvářet sám, použije se automaticky generátor kódu.
7.1.1 Generování kódu pro entity Generování kódu je zajištěno pomocí nástroje Text Template Transformation Toolkit (T4). Jedná se o šablonu, která obsahuje text a proměnné. Uživatel na- plní tyto proměnné a T4 vygeneruje výstupní textový soubor s aplikací těchto proměnných. Tento nástroj je součástí vývojového prostředí Visual Studio (viz kapitola 6.1.1) a jeho prostřednictvím lze vytvářet šablony pro generování texto- vých souborů, velmi často se T4 používá pro generování tříd. Z tohoto důvodu je tento nástroj použit v různých knihovnách. Generování tříd je jenom jeden z možných scénářů, např. v podnikových aplikacích by T4 mohl být šablonou pro zasílané emaily. V navrhovaném systému probíhá generování tak, že se spustí skript, který se přihlásí na testovací účet na SSB serveru. Pošle se požadavek na konfiguraci SSBQuery pro generovanou entitu a z přijatých dat se naplní šablona. Spustí se generátor a vygenerovaný text je uložen do souboru s příponou „.cs“, což je přípona pro soubor se zdrojovými kódy v jazyce C#. Takto vygenerované třídy lze později přidat do projektu. V tomto projektu jsou přidávány do vrstvy NISWebCore do složky Entities. Pro každou požadovanou SSBQuery, která je nakonfigurovaná na SSB ser- veru, se vygeneruje jedna entita s vlastnostmi (člen třídy v jazyce C#) a atributy. Každá vlastnost odpovídá jednomu sloupci u dané SSBQuery. Tyto vlastnosti
28 7. Implementace mají různé atributy, např. lokalizované jméno, formát zobrazení a informace, jestli je tento sloupec primární klíč. Všechny tyto hodnoty jsou nakonfigurované na SSB serveru.
7.1.2 Získání dat ze serveru
Získání dat probíhá tak, že si zvolíme danou entitu vygenerovanou v minu- lém kroku, pro kterou chceme získat data. Pro tuto entitu se vytvoří objekt generické třídy RemoteRepository
7.1.3 Spouštění metod na serveru
Každá nakonfigurovaná SSBQuery na serveru (entita v aplikaci) může mít na sebe navázané různé metody. Mezi hlavní a nejběžnější patří metody pro vlo- žení, upravení a smazání záznamů. Na objektu RemoteRepository
7.2 Autorizace a autentizace uživatelů
První autentizace probíhá pomocí SSB serveru. Po úspěšném přihlášení se uloží unikátní klíč a přihlašovací údaje pro daného uživatele, heslo se ukládá v he- šované podobě. Pro každé další připojení tohoto uživatele aplikace kontroluje, zda je unikátní klíč validní, zda nevypršel časový limit. Pokud nevypršel, uživatel je automaticky pomocí uložených údajů přihlášen na SSB server. V opačném případě je přesměrován na první krok. Autorizace probíhá pro každý požadavek až na SSB serveru. Pokud se např. uživatel snaží spustit metodu, na kterou nemá dostatečná práva, SSB server mu v odpovědi místo výsledku vrátí chybu. To stejné platí v případě dotazu na data. Informace o právech se rovněž zasílá v konfiguraci k SSBQuery nebo SSBMethod, takže tuto informaci lze použít už na klientovi, např. nezobrazovat tlačítko pro spuštění metody.
29 7. Implementace 7.3 Inversion of Control a Dependency injection
„Inversion of Control (IoC) je paradigma, které má za cíl za- jistit, aby komponenty na vyšší úrovni nebyly závislé přímo na komponentách nižší úrovně, ale aby obě skupiny byly závislé na abstrakcích. Dále má zajistit, aby abstrakce nebyly závislé na im- plementacích, ale implementace na abstrakcích.“ ([22], s. 211)
Dependency Injection (DI) je jedním z možných návrhových vzorů, který im- plementuje paradigma Inversion of Control. Má za cíl odstranit přímé závislosti mezi komponentami pomocí architektury zásuvných modulů. Je to vzor, ve kte- rém je odpovědnost za vytváření a propojování objektů přesunuta z jednotlivých objektů do továrny, např. do IoC kontejneru. Na žádost továrna vytvoří objekt nebo nabídne objekt z fondu dostupných objektů a automaticky nastaví jeho zá- vislosti na jiných objektech (např. injekcí konstruktorem – Contructor Injection, injekcí metodou – Setter Injection, použitím rozhraní – Interface Injection nebo kombinovaným způsobem). DI je tedy implementace Inversion of Control ve smyslu automatického vnějšího vytváření objektů a tvoření vazeb mezi objekty.
7.3.1 Ninject V této aplikaci jsem jako IoC kontejner využil Ninject. Jedná se o malý, volně do- stupný kontejner s velmi jednoduchou a přehlednou obsluhou bez komplikované konfigurace. Tento kontejner je použit ve vrstvě NISWebCore, kde pomáhá zís- kávat konkrétní objekty pro zvolené rozhraní, např. pro rozhraní IRepository
7.4 Jednotkové testování
Jednotkové testování (Unit testing) je jednou z metod pro ověření správnosti programu. Nicméně se vztahuje jen k velmi nízké úrovni – testuje třídy a jed- notlivé metody. Jeho cílem je ověřit, zda skutečný efekt způsobený testovanou metodou v určitém kontextu a se specifickými vstupními parametry je podle očekávání. Jedná se o základní kámen programování řízené testy (TDD – Test- driven development). Tento způsob vývoje očekává, že se testy budou psát pro malý úsek kódu, a to před samotným napsáním tohoto úseku. [23] V této aplikaci jsem jednotkové testy použil hlavně k otestování vrstvy SSBWebCore. Testuje se celá funkčnost této vrstvy – přihlášení uživatele, zís- kávání dat ze vzdáleného serveru, spouštění metod na vzdáleném serveru, ge- nerování kódu atd. Většina těchto funkcí spolu nějak souvisí, proto je nutné po
30 7. Implementace každé malé změně na této vrstvě pouštět všechny testy a ujistit se, že všechny skončily úspěšně. K testování jsem využil nástroj z vývojového prostředí Visual Studio – Unit Testing Framework.
31 8 Závěr
Záměrem této bakalářské práce bylo vytvořit aplikaci zjednodušující získávání a pořizování pacientských dat v nemocničním informačním systému POWER- NIS/SSB vytvořeným společností SEACOMP s.r.o. Nově vytvořená aplikace je primárně určena pro tablety a na rozdíl od stávající klientské části systému pou- žívané pouze na stolním nebo přenosném počítači s použitím klávesnice, kdy je proces získávání a pořizování pacientských dat vzhledem k přesunům personálu nemocnice k počítači zdlouhavý, nabízí možnost jednoduchého a rychlého pří- stupu k pacientským datům odkudkoliv v nemocnici. Stanovený cíl se mi podařilo splnit. V teoretické části jsem přiblížil problematiku NIS včetně jejich využití v sou- časném zdravotnictví. Prezentoval jsem blíže bezdrátová zařízení, konkrétně elektronická zařízení s dotykovým ovládáním, mezi něž řadíme tablety a chytré telefony a která v dnešní době z důvodu jednoduchého ovládání, mobility a ce- nové dostupnosti nacházejí uplatnění v různých oblastech života včetně zdravot- nictví. Nedílnou součástí teoretické části bylo představení aktuálních NIS, které je možno prostřednictvím běžných tabletů pro osobní použití ovládat. Jednalo se o NIS Medeor a MedicalSys, které nacházejí uplatnění v českém zdravotnictví, a zahraniční NIS GaiaEHR. V úvodu praktické části jsem představil společnost SEACOMP s.r.o. a její aktuální nemocniční informační systém POWERNIS/SSB. Následně jsem pro tento NIS vytvořil webovou aplikaci určenou primárně pro tablety, která umož- ňuje přístup k pacientským datům odkudkoliv v nemocnici. Výhodou pro mě byla skutečnost, že jsem zaměstnancem této společnosti a NIS vytvořený touto společností vyvíjím. Podrobně jsem popsal průběh vytváření webové aplikace. Při analýze jsem vycházel ze znalostí a vlastní praxe se současným systémem. Aplikaci jsem vyvíjel za dodržování pravidel SOLID (Single responsibility, Open- closed, Liskov substitution, Interface segregation and Dependency inversion [22]) a měl jsem možnost ji testovat na interním serveru a třech typech tabletů (iPad, Sony Xperia Z, Nexus 7). Při implementaci bylo potřeba vyřešit dva podstatné problémy – zvolit vhodnou technologii pro vývoj webové aplikace a zajistit ko- munikaci se stávajícím SSB serverem. Z pohledu existujícího systému se tato webová aplikace chová jako nový druh klienta, a nevznikla tak potřeba měnit logiku a funkcionalitu SSB serveru. Postup řešení jsem průběžně konzultoval s vedoucím vývojářem a s vedením společnosti. Návrh webové aplikace byl velice přínosný pro moji praxi. Dosud jsem neměl žádné větší zkušenosti s webovými technologiemi a tato bakalářská práce mi umožnila se s touto oblastí blíže seznámit. Také jsem dostal samostatný prostor
32 8. Závěr pro vytvoření obsáhlejší webové aplikace. Vzhledem k tomu, že se do budoucna počítá s rozšířením této aplikace, bylo nutné, abych systém navrhoval a imple- mentoval s použitím osvědčených metodik (modulární architektura, návrhové vzory, čistý kód, unit testy apod.). Přestože navrhovaná webová aplikace ještě není aplikována v praxi, obsah této bakalářské práce odpovídá stanovenému cíli – rozšiřuje aktuální nemocniční informační systém POWERNIS/SSB a je základem pro budoucí přenesení tohoto systému na webové rozhraní.
33 Literatura
[1] VYMĚTAL, D. Informační systémy v podnicích: teorie a praxe projektování. 1. vyd. Praha: Grada, 2009, 142 s. Průvodce (Grada). ISBN 978-80-247- 3046-2.
[2] Nemocniční informační systém. In: EZDRAV.cz: odborný por- tal o elektronickém zdravotnictví [online]. 30.8.2012 [cit. 16.12.2014]. Dostupné z:
[3] GLANDON, G. L. - SMALTZ, D. H. - SLOVENSKY, D. J. Information Systems For Healthcare Management. 7. vyd. USA: Health Administration Press, 2008, 288 s. ISBN 1-56793-297-5.
[4] ANTALOVÁ, D. Bezdrátové technologie [online]. [cit. 16.12.2014]. Dostupné z:
[5] MRÁZEK, Š. Co je to vlastně Tablet PC? Svět hardware [online]. 4.12.2002 [cit. 16.12.2014]. ISSN 1213-0818. Dostupné z:
[6] DATASYS, NIS Medeor [online]. [cit. 18.1.2014]. Do- stupné z:
[7] PEVNINA CZ s.r.o., MedicalSys: zdravotnický informační systém [online]. [cit. 16.12.2014]. Dostupné z:
[8] CERTUN LLC., GaiaEHR [online]. [cit. 16.12.2014]. Dostupné z:
[9] SEACOMP s.r.o., O nás [online]. [cit. 16.12.2014]. Dostupné z:
[10] SEACOMP S.R.O. POWERNIS/SSB, Uživatelská dokumentace: Úvod do systému POWERNIS/SSB. 1. vyd. Brno, 2012.
[11] SHARP, J. Microsoft Visual C# 2010: Krok za krokem. 1. vyd. Brno: Computer Press, 2010. 696 s. ISBN 978-80-251-3147-3.
34 8. Závěr
[12] Internetový slovníček [online]. [cit. 16.12.2014]. Dostupné z:
[13] SOAP [online]. [cit. 16.12.2014]. Dostupné z:
[14] VALÁŠEK, M. Stavové HTTP: jak fungují Cookies, Session a ViewState a proč je nepoužívat. In: Aspnet.cz: in technology we trust [online]. 20.3.2008 [cit. 16.12.2014]. Dostupné z:
[15] RODRIGUEZ, A. RESTful Web services: The basics. In: De- veloperWorks [online]. 6.11.2008 [cit. 16.12.2014]. Dostupné z:
[16] What is the Apache HTTP Server Project? [online]. [cit. 16.12.2014]. Dostupné z:
[17] FREEMAN, A. Pro ASP.NET MVC 4. 4. vyd. Nakladatelství Apress, 2012. 756 s. ISBN 978-1-4302-4236-9.
[18] AJAX: Asynchronous JavaScript and XML [online]. [cit. 16.12.2014]. Do- stupné z:
[19] JQuery návod: Vše okolo jQuery [online]. [cit. 16.12.2014]. Dostupné z:
[20] GERCHEV, I. Top 10 Front-End Development Fra- meworks. In: Sitepoint [online]. 16.6.2013 [cit. 16.12.2014]. Dostupné z:
[21] Bootstrap: About [online]. [cit. 16.12.2014]. Dostupné z:
[22] MARTIN, R. C. - MARTIN, M. Agile Principles, Patterns, and Practices in C#. 1. vyd. USA: Prentice Hall, 2006, 768 s. ISBN 978-0131857254.
[23] MARTIN, R. C. Čistý kód. 1. vyd. Brno: Computer Press, 2009, 423 s. ISBN 978-80-251-2285-3.
35 A Uživatelské rozhraní existujícího POWERNIS/SSB klienta
Obrázek A.1: Osobní údaje pacienta.
36 A. Uživatelské rozhraní existujícího POWERNIS/SSB klienta
Obrázek A.2: Anamnézy pacienta.
37 A. Uživatelské rozhraní existujícího POWERNIS/SSB klienta
Obrázek A.3: Karta pacienta.
38 A. Uživatelské rozhraní existujícího POWERNIS/SSB klienta
Obrázek A.4: Výsledky vyšetření pacienta.
39 A. Uživatelské rozhraní existujícího POWERNIS/SSB klienta
Obrázek A.5: Denní dekurz hospitalizovaného pacienta.
40 B Uživatelské rozhraní nového webového POWERNIS/SSB klienta
Obrázek B.1: Osobní údaje pacienta.
41 B. Uživatelské rozhraní nového webového POWERNIS/SSB klienta
Obrázek B.2: Anamnézy pacienta.
42 B. Uživatelské rozhraní nového webového POWERNIS/SSB klienta
Obrázek B.3: Karta pacienta.
43 B. Uživatelské rozhraní nového webového POWERNIS/SSB klienta
Obrázek B.4: Výsledky vyšetření pacienta.
44 B. Uživatelské rozhraní nového webového POWERNIS/SSB klienta
Obrázek B.5: Denní dekurz hospitalizovaného pacienta.
45