Adastra.JLabs.Prezentace20080424

Adastra.JLabs.Prezentace 24.4.2008

Předmět prezentace

Předmětem prezentace je koncepce nemocničního informačního systému založená na důsledné decentralizaci funkcí a na využití moderních konceptů, jako jsou webservices, nezávislost na platformě atd. Ukázka předvede průřez samotného jádra systému - práce s pacientskou dokumentací.

Prezentovaná data jsou anonymizována resp. náhodně vygenerována pro vymyšlené pacienty. Data jsou ale sestavena tak, aby dávala smysl. Je-li tedy pacient například po úrazu hlavy na neurochirurgii, je jeho dokumentace naplněna údaji o komplikacích, spoustou pomocných vyšetření atd. Reálná implementace serverové části je realizována downgradingem na virtuální Linux pomocí VMWare na notebooku a případné horší prodlevy nebo nedokonalosti v přístupu k datům prosíme velkoryse tolerovat. Vypreparovat a na notebooku odvézt celý distribuovaný informační systém není úplně jednoduché:-)

Základní rysy prezentovaného NISu:

A.Existuje jenom malá a omezená množina komponent, které je možno označit jako "centrální". Patří sem správa číselníků, registry pacientů, dokumentů (datový sklad), události a centrální vyúčtovací systém.

B.Každý primiariát nebo podobná organizační jednotka má vlastní, naprosto ucelený a autonomní informační systém, který může v krajním případě fungovat an-sich. V případě nedostupnosti centrálních komponent takový systém funguje případně s menším komfortem, ale funguje. Výpadek takovéhoto autonomního systému pro změnu nijak neovlivní provoz jinde.

C.Technicky může mít každé oddělení svůj server, může také několik oddělení rezidovat na jednom serveru, konfigurace je logická a ne fyzická.

D.Všechny tyto autonomní systémy mohou být iniciálně identické kopie stejného generického systému. To tedy prakticky značí, že všichni mohou začít s jednotným a jednoduchým systémem, Dále v prezentaci bude jasně vidět, že velmi odlišné aplikace pro anestezii, neurologii, neurochirurgii, MRI, ... mají společné kořeny a přitom jejich kustomizací vznikly naprosto specializované systémy.

E.Koncepce vůbec nepředjímá, zda centrální komponenty či některé autonomní systémy jsou nebo nejsou implementovány stejným dodavatelem. Naopak, rozumí se jako samozřejmé, že nemocnice může mít vlastní registr nebo jiné petrifikované řešení, se kterým je dlouhodobě spokojena. Pokud existuje možnost "obalit" takovéto komponenty pomocí webových služeb, ihned se takovéto komponenty stávají plnohodnotnou a kooperující komponentou celého systému.

F.Grafické rozhraní. Aplikace NENÍ grafické rozhraní. Názor na jeho šikovnost i konformita s platformou se mění. Proto je důsledně oddělena funkcionalita a prezentační vrstva. Aktuálně podporujeme tyto tři varianty rozhraní, každá z nich má svoje výhody i nevýhody:
VaxNt - klasická aplikace pro Windows, široká funkcionalita. Není platformě nezávislá, neumožňuje snadno vzdálený přístup. Vyžaduje instalaci na koncová PC.
Stetoskop - třívrstvá aplikace. Vázána na Windows, nevyžaduje žádnou instalaci na koncová PC, umožňuje bezpečný přístup k datům z domova nebo z ordinací externích spolupracujících lékařů.
Webové rozhraní - zcela platformě nezávislé, dovoluje vzdálený přístup, pokrok na poli rozvoje GUI je automaticky zajištěn hnací silou - Internetem.

G.Nezávislost na databázové platformě. Implementace nedefinuje striktně způsob ukložení dat. Je možno použít jak "vysokozdvižné" systémy (ORACLE,MS-SQL) tak open=source řešení (MySQL, FirebirdSQL).

H.Důležité je, že všechna tři GUI rozhraní pracují důsledně nad stejnými daty a implementují funkce pomocí stejných základních operací. Typické operace NEJSOU v řeči datábáze, ale v řeči logické:
Zavedení pacienta do registru
Příjem na oddělení
Denní dekurz
Medikační list
Infuzní list
Operační protokol
Propouštěcí zpráva
Vyúčtování konkrétního typu operace
... Jak se tedy promítnou logické akce lékařů a sester není věci front-end aplikace, ale je to definováno jako logická operace přes aplikační server, který jediný má důvod vůbec vědět, která data jsou v jaké databázové tabulce a zda vůbec to je nebo není databáze.

I.Kooperace mezi autonomními systémy. Každý autonomní systém má svou určitou vnitřní "kuchyni", do které v zásadě jiným systémům nic není. Například mikrobiologická laboratoř je producentem výsledků, konzultací atd. Zároveň má možnost nahlížet do jiných dokumentů produkovaných jinými odděleními. V této řeči jsou všechny autonomní systémy producenty a konzumenty definitivních verzí dokumentů, které všechny směřují do společného datového skladu, registru dokumentů. Jak přesně funguje každé oddělení je pro ostatní oddělení BEZPŘEDMĚTNÉ. Je výhodou, pokud je funkcionalita i ovládání všude shodná, ale není to nezbytně nutné a někdy to ani není dosažitelné, protože nemocnice může mít již netriviální investice v PACSech, laboratořích apod. a není důvodu se jich vzdávat.

J.Přístupová práva a role. Systém předpokládá centralizovanou správu a dovede ji respektovat. Je tedy věcí administrativního rozhodnutí, kdo smí co dělat a jaká data smí vidět. Konfigurace pak jednoduše dáví každému na výběr jenom z těch funkcí, které má povoleny.

K.Úplnost. Systém předpokládá, že některé věci má a musí mít nemocnice nějak již vyřešeny - například správu hesel. Pokud nějaká takováto komponenta neexistuje, systém nabízí generické, i kdyžb jednoduché řešení. Není-li tedy centrální přihlašovací server, systém může použít svůj vlastní.

L.Aktuální kroky vývoje. V současnosti probíhá reimplementace směrem na web tak, aby cílové řešení nebylo platformě závislé. To zasahuje i do definice logiky některých funkcí tak, aby například šlo smysluplně využívat portabilní zařízení, která mají daleko ke klasickému počítači.

M.Poznámka k unifikaci a jednotnosti. Podle našich zkušeností mají snahy o unifikaci práce uvnitř nemocnice určité nepřekročitelné hranice plynoucí z podstatných odlišností oborů. Proto prostě vždy bude existovat jakási nepochybná společná část využitelná v zásadě kdekoli, ale jakákoli pokročilejší činnost specifická pro daný obor vyžaduje podstatnou kustomizaci. Pro řadu oborů také existuje specifický software, například od výrobců modalit RDG, jehož úrovně žádný obecně pojímaný NIS nemá šanci nikdy dosánout. Zde je pak předností takovýto software umět spíše zařadit a využít než ho marně nahrazovat.

N.Poznámka ke standardům. Dekompozice na logické funkce a možnost jejich implementace heterogenními systémy je zcela v duchu normalizačních úsilí typu HL7. V zásadě by mělo být jedno, kdo a jak přesně implementuje jaký systém. Důležité je, aby se s ním dalo komunikovat pomocí popsaného a co možná standardizovaného rozhraní.

Tok prezentace:

    Neurochirugie - typické oddělení orientované na invazivní zákroky:
        Přehled pacientů
            Přehledy obecně
            Tablo
                Prolínání administrativní a odborné činnosti
        Základní funkce
            Příjem a pohyb po oddělení
            Operace
                Normy operací
                Konkrétní zákrok ANEU
                Klinické protokoly
            Denní dekurzy
                Příklady výstupů
                Medikační listy
                Vzorové konfigurace
                Náhled do datového skladu
                    Asynchronní běh
            Propuštění
        Statistické výstupy

    Neurologie - typické oddělení orientované na konzervativní léčbu, diagnostiku atd.:
        Přehledy
            Společné rysy generické konfigurace
        Ambulance a vyšetřovací modality:
            Různé typy záspisů s předpřipravenými zápisy
        Složitá klasifikace případů
        
    Anestezie:
        Celonemocniční dosah anestezií
        Statistické funkce
        Řízení kvality - přesčasy, výpočty nutné kapacity pro weekendy

    Pozitronová emisní tomografie:
        Různé profily pro různé role pracovníků.
        Pokročilý plánovací systém.
        Žádanky versus přímá rezervace termínů on-line.

    Magnetická rezonance:
        Plánování provozu
        Flexibilní definice rastru

    Gama nůž:
        Příklad úzké vazby s kooperujícím oddělením
        Různé varianty vzhledu GUI

    Stetoskop:
        Vzdálený přístup
        Grafická informace a napojení na PACS
        Konfigurace pro externisty, odběratele výsledků apod.

    Web:
        Alternativní přístup k dokumentaci
        Konzilia

    Tiskový systém:
        Prezentace využívá jako tiskový server lokální instalaci MS-Office. Cílové řešení 
        je ale centrální tiskový server produkující .pdf dokumenty A ZÁROVEŇ ARCHIVUJÍCÍ úplně 
        všechno, co nemocnice vydává jako oficiální tištěný doklad.
        To dovoluje jednotný look, flexibilní změnu formátů atd. A hlavně, není možno, aby vznikl 
        nějaký doklad "na divoko" a nebylo jasné, kdo, kdy a kde jej vytvořil.

    Summary:
        Prezentovaný systém nabízí zároveň distribuované řešení a zároveň jednotící pohled na 
        zásadně důležité činnosti v nemocnici. Vychází z názoru, že každá interakce lékaře, sestry, 
        laboranta atd s pacientem (nebo vzorkem apod. v případě paraklinických oborů) musí být dobře 
        popsána na logické úrovni a rezultuje z ní vždy nějaký dokument, ať opravdu tištěný nebo 
        zcela fiktivní. Vlastnímu procesu vzniku dokumentů je ponechána velká míra volnosti v každém
        oddělení, dokumenty jsou pak následně ukládány v centrálním skladu a zde jsou k dispozici 
        jak pro náhled tak i pro jakkoli složitou statistickou analýzu.

        Otevřenost datového modelu. Všechny snahy o dokonale definovaný datový model jsou předem 
        odsouzeny k nezdaru, protože měnící kontext i postupující kustomizace vždy odhalí nějaký 
        nedostatek. Proto na precizní model rezignujeme úmyslně a ponecháváme možnost datové 
        atributy flexibilně ukládat opravdu jako databázové položky nebo jako součást 
        "amorfní hmoty", volného textu. Aplikace tak jako tak v naší koncepci nikdy nepřícházejí 
        s daty do styku jako s databází, ale jako s XML dokumenty. Pochopitelnou výjimkou je 
        statistický subsystém, který ale není zase určen pro široké a zcela bezbřehé používání

    K*O*N*E*C

Aktualizováno dne 20080423. Komentář: info@jlabs.cz