facebook LinkedIN LinkedIN - follow
IT SYSTEMS 12/2009 , ITSM (ITIL) - Řízení IT

Integrace podnikových aplikací ve zdravotnictví

Mýtus integračních platforem

Zdeněk Hřib


Na téměř každé mezinárodní konferenci o eHealth dnes zaznívají vzletné vize o integraci informačních systémů jednotlivých zdravotnických zařízení a jednotném pohledu na pacientovy zdravotní údaje v rámci jeho celoživotní kontinuální zdravotní péče. Realita je však taková, že samotná integrace informačních systémů není dostatečná. A to ani v rámci jednotlivých zdravotnických zařízení, kde je celá situace nejen technicky, ale i po právní stránce podstatně jednodušší. Je to dáno nepochybně také faktem, že každý obor medicíny má svá významná specifika, a proto snaha o přístup „one size fits all“ v tomto sektoru musí nutně dříve nebo později tvrdě narazit.


Proto nejsou výjimkou nemocnice, kde různá oddělení používají pro určité části své práce rozličné, úzce specializované aplikace různých výrobců. Vzhledem k tomu, že tyto aplikace bývají často nedostatečně propojené (integrované), je obtížné, až prakticky nemožné, získat na jednom místě o jednom pacientovi skutečně kompletní informace zahrnující všechny procesy dané nemocnice. Cestou z tohoto informačního bludiště je integrace aplikací založená na konceptu SOA (service oriented architecture – architektura orientovaná na služby). Ale i zde je háček. Z marketingových materiálů některých renomovaných výrobců můžeme totiž nabýt dojmu, že integraci podnikových systémů lze zajistit koupí nákladné integrační platformy a že zavedením této integrační platformy v podstatě zároveň postavíte moderní architekturu podnikového informačního systému označovanou onou magickou zkratkou „SOA“. Skutečnost je však jiná a úzce souvisí s tím, co vlastně ve skutečnosti SOA znamená. V koncepci SOA poskytuje každá aplikace své služby prostřednictvím svého API (application programmable interface) jiným aplikacím. Dnes je API představováno zejména rozhraním webových služeb. Tyto služby jsou následně vystaveny na ESB (enterprise service bus), tedy podnikové sběrnici, na kterou se, jakožto na centrální prvek komplexního podnikového informačního systému, napojují systémy, které chtějí tyto služby využívat (například potřebují získat data z aplikace X nebo zapsat data do aplikace Y). Z výše uvedeného vyplývá, že SOA nelze jen tak koupit – je třeba ji především plánovat a řídit a také jí podřídit design jednotlivých dílčích aplikací.

 

Obr. 1: Schéma integrace založené na principech SOA
Obr. 1: Schéma integrace založené na principech SOA

 

Bohužel, stávající situace ve většině zdravotnických zařízení je taková, že v centru nestojí integrační platforma propojující jednotlivé aplikace s definovaným API, ale většinou databáze jedné rozsáhlé aplikace, která se obvykle nazývá Nemocniční informační systém (NIS). Integrace tak neprobíhá pomocí služeb exponovaných jednotlivými dílčími a relativně jednoduchými aplikacemi na ESB, ale pomocí přímého zápisu do databáze jedné „centrální“ aplikace, která se tak stává nesmírně komplexní. Důvody jsou víceméně historické a pocházejí ze začátku devadesátých let, kdy bylo nutné rychle vybudovat systémy pro výkaznictví pojišťovnám, tedy řešit primárně ekonomickou agendu. K těmto systémům byla následně doplněna funkčnost evidence lékařské části zdravotnické dokumentace, stravování a hotelových služeb a další agendy. Následně už nikomu nepřišlo nelogické, že se vlastně všechny další aplikace stávají moduly monolitického systému s jednou obří databází. Vzhledem k tehdy běžné architektuře je drtivá většina funkčnosti aplikace řešena na jednotlivých formulářích pro zadávání dat a vše je zabaleno do jedné binární distribuce spustitelného souboru. Ve výsledku je pak taková monolitická aplikace velmi těžko integrovatelná do jakéhokoliv většího celku.

 

Obr. 2: Schéma integrace při použití „centrální“ aplikace (současná situace ve zdravotnictví)
Obr. 2: Schéma integrace při použití „centrální“ aplikace (současná situace ve zdravotnictví)

 

Procesy, procesy, procesy

Je možné si v tuto chvíli položit otázku, proč vlastně řešit integraci přes integrační platformu, a nikoliv přes NIS. Hlavním důvodem je stále více zřetelná potřeba implementace procesního řízení ve zdravotnických zařízeních. Původní systémy jsou řešeny tzv. agendovým přístupem, tedy principiálně slouží k evidenci údajů. Takový přístup je dostatečný v systému pro několik málo uživatelů, nicméně řízení podniku o několika stovkách, ba i tisících zaměstnanců, i v běžných průmyslových odvětvích, vyžaduje přístup zcela jiný. Zdravotnictví je navíc specifické tím, že péče o zákazníka (pacienta) je často řešena několika organizačními jednotkami zdravotnického zařízení najednou (mezioborová péče), čímž nadále vzrůstá komplexnost klinických procesů a s nimi logicky vzrůstá i riziko chyby při poskytování zdravotní péče. Zavedení procesního řízení se tak stává nejen ekonomickou nutností, ale morální a etickou nezbytností. Standardními nástroji IT podpory procesního řízení je procesní nadstavba nad ESB implementující BPEL, na kterou je možné napojit další nadstavbové mechanismy, jako například BAM (business activity monitoring) a BPM (business performance monitoring), tedy nástroje pro měření procesů a jejich výkonnosti. Například doby mezi jednotlivými kroky podnikového procesu či jejich množství a dalších parametrů. Na běh kompletního systému je dále možné (po jeho dekompozici na jednotlivé dílčí celky) efektivně dohlížet pomocí nástrojů SOA governance, které mohou pomoci určit úzká místa systému, jak v rámci podnikových aplikací, nebo i v externí integrované aplikaci, mimo kontrolu podnikového IT oddělení. Hlavní odměnou za námahu vynaloženou při implementaci SOA je však skutečnost, že v takovémto informačním systému lze pracovat s komplexním virtuálním objektem pacienta zahrnujícím veškeré klinické i ekonomické informace ze všech dostupných systémů. Skutečnost, že jsou všechny informace dostupné na jednom místě, umožňuje nad těmito daty budovat další nadstavby pro podporu klinického rozhodování a snadno řešit komplexní procesy (např. příjem pacienta na oddělení přes centrální příjem), které nutně zahrnují práci s daty ve více interních aplikacích (klinický systém, žádankový systém, stravovací systém, výkaznictví pojišťovny) a souběžně vyžadují i data z externích systémů (ověření čísla pojištěnce v registru VZP, ověření platnosti občanského průkazu u ministerstva vnitra, vyžádání snímků z externích PACS). Tyto procesy lze snadno řešit právě nástroji SOA, například jejich implementací pomocí BPEL (Business Process Execution Language) v procesní nadstavbě orchestrací základních služeb poskytovaných dílčími aplikacemi na podnikové sběrnici ESB. BPEL je jazyk, kterým lze popsat část procesu při návštěvě pacienta v ambulanci například takto: „Není-li nově příchozí již zaregistrován, ověř platnost jeho občanského průkazu pomocí služby Ministerstva vnitra, pak ověř jeho pojištění pomocí služby ověření pojištění u pojišťovny, pokud je vše v pořádku, založ v klinickém informačním systému informaci, že pacient prošel recepcí a je v čekárně.“ Výhodou je i uživatelská přístupnost a grafické znázornění takového procesu, který se stává pro manažery transparentním a snáze řiditelným.

Kromě dalších, na první pohled zřejmých přínosů v technické rovině, kterým je například větší transparentnost systému pro IT oddělení dané nemocnice či prevence tzv. vendor lock-in (zákazník nemá praktickou možnost opustit svého stávajícího dodavatele NIS ani v případě značné nespokojenosti s poskytovanými službami), je dalším motivem stále vzrůstající potřeba elektronizace ošetřovatelské dokumentace. Ta je na rozdíl od lékařské dokumentace stále ještě výhradně papírová, přestože ošetřovatelské úkony tvoří až 85 procent veškeré klinické činnosti. Důvod patrně souvisí se skutečností, že dokumentace těchto úkonů je obvykle podstatně strukturovanější než dokumentace lékařská, a proto její implementací běžnými postupy do běžných NIS by komplexnost databáze vzrostla několikanásobně. Proto se pro tento účel již začínají prosazovat moderní formulářové systémy založené například na standardu XForms. Tato nová dokumentace musí však být provázána s již existující zdravotnickou dokumentací pacienta, což opět vyžaduje komunikaci s původní databází (monolit NIS), přičemž na straně moderních formulářových systémů je často jediným přijatelným řešením komunikace webová služba nebo jiná forma messagingu. Strukturovaná ošetřovatelská dokumentace integrovaná s ostatními datovými úložišti se pak může stát cenným zdrojem informací o kvalitě zdravotní péče poskytované danou nemocnicí. Posledním motivem zavedení SOA je skutečnost, že nástup národních projektů eHealth v České republice přinese další potřebu integrace podnikových informačních systémů ve zdravotnických zařízeních s centrálními systémy, takže profesionální integraci pomocí standardních prověřených postupů a nástrojů se vyhnout prostě nelze.

ERP nesmí zůstat stranou

Dalším stále více skloňovaných pojmem ve zdravotnické informatice je zkratka ERP. Tento pojem v plné podobě znamená „enterprise resource planning“, tedy systém pro plánování podnikových zdrojů. Často se však za ERP vydává software řešící pouze ekonomické, majetkové a personální agendy. Pokud má systém skutečně pomoci s „plánováním zdrojů“ musí logicky obsahovat především data o skutečném využití těchto zdrojů (přímo nebo pomocí integrace), data o produkci (v pojetí našeho zdravotnictví jde o výkaznictví pro pojišťovnu), plán využití pracovníků a přístrojové techniky a další. Realita je však taková, že zmíněné agendy jsou spojovány s těmito systémy jen velmi vzdáleně. Využití zdrojů je tak evidováno v docházkových systémech a provozních denících (často papírově), výkaznictví pro pojišťovny je uloženo v databázi NIS a plán využití zdrojů je řešen jako externí kalendářová aplikace. Plánování, byť s použitím manažerské nadstavby pro generování statistických sestav nad ekonomickým systémem či výkazy pro zdravotní pojišťovny, má tedy značně omezené možnosti. O možnosti vztáhnout ekonomické veličiny přímo ke konkrétnímu klinickému případu ani nemluvě. I zde proto může organizace těžit ze sjednoceného pohledu na ekonomická i klinická data o jednotlivých pacientech, který jí kvalitní implementace SOA umožní, a využít pro analýzu dat standardních postupů a nástrojů BI (business intelligence) ověřených v jiných sektorech. Lze obecně říci, že zdravotnická informatika nemá důvod lišit se v základních konceptech od informatiky jiných odvětví poskytujících služby. V těchto odvětvích najdeme mezi základními IT nástroji kromě ERP systémů také CRM systémy či systémy povahy service desku, tedy systémy pokrývající u servisních společností core business procesy podniků. Ve zdravotnictví se sice zavedení principů CRM nyní jeví jako zbytečnost, ale s počtem přibývajících neplatičů regulačních poplatků a s rozšířenými možnostmi nabídky nadstandardních služeb se tento názor bude nepochybně zvolna měnit. Na místě systému pro podporu core businessu je pak možné vidět kvalitní klinický informační systém, který je především procesně orientovaný a rovněž standardním způsobem integrovaný s ERP systémem v rovině plánu a skutečného využití podnikových zdrojů a výkazů produkce pro zdravotní pojišťovny.

Autor působí jako senior business consultant společnosti Aquasoft.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.

Inzerce

Konec papírování, digitalizujte a usnadněte si práci!

IT Systems 3/2024V aktuálním vydání IT Systems jsme se zaměřili na vývoj digitalizace ve světě peněz, tedy v oblasti finančnictví a pojišťovnictví. Dozvíte se například, proč je aktuální směrnice PSD2 v inovaci online bankovnictví krokem vedle a jak by její nedostatky měla napravit připravovaná PSD3. Hodně prostoru věnujeme také digitalizaci státní správy a veřejného sektoru, která nabírá obrátky.