1. ÚvodSystémy pro podporu v rozhodování (DSS z angl. Decision Support System) si v medicínském prostředí našly své místo a denně poskytují lékařům oporu a usnadňují jim jejich rozhodnutí. Několik studií potvrdilo, že přínos těchto systémů spočívá zejména v předcházení omylů při poskytování zdravotní péče a zvyšování její kvality, ale rovněž vede i ke snížení nákladů a k úspoře času [1-5]. Úspěšnost těchto systémů bývá v praxi podmíněna přístupným a neobtěžujícím ovládáním pro lékaře či ostatní členy lékařského personálu. Toto pozorování je doloženo v práci [2], která systematicky zkoumala stávající DSS, přičemž ty, které pracovaly na pozadí a uživatele upozornily pouze v případě připomínky či varování (příklady takových systémů lze nalézt v [6], [7]), byly vyhodnoceny jako nejvíce přínosné. Znalosti v DSS typicky vycházejí z lékařských doporučení (např. v [8], [9]), které popisují doporučené postupy pro diagnózu a/nebo postup léčby konkrétních onemocnění. Z analýzy existujících DSS [1-9] však rovněž vyplývá, že pro jejich úspěšné použití je nutná plná integrace v daném zařízení, kde jsou používány, což znamená přizpůsobení lokálním podmínkám a omezením. Proto je nutné, aby se kromě obecných lékařských doporučení při tvorbě znalostní báze DSS zohledňovaly také organizační postupy v daném zařízení. Tyto znalosti zachycující medicínské postupy pak mohou být systémem použity pro kontrolu jejich návrhu, simulaci, nebo na kontrolování jejich dodržování v praxi. Jednou z oblastí medicíny, kde nasazení DSS může být mimořádně přínosné, je oblast domácí péče (HC z angl. Home care) [10], [11]. Zvyšující se počet chronicky nemocných starších pacientů má za následek zvýšené nároky na nepřetržitou dlouhodobou léčbu pod dohledem zdravotních specialistů. Navíc je možné pozorovat, že umístění a léčba těchto pacientů v domácím prostředí může mít pozitivnější výsledky než jejich dlouhodobá hospitalizace [11]. Potřeba nasazení DSS v oblasti domácí péče vychází zejména z její distribuované povahy. Pracovníci domácí péče navštěvují doma své pacienty a poskytují jim patřičnou asistenci či vyšetření, tak však přicházejí o možnost rychlé konzultace se svými kolegy při neznámých situacích nebo komplikacích. Nasazení systému pro podporu nebo kontrolu jejich činností by tak mohlo jednoznačně zvýšit kvalitu poskytované zdravotní péče. Vzhledem k distribuované povaze oblasti domácí péče, ji musí zohledňovat také příslušný DSS. Z tohoto důvodu jsou často využívány modely vycházející z multiagentních přístupů [11-15]. Pod pojmem multiagentní systém rozumíme systém, kde skupina inteligentních autonomních agentů společně interaguje, přičemž chtějí dosáhnout předem definované cíle. Chování se těchto agentů bývá specifikováno pomocí více základních modelů – (1) čistě reaktivní agenti, kteří na základě předdefinovaných pravidel reagují na podněty okolí, (2) uvažující agenti, kteří si budují vlastní model prostředí a plánují své budoucí akce a (3) hybridní modely kombinující předchozí dva modely. Tyto základní modely chování agentů mohou být implementovány jak s využitím standardních programovacích jazyků, např. Java, tak s využitím specializovaných agentních programovacích jazyků, jako např. Jazzyk [16], CONRAD [17], nebo některé z verzí jazyka APL [18]. Nedostatkem těchto programovacích jazyků je zejména nemožnost efektivně namodelovat situace kooperace a koordinace tak, aby agenti sledovali vlastní cíle, ale zároveň i cíle společné, pro které je kooperace nutná. Na druhou stranu, organizační procesy a lékařské doporučení jsou často založeny na nutnosti kooperace zúčastněných aktérů, přičemž poskytují i potřebné informace o následnosti a podmínkách provedení jednotlivých akcí (např. před operačním zákrokem je nutno provést příslušná vyšetření, pro které je nutný jistý druh vybavení apod.). V předchozích pracích jsme proto vytvořili nový způsob modelování chování agentů, který takovou kooperaci podporuje [19], [20]. Náš přístup je založen na rozšířených procesech, pomocí kterých formalizujeme znalosti o postupech. Na jejich základě vytváříme agenty systému, jejichž specifická organizace dovoluje pracovat s procesy ve smyslu kontroly jejich návrhu, jejich simulace, případně kontroly jejich exekuce v praxi. Z důvodu přehlednosti budeme v této práci tuto architekturu označovat jako ProMA.
Architektura ProMA byla původně navržena s ohledem na všeobecné použití a tedy s obecnou specifikací procesního formalismu. Cílem této práce je proto ukázat možné aplikace architektury ProMA pomocí rozšíření architektury stávajícího systému pro podporu domácí péče, K4Care [11], kde se pro ukládání postupů využívá formalismus SDA* [21]. Důraz při tom klademe na integraci nové architektury do systému K4Care a její dopad na změny v modelech a nové vlastnosti takto vylepšeného systému. Příspěvek je organizován takto. V následující sekci přesněji vysvětlíme pojem procesu v medicínském kontextu, po čem následuje popis nové architektury ProMA, která s procesy dokáže pracovat. V další sekci představíme systém K4Care, po ní pak následuje sekce věnovaná zapojení architektury ProMA do systému K4Care. Zdůrazněme, že toto zapojení slouží jako potvrzení aplikovatelnosti obecné architektury ProMA v konkrétním systému, přičemž popíšeme zejména benefity plynoucí z této integrace. V předposlední sekci nastíníme nové možnosti, které tato integrace poskytuje a v poslední sekci poskytneme shrnující závěr. 2. Multiagentní architektura založena na procesech (ProMA)Tato sekce je věnována popisu procesů v oblasti zdravotnictví, jejich rozdělení a následně architektuře ProMA, která s nimi umožňuje pracovat. Pod pojmem proces rozumíme sekvenci aktivit, stavů, rozhodnutí, ale také stavů rozdělujících sekvenci na několik paralelních, resp. synchronizační stavů. Procesy v oblasti medicíny rozdělujeme na dva základní typy – organizační procesy a procesy související s léčbou (resp. lékařské doporučení). Organizační procesy v oblasti zdravotní péče jsou podobné procesům známým z jiných odvětví. Několik prací (např. [22], [23]) se věnuje zkoumání možností aplikace procesního modelování či používání tzv. workflow management systémů v oblasti zdravotnictví. Panuje shoda, že úspěšné nasazení těchto technik a systémů může přinést zvýšenou kvalitu poskytované péče, snížit čas potřebné hospitalizace pacienta a díky tomu i snížit celkové náklady. Lékařské doporučení jsou delší dobu součástí procesu standardizace lékařské péče a lze je chápat jako jeden z pilířů medicíny založené na znalostech. Obsahují doporučené a odbornými komisemi schválené postupy, akce a principy pro diagnostiku či léčbu onemocnění. V současné době mají používané lékařské doporučení často textovou podobu, která je pro lékařské specialisty přirozená. Na druhé straně je však tato textová podoba komplikací při potřebě rychlé konzultace během vyšetření pacienta, případně pro rychlé zorientování se ve změnách při vydání nové varianty doporučení. Navíc, textová podoba je naprosto nevhodná pro počítačové zpracování, nebo jako vědomostní základ pro systémy pro podporu v rozhodování. Proto je velká část výzkumu v oblasti medicínské informatiky věnovaná právě formalizaci lékařských doporučení do elektronické podoby, přičemž bylo vyvinuto několik procesních jazyků pro takovou formalizaci (např. jazyky PROforma [24], Asbru [25], nebo GLIF [26]) a s jejich pomocí lze zachytit znalosti z textových doporučení do strukturované elektronické podoby. Oba tyto typy procesů můžeme vnímat společně a oba musí být zastoupeny při tvorbě báze znalostí postupů v DSS. V další části této sekce představíme multiagentní architekturu, která je s těmito znalostmi formalizovanými pomocí obecného procesního jazyka schopna pracovat. Celkový náhled na architekturu je na Obrázku 1. 
Obr. 1. Schéma multiagentní architektury založené na procesech. 2.1 Agent prostředí (Environment Agent) Mutli-agentní systémy a simulace jsou vždy vztaženy k určitému prostředí, ve kterém agenti operují. V ProMA architektuře je toto prostředí reprezentováno specializovaným agentem. V závislosti na tom, na jaké úrovni detailu chceme systém používat, může tento agent reprezentovat virtuální svět (to znamená od celého nemocničního oddělení po položky v databázi záznamů pacientů) spolu se stávajícími objekty (např. lůžka, RTG nebo EEG přístroje, laboratorní výsledky apod.). Je však rozdíl při práci s daty týkajícími se zdravotního záznamu pacientů a ostatními položkami. Proto, jak je uvedeno ve schématu, a jak bude ukázáno později, je vhodné oddělit simulační a skutečné data, avšak, agent prostředí je schopen tyto údaje získat od specializovaného agenta (Patient Health Record Agent). 2.2 Exekuční agent (Execution Agent)
Exekuční agenti (EA) v architektuře reprezentují konkrétní lidi – lékaře, sestry, pacienty či dalších zaměstnance, kteří se podílejí na výkonu formalizovaných procesů. Tito agenti využívají reaktivní model chování formou hierarchických pravidel, které lze na základě procesní specifikace automaticky generovat (v publikaci [20] jsou uvedeny detaily daného algoritmu). Každý EA má předem definovanou sadu pravidel, pomocí kterých je schopen plnit základní cíle v daném prostředí (např. odpovídá na zaslané zprávy, informuje agenta prostředí o nutných změnách stavu a pod.). Následně pro každou aktivitu, ve které může tento agent (a tedy konkrétní osoba, kterou reprezentuje) vystupovat, je vytvořeno jedno další pravidlo. Tyto mohou být v průběhu práce s procesy aktivovány (v případě, že je možné danou aktivitu uskutečnit) nebo deaktivovány (v případě, že provedení této aktivity není aktuálně možné). Aktivaci či deaktivaci provádí agent role (bude popsán později). Výhodou tohoto systému je fakt, že to, kterou konkrétní aktivitu bude exekuční agent provádět, závisí na jeho autonomním rozhodnutí a jeho prioritách k aktivovaným prioritám. 2.3 Agent role (Role Agent)
Agenti rolí (RA) reprezentují všeobecné role v daném prostředí (všechny lékaře, sestry atd.). Cílem RA je najít vhodného exekučního agenta (EA) pro vykonání dané aktivity na žádost příslušného Procesního Agenta (bude popsán později). Důvodem, pro který je vhodné nasazení specifických agentů reprezentujících role je fakt, že v typické pracovní struktuře zaměstnanců jsou jejich role navzájem hierarchicky uspořádány (např. sekretářka i sestra jsou obě zároveň i zaměstnankyněmi). Proto, když RA obdrží žádost o účast na dané aktivitě od procesního agenta, vyhledává mezi exekučními agenty (pomocí tzv. contract-net protokolu (CNP)) ty, kteří mají tuto roli, ale i ty role, které jsou v kontextu dané hierarchie všeobecnější. V případě, že jednu aktivitu může současně provést několik EA a je potřebný jen jeden, RA autonomně určí vítěze na základě interních pravidel, přičemž vítězi předá zprávu o aktivaci daného pravidla. Výběr takového vítěze je vždy doménově závislý, případně závisí na konkrétních rolích (např. se může jednat o agenta, který byl nejdéle nečinný apod.). Navíc, RA jsou odpovědni i za nalezení náhrady za vítězného EA v případě, že ten dočasně pozastaví činnost na dané aktivitě (např. lékař je zavolán k akutnímu případu a může být nahrazen v aktuální činnosti).
2.4 Procesní agent (Process Agent)
Procesní agent (PA) je vytvořen pro každý krok v procesním formalismu (tedy pro každý stav, aktivitu, rozhodnutí, rozdělení či synchronizaci). PA je zodpovědný za korektní exekuci daného kroku. Na začátku kontroluje zda jsou splněny vstupní podmínky pro zahájení procesu:
- zda předchozí PA úspěšně skončil(y) (a tedy zda PA obdržel příslušnou informační zprávu),
- zda všechny hodnoty na objektech potřebných k provedení tohoto kroku jsou správně (PA se pomocí jednoduchého protokolu ptá agenta prostředí),
- zda existují exekuční agenti, kteří jsou potřební pro provedení tohoto kroku (PA používá CNP protokol pro příslušné agenty rolí, kteří přísluší této aktivitě).
V případě, že jsou všechny nutné podmínky splněny, zahájí PA exekuci kroku (tedy např. simulaci aktivity, výpočet, nebo učiní patřičné rozhodnutí) a po úspěšném ukončení je PA povinen zaslat výsledek agentovi prostředí (pomocí jednoduchého protokolu žádosti) a informovat vlastního následovníka o úspěšném konci (pomocí jednoduchého informačního protokolu).
Tato architektura navíc umožňuje dočasně pozastavit provádění patřičné aktivity a promítnutí dílčích výsledků do prostředí, nahrazení jednoho exekučního agenta druhým, koordinaci více exekučních agentů i nepovinné vstupní podmínky. 2.5 Agent Procesního Záznamu (Process Director Agent) Poslední agent je výhradně pomocným agentem, který čte formalizované procesy, na základě kterých vytváří ostatní agenty a následně jim odpovídá na otázky týkající se těchto procesů (jako např. vstupní objekty, předchůdci, apod.). Jedná se o zjednodušení vlastní implementace systému postaveném na této architektuře, ale je vhodné upozornit, že stále všichni agenti jsou si vědomi a uvažují o procesech jako takových. 3. K4CareCílem projektu K4Care [11] bylo vytvoření, implementace a ověření zdravotního modelu postaveného na znalostech pro asistenci pacientům v domácí léčbě. Znalosti o postupech jsou reprezentovány pomocí lékařských doporučení, které se v kontextu tohoto projektu nazývají formální intervenční plány (FIP). Na druhou stranu, pro zachycení specifických podmínek pro každého pacienta představuje projekt K4Care tzv. individuální intervenční plány (IIP), které spojují jak medicínské znalosti, tak i lokální pravidla a sociální charakteristiky daného pacienta. Znalost o obou typech postupů, tedy jak individuálních tak i formálních intervenčních plánech, je v systému K4Care reprezentována pomocí formalismu SDA* [21]. Jedná se o procesní jazyk obsahující 3 základní terminologické komponenty: (1) stavy, (2) rozhodnutí a (3) akce. Stavy popisují přípustné stavy pacienta nebo významné situace v daném kontextu (např. zvýšený krevní tlak). Rozhodnutí reprezentují terminologii, kterou specialisté používají pro rozlišení několika následujících postupů (např. dřívější problémy se srdcem mohou rozlišit následující kroky, pokud jsou pravdivé). Termíny akcí popisují lékařské, klinické nebo operační akce, které mohou provádět aktéři zohlednění v systému (např. užití betablokátoru, vyhýbání se slaným jídlům, provedení krevní analýzy, apod.). Na rozdíl od typických procesních jazyků, SDA* nemá specifickou komponentu pro aktéry, ale ti jsou v systému fixně určení ke každé akci. Rozlišujeme dvě skupiny – žadatelé a vykonavatelé. V první skupině jsou ti aktéři, kteří mají oprávnění žádat provedení dané akce, ve druhé skupině jsou ti aktéři, kteří mají oprávnění k jejímu provedení v praxi. Formalizované znalosti postupů jsou nejprve využívány lidským expertem (lékaři nebo manažeři daného zdravotního zařízení). V případě, že pacient prostřednictvím systému požádá o poskytnutí služby, tým specialistů nejprve identifikuje na základě příznaků množinu možných onemocnění. Platforma K4Care následně poskytne dostupné formálně intervenční plány (FIP), které se daných znalostí mohou dotýkat. Lidský expert následně spojí a dále upraví tuto množinu plánů tak, aby odpovídaly aktuálním potřebám. Výsledný plán je uložen jako individuální intervenční plán daného pacienta. Tento plán má přiřazené konkrétní aktéry, kteří se budou na provádění tohoto plánu podílet, a proto se po jejich odsouhlasení výsledné úkoly zobrazí v jejich osobních portálech. Tyto jsou vygenerovány SDA* exekučním mechanismem na základě uloženého IIP. Pracovník po úspěšném vykonání dané úlohy, vyplní v systému příslušná místa v dokumentu týkajícím se dané aktivity a vygenerují se nové úkoly na základě specifikace v IIP.  Obr. 2. Schéma systému K4Care prezentovaná v [13].
4. Integrace architektury ProMA do systému K4CareV této sekci popíšeme vylepšení stávajícího modelu systému K4Care integrací architektury ProMA. Nejdříve se zaměříme na technické detaily vyplývající z této integrace, pak bude následovat návrh nových možností, které takto modifikovaný systém může poskytnout. V celé sekci následujeme příklad použití uveden na závěr předchozí sekce a integraci budeme vysvětlovat v tomhle kontextu. Důvodem je přímo viditelná výhoda při návrhu IIP lidským expertem díky integraci architektury ProMA do systému K4Care. Další možnosti rozšíření a z nich vyplývající nové vlastnosti systému diskutujeme v následující sekci. 4.1 Prostředí
V tomto příspěvku se zaměřujeme na multiagentní část platformy K4Care (viz Obr. 2). Nejdříve se proto zaměříme na unifikaci stávající funkcionality systému K4Care s architekturou ProMA. Propojení s údaji v zdravotních záznamech pacienta a doporučenými postupy, v architektuře ProMA reprezentovány pomocí komunikace příslušných agentů, je v systému K4Care realizováno pomocí datové abstraktní vrstvy (DAL). Ta poskytuje rozhraní (tzv. API z angl. Application Program Interface) pro získání dat pacientů z jejich záznamu nebo doporučení formalizované pomocí SDA*. Přesto, agent prostředí musí být stále přítomen pro dočasné ukládání dat, která nemají perzistentní charakter (např. během simulace). Vrstva DAL rovněž neumožňuje odpovědět na dílčí dotazy pro jednotlivé položky dokumentů či doporučení, proto oba specializovaní agenti (agent procesního záznamu a agent pacientova zdravotního záznamu) musí být ve výsledném multiagentním systému vytvoření. 4.2 Exekuční agenti
Exekuční agenti (EA) architektury ProMA konceptuálně odpovídají agentům aktérů v systému K4Care (Actor Agents) – reprezentují totiž konkrétné lidi, uživatele systému, kteří vykonávají akce. Pro úplnou shodu však agenti aktérů musí umět komunikovat s agenty rolí (RA) a umět autonomně reagovat na jejich požadavky. Taková reakce je v současném návrhu systému K4Care postavená výhradně na lidské odpovědi. Vzhledem k tomu, že jsou tito agenti aktérů perzistentně v systému přítomní, jejich funkcionalita může být poměrně jednoduše vylepšená tak, aby dokázaly reagovat na příchozí požadavky v podobě CNP protokolů inicializovaných agenty RA. Autonomní odpověď může být postavena na seznamu aktuálně přidělených úkolů danému aktérovi nebo jeho aktuální dostupnosti (pokud je například specialista dlouhodobě mimo zařízení, jeho agent by měl mít tuto informaci a automaticky zamítnout jeho účast na navrhovaných aktivitách). Navíc, koncepty formalismu SDA* typicky obsahují i časové informace (např. časový interval či periodicitu výskytu), díky čemuž mohou poskytovat agenti aktérů mnohem sofistikovanější odpovědi v závislosti na všech plánovaných aktivitách a přidružených IIP, přičemž ve finále mohou společně fungovat jako rozvrhovací algoritmus umožňující lidskému expertovi jednodušší rozhodnutí při vytváření nového IIP (více je tato alternativa analyzována v následující sekci). 4.3 Agenti rolí
Ostatní typy agentů prezentovaných v architektuře ProMA nemají přímou alternativu v systému K4Care, a proto musí být vytvořeni, přičemž v dalších sekcích popíšeme jejich integraci do systému. Jak agenti rolí (RA), tak ani procesní agenti (PA) nemusí být v systému perzistentně přítomni a mohou být vytvořeni při vytváření nového IIP pro daného pacienta na základě vyžádaných doporučení (FIP). Agenti rolí (RA) konceptuálně v systému K4Care odpovídají typům aktérů. Proto vytvoříme RA pro každou následující roli: pacient, rodinný lékař, hlavní sestra, vedoucí lékař, sociální pracovník, sestra, lékař specialista, operátor sociálního pracoviště, poskytovatel nepřetržité péče a ostatní. V systému K4Care jsou navíc tyto role sdruženy do skupin jako evaluační jednotka či další poskytovatelé péče. Proto jsou RA vytvořeni i pro každou z těchto skupin a příslušná hierarchická struktura mezi rolemi je vybudována. Navíc, ve více aktivitách také existuje podobná hierarchie (např. řadu aktivit, které provádí sestra umí provést i hlavní sestra, apod.).
4.4 Procesní agenti
Jeden procesní agent (PA) je vytvořen pro každý stav, rozhodnutí nebo aktivitu ve vyžádaných doporučeních FIP formalizovaných pomocí SDA*. Taky, pokud uživatel v IIP vytvoří nové kroky, pro každý z nich se vytvoří nový PA. Kolektivní chování v základním režimu odpovídá jedinému agentovi v systému K4Care – SDA* exekučnímu mechanismu. Výhody oproti stávajícímu modelu jsou viditelné například v částečném automatickém spojení FIP, který může navrhnout expertovi základní variantu finálního IIP, kterou on/ona následně upraví podle vlastních znalostí a zkušeností. Díky tomu, že všechny charakteristiky kroků formalizovaných pomocí SDA* využívají zápis pomocí rozsáhlé ontologické báze, můžeme tyto informace využít pro částečnou automatizaci procesu spojení vyžádaných FIP. Ekvivalence několika kroků modelu SDA* může být provedena pomocí příslušných PA, kteří si porovnají asociované termíny, kontext a vstupní podmínky. V případě, že souhlasí, ve finálním IIP může být umístěn jen jeden PA, který využívá sjednocení všech vstupních a výstupních údajů (např. krevní vyšetření může být provedeno pouze jednou pro všechny požadované informace). Myšlenka poloautomatického spojování dostupných FIP není nová (základní návrh byl prezentován v [13]), ale návrh v tomto příspěvku se zaměřuje na spojování jednotlivých kroků postupů pomocí vyjednávání autonomních agentů. Tato základní myšlenka může být dále vylepšena pomocí základní simulace (bude vysvětleno později) všech otevřených postupů (což architektura ProMA umožňuje). Jednotliví PA takto umí identifikovat pořadí, ve kterém mohou být exekuováni nejen v závislosti na pořadí v jednotlivých FIP, ale také v závislosti na splnění dalších vstupních podmínek. Pod pojmem „základní simulace" myslíme simulaci, kdy se PA snaží vyplňovat potřebné výstupní hodnoty dočasnými libovolnými hodnotami a také díky tomu analyzovat možný další postup v jednotlivých FIP. V následující sekci tuto myšlenku dále rozšíříme. Nakonec, pomocí CNP protokolu delegují PA problém výběru aktéra na asociované agenty rolí (RA). Oproti původnímu návrhu v architektuře ProMA musí RA v K4Care dodržovat bezpečnostní oprávnění a tedy notifikovat pouze ty agenty aktérů, kteří mají oprávnění provádět tuto akci pro pacienta, pro kterého je aktuálně IIP vytvářeno. Na základě odpovědí agentů aktérů může RA vrátit PA nejlepšího kandidáta, ale také můžeme tuto funkcionalitu modifikovat a RA vrátí seřazený seznam kandidátů a výběr přenechá expertovi.
5. Možné vylepšení a diskuseV předchozí sekci jsme popsali integraci architektury ProMA do systému K4Care, která potřebovala jen minimální počet konceptuálních změn v daných modelech. Klíčová výhoda takové integrace však spočívá v otevření nových možností pro systém K4Care, které jsou díky architektuře ProMA snadněji proveditelné. Na druhou stranu by vyžadovaly rozšíření znalostí o aktivitách podporovaných tímto systémem. Klíčovým faktorem je využití simulace všech postupů během tvorby nového IIP. Výhodou systému K4Care je, že oba typy procesů, jak lékařské doporučení, tak i organizační procesy, jsou formalizované pomocí stejného jazyka SDA* a jsou tak vnímány a je s nimi nakládáno na ekvivalentní úrovni. Jak bylo ukázáno v předchozí sekci, i základní simulace je schopna poskytnout základní omezení a návrhy, jejichž vizualizace může expertovi usnadnit práci při návrhu nového IIP. Předpokládejme tedy dále, že v systému K4Care budou obsaženy doplňující informace. Za prvé rozšíříme stávající ontologický systém o další časové informace jako odhadovaná délka trvání jednotlivých aktivit a specifikace postupu pomocí časové funkce (viz [20] pro detailnější popis těchto funkcí). Dále předpokládejme, že součástí prostředí je mapa resp. virtuální prostředí ve kterém dané zařízení působí. V poslední řadě předpokládejme povolení přístupu PA k datům ostatních pacientů (samozřejmě omezených dle bezpečnostních pravidel). Všechny tyto dodatečné informace nám umožní provést simulaci přesněji s důrazem na potřebné detaily. V závěru tvorby IIP může být tento návrh simulován a ohodnocen podle přiřazených aktérů či dalších kritérií. Simulace postupů pracuje v souladu s návrhem architektury ProMA, což znamená, že PA se snaží úspěšně simulovat asociovaný krok postupu výběrem vhodných agentů rolí a následně agentů aktérů. Vzhledem k tomu, že agenti aktérů jsou limitováni dalšími již zadanými úkoly (to znamená, že vždy simulujeme i ostatní aktuálně platné IIP uloženy v systému), vybírají si akce, na kterých budou pracovat na základě vlastních možností a priorit. Tuto myšlenku můžeme demonstrovat na jednoduchém příkladu: potřebujeme přiřadit sestru k aktivitě N.15 – změření výšky cukru v krvi doma u pacienta. V systému je k dispozici sestra Alice a hlavní sestra Eva. Alice má naplánovanou jednu úlohu na opačném konci města, Eva má plánované dvě kratší úkoly v centru. Přestože aktérky Alice a Eva mají různé role, každá z nich může tuto aktivitu vykonávat díky povolené hierarchii (kdy sestra je obecnější role jako hlavní sestra). Díky tomu, že architektura ProMA tuto hierarchii umožňuje zvládnout, RA odpovídající roli sestry osloví s požadavkem i RA odpovídající roli hlavní sestry. Pro získání vhodné odpovědi simulujeme celkový stav ve virtuálním prostředí. To znamená, že agenti aktérů v tomto prostředí také simulují provádění již naplánovaných aktivit. Když obdrží nový požadavek na provedení aktivity N.15 od RA odpovídajícího roli sestry, nacházejí se tito aktéři na různých místech ve virtuálním prostředí a na základě aktuálního stavu ostatních úkolů vědí odhadnout čas, potřebný k splnění daného požadavku. Proto, v našem zjednodušeném příkladu, by byla hlavní sestra Eva navržena jako vhodnější kandidát pro vykonání dané aktivity. Pokud by však tato aktivita N.15 měla pro Alici vyšší prioritu a ona by mohla dočasně přerušit provádění právě přiděleného úkolu, mohla by být vybrána právě ona. Pro věrnou simulaci a zejména výsledky jednotlivých kroků je nutné, aby měli PA přístup k záznamům o pacientech a věděli lépe odhadnout výsledek daného kroku (podobně jako v případě verifikace v [19]). Tento výsledek může totiž významně ovlivnit další pokračování v simulovaných IIP. Navíc, po vytvoření a uložení IIP do systému, může architektura ProMA stejně posloužit pro kontrolu dodržování těchto postupů a v případě inkonzistence upozornit vedoucího pracovníka (viz [19]). 6. ZávěrV tomto příspěvku jsme analyzovali použitelnost obecné multiagentní architektury do stávajícího systému pro podporu v rozhodování, identifikovali jsme potřebné změny v daných modelech a ukázali jak okamžité výhody z této integrace, tak i potenciální výhody a nové možnosti. Konkrétně jsme popsali procesy a stávající formalismy pro zachycení znalostních postupů v oblasti zdravotnictví a také novou multiagentní architekturu (ProMA), která je s těmito procesy schopna pracovat. Následně jsme se zaměřili na systém K4Care, kde jsou znalostní postupy formalizovány pomocí jazyka SDA* a používané multiagentním systémem pro poskytování podpory v oblasti domácí péče. Navrhli jsme spojení těchto dvou architektur a identifikovali minoritní změny v obou modelech, přičemž jsme poukázali na nové možnosti zefektivňující tvorbu individuálních intervenčních plánů pacienta. Na závěr jsme představili další nové možnosti, které touto integrací vznikly a vlastnosti, které by to systému K4Care mohlo přinést. Poděkování
Poděkování patří doc. Ing. L. Lhotské, CSc. za poskytnutí materiálů k systému K4Care. a Ing. A. Horňákové za překlad ze slovenského do českého jazyka. Tento výstup vznikl v rámci podpory projektem Specifického vysokoškolského výzkumu SVV-2010-265513 a projektem Ministerstva školství, vědy, výzkumu a sportu č. MSM6840770038.
Literatura | [1] | Balas E. A., Weingarten S., Garb C. T., Blumenthal D., Boren S. A., Brown G. D.: Improving preventive care by prompting physicians. Arch Intern Med. 2000 Feb 14;160(3):301-308. | | [2] | Garg A. X., Adhikari N. K., McDonald H. et al.: Effects of computerized clinical decision support systems on practitioner performance and patient outcomes: a systematic review.JAMA. 2005 Mar 9;293(10):1223-1238. | | [3] | Grimshaw J. M., Russell I. T.: Effect of clinical guidelines on medical practice: a systematic review of rigorous evaluations. Lancet. 1993 Nov 27;342(8883):1317-1322. | | [4] | Hunt D. L., Haynes R. B., Hanna S. E., Smith K.: Effects of computer-based clinical decision support systems on physician performance and patient outcomes: a systematic review. JAMA. 1998 Oct 21;280(15):1339-1346. | | [5] | Kawamoto K., Houlihan C. A., Balas E. A., Lobach D. F.: Improving clinical practice using clinical decision support systems: a systematic review of trials to identify features critical to success. Bmj. 2005 Apr 2;330(7494):765. | | [6] | Burack R. C., Gimotty P. A.: Promoting screening mammography in inner-city settings: the sustained effectiveness of computerized reminders in a randomized controlled trial. Med Care. 1997;35:921-931. | | [7] | Demakis J. G., Beauchamp C., Cull W. L. et al.: Improving residents' compliance with standards of ambulatory care: results from the VA Cooperative Study on Computerized Reminders. JAMA. 2000;284:1411-1416. | | [8] | Overhage J. M., Tierney W. M., McDonald C. J.: Computer reminders to implement preventive care guidelines for hospitalized patients. Arch Intern Med. 1996;156:1551-1556. | | [9] | Nilasena D. S., Lincoln M. J.: A computer-generated reminder system improves physician compliance with diabetes preventive care guidelines. Proc Annu Symp Comput Appl Med Care. | | [10] | Egan M., Wells J., Byrne K., Jaglal S., Stolee P., Chesworth B. et al.: The process of decision-making in home-care case management: implications for the introduction of universal assessment and information technology. Health & Social Care in the Community. (2009, July); 17(4): 371-378. | | [11] | Campana F., Moreno A., Riano D., Varga L.Z.: K4care: Knowledge-based homecare e-services for an ageing europe. Agent Technology and e-Health. 2008;p. 95-115. | | [12] | Aubrecht P., Lhotska L., Dolezel J., Dolezal J.: Mobile Devices for e-Services in Home Care. In: 4th European Conference of the International Federation for Medical and Biological Engineering. Springer; 2009. p. 1006-1009. | | [13] | Isern D., Moreno A., Sanchez D., Hajnal A., Pedone G., Varga L.: Agent-based execution of personalised home care treatments. Applied Intelligence. 2009;p. 1-26. | | [14] | Isern D., Moreno A.: Computer-based execution of clinical guidelines: A review. International Journal of Medical Informatics. 2008;77(12):787 - 808. | | [15] | Isern D., Sanchez D., Moreno A.: HeCaSe2: A Multi-agent Ontology-Driven a Guideline Enactment Engine. In: CEEMAS '07: Proceedings of the 5th international Central and Eastern European conference on Multi-Agent Systems and Applications V. Berlin, Heidelberg: Springer-Verlag; 2007. p. 322-324. | | [16] | Novak P.: Jazzyk: A programming language for hybrid agents with heterogeneous knowledge representations. Programming Multi-Agent Systems. 2009;p. 72-87. | | [17] | Bordini R. H., Hubner J. F., Wooldridge M. J.: Programming multi-agent systems in AgentSpeak using Jason. Wiley-Interscience; 2007. | | [18] | Hindriks K. V., De Boer F. S., Van der Hoek W., Meyer J. J. C.: Agent programming in 3APL. Autonomous Agents and Multi-Agent Systems. 1999;2(4):357-401. | | [19] | Bosansky B., Lhotska L.: Agent-based process-critiquing decision support system. In: 2nd International Symposium on Applied Sciences in Biomedical and Communication Technologies, 2009. ISABEL 2009; 2009. p. 1-6. | | [20] | Bosansky B., Brom C.: Agent-Based Simulation of Business Processes in a Virtual World. In: Corchado E, Abraham A, Pedrycz W, editors. Hybrid Artificial Intelligence Systems. vol. 5271 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg; 2008. p. 86-94. | | [21] | Riano D.: The SDA* Model: A Set Theory Approach. CBMS 2007, Maribor, Slovenia, (2007). | | [22] | Lenz R., Blaser R., Beyer M., Heger O., Biber C., Baumlein M. et al.: IT support for clinical pathways-Lessons learned. International Journal of Medical Informatics. 2007;76(Supplement 3):S397 - S402. Ubiquity: Technologies for Better Health in Aging Societies - MIE 2006. | | [23] | Kumar A., Smith B., Pisanelli M., Gangemi A., Stefanelli M.: Clinical Guidelines as Plans: An Ontological Theory. Methods of Information in Medicine. 2006;2. | | [24] | Fox J., Johns N., Rahmanzadeh A., Thomson R.: PROforma: A method and language for specifying clinical guidelines and protocols. In: Amsterdam; 1996. . | | [25] | Shahar Y., Miksch S., Johnson P.: The Asgaard project: a task-specific framework for the application and critiquing of time-oriented clinical guidelines. Artificial Intelligence in Medicine. 1998;14:29-51. | [26]
| Peleg M., Boxwala A., Ogunyemi O.: GLIF3: The Evolution of a Guideline Representation Format. Proc AMIA Annu Fall Symp. 2000;p. 645-649. |
Branislav Bošanský
Centrum agentních technologií
Katedra kybernetiky
Fakulta elektrotechnická
České vysoké učení technické v Praze
Technická 2
166 27 Praha 6
e-mail: bosansky@labe.felk.cvut.cz
|
in English |
Česky
English
Slovensky
