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

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

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

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

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

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

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

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

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

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

Č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

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

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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Semestrální práce 2 znakový strom

Semestrální práce 2 znakový strom Semestrální práce 2 znakový strom Ondřej Petržilka Datový model BlockFileRecord Bázová abstraktní třída pro záznam ukládaný do blokového souboru RhymeRecord Konkrétní třída záznamu ukládaného do blokového

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

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

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

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

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

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

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

emedocs Exchange Medical Document System David Zažímal Petr Pavlinec

emedocs Exchange Medical Document System David Zažímal Petr Pavlinec emedocs Exchange Medical Document System David Zažímal Petr Pavlinec ehealth strategie Kraje Vysočina Projekty ehealth Vysočiny uskutečněné probíhající plánované SWLab e@mbulance ERP QI nový NIS MarkQ

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

Úloha ve stavovém prostoru SP je , kde s 0 je počáteční stav C je množina požadovaných cílových stavů

Úloha ve stavovém prostoru SP je <s 0, C>, kde s 0 je počáteční stav C je množina požadovaných cílových stavů Stavový prostor a jeho prohledávání SP = formalismus k obecnějšímu uchopení a vymezení problému, který spočívá v nalezení posloupnosti akcí vedoucích od počátečního stavu úlohy (zadání) k požadovanému

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

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

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á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

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

Program a životní cyklus programu

Program a životní cyklus programu Program a životní cyklus programu Program algoritmus zapsaný formálně, srozumitelně pro počítač program se skládá z elementárních kroků Elementární kroky mohou být: instrukce operačního kódu počítače příkazy

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

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

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

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky.

Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky. Inovace tohoto kurzu byla spolufinancována z Evropského sociálního fondu a státního rozpočtu České republiky. Projekt ESF OP VK reg.č. CZ.1.07/2.2.00/28.0209 Elektronické opory a e-learning pro obory výpočtového

Více

Pracovní seminář ASEP k hodnocení 2015

Pracovní seminář ASEP k hodnocení 2015 Pracovní seminář ASEP k hodnocení 2015 Kolektiv ASEP Knihovna AV ČR, v. v. i. Praha 4. 12. 2014, Brno 10. 12. 2014 Program Hodnocení AV v roce 2015, KIS a ASEP Bibliografické záznamy, ukládání plných textů,

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

SMĚRNICE DĚKANA Č. 4/2013

SMĚRNICE DĚKANA Č. 4/2013 Vysoké učení technické v Brně Datum vydání: 11. 10. 2013 Čj.: 076/17900/2013/Sd Za věcnou stránku odpovídá: Hlavní metodik kvality Za oblast právní odpovídá: --- Závaznost: Fakulta podnikatelská (FP) Vydává:

Více

FORTANNS. havlicekv@fzp.czu.cz 22. února 2010

FORTANNS. havlicekv@fzp.czu.cz 22. února 2010 FORTANNS manuál Vojtěch Havlíček havlicekv@fzp.czu.cz 22. února 2010 1 Úvod Program FORTANNS je software určený k modelování časových řad. Kód programu má 1800 řádek a je napsán v programovacím jazyku

Více

1. Umístěte kurzor do sloupce Datový typ na řádek s polem, ve kterém vytvořit chcete seznam.

1. Umístěte kurzor do sloupce Datový typ na řádek s polem, ve kterém vytvořit chcete seznam. 10.6.7 POSTUP TVORBY KOMBINOVANÉHO SEZNAMU 1. Umístěte kurzor do sloupce Datový typ na řádek s polem, ve kterém vytvořit chcete seznam. 2. V rozbalovací nabídce se seznamem datových typů vyberte volbu

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

Interaktivní nástroje pro výuku léčebných standardů cytostatické léčby zhoubných nádorů Portál DIOS

Interaktivní nástroje pro výuku léčebných standardů cytostatické léčby zhoubných nádorů Portál DIOS Interaktivní nástroje pro výuku léčebných standardů cytostatické léčby zhoubných nádorů Portál DIOS Klimeš D., Dušek L., Kubásek J., Fínek J., Petruželka L., Zoláková A., Vyzula R. Historie projektu Snaha

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

Maturitní otázky z předmětu PROGRAMOVÁNÍ

Maturitní otázky z předmětu PROGRAMOVÁNÍ Wichterlovo gymnázium, Ostrava-Poruba, příspěvková organizace Maturitní otázky z předmětu PROGRAMOVÁNÍ 1. Algoritmus a jeho vlastnosti algoritmus a jeho vlastnosti, formy zápisu algoritmu ověřování správnosti

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

13 Barvy a úpravy rastrového

13 Barvy a úpravy rastrového 13 Barvy a úpravy rastrového Studijní cíl Tento blok je věnován základním metodám pro úpravu rastrového obrazu, jako je např. otočení, horizontální a vertikální překlopení. Dále budo vysvětleny různé metody

Více

EKONOMETRIE 7. přednáška Fáze ekonometrické analýzy

EKONOMETRIE 7. přednáška Fáze ekonometrické analýzy EKONOMETRIE 7. přednáška Fáze ekonometrické analýzy Ekonometrická analýza proces, skládající se z následujících fází: a) specifikace b) kvantifikace c) verifikace d) aplikace Postupné zpřesňování jednotlivých

Více

Postupy práce se šablonami IS MPP

Postupy práce se šablonami IS MPP Postupy práce se šablonami IS MPP Modul plánování a přezkoumávání, verze 1.20 vypracovala společnost ASD Software, s.r.o. dokument ze dne 27. 3. 2013, verze 1.01 Postupy práce se šablonami IS MPP Modul

Více

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií VY_32_INOVACE_33_02 Š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

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

PŘETĚŽOVÁNÍ OPERÁTORŮ

PŘETĚŽOVÁNÍ OPERÁTORŮ PŘETĚŽOVÁNÍ OPERÁTORŮ Jazyk C# podobně jako jazyk C++ umožňuje přetěžovat operátory, tj. rozšířit definice některých standardních operátorů na uživatelem definované typy (třídy a struktury). Stejně jako

Více

Zabezpečení proti SQL injection

Zabezpečení proti SQL injection Zabezpečení proti SQL injection ESO9 intranet a.s. Zpracoval: Tomáš Urych U Mlýna 2305/22, 141 Praha 4 Záběhlice Dne: 19.9.2012 tel.: +420 585 203 370-2 e-mail: info@eso9.cz Revize: Urych Tomáš www.eso9.cz

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

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

VZORCE A VÝPOČTY. Autor: Mgr. Dana Kaprálová. Datum (období) tvorby: září, říjen 2013. Ročník: sedmý

VZORCE A VÝPOČTY. Autor: Mgr. Dana Kaprálová. Datum (období) tvorby: září, říjen 2013. Ročník: sedmý Autor: Mgr. Dana Kaprálová VZORCE A VÝPOČTY Datum (období) tvorby: září, říjen 2013 Ročník: sedmý Vzdělávací oblast: Informatika a výpočetní technika 1 Anotace: Žáci se seznámí se základní obsluhou tabulkového

Více

Access. Tabulky. Vytvoření tabulky

Access. Tabulky. Vytvoření tabulky Access správa databáze (tabulky, relace, omezující podmínky, data...) uživatelské prostředí pro práci s databází (formuláře, sestavy, datové stránky, makra...) ukázková aplikace Northwind hlavní okno databáze

Více

Manuál na pořízení technické změny pomocí webové kalkulačky. Verze 1.2

Manuál na pořízení technické změny pomocí webové kalkulačky. Verze 1.2 Manuál na pořízení technické změny pomocí webové kalkulačky Verze 1.2 2 Obsah 1. Úvod.. 3 1.1. Základní informace 3 1.2. Spuštění kalkulačky. 3 1.3. Přehled možných úprav 4 2. Sestavení technické změny.

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

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

EndNote Web. Stručné informace THOMSON SCIENTIFIC

EndNote Web. Stručné informace THOMSON SCIENTIFIC THOMSON SCIENTIFIC EndNote Web Stručné informace Web je webový nástroj navržený tak, aby poskytoval studentům a výzkumníkům pomoc při psaní výzkumných prací. Databáze ISI Web of Knowledge a nástroje EndNote

Více

DoplněkCite While You Write pro aplikaci Microsoft Word

DoplněkCite While You Write pro aplikaci Microsoft Word DoplněkCite While You Write pro aplikaci Microsoft Word Díky doplňku Cite While You Write pro nástroj EndNote Web máte možnost reference a formátované citace či bibliografie při psaní vaší práce v aplikaci

Více

xrays optimalizační nástroj

xrays optimalizační nástroj xrays optimalizační nástroj Optimalizační nástroj xoptimizer je součástí webového spedičního systému a využívá mnoho z jeho stavebních bloků. xoptimizer lze nicméně provozovat i samostatně. Cílem tohoto

Více

Masterský studijní obor datové & webové inženýrství

Masterský studijní obor datové & webové inženýrství Masterský studijní obor datové & webové inženýrství Předpoklady Struktura studia Přihlášky Poradenství Masterský studijní obor datové & webové inženýrství představuje ve studijním konceptu fakulty informatiky

Více

Monitorovací zprávy v aplikaci Benefit7. Nejčastější dotazy a chyby

Monitorovací zprávy v aplikaci Benefit7. Nejčastější dotazy a chyby Monitorovací zprávy v aplikaci Benefit7 Nejčastější dotazy a chyby Podklady pro příjemce Postup administrace monitorovací zprávy v aplikaci Benefit 7+ je podrobně popsán v dokumentu s názvem Příručka Elektronická

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

Pacientův průvodce po webu

Pacientův průvodce po webu Pacientův průvodce po webu Webové stránky jsou jedním z nejvyužívanějších zdrojů pro vyhledávání informací o tělesném a duševním zdraví a diagnostice a léčbě chorob. Velké množství webových stránek obsahuje

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Reranking založený na metadatech

Reranking založený na metadatech České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Reranking založený na metadatech MI-VMW Projekt IV - 1 Pavel Homolka Ladislav Kubeš 6. 12. 2011 1

Více

Spolehlivost soustav

Spolehlivost soustav 1 Spolehlivost soustav Spolehlivost soustav 1.1 Koherentní systémy a strukturní funkce Budeme se zabývat modelováním spolehlivosti zřízení s ohledem na spolehlivost jeho komponent. Jedním z hlavních cílů

Více

Funkce, podmíněný příkaz if-else, příkaz cyklu for

Funkce, podmíněný příkaz if-else, příkaz cyklu for Funkce, podmíněný příkaz if-else, příkaz cyklu for Definice funkce Funkce je pojmenovaná část programu, kterou lze dále zavolat v jiné části programu. V Pythonu je definována klíčovým slovem def. Za tímto

Více

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 12. Virtuální sítě (VLAN) Studijní cíl Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 1 hodina VLAN Virtuální síť bývá definována jako logický segment LAN, který spojuje koncové uzly, které

Více

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná.

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná. Průběžná klasifikace Nová verze modulu Klasifikace žáků přináší novinky především v práci s průběžnou klasifikací. Pro zadání průběžné klasifikace ve třídě doposud existovaly 3 funkce Průběžná klasifikace,

Více

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová

Objektově orientované technologie Logická struktura systému Objektový diagram. Pavel Děrgel, Daniela Szturcová Objektově orientované technologie Logická struktura systému Objektový diagram Pavel Děrgel, Daniela Szturcová Osnova Modelování objektů objektový diagram Struktura a vazby mezi objekty Dobré zvyky při

Více

Délka (dny) 150 - - 2 terénní úpravy (prvotní) 15-20 - příprava staveniště (výstavba přístřešku pro materiál)

Délka (dny) 150 - - 2 terénní úpravy (prvotní) 15-20 - příprava staveniště (výstavba přístřešku pro materiál) Skupinová práce. Zadání skupinové práce Síťová analýza metoda CPM Dáno: Výstavba skladu zásob obilí představuje následující činnosti: Tabulka Název činnosti Délka (dny) Optimální projekt. Optimální dělníků

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více