Univerzita Karlova v Praze Matematicko-fyzikální fakulta BAKALÁŘSKÁ PRÁCE
Jakub Húska
Univerzálne prepojenie elektronických zdravotných záznamov a formalizovaných elektronických lekárskych odporúčaní Katedra softwarového inženýrství
Vedoucí bakalářské práce: Mgr. Miroslav Nagy Studijní program: Informatika, Programování
2009 Na tomto mieste by som chcel poďakovať svojmu otcovi za podporu počas štúdia, pánovi Mgr. Miroslavovi Nagyovi za vedenie mojej práce, cenné rady pri písaní dokumentácie a poskytnutie potrebnej literatúry.
Vyhlasujem, že som svoju bakalársku prácu napísal samostatne a výhradne s použitím citovaných zdrojov. Súhlasím so zapožičiavaním práce a jej zverejňovaním.
V Prahe dňa Jakub Húska
2 Obsah
1 Úvod 6 1.1 Ciele práce ...... 6 1.2 Electronic Health Record ...... 7 1.2.1 AdamekJ ...... 7 1.3 GuideLine Interchange Format - GLIF ...... 8 1.3.1 Implementácia GLIF modelu ...... 9 1.3.2 GLIF Expression Language ...... 10
2 Analýza 11 2.1 CORBA - Common Object Requesting Broker Architecture ...... 11 2.2 Webové služby ...... 12 2.2.1 Funkčné zložky webovej služby ...... 12 2.2.2 SOAP ...... 13 2.2.3 WSDL ...... 15 2.3 Apache Axis ...... 16 2.4 Zdôvodnenie výberu ...... 16
3 Implementácia 18 3.1 EHR2GLBridge ...... 18 3.2 EHRClient ...... 22 3.3 MGLSServer ...... 23 3.4 Lekárske číselníky ...... 24
4 Programátorská dokumentácia 27 4.1 Organizácia systému ...... 27 4.2 EHRClient ...... 27 4.2.1 Technológia JAXB ...... 28 4.2.2 Metóda getPatientList() ...... 29
3 4.2.3 Metóda getPatientData() ...... 29 4.3 EHR2GLBridge ...... 30 4.3.1 Java Servlety ...... 30 4.3.2 Java RMI a webové služby ...... 31 4.3.3 BridgeServlet ...... 31 4.4 MGLSServer ...... 32 4.4.1 Metóda putFullParaModel() ...... 32 4.4.2 Metóda getPatientData() ...... 33
5 Inštalácia a spúšťanie 37 5.1 Požiadavky ...... 37 5.2 Konfigurácia podprojektov ...... 38 5.3 Spustenie podprojektov ...... 39
6 Záver 40
Referencie 42
A Obsah priloženého CD-ROM 45
B Nastavenie HTTPS 46
4 Názov práce: Univerzálne prepojenie elektronických zdravotných zázna- mov a formalizovaných elektronických lekárskych odporúčaní Autor: Jakub Húska Katedra (ústav): Katedra softwarového inženýrství Vedúci bakalárskej práce: Mgr. Miroslav Nagy E-mail vedúceho: [email protected]
Abstrakt: Cieľom bakalárskej práce je navrhnúť a implementovať premoste- nie medzi elektronickým zdravotným záznamom MUDRLite2 v implementá- cii AdamekJ a lekárskymi odporúčaniami formalizovanými v systéme „Me- dical Guidelines SYSTEMÿ[1]. Riešenie by malo byť navrhnuté univerzálne s ohľadom na možnosť pripojenia rôznych implementácií elektronických zázna- mov a rôznych systémov lekárskych odporúčaní založených na GLIF mode- loch. Súčasťou práce by mala byť analýza problematiky a popis navrhnutého riešenia. Kľúčové slová: Univerzálne prepojenie EHR a lekárskych Guidelines
Title: Universal interconnection of Electronic Health Record and Formali- zed Electronic Medical Guidelines Author: Jakub Húska Department: Department of Software Engineering Supervisor: Mgr. Miroslav Nagy Supervisor’s e-mail address: [email protected]
Abstract: The purpose of this thesis is to design a universal bridge between any Electronic Health Record (EHR) and formalized medical guidelines inc- luded in evaluation and presentation system. The interconnection should ensure medical data for medical guidelines that are evaluated. These data should be acquired from EHR using standard techniques, if possible. To solve the thesis there are some systems ready to be used: the medical guidelines evaluating and presenting system named „Medical Guidelines SYSTEMÿ[1] and an EHR named AdamekJ based on the MUDRLite2 technology. The solution should be designed in a modular way in order to connect various EHRs and medical guidelines systems. The programming language and ot- her supportive technologies necessary for completing the task can be chosen by a student. Keywords: Universal interconnection of EHR and Medical Guidelines
5 Kapitola 1
Úvod
Postupným informatizovaním spoločnosti dochádza k informatizácii nemoc- níc, dát pacientov a lekárskych postupov. Vzniká mnoho organizácií zaobe- rajúcich sa vytváraním štandardov ukladania pacientových dát a popisov postupov liečenia. V roku 1990 vznikajú v Čechách a na Slovensku prvé ústavy lekárskej informatiky vybavené v tej dobe špičkovými počítačmi PC AT286. Zaobe- rajú sa primárne metodológiou riešení odborných problémov, spracovaním lekárskych informácií, metódami získavania údajov, formalizáciou lekárskych problémov a klinickými informačnými systémami. V roku 1994 vzniká centrum EuroMISE ako spoločné pracovisko Uni- verzity Karlovej a Akadémie vied Českej republiky, ktoré vytvorilo systém elektronických záznamov AdamekJ podporujúci štandard HL7 (Health Level Seven)[2].
1.1 Ciele práce
Cieľom práce je navrhnúť univerzálne prepojenie elektronického zdravotného záznamu pacienta a systému lekárskych odporúčaní (v ďalšom texte nazý- vaným aj prehliadač odporúčaní). Ako implementácia ukladania paciento- vých dát - EHR (Electronic Health Record) je použitý systém AdamekJ[4] s dátovou schémou uvedenou v prílohách, alebo na priloženom CD v zložke doc. Prehliadačom odporúčaní bude stránka EuroMISE guidelines[1]. Aby sa podarilo dosiahnuť univerzálnosť, prepojenie musí byť schopné fungovať s rôznymi implementáciami ukladania EHR záznamov ako aj s rôznymi im- plementáciami prehliadačov lekárskych odporúčaní. Vytvorený projekt by
6 mal byť multiplatformný, čoho sa dosiahne použitím programovacieho ja- zyka Java[30].
1.2 Electronic Health Record
EHR[14] systém je digitálny systém, v ktorom sú uložené lekárske dáta pa- cienta. Elektronická zdravotná dokumentácia obsahuje informácie súvisiace s fyzickým či duševným zdravím pacientov, ale aj informácie vzťahujúce sa k poskytovaniu zdravotnej starostlivosti zo strany zdravotníkov alebo zdra- votníckych zariadení. Samotná skratka EHR označuje všetky dostupné le- kárske záznamy týkajúce sa jednotlivca. Prínosy z elektronického ukladania dát pre pacientov: • Zvýšenie kvality zdravotnej starostlivosti • Prehľad o poskytnutých zdravotníckych službách a príslušných nákla- doch • Skrátenie času administratívnych úkonov • Zmena postavenia pacienta v systéme zdravotnej starostlivosti • Možnosť komunikovať aj elektronickou cestou so systémom poskyto- vania zdravotnej starostlivosti • Zvýšenie ochrany pacienta pri poskytovaní zdravotnej starostlivosti • Ľahko dostupné podklady pre rozhodovanie o svojom zdravotnom stave, výbere poskytovateľa zdravotnej starostlivosti, liekovej preferencii Elektronické ukladanie dát pacientov prinesie zdravotníctvu zvýšenie efekti- vity využitia prostriedkov (znížením duplicít vo vyšetreniach), zníženie ná- kladov na administratívne činnosti, zvýšenie úrovne cielenej prevencie ocho- rení a dôjde k zníženiu korupčného správania.
1.2.1 AdamekJ Aplikácia AdamekJ[4] je pilotnou implementáciou technológie MUDRLite2, ktorá bola vytvorená pre zber dát v oblasti kardiológie a genetiky. Skratka AdamekJ znamená ”Aplikace Datového Modelu EuroMISE-Kardio” naprog- ramovaná v Jave. Aplikácia AdamekJ je založená na dvojvrstvej architektúre
7 - užívateľská a dátová vrstva. Užívateľská vrstva je multiplatformná a jed- noducho ovládateľná. Dátová vrstva je realizovaná na databázovom serveri Oracle 10g. V reálnom nasadení AdamekJ obsahuje databázu s vyše 1000 pacientmi. Na získaných dátach sa robia rôzne analýzy, napríklad výpočet celkového rizika kardiovaskulárnych chorôb v Českom obyvateľstve. Pre účely testovania tejto práce bola vytvorená nová databáza, v ktorej bolo vytvorených niekoľko fiktívnych pacientov s vymyslenými dátami.
1.3 GuideLine Interchange Format - GLIF
GLIF[15] je metodológia podporujúca modelovanie a reprezentáciu klinic- kých odporúčaní v štruktúrovanom formáte. Hlavnou úlohou GLIF je umož- niť zdieľanie odporúčaní medzi organizáciami a medzi počítačovými apliká- ciami[21]. GLIF model je výsledkom spolupráce Univerzity Columbia, Har- vardskej, McGillovej a Stanfordskej Univerzity. GLIF formát bol navrhnutý na použitie v mnoho typoch odporúčaní. Odporúčania môžu byť rozdelené podľa klinickej oblasti, stupňa poruchy zdravia alebo podľa spôsobu liečenia[23]. Vo formáte GLIF sú odporúčania reprezentované ako vývojové diagramy zložené z usporiadaných vrcholov na- zývaných kroky. V odporúčaniach existuje päť typov krokov[23][24]:
Rozhodovací krok predstavuje vetvenie (výber) na základe splnenia lo- gického kritéria. Ďalší postup grafom je daný výsledkom logického vý- razu nad konkrétnymi dátami alebo rozhodnutím užívateľa, kedy ak- cia reprezentovaná následným krokom môže, ale nemusí byť vykonaná, alebo môže prebiehať paralelne s inými akciami. Užívateľ má v tomto mieste možnosť rozhodnúť, ktorou časťou grafu sa bude ďalej pokra- čovať.
Akčný krok definuje špecifickú činnosť, alebo udalosť. Akciou môže byť aj podgraf, ktorý ďalej zjemňuje danú činnosť. Existujú dva typy akčných krokov: lekársky-zameraný krok (napríklad odporúčanie určitého typu liečby) a programovo-zameraný krok (napr. získanie dát z EHR).
Krok vetvenia sa používa pri modelovaní nezávislých krokov, ktoré môžu prebiehať paralélne.
Krok synchronizácie slúži ako zlučovací bod pre kroky vetvenia.
8 Stav značí stav, v ktorom sa skúmaný objekt nachádza pri vstupe do mo- delu alebo po vykonaní niektorého predchádzajúceho kroku. Priechod jednotlivými vetvami GLIF modelu je závislý na splnení alebo ne- splnení podmienok v rozhodovacích krokoch, alebo na interaktívnom výbere príslušnej vetvy grafu užívateľom. Každá vetva, ktorou sa výpočet môže vydať môže mať štyri pravidlá: strict out Ak je splnená podmienka, tak sa príslušnou vetvou nebude po- kračovať - táto vetva je zakázaná strict in Ak je splnená podmienka, určite sa bude pokračovať príslušnou vetvou rule out Pri splnení podmienky je doporučené pokračovať nasledujúcou vetvou rule in Pri splnení podmienky nie je doporučené pokračovať nasledujúcou vetvou Pri výbere nasledujúcej vetvy sa najprv vyhodnotí podmienka strict-out a pri jej splnení sa už ďalšie podmienky nevyhodnocujú. Ak nie je splnená, vyhodnotí sa podmienka typu strict-in, ktorá keď je splnená pokračuje sa ňou určenou vetvou. V prípade, že nie je splnená ani jedna podmienka strict-in je vyžadovaný zásah užívateľa, ktorému je na základe vyhodnotenia pod- mienok rule-in a rule-out doporučený, alebo nedoporučený výber príslušnej vetve. Pri rozhodovaní, či bude výpočet pokračovať danou vetvou sa berie do úvahy prvá z podmienok, ktorá je splnená. Ostatné podmienky sa nevy- hodnocujú. Odporúčania vo formáte GLIF sú modelované v troch vrstvách abstrak- cie. Prvá vrstva nazývaná ”konceptuálna” vznikne, keď je odporúčanie vy- tvárané. V tejto vrstve sa pre odporúčanie vytvára vývojový diagram. V dru- hej vrstve ”výpočetnej” autor špecifikuje, ktoré dáta sú dôležité pre jednot- livé kroky aby bola špecifikácia spočítateľná. Tretou úrovňou je ”implemen- tácia”, kedy sú akcie a referencie na pacientove dáta mapované na základné procedúry a záznamy EHR.
1.3.1 Implementácia GLIF modelu Aby bolo možné počítačové spracovanie vývojového diagramu odporúčania, musel sa GLIF model zakódovať. Bol použitý formát XML, ktorý je pre- hľadným a rozšíreným spôsobom uloženia dát v počítačových systémoch.
9 GLIF model sa skladá z jednotlivých krokov reprezentujúcich príslušné prvky modelu. Pre zápis rozhodovacích pravidiel a synchronizačných pod- mienok bol použitý jazyk XPath[3].
1.3.2 GLIF Expression Language GLIF Expression Language (GELLO)[25] je jazyk, pomocou ktorého sa za- pisujú výrazy vo formáte GLIF. Nie je súčasťou GLIF ale je vyvíjaný v sú- činnosti s HL7[2]. GELLO je objektovo orientovaný jazyk vytvorený z existujúcich štan- dardov. Je založený na Object Constraint Language (OCL)[5] vyvíjaným organizáciou Object Management Group. GELLO môže byť použité na:
• Vytvorenie dotazov na výber a manipuláciu dát z EHR.
• Konštrukciu rozhodovacích kritérií vytvorením výrazov hodnotiacich určité dáta. Tieto kritéria potom možno použiť na vytvorenie varovaní, upomienok alebo iných rozhodovacích pravidiel.
• Vytvorenie výrazov, formulí a dotazov pre iné potreby.
Jednoduchý dotaz v GELLO vyzerá napríklad[25]:
Let hypotensive_agents : CodedValue = CodedValue.new("SNOMED-CT", "1182007") MedicationOrder->select( code.subclassOf(hypotensive_agents) and effectiveTime.high = null )->size() > 1
10 Kapitola 2
Analýza
Pri univerzálnom prepájaní dvoch nezávislých systémov je nutné použiť obecne definovaný štandard. V tejto kapitole popíšem jednotlivé používané architektúry, popíšem ich výhody a nevýhody a zdôvodním výber jednej.
2.1 CORBA - Common Object Requesting Broker Architecture
V nedávnej minulosti bol veľmi obľúbeným štandardom, ktorý vytvorilo Konzorcium OMG(Object Management Group)[6]. Je to architektúra dovoľujúca spojenie rôznych softwarových komponent napísaných v rôznych programovacích jazykoch bežiacich na rôznych platfor- mách. Definuje rozhranie, ktorým komunikujú jednotlivé komponenty (ob- jekty). Používa protokol IIOP, ktorý je implementáciou abstraktného proto- kolu General Inter-ORB Protocol (GIOP) nad architektúrou TCP/IP. Pre každý podporovaný programovací jazyk má CORBA definované mapovanie ním používaných typov na typy používané rozhraním. Výhody architektúry CORBA zahrňujú nezávislosť na programovacom jazyku, nezávislosť na operačnom systéme, silnú typovú kontrolu, jednodu- chý a prepracovaný systém odchytenia výnimiek a kompresia predávaných dát do binárnej formy. Medzi nevýhody patrí ťažkopádna komunikácia objektov existujúcich v rovnakom adresovom priestore (v jednej aplikácii), pretože s nimi CORBA jedná ako so vzdialenými, nutnosť povolenia TPC/IP spojení na firewalle, aby si objekty mohli predávať binárne dáta a rôzne implementácie, ktoré ne-
11 splňujú všetky požiadavky špecifikácie - sú nekompletné, v horšom prípade implementácie, ktoré sú nekompatibilné.
2.2 Webové služby
V súčasnosti prechádzajú búrlivým rozvojom. Boli definované Konzorciom W3C[7] ako systémy dovoľujúce spolupracovanie rôznych počítačov cez sieť. Inými slovami sú technológia, ktorá umožňuje integrovať ľubovoľné apliká- cie bežiace na rôznych platformách a ovládať ich prostredníctvom webového rozhrania. Sú založené na klient-server architektúre. Snahou webových slu- žieb je dať užívateľom možnosť pristupovať k potrebným informáciám, a to kdekoľvek a kedykoľvek a naviac z ľubovoľného zariadenia - nielen z bežného osobného počítača, ale tiež z vreckového počítača alebo mobilného telefónu. A keďže sú medzi jednotlivými typmi zariadení veľké rozdiely, musia webové služby poskytovať univerzálne rozhranie medzi zdrojom dát a užívateľom.
2.2.1 Funkčné zložky webovej služby Implementácia webových služieb sa skladá z troch vzájomne prepojených častí:
Poskytovateľ služieb (Service Provider) je subjekt, ktorý je zodpovedný za prijatie žiadostí klienta a umožnenie spracovania žiadostí implemen- tácii danej služby. Poskytovateľ môže byť naprogramovaný v ľubovo- ľnom programovacom jazyku a môže bežať na ľubovoľnej platforme.
Register služieb (Service Registry) je miesto, na ktorom užívatelia môžu vyhľadávať poskytovateľov, a ktoré súčasne poskytuje informácie po- trebné pre vytvorenie komunikácie medzi klientom a poskytovateľom služieb.
Požadovateľ služby (Service Requestor) je ten, kto vyhľadáva požado- vanú službu. Z hľadiska architektúry sa jedná o aplikáciu, ktorá volá procedúru v registri služieb poskytovanú poskytovateľom, teda apliká- cia bežiaca vo webovom prehliadači ovládaná užívateľom.
Poskytovateľom služby môže byť napríklad aplikačný server Apache Tom- cat[13] s jadrom Apache AXIS[12]. Register služieb je realizovaný pomocou UDDI (Universal Description, Discovery, and Integration)[8], a klient môže
12 Obr. 2.1: Fungovanie webových služieb byť čokoľvek, napríklad JavaScript spustený kliknutím na tlačítko na we- bovej stránke. Idea spolupráce týchto troch častí je zobrazená na obrázku 2.1.
2.2.2 SOAP Simple Object Access Protocol[9] je protokol na výmenu štruktúrovaných informácií cez webové služby v počítačových sieťach. Je decentralizovaný a pracuje nad distribuovanými systémami. Distribuovaný systém je prog- ram alebo skupina programov, ktoré pre beh používajú viac než jeden výpo- čtový zdroj. Základom je technológia XML (Extensible Markup Language), ktorá sa používa na formátovanie správ posielaných počas komunikácie me- dzi uzlami. Protokol SOAP obsahuje tri základné časti:
13 Obálka (SOAP Envelope) definuje presne, čo sa v správe nachádza, kto by mal správu spracovať a deklaruje, ktoré časti správy sú povinné a ktoré voliteľné. Kódovanie (SOAP Encoding) špecifikuje dátový typ jednotlivých XML elementov v správe. Definuje jednoduché typy ako Integer, String, Enumeration a zložité typy ako napríklad XML element obsahujúci potomkov, alebo pole potomkov. Reprezentácia RPC (SOAP RPC representation) definuje konvencie ako reprezentovať volanie vzdialenej procedúry RPC (Remote Procedure Call) a ako reprezentovať dáta v odpovedi.
SOAP správa SOAP správa má vždy koreňový element Envelope, v ktorom je defino- vané namespace ”http://schemas.xmlsoap.org/soap/envelope”. Element En- velope obsahuje jeden nepovinný a jeden povinný element. Header je nepo- vinným elementom, obsahuje rozširujúce informácie o správe ako napríklad autentifikačné údaje. Povinným elementom je Body, ktorý obsahuje samotné telo správy. Všetci bezprostrední potomkovia elementu Body sa nazývajú po- ložky tela (body entry). Každá položka je kódovaná ako nezávislý element v tele. Položka tela musí byť identifikovaná plne kvalifikovaným menom, ktoré sa skladá z URI menného priestoru a vlastného mena a môže ob- sahovať atribút encodingStyle na označenie kódovania položiek tela. SOAP definuje jednu nepovinnú položku tela a tou je Fault, ktorá sa používa na po- pis chybných stavov. Jednoduchá správa použitá na volanie metódy getPatientList s dvoma parametrami objektu EHRClient vyzerá:
14 2.2.3 WSDL Web Service Description Language[10] je jazyk, ktorým popisujeme vlast- nosti webovej služby. WSDL podáva užívateľovi služby návod ako komu- nikovať s webovou službou. Je to XML dokument, v ktorom sú popísané typy správ a portov. Správy sú abstraktné deklarácie dát, ktoré sa posielajú a porty sú deklarácie dostupných akcií. WDSL popisuje verejné rozhranie, ktoré poskytuje daná webová služba. WSDL nepopisuje naviazanie služby na nejaký konkrétny programovací jazyk, ale popisuje službu nezávisle na po- užitom programovacom jazyku a platforme. Samotný dokument sa skladá z definícií:
Typov - XML schéma[34] definície dátových typov použitých v správach
Správ - definuje správy, ktoré si vymieňa webová služba s klientom
Portov - popisujú rozhranie webovej služby. Každý port obsahuje niekoľko abstraktných operácií, ktoré služba vykonáva a zoznam správ, ktoré sú prijímané a odosielané v rámci týchto operácií.
Naviazaní (Bindings) – priradí každý port a jeho operácie konkrétnemu transportnému protokolu nižšej vrstvy
Služieb – používa sa na priradenie sieťovej adresy naviazaniu. Týmto sa vytvorí webová služba.
Výhody a nevýhody webových služieb Multiplatformnosť, nezávislosť na použitom programovacom jazyku, glo- bálna dostupnosť, schopnosť bežať na protokole HTTP, ktorá povoľuje ko- munikáciu cez proxy a firewally, obecnosť a jednoduchosť vyplývajúca z po- užitia XML ako formátu pre správy. Obmedzenia technológie webových služieb môžeme rozdeliť podľa použi- tého štandardu na obmedzenia týkajúce sa WSDL a UDDI[11]. Medzi obme- dzenia WSDL patrí chýbajúce oddelenie privátnej a verejnej časti rozhrania služby, chýba podpora transakcií a nerieši otázky zabezpečenia. Medzi obme- dzenia UDDI špecifikácie patrí centralizovaný prístup, ktorý nereflektuje dis- tribuované prostredie internetu a ktorý podlieha všetkým problémom, ktoré má akákoľvek centralizovaná správa (výpadok pri poruche, odstavenia, ...), neistá dôveryhodnosť centrálneho registru a vyhľadanej služby a nemožnosť
15 automatického vyhľadávania, vyhodnocovania relevancie a kvality poskyto- vaných služieb softwarovými agentmi. I cez tieto problémy je technológia webových služieb pomerne obľúbená a využívaná.
2.3 Apache Axis
Apache Extensible Interaction System[12] je open-source framework pre we- bové služby, ktorý obsahuje Java a C++ implementáciu SOAP serveru. Zá- kladom Axisu je samostatný SOAP server, ktorý sa nainštaluje do Java apli- kačného serveru. Axis podporuje WSDL ako spôsob definície verejných me- tód webovej služby. Umožňuje generovať programový kód parsujúci SOAP správy do užívateľom definovaných typov a tiež generovanie WSDL definícií z existujúceho kódu. Na rozšírenie flexibility existuje formát WSDD (Web Service Deploy- ment Descriptor)[12]. Je to XML súbor, v ktorom sú definované parametre a menné priestory používané webovou službou. Umožňuje definovať singleton (objekt, ku ktorému existuje len jediná inštancia), alebo objekty, pre ktoré bude existovať práve jedna inštancia pre jednu session. Axis podporuje dva typy zverejnenia webových služieb. Prvý je pomo- cou zdrojových kódov v súboroch jws, ktoré sa skopírujú do zložky webapps v domovskom adresári Axisu. Druhým spôsobom je vytvorenie war, alebo aar (Axis Archive) archívu, ktorý neobsahuje zdrojové kódy, ale class sú- bory (teda medizkód). Vytvorený archív sa skopíruje do zložky webapps Axisu a Axis ho načíta pri štarte aplikačného serveru.
2.4 Zdôvodnenie výberu
Po zvážení výhod a nevýhod sa rozhodlo pre implementáciu pomocou webo- vých služieb, kvôli jednoduchosti a tiež vzhľadom k tomu, že formát GLIF je interpretovaný ako XML súbory. Problém bezpečnosti sa dá obísť jednoducho - použitím protokolu HTTPS namiesto HTTP. Potencionálny útočník uvidí len zašifrovanú komunikáciu. Jedine že by použil útok typu Man in the Middle a dokázal predstierať, že on je server obsahujúci záznamy pacienta, ale na to by potreboval plný prístup ku klientskej aplikácii, alebo plný prístup k serveru, aby si mohol pre- smerovať celú ich komunikáciu k sebe. Podpora transakcií nie je potrebná,
16 vzhľadom k tomu, že aplikácia nemení dáta pacienta, len s nimi pracuje a UDDI ako centralizovaný vyhľadávač sa vôbec nepoužije, pretože by to len mohlo narušiť bezpečnosť a mohlo by dôjsť k úniku citlivých dát. K odmietnutiu štandardu CORBA prispela potreba zobraziť získané dáta v internetovom prehliadači pomocou JavaScriptu, ktorý má postačujúcu podporu XML súborov, ale nemá dostatočnú podporu CORBA.
17 Kapitola 3
Implementácia
Pre dosiahnutie univerzálnosti sa projekt musel rozdeliť na tri podprojekty. Jeden obecný a dva implementačne závislé, ktorých funkcia je mapovať obecné dáta na dáta danej aplikácie (čiernej skrinky). Obecný projekt je nazvaný EHR2GLBridge, projekt EHRClient je napojený na databázu pa- cientových záznamov a MGLSServer slúži ako cache pacientových dát, kým si ich vyzdvihne webová stránka „Medical Guidelinesÿ[1]. Schéma je na ob- rázku 3.1. Prepojenie projektov je implementované volaním metód webových slu- žieb.
3.1 EHR2GLBridge
Univerzálny projekt prepojuje záznamy pacienta a lekárske odporúčania. Univerzálnosť sa dosiahla oddelením implementačne závislej časti pracujú- cej s pacientovými dátami a implementačne závislej časti zobrazujúcej lekár- ske odporúčania. Pre zjednodušenie v nasledujúcom texte budeme pre tento projekt používať názov Bridge, prípadne Most. Bridge je schopný prepá- jať akúkoľvek implementáciu EHR záznamov na akúkoľvek implementáciu lekárskych odporúčaní. Teda ak máme 3 rôzne implementácie EHR a dva rôzne prehliadače odporúčaní Bridge je schopný zobraziť dáta pacienta z ho- ciktorého EHR na hociktorom prehliadači. Ako jediný z podprojektov má užívateľské rozhranie v podobe Java servletu[26] - webovej stránky. Pracuje na protokole HTTPS a musí byť spustený v nejakom Java aplikačnom ser- veri, napríklad Apache Tomcat 6.0.[13]. Po prihlásení do servletu sa užívateľovi zobrazí jednoduchá stránka vý-
18 Obr. 3.1: Schéma fungovania naprogramovanej aplikácie 19 beru, presne ako na obrázku 3.2. Na formátovanie stránky sa používajú CSS[29] štýly.
Obr. 3.2: Užívateľské rozhranie Bridge
Užívateľ zvolí MGLS viewer - teda prehliadač odporúčaní, v ktorom si chce nechať zobraziť dáta daného pacienta, vyberie odporúčanie, ktoré si chce pre pacienta zobraziť v danom prehliadači. Potom zvolí EHR server - aplikáciu, ktorá pracuje s dátami pacientov. Zobrazí sa mu zoznam pacientov pre daný EHR, alebo len prázdny zoznam s jedinou možnosťou ”vyberte”. V prípade prázdneho zoznamu užívateľ musí kliknúť na obrázok obnovenia, ktorý je vľavo od comboboxu výberu pacienta. Keď užívateľ klikne na ob- rázok Bridge sa pripojí na EHRClienta a vyžiada si od neho zoznam pa- cientov, s ktorými má daný užívateľ právo pracovať v danom EHR. Pokiaľ sa nepodarí pripojenie, alebo EHRClient vráti prázdny zoznam, užívate- ľovi sa zobrazí pomocou JavaScriptu správa o chybe. Ak EHRClient vráti príliš dlhý zoznam pacientov (viac ako 40), zobrazí sa užívateľovi abeceda
20 nad comboboxom výberu pacienta, kde si klikne na písmeno, akým začína priezvisko pacienta a Bridge mu zobrazí výber len pacientov, ktorých meno začína na dané písmeno. Pokiaľ majú pacienti rovnaké meno, zobrazí bridge ich dátum narodenia, aby užívateľ vedel vybrať presne daného pacienta, kto- rého chce. Aby fungovalo obnovenie zoznamu pacientov z EHR, musí mať užívateľ nastavené užívateľské meno a heslo do EHR. Môže si to nastaviť sám, alebo mu ho nastaví administrátor v druhom servlete nazvanom BridgeAdmin. K servletu BridgeAdmin sa užívateľ dostane kliknutím na tlačítko ”Ad- ministrační panel”. Zobrazí sa mu výber EHRServeru a možnosť zadať nové užívateľské meno a heslo. Súčasný login a heslo sa nezobrazí z bezpečnost- ných dôvodov. Bridge servlet pracuje so štyrmi typmi užívateľských privilégií:
Zakázaný účet (PRIVILEGES BANNED) pre zakázané účty, na ktoré servlet nepovolí prístup.
Užívateľ (PRIVILEGES USER) - normálny užívateľský účet, ktorý si môže meniť prihlasovacie údaje do EHR.
Administrátor (PRIVILEGES ADMIN) - môže meniť údaje užívateľov: login k servletu, heslo, meno, priezvisko, užívateľské loginy k EHR a môže zakázať užívateľský účet. Nevidí účty ostatných administrátorov.
Globálny administrátor (PRIVILEGES GLOBAL ADMIN) - vidí všetkých užívateľov (aj ostaných globálnych administrátorov) môže všetko čo ad- ministrátor plus môže mazať užívateľské účty. Môže upravovať (pridá- vať a editovať) databázu EHR Serverov a Guideline Viewerov (pre- hliadačov odporúčaní).
Databázová schéma projektu Bridge je zobrazená na obrázku 3.3. Pre každého užívateľa si Bridge pamätá posledne vybrané hodnoty na for- mulári, pretože objekt session je zničený pri odlogovaní. Každý užívateľ má svoj vlastný login pre každý EHR server - uložený v tabuľke user EHR login a každý prehliadač odporúčaní (Guideline Viewer) má svoje vlastné odpo- rúčania, ktoré je schopné zobraziť v tabuľke guidelines. Skript vytvárajúci databázu Bridge je uložený na priloženom CD v zložke bin/scripts/database. Bola snaha urobiť užívateľské rozhranie, čo najjed- noduchšie ovládateľné, aby aj počítačovo neskúsený užívateľ zvládol prácu s Bridge.
21 Obr. 3.3: Databázové schéma Bridge
3.2 EHRClient
Je klient poskytujúci projektu Bridge pacientove údaje. Presnejšie Bridge pošle EHRClientovi XML súbor, ktorý nazývame prázdny Parametrický Mo- del (alebo ParaModel), v ktorom je presne uvedené, aké dáta sú dôležité pre dané lekárske odporúčanie. Pracuje nad čiernou skrinkou - aplikáciou spracúvajúcou pacientove dáta. Je to program AdamekJ vyvinutý v centre EuroMISE (Evropské centrum pro medicínskou informatiku, statistiku a epidemiologii) v roku 2006. Pou- žíva databázový server Oracle a dátovú schému AdamekJ popísanú v úvode. Súčasná implementácia EHRClienta pracuje priamo s databázovou vrstvou a nespolupracuje s programom AdamekJ, len mu číta pacientove dáta z da- tabáze. Nebol by ale problém napísať klienta, ktorý by posielal dotazy rovno aplikačnej vrstve programu spravujúceho EHR záznamy. EHRClient používa dva konfiguračné súbory. Jeden, v ktorom sú špeci- fikované informácie ohľadom pripojenia do databáze a v druhom je defino- vané mapovanie názvov hodnôt použitých v prázdnom ParaModeli na SQL
22 dotazy do databáze. EHRClient poskytuje dve verejné metódy Patient[] getPatientList() a ParaModel getPatientData(). Metóda getPatientList vracia zoznam mien, priezvisk a dátumov na- rodení pacientov prístupných pre užívateľa, ktorého prihlasovacie údaje do- stane na vstupe. Je odolná voči hackerskému útoku SQL injection, kedy útočník podstrčí serveru schovaný SQL kód ako parameter. Zložitejšie funguje metóda getPatientData, ktorá napĺňa prázdny Para- Model. Postupne prechádza prázdny ParaModel a všetky parametre uvedené v ňom. Ak má pre daný parameter deklarované mapovanie na SQL dotaz, tak daný dotaz spustí a výsledok zapíše do vytváraného ”plného”ParaModelu. Parametre, ktoré nerozpozná, len zaradí s prázdnou hodnotou do plneného ParaModelu. Plný ParaModel pošle späť Bridgu, ktorý ho len pošle ďalej MGLSServeru ako je znázornené na obrázku 3.4.
3.3 MGLSServer
Pracuje nad čiernou skrinkou - webovou stránkou EuroMISE Guidelines[1]. Je to php skript zobrazujúci zobrazujúci GLIF graf. Pôvodná stránka nebola v dobrom stave. Nepoužívala Session, všetko mala ako globálne premenné a používala kódovanie Latin2 a databázu v kódovaní UTF-8 s textami ulo- ženými v Latin2. Bolo treba doprogramovať podporu Sessions a zmeniť kó- dovanie celej stránky na UTF-8. Z bezpečnostných dôvodov bola stránka presmerovaná na HTTPS. Stránka funguje systémom, že sa lekár (užívateľ) prihlási, vyberie typ odporúčania, vyberie existujúceho alebo pridá nového pacienta, vyplní všetky jeho dáta a klikne na tlačítko Odoslať. Stránka mu zobrazí odporúčaný prechod grafom formalizovaného lekárskeho odporúča- nia na základe zadaných dát. Prepojenie MGLSServeru a stránky odporúčaní je pomocou JavaScriptu, ktorý sa volá ako obsluha kliknutia na tlačítko ”Načíst data”. JavaScript do- stane XML súbor typu AlteredParaModel (popísané neskôr) a nastaví pa- cientove dáta na stránke aby ich nemusel vyplňovať lekár. MGLSServer slúži ako cache dát pre stránku zobrazujúcu odporúčania. Vždy keď užívateľ Bridgu klikne na tlačítko ”Získat data a přesměrovat na stránku Guidelines”, Bridge pošle prázdny ParaModel EHRClientovi, ktorý ho naplní a vráti Bridgu a ten ho pošle ďalej MGLSServeru, ktorý ho spracuje a uloží do databáze. Sekvenčný diagram UML, ktorý popisuje postupnosť volaní metód pri získavaní dát pacienta, keď si užívateľ nechá zobraziť odporúčanie pre pa-
23 cienta je znázornený na obrázku 3.4.
Obr. 3.4: diagram znázorňujúci postupnosť volaní metód webových služieb
Databáza MGLSServeru obsahuje len 2 tabuľky. Tabuľku ParaModels, kde si ukladá spracované AlteredParaModely a tabuľku ParaModelPIDto- MGLSValuesMap, v ktorej má definované mapovanie hodnôt v plnom Para- Modeli na AlteredParaModel. AlteredParaModel (nazývaný aj upravený ParaModel) je XML sú- bor, ktorý obsahuje názvy ovládacích prvkov vyskytujúcich sa na stránke odporúčaní a im priradené hodnoty. V konfiguračnom súbore Paramodel- PidToMGLSControlBinding.ini má MGLSServer definované mapovanie náz- vov jednotlivých dát v plnom ParaModeli na názvy a typ ovládacích prvkov na stránke odporúčaní. Pre potrebu testovania bolo vytvorené jedno príkla- dové mapovanie - číselník. Formát súboru AlteredParamodel bol vytvorený len pre potreby zobra- zovania dát na webovej stránke prehliadača odporúčaní a v prípade použitia inej implementácie zobrazovača odporúčaní nemusí byť použitý.
3.4 Lekárske číselníky
Funkciou číselníkov je mapovať všetky lekárske termíny na kódy. Z hľadiska informatického sú to dátové súbory, obsahujúce základné definície a popisy termínov a procedúr používaných v zdravotníctve. Existujú kvôli štandardi- zácii a normalizácii práce s pacientom a jednotnému spracovaniu paciento- vých dát. Pôvodne začali vznikať v laboratóriách, kde bola potreba rovnako
24 pomenovávať objekty a procedúry, neskôr vznikla potreba si dané výsledky predávať a to dalo podnet k štandardizácii. Elektronická správa zdravotných záznamov ponúka nasledujúce výhody: zníženie nákladov na archiváciu, do- sažiteľnosť, okamžitú predateľnosť a čitateľnosť.
Narodní číselník laboratorních položek NČLP[16] bol zavedený do praxe Ministerstvom zdravotníctva ČR v roku 1997. Vznikol zo štandardu, ktorý používajú medzinárodné inštitúcie IUPAC (International Union of Pure and Applied Chemistry) a IFCC (International Federation of Clinical Chemistry and Laboratory Medicine). Každá labora- tórna položka je definovaná pomocou piatich charakteristík:
• systému - predmetu laboratórneho vyšetrenia
• komponenty - definovateľnej časti systému
• procedúry - laboratórny vyšetrovací postup, slúžiaci k získavaniu vlast- ností komponent
• druhu veličiny - je vlastnosť komponenty (predmetu), ktorá môže byť kvalitatívne odlíšená a kvantitatívne určená
• jednotky - veličina, používaná pre kvantitatívne porovnávanie veličín rovnakého druhu.
Takto definovanej položke je priradený jednoznačný číselný kľúč, ktorý sa používa na indexovanie. Názov laboratórnej položky NČLP je konštruovaný z jednotlivých elementov - názvu komponenty, skráteného názvu systému, skráteného názvu druhu veličiny, jednotky a procedúry. Používa sa najmä v laboratóriách v ČR.
SNOMED CT SNOMED CT (Systematized Nomenclature of Medicine - Clinical Terms)[17] je systematicky organizovaná, počítačom spracovateľná kolekcia lekárskych pojmov. Je považovaný za najkomplexnejšiu mnohojazyčnú terminológiu na svete. Používa sa v 40 krajinách sveta. Zaoberá sa zlepšením starost- livosti o pacientov vývojom systémov spresňujúcich zdravotné záznamy. Pa- cienti profitujú z používania SNOMED hlavne pri výmene zdravotných dát
25 medzi zdravotníckymi zariadeniami. Používaním štandardizovanej termino- lógie sa dá predísť mnoho úmrtiam a zraneniam. SNOMED je zložený z komponentov:
Koncepty sú základná jednotka vytvorená z jedinečného číselného kódu, plne kvalifikovaného mena a popisu
Popisy sú termíny a synonymá priradené konceptu
Hierarchie sú zaradením konceptu do jednej z dvadsiatich hierarchií, pri- čom každá hierarchia má svoje podhierarchie
Vzťahy spojenia konceptov vnútri hierarchie, alebo medzi rôznymi hierar- chiami
Napríklad definícia srdcového infarktu v angličtine vyzerá:
Fully Specified Name: Myocardial infarction (disorder), DescriptionID 751689013 Preferred term: Myocardial infarction, DescriptionID 37436014 Synonym: Cardiac infarction, DescriptionID 37442013 Synonym: Heart attack, DescriptionID 37443015 Synonym: Infarction of heart, DescriptionID 37441018
V Českej republike žiadna jednotná terminológia v zdravotníctve nie je zave- dená. Dokonca zatiaľ nie je jednoznačne definovaná potreba a dôvody k za- vedeniu takejto terminológie[18].
26 Kapitola 4
Programátorská dokumentácia
4.1 Organizácia systému
Ako už bolo napísané, systém je rozdelený na jeden projekt webovej stránky a dva implementačne závislé projekty. Podprojekty medzi sebou komuni- kujú použitím protokolu SOAP - posielaním SOAP správ. Každý projekt má vlastnú databázu, do ktorej sa pripája použitím knižnice implementu- júcej JDBC (Java Database Connectivity)[31]. Konfigurácia podprojektov bude popísaná v nasledujúcej kapitole. Ako vývojové prostredie bolo použité Eclipse Platform (www.eclipse.org) s pluginmi http://ws.apache.org/axis2/tools/index.html. Plugin Service Ar- chive Wizard bol použitý na generovanie výstupných aar archívov obsahu- júcich medzikód pre JVM (Java Virtual Machine). Systém môže prepájať EHR záznamy a prehliadač na localhoste, alebo kdekoľvek inde v internete.
4.2 EHRClient
Je to projekt webovej služby, ktorej primárnou úlohou je napĺňať prázdne ParaModel XML súbory. Napĺňanie prebieha z databáze Oracle s dátovou schémou AdamekJ. Hlavná trieda EHRClientSkeleton implementuje roz- hranie EHRClientSkeletonInterface, v ktorom sú definované dve verejné metódy. Stačí aby aplikácia implementovala pomocou webových služieb tieto dve metódy a môže fungovať ako náhrada súčasnej implementácie EHR- Clienta.
27 Za načítanie konfiguračného súboru a načítanie mapovania identifikáto- rov dát v ParaModeli na SQL dotazy je zodpovedná trieda EHRClientConfig. Konfigurácia je definovaná XML súborom so schémou EHRClientConfig.xsd. Pre mapovanie identifikátorov bola použitá trieda java.util.Properties, ktorá je potomkom Hash mapy, pri porovnávaní kľúčov rozlišuje malé a veľké písmená a poskytuje metódu load(InputStream inStream), ktorá načíta mapovanie zo streamu. O spúšťanie dotazov a pripojenie do databáze sa stará trieda SQLClient. Má tri verejné metódy - Connect(), getResultSet() a GetReturnValue(). GetReturnValue() vracia reťazec, ktorý sa vyplní ako hodnota daného iden- tifikátoru pri napĺňaní ParaModelu. Trieda EHRClientMessageReceiverInOut spracúva príchodzie SOAP sp- rávy a volá požadované metódy, ktorým predá parametre načítané zo správy. GetPatientData je trieda reprezentujúca dotaz na pacientove dáta. Má vo vlastných premenných uložené parametre pre metódu getPatientData(). Trieda GetPatientDataResponse slúži ako návratová hodnota a je to trieda obaľujúca odpoveď na dotaz pacientových dát. V balíku tried EHRClient.ParaModel sú triedy použité na načítanie Pa- raModel XML do JAXB Kontextu. Tento balík bol generovaný pluginom https://jaxb.dev.java.net/plugin.html.
4.2.1 Technológia JAXB Java Architecture for XML Binding (JAXB)[19] umožňuje mapovanie XML dokumentov založených na XML schéme na Java objekty. Zvyčajný postup práce s JAXB spočíva v nasledovných krokoch:
1. Vytvorenie XML schémy a príslušných XML dokumentov, ktoré sú na nej založené.
2. Vygenerovanie Java tried na základe tejto schémy. Triedy zodpovedajú jednotlivým elementom XML dokumentu.
3. Deserializácia (unmarshalling) - konverzia XML dokumentu do inštan- cií príslušnej triedy.
4. Serializácia (marshalling) - vytvorenie XML dokumentu z inštancie.
Výhodou JAXB je zjednodušenie prístupu k XML dokumentu z progra- mového kódu. JAXB nevyžaduje po programátorovi vedieť metódy XML
28 spracovania (nemusí vytvárať SAX parser, ani Callback metódy). Na roz- diel od DOM spracovania povoľuje prístup k dátam v nesekvenčnom poradí. Nenúti programátora prechádzať strom XML aby sa dostal k dátam. Umož- ňuje testovanie validity vytvorením Validator objektu.
4.2.2 Metóda getPatientList() Parametrom je inštancia triedy GetPatientList s vyplnenými dátovými po- ložkami užívateľské meno a heslo pre daného užívateľa do systému EHR. Návratová hodnota je pole mien, priezvísk a dátumov narodení pacientov, ku ktorým má daný užívateľ prístup. Návratová hodnota je obalená v triede GetPatientListResponse. Metóda je odolná voči SQL injection útoku tým, že nepodporuje znak medzery v hesle ani v logine užívateľa. V prípade chyby vráti prázdne pole. Ak pacient nemá zadané dátum narodenia, určí ho me- tóda z rodného čísla. Ak nie je zadané ani rodné číslo, ako dátum narodenia sa použije aktuálny dátum.
4.2.3 Metóda getPatientData() Ako parametre dostane reťazec, v ktorom je uložený prázdny ParaModel, dátum, ku ktorému chce užívateľ aktuálne dáta, meno, priezvisko a dátum narodenia pacienta, a login a heslo užívateľa do databáze EHR. Jej úlohou je naplniť ParaModel dátami z databáze, ktoré sú aktuálne k dátumu pre- danému ako parameter. V prípade chyby vráti reťazec začínajúci "CHYBA:", aby mohol prehliadač odporúčaní užívateľovi chybu zobraziť. Samotný cyklus napĺňania prebieha postupne po jednotlivých identifiká- toroch dát (v nasledujúcom texte ich budem nazývať atribúty) uložených v prázdnom ParaModeli. Pre každý atribút, pre ktorý je definované mapo- vanie na SQL dotaz sa spustí vykonanie dotazu a výsledok uloží do hodnoty príslušného atribútu v plnom ParaModeli. Spomínaný cyklus by bolo možné optimalizovať, že by sa deklarovalo, ktoré atribúty sú uložené v rovnakej tabuľke v schéme AdamekJ a nedotazovať sa na každý samostatne. Problé- mom je, že pri jednom vyšetrení nie je doktor povinný vyplniť všetky dáta a teda by sa mohlo stať, že by sme dotazom vybrali záznam z vyšetrenia staršieho dátumu, len preto, že neobsahuje jeden z vyžadovaných atribútov. To by mohlo negatívne ovplyvniť neskorší výber liečby pacienta. Napríklad tabuľka FyzikalniVysetreni obsahuje dáta o výške, váhe, obvode pasu, telesnej teplote a tlaku pacienta. V prípade, že by sme požadovali v dotaze
29 všetky spomínané atribúty vyplnené, mohlo by sa stať, že vrátený výsledok nebude obsahovať žiaden záznam, hoci by všetky atribúty v databázi vypl- nené boli, ale nebolo by to pri jednej návšteve, ale pri viacerých. Naplnený ParaModel sa JAXB marshallerom serializuje do XML súboru a ten sa nastaví ako odpoveď v objekte typu GetPatientDataResponse.
4.3 EHR2GLBridge
Ako jediný z projektov má užívateľské rozhranie. Úvodná stránka index.jsp je napísaná v technológii Java Server Pages. JSP je veľmi podobná JavaSc- riptu, akurát kód vložený v súbore sa spustí na strane serveru, nie u klienta. Úvodná stránka presmeruje HTTP spojenie kvôli bezpečnosti na HTTPS a zobrazí klientovi jednoduchý prihlasovací formulár. Ostatné prvky projektu Bridge sú implementované ako servlet, na kto- rom užívateľ môže požiadať o dáta pacienta.
4.3.1 Java Servlety Servlety[26] sú komponenty nezávislé na protokole a platforme. Sú načítané a spúšťané pomocou JVM (Java Virtual Machine)[30] na príslušnom apli- kačnom serveri. Servlety majú byť implementácia dynamického webového obsahu ako PHP, CGI alebo ASP.NET v Jave. Implementujú princíp po- žiadavka/odpoveď, typický pre architektúru klient-server. Java Servlet API definuje štandardné rozhrania pre obsluhu týchto požiadaviek a odpovedí medzi klientom a serverom. Životný cyklus servletu: 1. Trieda servletu je načítaná aplikačným serverom. 2. Aplikačný server zavolá init() metódu. Tá inicializuje servlet a musí byť zavolaná predtým, ako servlet spracuje prvú požiadavku. Je zavo- laná vždy len raz pre každý servlet. 3. Po inicializácii servlet môže dostávať požiadavky. Každá požiadavka je spracovávaná vo vlastnom vlákne. Aplikačný server zavolá service() metódu, ktorá určí metódu servletu, ktorá sa zavolá na spracovanie požiadavky. 4. Nakoniec aplikačný server zavolá metódu destroy(), ktorá zruší serv- let. Metóda destroy() je tiež volaná len raz pre každý servlet.
30 Výhody servletov vyplývajú z ich behu v JVM, ktorá jednotlivé požiadavky obsluhuje vláknami. V pamäti sa nachádza len jedna inštancia servletu. Oproti tomu pri spúšťaní CGI skriptov sa po ukončení obsluhy požiadavky ukončí i program a pre každú požiadavku je spustený samostatný proces, čo spôsobuje zvýšenú réžiu.
4.3.2 Java RMI a webové služby Na volanie webových služieb sa používa technológia Remote Method Invoca- tion (RMI), ktorá je využívaná i v CORBA. Java RMI je objektový protokol špeciálne navrhnutý tak, aby umožnil komunikovať objektom nachádzajú- cim sa v rôznych JVM. Vytvára určité „maskovanieÿ, pri ktorom volanie z pohľadu klientského objektu vyzerá tak, ako keby vzdialený objekt bežal na tej istej JVM, i keď v skutočnosti beží na inej. Stub je proxy objekt, zodpovedný za spracovanie volania vzdialených metód. Jeho úlohou je ukrývať fakt, že klient v skutočnosti komunikuje so vzdialeným objektom. Stub presne kopíruje metódy vzdialeného objektu.
4.3.3 BridgeServlet Implementuje metódy doGet() a doPost() triedy HttpServlet. HTTP me- tóda POST sa používa len na prihlásenie užívateľa, metóda GET sa používa pri zmenách ovládacích prvkov, aby sa užívateľovi nestrácali vyplnené údaje, keď si obnoví stránku, alebo keď vyberie iný EHR server, aby sa mu zobrazil zoznam pacientov k danému EHR a nie všetci možní pacienti. Diakritika v priezviskách pacientov nie je problémom. SQL dotaz SELECT * FROM patient WHERE surname LIKE "s%" COLLATE "utf8_general_ci" ORDER BY surname,birth_date ASC vráti zoznam pacientov, ktorých priezvisko začína na S alebo Š zoradený podľa abecedy vzostupne, v prípade rovnakého priezviska zoradí pacientov v zozname podľa dátumu narodenia. Konfigurácia je uložená v JSP súbore defaults.jsp. BridgeServlet si ju načíta do Hash mapy pri prvom spustení. Načítanie a správu konfigurácie má na starosti trieda BridgeConfig. Na komunikáciu s EHRClientom sa používajú triedy EHRClientStub a EHRClientCallbackHandler. EHRClientStub poskytuje metódy na vy- tvorenie volania a EHRClientCallbackHandler sa použije pri asynchrón- nom volaní webovej služby. Metóda getPatientList() sa volá synchrónne,
31 lebo potrebujeme užívateľovi zobraziť aktuálny zoznam pacientov v danom EHR, ale metóda getPatientData() sa volá asynchrónne, lebo jej volanie môže trvať dlhšiu dobu a užívateľ o ňom nemusí vedieť. Keď Bridge dostane plný ParaModel, musí ho poslať MGLSServeru (po- písaný ďalej). Na to použije triedu MGLSServerStub a jej metódu putFullParaModel().
4.4 MGLSServer
Implementuje dve webové služby. Vznikol ako prepojenie Bridge na stránku prehliadača odporúčaní. Prvá webová služba je smerom ku Bridge s me- tódou putFullParaModel(), ktorou sa na server dostávajú dáta. Druhá je smerom k webovému prehliadaču odporúčaní getPatientData(), ktorou sa dáta dostanú na stránku Guidelines[1](prehliadača odporúčaní). V konfigurácii je definované spojenie do databáze a mapovanie názvov atribútov v plnom ParaModeli na názvy a typy ovládacích prvkov na stránke prehliadača odporúčaní.
4.4.1 Metóda putFullParaModel() Vytvára upravený ParaModel z plného ParaModelu. Pomocou zdrojového kódu:
JAXBContext jc2 = JAXBContext. newInstance(MGLSServer.response.ObjectFactory.class); Marshaller marshaller = jc2.createMarshaller(); sa vytvorí serializátor upraveného ParaModelu do XML formátu. Cyklom cez všetky atribúty v plnom ParaModeli a aplikovaním mapova- nia názvov atribútov na názvy a typy ovládacích prvkov sa plný ParaModel pretransformuje na upravený. V prípade potreby pretransformovania hod- nôt atribútov v plnom ParaModeli na iné hodnoty v upravenom ParaModeli sa použije tabuľka ParaModelPIDtoMGLSValuesMap, v ktorej je napríklad definované, že pre atribút ”SEX” hodnota ”1” v plnom ParaModeli bude hodnota ”muž” v upravenom ParaModeli. Parametrami metódy putFullParaModel() sú XML reťazec plného Pa- raModelu, meno a priezvisko pacienta, kód označujúci odporúčanie a dá- tum, ku ktorému sú pacientove dáta aktuálne. Parametre sú zabalené v
32 triede PutFullParaModel. Upravený ParaModel sa uloží do databáze spolu s menom pacienta a kódom označujúcim odporúčanie, pre ktoré boli dáta vytvorené. Dátum, ku ktorému sú pacientove dáta aktuálne sa v súčasnej implementácii nepoužíva, ale v prípade iných typov prehliadačov odporúčaní sa môže hodiť. Upravené ParaModely sú v databázi uložené v podobe reťazcov. Pre ka- ždého pacienta a každý kód odporúčania povoľujeme mať uložené jedny dáta, aby databáza nerástla nad všetky medze. Prípad, že by si dvaja lekári (užíva- telia) chceli pozrieť rovnaké odporúčanie pre toho istého pacienta v rovnaký čas s iným časom, ku ktorému majú byť dáta aktuálne, je veľmi nepravde- podobný. Predpokladáme, že lekár si sám od seba pacientove odporúčania prezerať nebude a teda pacient musí byť u lekára, aby si lekár prezeral jeho dáta pre odporúčanie a predpokladáme, že pacient je len človek, teda ne- môže byť na viacerých miestach naraz. Pacientove dáta nie sú nijako viazané na užívateľa preto server odmietne požiadavku na získanie pacientových dát v prípade, že čas vytvorenia uprave- ného ParaModelu sa líši o viac ako 15 minút od aktuálneho času. Užívateľovi sa zobrazí chybová správa, že pacientove dáta na serveri sú príliš staré, nech si ich obnoví. Nevýhodou navrhnutej implementácie je, že sa užívateľ môže dostať k dá- tam pacienta, ku ktorému by inak nemal práva, ale v ParaModeli sa nepre- dávajú žiadne dáta, ktoré by mohli diskreditovať pacienta. V prípade potreby vyššej bezpečnosti pacientových dát, by sa systém navrhol tak, že by zmazal z databáze upravený ParaModel hneď potom, ako by ho poslal užívateľovi. Načítanie pacientových dát na stránku prehliadača odporúčaní je automatické a prebieha hneď po prihlásení. Útočník by musel stihnúť vyžiadať si dáta od MGLSServeru skôr ako sa užívateľovi, ktorý si chce zobraziť dáta načíta stránka prehliadača odporúčaní.
4.4.2 Metóda getPatientData() Úlohou metódy getPatientData() je posielať upravený ParaModel prehlia- daču odporúčaní. Presnejšie to funguje tak, že v prehliadači odporúčaní je vložený JavaScript, ktorý sa zavolá buď na užívateľskú žiadosť, alebo auto- maticky po prihlásení užívateľa, ak prehliadač rozpozná, že má žiadať o dáta automaticky. Serverová časť metódy getPatientData() je kratučká, robí len výber uloženého upraveného ParaModelu z databáze pre daného pacienta a dané
33 odporúčanie. Užívateľ musí splniť 15 minútovú lehotu, po ktorú má možnosť vyzdvihnúť upravený ParaModel, inak vráti chybu, že dáta nie sú k dispo- zícii.
AJAX Asynchronous JavaScript and XML (AJAX)[27] vznikol vhodnou kombiná- ciou bežne používaných technológií. AJAX umožňuje, aby stránka kontak- tovala HTTP server a prijala od neho ľubovoľné dáta v XML, bez toho, aby sa musela celá znovu nahrávať. Všetko je riešené len pomocou JavaScriptu, teda presnejšie použitím metód objektu XMLHttpRequest.
Zdrojový kód volajúci metódu getPatientData() Je napísaný v JavaScripte. Najprv sa vytvorí reťazec, ktorý použije ako SOAP správa webovej službe. Potom sa vytvorí príslušný XMLHttpRequest objekt, ktorý musí byť iný pre Internet Explorer, ako pre Firefox a Operu. Vzhľadom k tomu, že štandardný internetový prehliadač nedovolí poslať XML dotaz na inú doménu, musel sa naprogramovať proxy server uložený na rovnakom webe ako je prehliadač odporúčaní, ktorý posiela ďalej SOAP správu MGLSServeru a samozrejme SOAP odpoveď pošle ďalej prehliadaču odporúčaní. Pri programovaní proxy sa vychádzalo z kódu dostupného na stránke http://www.troywolf.com/articles/php/class http, ktorý musel prejsť nemalými úpravami, aby poslal ďalej HTTP hlavičky a HTTP telo SOAP správy. Objekt XMLHttpRequest umožňuje vytvoriť asynchrónne volanie, tým, že sa jeho vlastnosti onReadyStateChange priradí pointer na metódu (názov metódy) schopnej spracovať zmeny stavu. Po inicializovaní asynchrónneho volania sa zavolá metóda open() a nastavia sa príslušné hlavičky HTTP. Žiadosť sa pošle volaním metódy send(), ktorej sa ako parameter predá reťazec, v ktorom je uložená SOAP správa. Kód vytvárajúci SOAP správu pre volanie webovej služby zabalenej v AJAX žiadosti vyzerá: function getSOAPEnvelope(PatientName, GuideLine) { return "<\?xml version=’1.0’ encoding=’utf-8’?>" + "
34 "
Odpoveď na AJAX žiadosť je dostupná, keď vlastnosť readyState objektu XMLHttpRequest je rovná číslu 4. Možné hodnoty vlastnosti readyState sú:
35 0 - žiadosť nie je inicializovaná
1 - žiadosť bola inicializovaná
2 - žiadosť bola poslaná
3 - žiadosť je spracovávaná
4 - odpoveď je prijatá
Samotný XML súbor odpovede braný ako reťazec je dostupný vo vlastnosti responseText. Vnútri SOAP odpovede je vložený XML súbor upraveného ParaModelu. Funkcia myStateChange() najprv získa upravený ParaModel ako reťa- zec. Musí odstrániť SOAP obálku, nahradiť reťazec ”<” znakom ”<” a re- ťazec ”>” znakom ”>”. Potom reťazec upraveného ParaModelu načíta DOM XML parserom a nastaví hodnoty ovládacích prvkov na stránke pre- hliadača odporúčaní.
36 Kapitola 5
Inštalácia a spúšťanie
V tejto kapitole je popísané, čo potrebuje vytvorená aplikácia k behu, mo- žnosti jej konfigurácie a kroky potrebné na spustenie.
5.1 Požiadavky
Aplikácia môže bežať na ľubovoľnom počítači s ľubovoľným operačným sys- témom s nainštalovaným JRE (Java Runtime Enviroment). Minimálna hard- warová konfigurácia na spustenie JVM (Java Virtual Machine) je Pentium 166MHz alebo lepšie, 125 MB voľného miesta na disku a aspoň 32MB pa- mäti RAM. K funkčnej JVM sa musí nainštalovať Java aplikačný server - Apache Tomcat 6.0[13], ktorý je potrebné nastaviť aby podporoval aj HTTPS pri- pojenia. Návod je uvedený v prílohách. V aplikačnom serveri musí fungovať Apache AXIS[12], ktorý sa do Tomcatu nainštaluje skopírovaním axis2.war archívu do zložky Tomcat/webapps. Webová stránka prehliadača odporúčaní vyžaduje funkčný webový server s podporou PHP a MySQL. Odporúčame nainštalovať XAMPP (http://www.apachefriends.org/en/xampp.html), ktorý obsahuje korektne na- stavený webový server Apache, PHP a databázový server MySQL. Stránka prehliadača dovoľuje len HTTPS prístup, preto treba urobiť zmeny v konfi- gurácii Apache - popísané v prílohe. Každý podprojekt vytvorenej aplikácie vyžaduje prácu s databázou, preto treba nainštalovať databázový server MySQL (http://www.mysql.com). Da- tabázový server Oracle s databázou fiktívnych pacientov beží na serveri neo.euromise.cz.
37 5.2 Konfigurácia podprojektov
Na zmenu konfigurácie už skompilovaných podprojektov je možné použiť WinRar, alebo program schopný rozbaliť a zabaliť war a aar archívy.
BridgeServlet Konfiguračný súbor je neštandardne súbor default.jsp nachádzajúci sa v zložke koreňovej zložke Bridge.war archívu. Musel byť použitý formát jsp súboru, lebo konfigurácia musí byť prístupná z prihlasovacej stránky index.jsp. V konfiguračnom súbore je definované pripojenie do databáze, číslo HTTPS portu pre Tomcat a logická hodnota, určujúca či sa má obno- vovať zoznam pacientov pre daný EHR pri každej zmene vybraného EHR serveru na stránke BridgeServletu.
EHRClient Konfigurácia EHRClienta je uložená v súboroch xml a ini nachádzajúcich sa v zložke EHRClient/config v archíve EHRClient.aar. V XML súbore je definované pripojenie do databáze, v INI súbore je deklarované mapovanie názvov atribútov v prázdnom ParaModeli na SQL dotazy.
MGLSServer Rovnako ako EHRClient má xml a ini súbor. V INI súbore je definované ma- povanie názvov atribútov v plnom ParaModeli na názvy ovládacích prvkov na stránke prehliadača odporúčaní. Súbory sú v zložke MGLSServer/config v archíve MGLSServer.aar.
Prehliadač odporúčaní Má konfiguračný súbor MGLSWebInterface/config/defaults.php. Je dô- ležité správne nastaviť premenné $MGLSServer url na URL webovej služby MGLSServeru a $proxy url na URL k súboru proxy.php na stránke pre- hliadača. Uvedené premenné sa používajú JavaScriptom pri volaní funkcie getPatientData() webovej služby MGLSServeru.
38 5.3 Spustenie podprojektov
Na skopírovanie skompilovaných archívov obsahujúcich JVM medzikód sú na priloženom CD vytvorené skripty v zložke /bin/scripts. Pre operačný systém Windows je skript nazvaný CreateScript.cmd, pre Linux CreateScript.sh. Predpokladá sa, že užívateľ má nainštalované a spus- tené všetky aplikácie, na ktorých sú podprojekty závislé. Hlavne užívateľ musí spustiť Apache Tomcat a do neho skopírovať axis2.war aby sa vytvo- ril adresár Tomcat/webapps/axis2 a jeho podadresáre, do ktorých sa musia skopírovať skompilované archívy webových služieb. Skripty pracujú s pred pripravenými skompilovanými archívmi podpro- jektov, ktoré boli vytvorené pomocou vývojového prostredia Eclipse, ktoré umožňuje zvoliť cestu kam sa archív podprojektu vytvorí. V skriptoch sa po- užívajú premenné, ktoré musí užívateľ aktualizovať, ak zmenil štandardnú cestu pri inštalácii niektorej aplikácie. Súbor Bridge.war je vytvorený Tomcat pluginom. Užívateľ si musí na- staviť cestu kam chce vytvoriť archív. Súbory EHRClient.aar a MGLSServer.aar sú vytvorené pluginom Axis2 Service Archiver. Do aar archívu podprojektu je vždy pridaná používaná knižnica JDBC ovládača nachádzajúca sa v pod zložke lib v zložke podpro- jektu.
39 Kapitola 6
Záver
Cieľom tejto práce bolo vytvoriť spojenie medzi elektronickými záznamami pacientových dát[4] a prehliadačom odporúčaní[1]. Vznikol systém, ktorého úlohou je automaticky naplniť dáta potrebné pre výpočet odporúčania z da- tabáze pacientových dát. Univerzálnosť systému je dosiahnutá možnosťou použitia akejkoľvek implementácie EHR záznamov schopnej naplniť prázdny ParaModel a akéhokoľvek prehliadača lekárskych odporúčaní, ktorý dokáže spracovať naplnený ParaModel. Rozsah práce nedovoľuje použité technológie popísať do detailov, preto sa v prípade nejasností odporúča preštudovať zdroje uvedené v použitej li- teratúre.
ParaModel XML ParaModel je XML súbor obsahujúci množinu atribútov - hodnôt dôležitých pre výpočet odporúčania. ParaModel definuje unikátne meno, typ, popis v Českom jazyku, dátový typ a hodnotu atribútu. Implementácia príkladového ParaModelu je popísaná a priložená v dokumente [20], alebo v zložkách zdro- jových kódov k podprojektu EHR2GLBridge. Do používaného XML súboru ParaModelu boli pridané ďalšie atribúty, ktoré je schopný EHRClient naplniť z databáze. V ideálnom prípade by atribúty ParaModelu boli číslované podľa číselníku SNOMED CT[17], ale k vytvoreniu takého ParaModelu by bolo treba mať odborníka, ktorý sa do číselníku vyzná. Vzhľadom k tomu, že potrebu používania štandardizovaného číselníka v ČR ešte neschválilo Ministerstvo zdravotníctva ČR[18], nie je v Českej
40 republike žiadny odborník, ktorý by sa vyznal do implementácie SNOMED. Preto z testovacích dôvodov bol vytvorený príkladový ParaModel, v ktorom boli pre názvy atribútov v ParaModeli použité anglické názvy daných atri- bútov, prípadne skratka viacslovného názvu. Rovnaké názvy atribútov boli potom použité pri mapovaní atribútov ParaModelu na SQL dotazy v pod- projekte EHRClient a pri mapovaní atribútov plného ParaModelu na názvy a typy ovládacích prvkov na stránke prehliadača odporúčaní. Keby názvy atribútov boli podľa číselníku SNOMED celý program by fungoval presne rovnako, akurát by boli použité iné hodnoty v mapovaniach.
Budúce práce Rozširovanie súčasného projektu sa môže uberať v budúcnosti tromi smermi:
1. Rozšírenie EHR - použitie číselníku SNOMED pri ukladaní pacien- tových dát do databáze, aby mohla byť použitá rovnaká implementácia EHR aj v iných krajinách.
2. Implementácia SNOMED - rozšírenie implementácie tejto bakalár- skej práce na používanie číselníku SNOMED v súboroch ParaModelov a v definíciách mapovaní.
3. Zmena prehliadača odporúčaní - vytvorenie nového projektu pre- hliadača odporúčaní, ktorý by nepotreboval mať v databáze uložené súradnice, kde presne má daný krok v odporúčaní vykresliť a súrad- nice začiatočných a koncových bodov všetkých hrán medzi krokmi. Teda vytvoriť aplikáciu schopnú zobraziť odporúčanie rovno načíta- ním XML dokumentu definujúceho kroky v odporúčaní a ich vzťahy.
Pre všetky tri smery bude treba implementovať viac typov odporúčaní a po- užitie väčšieho dátového modelu pacientových dát.
41 Literatúra
[1] On-line aplikácia „Medical Guidelines SYSTEMÿ http://guidelines.euromise.cz
[2] Health Level Seven - http://en.wikipedia.org/wiki/Health Level 7
[3] XPath - http://www.w3.org/TR/xpath
[4] AdamekJ „Aplikace Datového Modelu EuroMISE-Kardio v Javěÿ, 43-48 http://www.cs.cas.cz/hakl/doktorandsky-den/files/2007/ sbornik-dd-2007.pdf,
[5] OCL - Object Constraint Language http://www.omg.org/docs/ptc/03-10-14.pdf
[6] CORBA - Common Object Request Broker Architecture http://www.omg.org/gettingstarted/corbafaq.htm
[7] Word Wide Web Consortium - http://www.w3.org/
[8] Universal Description, Discovery and Integration register http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm
[9] Simple Object Access Protocol http://www.w3.org/TR/soap/
[10] Web Services Description Language http://www.w3.org/TR/wsdl
[11] Webové služby a ontologie, 6-8 http://nb.vse.cz/ svatek/mdb03fi.pdf
42 [12] Apache AXIS framework http://ws.apache.org/axis2/
[13] Apache Tomcat 6.0. http://tomcat.apache.org/
[14] Nagy M, Hanzlicek P, Preckova P, Kolesa P, Misur J, Dioszegi M, Zva- rova J: Building semantically interoperable EHR systems using inter- national nomenclatures and enterprise programming techniques, CeHR Conference Proceedings 2007, 105-110 ISBN 978-1-58603-834-2
[15] Ohno-Machado L, Gennari JH, Murphy SN, Jain NL a kol.: The Guide- line Interchange Format: A model for representing guidelines, Journal of the American Medical Informatics Association 1998, 5(4), 357-372 ISSN 1067-5027
[16] NČLP - Národní číselník laboratorních položek http://ciselniky.dasta.mzcr.cz/CD DS3/hypertext/MZAIA.htm
[17] SNOMED - Systematized Nomenclature of Medicine - Clinical Terms http://en.wikipedia.org/wiki/SNOMED CT
[18] Ministerstvo zdravotnictví ČR: Návrh systému správy terminologie ve zdravotnictví http://www.mzcr.cz/Odbornik/Pages/ 503-navrh-systemu-spravy-terminologie-ve-zdravotnictvi.html
[19] Java Architecture for XML Binding http://java.sun.com/developer/technicalArticles/WebServices/jaxb/
[20] Buchtela D: GLIF-XML model „Doporučení pro diagnostiku a léčbu plicní arteriální hypertenze v ČRÿ, Praha, 2006 zpráva Centru biomedicínské informatiky (CBI)
[21] Buchtela D, Brožek J: Knowledge representation system for decision support, Scientia Agric. Bohem., 39, 2008, 97–101 http://sab.czu.cz/cs/?r=4407&mp=download&sab=19&part=123
[22] Patel VL, Branch T, Wang D, Peleg M, Boxwala A: Analysis of the Process of Encoding Guidelines: A Comparison of GLIF2 and GLIF3,
43 Methods Inf Med, 2002, no. 2, 105-113 ISSN 0026-1270 [23] Peleg M, Boxwala A a kol., Guideline Interchange Format 3.5 Technical Specification, InterMed Collaboratory, May 2004 http://ishtar.me/zen/attachment/1289900789.pdf alebo http://smi-web.stanford.edu/projects/intermed- web/guidelines/GLIF TECH SPEC May 4 2004.pdf [24] Boxwala A a kol.: GLIF 3: a representation format for sharable computer-interpretable clinical practice guidelines, Journal of Biome- dical Informatics, Volume 37, Issue 3, June 2004, 147-161 ISSN 1532-0464 [25] Sordo M, Ogunyemi O, Boxwala AA, Greenes RA. Software Specificati- ons for GELLO: An object-oriented query and expression language for clinical decision support. DSG Technical Report DSG-TR-2003-02 http://www.hl7.org/Library/Committees/dss/GELLOspecsJan041.pdf [26] Java Servlet Technology http://java.sun.com/products/servlet/ [27] Asynchronous JavaScript and XML http://en.wikipedia.org/wiki/AJAX [28] Zdrojový kód použitý ako server proxy pre SOAP správy http://www.troywolf.com/articles/php/class http [29] CSS - Cascading Style Sheets - http://www.w3.org/Style/CSS/ [30] Java, Sun Microsystems Inc. - http://java.sun.com/ [31] JDBC - Java Database Connectivity http://en.wikipedia.org/wiki/Java Database Connectivity [32] OpenSSL: The Open Source toolkit for SSL/TLS http://www.openssl.org/
[33] History of TEX- http://www.tug.org/whatis.html [34] XML Schema - www.w3.org/XML/Schema
44 Dodatok A
Obsah priloženého CD-ROM
Koreňový adresár obsahuje zložky:
bin obsahuje inštalačné súbory aplikácií potrebných na spustenie bakalár- skej práce, archívy Java medzikódu vytvorené skompilovaním zdro- jových súborov, skript na uverejnenie všetkých troch podprojektov a prehliadaču odporúčaní a SQL skripty na vytvorenie databáz použi- tých v podprojektoch bakalárskej práce.
src obsahuje zdrojové kódy všetkých podprojektov a prehliadača odporú- čaní
doc obsahuje tento text vo forme pdf súboru, zložku v ktorej sú ulo- žené všetky súbory použité na vygenerovanie textu bakalárskej práce z TEX a obrázok dátovej schémy aplikácie AdamekJ
45 Dodatok B
Nastavenie HTTPS
HTTPS vo webovom serveri Apache
Najprv sa musia vytvoriť SSL certifikáty serveru. Na ich vytvorenie slúži OpenSSL[32] aplikácia. Nasledujúcimi príkazmi sa vytvoria a potom sa vy- tvorené súbory musia presunút do podadresára Apache/conf.
openssl req -new -out server.csr openssl rsa -in privkey.pem -out server.key openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 365
Do konfiguračného súboru Apache serveru Apache/conf/httpd.conf sa pri- dajú riadky:
Listen 443 AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl SSLPassPhraseDialog builtin SSLSessionCache dbm:logs/ssl.scache SSLSessionCacheTimeout 300 SSLMutex default
46 SSLCertificateKeyFile conf/server.key #Aby server odmietol prístup k dôležitým súborom
Apache Tomcat a HTTPS
Vygeneruje sa .keystore súbor príkazom
openssl -genkey -alias tomcat -keyalg RSA -keystore cesta\_k\_certifikátu -storepass heslo\_k\_certifikátu a potom sa pridá do konfiguračného súboru Tomcatu Tomcat/conf/server.xml nasledujúci XML tag:
47