V této části dokumentace popisujeme podrobněji jednotlivé pracovní scénáře. Rozumí se, že agenda kontroly infekcí rozlišuje pro různé pracovníky různé profily. Směrem shora dolů podle šíře kompetencí vůči systému to jsou tyto:

• Systémový administrátor. Smí spouštět všechny scénáře a provádět i konfigurační zásahy. Jeho zásahy do systému jsou ale spíše výjimečné a slouží k úpravám, odstranění závad a servisu vůbec.
• Odborný administrátor, odpovědný lékař. Má oprávnění ke všem úkonům, typicky se ale nezabývá konfigurací systému a řešením čístě provozních či technických problémů. Má rovněž právo k improvizacím nad daty. Tedy kladení sql-dotazů ad-hoc, k definici významu klasifikačních položek apod. V jeho kompetenci je rovněž formulace námětů na úpravy do příštích verzí systému a to jak s ohledem na místní kontext tak iobecně.
• Člen teamu kontroly infekcí. Může definovat nové kauzy, zapisovat do agendy kontroly infekcí. Může spouštět rutinní statistické akce atd.
• Kontaktní lékař na oddělení. Má vesměs právo na prohlížení obsahu agend a rutinních statistických výstupů. Má právo zapisovat do agendy hlášení kontroly infekcí.
• Zdravotnický personál na oddělení. Právo prohlížet (a samozřejmě plnit) instrukce.
• Zdravotnická veřejnost v nemocnici. Prohlíží si rutinní statistické přehledy. Sem patří rovněž management.

Je jasné, že toto rozdělení není dogmatické. Pouze popisuje hierarchii tak, jak by měla ideálně vypadat. Rozdělení funkcí do profilů je dynamickou záležitostí a v každé instalaci se bude zřejmě v detailech lišit. Důležité sdělení je to, že na různé profily je pamatováno.

Následující výčet scénářů je seřazen naopak směrem zdola nahoru a začíná tedy scénáři, které jsou určeny profilům s nejmenšími kompetencemi.

• Prohlížení přehledu aktuálních zápisů v agendě kontroly infekcí. Zde i v dalším se rozumí prohlížení v databázové slova smyslu, kdy je uživatel vybaven funkcemi typu filtr, přetřídění, drill-in, zůžení atd. Prohlížení může být podle loginu uživatele automaticky omezeno jenom na data, která smí vidět - to je opět obecnou vlastností všech zobrazení, která jednoduše neukazují nikdy nic, co neplyne z kompetence daného uživatele.
• Prohlížení jednotlivých kauz.
• Prohlížení recentních hlášení.
• Prohlížení recentních případů. Je tedy možno kdykoli operativně zjistit, zda se náhodou team pro kontrolu infekcí již případem daného pacienta nezabývá. Tím se přirozeně sníží počet hlášených případů o ty, které by případně byly nahlášeny několikanásobně.
• Prohlížení sumarizačních údajů. Celá hierarchie sumarizující události významné pro kontrolu infekcí a to podle typu, období i struktury nemocnice. Jedná se vesměs již o anonymizovaná data.
• Zápis hlášení o suspektním případu.
• Prohlížení instrukcí personálu, vzetí konkretní instrukce na vědomí.
• Zápis do agendy kontroly infekcí. Založení nebo úprava pomocí progamovatelného formuláře.
• Zápis do tabulky kauz kontroly infekcí. Založení nebo úprava pomocí progamovatelného formuláře.
• Zápis do přehledu suspektních případů. Opět založení nebo úprava pomocí formuláře. Předpokládá se, že odpovědný lékař se bude každým aápisem zabývat opakovaně až do vyřešení a definitivního určení daného případu.
• Zápis do rutinního přehledu. Rutinní přehled sumarizuje údaje ze všemožných zdrojů. V ideálním případě se jedná o laboratorní systém, konzultační systém, systém výdeje vázaných antibiotik, intranet i manuálně vznikající zápisy. Jsou-li zdrojem informací jiné informační systémy, předpokládá se, že jejich příspěvky přes vhodně rozhraní do agendy "naskáčou" de-facto samy.
• Improvizované využití údajů.

Úplný výčet scénářů by byl velmi dlouhý a není ani nutno ho uvádět. Existuje řada variant de-facto stejných scénářů. Kupříkladu tedy můžeme kauzu ukončit v obvyklém formuláři vyplněním mimo jiné datumem ukončení, můžeme ale tutéž kauzu ukončit k tomu určenou horkou klávesou (a datum se rozumí dnešní) atp.

Nyní zkusíme popsat tok událostí v čase. Jedná se tak trochu o problém typu "slepice x vejce", musíme v cyklickém a pravidelném procesu nalézt jedno místo, jak do něj vniknout. Samozřejmě, agenda asynchronně zachycuje řadu případů a každý z nich se nachází v různém stadiu rozpracovanosti a hodnocení. Jména oddělení i další specifkace jsou samozřejmě smyšlená.

• Na oddělení CHIR je zjištěn suspektní případ, pacient Josef Pacient. Prozatím není zcela zřejmé, o co se jedná. Iniciální indikací by alternativně mohl být fakt, že léčba pacienta byla konzultována s odpovědným lékařem. Podobně by se do horizontu záběru teamu kontroly infekcí mohl dostat z laboratoře, například díky pozitivitě hemokultury. Každopádně vznikne záznam do rutinního přehledu a ten si nese takové atributy, které byly podle povahy věci známy. Vyjadřuje-li se k případu lékař manuálně přes intranet, zapíše klinické hodnocení. Posílá-li data laboratorní systém, budou data obsahovat případně identifikaci patogenního agens apod.
• Aby byla agenda provozovatelná i v rozsáhlých nebo počítačově méně vybavených nemocnicích, je samozřejmě možné hlášení provést telefonicky nebo písemně. Organizační regule uvnitř nemocnice stanoví přesně a závazně komu a v jaké formě.
• Odpovědný lékař se vznikajícími záznamy v rutinním přehledu pravidelně zabývá. Přitom záznamy vytvářejí přirozeným způsobem určité shluky - data týkající se jednoho pacienta. Rozumí se recentní data, i když je možno přistupovat i k datům starším. To v případě opakovaných hospitalizací apod. Podle toho, jaké informace odpovědný lékař má, může založit záznam o novém suspektním případu. Řada údajů se automaticky zkopíruje, například z hlášení nebo z laboratorního výsledku. Může se také stát, a bude to častý případ, že daný pacient je již agendě znám. Tak jako tak uživatel pomocí barevného rozlišení dostane každý ze záznamů v rutinní přehledu do některého ze stavů, které indikují míru znalostí o případu. Tedy od "zatím nic nevíme" až do "přesně známe". Různé záznamy také mohou být prohlášeny za irelevantní, chybné nebo duplicitní.
• Jakmile má pacient založen případ, vyvíjí se tento autonomně a může se stát, že pacienta bude mít otevřeno více případů. Například uroinfekci zároveň s komplikací po operačním výkonu.
• Nový případ nebo případ postupně vyjasňovaný pak může nebo nemusí "pasovat" do některé z již existujících kauz. Máme-li tedy již kupříkladu výskyt MRSA na oddělení CHIR a věcí se zabýváme, kauzu "MRSA na CHIR v litospadu 2004" máma asi založenu. Jedná-li se o první takový případ a pokud se podezření na MRSA potvrdí, je naopak na místě takovou kauzu založit.
• Založení kauzy je doprovázeno zápisem a počínaje tím okamžikem se může rozjet agenda kontroly infekcí vázaná na tuto kauzu.
• Každý z teamu kontroly infekcí může vytvořit a upravovat předem nespecifikované množství zápisů do agendy. Ty by měly odpovídat atomárním věcem typu zjištění, intrukcím pro personál, instrukcím pro team. Vždy pak vybaveny adekvátním datumem - termínem splnění vyplývajících úkolů.
• Team kontroly infekcí se pravidelně, obvykle jednou týdně, schází a kauzy vyhodnocuje. Z povahy věci plyne, že část teamu se bude věnovat spíše intervencím na místě na oddělení CHIR, jiná část teamu pak buse spíše vyhodnocovat laboratorní výsledky atd. Údaje o kauze jsou zpřesňovány, zápisy v agendě kontrolovány na plnění termínů a instrukcí.
• Personál na oddělení CHIR (jakož i na ostatních odděleních) ma za povinnost sledovat instrukce teamu. Software jim dává možnost vzít konkrétní instrukci na vědomí. Jinak ale zápisy do agendy rpovádějí výlučně členové teamu s výjimkou iniciálních hlášení a konfirmace klinických závěrů.
• V rámci kauzy se případně vyskytne další jeden nebo více pacientů, cyklus se opakuje.
• Podobně se v rámci kauzi postupně uplatňují opatření teamu, dochází ke kontrolám a posléze i k utlumení kauzy a jejímu zhodnocení.
• Tím se tedy uzavírá cyklus práce nad jedním případem a šířejí kauzou, do které patřil.

Index