FJFI ČVUT v Praze POSUDEK VEDOUCÍ BAKALÁŘSKÉ PRÁCE

FJFI ČVUT v Praze POSUDEK VEDOUCÍ BAKALÁŘSKÉ PRÁCE Název práce: Autor: Vedoucí práce: Datum odevzdání:

Databáze pro nemocnici Václav Rohlík Mgr. Dana Majerová, Ph.D. červenec 2015

Cílem bakalářské práce bylo navrhnout a ve vhodném databázovém systému realizovat databázi pro nemocnici, která bude uchovávat informace o lékařích, pacientech, vyšetřeních (včetně receptů a lékařských zákroků), hospitalizacích apod. a bude zohledňovat finanční politiku mezi nemocnicí a zdravotními pojišťovnami. Textová část práce Práce je rozdělena do pěti kapitol. V první kapitole autor uvádí základní pojmy z oblasti databázových systémů (databáze, systém řízení báze dat, jazyk SQL a jeho podmnožiny). Ve druhé kapitole jsou stručně popsány 3 nemocniční informační systémy, používané v některých českých nemocnicích. Ve třetí kapitole autor shrnul požadavky na databázi pro nemocnici a stanovil integritní omezení pro data. Následně navrhl databázi s 28 tabulkami (obr. 3.7 na str. 27) a „pomocnou“ tabulkou temp_cenik_leku. Pro realizaci autor zvolil databázový systém MySQL a pro zpracování číselníků (úhrady léků, lékařské specializace, diagnózy) použil jazyk Java. Ve čtvrté kapitole autor nejprve podrobně popisuje vytvoření databáze a jednotlivých tabulek, poté v části 4.3 přibližuje čtenáři tři z celkem 9 vytvořených pohledů, v části 4.4 se věnuje podrobněji dvěma z 5 spouští (triggers) zajišťujících splnění některých integritních omezení nebo kontrolu doménové integrity (např. formát rodného čísla), dále uvádí přehled uložených procedur (část 4.5) se 3 ukázkami, a nakonec zařadil 3 vytvořené uživatelské funkce (část 4.6). Kapitola 5 obsahuje ukázky databáze s fiktivními daty jako výstup z webového klienta phpMyAdmin. Přílohami práce jsou: popis instalace serveru MySQL a způsobů přístupu k němu (příloha A), uživatelská příručka (příloha B) a CD s textem práce v PDF, zdrojovým kódem databáze, souborem pro vložení fiktivních dat a s programy v jazyku Java, které slouží pro zpracování číselníků. Poznámky k textu práce: • Kap. 2: v popisu existujících nemocničních informačních systémů jsou informace o systému IKIS jen okrajové. Chybí bližší popis jeho funkcí, resp. výhod. • Kap. 3: v ERA diagramu databáze (část 3.3) není uvedena tabulka temp_cenik_leku (je o ní zmínka pouze u procedury prirazeni_cen v části 4.5) – proč je v databázi? • Význam atributů je popsán jen u 5 „hlavních“ tabulek – to je málo (např. k čemu slouží atribut do_kdy v tabulce hodnota?). • Vztahy mezi tabulkami na obr. 3.1 (základní kostra E-R diagramu) jsou jiné než na obr. 3.7 (ERA diagram)! • Obr. 3.1 mohl být lépe uspořádán a zvětšen. • Část 3.4 (Použité technologie) patří spíše do kapitoly čtvrté, která je věnována implementaci databáze. • Kap. 4: zde oceňuji přehledné ukázky SQL k vybraným databázovým objektům a grafické znázornění pohledů. • Popis vytváření tabulek (část. 4.2) je zbytečně podrobný – autor se měl raději více věnovat vytvořeným pohledům, spouštím a procedurám. • V popisu vybraných pohledů jsou nejasnosti: např. jméno a příjmení lékaře (pohled faktura_s_doklady) se vztahuje k vyšetření nebo k zákroku? • Obrázky 4.1 až 4.3 (pohledy) neodpovídají návrhu databáze na obr. 3.7 – liší se kardinalita i parcialita vztahů! • Část 4.6 (Uživatelské funkce) měla být zařazena před 4.4, protože popisované funkce jsou používány v některých procedurách a spouštích. • Kap. 5 (ukázky výsledků dotazů) patří spíše do uživatelské příručky. • Příloha B: uživatelská příručka je psána z pohledu studenta databázových systémů (základní druhy příkazů SQL pro práci s daty), nikoli z pohledu osob, které s databází budou pracovat. Jak např. lékař vloží nového pacienta? • V části B.4 není uvedeno, že u posledních 3 příkazů (LOAD) v souboru finalniverze_bc.sql je potřeba změnit cestu k souborům s číselníkem diagnóz, specializací a cen léků. 1

Návrh databáze Na začátku autor identifikoval hlavní entity: osoba, zdrav. pojišťovna, vyšetření, oddělení,... Mezi ně patřily také tabulky lék a úkon, avšak při bližším seznámení se s finanční politikou ve zdravotnictví bylo potřeba na tyto dvě entity odkazovat z tabulky doklad, a proto byly sloučeny do tabulky zdravotni_polozka, ke které následně vznikly tabulky vlastnost a hodnota (a seznam povolených vlastností léků/úkonů uchovávaný v tabulce povoleni). Při konzultacích nad návrhem databáze jsem studentovi doporučila vytvořit tabulku adresa bez čísla popisného, aby se snížilo množství dat v databázi. Bylo by vhodné nastavit trojici město-ulice-PSČ jako unikátní, protože by se to dalo využít při vkládání nové osoby (resp. pojišťovny) – uživatel by nemusel zjišťovat hodnotu klíče. (Pozn.: nestačí unikátní dvojice město-ulice, protože ve výjimečných případech PSČ závisí i na čísle popisném – u velkých měst může ulice protínat více městských částí). Databáze celkem obsahuje 29 tabulek (z toho jedna je „pomocná“ bez vazby na ostatní tabulky!). Autor správně dekomponoval vztahy s kardinalitou M :N a identifikoval potřebné atributy. V tabulce osoba však postrádám atribut pohlaví, které je ve zdravotnictví často využíváno. Dále mám výhrady k datovým typům některých atributů: • ceny jsou ukládány jako řetězec! Naštěstí MySQL skrytě provádí konverzi, takže SUM(řetězce) skutečně vrátí součet; • nesouhlasí délka řetězcových typů u týchž položek: atribut temp_cenik_leku.nazev_leku má VARCHAR(255), kdežto jemu odpovídající zdravotni_polozka.nazev_zp má VARCHAR(200); dále temp_cenik_leku.cena_leku má VARCHAR(11), kdežto uhrada.cena má VARCHAR(45); • atribut pracovni_doba.den měl být typu ENUM (případně odkazovat na tabulku s povolenými názvy dnů), podobně i atribut pojistovna.frekvence_zasilani_faktur. Dále by bylo vhodné vyžadovat unikátní hodnoty následujících atributů: název typu zdravotní položky, název zdr. položky, název oddělení, kód specializace, kód diagnózy, číslo receptu. Zprovoznění databáze Databázi jsem zprovoznila v MySQL verze 5.5.25a s využitím souboru finalniverze_bc.sql (kopírovala jsem příkaz po příkazu a jednotlivé procedury jsem zkoušela volat ihned po vytvoření). U příkazů LOAD DATA bylo potřeba změnit cestu, příp. i název souborů, jinak vše proběhlo v pořádku. Nedostatky v souboru finalniverze_bc.sql: • příkazy pro vytvoření uživatelských funkcí by měly předcházet příkazům pro vytvoření procedur a spouští, které tyto funkce používají (bez funkcí nelze spustit procedury faktura_doklady a lekar_prac_vys); • chybí příkazy pro vložení „předvyplněných“ dat (např. tabulka typ_polozky by měla obsahovat záznamy ’lék’ a ’úkon’ se správným klíčem – závisí na tom procedura faktura_doklady! Dále by mělo být zadáno a povoleno několik vlastností pro léky a další pro úkony – viz část A.3.2). Dále jsem použila příkazy ze souboru fiktivni_data.sql pro vložení dat. Vše proběhlo úspěšně, až na volání procedur lekar_prac_vys (generuje chybu „Lékař nemá pracovní dobu“ ) a faktura_doklady (oznámí varování, protože funkce vypocet_celkove_castky vrací NULL). Fiktivní data porušují integritní omezení: doklady č. 1 a 3 mají chybné číslo vyšetření (má být 2 v obou případech), tři recepty jsou prázdné (id: 1, 3 a 4), k úkonu č. 5 není záznam v tabulce uhrada ani k němu není doklad (úkon patří k vyšetření č. 3). Vytvořené pohledy (views) Autor vytvořil celkem 9 pohledů. Zobrazují především souhrnná data související s lékaři nebo zdravotními položkami. K vytvořeným pohledům mám několik poznámek:

2

• názvy pohledů jsou voleny většinou v jednotném čísle, ačkoliv je vhodnější množné číslo (pohledy sdružují více informací o příslušných objektech); • je vhodné, aby každý pohled obsahoval i jednoznačnou identifikaci všech zobrazovaných objektů (id), aby se případně mohl následně využít pro spojení s jinými tabulkami/pohledy. Toto není realizováno důsledně (často chybí např. id zdravotní položky nebo id lékaře); • některé pohledy mají nastaveno implicitní řazení, jiné nemají – autorův styl práce není jednotný; • většina pohledů nadbytečně používá vnější spojení tabulek (LEFT JOIN) – při vhodném pořadí spojování tabulek by se dalo mnoho vnějších spojení ušetřit, a tím zrychlit zobrazení dat; • některé pohledy nepotřebují všechny uvedené tabulky (v pohledu lekar_info_vysetreni lze vynechat tabulku pacient, v pohledu faktura_s_doklady je zbytečná tabulka pojistovna, pohled zdravotni_polozka_cena nepotřebuje tabulku hodnota a pohled zdravotni_polozka_info se obejde bez tabulky povoleni – má vztah přímo s tabulkou typ_polozky); • pohled faktura_s_doklady zobrazuje duplicity (např. pokud existuje více úhrad k dané položce); • pohled lekar_pracovni_doba zobrazuje duplicity (není vhodné spojení s pohledem udaje_osoby, protože tam může být pro každou osobu N kontaktů); • pohled zdravotni_polozka_cena nezobrazuje typ zdravotní položky, pokud nemá přiřazenou žádnou vlastnost (dal se využít přímý vztah s tabulkou typ_polozky). Postrádám pohled, který by zobrazoval doklady k jednotlivým vyšetřením. Také by bylo vhodné udělat pohled pro recepty s předepsanými léky. Dále by mohly existovat „statistické“ pohledy – např. pohled zobrazující ke dvojici lékař-úkon celkový počet a poslední datum. Vytvořené uživatelské funkce (functions) Autor vytvořil tři uživatelské funkce, které jsou využívány v procedurách nebo ve spouštích. Poznámky: • Funkci dencesky, kterou využívá procedura lekar_prac_vys, lze nahradit dvojicí příkazů: SET LC_TIME_NAMES=’cs_CZ’; SELECT DATE_FORMAT(den_v_tydnu,’%W’) INTO denceskyslovy;. Dále funkce vrací VARCHAR(9), který je poté porovnáván s VARCHAR(25) – nejednotnost. • Funkce vypocet_celkove_castky by místo podmínky platnost_od = od_kdy měla obsahovat od_kdy BETWEEN platnost_od AND platnost_do, protože platnost faktury se nemusí přesně shodovat se dnem začátku platnosti úhradové vyhlášky. Myslím si, že pro výpočet správné ceny by bylo ideální navrhnout funkci, která by zjistila cenu podle data úkonu (resp. vystavení receptu). Případně přidat redundantní atribut cena do tabulky doklad. • Funkce zjisti_pocet_hospitalizaci nezapočítává pacienty, kteří nemají zadané datum konce hospitalizace (atribut do v tabulce hospitalizace má povoleno NULL). Vzhledem k tomu, že některé procedury potřebují zjišťovat hodnotu primárního klíče, tak by bylo vhodné vytvořit další funkce – např. zjisti_id_adresy nebo je_pacient (vracející ano/ne). Vytvořené spouště (triggers) Spouští je vytvořeno celkem pět. Poznámky k některým spouštím: • psc_ok: regulární výraz mohl být přesnější (složitější), jelikož první číslice nabývá v ČR pouze hodnot 1 až 7). • rodne_cislo_kontrola: některá chybová hlášení jsou bez diakritiky. • hospitalizace_vyplneno_zle: spoušť se nezabývá situací, kdy konec hospitalizace je NULL. • vysetreni_kontrola: kontrola překryvu vyšetření by měla být také pro pacienta, nejen pro lékaře. Vytvořené spouště nepokrývají plně potřeby systému. Např. chybí spoušť pro automatické generování dokladu k předepsanému léku nebo provedenému úkonu (AFTER INSERT pro obsah a pro zakrok), dále kontrola existence ceny léku/úkonu před přidáním obsahu/zákroku (BEFORE INSERT pro obsah/zakrok), kontrola (resp. zákaz) smazání dokladu v již zaplacené faktuře (BEFORE DELETE pro 3

doklad), automatické smazání dokladu při odstranění léku/úkonu z obsahu/zákroku (AFTER DELETE pro obsah a zakrok) a v neposlední řadě také přepočítání celkové částky faktury po odstranění dokladu (AFTER DELETE pro doklad). Není realizováná žádná spoušť pro UPDATE. Vytvořené procedury (stored procedures) Autor vytvořil celkem 13 uložených procedur, které se starají o vkládání dat. Oproti pohledům (využívajícím vnitřní a vnější spojování tabulek) je v procedurách používán jedině kartézský součin, který je pomalejší. Procedura pridej_adresu po úspěšném skončení vypíše id vloženého záznamu, ostatní procedury vkládající do číselníků se tak nechovají (přitom je to užitečná informace). Názvy některých procedur mohly lépe vystihovat jejich činnost. Poznámky k procedurám: • Procedury pridej_pojistovnu a pridej_osobu nejsou uživatelsky přívětivé, neboť vyžadují znalost id adresy. Stačilo trojici ulice-město-psč nastavit jako unikátní (v tab. adresa) a příslušný vstup procedury nahradit těmito třemi. • Procedura pridej_osobu mohla mít ještě jeden vstup „pacient“ (ano/ne) a v kladném případě by automaticky vložila odpovídající záznam do tabulky pacient. Případně mohla existovat procedura pridej_pacienta, která by vložila osobu (pokud neexistuje), a poté z ní udělala pacienta. Analogicky by mohla existovat procedura pridej_lekare. • Procedura pridej_recept by měla zajistit, že spolu s receptem vznikne alespoň jeden předepsaný lék, aby bylo splněno integritní omezení „recept obsahuje 1-N léků“ . • Procedura konrola (vhodnější název by byl pridej_hodnotu_vlastnosti_zp) má chybný datový typ vstupu zadana_hodnota – místo VARCHAR(255) měl být LONGTEXT. • Procedura prirazeni_cen (výstižněji pridej_ceny_leku) mohla automaticky cenu nastavit pro všechny existující pojišťovny. • V proceduře cena_ukon (výstižněji pridej_cenu_ukonu) se vkládá pomocí dotazu SELECT – nedalo se vložit přímo pomocí VALUES? Nemohlo být pro automatické vkládání využito tabulky hodnota? • Procedura faktura_doklady (výstižněji pridej_fakturu_a_prirad_doklady) mohla místo složitých dotazů využít pohled zdravotni_polozka_cena (ten by však musel obsahovat id zdravotní položky). • Vstupní kód pojišťovny je v proceduře ignorován (podle popisu to má být faktura za oddělení pro určitou pojišťovnu)! • Je zbytečné v rámci obou rozsáhlých příkazů SELECT porovnávat id typu zdravotní položky s konkrétní hodnotou – je to dáno tím, že úkony souvisí s tabulkou zakrok a léky s tabulkou obsah. • Při porovnávání časových údajů DATETIME<=DATE bude podmínka splněna jen v případě, že jde o dva různé dny nebo že DATETIME obsahuje čas 0:00:00. Pokud je výsledkem spojení dotazů (SELECT ... UNION ALL SELECT ... ) prázdná množina, tak příkaz UPDATE provede přiřazení všech dokladů k dané faktuře!!! Tato důležitá procedura se tedy chová jinak než by měla. • Procedura lekar_prac_vys (výstižněji pridej_vysetreni) kontroluje, zda začátek vyšetření spadá do pracovní doby lékaře (konce vyšetření si nevšímá, což odpovídá praxi), ale nekontroluje, že začátek a konec vyšetření je ve stejný den (řešení: místo dvou vstupů typu DATETIME dát jeden typu DATE a dva typu TIME). Dále je zde použita funkce DATE_FORMAT pro údaj typu TIME (pracovní hodiny lékaře) – v MySQL 5.5.25 jde o nekorektní vstup, výsledkem je NULL, následkem čehož je tato procedura nefunkční. Pozn.: dva dotazy do tabulky pracovni_doba se dají sloučit do jednoho (tj. SELECT od, do_kdy INTO od_kdy_pracuje, do_kdy_pracuje FROM...). • Procedura pridej_pracovni_dobu má nelogické pořadí vstupů: čas od, den, RČ lékaře, čas do (vhodnější je: RČ, den, od, do). Tato procedura chybně kontroluje existenci osoby namísto existence lékaře (záznam v tabulce lekar). • Procedury pridej_kontakt a pridej_pracovni_dobu počítají s tím, že rodné číslo (vstup) je v rámci tabulky osoba unikátním údajem. Toto ale není v databázi zajištěno!

4

Zpracování číselníků pomocí Javy Při zpracování číselníku specializací je potřeba brát ohled nejen na čárky, ale i na uvozovky. Prosté rozdělení řetězce podle čárek způsobilo, že specializace 989 má název oříznutý. Vhodné by bylo využít regulárních výrazů.

Celkové hodnocení práce Text práce je přehledný, má dobrou typografickou úpravu (až na ukázky SQL v rámci odstavců) a obsahuje jen malé množství chyb a překlepů. Pozitivně hodnotím ukázky kódu SQL a grafické znázornění pohledů. Drobné výhrady mám k některým nepřesným formulacím (především v implementaci) a velkou výhradu k uživatelské příručce, která z pohledu lékaře není využitelná. Navržená databáze by se po úpravách datových typů atributů (především pro peněžní údaje) mohla stát základem nemocničního informačního systému. Pozitivně hodnotím některé vytvořené pohledy, spouště a procedury i autorův nápad využít uživatelské funkce. Avšak myšlenka návaznosti procedur na funkce nebyla realizována důsledně – autorův styl práce mi připadá chaotický. Některé důležité procedury nefungují (viz výše), pohledy by měly obsahovat i původní primární klíče důležitých entit a spouště zdaleka nepokrývají všechny potřebné činnosti. Praktická část práce pravděpodobně vznikala v časové tísni, protože výběrové dotazy ve většině pohledů a procedur se daly optimalizovat. K odstranění chyb by také pomohlo testování s pečlivě navrženou sadou fiktivních dat. Celkově navrhuji bakalářskou práci hodnotit známkou uspokojivě (D).

V Děčíně dne 26. srpna 2015

Dana Majerová

Dotazy k obhajobě: 1. Mohla by být tabulka faktura realizována jen jako pohled? 2. Jak se na celkové částce v tabulce faktura projeví situace, kdy faktura obsahuje doklad ke zdravotní položce, jejíž cena není v tabulce uhrada zadána vůbec, resp. je zadána s datem např. rok starým? 3. Atribut frekvence_zasilani_faktur (tabulka pojistovna) nemá využití. K čemu měl sloužit? 4. Jak se liší datový typ BIT (ve spoušti psc_ok) a TINYINT(1) použitý pro jeden atribut tabulky vysetreni? 5. Podle čeho jste stanovil hodnoty kódů SQLSTATE v procedurách?

5

Posudek oponentky bakalářské práce Název práce: Autor: Vedoucí práce:

Databáze pro nemocnici Václav Rohlík Mgr. Dana Majerová, Ph.D.

Cílem práce bylo navrhnout a implementovat databázi pro nemocnici, která by umožňovala správu pacientů v rámci jedné nemocnice a řešila úhrady léků a zákroků mezi nemocnicí a zdravotními pojišťovnami. Samozřejmostí by mělo být zajištění importu dat od zdravotních pojišťoven ve formě číselníků. Text práce je rozdělen do pěti částí. Student nejprve popisuje databázový systém a jazyk SQL, analyzuje problém a popisuje existující nemocniční systémy. Na základě této studie stanovil požadavky na vlastní databázi, díky kterým vznikl návrh databáze obsahující celkem 29 tabulek. Student se zaměřil na podrobný popis pěti nejdůležitějších (bohužel intuitivních) tabulek. Důvod existence mnochých dalších tabulek tak zůstane čtenáři neznámý. Bylo by vhodné vysvětlit, proč jsou atributy vypadající na první pohled jako číselné typu řetězec (cena v tabulce uhrada, celkova_castka v tabulce faktura, . . . ). Není zřejmé, proč je v tabulce obsah, která popisuje obsah receptu, atribut pocet_ks obsahující řetězec udávající např. počet a sílu tablet. Chápala bych jej spíše jako počet předepsaných balení léku, jak jsme tomu z receptů zvyklí. Logičtější by bylo, kdyby byly údaje jako počet tablet a jejich síla v balení daného léku určeny jednoznačně identifikačním číslem léku. Bohužel tento požadavek není možné splnit, neboť při studiu číselníku léků vysledek_lek.txt zjišťuji, že student ze souboru dodaného pojišťovnou HVLP150501.csv tyto důležité údaje zahodil a ponechal pouze název léku a jeho cenu. V pomocné tabulce s léky se tedy následně dozvíme, že např. stejný lék PURINOL 100 MG stojí jenou 42,86 Kč a podruhé 85,71 Kč. Tento fakt je dán počtem tablet v balení, což je ovšem studentem zanedbaná hodnota. Z přiloženého souboru by bylo možné získat také spoustu dalších užitečných údajů, jako je síla léku, forma léku (tablety, injekce,. . . ), typ balení (blistr, ampule,. . . ) a další. Použitelnost některých atributů snižuje také ukládání více hodnot, přestože to není nutné (do atributu hodnota v tabulce hodnota je vkládáno ’45 minut’, ’20 bodů’, . . . ). Návrh databáze je doplněn několika ER-diagramy, které však obsahují rozdílný typ relací mezi tabulkami, přestože popisují stejnou databázi (obr. 3.1 a 3.7, v pohledu 4.3 se následně vazba mezi tabulkami osoba a lekar změní dokonce z typu 1:1 na 1:N atp.). Databáze je implementována v MySQL s tím, že kromě vlastních tabulek se student zaměřil na vytvoření několika pohledů, spouští, uložených procedur a uživatelských funkcí. Data od zdravotní pojišťovny nejprve transformuje do podoby, kterou je možné importovat do databáze ve formě číselníků. Zde není zřejmé, proč se syntaxe uložených procedur liší od použitých principů u funkcí či pohledů. Např. funkce pracovni_doba_prekryti nebo vysetreni_kontrola používají prostého porovnání dvou hodnot typu datetime, ale procedura lekar_prac_vys používá složitého přetypování hodnot typu datetime, v důsledku čehož není funkční. Pracuje totiž pouze s hodinou ordinační doby a hodinou počátku vyšetření, minuty, popř. sekundy zanedbává. Také nekontroluje konec pracovní doby nebo alespoň maximální délku vyšetření, díky čemuž je možné uložit vyšetření trvající 1 měsíc. Další problémy plynou např. z chybné implementace funkce zjisti_pocet_hospitalizaci, která ignoruje pacienty bez uvedeného konce hospitalizace. Díky tomu nemůže tedy fungovat ani spoušť hospitalizace_vyplneno_zle a do jedné místnosti bude možné hospitalizovat libovolný počet pacientů bez ohledu na její kapacitu. Také procedura prirazeni_cen nemůže nikdy fungovat správně, neboť jsou v ní pro všechny léky z tabulky zdravotni_polozka ukládány ceny do tabulky uhrada. Pokud je však povolena duplicita názvu léku v dočasné tabulce temp_cenik_leku díky vynechání údaje o počtu tablet nebo objemu injekcí,

o kterém jsem hovořila dříve (např. PURINOL 100 MG se dodává v počtu 50 nebo 100 tablet v balení s různou cenou), není možné správně přiřadit názvu léku jeho cenu. Volání procedury končí neošetřenou chybou týkající se zjištěné duplicity údajů. Poslední částí je naplnění databáze fiktivními daty. Bohužel si zde student příliš nelámal hlavu věrohodností uložených dat, takže se mezi zdravotními pojišťovnami objeví dvakrát pojišťovna VZP, pacienta ve věku 43 let vyšetřuje coby dítě s bolestí v krku s délkou vyšetření 1 měsíc a pacient s bolavým kotníkem se nejprve dostaví na kontrolu a teprve za týden si kotník opravdu pohmoždí. Snižuje tím hodnotu vykonané práce. V příloze práce se nachází uživatelská příručka, která měla být dle zadání práce pojata z pohledu jednotlivých činností a osob. Tento bod zadání nebyl splněn, neboť pro lékaře či sestru je příručka zcela nepoužitelná. Při testování aplikace jsem objevila několik dalších chyb ve funkčnosti a logice navržené databáze. • Lékař sice může mít více specializací, ale může v nemocnici pracovat pouze na jednom oddělení. Jeho ordinační doba se tedy vztahuje pouze na jedno dané oddělení, což většinou neodpovídá realitě. • V databázi zřejmě také není ošetřeno, zda zákrok může provést pouze lékař, který má v dané chvíli ordinační dobu na daném oddělení. Díky tomu se dozvíme, že MUDr. Cyril Judek pracující pouze na chirurgii provedl operaci na traumatologii, přestože v tu chvíli neměl pracovní dobu a na daném oddělení nepracuje. • Podle textu práce je správce databáze donucen každý měsíc importovat ceník léků a následně zavolat proceduru prirazeni_cen s uvedením kódu pojišťovny, přestože student na str. 40 sám uvádí, že ceny léků jsou pro všechny pojišťovny stejné. Při přiřazování cen jednotlivým lékům z tabulky zdravotni_polozka s následným uložením hodnoty do tabulky uhrada není údaj o pojišťovně pacienta nijak použit. Měl by tedy nejspíš být v tabulce uhrada nepovinným parametrem a v proceduře prirazeni_cen by tak nemusel figurovat vůbec. • Při volání procedury faktura_doklady(111,’2015-06-01’,’2015-06-30’,3); ze souboru s fiktivními daty vrací tato procedura NULL, protože na oddělení č. 3 nebyl zatím žádnému pacientovi předepsán lék ani proveden lékařský úkon. Ukázka použití této procedury je tedy nevhodná. • Po zavolání procedury faktura_doklady dojde k přepsání již existujících dokladů přiřazených k jiné faktuře v tabulce doklad, pokud je nová faktura vystavována pro stejné oddělení a za stejné období (místy dokonce i pro různá období). Kód pojišťovny nerozhoduje vůbec, díky čemuž dochází k postupnému přepisování již existujících dokladů přiřazených k jiným fakturám, což v budoucnosti znemožňuje opětovné zavolání funkce vypocet_celkove_castky. Navíc jsou pojišťovnám fakturovány částky za ošetření pacientů cizích pojišťoven. Téma bakalářské práce je velice zajímavé, avšak přestože se student omezil pouze na chod jedné nemocnice, je zpracování dané problematiky nedostatečné. Text práce je sice na první pohled napsán přehledně, avšak důležité informace týkající se návrhu a realizace aplikace jsou čtenáři často utajeny. Aplikace je funkční pouze z části, z mého pohledu došlo k chybnému návrhu některých tabulek databáze, mnohé funkce či procedury nefungují správně. Uživatelská příručka není pro lékaře a sestry použitelná, čímž student nesplnil jeden z bodů zadání bakalářské práce. Práci navrhuji hodnotit ještě stupněm E (dostatečně). V Jílovém, dne 27. 8. 2015

Ing. Kateřina Horaisová, Ph.D.