1 Úvod

Lékařská doporučení jsou potřebná pro podporu rozhodování v klinické praxi. Hlavním záměrem je zvýšení kvality péče o pacienty a snížení nákladů. Přístup k informacím obsaženým v konvenční podobě doporučení (ve formě volného textu) může být bohužel obtížný. Předpokladem pro vývoj systémů podpory rozhodování je tedy vytvoření počítačově zpracovatelné reprezentace znalostí obsažených v lékařských doporučeních. Proto se vývojem takové reprezentace doporučení zabývá řada výzkumných skupin.

Pravděpodobně nejznámějším jazykem pro reprezentaci lékařských doporučení v systémech podpory rozhodování je Ardenská syntaxe [1]. Jedná se o formalismus založený na pravidlech pro kódování individuálních klinických pravidel jako medicínské logické moduly. Řada přístupů sdílí hierarchickou dekompozici doporučení ve formě sítí dílčích úkolů, které se rozkládají v čase [2]. Všechny dále uvedené metody modelování mohou kombinovat jednotlivé kroky doporučení v orientovaných cyklických grafech.

Asbru je vyvíjen ve spolupráci Univerzity Bena Guriona a Vídeňské technologické univerzity [3]. Jedná se časově orientovaný jazyk založený na specifikaci záměrů a základní kostry plánu, který je používán pro reprezentaci klinických protokolů.

EON byl vyvinut na Stanfordské univerzitě a poskytuje sadu modelů a programových komponent pro vytváření aplikací postavených na doporučeních [4]. EON používá úkolově orientovaný přístup k definici služeb podpory rozhodování, které mohou být implementovány různými technikami [5]. V EON architektuře se používá prostředí Protége2000 ke konstrukci informačního modelu pacientových dat, model medicínské specializace a model doporučení, který formalizuje znalosti potřebné k realizaci doporučení s ohledem na klinická rozhodnutí a aktivity.

GUIDE je část modelovacího a výkonného rámce, který je vyvíjen na Univerzitě v Pavii [6]. Podporuje integraci modelů doporučení do pracovních procesů v organizaci použitím analyticko rozhodovacích modelů jako jsou rozhodovací stromy a diagramy vlivu, a simulaci implementace doporučení v podmínkách Petriho sítí.

PRODIGY byl vyvinut v Univerzitě v Newcastlu nad Tynem [7]. Cílem projektu PRODIGY je vytvoření nejjednoduššího rychleji pochopitelného modelu reprezentace třídy doporučení. Týmy klinických lékařů zde používají vývojové prostředí Protégé [8] pro kódování tří komplexních doporučení řízení chronických nemocí.

PROforma byla vyvinuta v Moderní výpočetní laboratoři výzkumu rakoviny v Britském království [10]. Kombinuje logické programování a objektově orientované modelování, formálně zakotveném v jazyce R²L. PROforma podporuje čtyři typy činností: akce, složené plány, rozhodování a dotazy. Všechny činnosti sdílejí atributy popisující cíle, kontrolní toky, předpoklady a následné podmínky.

GLIF (Guideline Interchange Format) verze 3 byl vyvinut ve spolupráci Univerzity Columbia, Harvardské, McGillovy a Stanfordské univerzity (InterMed). GLIF byl publikován ve specifikaci GLIF3.5 [10, 11, 12]. Jeho výrazový jazyk byl původně založen na Ardenské syntaxi a pro popis kritérií a výrazů byl používán jazyk GEL (Guideline Expression Language). V současnosti je používán jazyk GELLO, tj. rozšířený objektově orientovaný jazyk, který také podporuje množinu funkcí z jazyka GEL [13].

GLIF model byl také použit jako model reprezentace počítačových klinických doporučení v projektu SAPHIRE [14]. Systém SAPHIRE průběžně monitoruje pacienty prostřednictvím jednoúčelových agentů a pomocí inteligentního systému podpory rozhodování pomáhá profesionálům v zajištění zdravotní péče.

Cílem tohoto příspěvku je návrh znalostního modelu doporučení GLIKREM (Guidelines Knowledge Representation Model). GLIKREM je založený na GLIF modelu, oproti původnímu modelu obsahuje navíc rozšíření v definici a implementaci. Příspěvek popisuje vlastní znalostní model doporučení, jeho konstrukci, implementaci v XML (eXtensible Markup Language), realizaci datového rozhraní a použití výsledného modelu. Znalostní model GLIKREM je dále použit v systému reprezentace lékařských znalostí (MEKRES), který v současnosti vyvíjen [15].

2 Model reprezentace znalostí GLIKREM

Celý proces konstrukce modelu znalostí (GLIKREM) z volného textu lékařských doporučení, jeho následnou reprezentaci v XML a použití výsledného modelu znázorňuje obrázek 1 [16].

Obr. 1. Proces konstrukce, kódování a použití GLIKREM.

Ve fázi konstrukce modelu z textových doporučení je důležité najít procesní strukturu doporučení (rozhodovací algoritmus) a všechny podstatné parametry modelu a jejich vzájemné vztahy [17].

Ve fázi kódování je grafický model doporučení zakódován v XML. Mimoto je vytvořen i seznam základních a odvozených parametrů modelu (paramodel), který slouží jako rozhraní mezi modelem a reálnými daty [18].

2.1 Grafický model

2.1.1 Hlavní části (kroky) grafu

Znalostním modelem textových doporučení, vytvořeným ve fázi konstrukce, je orientovaný graf (viz obr. 2) skládající se z pěti hlavních částí (kroků):

• Akce – představuje specifickou činnost nebo událost. Akcí může být i podgraf, který dále zjemňuje danou činnost.
• Rozhodování – představuje větvení (výběr) na základě automatického splnění logického kritéria, kdy další postup grafem je dán výsledkem aritmetického nebo logického výrazu nad konkrétními daty. V případě, že nelze rozhodnout automaticky, má uživatel v tomto místě možnost výběru, kterou částí grafu bude dále pokračovat.
• Větvení a synchronizace – větvení se používá při modelování nezávislých kroků, které mohou probíhat paralelně a synchronizace slouží pro tyto kroky jako slučovací bod.
• Stav – značí stav, ve kterém se zkoumaný objekt nachází při vstupu do modelu nebo po provedení některého předchozího kroku.

Obr. 2. Prvky grafického modelu.

2.1.2 Rozhodovací kritéria

V každém rozhodovacím kroku jsou pro každou následnou volbu (větev) α¹ ... αⁿ definovány čtyři rozhodovací kritéria (viz obr. 3). Na základě jejich vyhodnocení je vybrán, automaticky nebo ručně, následný postup modelem.

Obr. 3. Rozhodovací kritéria v rozhodovacím kroku.

• Strict-in – jestliže je splněna podmínka (např. logický výraz) nezávisle na uživateli, určitě se bude pokračovat příslušnou větví.
• Strict-out – jestliže je splněna podmínka, příslušnou větví se určitě nebude pokračovat – tato větev je zakázána.
• Rule-in – při splnění této podmínky je pouze doporučeno pokračovat následnou větví – je vyžadován zásah uživatele, uživatel by si měl vybrat pouze z větví s pravdivou podmínkou rule-in.
• Rule-out – při splnění této podmínky není doporučeno následnou větví – opět vyžadován zásah uživatele.

Při výběru následné větve se postupuje tak, že se nejprve vyhodnotí podmínka typu strict-out a při jejím splnění se další typy již nevyhodnocují, z pohledu možného průchodu grafem je příslušná větev zakázána. V opačném případě se vyhodnotí podmínka typu strict-in. Je-li splněna pokračuje se touto větví. Jestliže není splněna ani jedna podmínka typu strict-in, je vyžadován zásah uživatele s tím, že na základě vyhodnocení podmínek rule-in a rule-out je doporučen nebo nedoporučen výběr příslušné větve.

2.1.3 Vyhodnocování kritérií

Při vyhodnocování logických kritérií (strict-in, strict-out, rule-in, rule-out) se velice často setkáme se situací, kdy nejsou známy jednoznačné hodnoty všech proměnných. Neznámá hodnota proměnné nemusí být přitom chybou a je třeba takový stav brát v úvahu. Logické formule, složené z proměnných (parametrů modelu) a logických či relačních operandů, mohou nabývat následující stavy:

• pravda – formule je splněná – označíme hodnotou 1,
• nepravda – formule není splněna – označíme hodnotou 0,
• neznámo – stav formule není jednoznačně určený - označíme hodnotou ½.

Z matematické logiky plyne, že jakoukoliv logickou formuli lze převést do disjunktivního (resp. konjunktivního) normálního tvaru, složeného pouze z logických operací negace, konjunkce (logický součin) a disjunkce (logický součet). Výsledný tvar formule je ekvivalentní s původní formulí.

Definici operací negace, konjunkce a disjunkce v tříhodnotové logice uvádějí následující vztahy:

• ¬p=1 – p
• (p₁ Λ p₂ Λ  ... Λ p_n) = min(p₁, p₂, ..., p_n)
• (p₁ ν p₂ ν  ... ν p_n) = max(p₁, p₂, ..., p_n)

Při vyhodnocování rozhodovacích kritérií a výběru následné větvě (volby) ze všech možných větví (voleb) vedoucích z rozhodovacího kroku definujeme následující pravidla:

• Automatický postup větví vycházející z rozhodovacího kroku je možný pokud její strict-in podmínka je vyhodnocena jako pravda (1) a pokud na této větvi neleží současně strict-out podmínka vyhodnocená jako pravda.
• Pokud nenastanou první bod lze postupovat dále jenom tak, že uživatel některou větev ručně vybere. K výběru jsou uživateli nabídnuty pouze větve, na nichž nejsou strict-out podmínky vyhodnocené jako pravda (nejsou zakázané).
• Doporučení či nedoporučení větve je uživateli nabídnuto po vyhodnocení podmínek rule-in a rule-out.
• Jestliže některé z kritérií strict-in nebo strict-out je vyhodnoceno jako neznámo (½), je třeba doplnit hodnoty parametrů, které se v těchto podmínkách vyskytují. Po doplnění parametrů se provede opakované vyhodnocení. Kritéria strict-in a strict-out musí být vždy vyhodnoceny jednoznačně (pravda nebo nepravda).
• V každém rozhodovacím uzlu musí být zajištěna konzistence, tj. při všech možných kombinacích hodnot parametrů je splněna (hodnota pravda) maximálně jedno strict-in kritérium a nejsou na stejné větvi (volbě) splněny (pravdivé) obě kritéria strict-in a strict-out.
• Rozhodovací kritéria mohou být závislá na několika různých parametrech. Vyhodnocení rozhodovacího kroku musí být korektní (minimálně jedno z kritérií strict-in nebo rule-in některé volby musí být pravdivé a strict-out v této volbě nepravdivé) pro všechny možné kombinace hodnot každého parametru.

2.1.4 Priorita v rozhodování

Při důsledném uplatňování předchozích pravidel může nastat situace, ve které bude po uživateli vyžadováno upřesnění hodnot vstupních parametrů i v případě, kdy to pro další průchod modelem není nezbytně nutné. V případě, že u některé z větví nabývá kritérium strict-in hodnoty pravda, bude se pokračovat určitě touto větví a vyhodnocování kritérií ostatních větví je zbytečné.

Počet potřebných upřesnění je závislé na pořadí vyhodnocování jednotlivých větví. Z uvedených důvodů je výhodné stanovit pořadí jejich vyhodnocování, tj. určit prioritu. Priorita je přiřazena jednotlivým větvím rozhodování při návrhu modelu po expertní analýze modelovaného problému (viz obr. 4).

Obr. 4. Priorita větví v rozhodovacím kroku.

V uvedeném příkladu se nejprve budou vyhodnocovat rozhodovací kritéria větve γ, poté větve α a nakonec větve β. Pokud bude splněno kritérium strict-in větve γ, větve α a β se již vyhodnocovat nebudou .

2.1.5 Synchronizační podmínky

Při modelování paralelně probíhajících větví pomocí prvků větvení a synchronizace je nutné upřesnit, které z větví musí uživatel určitě projít a které jsou pouze volitelné.

Uvedené případy lze realizovat pomocí synchronizační podmínky v synchronizačním kroku (viz obr. 5). Podmínku je možné opět vyjádřit v disjunktivním (konjunktivním) normálním tvaru, kde vstupními proměnnými jsou plovoucí (onfly) parametry reprezentující průchod jednotlivými větvemi. Hodnota onfly parametru je nastavena pomocí skryté operace (viz reprezentace modelu v XML) v posledním kroku příslušné větve. Ohodnocení parametrů je pak následující:

• hodnota 1 – touto větví uživatel prošel,
• hodnota 0 – touto větví uživatel neprošel.
  
   

Obr. 5. Synchronizační podmínka.

V ukázkové situaci se bude pokračovat v průchodu grafem, bude-li splněna synchronizační podmínka (α₁ ν α₂) Λ α₃, tj. jestliže uživatel určitě projde větví α₃ a zároveň alespoň jednou z větví α₁ nebo α₂.

2.1.6 Reprezentace grafického modelu v XML

Pro reprezentaci grafického modelu jsme navrhli vlastní XML schéma a vyvinuli grafický editor pro konstrukci grafického modelu a jeho překlad do XML. Celý model se skládá z jednotlivých kroků reprezentujících příslušné prvky grafického modelu. Kromě atributů vyplývajících přímo z modelu obsahuje navržená syntaxe XML i atributy vhodné pro další zpracování, například pro grafické zobrazení nebo pro podporu rozhodování (viz obr. 6).

 Obr. 6. XML schéma reprezentace grafického modelu.

Význam jednotlivých elementů je následující:

• glikrem – kořenový element celého modelu (GLIKREM),
• head – definice hlavičky modelu - viz kapitola rozšíření modelu pro MEKRES,
• graph – kořenový element vlastního grafického modelu, skládá se z kroků (step),
• step – parametry jednoho kroku, obsahuje elementy:
      name – jednoznačná identifikace (název) kroku,
      type – typ kroku, je možný pouze výběr z typů:
                action, case, branch, synchronization, state, subgraph,
      caption – text v záhlaví grafického symbolu kroku,
      text – vlastní text popisující krok,
      x – x-ová (horizontální) souřadnice grafického symbolu,
      y – y-ová (vertikální) souřadnice grafického symbolu,
      width – šířka (v pixelech) grafického symbolu,
      height – výška (px) grafického symbolu,
      focus – zvýraznění kroku pro zobrazení cesty v grafu, možné hodnoty jsou:
              not = nezvýrazněn, auto = zvýrazněn (automaticky),
              user = zvýrazněn (uživatelská simulace),
      status – postavení kroku v rámci modelu, možné hodnoty jsou:
              start = počáteční krok, end = koncový krok, in = vnitřní krok (všechny ostatní),
• operation – seznam skrytých operací probíhajících „na pozadí" kroku (viz obr. 7), každá operace je ohraničena elementy ops a obsahuje elementy:
        otype – typ operace, je možný výběr z:
                 insert = vložení (zadání) hodnot parametrů,
                 get = načtení hodnot parametrů (zjištění hodnoty),
                 put = nastavení (uložení) hodnoty parametru,
                 open = otevření souboru (např. podgrafu),
        oparam – název parametru nebo název souboru,
        ovalue – pouze pro operaci put obsahuje hodnotu, na kterou má být parametr nastaven,

Obr. 7. XML schéma operací na pozadí kroku.

• next – seznam následných větví (voleb) kroku (viz obr. 8), každá volba je ohraničena elementy option a obsahuje elementy:
       nname – název, identifikace následné větve,
       nstep – identifikátor (název) kroku, kterým se má pokračovat,
       ncaption – text zobrazený u příslušné volby,
       npriority – priorita vyhodnocení větve udaná číslem, defaultně hodnota 1,
       nstrictin – strict-in rozhodovací kritérium,
       nstrictout – strict-out rozhodovací kritérium,
       nrulein – rule-in rozhodovací kritérium,
       nruleout – rule-out rozhodovací kritérium,
       nnote – poznámka popisující příslušnou větev,
       nline – popis čáry vedoucí z tohoto kroku do následného, ve tvaru sekvence bodů (elementů point):
                px – x-ová souřadnice bodu,
                py – y-ová souřadnice bodu.

Všechny typy rozhodovacích podmínek mají obvykle tvar logické formule, kde proměnnými jsou základní a odvozené parametry paramodelu (modelu parametrů). Zápis rozhodovacích podmínek (strict-in, strict-out, rule-in, rule-out) dodržuje syntaxi jazyka XPath.

Příklad definice podmínky testující pravdivost obou parametrů PRIZNAKY a NALEZY:
/params/param[pid="PRIZNAKY"]/pvalue and params/param[pid="NALEZY"]/pvalue

Zápis synchronizačních podmínek je obdobný (opět v jazyku XPath), předpokládá ale definici plovoucích (onfly) parametrů definujících průchod příslušnou větví.

Příklad definice synchronizační podmínky, kdy je vyžadován průchod větví S3 nebo větví S4:
/params/param[pid="DG_S3"]/pvalue or /params/param[pid="DG_S4"]/pvalue

Obr. 8. XML schéma následných větví.

2.2 Model parametrů (paramodel)

Parametry podstatné pro modelování doporučení pomocí GLIKREM nemusí a často ani nebývají uloženy (v databázi či klinickém informačním systému) způsobem vhodným pro přímé použití tímto modelem. Výhodnějším řešením je navržené rozhraní mezi znalostním modelem a konkrétními uloženými daty ve formě paramodelu (modelu parametrů). Skutečné hodnoty se pak získají transformací dat (viz kapitola transformace dat). Vyhodnocování rozhodovacích podmínek v modelu se potom neprovádí s reálnými daty, ale s odkazem na parametry uložené v paramodelu.

2.2.1 Reprezentace paramodelu v XML

Pro reprezentaci paramodelu je, stejně jako u grafického modelu, využito jazyku XML. Celý model se skládá z elementů reprezentující příslušný parametr (viz obrázek 9). Parametry GLIKREM mohou být trojího typu a to:

• basic – základní parametr, tj. přímo měřitelná nebo získatelná hodnota,
• derived – parametr odvozený ze základních provedením logické, aritmetické či logicko-aritmetické operace,
• onfly – pomocný parametr (obsahující logickou hodnotu) pro definici synchronizačních podmínek.
  
  

Obr. 9. XML schéma paramodelu.

Význam jednotlivých XML elementů paramodelu je následující:

• paramodel – kořenový element celého paramodelu,
• head – hlavička paramodelu,
• params – kořenový element vlastních parametrů, obsahuje elementy param,
        param – popis jednoho parametru,
             pid – jedinečná identifikace (název) parametru
             ptype – typ parametru, možné hodnoty jsou basic, derived a onfly,
             pname – text úplného názvu parametru,
             pdatype – datový typ parametru odpovídající některému z XML datových typů,
             pvalue – vlastní hodnota parametru,
             punits – jednotky parametru,
             pdef – definice operace nad základními parametry pro odvozené parametry,
             pquery – definice dotazu do databáze na hodnotu parametru (např. SQL),
             pnote – text poznámky k parametru.

Definice odvozených parametrů (element pdef) využívá opět zápis v jazyce XPath.

2.2.2 Transformace vstupních dat

Reálná data o pacientech mohou být uložena v klinických informačních systémech a databázích různých typů. Není však velký problém data z těchto systémů exportovat do formátů XML nebo CSV (Comma-Separated Values). Před použitím těchto dat v GLIKREM je třeba je vhodným způsobem transformovat do paramodelu (v XML). Zjednodušený proces transformace je znázorněn na obrázku 10.

 

Obr. 10. Proces transformace dat do paramodelu.

Pro každý parametr v paramodelu je třeba, s ohledem na uložení reálných vstupních hodnot v datovém souboru (XML nebo CSV), definovat specifickou hodnotovou mapu (value-map). Definice hodnotové mapy je ve formě XSLT (eXtensible Stylesheet Language Transformations) souboru. Například stanovení hodnoty systolického tlaku jako průměr z naměřených hodnot (viz. obr. 11) uložených v XML souboru.

2.3 Rozšíření modelu pro použití v systému MEKRES

Pro použití GLIKREM v systému MEKRES (MEdical Knowledge REpresentation System) je model rozšířen o klíčové atributy. Klíčové atributy se uplatní v algoritmu výběru relevantních formalizovaných znalostí účastníkům systému. Klíčové atributy jsou zakódovány opět v jazyce XML a uloženy v hlavičce (element head) společně s grafickým modelem (viz obr. 12).

Obr. 11. Transformace systolického tlaku do paramodelu.

Obr. 12. XML schéma klíčových atributů.

Význam jednotlivých XML elementů hlavičky (elementu head) je následující:

• gname – název znalostního modelu,
• author – autor(ři) modelu,
• date – datum poslední aktualizace,
• BID – identifikátor oblasti – například pro medicínu podle mezinárodního číselníku nemocí (MSN),
• branch – oblast (obor), které se model týká,
• user – označení účastníka systému, kterému je model primárně určen (možné hodnoty jsou patient, GP, specialist, operator, everybody),
• status – označení platnosti modelu (možné hodnoty jsou valid, draft, expired),
• keys – seznam klíčů (klíčových atributů) vyskytujících se v modelu obsahuje elementy key,
       keyname – označení klíče,
       keyweight – váha klíče udává, do jaké míry je klíč popsán modelem.

Obrázek 13. Systém MEKRES.

2.3.1 Algoritmus výběru relevantního modelu

Celý systém reprezentace znalostí MEKRES a algoritmus výběru relevantního znalostního modelu je znázorněn na obrázku 13. Algoritmus výběru relevantního modelu lze popsat následovně:

• Pro uživatele systému a jeho atributy (data o uživateli) je vybrána množina oborů (branch) a klíčů, které odpovídají stavu uživatele (datům).
            o např. atributům pacienta „STK", „DTK" a „glycaemia" odpovídají obory „diabetes" a „hypertenze".
• Pro každý obor (branch) a klíč je vybrána množina znalostních modelů (GLIKREM), které obsahují tento obor v hlavičce (element head) a váha klíče (element keyweight) uloženého v modelu je nenulová.
            o např. modely G₁ (hypertenze) a G₂ (diabetes).
• Pro každý vybraný model je stanovena hodnota obecného agregovaného operátoru (např. ) udávající relevantnost daného modelu.
            o např. model G1 má operátor R_g1 = 2,1 a model G₂ má R_g2 = 0,8.
• Uživateli je zpětně zobrazen model s největší hodnotou relevance nebo seznam modelů uspořádaných podle relevance.
             o např. uživateli je nabídnut model G₁ s největší hodnotou relevance.

3 Závěr

Navržený model reprezentace znalostí GLIKREM, vycházející ze specifikace GLIF3.5, je univerzálním nástrojem pro formalizaci znalostí uložených ve formě volného textu (např. lékařských doporučení). Reprezentace grafického modelu v XML a vytvoření datového rozhraní ve formě paramodelu (v XML) umožňuje použití modelu v rozličných typech aplikací a napojení na reálná data z různých zdrojů. Pro transformaci vstupních dat i vlastního modelu je použito definice ve formě XSLT souboru.

Hlavní rozšíření a přínosy navrženého modelu jsou následující:

• Formální reprezentace grafického modelu v XML. Výsledkem reprezentace je návrh XSD (XML Schema Definition).
• Přesnější definice rozhodovacích kritérií a jejich vyhodnocování v tří hodnotové logice.
• Definice atributu priorita pro snížení nutného počtu vyhodnocení jednotlivých voleb v rozhodovacích krocích.
• Návrh paramodelu (v XML), který je použit jako rozhraní mezi GLIKREM a reálnými daty pacientů v klinických informačních systémech.
• Rozšíření GLIKREM o klíčové atributy. Toto rozšíření je dále využito v systému reprezentace lékařských znalostí (MEKRES).

Poděkování 

Vytvořeno s podporou grantu č. AV0Z10300504 a č. 1M06014 MŠMT ČR.

Literatura