VYSOK ´ E U ˇ CEN´I TECHNICK ´ E V BRN ˇ E
BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMA ˇ CN´ICH TECHNOLOGI´I USTAV INFORMA ˇ ´ CN´ICH SYST ´ EM ˚ U
FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
AMBULANTN´I SYST ´ EM ZALO ˇ ZEN ´ Y NA IZIP A JEHO ZABEZPE ˇ CEN´I
DIPLOMOV ´ A PR ´ ACE
MASTER’S THESIS
AUTOR PR ´ ACE Bc. LUK ´ A ˇ S JANE ˇ CKA
AUTHOR
BRNO 2008
VYSOK ´ E U ˇ CEN´I TECHNICK ´ E V BRN ˇ E
BRNO UNIVERSITY OF TECHNOLOGY
FAKULTA INFORMA ˇ CN´ICH TECHNOLOGI´I USTAV INFORMA ˇ ´ CN´ICH SYST ´ EM ˚ U
FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
AMBULANTN´I SYST ´ EM ZALO ˇ ZEN ´ Y NA IZIP A JEHO ZABEZPE ˇ CEN´I
MEDICAL SYSTEM BASED ON IZIP AND ITS SECURITY
DIPLOMOV ´ A PR ´ ACE
MASTER’S THESIS
AUTOR PR ´ ACE Bc. LUK ´ A ˇ S JANE ˇ CKA
AUTHOR
VEDOUC´I PR ´ ACE Ing. PAVEL JURKA
SUPERVISOR
BRNO 2008
Abstrakt
Tato pr´ace pojedn´av´a o anal´yze, n´avrhu a implementaci zjednoduˇsen´eho ambulantn´ıho informaˇcn´ıho syst´emu praktick´eho l´ekaˇre komunikuj´ıc´ıho se syst´emem IZIP. Pˇri n´avrhu syst´emu je uˇzita architektura Model–View–Controller, n´avrhov´e vzory a technika objek- tov´eho modelov´an´ı pomoc´ı UML. V pr´aci je tak´e pops´an zp˚usob komunikace se syst´emem IZIP, struktura odes´ılan´ych dat a zabezpeˇcen´ı t´eto komunikace. Pro implementaci navrˇze- n´eho syst´emu byl pouˇzit programovac´ı jazyk C++, pro zpracov´an´ı XML dokument˚u parser Xerces-C++, pro grafick´e uˇzivatelsk´e rozhran´ı toolkit Qt a data jsou ukl´ad´ana do relaˇcn´ı datab´aze Firebird.
Kl´ıˇ cov´ a slova
IZIP, ambulantn´ı informaˇcn´ı syst´em, datab´aze, bezpeˇcnost, Model–View–Controller, UML, n´avrhov´y vzor
Abstract
The work discusses the analysis, proposal and implementation of simplified outpatient in- formation system of general practitioner (GP), which communicates with IZIP information system. The proposal of system uses the Model–View–Controller architecture; the design patterns and subject simulated technique use UML. The way of communication with IZIP system, the structure of sent data and the communication security is also described in the work. C++ programming language is used for the implementation of the proposed system, parser Xerces-C++ for XML documents processing, toolkit Qt for graphical user’s interface;
and the data are stored into the Firebird relational database.
Keywords
IZIP, outpatient information system, database, security, Model–View–Controller, UML, de- sign pattern
Citace
Luk´aˇs Janeˇcka: Ambulantn´ı syst´em zaloˇzen´y na IZIP a jeho zabezpeˇcen´ı, diplomov´a pr´ace, Brno, FIT VUT v Brnˇe, 2008
Ambulantn´ı syst´ em zaloˇ zen´ y na IZIP a jeho zabez- peˇ cen´ı
Prohl´ aˇsen´ı
Prohlaˇsuji, ˇze jsem tento diplomov´y projekt vypracoval samostatnˇe pod veden´ım pana Ing.
Pavla Jurky. Dalˇs´ı informace mi poskytli MUDr. Pavel Janeˇcka a MUDr. Olga Janeˇckov´a.
Uvedl jsem vˇsechny liter´arn´ı prameny a publikace, ze kter´ych jsem ˇcerpal.
. . . . Luk´aˇs Janeˇcka
19. 5. 2008
Podˇ ekov´ an´ı
Dˇekuji vedouc´ımu diplomov´e pr´ace za vstˇr´ıcnost a mnoho dobr´ych rad a n´amˇet˚u, a Lucii Cepel´akov´e za pomoc pˇri testov´an´ı implementovan´eho syst´emu.ˇ
°c Luk´aˇs Janeˇcka, 2008.
Tato pr´ace vznikla jako ˇskoln´ı d´ılo na Vysok´em uˇcen´ı technick´em v Brnˇe, Fakultˇe in- formaˇcn´ıch technologi´ı. Pr´ace je chr´anˇena autorsk´ym z´akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´a- vnˇen´ı autorem je nez´akonn´e, s v´yjimkou z´akonem definovan´ych pˇr´ıpad˚u.
Obsah
1 Uvod´ 3
2 Programy a Internet 4
3 Zdravotnick´y software 5
3.1 Ambulantn´ı informaˇcn´ı syst´em . . . 5
4 Datov´y standard Ministerstva zdravotnictv´ı ˇCR 7 5 Zdravotnick´e port´aly 8 5.1 IZIP . . . 8
5.2 Komunikace s IZIP . . . 9
5.2.1 Komunikace s IZICHECK . . . 10
5.2.2 Komunikace s IZIVIEW . . . 10
5.2.3 Komunikace s IZIGATE . . . 10
5.2.4 Bezpeˇcnost informac´ı v IZIP . . . 11
5.3 Rizika a slab´a m´ısta projekt˚u zaloˇzen´ych na IZIP . . . 12
5.4 Komunikace s pojiˇst’ovnou . . . 13
5.4.1 P´ısemn´a komunikace . . . 13
5.4.2 Elektronick´a komunikace . . . 14
6 Ambulantn´ı informaˇcn´ı syst´em komunikuj´ıc´ı s IZIP 16 6.1 Anal´yza poˇzadavk˚u . . . 16
6.1.1 Poˇzadavky obecnˇe . . . 17
7 N´avrh ambulantn´ıho informaˇcn´ıho syst´emu komunikuj´ıc´ıho s IZIP 18 7.1 Pˇr´ıpady uˇzit´ı . . . 19
7.1.1 Pˇr´ıklady pˇr´ıpad˚u uˇzit´ı prvn´ı iterace . . . 19
7.2 Datab´aze . . . 20
7.2.1 Konceptu´aln´ı sch´ema datab´aze . . . 20
7.2.2 Sch´ema datab´aze . . . 21
7.3 Architektura syst´emu . . . 22
7.4 Bezpeˇcnost . . . 23
8 Implementace 25 8.1 Datab´aze . . . 25
8.1.1 Datov´e pohledy . . . 26
8.1.2 Datab´azov´e procedury . . . 26
8.2 Datov´a vrstva . . . 27
8.3 Vrstva Model . . . 28
8.3.1 Tˇr´ıdaSpravce . . . 28
8.3.2 Tˇr´ıdySpravceUzivatelu,SpravcePacientu a SpravceZaznamu. . . 28
8.3.3 Tˇr´ıdaSpravceCiselniku . . . 29
8.3.4 Tˇr´ıdaSystem . . . 30
8.4 Vrstva Controller . . . 30
8.4.1 Komunikace se syst´emem IZIP . . . 30
8.4.2 Odpovˇed’ syst´emu IZIP . . . 32
8.5 Vrstva View . . . 32
8.6 Tˇr´ıdaSpravceChyb . . . 34
8.7 Architektura syst´emu z pohledu komponent . . . 34
8.7.1 Firebird . . . 35
8.7.2 IBPP . . . 37
8.7.3 OpenSSL . . . 38
8.7.4 Libiconv . . . 38
8.7.5 Xerces-C++ . . . 38
8.7.6 Knihovna IZIP . . . 38
8.7.7 Qt . . . 39
8.8 Demonstrace projektu . . . 39
8.9 Stav implementace projektu . . . 40
9 Z´avˇer 41 A Prohl´aˇsen´ı o c´ılech 45 B Poˇzadavky na syst´em 46 B.1 Nefunkˇcn´ı poˇzadavky . . . 46
B.2 Funkˇcn´ı poˇzadavky . . . 46
C Anal´yza poˇzadavk˚u na syst´em 48 C.1 Diagram pˇr´ıpad˚u uˇzit´ı . . . 48
C.2 Popis diagramu pˇr´ıpad˚u uˇzit´ı prvn´ı iterace . . . 52
D N´avrh syst´emu 68 D.1 N´avrh obrazovek syst´emu . . . 68
D.2 N´avrh sch´ematu datab´aze . . . 70
D.2.1 Popis sch´ematu datab´aze . . . 70
D.2.2 Diagram sch´ematu datab´aze . . . 74
D.3 N´avrh architektury syst´emu . . . 76
D.3.1 N´avrh jednotliv´ych vrstev architektury . . . 77
E Obsah pˇriloˇzen´eho disku 81
Kapitola 1
Uvod ´
Tato pr´ace pojedn´av´a o v´yvoji ambulantn´ıho syst´emu, kter´y je schopen komunikovat se syst´emem IZIP. V ´uvodu pr´ace je vysvˇetleno, jak´e typy softwaru a za jak´ymi ´uˇcely jsou uˇz´ıv´any ve zdravotnictv´ı, a pops´ano zaˇrazen´ı ambulantn´ıho syst´emu do uveden´eho rozdˇelen´ı.
Protoˇze navrhovan´y syst´em m´a komunikovat s okoln´ımi subjekty pomoc´ı s´ıtˇe internet, jsou v pr´aci probr´any principy a zp˚usoby komunikace program˚u v t´eto celosvˇetov´e s´ıti.
Jelikoˇz v ˇCesk´e republice je mnoho softwarov´ych firem, kter´e vyv´ıjej´ı produkty pro zdravotnictv´ı, bylo potˇreba stanovit standard, kter´ym se bude ˇr´ıdit v´ymˇena informac´ı mezi tˇemito syst´emy. K tomuto ´uˇcelu byl sestaven Datov´y standard Ministerstva zdravotnictv´ı Cesk´e republiky, kter´y je v pr´aci tak´e zm´ınˇen.ˇ
Dalˇs´ı kapitola pr´ace pojedn´av´a o subjektech, s nimiˇz ambulantn´ı syst´em m˚uˇze komu- nikovat. ˇC´ast t´eto kapitoly je vyhrazena pro popis syst´emu IZIP a bezpeˇcnost syst´em˚u zaloˇzen´ych na IZIP.
Za touto kapitolou n´asleduj´ı kapitoly s n´avrhem amulantn´ıho syst´emu a jeho implemen- tac´ı.
V r´amci semestr´aln´ıho projektu byla provedena anal´yza a n´avrh tohoto syst´emu. V t´eto diplomov´e pr´aci jsou ze semestr´aln´ıho projektu vyuˇzity kapitoly zab´yvaj´ıc´ı se touto prob- lematikou a tak´e k tˇemto ˇc´astem n´aleˇzej´ıc´ı pˇr´ılohy.
Pro projekt ambulantn´ıho informaˇcn´ıho syst´emu jsem se rozhodl z d˚uvodu velk´eho z´ajmu o velmi levn´y, jednoduch´y program do ordinace praktick´eho l´ekaˇre, kter´y projevili osloven´ı praktiˇct´ı l´ekaˇri. Popt´avan´y program mˇel umˇet tak´e komunikovat se syst´emem IZIP, jehoˇz uˇz´ıv´an´ı bylo v t´e dobˇe zv´yhodnˇeno r˚uzn´ymi bonusy.
Kapitola 2
Programy a Internet
Podle [1] je Internet celosvˇetov´a poˇc´ıtaˇcov´a s´ıt’, kter´a spojuje jednotliv´e menˇs´ı s´ıtˇe pomoc´ı sady protokol˚u IP. Komunikace v t´eto s´ıti je ˇr´ızena protokoly, kter´e jsou podle vykon´avan´e funkˇcnosti dˇeleny do ˇctyˇr vrstev. Protokolem se podle [2] rozum´ı soubor syntaktick´ych a s´emantick´ych pravidel urˇcuj´ıc´ıch v´ymˇenu informace mezi nejm´enˇe dvˇema entitami. Toto dˇelen´ı vych´az´ı z referenˇcn´ıho modelu ISO/OSI. Mezi tyto ˇctyˇri vrstvy patˇr´ı:
vrstva s´ıt’ov´eho rozhran´ı – definuje standardy pro fyzick´a m´edia, elektrick´e sign´aly a rutiny pro pˇr´ıstup k fyzick´emu m´ediu,
s´ıt’ov´a vrstva – vytv´aˇr´ı datagramy, adresuje je a smˇeˇruje na m´ısto urˇcen´ı, transportn´ı vrstva – pˇred´av´a data mezi koncov´ymi uzly,
aplikaˇcn´ı vrstva – je tvoˇrena procesy a aplikacemi, kter´e komunikuj´ı po s´ıti.
Z hlediska program´atora jsou d˚uleˇzit´e posledn´ı dvˇe jmenovan´e vrstvy, na jejichˇz rozhran´ı se nach´az´ı tzv. sockety (schr´anky), coˇz je aplikaˇcn´ı programov´e rozhran´ı (API) pro ko- munikuj´ıc´ı procesy po s´ıti. Toto rozhran´ı je implementov´ano v knihovn´ach pro r˚uzn´e pro- gramovac´ı jazyky i pro r˚uzn´e operaˇcn´ı syst´emy (napˇr. BSD socket API pro unixov´e operaˇcn´ı syst´emy a Windows Sockets API pro operaˇcn´ı syst´emy MS Windows).
Pro komunikaci mezi dvˇema uzly v s´ıti jsou k dispozici dvˇe z´akladn´ı sch´emata:
• klient–server,
• klient–klient.
Sch´ema klient–server rozliˇsuje ´uˇcastn´ıky komunikace na klienta, kter´y pos´ıl´a poˇzadavky na zpracov´an´ı a (obvykle) iniciuje komunikaci, a server, kter´y ˇcek´a na poˇzadavky, zpra- cov´av´a je a zas´ıl´a odpovˇed’. Pˇri uˇzit´ı tohoto sch´ematu se v n´avrhu rozliˇsuje n´avrh klientsk´e ˇc´asti aplikace od serverov´e.
Ve sch´ematu klient–klient nelze ´uˇcastn´ıky rozliˇsit, protoˇze mohou simult´annˇe vystupovat v obou rol´ıch.
Uzly (aplikace) mezi sebou komunikuj´ı pomoc´ı aplikaˇcn´ıho protokolu. Tento mohou m´ıt sv˚uj vlastn´ı nebo vyuˇz´ıvaj´ı nˇekter´eho ze standardizovan´ych (napˇr. HTTP, IMAP, SMTP).
Kapitola 3
Zdravotnick´ y software
Zdravotnictv´ı je segment, v nˇemˇz trvale vznik´a velk´e mnoˇzstv´ı informac´ı. Tyto infor- mace vznikaj´ı na r˚uzn´ych m´ıstech a pˇri pouˇzit´ı konvenˇcn´ıch metod z´apisu (chorobopisy, l´ekaˇrsk´e zpr´avy, . . . ) doch´az´ı k jejich fragmentaci. Velk´y probl´em pˇredstavuje tak´e doba jejich pˇresunu (at’ uˇz mezi r˚uzn´ymi specializovan´ymi pracoviˇsti, nebo napˇr´ıklad pˇri pˇrestˇe- hov´an´ı pacienta).
Reˇsen´ım tohoto probl´emu je digitalizace tˇechto informac´ı a vyuˇzit´ı elektronick´e komu-ˇ nikace pro jejich pˇresun. Zdigitalizovan´a informace nic
”nev´aˇz´ı“, objemovˇe zab´ır´a mno- hem menˇs´ı prostor neˇz informace
”pap´ırov´a“, d´a se mnohem l´epe zabezpeˇcit (a to jak proti neopr´avnˇen´emu ˇcten´ı, tak proti zniˇcen´ı) a pˇri uˇzit´ı elektronick´e komunikace m˚uˇze b´yt kdykoliv k dispozici. Pro digitalizaci a spr´avu informac´ı ve zdravotnictv´ı slouˇz´ı specializo- van´y software – zdravotnick´y software.
Zdravotnick´y software m˚uˇzeme rozdˇelit do skupin podle oblast´ı jeho uˇzit´ı, kaˇzd´a oblast m´a na tento software jin´e specifick´e n´aroky. Tyto skupiny mohou b´yt n´asleduj´ıc´ı (pˇrevzato z [22]):
• Ambulantn´ı informaˇcn´ı syst´emy – slouˇz´ı pro samostatn´e a poliklinick´e ambulance.
• Nemocniˇcn´ı klinick´e informaˇcn´ı syst´emy – hlavn´ımi ´ukoly jsou administrativa, ambu- lance, l˚uˇzka, v´ykaznictv´ı a jin´e.
• Laboratorn´ı informaˇcn´ı syst´emy
• L´ek´arensk´e informaˇcn´ı syst´emy
• Manaˇzersk´e a ekonomick´e informaˇcn´ı syst´emy – zamˇeˇreny na provoz zdravotnick´eho zaˇr´ızen´ı.
• Jin´e speci´aln´ı produkty.
3.1 Ambulantn´ı informaˇ cn´ı syst´ em
Tato pr´ace se zab´yv´a informaˇcn´ım syst´emem ambulantn´ım, jehoˇz hlavn´ımi ´ukoly je spr´ava zdravotn´ıch z´aznam˚u, v´ykaznictv´ı a administrativa. Tyto syst´emy se d´ale rozliˇsuj´ı podle l´ekaˇrsk´e specializace (gynekologick´e, stomatologick´e, oftalmologick´e – kaˇzd´a specializace m´a jin´e n´aroky na syst´em), nˇekter´e z nich jsou navrˇzeny tak, ˇze je lze provozovat pro v´ıce odbornost´ı. V pr´aci se budu zab´yvat ambulantn´ım informaˇcn´ım syst´emem se zamˇeˇren´ım pouze pro praktick´e l´ekaˇre, protoˇze rozˇs´ıˇren´ı pro v´ıce odbornost´ı syst´em znaˇcnˇe komplikuje.
Pˇred zah´ajen´ım pr´ace na projektu jsem se sezn´amil s nab´ıdkou dostupn´ych produkt˚u s podobn´ym zamˇeˇren´ım. Zjistil jsem, ˇze v nab´ıdce jsou pouze produkty komerˇcn´ı, ˇz´adn´y produkt vyv´ıjen´y komunitou nebo produkt s otevˇren´ym zdrojov´ym k´odem, ˇci”volnou“ li- cenc´ı se na ´uzem´ı ˇCesk´e republiky nevyskytuje. (Ot´azku pouˇzitelnosti takov´ehoto syst´emu zde diskutovat nebudu.) Mezi ambulantn´ı informaˇcn´ı syst´emy patˇr´ı napˇr´ıklad 3L, PC DOK- TOR, AMBULANCE, MEDICUS, AMICUS.
Vˇsechny mnou zkouman´e produkty mˇely stejn´y model licencov´an´ı. Uˇzivatel nejprve zaplat´ı jednor´azovou ˇc´astku, za kterou obdrˇz´ı syst´em a s n´ım i podporu, kter´e je omezena na urˇcitou dobu. V r´amci t´eto podpory dost´av´a uˇzivatel aktualizace programu zdarma.
Avˇsak po uplynut´ı t´eto doby je uˇzivatel jiˇz nucen dalˇs´ı aktualizace programu zaplatit, pˇriˇcemˇz vˇetˇsina aktualizac´ı programu se skl´ad´a z aktualizac´ı ˇc´ıseln´ık˚u, kter´e se vesmˇes daj´ı z internetu st´ahnout zdarma (napˇr´ıklad ˇc´ıseln´ıky l´eˇciv, kter´e spravuje Vˇseobecn´a zdravotn´ı pojiˇst’ovna).
Dalˇs´ı negativn´ı vlastnost´ı tˇechto syst´em˚u je ˇspatn´a podpora pˇrechodu mezi jednotliv´ymi produkty. Jakmile uˇzivatel zaˇcne pouˇz´ıvat jeden produkt a m´a v jeho intern´ıch struktur´ach vˇsechna data, je pˇrechod na jin´y produkt velmi komplikovan´y, nˇekdy aˇz nemoˇzn´y. Nˇekter´e z firem nab´ızej´ı pˇreveden´ı dat z jin´eho syst´emu do sv´eho, cena tohoto pˇrevodu vˇsak mnohdy pˇrekroˇc´ı cenu vlastn´ıho software.
Aby tento text nevyznˇel jako kritika ambulantn´ıch syst´em˚u na trhu, mus´ım ho uzavˇr´ıt konstatov´an´ım, ˇze na trhu je tak´e mnoho kvalitn´ıch syst´em˚u, kter´e maj´ı mimo tˇechto nˇekolika negativ mnoho kladn´ych vlastnost´ı.
Kapitola 4
Datov´ y standard Ministerstva zdravotnictv´ı ˇ CR
Kv˚uli znaˇcn´e rozmanitosti informaˇcn´ıch syst´em˚u uˇz´ıvan´ych ve zdravotnictv´ı a potˇrebˇe sjednocen´ı pravidel pro komunikaci mezi nimi, byl sestaven Datov´y standard Ministerstva zdravotnictv´ı ˇCesk´e republiky (d´ale jen DASTA).
Pr´ace na tomto standardu zapoˇcaly v roce 1997 a pod´ıleli se na nˇem hlavn´ı dodavatel´e zdravotnick´ych informaˇcn´ıch syst´em˚u v ˇCR. Pˇri n´avrhu standardu byla snaha zohlednit jak existuj´ıc´ı mezin´arodn´ı standardy (napˇr. Health Level 7), tak potˇreby poskytovatel˚u zdravotn´ı p´eˇce. Pr´ace na datov´em standardu byly podle [19] dovrˇseny v roce 2002 vyd´an´ım verze 02.01.01.
Mezi hlavn´ı vlastnosti DASTA patˇr´ı:
• pˇrenositelnost dat (zajiˇstˇena pomoc´ı textov´eho form´atu XML),
• univerz´alnost (lze pouˇz´ıt ve vˇsech zdravotnick´ych syst´emech),
• garance dat (u vˇsech dat lze zjistit jejich p˚uvod),
• plnohodnotnost (lze zapsat vˇsechny typy zdravotn´ıch z´aznam˚u).
Datov´y standard proch´az´ı neust´al´ym v´yvojem, v prosinci 2006 byla vyd´ana verze 4.01.01 a n´asleduj´ıc´ı verze se snaˇz´ı o harmonizaci s mezin´arodn´ım standardem Health Level 7.
Kapitola 5
Zdravotnick´ e port´ aly
Mezi zdravotnick´e port´aly (port´aly, se kter´ymi komunikuje zdravotnick´y software ˇci pra- covn´ık) patˇr´ı port´aly pojiˇst’oven, port´al ´Ustavu zdravotnick´ych informac´ı a statistiky ˇCesk´e republiky, port´aly laboratoˇr´ı, IZIP a jin´e. Ne vˇsechna komunikace podl´eh´a Datov´emu stan- dardu MZ ˇCR, pˇr´ıkladem mohou b´yt laboratoˇre, kter´e vyuˇz´ıvaj´ı pro komunikaci intern´ıch datov´ych standard˚u sv´ych informaˇcn´ıch syst´em˚u (napˇr. MEDEA II, DUMP 2 a jin´e).
Kromˇe komunikace se zdravotnick´ymi port´aly se uplatˇnuje tak´e komunikace pomoc´ı e- mailu (hojnˇe vyuˇz´ıvan´a zvl´aˇstˇe laboratoˇremi), kdy jsou data zas´ıl´ana zaˇsifrovan´a a podep- san´a elektronick´ym podpisem.
5.1 IZIP
Syst´em IZIP, neboli Internetov´y pˇr´ıstup ke Zdravotnick´ym Informac´ım Pacienta, si podle [21] klade za hlavn´ı c´ıle:
• zlepˇsen´ı kvality poskytovan´e p´eˇce,
• zefektivnˇen´ı v´ymˇeny zdravotn´ıch informac´ı,
• zrychlen´ı a zkvalitnˇen´ı rozhodov´an´ı zdravotnick´ych pracovn´ık˚u,
• uspoˇren´ı finanˇcn´ıch prostˇredk˚u.
Tˇechto c´ıl˚u chce dos´ahnout d´ıky poskytnut´ı zdravotn´ıch informac´ı o pacientovi kdykoli je to potˇreba a tam, kde je to potˇreba. K tomu vyuˇz´ıv´a celosvˇetov´e s´ıtˇe Internet. Transport informac´ı uˇzit´ım syst´emu IZIP a dosavadn´ıho ˇreˇsen´ı zn´azorˇnuje obr´azek 5.1, pˇrejat´y z [20].
Odborný lékař 1
Odborný lékař 2
Laboratoř Praktický
lékař
Nemocnice Záchranná
služba
Pacient
Lékárna
Odborný lékař 1 Odborný
lékař 2
Laboratoř
Praktický lékař
Nemocnice Záchranná
služba
Pacient
Lékárna IZIP
Obr´azek 5.1: Pˇred´av´an´ı informac´ı bez IZIP a s IZIP
Zdravotn´ı informace jsou shromaˇzd’ov´any do tzv. Zdravotn´ıch kn´ıˇzek pacient˚u. Zdravotn´ı kn´ıˇzka vznik´a na z´akladˇe ˇz´adosti pacienta a je j´ım vlastnˇena. Pacient tak m´a pln´y pˇr´ıstup ke sv´ym z´aznam˚um, m˚uˇze je komentovat a podle [17] dokonce i poˇz´adat o jejich v´ymaz.
(V takov´em pˇr´ıpadˇe z˚ustane ve Zdravotn´ı kn´ıˇzce informace o vymaz´an´ı z´aznamu.)
Ke zdravotn´ım z´aznam˚um pacienta maj´ı pˇr´ıstup pouze pacientem vybran´ı l´ekaˇri a zdravotnick´a pracoviˇstˇe. V´yjimku tvoˇr´ı tzv. emergentn´ı pˇr´ıstup, kdy zdravotn´ı pracovn´ık m˚uˇze z´ıskat ze zdravotn´ı kn´ıˇzky urgentn´ı informace (krevn´ı skupina, alergie a podobnˇe).
Emergentn´ı pˇr´ıstup je pˇr´ıstup do syst´emu, kter´y je umoˇznˇen pouze pracovn´ık˚um z´a- chrann´e sluˇzby. Pˇri tomto pˇr´ıstupu nen´ı vyˇzadov´ano heslo pacienta, ale je nutn´e, aby pracovn´ık z´achrann´e sluˇzby, stejnˇe jako pracoviˇstˇe z´achrann´e sluˇzby, byl v syst´emu IZIP ˇr´adnˇe registrov´an.
5.2 Komunikace s IZIP
IZIP – internetov´y pˇr´ıstup ke zdravotn´ım informac´ım pacienta je tvoˇren port´alem, ke kter´emu pˇristupuj´ı jak l´ekaˇri, tak pacienti (klienti). L´ekaˇr sm´ı jednor´azovˇe nahl´ednout do z´aznam˚u pacienta, kter´y mu k tomuto ´uˇcelu sdˇel´ı sv´e pˇr´ıstupov´e heslo. Pro trval´e nahl´ıˇzen´ı do z´aznam˚u mus´ı klient v IZIP oznaˇcit tohoto l´ekaˇre jako d˚uvˇern´eho, toto oznaˇcen´ı m˚uˇze pozdˇeji odebrat.
Pro lepˇs´ı spolupr´aci mezi l´ekaˇrsk´ym softwarem a IZIP byly zpˇr´ıstupnˇeny tˇri br´any u- moˇzˇnuj´ıc´ı vz´ajemnou komunikaci:
IZIGATE – pro pˇr´ıjem informac´ı do Zdravotn´ıch kn´ıˇzek, IZICHECK – pro ovˇeˇren´ı existence klienta v datab´azi IZIP,
IZIVIEW – pro snadn´e nahl´ıˇzen´ı do konkr´etn´ı Zdravotn´ı kn´ıˇzky klienta.
Komunikace je ˇr´ızena zabezpeˇcen´ym protokolem HTTPS a sest´av´a ze ˇctyˇr f´az´ı:
• ustaven´ı spojen´ı,
• odesl´an´ı HTTP poˇzadavku,
• obdrˇzen´ı odezvy,
• ukonˇcen´ı spojen´ı.
Obsahem HTTP poˇzadavku jsou pˇr´ıstupov´e ´udaje k IZIP (identifikace uˇzivatele, pˇr´ıstu- pov´e heslo) a data ve form´atu XML, kter´y je podle [16] kompatibiln´ı s Datov´ym standardem Ministerstva zdravotnictv´ı ˇCR verze 03.01.01 (viz [18]).
Obsahem obdrˇzen´e odezvy jsou rovnˇeˇz data ve form´atu XML, v´yjimkou je zad´an´ı ˇspatn´eho uˇzivatelsk´eho jm´ena ˇci hesla resp. nesplnˇen´ı vstupn´ıch podm´ınek (napˇr. limit ve- likosti). V takov´em pˇr´ıpadˇe vrac´ı server HTTP odpovˇed’ s hlaviˇckou 400 resp. 403 a tˇelem obsahuj´ıc´ım text 40001 resp. 40301.
5.2.1 Komunikace s IZICHECK
Br´ana IZICHECK slouˇz´ı pro ovˇeˇren´ı existence klienta v datab´azi IZIP. Toto ovˇeˇren´ı by mˇelo pˇredch´azet vlastn´ımu odesl´an´ı dat na br´anu IZIGATE, ˇc´ımˇz se zamez´ı odesl´an´ı informac´ı o klientech, kteˇr´ı nemaj´ı svou Zdravotn´ı kn´ıˇzku.
Komunikace prob´ıh´a posl´an´ım dotazu s identifikaˇcn´ımi ˇc´ısly klient˚u, kteˇr´ı se maj´ı provˇe- ˇrit, ve form´atu XML, na kter´y br´ana odpov´ı identifikacemi klient˚u v syst´emu obsaˇzen´ymi.
Tak´e je moˇzn´e z´ıskat informace o poˇctu vyˇsetˇren´ı klienta proveden´ych odes´ılaj´ıc´ım zdravot- nick´ym pracovn´ıkem, jin´ymi nebo vˇsemi zdravotnick´ymi pracovn´ıky. Do odpovˇedi lze zahr- nout informaci o tom, zda si dan´y klient svou Zdravotn´ı kn´ıˇzku aktivoval.
5.2.2 Komunikace s IZIVIEW
Br´ana IZIVIEW byla vytvoˇrena pro rychl´e a snadn´e nahl´ıˇzen´ı do Zdravotn´ı kn´ıˇzky klient˚u IZIP z jin´eho zdravotnick´eho software. Od tohoto software se pˇredpokl´ad´a implementace IZICHECK v pln´em rozsahu a ve spojen´ı s IZIVIEW umoˇzn´ı efektivn´ı pr´aci s IZIP. Zdravotn´ı pracovn´ık z´ısk´a pˇrehled o nov´ych z´aznamech ve Zdravotn´ı kn´ıˇzce klienta a jej´ı otevˇren´ı bude realizov´ano jedin´ym stisknut´ım tlaˇc´ıtka.
Na br´anu IZIVIEW se tedy odes´ılaj´ı identifikaˇcn´ı ´udaje zdravotnick´eho pracovn´ıka, informace o jeho zdravotn´ım software a identifikaˇcn´ı ´udaje pacienta, do jehoˇz Zdravotn´ı kn´ıˇzky hodl´a pracovn´ık nahl´ednout. IZIVIEW ˇz´adost zpracuje a v poˇzadavku vrac´ı HTML k´od WWW str´anky se Zdravotn´ı kn´ıˇzkou pacienta.
5.2.3 Komunikace s IZIGATE
Br´ana IZIGATE slouˇz´ı pro zas´ıl´an´ı informac´ı do Zdravotn´ıch kn´ıˇzek pacient˚u. Mezi tyto informace patˇr´ı anamn´eza, oˇckov´an´ı, pˇredepsan´e ˇci vydan´e l´eky, zpr´avy z ambulantn´ıho vyˇsetˇren´ı ˇci hospitalizace, urgentn´ı informace a v´ysledky laboratorn´ıch vyˇsetˇren´ı. N´asleduje struˇcn´y popis informac´ı, kter´e um´ı syst´em IZIP zobrazit:
• Z´aznam Anamn´eza je tvoˇren pouze textem, kter´y je moˇzn´e strukturovat dle vlastn´ıho uv´aˇzen´ı.
• Z´aznam Oˇckov´an´ı je tvoˇren urˇcen´ım data a ˇcasu aplikace a tˇremi textov´ymi popisy.
Prvn´ı popisuje typ oˇckov´an´ı, druh´y oˇckovac´ı l´atku (n´azev, ˇc´ıslo ˇsarˇze, podan´e mnoˇzstv´ı a m´ısto aplikace) a tˇret´ı, voliteln´y, je vyhrazen pro urˇcen´ı diagn´ozy.
• Z´aznam Ambulantn´ı vyˇsetˇren´ı se skl´ad´a z ˇc´asti Z´avˇer, zahrnuj´ıc´ı podstatn´e infor- mace o poskytnut´e p´eˇci a jej´ıch v´ysledc´ıch, voliteln´eho pole Diagn´oza, ud´avaj´ıc´ıho k´od diagn´ozy, a d´ale z pole Indikovan´a vyˇsetˇren´ı, pro specifikaci vyˇsetˇren´ı, o jejichˇz proveden´ı l´ekaˇr rozhodl, ale s´am je neprov´ad´ı, Terapie (mimo l´eky), pro popis ´udaj˚u o l´eˇcbˇe, kterou l´ekaˇr provedl nebo doporuˇcil (napˇr. oˇsetˇren´ı r´any, proveden´a nebo doporuˇcen´a punkce, doporuˇcen´a dieta apod.) a L´eky, pro zaznamen´an´ı pˇredepsan´ych l´eˇciv (zahrnuje n´azev l´eku/zdrav. prostˇredku, d´avkov´an´ı, poˇcet balen´ı/kus˚u a k´od l´eku/zdrav. prostˇredku). Posledn´ı pole je vyhrazeno pro libovoln´y dokument, kter´y lze pˇripojit jako pˇr´ılohu.
• K Urgentn´ım informac´ım maj´ı pˇr´ıstup mimo klientem vybran´e l´ekaˇre tak´e l´ekaˇri rychl´e z´achrann´e sluˇzby. Urgentn´ı informace sest´avaj´ı z pol´ı Alergie, Krevn´ı skupina, Rizikov´e faktory, Trval´a medikace a Datum posledn´ıho oˇckov´an´ı tetanu.
• Z´aznam Hospitalizace je velmi podobn´y z´aznamu Ambulantn´ı vyˇsetˇren´ı. Obsahuje nav´ıc pouze pole pro zad´an´ı k´od˚u vedlejˇs´ıch diagn´oz.
Syst´em IZIP umoˇzˇnuje pˇr´ıjem dat zas´ılan´ych v XML souborech podl´ehaj´ıc´ıch standardu MZ ˇCR 03.01.01 bud’to ve form´atu
”vˇse v jednom“, kdy jsou vˇsechny z´aznamy vloˇzeny do jednoho souboru, nebo form´atu
”kaˇzd´y zvl´aˇst’“, kdy je kaˇzd´y z´aznam v samostatn´em souboru.
Pˇri zjiˇstˇen´ı chyby v souboru s v´ıce z´aznamy je zpracov´an´ı tohoto souboru pˇreruˇseno a vˇsechny doposud naˇcten´e z´aznamy jsou odm´ıtnuty.
Zas´ılan´a data mus´ı respektovat limity na velikost. Tyto limity jsou:
• velikost kaˇzd´eho jednotliv´eho souboru nesm´ı pˇres´ahnout 2MB,
• celkov´a velikost kolekce POST nesm´ı pˇres´ahnout 8MB.
5.2.4 Bezpeˇcnost informac´ı v IZIP
N´asleduj´ıc´ı text vych´az´ı z [15]. Bezpeˇcnost syst´emu IZIP lze rozdˇelit do tˇr´ı ´urovn´ı:
Bezpeˇcnost na ´urovni pacienta a l´ekaˇre
• Zdravotn´ı kn´ıˇzka patˇr´ı pacientovi a pouze on rozhoduje o tom, kter´ym l´ekaˇr˚um ji zpˇr´ıstupn´ı. Bez souhlasu pacienta nem˚uˇze z´aznamy v kn´ıˇzce nikdo prohl´ıˇzet (v´yjimkou je tzv. emergentn´ı pˇr´ıstup, kter´y umoˇzˇnuje ˇc´ıst urgentn´ı informace z pacientovy kn´ıˇzky).
• Pokud chce pacient v kn´ıˇzce ˇc´ıst, mus´ı zadat sv´e pˇr´ıstupov´e ´udaje, tj. identifikaˇcn´ı ˇc´ıslo (s jeho svolen´ım je to rodn´e ˇc´ıslo) a heslo, kter´e je mu zasl´ano v doporuˇcen´em dopise do vlastn´ıch rukou. M˚uˇze zadat i osobn´ı heslo, kter´e si m˚uˇze nav´ıc s´am vytvoˇrit.
• Pˇr´ıstupov´a hesla generuje program zcela n´ahodnˇe, ˇz´adn´y z pracovn´ık˚u spoleˇcnosti IZIP nem´a moˇznost je zjistit. Heslo se vytiskne a zabal´ı do zvl´aˇstn´ı ob´alky, podobnˇe jako PIN u bankovn´ıch karet. Tato ob´alka je zasl´ana klientovi doporuˇcenˇe do vlastn´ıch rukou. Klient m´a vˇzdy moˇznost poˇz´adat o zmˇenu hesla.
• Pokud se do kn´ıˇzky sv´eho pacienta chce pod´ıvat l´ekaˇr, mus´ı zadat sv´e pˇr´ıstupov´e
´ udaje.
• Nahl´ıˇzet do z´aznam˚u pacienta mohou jen ti l´ekaˇri, kter´ym to pacient umoˇzn´ı, tj.
kter´ym udˇel´ı opr´avnˇen´ı k pˇr´ıstupu. Pokud pacient neudˇel´ı l´ekaˇri opr´avnˇen´ı, nem˚uˇze l´ekaˇr v pacientovˇe kn´ıˇzce ˇc´ıst. Sv´e z´avˇery z vyˇsetˇren´ı m˚uˇze pˇresto do IZIP zapsat.
Bezpeˇcnost na ´urovni softwaru, poˇc´ıtaˇcov´eho vybaven´ı a zaˇr´ızen´ı
• Syst´em IZIP vyuˇz´ıv´a nejmodernˇejˇs´ı technologick´e prostˇredky proti zneuˇzit´ı dat.
• Zdravotnick´a data a jejich pˇrenos jsou zabezpeˇceny na stejn´ych principech, jako jsou zajiˇst’ov´any internetov´e bankovn´ı operace.
• Po zad´an´ı pˇrihlaˇsovac´ıch ´udaj˚u prob´ıh´a autentizace a autorizace (zjiˇstˇen´ı a ovˇeˇren´ı) poˇzadavku na pˇr´ıstup k dat˚um.
• Server zkontroluje, zda uˇzivatel, kter´y se pˇrihlaˇsuje, splˇnuje vˇsechny podm´ınky pro to, aby mohl v kn´ıˇzce ˇc´ıst nebo do n´ı zapisovat.
• Pokud tomu tak je, server zpˇr´ıstupn´ı uˇzivateli (l´ekaˇri nebo pacientovi) ty z´aznamy, ke kter´ym m´a dle sv´eho opr´avnˇen´ı pˇr´ıstup.
• Pokud uˇzivatel provede v´ıce chybn´ych pˇrihl´aˇsen´ı, je jeho pˇr´ıstup zablokov´an a je nutn´e kontaktovat administr´atory spoleˇcnosti IZIP.
• Firewally jsou jedn´ım z mnoha pouˇzit´ych bezpeˇcnostn´ıch zaˇr´ızen´ı. Zabraˇnuj´ı neop- r´avnˇen´ym pˇr´ıstup˚um a hl´ıdaj´ı pokusy o pr˚unik do syst´emu.
• Administr´atoˇri spoleˇcnosti IZIP kontroluj´ı, zda jsou servery v poˇr´adku, vyhodnocuj´ı pˇr´ıstupy a v pˇr´ıpadˇe potˇreby podnikaj´ı kroky k zabr´anˇen´ı neopr´avnˇen´ym pˇr´ıstup˚um.
• S vlastn´ı datab´az´ı pracuj´ı pouze jej´ı administr´atoˇri, kteˇr´ı pracuj´ı v oddˇelen´em patˇre s elektronicky zajiˇstˇen´ym vstupem. Jedn´a se o opr´avnˇen´e a speci´alnˇe vyˇskolen´e osoby.
• Data na vlastn´ım serveru jsou zaˇsifrov´ana.
Bezpeˇcnost na ´urovni fyzick´eho uloˇzen´ı server˚u s daty
• Servery jsou uloˇzeny na bezpeˇcn´em m´ıstˇe v podzem´ı a jsou fyzicky hl´ıd´any 24 hodin dennˇe.
• Pˇr´ıstup k tˇemto server˚um maj´ı pouze opr´avnˇen´e osoby, kter´e mus´ı vˇzdy doprov´azet povˇeˇren´y pracovn´ık spoleˇcnosti IZIP.
• Kaˇzd´y z nich m´a jeden bezpeˇcnostn´ı kl´ıˇc k opanc´eˇrovan´ym protipoˇz´arn´ım dveˇr´ım.
K jejich otevˇren´ı je potˇreba pouˇz´ıt oba kl´ıˇce z´aroveˇn.
5.3 Rizika a slab´ a m´ısta projekt˚ u zaloˇ zen´ ych na IZIP
Pro nastudov´an´ı problematiky bezpeˇcnosti informaˇcn´ıch syst´em˚u jsem pouˇzil [14], ze kter´e zde odcituji definice z´akladn´ıch bezpeˇcnostn´ıch pojm˚u:
Zraniteln´e (slab´e) m´ısto je slabina v informaˇcn´ım syst´emu, kter´a je vyuˇziteln´a ke zp˚u- soben´ı ˇskod. Existence tˇechto m´ıst je d˚usledkem chyb v anal´yze, n´avrhu a/nebo v im- plementaci, sloˇzitosti softwaru, existence skryt´ych kan´al˚u pro pˇrenos informace jinou neˇz zam´yˇslenou cestou a podobnˇe.
Riziko je tvoˇreno kombinac´ı slab´eho m´ısta a bezpeˇcnostn´ı hrozby.
Hrozbou oznaˇcujeme moˇznost vyuˇzitkovat zraniteln´e m´ısto IS k ´utoku na nˇej – ke zp˚uso- ben´ı ˇskody na aktivech. Hrozby mohou b´yt:
1. ne´umysln´e – ˇziveln´e ud´alosti, poruchy zaˇr´ızen´ı, chyby v software, selh´an´ı osob, 2. ´umysln´e – kr´adeˇz HW, ´umysln´e poˇskozen´ı zaˇr´ızen´ı, kr´adeˇz dat, kr´adeˇz SW,
neopr´avnˇen´a manipulace s daty.
Bezpeˇcnost´ı rozum´ıme ochranu informaˇcn´ıch syst´em˚u a informac´ı, kter´e jsou v nich ucho- v´av´any, zpracov´av´any a pˇren´aˇseny. V soudob´em ch´ap´an´ı bezpeˇcnosti IT je bezpeˇcnost d´ana zajiˇstˇen´ım:
d˚uvˇernosti – ochrana proti neopr´avnˇen´emu prozrazen´ı informace,
integrity a autenticity – ochrana proti neopr´avnˇen´e modifikaci informace,
dostupnosti – ochrana proti neopr´avnˇen´emu odepˇren´ı pˇr´ıstupu k dat˚um nebo sluˇz- b´am.
V syst´emech zaloˇzen´ych na IZIP jsou uloˇzena d˚uvˇern´a data (data pacient˚u). Mus´ıme tedy zajistit jejich ochranu proti neautorizovan´emu ˇcten´ı (zabezpeˇcit pˇr´ıstup k dat˚um pouze autorizovan´ymi subjekty, zajistit komunikaci se syst´emem IZIP proti odposlechu), proti neautorizovan´e modifikaci (modifikovat data mohou pouze autorizovan´e subjekty) a v posledn´ı ˇradˇe mus´ıme zajistit, aby k dat˚um mˇeli pˇr´ıstup vˇsechny autorizovan´e subjekty.
5.4 Komunikace s pojiˇst’ovnou
Podle [4] jsou osoby, kter´e maj´ı trval´y pobyt na ´uzem´ı ˇCesk´e republiky, a osoby, kter´e na
´
uzem´ı ˇCesk´e republiky trval´y pobyt nemaj´ı, ale jsou zamˇestnanci zamˇestnavatele, kter´y m´a s´ıdlo na ´uzem´ı ˇCesk´e republiky, zdravotnˇe pojiˇstˇeny u nˇekter´e zdravotn´ı pojiˇst’ovny.
Podle ˇc´ıseln´ıku VZP verze 640 (platnost od 1. 10. 2007–31. 12. 2007) (viz [27]) je v ˇCesk´e republice jeden´act zdravotn´ıch pojiˇst’oven. Jejich seznam je v tabulce 5.1.
K´od N´azev
111 Vˇseobecn´a zdravotn´ı pojiˇst’ovna ˇCR 201 Vojensk´a zdravotn´ı pojiˇst’ovna ˇCR 205 Hutnick´a zamˇestnaneck´a pojiˇst’ovna
207 Oborov´a zdravotn´ı pojiˇst’ovna zamˇestnanc˚u bank a pojiˇst’oven 209 Zamˇestnaneck´a pojiˇst’ovna ˇSKODA
211 Zdravotn´ı pojiˇst’ovna Ministerstva vnitra ˇCR 212 Stavebn´ı zdravotn´ı pojiˇst’ovna
213 Rev´ırn´ı bratrsk´a pokladna
217 Zdravotn´ı pojiˇst’ovna METAL-ALIANCE 222 Cesk´a n´arodn´ı zdravotn´ı pojiˇst’ovnaˇ 333 Pojiˇst’ovna VZP, a.s.
Tabulka 5.1: Seznam zdravotn´ıch pojiˇst’oven
Pojiˇst’ovna 333 – Pojiˇst’ovna VZP, a.s. je dceˇrinou spoleˇcnost´ı Vˇseobecn´e zdravotn´ı pojiˇst’ovny ˇCR a poskytuje zdravotn´ı pojiˇstˇen´ı pouze pro cizince.
Pojiˇst’ovna 212 – Stavebn´ı zdravotn´ı pojiˇst’ovna byla slouˇcena s pojiˇst’ovnou 207, kter´a se nyn´ı jmenuje Oborov´a zdravotn´ı pojiˇst’ovna zamˇestnanc˚u bank, pojiˇst’oven a stavebnictv´ı.
N´aplˇn komunikace mezi l´ekaˇrem a pojiˇst’ovnou tvoˇr´ı napˇr. vykazov´an´ı poskytnut´e zdra- votn´ı p´eˇce, zas´ıl´an´ı faktur za poskytnutou p´eˇci, ovˇeˇrov´an´ı zdravotn´ı pojiˇst’ovny pacienta, ovˇeˇrov´an´ı registrace pacienta k oˇsetˇruj´ıc´ımu l´ekaˇri.
Komunikace m˚uˇze prob´ıhat tˇemito zp˚usoby: p´ısemnˇe nebo elektronicky, a to elektron- ickou poˇstou, port´alem nebo pomoc´ı datov´eho nosiˇce.
5.4.1 P´ısemn´a komunikace
Dneˇsn´ım trendem je omezov´an´ı p´ısemn´e komunikace. Nˇekter´e sluˇzby poskytuje pojiˇst’ovna dokonce pouze elektronicky (napˇr. pod´a-li si praktick´y l´ekaˇr s kapitaˇcn´ı platbou p´ısemnou
ˇz´adost na seznam registrovan´ych pacient˚u z d˚uvodu provˇeˇren´ı registrace pojiˇstˇence u tohoto l´ekaˇre, je mu odpovˇed’ doruˇcena pouze na datov´em nosiˇci).
Z [25] plyne, ˇze pro p´ısemnou komunikaci s pojiˇst’ovnou se uˇz´ıvaj´ı pˇredepsan´e tiskopisy nebo poˇc´ıtaˇcem tiˇstˇen´e v´ystupy, jejichˇz datov´y obsah a form´aln´ı ˇclenˇen´ı odpov´ıd´a pˇr´ısluˇs- n´emu pˇredepsan´emu tiskopisu. Nˇekter´e tiskopisy lze nal´ezt na str´ank´ach pojiˇst’ovny (viz [26]), jin´e poch´azej´ı z nakladatelstv´ı SEVT.
5.4.2 Elektronick´a komunikace
Elektronick´a komunikace podl´eh´a datov´emu rozhran´ı, toto rozhran´ı je pro vˇsechny pojiˇst’ov- ny ˇCR stejn´e. Jeho popis lze nal´ezt v [24]. Data pˇred´avan´a pˇres toto rozhran´ı jsou tvoˇrena ASCII soubory, kter´e jsou sloˇzeny z vˇet r˚uzn´ych typ˚u a pro jejichˇz skladbu jsou definov´ana pravidla. Jednotliv´e vˇety jsou oddˇeleny znakem pro nov´y ˇr´adek a jsou tvoˇreny hodnotami atribut˚u rozliˇsen´ymi oddˇelovaˇci.
Je-li elektronick´a komunikace uskuteˇcnˇena pomoc´ı datov´eho nosiˇce, je k tomuto nosiˇci pˇripojen formul´aˇr Pr˚uvodn´ı list datov´eho nosiˇce, na kter´em je raz´ıtko a podpis odes´ılatele.
Pˇri elektronick´e komunikaci pomoc´ı elektronick´e poˇsty je nutn´e opatˇrit zpr´avu zaruˇce- n´ym elektronick´ym podpisem (podpisem zaloˇzen´ym na kvalifikovan´em certifik´atu).
Kvalifikovan´y certifik´at – certifik´at, kter´y m´a n´aleˇzitosti stanoven´e z´akonem o elektroni- ck´em podpisu a byl vyd´an poskytovatelem certifikaˇcn´ıch sluˇzeb splˇnuj´ıc´ım podm´ınky stanoven´e t´ımto z´akonem pro poskytovatele certifikaˇcn´ıch sluˇzeb vyd´avaj´ıc´ı kvalifiko- van´e certifik´aty. (pˇrevzato z [3])
Pro komunikaci prostˇrednictv´ım posledn´ı moˇznosti elektronick´e komunikace – port´alo- v´ym ˇreˇsen´ım – je potˇreba vlastnit dva certifik´aty:
1. komerˇcn´ı – pro ovˇeˇren´ı totoˇznosti uˇzivatele pˇri pˇrihlaˇsov´an´ı k Port´alu a pro ˇsifrov´an´ı jeho spojen´ı s Port´alem.
2. kvalifikovan´y – pro elektronick´e podepisov´an´ı dat zas´ılan´ych pˇres port´al.
Moment´alnˇe se toleruje vlastnictv´ı pouze jednoho z tˇechto certifik´at˚u. Port´al neumoˇzˇnuje komunikaci se vˇsemi pojiˇst’ovnami v ˇCR. Nˇekter´e pojiˇst’ovny port´al nemaj´ı v˚ubec, jin´e maj´ı sv˚uj vlastn´ı. Souˇcasnou situaci vystihuje tabulka 5.2.
K´od Port´al
111
201
205
207
209
211
213
217
222
Tabulka 5.2: Seznam port´al˚u zdravotn´ıch pojiˇst’oven
Jak je patrn´e z tabulky 5.2, ˇsest pojiˇst’oven (201, 207, 209, 213, 217, 222) sd´ıl´ı jedin´y port´al. K tomuto port´alu je tak´e zdarma poskytov´ana knihovna, kter´a umoˇzˇnuje komunikaci mezi l´ekaˇrsk´ym softwarem a t´ımto port´alem, demonstraˇcn´ı aplikace a dokumentace (viz [7]).
Nˇekter´e ze sluˇzeb nab´ızen´ych poskytovatel˚um p´eˇce port´aly pojiˇst’oven:
• ovˇeˇren´ı aktu´aln´ı registrace pojiˇstˇence u zdravotn´ı pojiˇst’ovny
• vyhled´an´ı zdravotnick´eho zaˇr´ızen´ı ve smluvn´ım vztahu k pojiˇst’ovnˇe
• vyhled´an´ı informace o registraci pojiˇstˇence u jeho oˇsetˇruj´ıc´ıho l´ekaˇre
• zas´ıl´an´ı faktur za poskytnutou zdravotn´ı p´eˇci
• pˇred´av´an´ı soubor˚u vy´uˇctov´an´ı zdravotn´ı p´eˇce poskytnut´e pojiˇstˇenc˚um
• elektronick´a podatelna
Kapitola 6
Ambulantn´ı informaˇ cn´ı syst´ em komunikuj´ıc´ı s IZIP
6.1 Anal´ yza poˇ zadavk˚ u
Ambulantn´ı informaˇcn´ı syst´em komunikuj´ıc´ı se syst´emem IZIP by mˇel obsahovat minim´alnˇe takov´e funkce, aby byl schopen do syst´emu IZIP odeslat vˇsechny typy dat, kter´e je tento syst´em schopen zpracovat, a z´aroveˇn by tento ´ukon mˇel uˇzivateli co nejv´ıce usnadnit.
Odes´ıl´an´ı z´aznam˚u do IZIP je tedy hlavn´ı funkc´ı tohoto syst´emu. Dalˇs´ı funkce se budou od t´eto hlavn´ı funkce odv´ıjet:
• Odes´ıl´ame-li data pacient˚u, mus´ıme v syst´emu m´ıt funkce pro spr´avu pacient˚u (funkce kartot´eky).
• Vlastn´ımu odesl´an´ı dat do syst´emu IZIP by mˇela pˇredch´azet kontrola aktivity zdra- votn´ı kn´ıˇzky pacienta (funkce IZICHECK).
• Odes´ıl´ame-li data do IZIP, chceme si tak´e zobrazit data od jin´ych l´ekaˇr˚u (funkce IZIVIEW).
• Abychom mohli z´aznamy odeslat, mus´ıme nˇejak´e m´ıt:
– z´apis anamn´ezy pacienta,
– zaps´an´ı urgentn´ıch informac´ı o pacientovi, – zaps´an´ı oˇckov´an´ı pacienta,
– zaps´an´ı zpr´avy z ambulantn´ıho vyˇsetˇren´ı,
– zaps´an´ı zpr´avy z hospitalizace (pokud pracoviˇstˇe tuto sluˇzbu prov´ad´ı), – zaps´an´ı pˇrechodn´e/trval´e novˇe indikovan´e diagn´ozy.
Z tˇechto funkˇcn´ıch poˇzadavk˚u lze sestrojit diagram pˇr´ıpad˚u uˇzit´ı (viz obr´azek 6.1).
Nˇekter´e z v´yˇse jmenovan´ych funkc´ı v sobˇe zahrnuj´ı dalˇs´ı funkce, jako napˇr´ıklad Zaps´an´ı zpr´avy z ambulantn´ıho vyˇsetˇren´ı, jehoˇz souˇc´ast´ı m˚uˇze b´yt stanoven´ı nov´e diagn´ozy, pˇrede- ps´an´ı l´eˇciv, indikace vyˇsetˇren´ı ˇci terapie.
lékař sepsání záznamu
otevření Zdravotní knížky IZIP
odeslání dat do IZIPu zapsání očkování
zapsání anamnézy
<<Include>>
<<Include>>
zapsání zprávy z ambulantního vyšetření
zaznamenání urgentních informací
<<Include>>
<<Include>>
zapsání zprávy z hospitalizace
<<Include>>
Obr´azek 6.1: Diagram pˇr´ıpadu uˇzit´ı syst´emu komunikuj´ıc´ıho s IZIP
6.1.1 Poˇzadavky obecnˇe
Z pohledu l´ekaˇre je ale hlavn´ım poˇzadavkem na ambulantn´ı informaˇcn´ı syst´em v´ykaznictv´ı a n´asledn´e vy´uˇctov´an´ı p´eˇce. Pro znaˇcnou ˇcasovou n´aroˇcnost pr´ace na v´yˇse vyjmenovan´ych pˇr´ıpadech uˇzit´ı ambulantn´ıho informaˇcn´ıho syst´emu komunikuj´ıc´ıho s IZIP a tak´e rozs´ahlost a komplikovanost v´ykaznictv´ı a vy´uˇctov´an´ı l´ekaˇrsk´e p´eˇce, byla tato problematika zaˇrazena aˇz do dalˇs´ıch iterac´ı pr´ace na projektu.
Mezi dalˇs´ı poˇzadavky patˇr´ı podpora pro vyplˇnov´an´ı tiskopis˚u (l´azeˇnsk´a p´eˇce, v´ypisy ze zdravotn´ı dokumentace, hl´aˇsen´ı ´uraz˚u, tiskopisy ˇCesk´e spr´avy soci´aln´ıho zabezpeˇcen´e, ˇz´adanky a dalˇs´ı), veden´ı dispenz´arn´ı p´eˇce pacient˚u a dalˇs´ı.
V posledn´ı dobˇe je velk´y d˚uraz kladen tak´e na import a export dat. Mnohdy je l´ekaˇr se sv´ym dosavadn´ım syst´emem nespokojen a chce pˇrej´ıt na jin´y.
Dalˇs´ı hodnotn´e poˇzadavky na ambulantn´ı informaˇcn´ı syst´em lze z´ıskat z publikace [23].
Pˇri anal´yze ambulantn´ıho informaˇcn´ıho syst´emu jsem spolupracoval s nˇekolika prak- tick´ymi l´ekaˇri pro dospˇel´e, kter´e jsem situoval do role zadavatel˚u fiktivn´ıho projektu. Pokusil jsem se tedy analyzovat a navrhnout informaˇcn´ı syst´em pro potˇreby praktick´ych l´ekaˇr˚u.
V ´uvodu pr´ace na projektu jsem provˇeˇroval moˇznost vyv´ıjet syst´em pro v´ıce odbornost´ı, avˇsak n´avrh takov´ehoto syst´emu se velmi zkomplikoval, nebot’ potˇreby jednotliv´ych odbor- nost´ı jsou velmi rozmanit´e a mohou b´yt i navz´ajem disjunktn´ı.
Kapitola 7
N´ avrh ambulantn´ıho informaˇ cn´ıho syst´ emu komunikuj´ıc´ıho s IZIP
Na z´akladˇe v´ysledk˚u anal´yzy jsem navrhl ambulantn´ı syst´em. Syst´em jsem koncipoval jako v´ıceuˇzivatelsk´y s pˇr´ıstupem tˇr´ı r˚uzn´ych typ˚u akt´er˚u, kteˇr´ı se liˇs´ı v uˇzit´ı syst´emu. Pˇri mode- lov´an´ı pˇr´ıpad˚u uˇzit´ı jsem zavedl jeˇstˇe ˇctvrt´eho akt´era (Uˇzivatel), kter´y je pouze abstraktn´ı a ostatn´ı akt´eˇri dˇed´ı jeho vlastnosti.
Data v datab´azi jsou z principu pˇr´ıstupn´a vˇsem – coˇz usnadn´ı pr´aci l´ekaˇr˚um v pˇr´ıpadˇe, ˇze pacient pˇrech´az´ı mezi jednotliv´ymi l´ekaˇri syst´emu nebo se jedn´a o z´astup l´ekaˇre. Pokud l´ekaˇri nebudou cht´ıt sd´ılet kartot´eku pacient˚u, lze tento pˇr´ıpad ˇreˇsit vlastn´ım datab´azov´ym souborem pro kaˇzd´eho l´ekaˇre, nebo specifikov´an´ım pˇr´ıstupov´ych pr´av (l´ekaˇr by smˇel nahl´ıˇzet do z´aznam˚u pouze sv´ych registrovan´ych pacient˚u).
Aby se zabr´anilo neopr´avnˇen´ym pˇr´ıstup˚um k dat˚um, budou v syst´emu specifikov´ana opr´avnˇen´ı jednotliv´ych uˇzivatelsk´ych skupin (pozdˇeji m˚uˇze b´yt rozˇs´ıˇreno i na jednotliv´e uˇzivatele) pro spouˇstˇen´ı jednotliv´ych pˇr´ıpad˚u uˇzit´ı.
Diagram s akt´ery syst´emu je zn´azornˇen na obr´azku 7.1.
sestra správce
uživatel
lékař
Obr´azek 7.1: Akt´eˇri syst´emu
Pˇri n´avrhu syst´emu bylo pouˇzito modelovac´ıch technik UML. N´avrh prob´ıhal v tˇechto kroc´ıch:
• sestaven´ı prohl´aˇsen´ı o c´ılech,
• sestaven´ı poˇzadavk˚u na syst´em,
• sestaven´ı pˇr´ıpad˚u uˇzit´ı,
• popis pˇr´ıpadu uˇzit´ı,
• sestaven´ı sch´ematu datab´aze,
• popis sch´ematu datab´aze,
• n´avrh obrazovek syst´emu,
• n´avrh architektury syst´emu,
• n´avrh tˇr´ıd jednotliv´ych vrstev architektury.
V´ysledn´e dokumenty vˇsech f´az´ı lze nal´ezt v pˇr´ıloze.
7.1 Pˇr´ıpady uˇ zit´ı
Pˇri sestavov´an´ı pˇr´ıpad˚u uˇzit´ı byly pˇr´ıpady uˇzit´ı rozdˇeleny do ˇctyˇr iterac´ı. V prvn´ı iteraci jsou ty pˇr´ıpady uˇzit´ı, kter´e umoˇzn´ı z´apis tˇech dat do syst´emu, kter´a n´aslednˇe mohou b´yt odesl´ana do syst´emu IZIP. Tyto pˇr´ıpady uˇzit´ı budou implementov´any v r´amci t´eto diplomov´e pr´ace.
Ve druh´e iteraci jsou pˇr´ıpady uˇzit´ı pro spr´avu uˇzivatel˚u, spr´avu pacient˚u a r˚uzn´e admin- istraˇcn´ı ´ukoly l´ekaˇre. Tˇret´ı iterace zahrnuje vy´uˇctov´an´ı, posledn´ı iterace zahrnuje import a export dat, komunikaci s pojiˇst’ovnou a laboratoˇremi.
7.1.1 Pˇr´ıklady pˇr´ıpad˚u uˇzit´ı prvn´ı iterace
Pˇr´ıpad uˇzit´ı: Vyps´an´ı zdravotn´ıho z´aznamu (dekurzu)
ID: UC1I03
Struˇcn´y popis: Zaps´an´ı z´aznamu z n´avˇstˇevy pacienta v ordinaci, ˇci l´ekaˇre u pa- cienta.
Hlavn´ı akt´eˇri: l´ekaˇr Vedlejˇs´ı
akt´eˇri:
ˇz´adn´ı Vstupn´ı
podm´ınky:
otevˇren´a karta pacienta, pr´ava pro z´apis z´aznamu
Hlavn´ı sc´en´aˇr: Pˇr´ıpad uˇzit´ı je spuˇstˇen otevˇren´ım karty pacienta. Je tedy vˇzdy vytvoˇren nov´y z´aznam. Tento z´aznam je strukturovan´y a skl´ad´a se z dalˇs´ıch pˇripojen´ych dokument˚u. M´a-li pacient aktivovanou kn´ıˇzku v IZIP, oznaˇc´ı syst´em po jeho dokonˇcen´ı tento z´aznam jako nov´y z´aznam pro odesl´an´ı.
V´ystupn´ı podm´ınky:
nov´y z´aznam v kartˇe pacienta Alternativn´ı
sc´en´aˇre:
ˇz´adn´e
Pˇr´ıpad uˇzit´ı: Uprava identifikaˇcn´ıch ´´ udaj˚u pacienta
ID: UC1I05
Struˇcn´y popis: Oprava nˇekter´eho z identifikaˇcn´ıch ´udaj˚u pacienta z d˚uvodu zjiˇstˇen´ı chyby nebo zmˇeny
Hlavn´ı akt´eˇri: l´ekaˇr Vedlejˇs´ı
akt´eˇri:
ˇz´adn´ı Vstupn´ı
podm´ınky:
otevˇren´a karta pacienta, pr´ava pro zmˇenu ´udaj˚u
Hlavn´ı sc´en´aˇr: Pˇr´ıpad uˇzit´ı je spuˇstˇen zmˇenou nˇekter´eho z identifikaˇcn´ıch ´udaj˚u v kartˇe pacienta. Dokud je mˇenˇen´y ´udaj neplatn´y, syst´em ˇz´ad´a uˇzivatele, aby zadal platn´y ´udaj. Syst´em porovn´a novou hodnotu s p˚uvodn´ı, liˇs´ı-li se tyto hodnoty, pˇrid´a p˚uvodn´ı hodnotu do his- torie.
V´ystupn´ı podm´ınky:
Zmˇenˇen´y ´udaj u pacienta, nov´a hodnota v historii mˇenˇen´e.
Alternativn´ı sc´en´aˇre:
Neplatn´a hodnota mˇenˇen´eho identifikaˇcn´ıho ´udaje. Storno.
7.2 Datab´ aze
Pro uloˇzen´ı persistentn´ıch dat bude syst´emu slouˇzit datab´aze. S pˇrihl´ednut´ım ke sv´ym dosavadn´ım zkuˇsenostem a nab´ıdce datab´azov´ych syst´em˚u jsem zvolil datab´azi relaˇcn´ı.
7.2.1 Konceptu´aln´ı sch´ema datab´aze
Na obr´azku 7.2 je zobrazen ER diagram navrhovan´eho syst´emu, jehoˇz popis n´asleduje.
Se syst´emem budou pracovat tˇri skupiny uˇzivatel˚u:
• skupinaspr´avce, jej´ımˇz hlavn´ım ´ukolem bude nastavov´an´ı vlastnost´ı syst´emu a servisn´ı z´asahy,
• skupinasestra, kter´a bude m´ıt omezen´y pˇr´ıstup k vykon´av´an´ı nˇekter´ych akc´ı a hlavn´ım
´
ukolem t´eto skupiny bude nahl´ıˇzen´ı do zdravotn´ıch z´aznam˚u pacient˚u,
• skupinal´ekaˇr, kter´a je hlavn´ı uˇzivatelskou skupinou.
Uˇzivatelsk´e skupiny spr´avce a sestra budou modelov´any entitou Uˇzivatel a budou ro- zliˇseny pomoc´ı atributu urole. Uˇzivatelsk´a skupina l´ekaˇr bude modelov´ana pomoc´ı entity L´ekaˇr a to z toho d˚uvodu, ˇze k n´ı potˇrebujeme namodelovat mnohem v´ıce atribut˚u, neˇz k ostatn´ım skupin´am. Mezi entitamiL´ekaˇr aUˇzivatel je vztah specializace (atributy, kter´e m´a entitaUˇzivatel, m´a tak´e entitaL´ekaˇr).
Syst´em bude obsahovat zdravotn´ı z´aznamy pacient˚u – entitaPacient. Kaˇzd´y pacient m´a identifikaˇcn´ı ´udaje, jejichˇz zmˇeny chceme v syst´emu tak´e zachytit, entita Historie, a tak´e m˚uˇze pob´yvat na v´ıce adres´ach (napˇr. nemocn´a babiˇcka se doˇcasnˇe pˇrestˇehuje ke sv´ym dˇetem), coˇz namodelujeme entitouAdresa.
Mezi entitamiL´ekaˇraPacient je vztah typu M:N s atributemRegistrace. Kaˇzd´y z l´ekaˇr˚u bude registrovat pacienty. Pacient sm´ı b´yt registrov´an maxim´alnˇe u jednoho l´ekaˇre. Tohoto l´ekaˇre m˚uˇze ˇcasem zmˇenit (atributRegistrace bude obsahovat ˇcasov´y z´aznam). Proto vztah M:N.
je k zastižení pat íř
je podepsán zapsal
je popsán popisuje
obsahuje
náleží náleží
obsahuje
náleží
obsahuje náleží
obsahuje
náleží náleží
je popsán
popisuje je specifický
pat íř má
náleží
má
náleží registruje
je registrován Pacient
idPacient <pk>
Historie
idZmena <pk>
Adresa
idAdresa <pk>
Rizika
Anamnéza Lékař
Uživatel
idUzivatel <pk>
Záznam
idZaznam <pk>
Dekurz
idDekurz <pk>
Tlak - pulz Výška - váha
Sedimentace P edpis na lékř Zpráva P ílohař
O kováníč
Trvalá diagnóza Registrace
idTrvalaDiagnoza <pk>
Obr´azek 7.2: ER diagram syst´emu
Hlavn´ım zdravotn´ım z´aznamem je dekurz (entita Dekurz). Dekurz se skl´ad´a z jed- notliv´ych z´apis˚u z n´avˇstˇev pacienta u l´ekaˇre. Dekurz je v´ıcem´enˇe strukturovan´y text, skl´ad´a se z data proveden´ı z´aznamu a z´apis˚u jednotliv´ych proveden´ych v´ykon˚u. M˚uˇze obsahovat tak´e z´avˇer a doporuˇcen´ı pro dalˇs´ı postup. EntitaZ´aznampˇredstavuje proveden´y v´ykon. Spe- cializuje se na entityOˇckov´an´ı,Pˇredpis na l´ek a dalˇs´ı (avˇsak pouze ty, kter´e jsou zahrnuty do prvn´ı iterace).
Entity Anamn´eza a Rizika se pˇr´ımo nevztahuj´ı k dekurzu (jsou v kartˇe zaps´any nˇekde na dobˇre viditeln´em m´ıstˇe a vyskytuj´ı se pouze v jednom exempl´aˇri). Ale protoˇze jsou to tak´e formy zdravotn´ıho z´apisu, jsou modelov´any jako specializace Z´aznamu. Tyto entity nejsou modelov´any jako atributy pacienta proto, aby bylo moˇzn´e zobrazit jejich jednotliv´e verze, kter´e byly odesl´any do syst´emu IZIP.
Kaˇzd´y z´aznam v dekurzu mus´ı b´yt podeps´an l´ekaˇrem, kter´y jej provedl, proto je mezi entitamiDekurz a L´ekaˇr vztahzapsal.
7.2.2 Sch´ema datab´aze
Na obr´azku 7.3 je zjednoduˇsen´e sch´ema relaˇcn´ı datab´aze. Pln´e sch´ema i s popisem je moˇzn´e nal´ezt v pˇr´ıloze.
Pacient
Pojistovna
Dekurz
VyskaVaha TlakPulz
Sedimentace
PredpisLek Lekar
Banka
Lek
Diagnoza
Registrace
Uzivatel
Ockovani Rizika Anamneza Pacient_TrvalaDiagnoza
ZaznamIZIP
Zprava Pacient_Rodina
VerzeCiselniku
LOCTO RodinnyStav
StatniPrislusnost
Adresa
Prilohy
PSC Pacient_Historie
Obr´azek 7.3: Zjednoduˇsen´e sch´ema datab´aze
Tabulka Data pro IZIP slouˇz´ı pro ukl´ad´an´ı identifik´ator˚u z´aznam˚u, kter´e byly/ budou odesl´any do IZIP. Ke kaˇzd´emu z´aznamu je uchov´av´an tak´e jeho typ (pro rychl´e vyhled´an´ı), stav odesl´an´ı (byl odesl´an/ bude odesl´an/ typ nalezen´e chyby) a datum odesl´an´ı. Tabulka Data pro IZIP m´a vztah s tabulkou L´ekaˇr, d´ıky kter´emu je urˇceno, kter´y l´ekaˇr data do IZIP odes´ıl´a (jedn´a se vlastnˇe o duplicitn´ı informaci, kter´a byla zaˇrazena pro rychlejˇs´ı v´ybˇer z´aznam˚u z fronty jejich zapisovatelem).
7.3 Architektura syst´ emu
Jako architekturu syst´emu jsem zvolil Model–View–Controller, kter´a rozdˇeluje datov´y model aplikace, uˇzivatelsk´e rozhran´ı a ˇr´ıdic´ı logiku do tˇr´ı nez´avisl´ych komponent tak, ˇze modifikace nˇekter´e z nich m´a minim´aln´ı vliv na ostatn´ı (pˇrevzato z [5]).
Tato architektura se skl´ad´a z:
Model – dom´enovˇe specifick´a reprezentace informac´ı, s nimiˇz aplikace pracuje,
Controller – reaguje na ud´alosti (typicky poch´azej´ıc´ı od uˇzivatele) a zajiˇst’uje zmˇeny
v modelu nebo v pohledu,
View – pˇrev´ad´ı data reprezentovan´a modelem do podoby vhodn´e k interaktivn´ı prezentaci uˇzivateli.
Vrstva View je tvoˇrena tˇr´ıdami reprezentuj´ıc´ımi dialogy zobrazovan´e uˇzivateli, vrstva Controller je tvoˇrena jedin´ym objektem (n´avrhov´y vzor Singleton), kter´y pˇrij´ım´a uˇzivatelsk´e ud´alosti a zabezpeˇcuje jejich vyˇr´ızen´ı Modelem, Model je tvoˇren pˇeti bal´ıˇcky (Pacienti, Uˇzivatel´e, ˇC´ıseln´ıky, Z´aznamy, Datab´aze). ´Ukoly jednotliv´ych bal´ıˇck˚u vypl´yvaj´ı z jejich n´azvu.
Bal´ıˇcek Datab´aze je opˇet tvoˇren jedin´ym objektem (n´avrhov´y vzor Singleton), kter´y se star´a o komunikaci s datab´az´ı.
V n´avrhu tˇr´ıd vrstvy Model jsem pouˇzil n´avrhov´ych vzor˚u. N´avrhov´e vzory poskytuj´ı ˇreˇsen´ı pro ˇcasto opakovan´e probl´emy, napˇr. probl´em proch´azen´ı sekvenˇcnˇe uspoˇr´adan´ych prvk˚u – n´avrhov´y vzor Iterator.
Mezi ˇcasto uˇzit´e vzory patˇr´ı:
Proxy pattern – vyuˇz´ıv´a se pˇri potˇrebˇe zajiˇstˇen´ı kontroly nad pˇr´ıstupem k jin´emu ob- jektu. V n´avrhu je konkr´etnˇe pouˇzit pro vytvoˇren´ı objektu aˇz v situaci, kdy je to opravdu potˇreba: napˇr. objekt tˇr´ıdy Pacient je sloˇzit´y, protoˇze obsahuje mnoho re- ferenc´ı na dalˇs´ı objekty. Tyto objekty nejsou pˇri vytv´aˇren´ı objektu tˇr´ıdy Pacient vytvoˇreny, ale vytvoˇr´ı se aˇz v situaci, kdy jsou potˇreba.
Singleton pattern – zajiˇst’uje existenci pouze jedin´eho objektu tˇr´ıdy v syst´emu.
Iterator pattern – ˇreˇs´ı probl´em proch´azen´ı sekvenˇcnˇe uspoˇr´adan´ych prvk˚u.
Facade pattern – zjednoduˇsuje vstupn´ı bod do syst´emu (bal´ıˇcku, komponenty). Sniˇzuje z´avislost tˇr´ıd mezi bal´ıˇcky, komponentami.
Factory pattern – rozhoduje za bˇehu programu o vytvoˇren´ı instance konkr´etn´ı tˇr´ıdy.
Pˇri studiu n´avrhov´ych vzor˚u jsem vych´azel z [10].
7.4 Bezpeˇ cnost
Navrˇzen´y informaˇcn´ı syst´em nedovoluje neopr´avnˇen´y pˇr´ıstup k informac´ım. Uˇzivatel´e sys- t´emu se mus´ı autentizovat, neautentizovan´ı uˇzivatel´e nemaj´ı k dat˚um v syst´emu ˇz´adn´y pˇr´ıstup. Ihned po ´uspˇeˇsn´e autentizaci jsou uˇzivatel˚um pˇredˇelena pr´ava k vykon´av´an´ı jed- notliv´ych pˇr´ıpad˚u uˇzit´ı = autorizace. Tato pr´ava lze modifikovat. T´ım, ˇze jsou uˇzivatel˚um pˇridˇelena pr´ava pro spouˇstˇen´ı jednotliv´ych pˇr´ıpad˚u uˇzit´ı, nem˚uˇze doch´azet k neautorizovan´e modifikaci informac´ı a z´aroveˇn se k dat˚um dostanou vˇsichni ti, kteˇr´ı k tomu maj´ı pr´ava.
Prvn´ı verze syst´emu bude komunikovat pouze se syst´emem IZIP a to zabezpeˇcen´ym protokolem HTTPS. Pro komunikaci bude uˇzit komunikaˇcn´ı modul IZIP, kter´y je dod´av´an pouze v bin´arn´ı podobnˇe. Proto nelze vylouˇcit pˇr´ıtomnost skryt´ych kan´al˚u a ze stejn´eho d˚uvodu nelze tuto komunikaci oznaˇcit za bezpeˇcnou. (Prob´ıh´a sice zabezpeˇcen´ym pro- tokolem, ale nelze potvrdit uˇzit´ı uˇzivatelova bezpeˇcnostn´ıho certifik´atu a vylouˇcit uˇzit´ı podvrˇzen´eho ´utoˇcn´ıkova.)
Data v datab´azi implementovan´eho syst´emu nebudou ˇsifrov´ana (kromˇe uˇzivatelsk´ych hesel, kter´a budou zahashov´ana funkc´ı SHA) a to z d˚uvodu sn´ıˇzen´ı propustnosti syst´emu a probl´emu s bezpeˇcn´ym ´uloˇziˇstˇem pro ˇsifrovac´ı kl´ıˇc. K datab´azov´emu serveru budou smˇet
pˇristupovat pouze klientsk´e programy, kter´e budou zn´at pˇr´ıstupov´e ´udaje (autentizace v da- tov´e vrstvˇe). Komunikace s datab´az´ı bude prob´ıhat pomoc´ı sd´ılen´e pamˇeti (pˇri uˇzit´ı embed- ded verze datab´aze) nebo pomoc´ı s´ıt’ov´eho protokolu datab´azov´eho serveru. Tento protokol nejsp´ıˇs nebude ˇsifrovan´y a proto by mˇelo b´yt zajiˇstˇeno ˇsifrov´an´ı t´eto komunikace pomoc´ı jin´eho protokolu (IPSec, SSL/TLS a podobnˇe). Zabezpeˇcen´ı fyzick´eho pˇr´ıstupu k datab´azi pak bude z´aviset na zabezpeˇcen´ı hostitelsk´eho stroje a jeho spr´avci.
Kapitola 8
Implementace
Architektura syst´emu je tedy, jak jiˇz bylo zm´ınˇeno v kapitole 7.3, typu Model–View–
Controller a obr´azek 8.1 ji zobrazuje pohledem aplikaˇcn´ıch tˇr´ıd. V n´asleduj´ıc´ıch kapitol´ach je pak probr´ana postupnˇe vrstvu po vrstvˇe.
Databáze
SpravceChyb
SpravcePrav frmHlavniOkno frmPacient frmUzivatel frmSeznamPacientu ...
Controller
ControllerIzip
SpravceZaznamu SpravceUzivatelu SpravcePacientu SpravceCiselniku System
Číselníky Pacienti
Uživatelé Záznamy
Databaze
Obr´azek 8.1: Architektura syst´emu z pohledu aplikaˇcn´ıch tˇr´ıd
8.1 Datab´ aze
Jak jiˇz bylo zm´ınˇeno v kapitole 7.2, vyuˇz´ıv´a syst´em pro ukl´ad´an´ı persistentn´ıch dat relaˇcn´ı datab´azi. V t´eto kapitole bude struˇcnˇe pops´ana jej´ı struktura.
Z´akladn´ı tabulky jsou:
ˇc´ıseln´ıkov´e tabulky – tabulky pro uloˇzen´ı ˇc´ıseln´ık˚u. V kaˇzd´e z tˇechto tabulek m˚uˇze b´yt uloˇzeno v´ıce verz´ı stejn´eho ˇc´ıseln´ıku, a proto obsahuj´ı ciz´ı kl´ıˇc do tabulkyVerzeCisel- niku, kter´y jednoznaˇcnˇe identifikuje verzi ˇc´ıseln´ıku.
Pacient – do t´eto tabulky jsou ukl´ad´any z´akladn´ı identifikaˇcn´ı ´udaje pacienta. Nen´ı zde adresa, protoˇze se v n´avrhu poˇc´ıt´a s moˇznost´ı uloˇzen´ı v´ıce adres jednoho pacienta (tabulkaPacient Adresy). Do datab´aze se tak´e ukl´adaj´ı zmˇeny v tˇechto identifikaˇcn´ıch
´
udaj´ıch (tabulkaPacient Historie), coˇz je zajiˇstˇeno datab´azov´ym triggerem, kter´y je spouˇstˇen pˇri kaˇzd´e operaci UPDATE nad touto tabulkou.
Rizika – tato tabulka slouˇz´ı k ukl´ad´an´ı urgentn´ıch informac´ı o pacientovi. Kaˇzd´y pacient m˚uˇze m´ıt maxim´alnˇe jeden platn´y ˇr´adek v t´eto tabulce. Protoˇze tato tabulka obsahuje z´aznamy, kter´e jsou odes´ıl´any do syst´emu IZIP, je pro tyto z´aznamy vyˇclenˇena zvl´aˇstn´ı tabulka (z d˚uvodu zpˇetn´eho zobrazen´ı jiˇz odeslan´ych z´aznam˚u). Obdobnˇe funguje i tabulka Anamneza.
Lekar – tato tabulka slouˇz´ı k ukl´ad´an´ı informac´ı o l´ekaˇri. Obsahuje tak´e pˇr´ıstupov´e ´udaje k syst´emu IZIP.
Uzivatel – do t´eto tabulky jsou ukl´ad´any vˇsechny ostatn´ı uˇzivatelsk´e ´uˇcty. K rozliˇsen´ı typu uˇzivatelsk´eho ´uˇctu je vyhrazen jeden sloupec.
Dekurz – tabulka pro ukl´ad´an´ı denn´ıch z´aznam˚u o n´avˇstˇevˇe pacienta. Na dekurz mohou b´yt nav´az´any dalˇs´ı z´aznamy jako oˇckov´an´ı, zpr´ava, pˇredpis na l´ek a dalˇs´ı.
tabulky pro pˇripojen´e z´aznamy – prim´arn´ı kl´ıˇce tˇechto tabulek jsou tvoˇreny hodno- tami, kter´e jsou v r´amci vˇsech tˇechto tabulek unik´atn´ı a obsahuj´ı ciz´ı kl´ıˇc do tabulky Dekurz, ke kter´emu se v´aˇzou.
8.1.1 Datov´e pohledy
Datab´aze obsahuje dva datov´e pohledy. Prvn´ı nad tabulkouPacient, kter´y slouˇz´ı pro vyh- led´av´an´ı pacient˚u podle jm´ena a pˇr´ıjmen´ı s ignorov´an´ım velikost´ı p´ısmen a interpunkˇcn´ıch znam´enek, a druh´y nad tabulkamiLekar a Uzivatel pro vyhled´av´an´ı uˇzivatele podle uˇziva- telsk´eho jm´ena a pro kontrolu unik´atnosti uˇzivatelsk´ych jmen.
8.1.2 Datab´azov´e procedury V datab´azi jsou pˇr´ıtomny tyto triggery:
• triggery zajiˇst’uj´ıc´ı pˇridˇelov´an´ı jedineˇcn´ych hodnot prim´arn´ım kl´ıˇc˚um,
• trigger zajiˇst’uj´ıc´ı naplˇnov´an´ı tabulky Pacient Historie (je spouˇstˇen po operaci UP- DATE nad tabulkou Pacient),
• triggery zajiˇst’uj´ıc´ı naplˇnov´an´ı tabulkyZaznamIZIP. Tyto triggery jsou spouˇstˇeny po operac´ıch INSERT nad tabulkami se z´aznamy a jejich ´ukolem je zkontrolovat, zda pacient, jehoˇz se z´aznamy t´ykaj´ı, m´a aktivn´ı Zdravotn´ı kn´ıˇzku IZIP a zda l´ekaˇr, kter´y z´apis z´aznamu provedl, je registrov´an v syst´emu IZIP. Pokud jsou obˇe tyto podm´ınky splnˇeny, pak je z´aznam pˇrid´an do fronty z´aznam˚u pro odesl´an´ı do syst´emu IZIP.
V datab´azi je tak´e procedura, kter´a zajiˇst’uje symetriˇcnost vztah˚u v tabulce Pribuzny.
Je-li pacient uveden jako pˇr´ıbuzn´y jin´eho pacienta, pak se tento pˇr´ıbuzensk´y vztah projev´ı i u tohoto pˇr´ıbuzn´eho.
8.2 Datov´ a vrstva
Datov´a vrstva ambulantn´ıho syst´emu je tvoˇrena relaˇcn´ı datab´az´ı Firebird (v´ıce informac´ı v kapitole 8.7.1). Pˇri implementaci byla vyuˇzita embedded verze, coˇz znamen´a, ˇze syst´em komunikuje s datab´az´ı pˇres sd´ılenou pamˇet’ (pomoc´ı vol´an´ı funkc´ı dynamicky linkovan´e knihovny).
Pˇrechod na jinou verzi datab´aze Firebird nen´ı nijak sloˇzit´y, staˇc´ı zamˇenit embedded knihovnu za s´ıt’ovou a syst´em bude komunikovat s datab´az´ı pˇres s´ıt’ov´e rozhran´ı. Datab´aze tak m˚uˇze b´yt sd´ılena v´ıce klienty.
Pro eliminaci pˇr´ım´e vazby syst´emu na konkr´etn´ı datab´azi byla do syst´emu pˇrid´ana abstraktn´ı datab´azov´a vrstva, kter´a odstiˇnuje datab´azov´e operace z´avisl´e na uˇzit´e datab´azi od vyˇsˇs´ıch vrstev. Syst´em tak m˚uˇze b´yt pˇrenesen na jinou datab´azi, pˇriˇcemˇz staˇc´ı pˇrepsat pouze tuto abstraktn´ı datab´azovou vrstvu.
Abstraktn´ı datab´azov´a vrstva je implementov´ana ve tˇr´ıdˇe Databaze, jej´ımiˇz hlavn´ımi funkcemi jsou:
• nastaven´ı parametr˚u spojen´ı,
• pˇripojen´ı k datab´azi,
• odpojen´ı od datab´aze,
• spuˇstˇen´ı datab´azov´e transakce,
• COMMIT datab´azov´e transakce,
• ROLLBACK datab´azov´e transakce,
• proveden´ı datab´azov´eho pˇr´ıkazu s pr´azdnou mnoˇzinou v´ysledku,
• proveden´ı datab´azov´eho pˇr´ıkazu s nepr´azdnou mnoˇzinou v´ysledku,
• pˇrevzet´ı v´ysledku datab´azov´e operace.
Pro potˇreby pr´ace s v´ysledky datab´azov´ych dotaz˚u byly vytvoˇreny tˇr´ıdy pro zapouzdˇren´ı z´akladn´ıch datab´azov´ych typ˚u:
• Smallint, Integer, Bigint – pro zapouzdˇren´ı celoˇc´ıseln´ych datab´azov´ych typ˚u,
• Char, Varchar – pro zapouzdˇren´ı znakov´ych datab´azov´ych typ˚u,
• Date, Time, Timestamp – pro zapouzdˇren´ı ˇcasov´ych datab´azov´ych typ˚u,
• Decimal, Numeric – pro zapouzdˇren´ı ˇc´ıseln´ych typ˚u s pevnou desetinnou ˇc´arkou,
• Float, Double – pro zapouzdˇren´ı ˇc´ıseln´ych typ˚u s pohyblivou desetinnou ˇc´arkou,
• Blob – pro rozs´ahl´e textov´e nebo bin´arn´ı datov´e typy.
8.3 Vrstva Model
Vrstva Model je tvoˇrena objekty, kter´e jsou ukl´ad´any nebo naˇc´ıt´any z datab´aze, a tˇr´ıdami, kter´e tyto objekty spravuj´ı – staraj´ı se o jejich naˇc´ıt´an´ı, ukl´ad´an´ı a ´uklid z pamˇeti. Tyto tˇr´ıdy jsou odvozeny od tˇr´ıdy Spravce.
8.3.1 Tˇr´ıda Spravce
Tato tˇr´ıda zapouzdˇruje operace nad datab´azovou transakc´ı, v r´amci kter´e datab´azov´e oper- ace odvozen´ych tˇr´ıd prob´ıhaj´ı. Obsahuje tedy jedineˇcn´y identifik´ator datab´azov´e transakce a metody pro start transakce, COMMIT a ROLLBACK a je b´azovou tˇr´ıdou pro tˇr´ıdy SpravceUzivatelu,SpravcePacientu aSpravceZaznamu.
8.3.2 Tˇr´ıdy SpravceUzivatelu, SpravcePacientu a SpravceZaznamu Objekty tˇechto tˇr´ıd maj´ı na starosti spr´avu objekt˚u, kter´e mohou b´yt bˇehem sv´e ˇzivotnosti naˇc´ıt´any, mˇenˇeny a zpˇetnˇe ukl´ad´any do datab´aze. K tomu potˇrebuj´ı pracovat v r´amci datab´azov´e transakce s pˇr´ıstupem Read-Write, coˇz jim zajist´ı b´azov´a tˇr´ıdaSpravce.
Protoˇze jsou tˇemito tˇr´ıdami spravovan´e objekty prov´azan´e (napˇr. Pacient (spravuje SpravcePacientu) – Dekurz (spravuje SpravceZaznamu) – L´ekaˇr (spravujeSpravceUzivate- lu)), jsou tak´e tyto tˇr´ıdy prov´azan´e, coˇz ukazuje obr´azek 8.2. Z kaˇzd´eho objektu tˇechto tˇr´ıd lze tedy z´ıskat ukazatel na objekt zb´yvaj´ıc´ıch tˇr´ıd z t´eto trojice a z´aroveˇn tyto tˇri objekty sd´ılej´ı jedinou datab´azovou transakci, coˇz je z d˚uvodu vlastnosti transakˇcn´ıho zpracov´an´ı izolovanost.
Spravce
SpravcePacientu
SpravceZaznamu SpravceUzivatelu
spravce_pacientu
spravce_zaznamu
spravce_pacientu spravce_uzivatelu
Obr´azek 8.2: Asociaˇcn´ı a dˇediˇcn´e vztahy mezi spr´avci objekt˚u
Spr´ava objekt˚u
Stejnˇe jako je tomu u tˇr´ıdy SpravceCiselniku m´a i zde kaˇzd´y spravovan´y objekt jedineˇcn´y identifik´ator v r´amci sv´e tˇr´ıdy, pomoc´ı kter´eho m˚uˇze b´yt popt´av´an. V´yjimkou jsou objekty tˇr´ıd odvozen´ych od b´azov´e tˇr´ıdy Zaznam, kter´e maj´ı identifik´ator unik´atn´ı v r´amci t´eto b´azov´e tˇr´ıdy.
Tito spr´avci objekt˚u maj´ı stejnˇe jako SpravceCiselniku asociativn´ı pole pro kaˇzdou tˇr´ıdu, kam jsou tyto objekty ukl´ad´any. Na rozd´ıl odSpravceCiselniku je za bˇehu programu vytvoˇreno v´ıce instanc´ı tˇechto tˇr´ıd – objekty vznikaj´ı se zah´ajen´ım transakce a s jej´ım ukonˇcen´ım (COMMIT, ROLLBACK) zanikaj´ı a s nimi i vˇsechny jimi spravovan´e objekty (i nezmˇenˇen´e), coˇz se dˇeje z toho d˚uvodu, ˇze tyto objekty pˇrest´avaj´ı b´yt platn´e (jin´a transakce je mohla zmˇenit).
