Analýza a návrh informačního systému pro zubní ordinaci

Masarykova univerzita Fakulta informatiky

Analýza a návrh informačního systému pro zubní ordinaci Bakalářská práce

Tomáš Kopecký 2011

Prohlášení

Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Poděkování

Chtěl bych poděkovat prof. RNDr. Jiřímu Hřebíčkovi, CSc. za vedení mé bakalářské práce a odbornou pomoc. Dále děkuji svému otci MUDr. Tomáši Kopeckému za poskytnuté rady z oblasti stomatologie a konzultace při tvorbě informačního systému.

Shrnutí

Cílem práce je provést analýzu dostupných informačních systémů pro ordinace zubních lékařů a porovnat je a na základě srovnání navrhnout a implementovat vhodný informační systém, který bude splňovat jak legislativní požadavky, tak i požadavky lékařských pojišťoven.

Klíčová slova

zdravotní pojišťovny, dávka s vyúčtováním hrazené zdravotní péče, Yourdon Modern Structured Analysis (YMSA), DFD, ERD, Lazarus, Firebird

Obsah Úvod............................................................................................................................................1 1 Legislativa a požadavky pojišťoven........................................................................................2 1.1 Zákon o veřejném zdravotním pojištění..........................................................................2 1.2 Pořizování dokladů..........................................................................................................3 1.2.1 Vyúčtování výkonů v ambulantní stomatologické péči (doklad 01s)......................4 1.2.2 Stomatologické výrobky (doklad 03s).....................................................................4 1.2.3 Ostatní doklady.............................................................................................................5 1.3 Předávání dokladů...........................................................................................................5 2 Existující informační systémy pro zubní ordinace..................................................................7 2.1 Ordinace PUSSA.............................................................................................................7 2.2 Medicus komfort.............................................................................................................9 2.3 Další informační systémy..............................................................................................10 3 Analýza a návrh vlastního systému.......................................................................................11 3.1 Metodika YMSA...........................................................................................................11 3.2 Model okolí systému.....................................................................................................12 3.2.1 Popis účelu systému...............................................................................................12 3.2.2 Kontextový diagram..............................................................................................13 3.2.3 Seznam událostí.....................................................................................................15 3.3 Model chování systému.................................................................................................17 3.3.1 Systémový diagram...............................................................................................17 3.3.2 Entitně relační diagram..........................................................................................18 3.3.3 Datový slovník.......................................................................................................21 4 Implementace vlastního systému..........................................................................................22 4.1 Použitý software............................................................................................................22 4.1.1 Integrované vývojové prostředí Lazarus...............................................................22 4.1.2 Databázová platforma Firebird..............................................................................23 4.2 Grafické uživatelské rozhraní systému..........................................................................24 4.3 Funkce systému.............................................................................................................25 5 Závěr.....................................................................................................................................28 Použitá literatura...................................................................................................................29 Příloha 1: Obsah CD.............................................................................................................31 Příloha 2: Pokyny ke zprovoznění aplikace.........................................................................32

Úvod Informační a komunikační technologie (ICT) se neustále vyvíjejí a zlepšují, proto nacházejí uplatnění téměř ve všech oblastech lidské činnosti. Příkladem praktického využití ICT mohou být informační systémy. Ty jsou dobrými pomocníky zejména v administrativní oblasti, protože šetří spoustu času a stovky listů popsaného papíru pro evidenci zboží, vedení účetnictví, vyhledávání zaměstnanců atd. Stejně je tomu i u administrativní činnosti lékařů. Lékař provozující zdravotnické zařízení je smluvně vázán se zdravotními pojišťovnami, které mu platí za odvedené výkony, tj. za léčbu a péči, kterou poskytuje pacientům. Tyto výkony musí lékař zaznamenávat do předepsaných dokladů a v pravidelných intervalech předkládat pojišťovně k vyúčtování. Způsob předkládání se stanoví ve smlouvě mezi zdravotnickým zařízením a pojišťovnou, zpravidla se však jedná o předávání dávek dokladů (textové soubory obsahující záznamy o zdravotní péči poskytnuté pojištěnci) na datových nosičích (disketa, CD) [1]. Dávky dokladů jsou obyčejné ASCII soubory [2], přesto nelze předpokládat, že by lékař vytvářel dávku manuálně, například v běžném textovém editoru. Tato práce by jistě byla velmi zdlouhavá, a proto je pro lékařskou ordinaci téměř nutností vlastnit informační systém umožňující automatizovanou tvorbu dávek. Informační systém zrychluje a zefektivňuje fungování zubní ordinace, dovoluje vést přehlednou dokumentaci pacientů nebo sledovat ekonomické náklady na provoz ordinace. Všechny potřebné údaje má zubní lékař k dispozici na jednom místě, a to ve svém počítači.

1

1 Legislativa a požadavky pojišťoven První kapitola práce popisuje právní vztahy mezi lékařem, pacientem a zdravotní pojišťovnou. Znalost těchto vztahů usnadňuje orientaci v problematice informačních systémů pro zubní ordinace. V následujícím popisu legislativy vycházíme především ze zákona č. 48/1997 Sb., o veřejném zdravotním pojištění [3]. Požadavky na komunikaci mezi zdravotními pojišťovnami a zubními lékaři jsou popsány na základě dokumentu „Metodika pro pořizování a předávání dokladů VZP ČR“ [1].

1.1 Zákon o veřejném zdravotním pojištění Všechny osoby s trvalým pobytem na území České republiky jsou zdravotně pojištěny a mají povinnost platit pojistné. Osoby samostatně výdělečně činné si jej platí sami. Pojistné za zaměstnance hradí z jedné třetiny zaměstnanec, ze dvou třetin zaměstnavatel. Za některé pojištěnce platí pojistné zdravotního pojištění stát (děti, studenti, důchodci, ženy na mateřské dovolené, nezaměstnaní). Peníze z pojistného putují do společného fondu zdravotní pojišťovny, ze kterého jsou hrazeny náklady na léčbu pojištěnců. Každý pojištěnec si takto „předplácí“ svou vlastní léčbu. Výše pojistného nezávisí na tom, jak moc pojištěnec zdravotní systém využívá, je tedy pravděpodobné, že zdravá osoba odvede do zdravotního systému více peněz, než kolik jich využije na svou léčbu. Naopak náklady na péči o více nemocného člověka budou nejspíš vyšší, než množství peněz jím vložených. Zdravotní pojištění tedy funguje na principu solidarity zdravých s nemocnými. Dalším peněžním příjmem do zdravotního systému jsou regulační poplatky. Ty se platí za každou návštěvu lékaře, pobyt v nemocnici nebo za recept na léčivý prostředek. Regulační poplatky tedy slouží k mírnému zvýšení finančních příspěvků do zdravotního systému od osob, které jej využívají více. Zákon udává pro pojištěnce mnoho práv a povinností. Z pohledu tvůrce informačního systému nás zajímají tato práva pojištěnce: ●

Pojištěnec má právo na výběr zdravotní pojišťovny. Zdravotní pojišťovnu lze změnit jednou za 12 měsíců, a to vždy jen k 1. dni kalendářního čtvrtletí. Pokud pojišťovna vstoupí do likvidace nebo je nad ní zavedena nucená správa, mají její pojištěnci oprávnění změnit zdravotní pojišťovnu i ve lhůtě kratší, a to vždy k 1. dni kalendářního měsíce, nejdříve však k 1. dni následujícího kalendářního měsíce.

●

Pojištěnec má právo na výběr lékaře, který je ve smluvním vztahu k příslušné zdravotní pojišťovně. Toto právo může uplatnit jednou za tři měsíce.

●

Pojištěnec má právo na zdravotní péči bez přímé úhrady, pokud mu byla poskytnuta v rozsahu a za podmínek stanovených zákonem. Tato péče se hradí ze zdravotního pojištění a jejím cílem je zachovat nebo zlepšit zdravotní stav pacienta. Ze zdravotního pojištění nelze hradit veškerou zdravotní péči, nehradí se péče nadstandardní, netradiční nebo vysoce nákladná, např. plastická chirurgie nebo akupunktura. Některé zdravotní prostředky hradí pojišťovna jen zčásti a zbytek si doplácí pacient sám.

2

Zdravotní pojišťovny uzavírají se zdravotnickými zařízeními smlouvy o poskytování zdravotní péče. Pojišťovny jsou povinny uhradit zdravotnickým zařízením, které v souladu se zákonem poskytly zdravotní péči pojištěncům, tuto poskytnutou péči ve lhůtách sjednaných ve smlouvě. Zdravotnická zařízení jsou reprezentována lékaři nebo zdravotnickými pracovníky, kteří v daném zdravotnickém zařízení pracují a uzavřeli s pojišťovnou smlouvu o poskytování zdravotní péče.

1.2 Pořizování dokladů Veřejná zdravotní pojišťovna České republiky (VZP) určuje způsob komunikace lékařů a pojišťoven a předepisuje doklady, které se pro takovou komunikaci používají. VZP dále na svých internetových stránkách vydává tzv. číselníky. V číselnících jsou uvedeny kódy, které se používají pro popis zdravotních výkonů, materiálů, léčiv, stomatologických výrobků apod. Když lékař zapisuje údaje do dokladů, místo názvů používá kódy z číselníků, což šetří místo i čas. Například místo „ošetření zubního kazu – stálý chrup“ stačí napsat „00921“, což je kód tohoto výkonu podle číselníku Zdravotní výkony. Doklady, metodika jejich vyplňování a předávání i číselníky vydávané VZP jsou závazné pro všechny pojišťovny. Lékař tedy komunikuje se všemi zdravotními pojišťovnami jednotným způsobem. Na většině dokladů se vyplňují tyto údaje: Kód pojišťovny – číslo pojišťovny pojištěnce dle číselníku Zdravotní pojišťovny, např. VZP má kód 111. Kód pojistného vztahu – číslo pojistného vztahu podle číselníku Druh pojistného vztahu. Obvyklý pojistný vztah je veřejné zdravotní pojištění, které má kód 1. Jiným druhem pojistného vztahu může být cestovní či smluvní připojištění. IČO – identifikační číslo organizace (zdravotnického zařízení), přidělené Českým statistickým úřadem. IČZ – identifikační číslo zdravotnického zařízení nebo části zařízení. Přiděluje ho územní pracoviště VZP (pracoviště VZP v rámci okresu). IČP – identifikační číslo pracoviště, blíže identifikuje konkrétní zdravotnické pracoviště zařízení nebo části zařízení. Je přidělováno územním pracovištěm VZP. Odbornost – určuje specializaci a odborné zaměření činnosti zdravotnického pracoviště, tj. způsobilost k poskytování příslušné zdravotní péče. Uvádí se podle číselníku Smluvní odbornosti pracovišť. Pracoviště praktického zubního lékaře má kód odbornosti 014. Číslo dokladu – číslo dokladu slouží k jeho jednoznačné identifikaci v rámci zdravotnického zařízení a roku, za který byl vystaven a předložen pojišťovně. V jednom roce tedy není možné jedné pojišťovně poslat dva doklady se stejným číslem. Variabilní Symbol – variabilní symbol je určen k další identifikaci zdravotního zařízení, např. rozdělení na nákladová střediska apod. O tom, zda se bude variabilní symbol používat, rozhoduje územní pracoviště VZP. Příjmení a jméno pacienta – slouží k doplňující identifikaci pojištěnce. Číslo pojištěnce – identifikuje pojištěnce, je shodné s rodným číslem.

3

Základní Diagnóza – kód základního onemocnění nebo diagnóza, která byla důvodem poskytnutí ambulantní péče či důvodem kontaktu se zdravotnickým zařízením. Vyplňuje se podle číselníku Mezinárodní klasifikace nemocí verze 10. Ostatní diagnózy – na prvním místě se uvede diagnóza onemocnění, které nejvíce ohrožuje zdraví či život nemocného, pokud již není uvedena jako základní diagnóza a byla léčena společně se základní diagnózou. Dále se uvádějí kódy dalších onemocnění, které komplikují, tj. ovlivňují či odůvodňují frekvenci, trvání, objem a strukturu poskytnuté a vykázané péče. Náhrady (Kód náhrady, KN) – zdravotnické zařízení je povinno indikovat úrazy a jiná poškození zdraví osob, kterým poskytlo zdravotní péči, pokud má důvodné podezření, že úraz nebo jiné poškození zdraví byly způsobeny jednáním právnické nebo fyzické osoby. Uvádí se kód náhrady dle číselníku Náhrady za zdravotní péči.

1.2.1 Vyúčtování výkonů v ambulantní stomatologické péči (doklad 01s) Každému pacientovi, kterému zubní lékař poskytl zdravotní péči, je přiřazen doklad s názvem Vyúčtování výkonů v ambulantní stomatologické péči. Do jednotlivých řádků tohoto dokladu lékař vyplňuje provedené zdravotní výkony. Na každém řádku je tedy uvedeno: Datum – datum provedení výkonu. Vykazuje-li se více různých výkonů ke stejnému dni, stačí uvést datum k prvnímu výkonu. Lokalizace – číselný kód podle číselníku Lokalizace, určující umístění zubu, na kterém byl výkon proveden. Kód – kód provedeného výkonu podle číselníku Zdravotní výkony Počet – počet provedení vykazovaného výkonu. Pokud není uveden, započte se provedení výkonu jedenkrát. Odbornost – byl-li výkon uvedený v řádku poskytnut jiným pracovištěm jiné odbornosti, uvede se odbornost tohoto pracoviště v řádku dokladu. Diagnóza – v řádku dokladu se vyplní diagnóza, pro kterou byl výkon poskytnut, pokud je tato diagnóza rozdílná od uvedené diagnózy základní.

1.2.2 Stomatologické výrobky (doklad 03s) Pokud je součástí zdravotní péče i poskytnutí stomatologického výrobku, zaznamená zubní lékař tento výrobek do dokladu Stomatologické výrobky. Doklad se nevyskytuje samostatně, vždy musí následovat za dokladem Vyúčtování výkonů v ambulantní stomatologické péči. Na jednotlivých řádcích tohoto dokladu se uvádí: Datum – datum poskytnutí výrobku. Sk – jednomístný číselný údaj dle číselníku Skupiny číselníků léčivých přípravků, ZP a stomatologických výrobků. Stomatologické výrobky mají číslo 4. Kód – číselný údaj označující stomatologický výrobek. Vyplňuje se podle číselníku Stomatologické výrobky. Množství – spotřebované množství výrobku.

4

Cena – cena za vykázané množství, kterou je zdravotnické zařízení oprávněno účtovat, nejvýše však do hodnoty maximální úhrady pojišťovnou.

1.2.3 Ostatní doklady Registrační list slouží k registraci pojištěnce k lékaři. Nejdůležitějším údajem je zde datum registrace. Doklad Přihláška registrovaných pojištěnců slouží lékaři k pořízení seznamu pojištěnců pojišťovny, kteří jsou u něho registrovaní, a k pravidelnému hlášení nově registrovaných a přeregistrovaných pojištěnců. Doklad Registrační list bývá označován číselným kódem 30, Přihláška registrovaných pojištěnců má kód 80.

1.3 Předávání dokladů Zdravotní pojišťovny proplácí lékařům péči, která byla poskytnuta pojištěncům. K proplacení péče zubnímu lékaři je nutné, aby předložil pojišťovně všechny doklady s vykázanými výkony a stomatologickými výrobky. Ve smlouvě mezi pojišťovnou a zdravotnickým zařízením se uvádí, jak často se budou předkládat doklady k vyúčtování. Doklady se předkládají v dávkách. Dávka je zavedena jako pomocná jednotka pro vyúčtování a pro předávání dokladů pojišťovně. Zubní lékař sestavuje dávku z dokladů „Vyúčtování výkonů v ambulantní stomatologické péči“ a „Stomatologické výrobky“. Taková dávka se nazývá „Dávka ambulantní smíšená pro stomatologii“. Do této dávky zařazuje stomatolog všechny doklady, na kterých jsou zaznamenané výkony nebo výrobky poskytnuté v období, za které předkládá dávku k vyúčtování. V dokladech je nutné vyplnit položku „Pořadové číslo“, která označuje pořadí jednotlivých listů dokladů v dávce. Také způsob předkládání dokladů je uveden ve smlouvě. Může jít o předkládání dokladů v papírové nebo elektronické podobě. Některé pojišťovny však vyžadují jen doklady elektronické. Elektronickou formou dokladů jsou zápisy dat na datovém médiu (disketě, CD, flash disku apod.), zápisy dat předávané přes zabezpečený webový portál nebo přímo vyplňované elektronické formuláře odpovídající papírové podobě dokladů. Pokud má lékař zájem posílat dávky dokladů na portál pojišťovny, musí si opatřit elektronický certifikát. Spolu s dávkami pošle i elektronický podpis svého certifikátu, čímž dávky autentizuje, tj. dá najevo, že skutečně pocházejí od něj [4]. Na datovém nosiči jsou všechny dávky uloženy v jednom souboru s názvem KDAVKA.xxx, kde xxx představuje kód pojišťovny podle číselníku Zdravotní pojišťovny [2]. K nosiči se přikládá vyplněný tiskopis Průvodní list datového nosiče. Na tomto tiskopisu se vyplní IČZ a počet předaných dávek na datovém nosiči. Předaný datový nosič pojišťovna zkontroluje a vyřadí doklady, které kontrolou neprojdou. Vyřazené doklady je nutné opravit a znovu předat ve zvláštní dávce, nazývané dávka opravná. Dávky dokladů slouží zdravotní pojišťovně ke kontrole, zda je částka, kterou lékař od pojišťovny požaduje, oprávněná. K vlastnímu vyžádání částky se používá faktura za období nebo faktura za dávky. Stomatologické zdravotní zařízení obvykle používá faktury za období. Faktura za dávky se používá při předávání opravných dávek, není-li ve smlouvě uvedeno jinak. Na fakturách se uvádí

5

peněžní ústav a číslo účtu zdravotnického zařízení, den vystavení a odeslání faktury a účtovaná finanční částka. Faktura se většinou předává pojišťovně v papírové formě, a to i v případě, že dávky dokladů se předkládají na datovém nosiči. Pokud zdravotnické zařízení předává na datovém nosiči i fakturu, je tato faktura umístěna v souboru FDAVKA.xxx, kde xxx je kód zdravotní pojišťovny, které se faktura posílá. Kromě dávek s vyúčtováním zdravotní péče může zubní lékař posílat pojišťovnám i dávky s přihláškami registrovaných pojištěnců. Do těchto dávek se řadí doklady „Přihláška registrovaných pojištěnců“.

6

2 Existující informační systémy pro zubní ordinace Druhá kapitola analyzuje současný stav trhu s informačními systémy pro zubní ordinace. Těchto systémů existuje velké množství, jejich velkou nevýhodou je však vysoká cena, která se i u těch nejjednodušších pohybuje v řádech tisíců korun za jednu licenci. Podrobně jsou popsány dva vybrané produkty dostupné jako demoverze na Internetu.

2.1 Ordinace PUSSA

Obr. 1 : Tvorba dávek v programu Ordinace PUSSA

7

Hlavní nevýhoda tohoto systému je vidět na první pohled – je jí grafické uživatelské rozhraní, které působí zastaralým dojmem.Program je totiž primárně určen pro operační systém DOS. Při použití v operačních systémech Windows se musí podle nápovědy k programu nastavit systémový soubor CONFIG.NT. V tomto souboru je nutno zvýšit hodnotu parametru FILES, který udává maximální počet otevřených souborů při používání aplikací pro MS DOS. Pokud tuto hodnotu neupravíme alespoň na doporučených 180, bude program při běhu kolabovat. Program se ovládá pomocí přehledného menu v horní části obrazovky. Základem systému je kartotéka pacientů. Zde se ukládají údaje o pacientech (jméno, adresa, pojišťovna atd.), zdravotních výkonech a výrobcích, které jim byly poskytnuty. V kartotéce má lékař dále možnost evidovat a tisknout recepty vystavené pacientům a psát texty popisující např. průběh nemoci a léčby. Při práci se systémem může lékař jediným stisknutím klávesy vyvolat číselníky VZP a vybrat z nich požadovaný kód. Číselníky jsou k dispozici hned po nainstalování programu, navíc je možné stáhnout z Internetu jejich novou verzi a nahrát ji do programu. Výběrem položky „Přehledy“ může lékař vytvářet různé statistiky o provedených výkonech, počtech pacientů, vybraných regulačních poplatcích atd. Samozřejmostí je tvorba dávek a faktur pro zdravotní pojišťovny. Vytvořenou dávku lze otestovat na správnost údajů (např. kontrola správnosti rodných čísel). Bohužel lze vytvářet jen dávky předávané na datovém nosiči, program sám neumí poslat dávky na webový portál pojišťovny. Pokročilou funkcí tohoto informačního systému je vytváření a on-line nahrávání dávek pro systém IZIP. IZIP je společnost, která provozuje elektronické zdravotní knížky. Elektronické zdravotní knížky systému IZIP obsahují zdravotní záznamy pacienta. Pacient, který si elektronickou zdravotní knížku pořídí, může po vzájemné dohodě dovolit svému lékaři prohlížet a doplňovat své zdravotní záznamy. IZIP také pomůže sdílet důležité informace mezi různými lékaři. To zkvalitní celkovou péči o pacienta [5]. Program Ordinace PUSSA umožňuje přihlašování uživatelským jménem a heslem a přidělování přístupových práv, čímž se chrání lékařské záznamy před neoprávněným použitím. Program není určen pouze stomatologům, dokáže pracovat s více odbornostmi. I přes nepohodlné grafické uživatelské rozhraní lze tento systém doporučit lékařům, kteří požadují jednoduchý software nenáročný na technické vybavení počítače. Výhodou oproti jiným a propracovanějším informačním systémům je i cena tohoto produktu [6].

8

2.2 Medicus komfort

Obr. 2: Program Medicus Komfort se zobrazeným zubním křížem Společnost Medisoft dodává informační systém Medicus ve variantách Start, Profesionál a Komfort. V této práci se budeme zabývat variantou Komfort, protože má nejbohatší funkcionalitu. Všechny verze systému Medicus obsahují stejné funkce jako výše popsaný program Ordinace PUSSA. Kromě toho však umožňují provádět mnoho jiných operací, které předchozí program nepodporuje. Podrobnější je zde kartotéka, k pacientům lze přiřadit jejich podobenku, i když tato funkce pravděpodobně nebude lékaři často používána. Do zdravotní dokumentace lze ukládat obrazová data z nejrůznějších vyšetření i s jejich popisem. Pomocí řízení přístupu může lékař zpřístupnit kartu pacienta jiným uživatelům systému, nebo jim naopak přístup zakázat. Program je schopen pracovat se všemi doklady používanými pro styk se zdravotními pojišťovnami, dávky umí zpracovávat na datový nosič i přímo posílat přes Internet na portály pojišťoven. Stav chrupu je možné přehledně sledovat v okně „Zubní kříž“. Zubní kříž je grafické znázornění jednotlivých zubů, jejich stavu a léčby. Historie zubního kříže se ukládá, takže je možné sledovat změny stavu chrupu. Pokud lékař do zubního kříže zaznamená provedený výkon, lze tento výkon přenést do dokladu Vyúčtování výkonů v ambulantní stomatologické péči.

9

Systém se stará o platbu regulačních poplatků, umožňuje tisk účtenky, která prokazuje jeho zaplacení, a pokud lékař zavře kartu pacienta bez toho, aby vykázal regulační poplatek, program na to upozorní. Medicus je schopen pracovat v síťovém režimu a dovoluje tak komunikaci mezi lékařem a zdravotní sestrou, pokud např. pracují v různých místnostech. Příkazem „Do fronty“ může sestra přidat pacienta do seznamu Fronta pacientů, kde jsou uvedeni pacienti čekající v čekárně na ošetření. Lékař pracující na jiném počítači si tento seznam může prohlížet. Informační systém obsahuje objednávkový kalendář, ve kterém může lékař editovat své ordinační hodiny a objednávat pacienty. Objednávkový kalendář lékaře je možné zveřejnit na internetových stránkách programu Medicus a umožnit tak pacientům on-line objednávání. Uživatel si může systém přizpůsobit pomocí menu „Konfigurace“, kde lze nastavit zobrazovaná tlačítka, klávesové zkratky, zařazovat pacienty do skupin nebo zadávat tzv. fráze, tj. často se opakující části textu, které pak může lékař vkládat do textové části zdravotní dokumentace. Program umožňuje napojení a zpracování dat z vnějších zařízení jako jsou kamery, fotoaparáty či rentgenové přístroje. Informační systém Medicus Komfort je komplexním programem pro stomatology. Kvůli této komplexnosti však bude možná uživatel potřebovat více času na zorientování se v uživatelském rozhraní a funkcích systému. Také hardwarové požadavky jsou vyšší než u předchozího programu. Systém Medicus Komfort lze doporučit zubním lékařům, kteří mají zájem při práci v ordinaci plně využívat možností informačních technologií [7].

2.3 Další informační systémy Příkladem velmi jednoduchého komerčního systému pro zubní ordinace je Dositech. Tento systém obsahuje jednoduchou kartotéku pacientů a zaměřuje se pouze na účtování zdravotním pojišťovnám a tvorbu jednoduchých statistik. Kromě klasického režimu práce v ordinaci s kartotékou pacientů umožňuje i režim pořizovací, kdy se pouze přepisují papírové doklady do počítače, aby z nich mohla být sestavena elektronická dávka [8]. Ostatní propracovanější informační systémy se svou funkcionalitou příliš neliší od výše zmíněného programu Medicus Komfort. Za zmínku stojí modul Daňová evidence, který používá firma Hobosoft ve svém systému Stomatolog. Tento modul rozšiřuje stomatologický informační systém o funkce související s vedením účetnictví a obsahuje pokladní knihu, evidenci příjmů, výdajů a skladových zásob [9]. Program Dentist+ zase umožňuje vytvoření léčebních postupů, kdy se najednou vykáže celá skupina kódů, které se obvykle používají společně. To značně zkrátí dobu, kterou lékař musí věnovat tvorbě dokladů [10].

10

3 Analýza a návrh vlastního systému Následující kapitola popisuje analýzu a návrh systému pomocí metodiky YMSA. Nejprve jsou uvedeny principy této metodiky, poté je prezentována vlastní analýza a návrh včetně vyobrazení DFD a ERD diagramů. Tyto diagramy byly vytvořeny v CASE nástroji CASE Studio 2 od společnosti Charonware [11]. Analýza systému vycházela z požadavků konkrétního zubního lékaře, který bude systém používat. Protože tento lékař neměl předchozí zkušenost s jinými informačními systémy, byly mu předvedeny komerční programy popsané v předchozí kapitole. Získání představy o možnostech systémů pro zubní ordinace pomohlo lékaři přesněji formulovat požadavky na vlastní systém.

3.1 Metodika YMSA Období 60. let 20. století je softwarovými inženýry často označováno jako softwarová krize. V této době již byly počítače technicky poměrně vyspělé, a tak vzrůstalo množství a složitost úkolů, které na nich byly prováděny. Zároveň však narůstal i počet projektů, které nebyly dokončeny nebo jejich vývoj značně přesáhl původně plánovaný rozpočet a časový plán. K programům se nevytvářela dokumentace, což ztěžovalo jejich udržovatelnost a možnost rozšiřování o nové funkce [12]. Od 70. let proto dochází k vytváření postupů, jejichž cílem je naplánovat a zdokumentovat vývoj programového systému předtím, než se začne s jeho implementací, tedy psaním zdrojového kódu. Vznikají metodiky strukturované analýzy, později se přidávají metodiky objektové analýzy určené pro objektově orientované programování. Yourdon Modern Structured Analysis (YMSA) je metodika strukturované analýzy vytvořená roku 1989 Edwardem Yourdonem [13]. Základním modelovacím nástrojem Yourdonovy moderní strukturované analýzy je diagram datových toků (DFD – Data Flow Diagram). DFD představuje funkčně (procesně) orientovaný pohled na systém. Jeho úkolem je tedy znázornit množinu funkcí, které systém poskytuje. Na DFD se mohou objevit 4 druhy komponent: terminátor, proces, datový tok a paměť. Terminátor reprezentuje externí entitu komunikující se systémem. Terminátory jsou zpravidla uživatelé, méně často jiné softwarové systémy nebo hardwarová zařízení. Proces představuje určitou funkci systému a transformuje vstupní data (data vstupující do procesu) na data výstupní. Datový tok znázorňuje cestu, po které se pohybují data z jedné části systému do druhé. Paměť je pasivní prvek systému sloužící k ukládání dat za účelem jejich pozdějšího zpracování. Grafické znázornění těchto 4 komponent DFD diagramu se může lišit podle použité metodiky. Na následujícím obrázku jsou komponenty zobrazeny v notaci Yourdon-DeMarco, kterou používá program CASE Studio.

11

Obr. 3: Komponenty DFD diagramu v notaci Yourdon-DeMarco DFD zpravidla obsahuje velké množství procesů, které není možné všechny umístit do jednoho diagramu, protože by byl velmi složitý a nepřehledný. Z tohoto důvodu používáme DFD diagramy různých úrovní. Procesy na DFD diagramu nižší úrovně jsou na diagramu vyšší úrovně sloučeny do jednoho společného procesu. DFD nejvyšší úrovně se nazývá kontextový diagram a obsahuje jen jeden proces. Tento proces reprezentuje celý modelovaný systém. DFD nulté úrovně, rovněž nazývaný systémový diagram, je diagram o úroveň nižší než kontextový diagram. Na diagramu nulté úrovně je proces z kontextového diagramu rozložen (dekomponován) na několik hlavních procesů. Každý z těchto procesů může být opět rozložen na samostatném DFD. Dekompozici procesů provádíme tak dlouho, dokud není činnost prováděná procesem dostatečně elementární. K procesům, které již dále nedekomponujeme, připojíme minispecifikaci. Minispecifikace definuje logiku procesu a většinou má podobu stručného slovního zápisu činnosti procesu. Metodika YMSA se soustředí na nalezení esenciálního modelu systému, který slouží jako základ pro odvození implementačního modelu systému. Esenciální model systému se skládá z modelu okolí systému a modelu chování systému. Model okolí systému popisuje rozhraní systému a události ve vnějším světě, na které systém reaguje. Tento model se skládá ze tří částí: ● popis účelu systému ● kontextový diagram ● seznam událostí Model chování systému se soustředí na vnitřní uspořádání systému a ukazuje ty z jeho vlastností, které nejsou z vnějšku vidět. Při jeho tvorbě se vychází ze seznamu událostí. Vytváří se DFD diagram tak, že pro každou odezvu na událost se do diagramu umístí samostatný proces. Dále dochází ke slučování souvisejících procesů do agregovaného procesu na diagramu vyšší úrovně. Tomuto slučování procesů se říká dekompozice DFD diagramu zdola – nahoru. Současně s DFD diagramem se vytváří i ERD diagram a datový slovník. Implementační model systému pokrývá alokaci esenciálního modelu na osoby a stroje. O některých procesech v esenciálním modelu může být rozhodnuto, že budou prováděny manuálně, tyto procesy jsou pak v implementačním modelu nahrazeny terminátory. Obsahem implementačního modelu je i určení uživatelského rozhraní, doporučení pro návrh rozhraní a návrh formulářů [13]. Těmito tématy se budeme zabývat v kapitole Implementace vlastního systému.

12

3.2 Model okolí systému 3.2.1 Popis účelu systému Popis účelu systému je stručný textový dokument, který vyjadřuje hlavní strategické cíle, jichž by mělo být dosaženo po realizaci a nasazení vyvíjeného systému [13]. Našim cílem je vytvořit informační systém, který bude použitelný v ordinaci konkrétního zubního lékaře a umožní mu přechod z vedení dokladů v papírové formě do formy elektronické. Hlavním účelem systému je zajistit komunikaci mezi stomatologem a zdravotní pojišťovnou. Tato komunikace se děje prostřednictvím dávek vyúčtování poskytnuté zdravotní péče a dávek registračních listů s registrovanými pojištěnci. Systém tedy musí být schopen tyto dávky vytvářet a ukládat. Systém bude evidovat pacienty registrované u lékaře. Lékař bude moci vytvářet doklady pro pacienty a měnit údaje uložené na těchto dokladech. Pro pohodlí lékaře bude systém schopen zpracovávat číselníky VZP, které stomatolog potřebuje ke své práci. Na požádání lékaře program zobrazí vybraný číselník a uživatel tak může doplnit kód z číselníku do dokladu. Výhodou tohoto zápisu údajů do dokladů je, že lékař nemusí znát kódy zpaměti ani je mít vytištěné na papíře.

3.2.2 Kontextový diagram Kontextový diagram je speciálním případem DFD diagramu. Jak bylo řečeno výše, celý systém je na něm reprezentován pomocí jediného procesu. Tento diagram zdůrazňuje hranice mezi systémem a vnějším světem. Zobrazuje toky dat procházející přes rozhraní systému, tj. data proudící z okolí nebo do okolí systému [13]. Na kontextovém diagramu našeho systému jsou dvě paměti umístěny vně systému. Paměť „Soubory s číselníky“ představuje soubor(y), které si uživatel musí stáhnout z internetových stránek VZP. Každý soubor obsahuje údaje z určitého číselníku. Naše aplikace bude tento soubor zpracovávat a údaje z něj si uloží do vlastního úložného prostoru. Paměť „Soubory s dávkami“ reprezentuje vygenerované soubory s dávkami, které zubní lékař předává zdravotní pojišťovně. Z důvodu úspory místa a zpřehlednění diagramu nerozlišujeme, zda uživatel vkládá do systému nové údaje nebo přepisuje údaje již dříve uložené. Pro oba tyto případy používáme pouze jeden datový tok. Zobrazený DFD diagram obsahuje tři terminátory. Ty reprezentují jednotlivé skupiny uživatelů, kteří se systémem pracují. Úkolem administrátora je spravovat uživatelské účty. Má možnost vytvářet a mazat uživatele a měnit jejich údaje (heslo, oprávnění). Běžnou administrativní činnost ve stomatologické ordinaci většinou zajišťuje zdravotní sestra. Ta se v našem systému stará o evidenci a objednávání pacientů a zápis údajů do dokladů. Sestra může také mazat jednotlivé doklady (datový tok „pokyn ke smazání dokladu“), nemá ale oprávnění k hromadnému mazání více dokladů najednou (datový tok „pokyn k hromadnému smazání dokladů“ u terminátoru Stomatolog).

13

Zdravotní sestra nemá oprávnění k vytváření dávek nebo údržbě číselníků. Těmito činnostmi, nesouvisejícími s běžným denním provozem ordinace, se zabývá stomatolog.

Obr. 4: Kontextový diagram informačního systému pro zubní ordinaci Stomatolog může do systému nahrát údaje z číselníků (datový tok „pokyn k nahrátí číselníků“), v tomto případě systém získává údaje z paměti „Soubory s číselníky“. O tom, zda nahrávání proběhlo úspěšně, je stomatolog informován prostřednictvím datového toku „stav nahrávání číselníků“. Údaje o zdravotních pojišťovnách a pojistných vztazích jsou sice také vydávány jako číselníky VZP, ale

14

nejsou dostupné ve formě textových souborů dostupných na Internetu. Proto je nutné, aby tyto údaje zadal stomatolog do systému samostatně (datové toky „údaje o pojišťovně“ a „údaje o pojistném vztahu“). Při zobrazování údajů již tyto číselníky od ostatních nerozlišujeme a používáme pro všechny jednotný datový tok (datové toky „dotaz na číselník“ a „údaje z číselníku“ jako odpověď systému na tento dotaz). Po vytvoření dávky (datový tok „pokyn k vytvoření dávky“) zašle systém stomatologovi údaje, které by měl doplnit na fakturu předávanou pojišťovně společně s dávkami (datový tok „údaje na fakturu“). Dávky, které již úspěšně prošly kontrolou v informačním systému zdravotní pojišťovny a stomatolog je již nehodlá používat, mohou být uzavřeny. K tomu slouží datový tok „pokyn k uzavření dávky“. Doklady, které jsou zařazeny v uzavřených dávkách, může stomatolog všechny najednou odstranit (datový tok „pokyn k hromadnému smazání dokladů“). Speciálním datovým tokem je tok s názvem „pokyn ke zobrazení seznamu dávek“. Ten je na diagramu zobrazen přerušovanou čarou. Takto znázorňujeme datové toky, které neobsahují žádná data, ale jen signál, který systém umí interpretovat a na jehož základě vykoná určenou akci [13]. Pozorný čtenář si může všimnout, že na kontextovém diagramu chybí datový tok s pokynem ke smazání údajů o lékaři. Protože je systém zamýšlen pro použití jen jedním zubním lékařem, nelze do něj ukládat údaje o více lékařích. Z tohoto důvodu nemá příliš smysl uvažovat o mazání údajů o lékaři a stačí pouze zajistit možnost editace těchto údajů (datovým tokem „údaje o lékaři“).

3.2.3 Seznam událostí Seznam událostí je textový výčet stimulů, jež se objevují ve vnějším světě a na něž musí systém odpovědět. Rozlišujeme tři typy událostí: F (flow), T (temporal) a C (control). Událost typu F je tokově orientovaná událost, která je sdružena s nějakým datovým tokem. Událost typu T je časová událost, která nastává v nějakém významném časovém bodě. Událost typu C je řídící událost, která je sdružena s nějakým řídícím signálem systému [13]. Seznam událostí informačního systému pro zubní ordinaci: ● ● ● ● ● ● ● ● ● ● ● ● ●

Administrátor přidává nového uživatele. (F) Administrátor edituje údaje o uživateli. (F) Administrátor maže uživatele. (F) Stomatolog zapisuje nové údaje o své osobě. (F) Stomatolog edituje údaje o své osobě. (F) Stomatolog zapisuje novou zdravotní pojišťovnu. (F) Stomatolog edituje údaje o zdravotní pojišťovně. (F) Stomatolog maže zdravotní pojišťovnu. (F) Stomatolog zapisuje nový pojistný vztah. (F) Stomatolog edituje údaje o pojistném vztahu. (F) Stomatolog maže pojistný vztah. (F) Stomatolog dává pokyn k nahrávání číselníků. (F) Stomatolog dává pokyn k hromadnému mazání dokladů. (F)

15

● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●

Stomatolog dává pokyn k vytvoření dávky typu 80 – Dávka registračních listů. (F) Stomatolog dává pokyn k vytvoření dávky typu 81 – Dávka ambulantní smíšená pro stomatologii. (F) Stomatolog žádá o zobrazení seznamu dávek. (C) Stomatolog uzavírá dávku. (F) Stomatolog maže dávku. (F) Zdravotní sestra žádá o zobrazení číselníku. (F) Zdravotní sestra zapisuje nového pacienta. (F) Zdravotní sestra edituje údaje o pacientovi. (F) Zdravotní sestra vyhledává pacienta. (F) Zdravotní sestra maže pacienta. (F) Zdravotní sestra vyhledává doklad. (F) Zdravotní sestra mění charakter dokladu. (F) Zdravotní sestra zapisuje nový doklad 01s – Vyúčtování výkonů v ambulantní stomatologické péči. (F) Zdravotní sestra edituje údaje na dokladu 01s – Vyúčtování výkonů v ambulantní stomatologické péči. (F) Zdravotní sestra maže doklad 01s – Vyúčtování výkonů v ambulantní stomatologické péči. (F) Zdravotní sestra zapisuje nový doklad 03s – Stomatologické výrobky. (F) Zdravotní sestra edituje údaje na dokladu 03s – Stomatologické výrobky. (F) Zdravotní sestra maže doklad 03s – Stomatologické výrobky. (F) Zdravotní sestra žádá o zobrazení objednávkového kalendáře. (F) Zdravotní sestra objednává pacienta. (F) Zdravotní sestra ruší objednávku pacienta. (F)

16

3.3 Model chování systému 3.3.1 Systémový diagram

Obr. 5: Systémový díagram informačního systému pro zubní ordinaci

17

Na DFD jsou zobrazeny čtyři hlavní procesy našeho systému. První proces se stará o evidenci lékaře a uživatelů, druhý eviduje číselníky, třetí pacienty a doklady. Čtvrtý proces využívá údaje, které předchozí procesy ukládají do pamětí, pro tvorbu dávek. Paměti představující jednotlivé číselníky jsou ukryty uvnitř procesu „Evidence číselníků“. Výjimkou jsou paměti „Pojišťovny“ a „Lokalizace“. Proces „Tvorba dávek“ potřebuje údaje o adrese pojišťovny, aby ji mohl uvést stomatologovi v datovém toku „údaje na fakturu“. V dokladech je informace o lokalizaci uložena ve formě ID lokalizace. Při vytváření dávek je však potřeba konkrétní hodnota lokalizace, která se od hodnoty ID liší (viz kapitola Entitně relační diagram). Proto proces „Tvorba dávek“ přistupuje i k paměti „Lokalizace“, aby zde získal potřebné hodnoty lokalizací.

3.3.2 Entitně relační diagram Zatímco DFD představuje funkčně orientovaný pohled na systém, entitně relační diagram (ERD) se zabývá neměnnými atributy a strukturou dat. Komponentami ERD jsou entitní a vztahové množiny. Entitní množina se na diagramu znázorňuje obdélníkem, ve kterém je uvedeno její jméno. Tato množina představuje skupinu objektů (entit) v reálném světě. Vztahová množina obsahuje vztahy mezi entitami. Každý prvek entitní množiny může být popsán jedním nebo několika datovými elementy (atributy). Atributy se na ERD uvádí uvnitř obdélníku reprezentujícího entitní množinu. Atributy představují typy hodnot, které se o jednotlivých entitách uchovávají. Atributy, pomocí nichž lze entitu jednoznačně identifikovat, se nazývají klíčové atributy. ERD diagram na následujícím obrázku představuje tzv. logický datový model. Kromě logického existuje ještě konceptuální a fyzický datový model. Tyto modely se od sebe liší tím, jak detailně zobrazují entitní množiny. Konceptuální datový model je nejobecnější. Zobrazuje pouze názvy entitních množin a jejich atributů. Logický datový model přidává primární a cizí klíče a datové typy atributů. Zároveň by již měl splňovat normální formy. Fyzický datový model se vytváří ve fázi návrhu systému, kdy už je rozhodnuto o konkrétní databázové platformě, kterou bude systém využívat. Na fyzickém datovém modelu jsou obecné datové typy atributů nahrazeny konkrétními datovými typy používanými danou databázovou platformou [14]. Ačkoli náš ERD diagram představuje logický datový model, nejsou v něm vyobrazeny datové typy atributů. Ty CASE Studio 2 u logického modelu nepodporuje. CASE Studio 2 pracuje až s konkrétními typy zvolené databázové platformy na fyzickém datovém modelu.

18

Obr. 6: Entitně relační diagram informačního systému pro zubní ordinaci Uživatelé se do systému přihlašují uživatelským jménem (login) a heslem. Heslo není vhodné ukládat v čisté podobě, proto ukládáme jen jeho hash. Hash z hesla vytvoří hashovací funkce, která je jednosměrná, což znamená, že z hashe nelze zpětně odvodit původní heslo. Tím pádem nelze z databáze vyčíst hesla uživatelů, která tak nezná ani administrátor systému. Role reprezentují množinu činností, které mohou v systému provádět uživatelé, jimž byla role přiřazena. Konkrétní činnosti pro dané role definuje kontextový diagram systému. Platí, že jeden uživatel může mít přiřazeno více rolí.

19

Entitní množina „Lékař“ obsahuje atributy IČP a IČZ, které jsou využívány při tvorbě dávek. Ostatní atributy jsou spíše doplňující údaje o lékaři, které se zobrazují po vytvoření dávky a informují uživatele o datech, která má napsat na fakturu. Entitní množina „Pojišťovna“ obsahuje zdravotní pojišťovny, se kterými lékař uzavřel smlouvu o poskytování zdravotní péče jejím pojištěncům. Entitní množina „Pojistný vztah“ reprezentuje pojistné vztahy, jež lékař používá. Atributy „Kód pojišťovny“, „Kód pojistného vztahu“ a „Název“ stomatolog vyplní podle údajů z číselníků. Ostatní datové elementy u entitní množiny „Pojišťovna“ reprezentují adresu pojišťovny, na kterou jsou posílány faktury, a frekvenci zasílání dávek pojišťovně. Entitní množiny „Odbornost“, „Diagnóza“, „Náhrady“, „Lokalizace“, „Výkon“ a „Stomatologický výrobek“ představují jednotlivé číselníky, které lékař stahuje z Internetu. Každá položka číselníku obsahuje hodnotu kód, která slouží pro jednoznačnou identifikaci položky číselníku. Proto mají výše uvedené entitní množiny atribut „Kód“ jako primární klíč. Výjimkou je entitní množina „Lokalizace“. Číselník Lokalizace neobsahuje hodnoty, podle kterých by se dala jednoznačně identifikovat položka číselníku. Nabízí se použít jako primární klíč kombinaci atributů „Kvadrant“ a „Zub“, některé položky číselníku však nemají uvedenu ani jednu z těchto hodnot. Proto je u entitní množiny „Lokalizace“ přidán atribut „ID lokalizace“, který jednoznačně identifikuje položky číselníku. Do systému ukládáme více typů dokladů. Některé údaje se objevují na všech typech dokladů, tyto údaje představuje entitní množina „Doklad“. Množiny „Doklad 01s“ a „Doklad 03s“ pak reprezentují zbylé údaje, které se liší podle typu dokladu. Doklad typu 80 – Přihláška registrovaných pojištěnců neobsahuje žádné specifické údaje, a je proto celý reprezentován entitní množinou „Doklad“. Jednotlivé řádky dokladů jsou obsaženy v entitních množinách „Řádek 01s“ a „Řádek 03s“. Atributy, jejichž hodnoty se vyplňují podle číselníků, odkazují na atribut Kód (v případě číselníku „Lokalizace“ atribut „ID lokalizace“) v příslušném číselníku. Lokalizace je určena dvojicí atributů „Kvadrant“ a „Zub“, které mají obě své vlastní ID, proto jsou na ERD znázorněny dvě vztahové množiny spojující entitní množiny „Řádek 01s“, resp. „Řádek 03s“ s entitní množinou „Lokalizace“. Nepříjemností je, že CASE Studio 2 neumožňuje měnit názvy cizích klíčů. Z toho důvodu se u entitních množin „Řádek 01s“ a „Řádek 03s“ objevují dva atributy se stejným jménem „ID lokalizace“. Na řádku dokladu 01s je údaj „Řádková odbornost“. Protože se tento údaj vyplňuje jen zřídka a většinou zůstává prázdný, byl oddělen od entitní množiny „Řádek 01s“ a umístěn do samostatné množiny „Řádek 01s_odbornost“. Do této množiny se umísťuje údaj o řádkové odbornosti jen pro ty doklady, které ho skutečně mají vyplněný. Návrh ERD tak v tomto případě splňuje i 4. normální formu, jejíž cílem je zajistit, aby se v databázi nevyskytovaly entity, které nemají přiřazeny hodnoty některých atributů [13]. V praxi se obvykle dodržuje jen 1. až 3. normální forma [15]. I u ERD diagramu našeho systému je 4. normální forma v některých případech porušena. Například u některých výkonů nebo výrobků, zapisovaných do dokladů, se neuvádí lokalizace. Aby byla splněna 4. normální forma, musely by se atributy „Kvadrant“ a „Zub“ přesunout do samostatné entitní množiny. Tím bychom získali výhodu menší redundance a menší velikosti výsledné databáze. Hodnoty atributů „Kvadrant“ a „Zub“ by se totiž uchovávaly jen u těch řádků, na kterých by byly skutečně vyplněny. Nevýhodou by však bylo zkomplikování databázového schématu. Protože lze

20

navíc předpokládat, že na většině řádků bude kvadrant a zub vyplněn a nevyplněných řádků bude málo, velikost databáze se ve skutečnosti zmenší jen nepatrně. Jiná situace je u zmiňované řádkové odbornosti. Ta bude pravděpodobně vyplněna na minimu řádků, proto byla oddělena do samostatné entitní množiny.

3.3.3 Datový slovník Datový slovník popisuje obsah dat v datových tocích a entitních množinách. Při jeho sestavování se používají následující symboly [13, 16]: Symbol

Význam

=

Skládá se z

+

A

x–y

Rozsah možných hodnot od x po y

[...|...]

Výběr jedné z možností

{...}i

i-krát opakující se prvek

(...)

Nepovinný prvek

@

Klíč

*...*

Komentář

Tab. 1: Operátory datového slovníku Protože je datový slovník poměrně rozsáhlý dokument, není možné jej v tomto textu prezentovat celý. Pro ilustraci uvedeme datový slovník pro datový tok „údaje o lékaři“ z DFD systému: údaje o lékaři

= @IČP + IČZ + (rodné číslo) + (jméno) + (příjmení) + (variabilní symbol) + (IČO) + (název peněžního ústavu) + (kód peněžního ústavu) + (číslo účtu) IČP = {0 – 9}8 IČZ = {0 – 9}8 rodné číslo = [{0 – 9}9|{0 – 9}10 ], *3. a 4. pozice rodného čísla musí obsahovat číslo v rozsahu 01 –12, 21 –32, 51 –62 nebo 71 –82. 5. a 6. pozice rodného čísla musí obsahovat číslo v rozsahu 01 –31 nebo 51 –81. Je-li délka rodného čísla 10, pak rodné číslo modulo 11 = 0.* variabilní symbol = *znakový řetězec max. délky 6* IČO = {0 – 9}8 kód peněžního ústavu = {0 – 9}4 číslo účtu = {0 – 9}10

21

4 Implementace vlastního systému Po fázi analýzy a návrhu se věnujeme implementaci systému. V této kapitole je nejdříve popsán software, který byl pro implementaci použit, dále se zabýváme grafickým uživatelským rozhraním systému a jeho funkcemi.

4.1 Použitý software 4.1.1 Integrované vývojové prostředí Lazarus Lazarus je integrované vývojové prostředí (IDE – Integrated Development Environment) distribuované jako open source software [17]. Lazarus obsahuje kompilátor Free Pascal Compiler (FPC), který je schopen překládat kód napsaný v programovacím jazyce Object Pascal. Tento jazyk používá i IDE Delphi, dá se tedy říci, že Lazarus je nekomerční alternativa k vývojovému prostředí Delphi [18]. Výhodou vytváření aplikací v IDE Lazarus je především rychlý vývoj grafického uživatelského rozhraní (GUI – Graphical User Interface) programu. Lazarus má k dispozici velké množství komponent (prvky GUI, např. tlačítko, textové pole, obrázek), které vývojář pomocí myši umísťuje na tzv. formuláře, reprezentující okna jeho aplikace. Poté může měnit vlastnosti těchto komponent (velikost, umístění na formuláři, barva, popisek atd.). S komponentami může uživatel provádět akce jako kliknutí na komponentu, stisknutí klávesy, označení části textu a podobně. Tyto akce označujeme jako události. Programátor má možnost psát reakce na tyto události, což jsou příkazy, které má aplikace vykonat při výskytu příslušné události. Reakce na události tvoří většinu zdrojového kódu, proto programování v IDE Lazarus označujeme jako událostmi řízené programování. Jak již bylo uvedeno, je Lazarus velmi podobný Delphi. Jeho cílem však není být přesnou kopií Delphi, mezi těmito dvěma prostředími existují rozdíly. Výhodou IDE Lazarus je, že je multiplatformní, zatímco Delphi umí vytvářet programy jen pro Windows. Heslem IDE Lazarus je „Write once, compile anywhere“, což v překladu znamená „Napiš jednou, zkompiluj kdekoli“. To znamená, že kód, který byl napsán např. na počítači s operačním systémem MS Windows můžeme beze změny přenést na jiný stroj s jiným operačním systémem, např. s některou distribucí Linuxu. Na tomto druhém stroji pouze znovu přeložíme zdrojový kód pomocí překladače FPC pro daný operační systém a máme hotovu verzi programu pro Linux [19]. Dalším rozdílem je, že Delphi používají kódování ANSI, zatímco Lazarus používá UTF8. Nemusíme se tedy bát, že se nám budou špatně zobrazovat znaky národních abeced vinou rozdílného kódování. Drobnou nevýhodou použití kódování UTF8 je, že nemůžeme přistupovat k jednotlivým znakům řetězce pomocí zapsání pozice znaku, který chceme číst, do hranatých závorek za jméno proměnné, tak jak je tomu zvykem v Delphi. Máme-li textový řetězec uložen v proměnné „Retezec“, můžeme v Delphi získat první znak řetězce pomocí zápisu: Retezec[1]

22

Tento zápis ve skutečnosti vrací první bajt řetězce, což je v kódování ANSI, kde každý znak zabírá jeden bajt, totéž co první znak. V IDE Lazarus toto však funguje jen pro ASCII znaky. Znaky národních abeced jsou v UTF8 kódovány více bajty, a proto by tento zápis vrátil jen část znaku [20]. K získání prvního znaku řetězce musíme použít funkci UTF8Copy: UTF8Copy(Retezec,1,1) Parametry této funkce udávají textovou proměnnou, ze které se má kopírovat, pozici ,od které má kopírování začít, a počet zkopírovaných znaků. Stejné je to i u ostatních funkcí pracujících s řetězci. Chceme-li pracovat s jednotlivými znaky a ne s bajty, musíme použít UTF8 varianty příslušných funkcí. Programátora, který začíná s IDE Lazarus, může překvapit nadměrná velikost výsledných spustitelných souborů, které vytvoří kompilátor FPC. Prázdný projekt (vytvořený pomocí File – New – Application v hlavním menu IDE Lazarus), který sestává jen z jednoho okna, na němž nejsou umístěny žádné komponenty, má po zkompilování velikost 12 MB. Důvodem je to, že do spustitelného souboru jsou umístěny informace pro debugger. Tyto informace lze odstranit pomocí programu „strip“, který je součástí IDE Lazarus a spouští se z příkazového řádku. Po použití programu „strip“ klesne velikost souboru na 1,6 MB. To je stále velká velikost, která Lazarus znevýhodňuje v porovnání se spustitelnými soubory vytvořenými například v jazyku C++. Jednoduché programy typu „Hello world“ jsou skutečně příliš velké, se vzrůstající složitostí programu však velikost spustitelných souborů roste pomaleji než u jiných programovacích jazyků [21]. EXE soubor našeho informačního systému pro zubní ordinace má velikost 25,7 MB, po použití programu „strip“ se zmenší na 3,3 MB.

4.1.2 Databázová platforma Firebird Důvodem pro zvolení databázové platformy Firebird bylo to, že se jedná o multiplatformní open source databázi, která je výkonná a podporuje pokročilé vlastnosti relačních databází, jako jsou uložené procedury, triggery či transakce [22].

23

4.2 Grafické uživatelské rozhraní systému

Obr. 7: Informační systém pro zubní ordinaci se zobrazenými doklady Vytvořený systém obsahuje jedno hlavní okno, které je zobrazeno po celou dobu běhu programu. V tomto okně se nachází hlavní menu, přes které jsou dostupné všechny funkce programu. Pod hlavním menu jsou tlačítka sloužící k rychlému vyvolání nejčastěji používaných funkcí. V dolní části hlavního okna je umístěn stavový řádek. Ten informuje o jméně a rodném čísle aktuálně vybraného pacienta a o aktuálně vybraném dokladu a jeho platnosti. Prostor mezi dolní a horní částí hlavního okna je vyplněn světle modrou barvou a slouží jako plocha pro zobrazování ostatních oken. Již při spuštění programu je v levé části otevřeno okno „Seznam pacientů“. Toto okno bude lékař pravděpodobně využívat nejčastěji, protože se přes něj vybírají pacienti a jejich doklady. Okna, která reprezentují doklady, byla navržena tak, aby jejich vzhled co nejvíce odpovídal papírové podobě dokladů. Položky, do nichž se zapisují údaje z číselníku, mají vedle svých textových polí malé tlačítko se třemi tečkami. Po stisknutí tohoto tlačítka se zobrazí okno s příslušným číselníkem a uživatel z něj může vybrat požadovaný údaj.

24

4.3 Funkce systému Přihlašování do systému: Po spuštění aplikace je zobrazeno okno, které vyzývá uživatele k zadání uživatelského jména a hesla. Po stisknutí tlačítka OK se v databázi vyhledá uživatelské jméno a vytvoří se hash zadaného hesla. Dále se zkontroluje, zda je tento hash stejný jako hash uložený v databázi. Proběhne-li kontrola úspěšně, je uživatel přihlášen a může začít pracovat se systémem. Hash hesla vytváříme pomocí hashovací funkce MD5, jejíž implementace je součástí knihoven IDE Lazarus. Ještě před zobrazením okna pro zadávání přihlašovacích údajů je kontrolováno, jestli se v databázi nalézá alespoň jeden uživatelský účet. Pokud v databázi není žádný účet (tato situace nastává při prvním spuštění aplikace), okno pro přihlášení uživatele se nezobrazí. V tomto případě je uživateli rovnou umožněno pracovat se systémem na nejvyšší úrovni oprávnění. Doporučuje se, aby uživatel hned po prvním spuštění programu vytvořil potřebné uživatelské účty. Tím bude systém chráněn před neoprávněným použitím. Zbylé funkce systému budeme popisovat na základě položek hlavního menu aplikace. Pacient – Nový: Tato volba otevře okno „Údaje o pacientovi“, kde uživatel zadá požadované údaje. Povinným údajem je zde rodné číslo, pojišťovna, u níž je pacient pojištěn, a pojistný vztah.. Ostatní údaje lze v případě potřeby ponechat nevyplněné. Pacient – Údaje o pacientovi: Zobrazí se opět okno „Údaje o pacientovi“, tentokrát s již vyplněnými textovými políčky. Jejich hodnoty budou odpovídat údajům o aktuálně vybraném pacientovi. Tuto volbu může uživatel použít, pokud bude chtít zjistit informace o pacientovi nebo pokud bude chtít údaje o pacientovi změnit. Pacient – Objednávky: Otevře okno s objednávkovým kalendářem. Zde jsou zobrazeni všichni pacienti objednaní na návštěvu zubní ordinace. Je možné přidat novou objednávku pro vybraného pacienta nebo smazat již zadanou objednávku. Pacient – Vyhledat: Hledání pacienta buď podle rodného čísla, nebo podle jména a příjmení. Pokud je pacient nalezen, bude nastaven v okně „Seznam pacientů“ jako aktuálně vybraný pacient. Pacient – Smazat: Slouží pro smazání aktuálně vybraného pacienta. Po zadání této volby je uživatel vyzván, aby potvrdil, zda chce skutečně smazat pacienta. Pokud je mazání potvrzeno, pacient je odstraněn z databáze. Doklad – Nový – Vyúčtování výkonů v ambulantní stomatologické péči: Vytvoří nový doklad typu 01s pro aktuálně vybraného pacienta. Před zobrazením dokladu je uživatel vyzván, aby zadal platnost dokladu. Ta se zadává jako dvojice datumů „Datum od“ a „Datum do“. Datum výkonů zapisovaných do dokladů je kontrolován, zda leží mezi daty udávajícími platnost dokladu. Není možné uložit doklad, na kterém některý z výkonů nespadá do období platnosti dokladu. Zadaná platnost dokladu musí odpovídat údaji „Frekvence“ z číselníku „Zdravotní pojišťovny“. Má-li pojišťovna vybraného pacienta měsíční, resp. čtvrtletní frekvenci zasílání dávek, pak i doklad musí mít měsíční, resp. čtvrtletní platnost. Doklad – Nový – Stomatologické výrobky: Vytvoří nový doklad typu 03s, který připojí k aktuálně zobrazenému dokladu 01s. Tato volba je dostupná, jen pokud je nějaký doklad typu 01s skutečně zobrazen, protože doklad „Stomatologické výrobky“ nemůže existovat samostatně. Platnost

25

dokladu se automaticky nastaví podle platnosti dokladu 01s, ke kterému je nově vytvořený doklad připojen. Poté, co je zadán kód výrobku a jeho množství na řádku dokladu, systém automaticky spočítá cenu za poskytnuté množství výrobku. Doklad – Vyhledat: Doklad je možno hledat podle jeho čísla, nebo podle jeho pořadí v dávce. Podařilo-li se najít doklad, je tento doklad zobrazen. Současně je v seznamu pacientů vybrán pacient, jemuž vyhledaný doklad patří. Doklad – Změnit na opravný: Mění charakter dokladu. Pokud je aktuálně zobrazený doklad původní, pak jej lze změnit na opravný. Byl-li aktuálně zobrazený doklad již změněn na původní, pak je v popisku této položky nikoli „Změnit na opravný“, ale „Změnit na původní“. Měnit charakter dokladu lze jen u dokladů, které jsou zařazeny v dávce, u jiných dokladů tato volba není dostupná. Opravné doklady se od původních dokladů liší svou barvou, která je tmavší. Doklad – Smazat – Smazat aktuální doklad: Po potvrzení od uživatele je smazán aktuálně zobrazený doklad. Pokud byly k dokladu připojeny další navazující doklady, jsou odstraněny také. Doklad – Smazat – Hromadné mazání dokladů: Smaže více dokladů současně podle výběru uživatele. Lze vybrat mazání dokladů ze všech uzavřených dávek, z jedné konkrétní dávky, podle platnosti dokladu nebo podle platnosti dokladu a příslušnosti dokladu k zadané pojišťovně. Dávka – Vytvořit: Vytvoří dávku zvoleného typu a charakteru pro vybranou pojišťovnu. Do dávky typu 80 jsou zařazeni všichni pacienti pojištění u dané pojišťovny, kteří byli zaregistrováni v den spadající do období vytvářené dávky. Do dávky typu 81 jsou zařazeny všechny doklady, jejichž platnost spadá do období vytvářené dávky a jsou psány na vybranou pojišťovnu a pojistný vztah. Soubor s dávkou je uložen do zvoleného adresáře. Jméno souboru je vždy KDAVKA.XXX, kde XXX je kód pojišťovny, pro kterou vytváříme dávku. Je-li ve zvoleném adresáři soubor se stejným jménem již uložen, systém se zeptá uživatele, má-li starý soubor přepsat. Dávka – Seznam dávek: Zobrazí seznam všech vytvořených dávek. Vybranou dávku je možné uzavřít nebo smazat. Při smazání dávky budou ze systému odstraněny informace o této dávce, ne však doklady do dávky zařazené. Ty budou upraveny tak, aby nepatřily do žádné dávky. Pro smazání dokladů z dávky slouží hromadné mazání dokladů z menu „Doklad“. Číselníky – Nahrát číselníky: Uživatel zvolí složku, v níž by se měly nacházet z Internetu stažené soubory s číselníky. Zda se soubory ve složce skutečně nachází, si může uživatel zkontrolovat v levé části okna „Nahrávání číselníků“, kde je zobrazen seznam souborů z vybraného adresáře. Dále je potřeba zvolit číselníky, které chce uživatel nahrát do databáze systému. Po stisknutí tlačítka „Nahrát“ začne nahrávání. Pokud uživatel zvolil nahrávání číselníku „Mezinárodní klasifikace nemocí“, musí počítat s tím, že toto nahrávání i na rychlých počítačích trvá několik desítek sekund, během nichž aplikace nereaguje na jiné pokyny. Při nahrávání zmíněného číselníku totiž dochází ke zpracování přibližně 37 000 řádků textového souboru a ukládání položek z těchto řádků do databáze. Po dokončení nahrávání číselníků je uživatel informován, zda nahrávání proběhlo úspěšně, či zda u některého z číselníků nemohlo být nahrávání provedeno. Důvodem neúspěšného nahrávání může být neexistence správně pojmenovaného souboru v zadané složce nebo to, že struktura souboru s číselníkem neodpovídá pravidlům stanoveným VZP. Číselníky – Seznam číselníků: Zobrazí seznam údajů ze všech dostupných číselníků.

26

Číselníky – Zdravotní pojišťovny: Otevře okno se seznamem položek z číselníku „Zdravotní pojišťovny“. Je možné přidávat nové položky a editovat nebo smazat vybranou položku. V seznamu pojišťoven je u sloupce „Frekvence“ uvedena jednopísmenná hodnota „M“, „Q“ nebo „J“. Tyto hodnoty reprezentují měsíční, čtvrtletní nebo jinou frekvenci zasílání dávek. Číselníky – Druh pojistného vztahu: Otevře okno se seznamem položek z číselníku „Druh pojistného vztahu“. Je možné přidávat nové položky a editovat nebo smazat vybranou položku. Lékař – Údaje o lékaři: Po zadání této volby je zobrazeno okno s údaji o lékaři. Údaje je možno v tomto okně editovat. Uživatel – Seznam uživatelů: Tato volba je dostupná uživatelům s rolí administrátora. Zobrazí okno se všemi uživatelskými jmény a seznamem rolí, které jsou uživatelskému jménu přiřazeny. Přiřazením role umožníme uživateli provádět v systému úkony stanovené pro danou roli. Pokud chce uživatel mít plnou kontrolu nad systémem, musí mu být přiřazeny všechny tři role – zdravotní sestra, stomatolog i administrátor. Součástí okna „Seznam uživatelů“ jsou tlačítka pro přidání nového uživatele, smazání uživatele a pro změnu hesla. Při měnění hesla je nutné správně zadat staré heslo, jinak není změna hesla povolena. Uživatel – Odhlásit: Odhlásí aktuálního uživatele a zobrazí okno pro přihlášení nového uživatele. Zobrazit – Seznam pacientů: Zobrazí okno „Seznam pacientů“, pokud bylo zavřeno. V tomto okně jsou vypsáni všichni pacienti. Jeden pacient je vždy aktuálně vybraný. Tento pacient je zvýrazněn modrou barvou. Pro vybraného pacienta zobrazujeme i seznam dokladů, které jsou na něj psány. Doklady typu 03s jsou zařazeny za doklad typu 01s, ke kterému jsou připojeny. Po poklepání na některý doklad ze seznamu je tento doklad zobrazen.

27

5 Závěr Cílem mé bakalářské práce bylo vytvořit informační systém podle požadavků zubního lékaře, který bude tento systém využívat. V textu byly nejprve vysvětleny pojmy z oblasti legislativy a požadavků zdravotních pojišťoven, aby i nezasvěcený čtenář získal přehled o oblasti, kterou se tato práce zabývá. Poté byly představeny některé komerční informační systémy, které dnes může stomatolog využívat. V dalších kapitolách byla prezentována analýza a návrh systému pomocí metodiky YMSA a implementace systému v integrovaném vývojovém prostředí Lazarus. Vytvořený informační systém je funkční a připravený k použití. Svým rozsahem zatím nemůže konkurovat komerčním systémům, na nichž často pracuje celý tým vývojářů po dobu několika let. Výzvou do budoucna je rozšíření systému o nové funkce i zkvalitnění podpory účtování zdravotním pojišťovnám, což je hlavní funkce systému. Poté lze uvažovat i o komerční distribuci systému.

28

Použitá literatura [1] Metodika pro pořizování a předávání dokladů VZP ČR. Verze 6.28. [pdf, online]. Praha, září 2009 [cit. 17. 11. 2009]. Dostupné na: . [2] Datové rozhraní VZP ČR – individuální doklady. Verze 6.210. [pdf, online]. [cit. 17. 11. 2009]. Dostupné na: . [3] Česká republika. Zákon č. 48/1997 Sb., o veřejném zdravotním pojištění a o změně a doplnění některých souvisejících zákonů, ve znění pozdějších předpisů [rtf, online]. 7. 3. 1997 [cit. 5. 12. 2009]. Dostupné na: . [4] FALHAR, M. Zdravotní pojišťovny a elektronická komunikace [online]. 9. 8. 2008, poslední aktualizace 13. 1. 2009 [cit. 17. 11. 2009]. Dostupné na: . [5] Jak funguje IZIP [online]. [cit. 11. 2. 2010]. Dostupné na: . [6] Ordinace PUSSA – program pro ambulance soukromých lékařů [online]. [cit. 11. 2. 2010]. Dostupné na: . [7] Pro stomatology [online]. [cit. 11. 2. 2010]. Dostupné na: . [8] Dositech [online]. poslední aktualizace 2. 2. 2010 [cit. 12. 2. 2010]. Dostupné na: . [9] Program Stomatolog a Laboratoř [online]. [cit. 11. 2. 2010]. Dostupné na: . [10] Dentist+ – více o programu [online]. [cit. 11. 2. 2010]. Dostupné na: . [11] Toad Data Modeler [online]. [cit. 4. 12. 2009]. Dostupné na: . [12] RICHTA, K. Úvod do softwarového inženýrství [pdf, online]. [cit. 23. 12. 2010]. Dostupné na: . [13] RÁČEK, J. Strukturovaná analýza systémů [pdf, online]. Brno: Masarykova univerzita, 2006. [cit. 16. 11. 2009]. Dostupné pro autorizované uživatele na: . [14] Metodika vývoje webových prezentací [online]. [cit. 27. 12. 2010]. Dostupné na: . [15] SKŘIVÁNEK, F. Co jsou normální formy? [online]. 22. 5. 2008 [cit. 26. 12. 2010]. Dostupné na: .

29

[16] RÁČEK, J., SOCHOR, J. Modelování dat [pdf, online]. 19. 10. 2009. [cit. 26. 12. 2010]. Dostupné pro autorizované uživatele na: . [17] Lazarus [online]. [cit. 27. 12. 2010]. Dostupné na: . [18] Delphi from Embarcadero [online]. [cit. 27. 12. 2010]. Dostupné na: . [19] About Lazarus [online]. 24. 6. 2009 [cit. 28. 12. 2010]. Dostupné na: . [20] LCL Unicode Support [online]. poslední aktualizace 4. 10. 2010 [cit. 28. 12. 2010]. Dostupné na: . [21] Lazarus Faq [online]. poslední aktualizace 19. 12. 2010 [cit. 28. 12. 2010]. Dostupné na: . [22] Firebird – The RDBMS that's going where you're going [online]. [cit. 28. 12. 2010]. Dostupné na: .

30

Příloha 1: Obsah CD K textu práce je přiloženo CD, které obsahuje: ● text práce ve formátu ODT, PDF a DOC ● složku s vytvořenou aplikací ● složku se zdrojovými kódy aplikace (bez spustitelného EXE souboru) ● databázi naplněnou zkušebními daty (soubor dentist.fdb)

31

Příloha 2: Pokyny ke zprovoznění aplikace Aplikace je určena pro operační systém Windows. Pro její chod je potřeba mít nainstalovaný databázový server Firebird. Ten lze zdarma stáhnout na následující adrese: http://sourceforge.net/projects/firebird/files/firebird-win32/2.1.3-Release/Firebird2.1.3.18185_0_Win32.exe/download. Až budete při instalaci serveru Firebird vyzváni k vybrání instalovaných komponent (Select component), zvolte položku „Full instalation of server and development tools“. V okně „Select additional tasks“ zvolte „Run as an Application?“. Pokud nechcete spouštět Firebird automaticky při každém spuštění operačního systému, zrušte zaškrtnutí položky „Start Firebird automatically everytime you boot up?“. V tomto případě musíte před spuštěním informačního systému pro zubní ordinace zapnout server Firebird. Ten se zapíná pomocí programu Firebird Guardian, který je dostupný z nabídky Start ve Windows. Aplikace obsahuje prázdnou databázi. Pokud chce uživatel pracovat se zkušebními daty, musí nahradit soubor s prázdnou databází (soubor dentist.fdb) ve složce „databaze“ stejnojmenným souborem v kořenovém adresáři kompaktního disku. Údaje ve zkušební databázi jsou smyšlené a neodpovídají žádným konkrétním osobám. Při použití zkušební databáze se před spuštěním programu zobrazí okno pro přihlášení uživatele. Zde je nutno zadat jako uživatelské jméno i heslo slovo „admin“. Ve složce „ciselniky“ jsou soubory stažené z webových stránek VZP. Na těchto souborech si uživatel může vyzkoušet nahrávání číselníků do systému. Novou verzi souborů s číselníky lze stáhnout na adrese http://www.vzp.cz/cms/internet/cz/Lekari/Ciselniky.

32