Určení kompatibility doporučení: porovnání klinických doporučení se záznamem pacienta

Rozměr: px
Začít zobrazení ze stránky:

Download "Určení kompatibility doporučení: porovnání klinických doporučení se záznamem pacienta"

Transkript

1 Original Article cs1 Určení kompatibility doporučení: porovnání klinických doporučení se záznamem pacienta Arnošt Veselý 1,2, Jana Zvárová 2 1 Katedra informačního inženýrství, Česká zemědělská univerzita, Praha, Česká republika 2 Oddělení lékařské informatiky, Ústav informatiky AV ČR, Praha, Česká republika Shrnutí Snaha o zlepšení lékařské péče a usnadnění její standardizace vedla ke vzniku celé řady klinických doporučení. Klinická doporučení jsou nejdříve napsána v běžném jazyce a teprve potom jsou převedena do formálního modelu, který může být implementován na počítači. Pokud jsou všechna relevantní data o léčení pacienta uložena v jeho Elektronickém Zdravotním Záznamu (EZZ), formální model doporučení, alespoň v principu, může být porovnán s daty pacienta a může být zjištěno, zda byl pacient léčen ve shodě s doporučenou klinickou praxí. V tomto článku předkládáme algoritmus, který umožňuje porovnat pacientův zdravotní záznam s modelem EGLIF (rozšířeným modelem GLIF). EGLIF vznikl rozšířením standardního GLIF modelu a byl navržen proto, aby toto porovnávání bylo pohodlnější a transparentnější. Kontakt: Arnošt Veselý Katedra informačního inženýrství, Česká zemědělská univerzita Adresa: Kamýcká 129, Praha 6, Česká republika E mail: Srovnávací algoritmus byl navržen pro GLIF modely s jednoznačnými rozhodovacími uzly a pro takové zdravotní záznamy pacienta, které obsahují veškerou relevantní informaci o jeho léčení. Algoritmus lze snadno modifikovat také pro modely s libovolnými rozhodovacími uzly. Avšak porovnání GLIF modelu nebo EGLIF modelu s neúplným datovým záznamem pacienta je podstatně obtížnější úkol. Jak řešit tento obtížný úkol je naznačeno v závěru. Klíčová slova Klinická doporučení, GLIF model, elektronický zdravotní záznam, systém varování, algoritmus průchodu doporučeními EJBI 2012; 8(1):cs1 cs13 zasláno: 12. prosince 2011 přijato: 12. března 2012 publikováno: 15. června Úvod Klinická doporučení (KD) obsahují soubor léčebných rozhodnutí, které mají lékaři pomoci dospět ke správným diagnostickým, terapeutickým a dalším klinickým rozhodnutím. Jejich účelem je zajistit vysokou kvalitu klinické praxe [1]. KD mají zprvu podobu textových doporučení a jsou vytvořeny skupinou lékařů, expertů v dané oblasti, kteří byli k tomuto účelu vybráni místní vědeckou autoritou, například lékařskou společností nebo národní zdravotní institucí. Několik mezinárodních organizací vytváří a udržuje webová úložiště doporučení týkajících se různých oblastí lékařské péče [2, 3]. Rovněž v České republice byl vytvořen webový Katalog klinických doporučení [4, 5]. Vývoj klinických doporučení je značně nákladný proces. Nejdříve musí být vytvořena papírová forma doporučení. Papírová forma musí být potom přeložena do jazyka, který je schopen doporučení reprezentovat a který může být posléze interpretován počítačem. Tento proces je v obecných rysech popsán v pracích [6, 7, 8, 9] a [10, 11]. Více výzkumných týmů navrhlo způsob překladu doporučení do počítači srozumitelného formátu. Dobrý přehled o v literatuře popsaných metodách překladu a o získaných výsledcích lze získat z [12]. Zde zmíníme jen některé z nich. V článku [13] jsou popsány úspěšné počítačové implementace dvou kardiovaskulárních doporučení a doporučení, které se týkají hypercholesterolemie. Doporučení byla reprezentována v GLIF formátu a spojena s Elektronickým zdravotním záznamem. GLIF je prostředek, který byl vyvinut speciálně pro formalizaci lékařských doporučení. Také pojmy a prostředky, které byly vyvinuty pro modelování business procesů, se ukázaly být užitečné. Článek [14] porovnává vývoj doporučení s modelováním podnikových procesů a popisuje některé jejich silné a slabé stránky. Je třeba, aby lékařská doporučení byla vytvořena experty z různých oblastí. Články [15] a [16] navrhují pac 2012 EuroMISE s.r.o. EJBI Volume 8 (2012), Issue 1

2 cs2 Veselý, Zvárová Určení kompatibility doporučení ralelní strategii vývoje doporučení, kdy multidisciplinární tým kooperuje při vytvoření jejich textové i počítačem interpretovatelné formy. Tato strategie paralelního vývoje textové podoby doporučení a jejich formálního modelu se ukázala být velmi úspěšnou. Paralelní vývoj dovolil eliminovat vágní pojmy nebo chyby již v prvním stadiu vývoje doporučení. Přehled počítačem interpretovatelného formalizmu a způsobů modelování doporučení byl prezentován v pracích [1, 17] a [18]. Arezzo systém pro reprezentaci doporučení používá PROforma jazyk [19, 20]. Arezzo se skládá ze tří částí nazvanými Composer, Tester a Peformer. Odvozovací stroj Performeru prochází doporučení, při čemž bere v potaz pacientova data uložená v zdravotní databázi pacienta. DeGel (Digital Electronic Guidelines Library) je webově založená modulární a distribuovaná architektura, která usnadňuje konverzi textové formy doporučení do reprezentačního jazyka Asbru [21]. GLARE (Guidelines Acquisition, Representation and Execution) používá reprezentaci založenou na grafech [22, 23]. Uzly grafu reprezentují atomické akce. Existují čtyři druhy základních akcí: dotazy, které umožňují vstup informace do systému, akce, které reprezentují činnost, kterou je třeba vykonat, rozhodovací akce, které reprezentují výběr mezi alternativními akcemi prováděný na základě souboru podmínek a závěry, které umožňují popis důsledků rozhodnutí. NewGuide prostředek pro modelování klinických doporučení [24, 25] požívá pro reprezentaci jazyk GUIDE, který je založen na Petriho sítích [26]. To dovoluje modelovat paralelní procesy a časová data. SAGE (Standards-based Sharable Active Guidelines Environment) byl vytvořen ve spolupráci několika výzkumných skupin ve Spojených státech [27]. Hlavním cílem bylo zakódovat doporučení pomocí některé standardní metody reprezentace znalostí a ulehčit tak jejich využití v různých klinických informačních systémech. Reprezentace doporučení je založena na množině Protégé tříd a plug-inech. Lékařské léčebné postupy jsou specifikovány grafy aktivit, které se skládají z kontextových uzlů specifikujících klinické prostředí a relevantní vlastnosti pacienta, rozhodovacích uzlů, akčních uzlů a routovacích uzlů, které slouží k větvení a synchronizaci. HeCaSe2 (Health Care Services release 2) je platforma založená na přístupu známém z agentních systémů [28]. Systém není centrálně řízen. Agenti jednají nezávisle s použitím jejich vlastní znalosti a dat a plní různé úkoly. Agent doporučení provádí všechny akce, které se vážou ke klinickým doporučením. Klinická doporučení jsou reprezentována pomocí representačního jazyka PROforma [20]. Lékařské termíny používají terminologii UMLS a jsou součástí definované ontologie. V tomto článku používáme Guidelines Interchange Format (GLIF). GLIF je výsledkem spolupráce různých institucí a universit ve Spojených státech. Popis jeho verze 2.0 (GLIF2) lze najít v [29] a popis novější verze 3.0 (GLIF3) v [30]. Guidelines Execution Engine (GLEE), což je prostředek pro průchod doporučeními zakódovanými v GLIF3 formátu, je popsán v [31]. Pro reprezentaci doporučení GLIF zavádí procesně orientovaný model. Model může být reprezentován orientovaným grafem. Uzly grafu reprezentují jednotlivé kroky (elementární činnosti) doporučení a hrany grafu znázorňují následnost jednotlivých kroků. Kroky doporučení jsou různého typu. Krok doporučení může být: akční krok (action step), rozhodovací krok (decision step), krok větvení (branch step), synchronizační krok (synchronization step) a krok stavu pacienta (patient state step). Akční kroky specifikují klinické akce, které mají být realizovány. Může to být aplikace nějaké terapie, provedení nějakého vyšetření nebo měření atd. Akční krok může být také názvem jiných doporučení, které podrobněji specifikují vykonání dané akce. Rozhodovací kroky se používají pro podmíněné větvení. Rozhodovací krok specifikuje kritéria pro jednotlivá alternativní rozhodnutí. Kroky větvení a synchronizační kroky zavádějí do modelu paralelismus. Kroky, které následují po kroku větvení a které jsou na různých větvích mohou být vykonávány paralelně. Větve, které vycházejí z určitého kroku větvení, se nakonec spojí v jednom synchronizačním kroku, kde jsou synchronizovány. Synchronizace znamená, že akce, které následují po synchronizačním kroku nemohou být prováděny dokud není splněna synchronizační podmínka. Jednoduchá synchronizační podmínka může například vyžadovat, aby všechny akce, specifikované na větvích mezi krokem větvení a synchronizačním krokem, byly splněny. Krok stavu pacienta pouze pojmenovává stav, ve kterém se pacient nachází. Je mnoho výhod, které použití klinických doporučení může přinést. 1. KD mohou zlepšit kvalitu klinických rozhodnutí, neboť KD pomáhají lékařům využít klinickou znalost vztahující se k určitému klinickému stavu pacienta. 2. KD mohou být efektivně použity pro výuku, protože umožňují rychlou distribuci aktualizací a změn. 3. Odborníci z oblasti zdravotní péče mohou použít KD ke srovnání standardů zdravotní péče v různých institucích. 4. Pokud relevantní informace o pacientovi je uložena v elektronickém zdravotním záznamu (EZZ) pacienta, potom je možné kontrolovat, zda použitá léčebná procedura je v souladu s doporučenými standardy léčení. V tomto článku se zaměříme na výhody, které jsou zmíněny v bodě 4. První návrhy jak srovnávat data pacienta s formalizovanými doporučeními jsme popsali v [32, 33, 34] a [35]. Zde pokročíme dále a navrhneme algoritmus, který je schopen navržený způsob porovnání realizovat. Předpokládáme, že veškerá relevantní informace o léčení pacienta je uložena v pacientově EZZ. Naším úkolem je navrhnout metodu jak porovnat pacientova data EJBI Volume 8 (2012), Issue 1 c 2012 EuroMISE s.r.o.

3 Veselý, Zvárová Určení kompatibility doporučení cs3 uložená v EZZ s léčebnými standardy, popsanými v klinických doporučeních a zjistit, zda pacientova data v EZZ jsou s nimi v souladu. Porovnání může být provedeno ex post nebo on-line. V případě porovnání ex post je k dispozici pacientův zdravotní záznam za dlouhý časový úsek a úkolem je zjistit, zda pacient byl léčen v souladu s odpovídajícím léčebným standardem popsaným v KD. Při porovnávání on-line pacientův zdravotní záznam je porovnáván se standardem pokaždé, když je záznam aktualizován zápisem nové datové položky. On-line připomínkový systém, který varuje lékaře, pokud jeho akce není v souladu s léčebným standardem, může být založen právě na tomto on-line porovnávání. Algoritmus porovnávání navržený v tomto článku předpokládá, že jsou splněny následující dvě podmínky. 1. EZZ obsahuje veškerou relevantní informaci, to znamená, že všechny akce lékaře během léčby pacienta jsou do EZZ zaznamenány. 2. Všechna doporučení obsahují rozhodovací kroky, ve kterých musí být přijato rozhodnutí jak pokračovat dále. Podle pacientova stavu, který je určen hodnotami již vyšetřených parametrů, jsou některé alternativy doporučeny a některé ne. Předpokládáme, že tato doporučení, jak pokračovat, jsou jednoznačná. To znamená, že podle KD v každém rozhodovacím kroku jedna a pouze jedna alternativa musí být vybrána. Doporučení s touto vlastností nazýváme striktní. Navržený srovnávací algoritmus generuje chybovou hlášku pokud lékař nesleduje doporučeními jednoznačně stanovenou alternativu. Klinická doporučení v rozhodovacích krocích ale obvykle doporučují více než jednu alternativu. Taková doporučení nazýváme nestriktní. Srovnávací algoritmus může být upraven tak, aby mohl být použit i pro nestriktní doporučení. Jak lze tuto úpravu udělat je vysvětleno v závěru. Při léčbě pacienta se důležitá doporučení často týkají velikosti časových intervalů mezi dvěma akcemi nebo mezi nějakou akcí a jejím opakováním. Například nějaké vyšetření může být opakováno až po uplynutí alespoň jednoho týdne nebo nejdéle do dvou měsíců atd. V GLIF modelu podmínku, kterou interval mezi dvěma následujícími akcemi musí splňovat, lze zadat pomocí vloženého rozhodovacího uzlu. Je ale mnohem přehlednější a pro formulaci srovnávacího algoritmu pohodlnější, reprezentovat tuto časovou podmínku novým typem uzlu, který nazýváme Časovým uzlem (Time node). Článek má následující strukturu. Principy, na kterých je založen srovnávací algoritmus, jsou stručně naznačeny v paragrafu 2. Zde je také dán přibližný popis srovnávacího algoritmu. Potom následuje definice rozšířeného GLIF modelu, který označujeme EGLIF. Rozšíření modelu bylo nutné, aby srovnávací algoritmus mohl být navržen. V paragrafu 3 je srovnávací algoritmus přesně definován a jeho činnost je demonstrována na několika jednoduchých příkladech. V závěru jsou diskutována možná zobecnění algoritmu pro nestriktní doporučení a pro nekompletní datové záznamy pacienta. 2 Metody Cílem této práce je navrhnout algoritmus, který je schopen porovnat klinická data pacienta s formalizovanými doporučeními, které předepisují jak má být pacient léčen. Předpokládáme, že během pacientových návštěv lékař vyšetřuje jeho zdravotní stav a podle toho předepisuje způsob léčení. Během vyšetření lékař stanoví symptomy a provede vyšetření fysiologických veličin. Předpokládáme, že výsledkem každého vyšetření je stanovení hodnoty některé fyziologické hodnoty pacienta nebo jeho příznaku v určitém čase. Výsledek budeme psát ve tvaru P (time) = value. Například parametr SBP (systolický krevní tlak) byl vyšetřen v čase t a jeho hodnota byla 145. Potom výsledek je zapsán ve tvaru SBP (t) = 145. Předpokládáme, že také předepsání určité terapie může být zapsáno tímto způsobem. Potom P označuje předepsanou terapii a value = 1 znamená skutečnost, že terapie byla předepsána. Například Diet(t) = 1 znamená, že terapie Diet byla předepsána v čase t. Navíc pomocí parametru value může být dána bližší specifikace terapie. Například P enicilin(t) = Daily 2mg znamená, že v čase t byl předepsán P enicilin a že předepsaná dávka byla 2mg denně. Předpokládáme, že klinická data pacienta jsou uložena v jeho EZZ. Nepředpokládáme nějaký určitý formát EZZ. Předpokládáme pouze, že tento záznam může být převeden na posloupnost provedených vyšetření a předepsaných terapií (dále nazývanou datovou sekvencí) S = {P 1 (t 1 ) = c 1,..., P n (t n ) = c n }, t 1... t n, kde P i (t i ) označuje hodnotu parametru P i v čase t i. Abychom notaci zjednodušili, předpokládáme, že jednotkou času jsou dny zapsané ve formátu day.month.year, například t = nebo SBP (1.1.01) = 150 atd. Samozřejmě, v reálných aplikacích bude čas vyjádřen přesněji. Například čas t může být systémovým časem. Tabulka 1: Datový model jednoduchých doporučení z příkladu 1. akce parameter P typ Změření systolického SBP numerický krevního tlaku Změření diastolického DBP numerický krevního tlaku Test HDL cholesterolu HDL numerický Test LDL cholesterolu LDL numerický Předepsání dietního režimu Diet Booleovský Předpis medikace Medication Booleovský c 2012 EuroMISE s.r.o. EJBI Volume 8 (2012), Issue 1

4 cs4 Veselý, Zvárová Určení kompatibility doporučení Všechny fyziologické parametry a terapie, které se v klinických doporučeních vyskytují, musí být předem specifikovány. To může být uděláno prostřednictvím datového modelu doporučení. Datový model doporučení by měl obsahovat seznam všech možných vyšetření a terapií včetně popisu jejich možných hodnot. Nejčastější datové typy budou Booleovský, nominální a numerický. Příklad velmi jednoduchého datového modelu, který bude použit v dále uvedených příkladech, je uveden v Tabulce 1. Protože formalizovaná doporučení budou srovnávána s daty uloženými ve zdravotním záznamu pacienta, předpokládáme, že existuje datový model zdravotního záznamu. Tento model musí obsahovat soubor všech parametrů P G, které se ve formalizovaném modelu doporučení vyskytují. Aby bylo možné porovnávat zdravotní záznam pacienta s doporučeními, doporučení musí být formalizována a zakódována ve formátu, který může počítač přečíst. K tomuto účelu použijeme rozšířený GLIF model (EG- LIF model). Jak již bylo řečeno výše, předpokládáme, že zdravotní záznam pacienta může být převeden na datovou sekvenci S. Srovnání se provádí algoritmem CA, který byl pro tento účel navržen (viz obr. 1). CA algoritmus postupně odebírá ze sekvence S, vytvořené systémem EZZ, datové položky a porovnává je se zakódovaným EGLIF modelem. Pokud některá položka není v souladu s EGLIF modelem, CA algoritmus varuje uživatele. EGLIF model a CA algoritmus jsou podrobně popsány dále. Zde uvádíme pouze jejich hrubý popis. EGLIF model tvoří orientovaný graf, který má uzly různého typu. Uzlům jsou přiřazeny parametry a podmínky. Parametry uzlů nemají nic společného s parametry pacienta, o kterých se mluvilo výše. Nejdůležitější parametry uzlů jsou parametr next, který definuje grafovou strukturu EGLIF modelu a parametr token, který umožňuje definovat a sledovat průchod modelem. Některé z uzlů mají parametry pro uložení tokenů. Říkáme, že tyto uzly jsou schopny uložit nebo zachytit tokeny. Když porovnávání začíná, v EGLIF modelu existuje pouze jeden token, který je umístěn v uzlu ST ART. Během porovnávání tokeny se pohybují podél větví grafu mezi uzly, které je mohou zachytit. CA algoritmus postupně odebírá položky P (t) = c z datové sekvence S a porovnává je s těmi akčními uzly v GLIF modelu, které obsahují tokeny. Každý akční uzel má tři hlavní parametry action, result a time. Parametr action specifikuje předepsanou akci. Jeho hodnota je porovnána s P aktuálně odebrané datové položky. Pokud dojde ke shodě, potom výsledek c akce P (t) je zapsán do parametru uzlu result a čas t je zapsán do parametru uzlu time. Potom je token z tohoto uzlu předán uzlu, který je nejbližším uzlem na cestě tokenu a který dokáže token uložit. Pokud token prochází uzlem větvení BRN, vzniknou v tomto uzlu další tokeny. Pokud uzel větvení BRN má n vycházejících větví, potom z tohoto uzlu vychází n tokenů. Nově vytvořené tokeny pokračují podél různých větví. V synchronizačním uzlu SY NC s n vstupy jsou přicházející tokeny ukládány do n parametrů token 1,..., token n. Jakmile synchronizační podmínka synchronizačního uzlu SY N C je splněna, jeden token vychází ze synchronizačního uzlu a zároveň všechny uzly vyskytující se v uzlech podgrafu BRN SY N jsou uzlům odebrány. Srovnávací algoritmus CA je popsán přesněji v paragrafu 3. Abychom mohli algoritmus přesněji formulovat, musíme nejdříve definovat rozšířený GLIF model. 2.1 Popis rozšířeného GLIF modelu (EGLIF model) EGLIF model je orientovaný graf s uzly typu A, D, BRN, SY N, T IM, ST ART, ST OP, GLF, ERROR. Uzly stejného typu rozlišujeme pomocí indexů, např. A 1, A 2 atd. Každému uzlu je přiřazen jeden nebo více parametrů respektive podmínek. Parametr par nebo podmínku cond uzlu N budeme označovat N(par) nebo N(cond), např. A 1 (result) nebo T IM 2 (β). Parametr next obsahuje pointer na následující uzel a do parametru token se ukládá zachycený token. Pokud platí token = 1, znamená to, že v uzlu je uložen token a pokud platí token = 0, znamená to, že v uzlu token uložen není. Typy uzlů modelu EGLIF jsou následující. Akční uzel (action node) A(token, action, result, time, ref, next) Akční uzel reprezentuje akci. Druh akce je specifikován parametrem action. Výsledek akce se zapisuje do parametru result a čas, kdy byla akce provedena do parametru time. Parametr ref obsahuje pointer na některý časový uzel nebo obsahuje nulový pointer NULL. Pokud hodnota ref není NULL, potom parametr ref odkazuje na časový uzel, jehož podmínka β musí být splněna. Rozhodovací uzel (decision node) D ((α 1, next 1 ),..., (α n, next n ) Rozhodovací uzel reprezentuje rozhodnutí, které by mělo být učiněno na základě vyhodnocení podmínek α 1,..., α n, definovaných pro jednotlivé větve vycházející z tohoto rozhodovacího uzlu. Předpokládáme, že podmínky jsou striktní (strict-in conditions). To znamená, že jestliže podmínka α i je splněna, potom pro pokračování průchodu grafem musí být vybrána i-tá větev. Navíc předpokládáme, že vždy jedna a pouze jedna podmínka je splněna, tj. předpokládáme, že pro každý rozhodovací uzel platí α 1... α n = t(true), α i α j = f(false), for all i, j = 1,... n and i j. Podmínky α 1,..., α n jsou vytvořeny z parametrů akčních kroků pomocí obvyklých relačních a logických operátorů. Podmínka může vypadat například takto (A 1 (result) > 10) (A 2 (result) < 100). EJBI Volume 8 (2012), Issue 1 c 2012 EuroMISE s.r.o.

5 Veselý, Zvárová Určení kompatibility doporučení cs5 Obrázek 1: Porovnání pacientova zdravotního záznamu s kódovanými doporučeními. Uzel větvení (branch node) BRN(next 1,..., next n ) Uzel větvení vnáší do modelu paralelismus. Z uzlu větvení lze pokračovat libovolnou větví. Větve mohou být procházeny simultánně, avšak následnost kroků na jednotlivých větvích musí být dodržena. Synchronizační uzel (synchronization node) SY N(token 1,..., token n, α, β, time, next) Synchronizační uzel spojuje a synchronizuje větve. Jestliže synchronizační uzel SY N spojuje n větví, potom má n vstupů, které jsou reprezentovány n pointery SY N(1),..., SY N(n). Pokud token přichází z i-té větve, je uložen do i-tého parametru token i. Průchod tokenu synchronizačním uzlem je možný pouze když synchronizační podmínka α je splněna. Podmínka α je výroková formule vytvořená z parametrů token 1,..., token n. Například α = (token 1 token 2 ) token 3. Kdykoliv je token uložen do synchronizačního uzlu, aktuální čas (tj. čas t naposledy odebrané datové položky P (t) = c) je zapsán do parametru uzlu time. Podmínka β je časová podmínka, která musí být splněna pro všechny hodnoty časových parametrů všech akčních uzlů, které se vyskytují v podgrafu BRN SY N. V definici podmínky β se vyskytuje klíčové slovo atime, jehož význam je zřejmý z následujícího příkladu. Předpokládejme, že β je definována takto β = ((atime A(time) year). Tato podmínka stanoví, že jestliže B je libovolný uzel ležící v podgrafu BRN SY N, potom musí být splněna podmínka (B(time) A(time)) year. Stavový uzel (state node) ST AT E(name, next) přiřazuje stavu pacienta jméno. Časový uzel (time node) T IM(time, β, next) Časový uzel stanoví časové omezení následující akce. Když token prochází časovým uzlem T IM, aktuální čas je zaznamenán do parametru T IM(time). Podmínka β je časová podmínka, která musí být splněna pro čas následující akce. V definici podmínky β časový parametr následující akce je označen ftime. Například β = ((ftime T IM(time)) year). Startovací uzel (start node) reprezentuje začátek průchodu grafem ST ART (token, next). Uzel zastavení (stop node) reprezentuje konec procházení grafem. Chybový uzel (error node) reprezentuje konec procházení grafu způsobený chybou ERROR(token, text). Uzel volání (call node) reprezentuje přechod do jiného EGLIF modelu. Definice EGLIF modelu EGLIF model je množina výše popsaných uzlů vytvářejících pomocí pointerů (uložených v jejich parametrech next) spojitý orientovaný graf, pokud jsou splněny následující podmínky C 1 C 4. C 1 Množina uzlů obsahuje právě jeden Startovací uzel. c 2012 EuroMISE s.r.o. EJBI Volume 8 (2012), Issue 1

6 cs6 Veselý, Zvárová Určení kompatibility doporučení C 2 C 3 C 4 Pro každý uzel větvení BRN existuje jeden synchronizační uzel SY N, ve kterém všechny větve, které začínají v BRN uzlu, končí. Podgraf EGLIF modelu, který začíná uzlem BRN a končí uzlem SY N nazýváme BRN SY N podgraf EGLIF modelu. Jestliže G 1 a G 2 jsou dva BRN SY N podgrafy, potom platí pouze jedna z následujících podmínek: a) G 1 G 2 (tj. každý uzel G 1 je také uzlem G 2 ) b) G 2 G 1 c) G 1 G 2 = (tj. G 1 a G 2 nemají společný žádný uzel). Topologie grafu je taková, že během předání tokenu, token prochází nejvýše jedním časovým uzlem T IM a tímto uzlem prochází nejvýš jednou. Příklad 1 Malá doporučení pro prevenci srdečního selhání Když přijde pacient na návštěvu, lékař vyšetří jeho parametry SBP (systolický krevní tlak) a DBP (diastolický krevní tlak) a v laboratoři nechá vyšetřit parametry LDL, HDL udávající obsah cholesterolu v krvi. 1. Pokud krevní tlak není normální, tj. pokud podmínka α = (SBP < 145) (DBP < 90) není splněna, lékař předepíše dietu a pozve pacienta k opakované návštěvě po 1-2 měsících: (a) Pokud pacientův krevní tlak opět není normální, lékař předepíše nasadit léky. (b) Pokud krevní tlak pacienta je normální, lékař vyčíslí pacientův rizikový index i R = (LDL HDL)/HDL. Pokud hodnota rizikového indexu je malá (i R < 4.2), pacient je pozván k příští návštěvě nejpozději za rok. Pokud rizikový index je větší než 4.2, pacient je pozván k příští návštěvě nejpozději za půl roku. 2. Pokud krevní tlak je normální, tj. podmínka α je splněna, lékař vyčíslí pacientův rizikový index i R. Pokud hodnota rizikového indexu je malá (i R < 4.2), pacient je pozván k příští návštěvě nejpozději za rok. Pokud rizikový index je větší než 4.2, pacient je pozván k příští návštěvě nejpozději za půl roku. EGLIF graf modelu Malých doporučení pro prevenci srdečního selhání je na obr. 2. Kódovaná forma modelu je na obr Výsledky V tomto paragrafu popíšeme algoritmus pro srovnávání EGLIF modelu striktních doporučení s kompletním datovým záznamem pacienta. Začneme příkladem. Příklad 2 Předpokládáme, že lékař ukládá hodnoty všech vyšetřených parametrů pacienta (HDL, LDL, SBP, DBP ) a údaje o všech předepsaných terapiích (Diet, M edication) do pacientova zdravotního záznamu. Předpokládáme dále, že pacientova data uložená v systému EZZ mohou být vypsána ve formě datové sekvence popsané výše. Předpokládejme, že systému EZZ poskytnul následující datové sekvence S A, S B, S C, S D pro 4 pacienty A, B, C a D. S A = {SBP (1.1.01) = 150, DBP (1.1.01) = 85, HDL(2.1.01) = 1, LDL(2.1.01) = 6, Diet(2.1.01) = 1, DBP ( ) = 85, SBP ( ) = 140, SBP (1.5.01) = 130, DBP (1.5.01) = 85, HDL(2.5.01) = 1, LDL(2.5.01) = 5, SBP (1.4.02) = 130, DBP (1.4.02) = 90, LDL(2.4.01) = 7, HDL(2.4.01) = 2} S B = {SBP (1.1.01) = 150, DBP (1.1.01) = 85, HDL(2.1.01) = 1, LDL(2.1.01) = 6, DBP ( ) = 85, SBP ( ) = 140, SBP (1.5.01) = 130, DBP (1.5.01) = 85, HDL(2.5.01) = 1, LDL(2.5.01) = 5, SBP (1.4.02) = 130, DBP (1.4.02) = 90, LDL(2.4.01) = 7, HDL(2.4.01) = 2} S C = {SBP (1.1.01) = 150, DBP (1.1.01) = 85, HDL(2.1.01) = 1, LDL(2.1.01) = 6, Diet(2.1.01) = 1, DBP (1.4.01) = 85, SBP (1.4.01) = 140, SBP (1.5.01) = 130, DBP (1.5.01) = 85, HDL(2.5.01) = 1, LDL(2.5.01) = 5, SBP (1.4.02) = 130, DBP (1.4.02) = 90, LDL(2.4.01) = 7, HDL(2.4.01) = 2} S D = {SBP (1.1.01) = 150, DBP (1.1.01) = 85, HDL(2.1.01) = 1, LDL(2.1.01) = 6, Diet(2.1.01) = 1, DBP ( ) = 85, SBP ( ) = 140, SBP (1.5.01) = 130, DBP (1.5.01) = 85, HDL(2.5.01) = 1, LDL(2.5.01) = 5.5, SBP (1.4.02) = 130, DBP (1.4.02) = 90, LDL(2.4.01) = 7, HDL(2.4.01) = 2} Pokud je zdravotní záznam pacienta kompletní, můžeme porovnat ze záznamu vygenerovanou datovou sekvenci S s doporučeními a stanovit, zda pacient byl léčen v souladu s nimi. Srovnejme datové sekvence S A, S B, S C a S D s Malými doporučeními pro prevenci srdečního selhání popsanými v Příkladu 1. Porovnáním S A s těmito doporučeními zjistíme, že pacient A byl léčen v souladu s doporučeními. Když porovnáme S B s doporučeními, vidíme, že léčba pacienta B nebyla s nimi v souladu. Při první návštěvě totiž pacientův krevní tlak nebyl normální. Proto lékař měl předepsat dietu, ale datová položka týkající se předepsání diety v datové sekvenci S B chybí. Léčení pacienta C také nebylo v souladu s doporučeními, protože při návštěvě krevní tlak pacienta nebyl normální a proto pacient měl přijít na opakovanou návštěvu nejpozději do 2 měsíců. Ale přišel později, jak můžeme vidět z datové položky DBP (1.4.01) = 85. Snadno nahlédneme, že také léčba pacienta D neproběhla v souladu s doporučeními. Protože EJBI Volume 8 (2012), Issue 1 c 2012 EuroMISE s.r.o.

7 Veselý, Zvárová Určení kompatibility doporučení cs7 Obrázek 2: EGLIF model Malých doporučení pro prevenci srdečního selhání z příkladu 1. Pro větší názornost je hodnota parametru action uzavřena do závorek a zapsána za jméno akčního uzlu. HDL(2.5.01) = 1 a LDL(2.5.01) = 5, 5, rizikový index pacienta při jeho návštěvě měl hodnotu i R = 4, 5. Proto pacientova následující návštěva se měla uskutečnit nejpozději za půl roku. Ale uskutečnila se , jak je zřejmé z datové položky SBP (1.4.02) = 130. Algoritmus srovnání EGLIF modelu s datovou sekvencí (algoritmus CA) Porovnání datové sekvence s klinickými doporučeními je časově náročný a únavný proces náchylný k chybám. Proto možnost provést srovnání automaticky s použitím počítače je velmi lákavá. Pro porovnávání potřebujeme algoritmus, který by byl schopen porovnat danou datovou sekvenci se zakódovaným EGLIF modelem a odpovědět na otázku, zda lékař léčil pacienta v souladu s doporučenými léčebnými postupy specifikovanými v doporučeních. V dalším popíšeme algoritmus, který je schopen tuto odpověď poskytnout. V paragrafu 2 byl již uveden přibližný popis tohoto algoritmu, aby byly představeny principy, na kterých je založen. Zde nejdříve připomeneme jeho hlavní rysy a teprve pak jej podrobně popíšeme. Algoritmus porovnává EGLIF model s datovou sekvencí S = {P 1 (t 1 ) = c 1,..., P n (t n ) = c n }. Z datové sekvence algoritmus postupně odebírá jednotlivé datové položky. Předpokládejme, že v i-tém kroku algoritmus odebere datovou položku P i (t i ) = c i. Po odebrání položky algoritmus nalezne všechny akční uzly, které mají token a jejichž parametr action má hodnotu P i. V každém nac 2012 EuroMISE s.r.o. EJBI Volume 8 (2012), Issue 1

8 cs8 Veselý, Zvárová Určení kompatibility doporučení Obrázek 3: Kódovaný EGLIF model Malých doporučení pro prevenci srdeční selhání. lezeném uzlu algoritmus zapíše hodnotu t i do parametru time a hodnotu c i do parametru result. Potom algoritmus posune token nebo tokeny nalezeného uzlu nebo uzlů do nejbližšího následujícího uzlu nebo do nejbližších následujících uzlů. Jestliže žádný uzel výše uvedených vlastností nebyl nalezen, je generována chybová hláška a srovnání končí neúspěšně. Definice CA algoritmu Definice CA algoritmu má dvě části. Činnost algoritmu je popsána v první části. V popisu je ale použit pojem posun tokenu, jehož význam musí být rovněž přesně stanoven. To je provedeno v druhé části definice. Část 1 1. V nultém kroku algoritmus inicializuje parametry uzlů následovně: (a) Ve všech uzlech nastaví parametry time = 0, result = 0 a ref = NULL. (b) Ve všech uzlech kromě uzlu ST ART nastaví parametr token = 0. (c) Nastaví ST ART (token) = 1 (tj. umístí do uzlu ST ART token) a provede posun tohoto tokenu z uzlu ST ART. 2. V n-tém kroku algoritmus postupně odebírá ze začátku datové sekvence S jednotlivé datové položky P (t) = c tak dlouho, dokud není P P G (to znamená, že akce, které nejsou zmíněny v doporučeních, se neberou v úvahu). Množinu všech akčních uzlů s parametry token = 1 a action = P algoritmus označí N 0. (a) Jestliže je množina N 0 prázdná, algoritmus vytiskne chybovou hlášku Chyba v následnosti akcí a skončí. (b) Jestliže množina N 0 není prázdná, potom v každém akčním uzlu A N 0 algoritmus nastaví parametry A(time) = t a A(result) = c. Hodnoty t a c algoritmus vezme z datové položky P (t) = c naposledy vyjmuté z datové sekvence. Množinu těch uzlů A z N 0, které splňují následující podmínky cond1 a cond2 algoritmus označí N 1. cond1 Jestliže je akční uzel A uvnitř grafu BRN SY N, potom časová podmínka β uzlu SY N je splněna. cond2 Jestliže parametr ref akčního uzlu A obsahuje odkaz na časový uzel T IM (tj. pokud T IM(ref) NULL), potom časová podmínka β časového uzlu T IM je splněna. Pokud množina N 1 je prázdná, algoritmus vytiskne chybovou hlášku Časová chyba a skončí. V opačném případě v každém uzlu A N 0 algoritmus nastaví A(token) = 0 a z každého uzlu A N 1 posune token do EJBI Volume 8 (2012), Issue 1 c 2012 EuroMISE s.r.o.

9 Veselý, Zvárová Určení kompatibility doporučení cs9 Tabulka 2: Srovnání datové sekvence S A s EGLIF modelem. Po kroku 15 je datová sekvence prázdná a uzel ST OP neobsahuje žádný token. To znamená, že pacient byl léčen v souladu s doporučeními, ale léčení ještě neskončilo. Step Data item S i A 1 A 2 A 3 A 4 SY N 1 (1)SY N 1 (2)SY N 1 (3)SY N 1 (4)A 5 A 6 A 7 SY N 2 (1)SY N 2 (2) 0 Start 1 SBP (1.1.01) = DBP (1.1.01) = 85 3 HDL(2.1.01) = 1 4 LDL(2.1.01) = 6 5 Diet(2.1.01) = 1 6 DBP ( ) = 85 7 SBP ( ) = SBP (1.5.01) = DBP (1.5.01) = HDL(2.5.01) = 1 11 LDL(2.5.01) = 5 12 SBP (1.4.02) = DBP (1.4.02) = LDL(2.4.01) = 7 15 HDL(2.4.01) = 2 nejbližšího uzlu, který je schopen token uložit. Jestliže posunovaný token je zachycen synchronizačním uzlem SY N, potom algoritmus nastaví SY N(time) = t. Hodnotu t algoritmus vezme z datové položky naposledy vyjmuté z datové sekvence S. Nakonec se v n-tém kroku algoritmu posunou tokeny z těch synchronizačních uzlů SY N, jejichž synchronizační podmínka α je splněna. Jestliže podmínka α je splněna pro uzel SY N, potom pouze jeden token je posunut z tohoto uzlu. Jestliže posunovaný uzel je zachycen uzlem N, potom algoritmus nastaví N(time) = SY N(time). 3. Jestliže není splněna ukončující podmínka, algoritmus zvětší počet kroků algoritmu n o jedničku, tj. položí n = n + 1 a přejde na vykonávání bodu 2. Ukončující podmínka: Algoritmus skončí, pokud je splněna alespoň jedna z následujících podmínek a) nebo b). (a) Některý z uzlů ERROR nebo ST OP obsahuje token. (b) Z datové sekvence nelze odebrat datovou položku, protože všechny datové položky už byly odebrány. Část 2 (Pravidla posunu tokenů) 1. Tokeny jsou posunovány podél větví grafu. V rozhodovacím uzlu posunovaný token pokračuje tou větví i, jejíž podmínka α i je splněna. V uzlu větvení s n větvemi algoritmus vytvoří n 1 nových tokenů. Tokeny, které uzel větvení opouštějí, algoritmus posunuje podél různých větví. 2. Akční uzel předává token nejbližšímu uzlu, který je schopen token přijmout. Jestliže token prochází uzlem větvení a jsou vytvořeny nové tokeny, pak také každý nově vytvořený token je zachycen nejbližším uzlem, který je schopen jej zachytit. 3. Synchronizační uzel SY N předává pouze 1 token a předává jej stejným způsobem jako akční uzel. Navíc algoritmus provede následující akce: (a) Všechny tokeny uložené v synchronizačním uzlu jsou odstraněny. (b) Všechny tokeny, uložené v uzlech, které leží na větvích mezi uzlem SY N a uzlem BRN, který k němu přísluší, jsou odstraněny. 4. Jestliže uzel N předává token jinému uzlu a jestliže tento token během svého předání projde uzlem T IM, potom parametr time uzlu T IM algoritmus nastaví takto: T IM(time) = N(time). 5. Jetliže token byl předán do akčního uzlu A a jestliže během svého předávání prošel přes časový uzel T IM, potom algoritmus zapíše do parametru ref uzlu A pointer na uzel T IM. Jestliže token při svém předání neprošel žádným časovým uzlem, potom algoritmus zapíše do parametru ref uzlu A nulový pointer NULL. Pokud algoritmus CA neskončí chybou, skončí z jednoho ze dvou následujících důvodů. 1. Všechny datové položky S i byly z datové sekvence S odebrány. V tomto případě pacient byl léčen ve shodě s doporučeními. Podle doporučení má však jeho léčba dál pokračovat. c 2012 EuroMISE s.r.o. EJBI Volume 8 (2012), Issue 1

10 cs10 Veselý, Zvárová Určení kompatibility doporučení Tabulka 3: Srovnání datové sekvence S B s EGLIF modelem. V kroku 5 je generována chybová hláška Chyba v následnosti akcí, protože množina N 0 je v tomto kroku prázdná. Step Data item S i A 1 A 2 A 3 A 4 SY N 1 (1)SY N 1 (2)SY N 1 (3)SY N 1 (4)A 5 A 6 A 7 SY N 2 (1)SY N 2 (2) 0 Start 1 SBP (1.1.01) = DBP (1.1.01) = 85 3 HDL(2.1.01) = 1 4 LDL(2.1.01) = 6 5 DBP ( ) = 85 Tabulka 4: Porovnání datové sekvence S C s EGLIF modelem. V kroku 6 algoritmus generuje signál Časová chyba, protože množina N 1 je prázdná. Step Data item S i A 1 A 2 A 3 A 4 SY N 1 (1)SY N 1 (2)SY N 1 (3)SY N 1 (4)A 5 A 6 A 7 SY N 2 (1)SY N 2 (2) 0 Start 1 SBP (1.1.01) = DBP (1.1.01) = 85 3 HDL(2.1.01) = 1 4 LDL(2.1.01) = 6 5 Diet(2.1.01) = 1 6 DBP (1.4.01) = Do uzlu ST OP byl uložen token. V tomto případě pacient byl léčen ve shodě s doporučeními a léčení bylo ve shodě s doporučeními ukončeno. Jestliže všechny datové položky byly z datové sekvence S odebrány, lékař ukončil léčbu. Pokud nějaké datové položky v S zůstaly, pacient byl léčen dále, například z důvodu nějakých dalších zdravotních komplikací. Abychom demonstrovali chování algoritmu CA, použijeme jej pro srovnání Malých doporučení pro prevenci srdečního selhání z Příkladu 1 s datovými záznamy pacientů A, B, C a D, které jsme uvažovali výše. Předpokládáme, že doporučení byla formalizována pomocí EGLIF modelu a že datové záznamy pacientů byly transformovány do datových sekvencí S A, S B, S C a S D uvedenými výše. Průběh algoritmu pro jednotlivé datové sekvence je zachycen v tabulkách 2 5. V těchto tabulkách je znázorněn pohyb tokenů. Přítomnost tokenu v určitém uzlu (nebo tokenů jestliže se jedná o synchronizační uzel SY N) na konci n-tého kroku je znázorněna černou tečkou. Například černá tečka v buňce (step = 0, A 1 ) tabulky 2 znamená, že na konci nultého kroku bylo A 1 (token) = 1, černá tečka v buňce (step = 3, SY N 1 (2)) znamená, že na konci třetího kroku bylo SY N 1 (token 2 ) = 1, prázdná buňka (step = 2, SY N 1 (3)) znamená, že na konci druhého kroku bylo SY N 1 (token 3 ) = 0 atd. Pokud je řádka některého kroku rozdělena na dvě části, potom první část popisuje rozložení tokenů po první fázi kroku, to znamená těsně před posunem tokenů ze synchronizačních uzlů SY N. Jestliže CA algoritmus srovnává EGLIF model doporučení s datovou sekvencí S A (viz tab. 2), potom proces porovnávání skončí krokem 15. Datová sekvence je prázdná a uzel ST OP neobsahuje token. To znamená, že pacient A byl léčen ve shodě s doporučeními a že léčení ještě neskončilo. Jestliže CA algoritmus srovnává EGLIF model s datovou sekvencí S B (viz tabulka 3), srovnávání skončí v kroku 5 chybovou hláškou Chyba v následnosti akcí. Porovnávání skončí chybou, protože na začátku kroku 5 pouze uzel A 7 má token, odebraná položka použitá pro srovnání je DBP ( ) = 85 a A 7 (action) = Diet. Protože Diet DBP, množina N 0 je prázdná a tudíž algoritmus skončí s chybovou hláškou Chyba v následnosti akcí. Jestliže CA algoritmus srovnává EGLIF model s datovou sekvencí S C, porovnávaní skončí v kroku 6 chybovou hláškou Časová chyba. V kroku 6 je odebrána datová položka DBP (1.4.01) = 85. Jediné akční uzly, které mají na začátku kroku 6 tokeny, jsou uzly A 5 a A 6. Jejich parametr action má hodnotu A 5 (action) = SBP respektive A 6 (action) = DBP. Tudíž množina N 0 = {A 6 } a parametr A 6 (time)) je nastaven na hodnotu Uzel A 6 je uvnitř podgrafu BRN 2 SY N 2 a podmínka β uzlu SY N 2 je (1 month (atime A 7 (time)) 2 months). Proto podmínka (1 month (A 6 (time) A 7 (time)) 2 months). musí být splněna. Tato podmínka ale splněna není, protože A 7 (time) = Proto algoritmus generuje chybovou hlášku Časová chyba. Jestliže CA algoritmus porovnává EGLIF model s datovou sekvencí S D (viz tabulka 5), porovnávání skončí EJBI Volume 8 (2012), Issue 1 c 2012 EuroMISE s.r.o.

11 Veselý, Zvárová Určení kompatibility doporučení cs11 Tabulka 5: Srovnání datové sekvence S D s EGLIF modelem. V kroku 12 je generována chybová hláška Časová chyba, protože množina N 1 je prázdná. Step Data item S i A 1 A 2 A 3 A 4 SY N 1 (1)SY N 1 (2)SY N 1 (3)SY N 1 (4)A 5 A 6 A 7 SY N 2 (1)SY N 2 (2) 0 Start 1 SBP (1.1.01) = DBP (1.1.01) = 85 3 HDL(2.1.01) = 1 4 LDL(2.1.01) = 6 5 Diet(2.1.01) = 1 6 DBP ( ) = 85 7 SBP ( ) = SBP (1.5.01) = DBP (1.5.01) = HDL(2.5.01) = 1 11 LDL(2.5.01) = 5 12 SBP (1.4.02) = 130 v kroku 12 a algoritmus generuje chybovou hlášku Časová chyba. Na začátku kroku 12 mají token uzly A 1, A 2, A 3 a A 4, ale pouze uzel A 1 má hodnotu parametru action rovnou SBP. Tudíž N 0 = A 1 a A 1 (time) = Když byl token předáván do uzlu A 1, prošel uzlem T IM 2. Proto platí A 1 (ref) = T IM 2 a T IM 2 (time) = Podmínka β uzlu T IM 2 je ftime T IM 2 (time) 0.5 year. Protože ftime = , podmínka β není splněna a algoritmus generuje chybovou hlášku Časová chyba. 4 Závěr V tomto článku byl popsán algoritmus, který porovnává léčbu pacienta zachycenou v pacientově zdravotním záznamu s formálním modelem (EGLIF modelem) klinických doporučení. Algoritmus pracuje správně, pokud jsou splněny dvě podmínky: 1. EGLIF model je striktní, což znamená, že výběr větve ve všech rozhodovacích uzlech musí být jednoznačný. 2. Zdravotní záznam je kompletní, což znamená, že všechny výsledky vyšetření a aplikovaných terapií jsou do zdravotního záznamu zaneseny. Pro určitý stav pacienta doporučení ale často připouštějí více možných způsobů jak s léčením pokračovat. V GLIF modelu se tato skutečnost modeluje pomocí tzv. in-conditions, strict in-conditions, outconditions a strict out-conditions. Pokud je určitá strict in-condition respektive strict out-condition na dané větvi splněna, lékaři je striktně doporučeno touto větví pokračovat respektive nepokračovat. In-conditions a out conditions jsou pouze měkké podmínky a měly by být chápány pouze jako doporučení, která je třeba zvážit. V běžné praxi jsou GLIF modely doporučení zřídka kdy striktní a je třeba specifikovat, co pojem být v souladu s doporučeními, která nejsou striktní, vlastně znamená. Zde navrhneme jednu takovou možnou specifikaci. Nejdříve ale definujeme pojem přípustnosti větve. Když token prochází rozhodovacím uzlem, potom každá větev vycházející z tohoto uzlu, která splňuje následující podmínky C 1 and C 2 se nazývá přípustná. C 1 C 2 Všechny strict out-conditions a out-conditions na této větvi nabývají hodnotu false. Alespoň jedna strict in-condition nebo in-condition na této větvi nabývá hodnotu true. Nyní můžeme definovat soulad léčení a nestriktních doporučení. Léčení je v souladu s doporučeními, která nejsou striktní, jestliže každé provedené rozhodnutí vyústí v pokračování po přípustné větvi. Algoritmus porovnávání CA, který byl představen výše, lze snadno upravit tak, aby porovnával pacientův zdravotní záznam s EGLIF modelem nestriktních doporučení a určil, zda byl pacient léčen v souladu s nimi. Modifikace algoritmu spočívá v multiplikaci tokenu, který prochází rozhodovacím uzlem. Multiplikace znamená, že pokud token prochází rozhodovacím uzlem, je vytvořeno tolik nových tokenů, aby každou přípustnou větví mohl dále pokračovat jeden token. Druhá podmínka korektního fungování algoritmu byla podmínka úplnosti zdravotního záznamu pacienta. Je zřejmé, že v situaci, kdy do zdravotního záznamu jsou uložena pouze neúplná data o jeho léčbě, možnost testovat shodu pacientovy léčby s modelem doporučení je silně omezena. Nicméně v některých případech neshoda mezi zdravotním záznamem a modelem doporučení může být přesto objevena. To nastane tehdy, když data uložená ve zdravotním záznamu jsou v nesouladu s modelem doporučení ať jsou chybějící data ve zdravotním záznamu jakákoliv. c 2012 EuroMISE s.r.o. EJBI Volume 8 (2012), Issue 1

12 cs12 Veselý, Zvárová Určení kompatibility doporučení Kdybychom použili popsaný algoritmus CA pro záznamy s chybějícími daty, algoritmus by generoval chybou hlášku pro každý chybějící údaj. Nicméně to nemusí být to, co bychom chtěli dostat. V některých případech bychom třeba chtěli připustit chybějící data a chybové hlášky bychom chtěli dostat pouze tehdy, když nesoulad pacientova zdravotního záznamu a doporučení je zřejmý i z neúplného zdravotního záznamu. Navrhnout modifikaci CA algoritmu, který by tento požadavek splňoval, je ale mnohem obtížnější než je modifikace algoritmu pro nestriktní modely doporučení. V současnosti je tato problematika předmětem dalšího výzkumu. Poděkování Výzkum byl podpořen výzkumným projektem MSM a projektem 1M06014 MŠMT ČR. Literatura [1] D. Isern, A. Moreno, Computer-based Execution of Clinical Guidelines: A Review, International Journal of Medical Informatics, 77, pp , Maastricht, [2] National Guidelines Clearinghouse, [3] National Library of Guidelines Specialist Library, [4] Catalogue of Clinical Practice Guidelines (neo.euromise.cz /kkdp). [5] M. Zvolský, The Database of the Catalogue of Clinical Practice Guidelines Published via Internet in the Czech Language The Current State. European Journal for Biomedical Informatics 6 (2010), [6] V. Patel, V. Allen, J. Arocha, E. Shortliffe, Representing clinical guidelines in GLIF:individual and collaborative expertise, Journal American Medical Inf. Association, 1998, 5(5), [7] V. L. Patel, T. Branch, D. Wang, M. Peleg, A. Boxwala, Analysis of the Process of Encoding Guidelines: A Comparison of GLIF2 and GLIF3, Methods Inf. Med., 2002, no.2, pp [8] D. Buchtela, J. Peleška, M. Zvolský, J. Zvárová, Medical Knowledge Representation System, In: S. K. Andersen et al., Proceedings of MIE2008 e-health Beyond Horizon, pp , IOS Press, Goteborg, [9] D. Buchtela, J. Peleška, A. Veselý, M. Zvolský, J. Zvárová, Formalization of Clinical practice Guidelines, In: S. K. Andersen et al., Proceedings of MIE2008 e-health Beyond Horizon, pp , IOS Press, Goteborg, [10] A. Veselý, J. Zvárová, J. Peleška, Formalization of Clinical Practice Guidelines, In: S. K. Andersen et al., Proceedings of MIE2008 e-health Beyond Horizon, pp , IOS Press, Goteborg, [11] A. Veselý, J. Zvárová, J. Peleška, Z. Anger, D. Buchtela, Computerized Presentation of Medical Guidelines, In: Proceedings Medinfo 2004 AMIA San Francisco, [12] A. Latoschek-Berendsen, H. Tange, H. Herik, A. Hasman, From clinical practice guidelines to computer-interpretable guidelines, Methods Inf Med, 6, [13] P. Gillois, G. Chatellier, M. Jaulent, I. Colombet, M. Fieschi, P. Degoulet, From paper based to electronic gidelines: application to French guidelines, Medinfo 2001, 10, [14] J. Fox, E. Black, I. Chronakis, R.Dunlop, V. Patkar, M. South et al., From guidelines to careflows: modeling and supporting complex clinical processes, Stud Health Technol Inform, 2008, 139, [15] P. Shekelle, S. Woolf, M. Eccles, J. Grimshaw, Clinical guidelines:developing guidelines, BMJ 1999,318, [16] R. Gould, A. Hasman, A. Strijbis, N. Peek, A parallel guidelines development and formalization strategy to improve the quality of clinical practice guidelines, IntJ Med Inform, 2009, 78 (8), [17] P. DeClerq, K. Kaiser, A. Hasman, Computer-interpretable Guidelines Formalisms, Stud HealthTechnol Inform, 2008, 139, [18] D. Wang, M. Peleg, S.Tu, A.Boxwala, R.Greenes, V. Patel et al, representation primitives, process models and patient data in computer-interpretable clinical practice guidelines: a literature review of guidelines representation models., Int J Med Inform, 2002, 68, [19] J. Fox, S. Das, Safe and sound, 2000, MIT Press. [20] D.R Sutton, J. fox, The syntax and semantics of the PROforma guidelines modeling language, Journal of the American Medical Informatics Association, 2003, 10, [21] Y. Shahar, O. Young, E. Shalom, M. Galperin, A. Mayaffit, R. Moskovitch, A. Hessing, A hybrid, multiple-ontology clinical guidelines library and automated guideline-support tools, Journal of Biomedical Informatics, 2004, 37(5), [22] L. Anselma, P. Terenziani, S. Montani, A. Bottrighi, Towards a comprehensive treatment of repetitions, periodicity and temporal constrains in clinical guidelines, Artificial Intelligence in Medicine, 2006, [23] P. Terenziani, S. Montani, A. Bottrighi, M. Torchio, G.Molino, The GLARE approach to clinical guidelines: main features, in K. Kaiser, S.Miksch, S. Tu (Eds.), Computer-based support for clinical guidelines and protocols, Proceedings of the Symposium on Computerized guidelines and protocols, IOS Press, 2004, Prague, [24] P. Ciccarese, E. Caffi, L.Boiocchi, S. Quaglini, M. Stefanelli, A guideline management system, in M. Fieschi, E. Coiera, Y. Li (Eds.), Proceedings of 11th Word Congress of the International Medical Informatics Association, San Francisco, IOS Press, 2004, [25] P. Ciccarese, E. Caffi, L.Boiocchi, S. Quaglini, M. Stefanelli,Architectuers and tools for innovative health information systems: the guide project, International Journal of Medical Informatics, 74, 2005, [26] S. Quaglini, M. Stefanelli, A. Cavallini, G. Micieli, C. Fassino, C. Mossa, Guidelines-based careflow systems, Artificial Intelligence in Medicine 20 (2000), [27] J. H. Gennari, M.A. Musen, R.W. Fergerson, W.E. Grosso, M. Grubezy, H. Eriksson, N.F. Noy, S.W. Tu, The evolution of Protégé: an enviroment for knowledge-based systems development, International Journal of Human-Computer Studies 58(1), 2003, [28] D. Isern, D Sanchez, A. Moreno, An ontology-driven agentbased clinical guidelines execution engine, in Proceedings of 10th International Conference on Artificial Intelligence in Medicine, Vol of Lecture Notes on Artificial Intelligence, Springer, Berlin, 2007, EJBI Volume 8 (2012), Issue 1 c 2012 EuroMISE s.r.o.

13 Veselý, Zvárová Určení kompatibility doporučení cs13 [29] L. Ohno-Machado, J.H. Gennari, S. N. Murphy, N. L. Jain, S. W. Tu S, D. Oliver, et al., The GuideLine Interchange Format: A model for representing guidelines, Journal of the American Medical Informatics Association, 5(4), 1998, pp [30] M. Peleg, A. Boxwala, et al.: GLIF3: The Evolution of Guideline Representation Format, In: web.stanford.edu/projects/intermed-web/guidelines, [31] D. Wang, M. Peleg, S. V. Tu, A. Boxwala, et al., Design and implementation of the GLIF3 guideline execution engine, Journal of Biomedical Informatics 37(2004) [32] A. Veselý, J. Zvárová, J. Peleška, Medical guidelines presentation and comparing with electronic health record, International Journal of Medical Informatics, 75, pp , Maastricht, [33] A. Veselý, J. Zvárová, J. Peleška, M. Tomečková, On Direct Comparing of Medical Guidelines with Electronic Health Record, In: Proceedings of MIE2003 IOS San Malo, [34] A. Veselý, J. Zvárová, J. Peleška, D. Buchtela, Z. Anger, Medical Guidelines Presentation and Comparing with Electronic Health Record, In: Proceedings of the International Joint Meeting Merkantilie Prague Prague, [35] J. Zvárová A. Veselý, P. Hanzlíček, J. Špidlen, D. Buchtela, On Direct Comparing of Medical Guidelines with Electronic Health Record, In: M. Bubak et al.(eds.): Computational Science- ICCS2004,Part IV Springer-Verlag Berlin Krakow, 2004, c 2012 EuroMISE s.r.o. EJBI Volume 8 (2012), Issue 1

Vzdělávání v Biomedicínské a Zdravotnické Informatice

Vzdělávání v Biomedicínské a Zdravotnické Informatice Vzdělávání v Biomedicínské a Zdravotnické Informatice Prof. RNDr. Jana Zvárová, DrSc. EuroMISE Centrum Univerzity Karlovy a Akademie věd České republiky 1. LF UK a ÚI AV ČR Satelitní seminář EFMI STC 2013,

Více

BIOMEDICÍNSKÁ INFORMATIKA A JEJÍ ÚLOHA V PERSONALIZOVANÉ MEDICÍNĚ

BIOMEDICÍNSKÁ INFORMATIKA A JEJÍ ÚLOHA V PERSONALIZOVANÉ MEDICÍNĚ BIOMEDICÍNSKÁ INFORMATIKA A JEJÍ ÚLOHA V PERSONALIZOVANÉ MEDICÍNĚ Petr Lesný 1, Kryštof Slabý 1, Tomáš Holeček 2, Jan Vejvalka 1 1 Fakultní nemocnice v Motole, Praha 2 Fakulta humanitních studií UK, Praha

Více

Algoritmus. Cílem kapitoly je seznámit žáky se základy algoritmu, s jeho tvorbou a způsoby zápisu.

Algoritmus. Cílem kapitoly je seznámit žáky se základy algoritmu, s jeho tvorbou a způsoby zápisu. Algoritmus Cílem kapitoly je seznámit žáky se základy algoritmu, s jeho tvorbou a způsoby zápisu. Klíčové pojmy: Algoritmus, vlastnosti algoritmu, tvorba algoritmu, vývojový diagram, strukturogram Algoritmus

Více

Spojení OntoUML a GLIKREM ve znalostním rozhodování

Spojení OntoUML a GLIKREM ve znalostním rozhodování 1 Formalizace biomedicínských znalostí Spojení OntoUML a GLIKREM ve znalostním rozhodování Ing. David Buchtela, Ph.D. 16. června 2014, Faustův dům, Praha Skupina mezioborových dovedností Fakulta informačních

Více

NP-úplnost problému SAT

NP-úplnost problému SAT Problém SAT je definován následovně: SAT(splnitelnost booleovských formulí) Vstup: Booleovská formule ϕ. Otázka: Je ϕ splnitelná? Příklad: Formule ϕ 1 =x 1 ( x 2 x 3 )jesplnitelná: např.přiohodnocení ν,kde[x

Více

5 Orientované grafy, Toky v sítích

5 Orientované grafy, Toky v sítích Petr Hliněný, FI MU Brno, 205 / 9 FI: IB000: Toky v sítích 5 Orientované grafy, Toky v sítích Nyní se budeme zabývat typem sít ových úloh, ve kterých není podstatná délka hran a spojení, nýbž jejich propustnost

Více

4. blok část A Logické operátory

4. blok část A Logické operátory 4. blok část A Logické operátory Studijní cíl Tento blok je věnován představení logických operátorů AND, OR, NOT v jazyce SQL a práce s nimi. Doba nutná k nastudování 1-2 hodiny Průvodce studiem Při studiu

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

Petr Mojžíš, Petr Křelina Raiffeisenbank

Petr Mojžíš, Petr Křelina Raiffeisenbank Jak může SixSigma pomoci ITILu Petr Mojžíš, Petr Křelina Raiffeisenbank 2 Co je ITIL? 3 Co ITILu chybí? 4 Co ITILu chybí? 5 Co ITILu chybí? 6 Kdy je ITIL vhodným řešením? NAIMPLEMENTOVAT ITIL proces XYZ

Více

Algoritmizace a programování

Algoritmizace a programování Algoritmizace a programování Řídicí struktury jazyka Java Struktura programu Příkazy jazyka Blok příkazů Logické příkazy Ternární logický operátor Verze pro akademický rok 2012/2013 1 Struktura programu

Více

Logické operace. Datový typ bool. Relační operátory. Logické operátory. IAJCE Přednáška č. 3. může nabýt hodnot: o true o false

Logické operace. Datový typ bool. Relační operátory. Logické operátory. IAJCE Přednáška č. 3. může nabýt hodnot: o true o false Logické operace Datový typ bool může nabýt hodnot: o true o false Relační operátory pravda, 1, nepravda, 0, hodnoty všech primitivních datových typů (int, double ) jsou uspořádané lze je porovnávat binární

Více

Institut biostatistiky a analýz MU. Zkušenosti s vyhodnocováním telemedicínských technologií

Institut biostatistiky a analýz MU. Zkušenosti s vyhodnocováním telemedicínských technologií Institut biostatistiky a analýz MU Zkušenosti s vyhodnocováním telemedicínských technologií 1 O IBA hlavní oblasti zájmu Faculty of Science, Masaryk University Faculty of Medicine, Masaryk University Analýza

Více

Algoritmizace. 1. Úvod. Algoritmus

Algoritmizace. 1. Úvod. Algoritmus 1. Úvod Algoritmizace V dnešní době již počítače pronikly snad do všech oblastí lidské činnosti, využívají se k řešení nejrůznějších úkolů. Postup, který je v počítači prováděn nějakým programem se nazývá

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování. 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Business modelling, základní nástroje a metody business modelování.

Více

Informační a znalostní systémy jako podpora rozhodování

Informační a znalostní systémy jako podpora rozhodování Informační systémy a technologie Informační a znalostní systémy jako podpora rozhodování Petr Moos - ČVUT VŠL Přerov listopad 2015 Analýza a syntéza systému Definici systému můžeme zapsat ve tvaru: S =

Více

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a datových modelů Obsah Seznam tabulek... 1 Seznam obrázků... 1 1 Úvod... 2 2 Metody sémantické harmonizace... 2 3 Dvojjazyčné katalogy objektů

Více

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

Algoritmizace prostorových úloh

Algoritmizace prostorových úloh INOVACE BAKALÁŘSKÝCH A MAGISTERSKÝCH STUDIJNÍCH OBORŮ NA HORNICKO-GEOLOGICKÉ FAKULTĚ VYSOKÉ ŠKOLY BÁŇSKÉ - TECHNICKÉ UNIVERZITY OSTRAVA Algoritmizace prostorových úloh Algoritmus Daniela Szturcová Tento

Více

Elektronická zdravotní dokumentace

Elektronická zdravotní dokumentace Elektronická zdravotní dokumentace Prof. RNDr. Jana Zvárová, DrSc. vedoucí Oddělení medicínské informatiky Ústavu informatiky Akademie věd ČR v.v.i., ředitelka EuroMISE centra UK a AV ČR Elektronická zdravotní

Více

Roční periodická zpráva projektu

Roční periodická zpráva projektu WAK-1F44C-2005-2 WAK System Název projektu: Automatizovaná výměna dat mezi informačními systémy krizového řízení v dopravě s jednotným univerzálním a implementovaným rozhraním založeným na standardu webových

Více

Základní informace. Modelování. Notace

Základní informace. Modelování. Notace Základní informace BPMS = business process management systems - systémy pro modelování a optimalizace business procesů uvnitř organizace BPMN = business process modeling notation - součást BPMS, notace

Více

Datové typy a struktury

Datové typy a struktury atové typy a struktury Jednoduché datové typy oolean = logická hodnota (true / false) K uložení stačí 1 bit často celé slovo (1 byte) haracter = znak Pro 8-bitový SII kód stačí 1 byte (256 možností) Pro

Více

Je možné efektivně používat procesně orientované pracovní postupy při zdravotní péči?

Je možné efektivně používat procesně orientované pracovní postupy při zdravotní péči? Je možné efektivně používat procesně orientované pracovní postupy při zdravotní péči? Miloš Suchý 1, Martina Pátá 1, Richard Matyáš 2 1 Institut pro aplikovaný výzkum, edukaci a řízení ve zdravotnictví,

Více

ELEKTRONICKÁ PORODNÍ KNIHA POPIS APLIKACE Michal Huptych, Petr Janků, Lenka Lhotská

ELEKTRONICKÁ PORODNÍ KNIHA POPIS APLIKACE Michal Huptych, Petr Janků, Lenka Lhotská ELEKTRONICKÁ PORODNÍ KNIHA POPIS APLIKACE Michal Huptych, Petr Janků, Lenka Lhotská Anotace Tento příspěvek popisuje aplikaci, která je převodem tzv. porodní knihy do elektronické podoby. Aplikace vzniká

Více

Validace souborů DS3

Validace souborů DS3 Validace souborů DS3 Verze: 1.33 1. Rozsah...1 1.1 Identifikace systému...1 1.2 Přehled systému...1 2. Přehled verzí a změny v nich...1 3. Použité dokumenty...2 4. Shrnutí údajů o programovém vybavení...4

Více

Návrh a implementace algoritmů pro adaptivní řízení průmyslových robotů

Návrh a implementace algoritmů pro adaptivní řízení průmyslových robotů Návrh a implementace algoritmů pro adaptivní řízení průmyslových robotů Design and implementation of algorithms for adaptive control of stationary robots Marcel Vytečka 1, Karel Zídek 2 Abstrakt Článek

Více

Elektronický zdravotní záznam, sběr klinických údajů a klinické lékařské doporučení

Elektronický zdravotní záznam, sběr klinických údajů a klinické lékařské doporučení Elektronický zdravotní záznam, sběr klinických údajů a klinické lékařské doporučení Mgr. Miroslav Nagy, Ph.D. Centrum Biomedicínské Informatiky Oddělení Medicínské Informatiky, UI AV ČR v.v.i. Seminář:

Více

Sledování využívání elektronických informačních zdrojů. Ing. Barbora Katolická Univerzitní knihovna ZČU v Plzni Komise pro EIZ AKVŠ

Sledování využívání elektronických informačních zdrojů. Ing. Barbora Katolická Univerzitní knihovna ZČU v Plzni Komise pro EIZ AKVŠ Sledování využívání elektronických informačních zdrojů Ing. Barbora Katolická Univerzitní knihovna ZČU v Plzni Komise pro EIZ AKVŠ Obsah Význam měření využívání EIZ Zahraniční projekty k měření využívání

Více

10. blok Logický návrh databáze

10. blok Logický návrh databáze 10. blok Logický návrh databáze Studijní cíl Tento blok je věnován převodu konceptuálního návrhu databáze na návrh logický. Blok se věnuje tvorbě tabulek na základě entit z konceptuálního modelu a dále

Více

Čtvrtek 8. prosince. Pascal - opakování základů. Struktura programu:

Čtvrtek 8. prosince. Pascal - opakování základů. Struktura programu: Čtvrtek 8 prosince Pascal - opakování základů Struktura programu: 1 hlavička obsahuje název programu, použité programové jednotky (knihovny), definice konstant, deklarace proměnných, všechny použité procedury

Více

Základní pojmy teorie grafů [Graph theory]

Základní pojmy teorie grafů [Graph theory] Část I Základní pojmy teorie grafů [Graph theory] V matematice grafem obvykle rozumíme grafické znázornění funkční závislosti. Pro tento předmět je však podstatnější pohled jiný. V teorii grafů rozumíme

Více

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu VÝUKOVÝ MATERIÁL Identifikační údaje školy Vyšší odborná škola a Střední škola, Varnsdorf, příspěvková organizace Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632

Více

Lekce 01 Úvod do algoritmizace

Lekce 01 Úvod do algoritmizace Počítačové laboratoře bez tajemství aneb naučme se učit algoritmizaci a programování s využitím robotů Lekce 01 Úvod do algoritmizace Tento projekt CZ.1.07/1.3.12/04.0006 je spolufinancován Evropským sociálním

Více

7. Rozdělení pravděpodobnosti ve statistice

7. Rozdělení pravděpodobnosti ve statistice 7. Rozdělení pravděpodobnosti ve statistice Statistika nuda je, má však cenné údaje, neklesejte na mysli, ona nám to vyčíslí Jednou z úloh statistiky je odhad (výpočet) hodnot statistického znaku x i,

Více

Manuál administrátora FMS...2

Manuál administrátora FMS...2 Manuál administrátora Manuál administrátora FMS...2 Úvod... 2 Schéma aplikace Form Management System... 2 Úvod do správy FMS... 3 Správa uživatelů... 3 Práva uživatelů a skupin... 3 Zástupci... 4 Avíza

Více

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Pořadové číslo dodatečných informací: 14. ČÁST 1: Přesné znění žádosti dodavatele o dodatečné informace Otázka

Více

Business Process Modeling Notation

Business Process Modeling Notation Business Process Modeling Notation Stephen A. White, IBM Corporation Procesní řízení 1 Co to je BPMN? Standard Business Process Modeling Notation (BPMN) byl vyvinutý skupinou Business Process Management

Více

Analýza Petriho sítí. Analýza Petriho sítí p.1/28

Analýza Petriho sítí. Analýza Petriho sítí p.1/28 Analýza Petriho sítí Analýza Petriho sítí p.1/28 1. Základní pojmy Základní problémy analýzy bezpečnost (safeness) omezenost (boundness) konzervativnost (conservation) živost (liveness) Definice 1: Místo

Více

Michal Krátký. Tvorba informačních systémů, 2008/2009. Katedra informatiky VŠB Technická univerzita Ostrava. Tvorba informačních systémů

Michal Krátký. Tvorba informačních systémů, 2008/2009. Katedra informatiky VŠB Technická univerzita Ostrava. Tvorba informačních systémů Tvorba informačních systémů 1/18 Tvorba informačních systémů Michal Krátký Katedra informatiky VŠB Technická univerzita Ostrava Tvorba informačních systémů, 2008/2009 Tvorba informačních systémů 2/18 Úvod

Více

Algoritmus. Přesné znění definice algoritmu zní: Algoritmus je procedura proveditelná Turingovým strojem.

Algoritmus. Přesné znění definice algoritmu zní: Algoritmus je procedura proveditelná Turingovým strojem. Algoritmus Algoritmus je schematický postup pro řešení určitého druhu problémů, který je prováděn pomocí konečného množství přesně definovaných kroků. nebo Algoritmus lze definovat jako jednoznačně určenou

Více

GRAFY A GRAFOVÉ ALGORITMY

GRAFY A GRAFOVÉ ALGORITMY KATEDRA INFORMATIKY PŘÍRODOVĚDECKÁ FAKULTA UNIVERZITA PALACKÉHO GRAFY A GRAFOVÉ ALGORITMY ARNOŠT VEČERKA VÝVOJ TOHOTO UČEBNÍHO TEXTU JE SPOLUFINANCOVÁN EVROPSKÝM SOCIÁLNÍM FONDEM A STÁTNÍM ROZPOČTEM ČESKÉ

Více

2. úkol MI-PAA. Jan Jůna (junajan) 3.11.2013

2. úkol MI-PAA. Jan Jůna (junajan) 3.11.2013 2. úkol MI-PAA Jan Jůna (junajan) 3.11.2013 Specifikaci úlohy Problém batohu je jedním z nejjednodušších NP-těžkých problémů. V literatuře najdeme množství jeho variant, které mají obecně různé nároky

Více

Dolování asociačních pravidel

Dolování asociačních pravidel Dolování asociačních pravidel Miloš Trávníček UIFS FIT VUT v Brně Obsah přednášky 1. Proces získávání znalostí 2. Asociační pravidla 3. Dolování asociačních pravidel 4. Algoritmy pro dolování asociačních

Více

GIS Geografické informační systémy

GIS Geografické informační systémy GIS Geografické informační systémy Obsah přednášky Prostorové vektorové modely Špagetový model Topologický model Převody geometrií Vektorový model Reprezentuje reálný svět po jednotlivých složkách popisu

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

Více

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika 2 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk UML, základní modely, diagramy aktivit, diagramy entit.

Více

Kolaborativní aplikace

Kolaborativní aplikace Kolaborativní aplikace Michal Máčel Vema, a. s. Okružní 3a, 638 00 Brno - Lesná, macel@vema.cz Tomáš Hruška Fakulta informačních technologií Vysokého učení technického v Brně, Ústav informačních systémů,

Více

Nemocnice. Prvotní analýza a plán projektu

Nemocnice. Prvotní analýza a plán projektu Nemocnice Projekt do předmětu AIS Prvotní analýza a plán projektu Lukáš Pohl, xpohll00, xkosti03 Jan Novák, xnovak79 2009/2010 1 Neformální specifikace FN potřebuje informační systém, který bude obsahovat

Více

Modelování procesů (2) 23.3.2009 Procesní řízení 1

Modelování procesů (2) 23.3.2009 Procesní řízení 1 Modelování procesů (2) 23.3.2009 Procesní řízení 1 Seznam notací Síťové diagramy Notace WfMC Notace Workflow Together Editor Aktivity diagram (UML) FirsStep Designer Procesní mapa Select Prespective (procesní

Více

Funkce. Definiční obor a obor hodnot

Funkce. Definiční obor a obor hodnot Funkce Definiční obor a obor hodnot Opakování definice funkce Funkce je předpis, který každému číslu z definičního oboru, který je podmnožinou množiny všech reálných čísel R, přiřazuje právě jedno reálné

Více

Architektury počítačů a procesorů

Architektury počítačů a procesorů Kapitola 3 Architektury počítačů a procesorů 3.1 Von Neumannova (a harvardská) architektura Von Neumann 1. počítač se skládá z funkčních jednotek - paměť, řadič, aritmetická jednotka, vstupní a výstupní

Více

Markovské metody pro modelování pravděpodobnosti

Markovské metody pro modelování pravděpodobnosti Markovské metody pro modelování pravděpodobnosti rizikových stavů 1 Markovský řetězec Budeme uvažovat náhodný proces s diskrétním časem (náhodnou posloupnost) X(t), t T {0, 1, 2,... } s konečnou množinou

Více

Programovací jazyk Pascal

Programovací jazyk Pascal Programovací jazyk Pascal Syntaktická pravidla (syntaxe jazyka) přesná pravidla pro zápis příkazů Sémantická pravidla (sémantika jazyka) pravidla, která každému příkazu přiřadí přesný význam Všechny konstrukce

Více

Překladač a jeho struktura

Překladač a jeho struktura Překladač a jeho struktura Překladače, přednáška č. 1 Šárka Vavrečková Ústav informatiky, FPF SU Opava sarka.vavreckova@fpf.slu.cz http://fpf.slu.cz/ vav10ui Poslední aktualizace: 23. září 2008 Definice

Více

RELAČNÍ DATABÁZOVÉ SYSTÉMY

RELAČNÍ DATABÁZOVÉ SYSTÉMY RELAČNÍ DATABÁZOVÉ SYSTÉMY VÝPIS KONTROLNÍCH OTÁZEK S ODPOVĚDMI: Základní pojmy databázové technologie: 1. Uveďte základní aspekty pro vymezení jednotlivých přístupů ke zpracování hromadných dat: Pro vymezení

Více

3. Úloha o společném rozhraní

3. Úloha o společném rozhraní 34 3. Úloha o společném rozhraní Cíle Po prostudování této kapitoly budete schopni: Zjistit neregularity v systému Navrhnout řešení pro odstranění neregulárních vazeb Doba potřebná ke studiukapitoly:60minut

Více

Modelování procesů s využitím MS Visio.

Modelování procesů s využitím MS Visio. Modelování procesů s využitím MS Visio jan.matula@autocont.cz Co je to modelování procesů? Kreslení unifikovaných či standardizovaných symbolů, tvarů a grafů, které graficky znázorňují hlavní, řídící nebo

Více

Vyhodnocení studie SPACE

Vyhodnocení studie SPACE Kotlářská 267/2 602 00 Brno Česká republika www.biostatistika.cz Vyhodnocení studie SPACE Tato zpráva sumarizuje data shromážděná v rámci studie SPACE. Data byla poskytnuta Diabetickou asociací ČR. Autorský

Více

Úvod do databázových systémů

Úvod do databázových systémů Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Katedra informatiky Database Research Group Úvod do databázových systémů Cvičení 3 Ing. Petr Lukáš petr.lukas@vsb.cz

Více

8 Makra Příklad 4 Excel 2007

8 Makra Příklad 4 Excel 2007 TÉMA: Úprava maker rozhodování, příkaz If..Then..Else Sekretářka společnosti Naše zahrada potřebuje upravit makra vytvořená pomocí záznamu tak, aby vyhovovala jejím požadavkům. Pro úpravy využije Editor

Více

Grafy. doc. Mgr. Jiří Dvorský, Ph.D. Katedra informatiky Fakulta elektrotechniky a informatiky VŠB TU Ostrava. Prezentace ke dni 13.

Grafy. doc. Mgr. Jiří Dvorský, Ph.D. Katedra informatiky Fakulta elektrotechniky a informatiky VŠB TU Ostrava. Prezentace ke dni 13. Grafy doc. Mgr. Jiří Dvorský, Ph.D. Katedra informatiky Fakulta elektrotechniky a informatiky VŠB TU Ostrava Prezentace ke dni 13. března 2017 Jiří Dvorský (VŠB TUO) Grafy 104 / 309 Osnova přednášky Grafy

Více

Vyhledávání. doc. Mgr. Jiří Dvorský, Ph.D. Katedra informatiky Fakulta elektrotechniky a informatiky VŠB TU Ostrava. Prezentace ke dni 12.

Vyhledávání. doc. Mgr. Jiří Dvorský, Ph.D. Katedra informatiky Fakulta elektrotechniky a informatiky VŠB TU Ostrava. Prezentace ke dni 12. Vyhledávání doc. Mgr. Jiří Dvorský, Ph.D. Katedra informatiky Fakulta elektrotechniky a informatiky VŠB TU Ostrava Prezentace ke dni 12. září 2016 Jiří Dvorský (VŠB TUO) Vyhledávání 201 / 344 Osnova přednášky

Více

Jednofaktorová analýza rozptylu

Jednofaktorová analýza rozptylu I I.I Jednofaktorová analýza rozptylu Úvod Jednofaktorová analýza rozptylu (ANOVA) se využívá při porovnání několika středních hodnot. Často se využívá ve vědeckých a lékařských experimentech, při kterých

Více

S databázemi se v běžném životě setkáváme velmi často. Uvádíme běžné použití databází velkého rozsahu:

S databázemi se v běžném životě setkáváme velmi často. Uvádíme běžné použití databází velkého rozsahu: Úvod do databází Základní pojmy Databáze je množina záznamů, kterou shromažďujeme za nějakým konkrétním účelem. Databáze používáme zejména pro ukládání obsáhlých informací. Databázové systémy jsou k dispozici

Více

Naproti tomu gramatika je vlastně soupis pravidel, jak

Naproti tomu gramatika je vlastně soupis pravidel, jak 1 Kapitola 1 Úvod V přednášce se zaměříme hlavně na konečný popis obecně nekonečných množin řetězců symbolů dané množiny A. Prvkům množiny A budeme říkat písmena, řetězcům (konečným posloupnostem) písmen

Více

Základní pojmy. Úvod do programování. Základní pojmy. Zápis algoritmu. Výraz. Základní pojmy

Základní pojmy. Úvod do programování. Základní pojmy. Zápis algoritmu. Výraz. Základní pojmy Úvod do programování Michal Krátký 1,Jiří Dvorský 1 1 Katedra informatiky VŠB Technická univerzita Ostrava Úvod do programování, 2004/2005 Procesor Procesorem je objekt, který vykonává algoritmem popisovanou

Více

Nový bakalářský studijní obor Biomedicínská informatika na Fakultě biomedicínského inženýrství v Kladně

Nový bakalářský studijní obor Biomedicínská informatika na Fakultě biomedicínského inženýrství v Kladně Fakulta biomedicínského inženýrství České vysoké učení technické v Praze Nový bakalářský studijní obor Biomedicínská informatika na Fakultě biomedicínského inženýrství v Kladně Zoltán Szabó Katedra biomedicínské

Více

Úvod do programovacích jazyků (Java)

Úvod do programovacích jazyků (Java) Úvod do programovacích jazyků (Java) Michal Krátký Katedra informatiky VŠB Technická univerzita Ostrava Úvod do programovacích jazyků (Java), 2007/2008 c 2006 2008 Michal Krátký Úvod do programovacích

Více

Klinické hodnocení ARAMIS pro muže s rakovinou prostaty

Klinické hodnocení ARAMIS pro muže s rakovinou prostaty Klinické hodnocení ARAMIS pro muže s rakovinou prostaty Brožura pro účastníky DĚKUJEME VÁM, že jste se rozhodl zúčastnit klinického hodnocení ARAMIS pro muže s rakovinou prostaty. V této brožuře najdete

Více

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Číslo projektu: CZ.1.07/1.5.00/34.0410 Číslo šablony: 1 Název materiálu: Ročník: Identifikace materiálu: Jméno autora: Předmět: Tématický celek:

Více

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu VÝUKOVÝ MATERIÁL Identifikační údaje školy Vyšší odborná škola a Střední škola, Varnsdorf, příspěvková organizace Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632

Více

Závislost na počítačových hrách u žáků druhého stupně vybraných základních škol

Závislost na počítačových hrách u žáků druhého stupně vybraných základních škol POSUDEK BAKALÁŘSKÉ / MAGISTERSKÉ PRÁCE OPONENT Název Závislost na počítačových hrách u žáků druhého stupně vybraných základních škol Autor Bc. Jiří Zatřepálek Vedoucí práce Mgr. Jaroslav Vacek Oponent

Více

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT)

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta projektu rozpracována do

Více

nské informatice Prof. RNDr. Jana Zvárová, DrSc. informatiku, nské informatiky Ústav informatiky AV ČR R v.v.i. http://www.euromise.

nské informatice Prof. RNDr. Jana Zvárová, DrSc. informatiku, nské informatiky Ústav informatiky AV ČR R v.v.i. http://www.euromise. Vzdělávání v biomedicínsk nské informatice a ezdraví s podporou informačních a komunikačních technologií Prof. RNDr. Jana Zvárová, DrSc. Evropské centrum pro medicínskou informatiku, statistiku a epidemiologii

Více

Vývojové diagramy 1/7

Vývojové diagramy 1/7 Vývojové diagramy 1/7 2 Vývojové diagramy Vývojový diagram je symbolický algoritmický jazyk, který se používá pro názorné zobrazení algoritmu zpracování informací a případnou stručnou publikaci programů.

Více

Podpora skriptování v Audacity

Podpora skriptování v Audacity Specifikace softwarového díla & Časový plán implementace pro Podpora skriptování v Audacity Audacity je oblíběný editor zvuku, který ovšem v současné době postrádá možnost automatizovaného vykonávání skriptů.

Více

ADT STROM Lukáš Foldýna

ADT STROM Lukáš Foldýna ADT STROM Lukáš Foldýna 26. 05. 2006 Stromy mají široké uplatnění jako datové struktury pro různé algoritmy. Jsou to matematické abstrakce množin, kterou v běžném životě používáme velice často. Příkladem

Více

Lekce 9 - Migrace dat

Lekce 9 - Migrace dat Lekce 9 - Migrace dat 1 Cíle lekce...1 2 Co je migrace dat?...1 3 Cíle migrace dat...1 4 Parametry migrace dat...1 5 Procesy migrace dat...2 6 Projekt migrace dat...3 7 Zařazení projektu migrace do projektu

Více

Výhody a nevýhody jednotlivých reprezentací jsou shrnuty na konci kapitoly.

Výhody a nevýhody jednotlivých reprezentací jsou shrnuty na konci kapitoly. Kapitola Reprezentace grafu V kapitole?? jsme se dozvěděli, co to jsou grafy a k čemu jsou dobré. rzo budeme chtít napsat nějaký program, který s grafy pracuje. le jak si takový graf uložit do počítače?

Více

Využití a zneužití statistických metod v medicíně

Využití a zneužití statistických metod v medicíně Využití a zneužití statistických metod v medicíně Martin Hynek Gennet, Centre for Fetal Medicine, Prague EuroMISE Centre, First Faculty of Medicine of Charles University in Prague Statistika Existují tři

Více

MATICE. a 11 a 12 a 1n a 21 a 22 a 2n A = = [a ij]

MATICE. a 11 a 12 a 1n a 21 a 22 a 2n A = = [a ij] MATICE Matice typu m/n nad tělesem T je soubor m n prvků z tělesa T uspořádaných do m řádků a n sloupců: a 11 a 12 a 1n a 21 a 22 a 2n A = = [a ij] a m1 a m2 a mn Prvek a i,j je prvek matice A na místě

Více

Modely teorie grafů, min.kostra, max.tok, CPM, MPM, PERT

Modely teorie grafů, min.kostra, max.tok, CPM, MPM, PERT PEF ČZU Modely teorie grafů, min.kostra, max.tok, CPM, MPM, PERT Okruhy SZB č. 5 Zdroje: Demel, J., Operační výzkum Jablonský J., Operační výzkum Šubrt, T., Langrová, P., Projektové řízení I. a různá internetová

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

Evidence požadavků uživatelů bytů a nebytových prostor

Evidence požadavků uživatelů bytů a nebytových prostor Evidence požadavků uživatelů bytů a nebytových prostor Úvod Pro zjednodušení a zprůhlednění Vaší komunikace se správní firmou (dále jen SF ), která má na starost objekt, v němž se nachází bytový či nebytový

Více

Aplikace pro srovna ní cen povinne ho ruc ení

Aplikace pro srovna ní cen povinne ho ruc ení Aplikace pro srovna ní cen povinne ho ruc ení Ukázkový přiklad mikroaplikace systému Formcrates 2010 Naucrates s.r.o. Veškerá práva vyhrazena. Vyskočilova 741/3, 140 00 Praha 4 Czech Republic tel.: +420

Více

On-line dražební systém EDEN návod k použití

On-line dražební systém EDEN návod k použití On-line dražební systém EDEN návod k použití Obsah dokumentu 1. Registrace uživatele...2 2. Verifikace (ověření) e-mailu...3 3. Zapomenuté heslo...3 4. Přihlášení uživatele...4 5. Změna hesla...5 6. Přehled

Více

6. blok část B Vnořené dotazy

6. blok část B Vnořené dotazy 6. blok část B Vnořené dotazy Studijní cíl Tento blok je věnován práci s vnořenými dotazy. Popisuje rozdíl mezi korelovanými a nekorelovanými vnořenými dotazy a zobrazuje jejich použití. Doba nutná k nastudování

Více

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1 Dominik Vymětal 2009, Ostrava 1.-2.10.2009 1 Procesní model Výhody Orientace na konkrétní činnosti a možnost reengineeringu Nevýhody Malá orientace na průřezové nebo opakované činnosti Modely na základě

Více

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 Zadavatel: Česká republika Ministerstvo životního prostředí Sídlo: Vršovická 1442/65, 100 10 Praha 10 IČO: 00164801 Jednající: Název veřejné zakázky: Ing.

Více

Psychodiagnostika Hogan a 360 dotazník

Psychodiagnostika Hogan a 360 dotazník Psychodiagnostika Hogan a 360 dotazník Na svých pozicích řešíte množství situací a vztahů, které jsou pro vás náročnější než jiné a pravděpodobně si kladete otázku proč. Jednou z možností, jak na tuto

Více

Diskrétní řešení vzpěru prutu

Diskrétní řešení vzpěru prutu 1 z 5 Diskrétní řešení vzpěru prutu Discrete solution of beam buckling Petr Frantík Abstract Here is described discrete method for solution of beam buckling. The beam is divided into a number of tough

Více

Střední průmyslová škola Zlín

Střední průmyslová škola Zlín VY_32_INOVACE_33_01 Škola Název projektu, reg. č. Vzdělávací oblast Vzdělávací obor Tematický okruh Téma Tematická oblast Název Autor Vytvořeno, pro obor, ročník Anotace Přínos/cílové kompetence Střední

Více

24-2-2 PROMĚNNÉ, KONSTANTY A DATOVÉ TYPY TEORIE DATUM VYTVOŘENÍ: 23.7.2013 KLÍČOVÁ AKTIVITA: 02 PROGRAMOVÁNÍ 2. ROČNÍK (PRG2) HODINOVÁ DOTACE: 1

24-2-2 PROMĚNNÉ, KONSTANTY A DATOVÉ TYPY TEORIE DATUM VYTVOŘENÍ: 23.7.2013 KLÍČOVÁ AKTIVITA: 02 PROGRAMOVÁNÍ 2. ROČNÍK (PRG2) HODINOVÁ DOTACE: 1 24-2-2 PROMĚNNÉ, KONSTANTY A DATOVÉ TYPY TEORIE AUTOR DOKUMENTU: MGR. MARTINA SUKOVÁ DATUM VYTVOŘENÍ: 23.7.2013 KLÍČOVÁ AKTIVITA: 02 UČIVO: STUDIJNÍ OBOR: PROGRAMOVÁNÍ 2. ROČNÍK (PRG2) INFORMAČNÍ TECHNOLOGIE

Více

Speciální informační služby pro zdravotníky v Národní lékařské knihovně PhDr. Eva Lesenková, Ph.D. Mgr. Adéla Jarolímková, Ph.D.

Speciální informační služby pro zdravotníky v Národní lékařské knihovně PhDr. Eva Lesenková, Ph.D. Mgr. Adéla Jarolímková, Ph.D. Speciální informační služby pro zdravotníky v Národní lékařské knihovně PhDr. Eva Lesenková, Ph.D. Mgr. Adéla Jarolímková, Ph.D. Národní lékařská knihovna Praha specializovaná veřejná knihovna (Knihovní

Více

Algoritmizace a programování

Algoritmizace a programování Algoritmizace a programování Výrazy Operátory Výrazy Verze pro akademický rok 2012/2013 1 Operace, operátory Unární jeden operand, operátor se zapisuje ve většině případů před operand, v některých případech

Více

ANOTACE vytvořených/inovovaných materiálů

ANOTACE vytvořených/inovovaných materiálů ANOTACE vytvořených/inovovaných materiálů Číslo projektu Číslo a název šablony klíčové aktivity Tematická oblast Formát Druh učebního materiálu Druh interaktivity CZ.1.07/1.5.00/34.0722 III/2 Inovace a

Více

Základy programování. Úloha: Eratosthenovo síto. Autor: Josef Hrabal Číslo: HRA0031 Datum: 28.11.2009 Předmět: ZAP

Základy programování. Úloha: Eratosthenovo síto. Autor: Josef Hrabal Číslo: HRA0031 Datum: 28.11.2009 Předmět: ZAP Základy programování Úloha: Eratosthenovo síto Autor: Josef Hrabal Číslo: HRA0031 Datum: 28.11.2009 Předmět: ZAP Obsah 1 Zadání úkolu: 3 1.1 Zadání:............................... 3 1.2 Neformální zápis:.........................

Více

ČSN ISO/IEC OPRAVA 1

ČSN ISO/IEC OPRAVA 1 ČESKÁ TECHNICKÁ NORMA ICS 35.040 Únor 2011 Informační technologie Formáty výměny biometrických dat Část 2: Data markantů prstu ČSN ISO/IEC 19794-2 OPRAVA 1 36 9860 idt ISO/IEC 19794-2:2005/Cor.1:2009-10

Více

Výukový materiál zpracován v rámci projektu EU peníze školám

Výukový materiál zpracován v rámci projektu EU peníze školám Výukový materiál zpracován v rámci projektu EU peníze školám Registrační číslo projektu: CZ. 1.07/1.5.00/34.0637 Šablona III/2 Název VY_32_INOVACE_39_Algoritmizace_teorie Název školy Základní škola a Střední

Více

Martin Milata, <256615@mail.muni.cz> 27.11.2007. Pokud je alespoň jeden rozměr čokolády sudý (s výjimkou tabulky velikosti 1x2, která už je od

Martin Milata, <256615@mail.muni.cz> 27.11.2007. Pokud je alespoň jeden rozměr čokolády sudý (s výjimkou tabulky velikosti 1x2, která už je od IB000 Lámání čokolády Martin Milata, 27.11.2007 1 Čokoláda s alespoň jedním sudým rozměrem Pokud je alespoň jeden rozměr čokolády sudý (s výjimkou tabulky velikosti 1x2, která už

Více