Určení kompatibility doporučení: porovnání klinických

cs1
Original Article
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ší.
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
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: [email protected]
1
Ú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ý
c
2012
EuroMISE s.r.o.
EJBI 2012; 8(1):cs1–cs13
zasláno: 12. prosince 2011
přijato: 12. března 2012
publikováno: 15. června 2012
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í paEJBI – Volume 8 (2012), Issue 1
cs2
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ž
EJBI – Volume 8 (2012), Issue 1
Veselý, Zvárová – Určení kompatibility doporučení
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
c
2012
EuroMISE s.r.o.
cs3
Veselý, Zvárová – Určení kompatibility doporučení
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.
finová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. 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.
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í)
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).
kde Pi (ti ) označuje hodnotu parametru Pi v čase ti .
Abychom notaci zjednodušili, předpokládáme, že jednotkou času jsou dny zapsané ve formátu day.month.year,
například t = 1.1.02 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.
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
1. EZZ obsahuje veškerou relevantní informaci, to zna- jeho příznaku v určitém čase. Výsledek budeme psát ve
mená, že všechny akce lékaře během léčby pacienta tvaru
P (time) = value.
jsou do EZZ zaznamenány.
Č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ě dec
2012
EuroMISE s.r.o.
S = {P1 (t1 ) = c1 , . . . , Pn (tn ) = cn }, t1 ≤ . . . ≤ tn ,
Tabulka 1: Datový model jednoduchých doporučení z příkladu 1.
akce
Změření systolického
krevního tlaku
Změření diastolického
krevního tlaku
Test HDL cholesterolu
Test LDL cholesterolu
Předepsání dietního režimu
Předpis medikace
parameter P
SBP
typ
numerický
DBP
numerický
HDL
LDL
Diet
numerický
numerický
Booleovský
M edication
Booleovský
EJBI – Volume 8 (2012), Issue 1
cs4
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ů PG , 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 (EGLIF 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 N C s n
vstupy jsou přicházející tokeny ukládány do n parameEJBI – Volume 8 (2012), Issue 1
Veselý, Zvárová – Určení kompatibility doporučení
trů token1 , . . . , tokenn . 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ř.
A1 , A2 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ř. A1 (result) nebo T IM2 (β). 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 , next1 ), . . . ,
(αn , nextn )
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 6= 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
(A1 (result) > 10) ∧ (A2 (result) < 100).
c
2012
EuroMISE s.r.o.
cs5
Veselý, Zvárová – Určení kompatibility doporučení
Obrázek 1: Porovnání pacientova zdravotního záznamu s kódovanými doporučeními.
Uzel větvení (branch node) BRN (next1 , . . . , nextn )
Časový uzel (time node) T IM (time, β, next)
Uzel větvení vnáší do modelu paralelismus. Z uzlu větČasový uzel stanoví časové omezení následující akce.
vení lze pokračovat libovolnou větví. Větve mohou být Když token prochází časovým uzlem T IM , aktuální čas
procházeny simultánně, avšak následnost kroků na jed- je zaznamenán do parametru T IM (time). Podmínka β je
notlivých větvích musí být dodržena.
časová podmínka, která musí být splněna pro čas následující akce. V definici podmínky β časový parametr násleSynchronizační uzel (synchronization node)
dující akce je označen f time.
SY N (token1 , . . . , tokenn , α, β, time, next)
Například
β = ((f time − T IM (time)) ≤ year).
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).
Startovací uzel (start node) reprezentuje začátek průPokud token přichází z i-té větve, je uložen do i-tého chodu grafem
parametru tokeni . Průchod tokenu synchronizačním uzST ART (token, next).
lem je možný pouze když synchronizační podmínka α je
splněna. Podmínka α je výroková formule vytvořená z parametrů token1 , . . . , tokenn . Například
Uzel zastavení (stop node) reprezentuje konec procháα = (token1 ∧ token2 ) ∨ token3 .
zení grafem.
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).
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
Tato podmínka stanoví, že jestliže B je libovolný uzel
EGLIF model je množina výše popsaných uzlů vytváležící v podgrafu BRN − SY N , potom musí být splněna řejících pomocí pointerů (uložených v jejich parametrech
podmínka (B(time) − A(time)) ≤ year.
next) spojitý orientovaný graf, pokud jsou splněny následující podmínky C1 − C4 .
Stavový uzel (state node) ST AT E(name, next) přiřazuje stavu pacienta jméno.
C1 Množina uzlů obsahuje právě jeden Startovací uzel.
c
2012
EuroMISE s.r.o.
EJBI – Volume 8 (2012), Issue 1
cs6
Veselý, Zvárová – Určení kompatibility doporučení
C2 Pro každý uzel větvení BRN existuje jeden synchro- 3
Výsledky
nizační uzel SY N , ve kterém všechny větve, které
začínají v BRN uzlu, končí. Podgraf EGLIF moV tomto paragrafu popíšeme algoritmus pro srovnádelu, který začíná uzlem BRN a končí uzlem SY N vání EGLIF modelu striktních doporučení s kompletním
nazýváme BRN − SY N podgraf EGLIF modelu.
datovým záznamem pacienta. Začneme příkladem.
C3 Jestliže G1 a G2 jsou dva BRN − SY N podgrafy, Příklad 2
potom platí pouze jedna z následujících podmínek:
Předpokládáme, že lékař ukládá hodnoty všech vya) G1 ⊂ G2 (tj. každý uzel G1 je také uzlem G2 ) šetřených parametrů pacienta (HDL, LDL, SBP, DBP )
a údaje o všech předepsaných terapiích (Diet, M edication)
b) G2 ⊂ G1
do pacientova zdravotního záznamu. Předpokládáme dále,
c) G1 ∩G2 = ∅ (tj. G1 a G2 nemají společný žádný že pacientova data uložená v systému EZZ mohou být
uzel).
vypsána ve formě datové sekvence popsané výše. PředpoC4 Topologie grafu je taková, že během předání tokenu, kládejme, že systému EZZ poskytnul následující datové
token prochází nejvýše jedním časovým uzlem T IM sekvence SA , SB , SC , SD pro 4 pacienty A, B, C a D.
a tímto uzlem prochází nejvýš jednou.
SA = {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 (10.2.01) = 85,
SBP (10.2.01) = 140, SBP (1.5.01) = 130, DBP (1.5.01) = 85,
Příklad 1
HDL(2.5.01) = 1, LDL(2.5.01) = 5, SBP (1.4.02) = 130,
Malá doporučení pro prevenci srdečního selhání
DBP (1.4.02) = 90, LDL(2.4.01) = 7, HDL(2.4.01) = 2}
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.
SB = {SBP (1.1.01) = 150, DBP (1.1.01) = 85, HDL(2.1.01) = 1,
LDL(2.1.01) = 6, DBP (10.2.01) = 85, SBP (10.2.01) = 140,
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
iR = (LDL − HDL)/HDL.
Pokud hodnota rizikového indexu je malá (iR <
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 iR . Pokud hodnota rizikového indexu je malá (iR < 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. 3.
EJBI – Volume 8 (2012), Issue 1
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}
SC = {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}
SD = {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 (10.2.01) = 85,
SBP (10.2.01) = 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 SA , SB , SC
a SD s Malými doporučeními pro prevenci srdečního selhání popsanými v Příkladu 1.
Porovnáním SA s těmito doporučeními zjistíme, že pacient A byl léčen v souladu s doporučeními.
Když porovnáme SB 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 SB chybí.
Léčení pacienta C také nebylo v souladu s doporučeními, protože při návštěvě 1.1.01 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
c
2012
EuroMISE s.r.o.
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ě 2.5.01 měl hodnotu iR = 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 1.4.02, 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
c
2012
EuroMISE s.r.o.
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 = {P1 (t1 ) = c1 , . . . , Pn (tn ) = cn }. 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 Pi (ti ) = ci . Po odebrání položky
algoritmus nalezne všechny akční uzly, které mají token
a jejichž parametr action má hodnotu Pi . V každém naEJBI – Volume 8 (2012), Issue 1
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 ti do parametru
time a hodnotu ci 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 = N U LL.
(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
EJBI – Volume 8 (2012), Issue 1
P (t) = c tak dlouho, dokud není P ∈ PG (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čí N0 .
(a) Jestliže je množina N0 prázdná, algoritmus vytiskne chybovou hlášku „Chyba v následnosti
akcí“ a skončí.
(b) Jestliže množina N0 není prázdná, potom
v každém akčním uzlu A ∈ N0 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 N0 , které splňují
následující podmínky cond1 a cond2 algoritmus
označí N1 .
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 ) 6= N U LL), potom časová podmínka β časového uzlu T IM je splněna.
Pokud množina N1 je prázdná, algoritmus
vytiskne chybovou hlášku „Časová chyba“
a skončí. V opačném případě v každém uzlu
A ∈ N0 algoritmus nastaví A(token) = 0
a z každého uzlu A ∈ N1 posune token do
c
2012
EuroMISE s.r.o.
cs9
Veselý, Zvárová – Určení kompatibility doporučení
Tabulka 2: Srovnání datové sekvence SA 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
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Data item Si
Start
SBP (1.1.01) = 150
DBP (1.1.01) = 85
HDL(2.1.01) = 1
LDL(2.1.01) = 6
A1 A2 A3 A4 SY N1 (1)SY N1 (2)SY N1 (3)SY N1 (4)A5 A6 A7 SY N2 (1)SY N2 (2)
• • • •
• • •
•
• •
•
•
•
•
•
•
•
•
•
•
•
Diet(2.1.01) = 1
•
•
DBP (10.2.01) = 85
•
•
SBP (10.2.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
•
•
•
•
• • • •
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.
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.
Část 2 (Pravidla posunu tokenů)
Pokud algoritmus CA neskončí chybou, skončí z jed1. Tokeny jsou posunovány podél větví grafu. V rozho- noho ze dvou následujících důvodů.
dovacím uzlu posunovaný token pokračuje tou větví
1. Všechny datové položky Si byly z datové sekvence
i, jejíž podmínka αi je splněna. V uzlu větvení s n
S odebrány. V tomto případě pacient byl léčen ve
větvemi algoritmus vytvoří n−1 nových tokenů. Tokeny, které uzel větvení opouštějí, algoritmus posushodě s doporučeními. Podle doporučení má však
nuje podél různých větví.
jeho léčba dál pokračovat.
c
2012
EuroMISE s.r.o.
EJBI – Volume 8 (2012), Issue 1
cs10
Veselý, Zvárová – Určení kompatibility doporučení
Tabulka 3: Srovnání datové sekvence SB s EGLIF modelem. V kroku 5 je generována chybová hláška „Chyba v následnosti
akcí“ , protože množina N0 je v tomto kroku prázdná.
Step
0
1
2
3
4
5
Data item Si
A1 A2 A3 A4 SY N1 (1)SY N1 (2)SY N1 (3)SY N1 (4)A5 A6 A7 SY N2 (1)SY N2 (2)
Start
• • • •
SBP (1.1.01) = 150
• • •
•
DBP (1.1.01) = 85
• •
•
•
HDL(2.1.01) = 1
•
•
•
•
LDL(2.1.01) = 6
•
•
•
•
•
DBP (10.2.01) = 85
•
Tabulka 4: Porovnání datové sekvence SC s EGLIF modelem. V kroku 6 algoritmus generuje signál „Časová chyba“ , protože
množina N1 je prázdná.
Step
0
1
2
3
4
5
6
Data item Si
A1 A2 A3 A4 SY N1 (1)SY N1 (2)SY N1 (3)SY N1 (4)A5 A6 A7 SY N2 (1)SY N2 (2)
Start
• • • •
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
• •
2. 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í.
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í SB (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 A7 má token, odebraná položka použitá pro srovAbychom demonstrovali chování algoritmu CA, pounání je DBP (10.2.01) = 85 a A7 (action) = Diet. Protože
žijeme jej pro srovnání Malých doporučení pro prevenci
Diet 6= DBP , množina N0 je prázdná a tudíž algoritmus
srdečního selhání z Příkladu 1 s datovými záznamy paciskončí s chybovou hláškou „Chyba v následnosti akcí“ .
entů A, B, C a D, které jsme uvažovali výše. Předpokládáme, že doporučení byla formalizována pomocí EGLIF
Jestliže CA algoritmus srovnává EGLIF model s datomodelu a že datové záznamy pacientů byly transformovou sekvencí SC , porovnávaní skončí v kroku 6 chybovou
vány do datových sekvencí SA , SB , SC a SD uvedenými
hláškou „Časová chyba“ . V kroku 6 je odebrána datová
výše. Průběh algoritmu pro jednotlivé datové sekvence je
položka DBP (1.4.01) = 85. Jediné akční uzly, které mají
zachycen v tabulkách 2–5. V těchto tabulkách je znázorněn
na začátku kroku 6 tokeny, jsou uzly A5 a A6 . Jejich papohyb tokenů. Přítomnost tokenu v určitém uzlu (nebo
rametr action má hodnotu A5 (action) = SBP respektive
tokenů jestliže se jedná o synchronizační uzel SY N ) na
A6 (action) = DBP . Tudíž množina N0 = {A6 } a parakonci n-tého kroku je znázorněna černou tečkou. Napřímetr A6 (time)) je nastaven na hodnotu 1.4.01. Uzel A6 je
klad černá tečka v buňce (step = 0, A1 ) tabulky 2 znauvnitř podgrafu BRN2 ˘SY N2 a podmínka β uzlu SY N2
mená, že na konci nultého kroku bylo A1 (token) = 1,
je
černá tečka v buňce (step = 3, SY N1 (2)) znamená, že
na konci třetího kroku bylo SY N1 (token2 ) = 1, prázdná
(1 month ≤ (atime − A7 (time)) ≤ 2 months).
buňka (step = 2, SY N1 (3)) znamená, že na konci druhého
kroku bylo SY N1 (token3 ) = 0 atd. Pokud je řádka ně- Proto podmínka
kterého kroku rozdělena na dvě části, potom první část
popisuje rozložení tokenů po první fázi kroku, to zna(1 month ≤ (A6 (time) − A7 (time)) ≤ 2 months).
mená těsně před posunem tokenů ze synchronizačních uzlů
musí být splněna. Tato podmínka ale splněna není, proSY N .
tože A7 (time) = 2.1.01. Proto algoritmus generuje chyboJestliže CA algoritmus srovnává EGLIF model dopo- vou hlášku „Časová chyba“ .
ručení s datovou sekvencí SA (viz tab. 2), potom proces porovnávání skončí krokem 15. Datová sekvence je
Jestliže CA algoritmus porovnává EGLIF model s daprázdná a uzel ST OP neobsahuje token. To znamená, že tovou sekvencí SD (viz tabulka 5), porovnávání skončí
EJBI – Volume 8 (2012), Issue 1
c
2012
EuroMISE s.r.o.
cs11
Veselý, Zvárová – Určení kompatibility doporučení
Tabulka 5: Srovnání datové sekvence SD s EGLIF modelem. V kroku 12 je generována chybová hláška „Časová chyba“ , protože
množina N1 je prázdná.
Step
0
1
2
3
4
5
6
7
8
9
10
11
12
Data item Si
Start
SBP (1.1.01) = 150
DBP (1.1.01) = 85
HDL(2.1.01) = 1
LDL(2.1.01) = 6
A1 A2 A3 A4 SY N1 (1)SY N1 (2)SY N1 (3)SY N1 (4)A5 A6 A7 SY N2 (1)SY N2 (2)
• • • •
• • •
•
• •
•
•
•
•
•
•
•
•
•
•
•
Diet(2.1.01) = 1
• •
DBP (10.2.01) = 85
•
•
SBP (10.2.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
• • •
•
v kroku 12 a algoritmus generuje chybovou hlášku „Časová
chyba“ . Na začátku kroku 12 mají token uzly A1 , A2 , A3
a A4 , ale pouze uzel A1 má hodnotu parametru action
rovnou SBP . Tudíž N0 = A1 a A1 (time) = 1.4.02. Když
byl token předáván do uzlu A1 , prošel uzlem T IM2 . Proto
platí A1 (ref ) = T IM2 a T IM2 (time) = 2.5.01. Podmínka
β uzlu T IM2 je
f time − T IM2 (time) ≤ 0.5 year.
Protože f time = 1.4.02, podmínka β není splněna a algoritmus generuje chybovou hlášku „Časová chyba“ .
4
Závěr
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 C1 and C2 se nazývá přípustná.
C1 Všechny strict out-conditions a out-conditions na
této větvi nabývají hodnotu false.
C2 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 doV tomto článku byl popsán algoritmus, který porovporučení.
Léčení je v souladu s doporučeními, která nejsou
nává léčbu pacienta zachycenou v pacientově zdravotním
striktní,
jestliže
každé provedené rozhodnutí vyústí v pozáznamu s formálním modelem (EGLIF modelem) klinickračování
po
přípustné
větvi.
kých doporučení. Algoritmus pracuje správně, pokud jsou
Algoritmus
porovnávání
CA, který byl představen
splněny dvě podmínky:
výše, lze snadno upravit tak, aby porovnával pacientův
1. EGLIF model je striktní, což znamená, že výběr zdravotní záznam s EGLIF modelem nestriktních dopovětve ve všech rozhodovacích uzlech musí být jed- ručení a určil, zda byl pacient léčen v souladu s nimi.
Modifikace algoritmu spočívá v multiplikaci tokenu, který
noznačný.
prochází rozhodovacím uzlem. Multiplikace znamená, že
2. Zdravotní záznam je kompletní, což znamená, že pokud token prochází rozhodovacím uzlem, je vytvořeno
všechny výsledky vyšetření a aplikovaných terapií tolik nových tokenů, aby každou přípustnou větví mohl
dále pokračovat jeden token.
jsou do zdravotního záznamu zaneseny.
Druhá podmínka korektního fungování algoritmu byla
Pro určitý stav pacienta doporučení ale často při- podmínka úplnosti zdravotního záznamu pacienta. Je
pouštějí více možných způsobů jak s léčením pokračo- zřejmé, že v situaci, kdy do zdravotního záznamu jsou
vat. V GLIF modelu se tato skutečnost modeluje po- uložena pouze neúplná data o jeho léčbě, možnost tesmocí tzv. „in-conditions“ , „strict in-conditions“ , „out- tovat shodu pacientovy léčby s modelem doporučení je
conditions“ a „strict out-conditions“ . Pokud je určitá silně omezena. Nicméně v některých případech neshoda
strict in-condition respektive strict out-condition na dané mezi zdravotním záznamem a modelem doporučení může
větvi splněna, lékaři je striktně doporučeno touto větví být přesto objevena. To nastane tehdy, když data uložená
pokračovat respektive nepokračovat. In-conditions a out ve zdravotním záznamu jsou v nesouladu s modelem doconditions jsou pouze „měkké“ podmínky a měly by být poručení ať jsou chybějící data ve zdravotním záznamu
chápány pouze jako doporučení, která je třeba zvážit.
jakákoliv.
c
2012
EuroMISE s.r.o.
EJBI – Volume 8 (2012), Issue 1
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.
[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, 196-200.
Poděkování
[17] P. DeClerq, K. Kaiser, A. Hasman, Computer-interpretable
Guidelines Formalisms, Stud HealthTechnol Inform, 2008, 139,
22-43.
Výzkum byl podpořen výzkumným projektem MSM
6046070904 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. 787-808, Maastricht, 2008.
[2] National Guidelines Clearinghouse, http://www.guidelines
.gov/submit/template.aspx
[3] National Library of Guidelines Specialist
http://www.library.nhs.uk/GuidelinesFinder
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), 83-89.
[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), 467483.
[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. 105-113.
[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. 377382, IOS Press, Goteborg, 2008.
[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.
151-156, IOS Press, Goteborg, 2008.
[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. 151-156, IOS Press,
Goteborg, 2008.
[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, 2004.
[12] A. Latoschek-Berendsen, H. Tange, H. Herik, A. Hasman,
From clinical practice guidelines to computer-interpretable guidelines, Methods Inf Med, 6, 2010.
EJBI – Volume 8 (2012), Issue 1
[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, 44-62.
[15] P. Shekelle, S. Woolf, M. Eccles, J. Grimshaw, Clinical guidelines:developing guidelines, BMJ 1999,318,593-596.
[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), 513-520.
[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, 59-70.
[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, 433-443.
[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), 325-344.
[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, 38 171-195.
[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, 162-166.
[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, 28-32.
[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, 553-562.
[26] S. Quaglini, M. Stefanelli, A. Cavallini, G. Micieli, C. Fassino,
C. Mossa, Guidelines-based careflow systems, Artificial Intelligence in Medicine 20 (2000), 5-22.
[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, 89-123.
[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. 4594 of Lecture Notes on Artificial Intelligence,
Springer, Berlin, 2007, 49-53.
c
2012
EuroMISE s.r.o.
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. 357-372.
[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, 2003.
[30] M. Peleg, A. Boxwala, et al.: GLIF3: The Evolution of Guideline Representation Format, In: http://smi
web.stanford.edu/projects/intermed-web/guidelines, 2000.
[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, 2004.
[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) 305-318.
[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. 240-245, Maastricht, 2006.
c
2012
EuroMISE s.r.o.
[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 ScienceICCS2004,Part IV Springer-Verlag Berlin Krakow, 2004, 11331139.
EJBI – Volume 8 (2012), Issue 1