Software je zdravotnickým prostředkem, jakmile začne radit

MUDr. Mgr. Ing. Dalimil Chocholáč, Ph.D., MBA, LL.M., lékař a právník, který působí jako manažer úseku strategického rozvoje produktů Stapro, má čerstvou zkušenost s náročným procesem certifikace klinického informačního systému jako zdravotnického prostředku podle požadavků evropského nařízení o zdravotnických prostředcích MDR. Varuje nemocnice a lékaře před používáním softwaru, který splňuje definici zdravotnického prostředku, bez potřebné certifikace. A jak vidí české eHealth? „Někdy chceme být papežštější než papež. Na elektronizaci zdravotnictví se nemůžeme dívat jen očima inženýrů.“

• Za jakých podmínek potřebuje nemocniční informační systém nezbytně certifikaci podle MDR?

Potřebuje ji tehdy, pokud to je víc než evidenční software, tedy než elektronická kartotéka. To znamená, například když zpracovává data a na jejich základě navrhuje uživateli optimální dávku léků, další vyšetření nebo vyhodnocuje jakékoli alerty při překročení určitých hodnot. Už jen takový alert by mohl být považován za zdravotní tvrzení. Zdravotnický prostředek je cokoli, co se používá při prevenci, diagnostice nebo léčbě a není to lék. Pro software to platí také.

• Znamená to, že všechny moderní nemocniční informační systémy, ale i moderní ambulantní informační systémy budou certifikaci potřebovat?

Rozlišoval bych na jedné straně prosté evidenční nemocniční a ambulantní informační systémy a na druhé straně klinické systémy. Pokud systém zpracovává jakákoli klinická data a na základě nich doporučuje uživateli, ať lékaři, sestře, fyzioterapeutovi, porodní asistence, nebo jinému zdravotníkovi, co by měl dál sledovat, případně navrhuje úkony, které vyplývají ze zdravotního stavu pacienta, pak by takový systém měl být podle mého názoru certifikován jako zdravotnický prostředek. Pak už jen zbývá ozřejmit, do jaké bezpečnostní třídy zdravotnických prostředků takový software spadá. Evidenční software, který plní roli zdravotnické dokumentace, zdravotnickým prostředkem určitě není.

• Co když nemocnice nebo soukromý lékař bude používat sofistikovaný informační systém, který by měl mít certifikaci zdravotnického prostředku, ale nemá?

Je dobré si uvědomit, kdo je zodpovědný za používání zdravotnického prostředku, který není certifikován. Není to jeho výrobce, ale ta nemocnice, respektive, abych byl přesný, poskytovatel zdravotních služeb. Ten by si měl správně vybírat zdravotnické prostředky, které jsou certifikované. Stejně jako nenakoupí nejlevnější vatové čtverečky, které nejsou zdravotnickým prostředkem, stejně by měl postupovat při výběru softwaru. Zákonné požadavky totiž dopadají na něj. V některých případech se skutečně používají docela sofistikované softwary a certifikované nejsou.

Pokud chce ředitel nemocnice koupit do své nemocnice jenom evidenční software, jinými slovy nahradit šanony elektronickou formou, není problém vybrat necertifikovaný software. Pokud ale chce, když už elektronickou dokumentaci má, vyhodnocovat data a zlepšit péči o pacienty, aby software asistoval a radil, musí mít certifikaci. Stále ještě stačí certifikát podle předchozích pravidel v rámci přechodného období, nebo pak nový podle MDR. Jinak hrozí, že může platit pokutu v případě kontroly Státního ústavu pro kontrolu léčiv nebo mít problém v případném soudním sporu.

• Jak je to pak s aplikacemi, které si vyvíjejí i samotní poskytovatelé zdravotních služeb, myslím pacientské aplikace nebo software pro sledování určitých hodnot na dálku?

Pacientských aplikací a telemedicíny se určitě pravidla pro zdravotnické prostředky týkají také, ale je to otázka té které třídy bezpečnosti, do které bude software spadat.

•  Vy jste šli se svým nemocničním informačním systémem FONS Enterprise do certifikace třídy IIb. To je celkem vysoká třída.

To proto, že pokud by bylo s naším softwarem něco špatně, mohlo by při jeho používání dojít k vážnému poškození zdraví pacienta. Teoreticky by pro jiné nemocniční softwary mohla stačit i nižší třída IIa. Nebo i třída I, která sice musí splňovat podmínky MDR na bezpečnost a účinnost, ale nepotřebuje certifikát od notifikované osoby, podléhá takzvané samocertifikaci.

• Může se za nějakých okolností zdravotnický software dostat až do třídy III?

Například software implantabilního prostředku by spadal to třídy III a byl by certifikován spolu se svým  hardwarem.

• Jaké konkrétní funkcionality vašeho nemocničního informačního systému vás vedly k zařazení do třídy IIb?

Podmínky pro zařazení do této třídy znějí tak, že pokud by zdravotnický prostředek nefungoval správně, mohlo by dojít k ohrožení pacienta. V našem případě se to vztahovalo na čtyři oblasti. První byla elektronická medikace. Kdyby software fungoval špatně v oblasti medikací, mohlo by to vést k záměně léku nebo nepodání léku, a to by mohlo pacienta výrazně poškodit. Software sice nepředepisuje medikaci, ale nabízí funkci kopírování předpisu na další dny, a to kdyby fungovalo špatně, mohlo by dojít k chybě. Od lékaře se nedá spravedlivě očekávat, když má k dispozici funkci kopírování medikace do dalších dnů, že ji pro každý další den bude pečlivě kontrolovat, ani by to nedávalo smysl. Druhá oblast je vyhodnocování lékových interakcí. To je také systém, na který se uživatel spoléhá, a kdyby software na známou lékovou interakci mezi předepsanými léčivými přípravky neupozornil, kdyby je v databázi přehlédl, může opět dojít k poškození pacienta. Třetí oblastí jsou alerty, o kterých jsem mluvil, zejména alerty při překročení určitých stanovených hodnot ze zdravotnických přístrojů, z monitoru vitálních funkcí a dalších. Vytváříme určitá skórovací schémata, která na základě hodnot uživateli něco signalizují. Čtvrtou oblastí jsou takzvané klinické doporučené postupy, které reflektují doporučení odborných společností a napovídají zdravotníkovi, co má ještě udělat pro správnou diagnostiku nebo léčbu, například doporučí sono břicha, RTG, odběry, pohlídá jejich aktuálnost, pokud již byly provedeny, a celkově tím přispívá k tomu, že se na nic při těchto procesech nezapomene. Existují i další oblasti klinického systému, které spadají pod definici ZP, ale patrně již budou v nižší bezpečnostní třídě.

• U vyhodnocování lékových interakcí mi přijde zajímavá otázka, kde je hranice odpovědnosti výrobce systému a odpovědnosti lékaře. Pokud má lékař systém na vyhodnocování interakcí, přebírá výrobce na sebe celou odpovědnost za hlídání těchto interakcí?

Dá se říct, že na sebe výrobce přebírá velký díl zodpovědnosti. Je to stejný rozdíl, jako když na jedné straně sestra přepíše údaje z monitoru vitálních funkcí na papír a udělá při tom chybu, nebo na druhé straně když je vadný zdravotnický prostředek a zobrazí sestře špatné údaje. Ta druhá situace nejde na odpovědnost sestry. Sestra se na ta data spoléhá a i software musí být spolehlivý.

Lékař je i se softwarem na hlídání interakcí nadále odpovědný za celkovou medikaci pacienta. Ovšem když mu software nabídne jasnou odpověď, že tyto léky mezi sebou interakce nemají, může na to spoléhat a při nesprávné funkci může dojít k poškození pacienta..

• U jaké autority jste certifikací prošli?

U slovenské společnosti 3EC International, se kterou jsme spolupracovali už dříve na certifikacích podle předchozích pravidel.

• Co certifikace podle MDR obnášela?

Tu otázku jsem čekal úplně na začátku. Kdybych to měl popsat detailně, museli bychom tomu věnovat alespoň týden. Obnáší to především precizně vedenou dokumentaci vývoje softwaru. Precizně zpracovávané hlášené chyby při vývoji a včasnou reakci na tyto chyby. Pokud by ta chyba byla závažná, je nutné bezpodmínečně zpětně dohledat veškerá data, kde by se mohla projevit tak, že by mohlo dojít k poškození pacienta. Kromě zákonných požadavků a základních požadavků MDR ještě musíte plnit své vlastní požadavky, které si stanovíte ve směrnicích. Dokumentace výroby je opravdu složitá.

• Nicméně hodně věcí jste už měli nastavených z dřívějška z certifikace podle předchozích pravidel, ne?

Dá se říct, že plnění zhruba 60 procent požadavků jsme měli nastaveno z dřívějška, ale MDR zavedlo i zcela nové postupy. Jedním z nich je risk-benefit, analýza, která se musí dělat u každého zdravotnického prostředku, a u softwaru je to obzvlášť problematické.

V rámci klinického hodnocení softwaru je nutné stanovit správné cíle a požadavky tak, aby bylo reálné měřit benefity a potenciální rizika. Než jsme vytvořili sofistikovanou tabulku pro hodnocení rizik a benefitů pro pacienta, strávili jsme nad tím zhruba čtvrt roku

• Co jste tedy v tom klinickém hodnocení měřili jako rizika a benefity?

Máme ve FONS Enterprise celkem jedenáct oblastí, kvůli kterým podléhá registraci jako zdravotnický prostředek, z toho čtyři, kvůli kterým spadá do kategorie IIb. V těchto jedenácti oblastech jsme definovali rizika a benefity k hodnocení. Například u vyhodnocování lékových interakcí je rizikem, že se reálně existující léková interakce nenajde. Je potřeba stanovit, jak často k tomu může dojít, na kolik pacientů to může mít dopad a jak závažný dopad to může mít. Ještě složitější je vyčíslit měřitelný benefit pro pacienta, že lékař při medikaci dostane informaci o lékových interakcích. To se kvantifikuje poměrně složitě, protože ten software nepoužívá přímo pacient, ale používá ho lékař. Nicméně se nám to podařilo a považujeme to za naše velké know-how.

• Takže jste museli stanovit, o kolik procent budou ti uživatelé lepšími poskytovateli péče? To vám muselo přinést spoustu zajímavých informací.

Je pravda, že analýza a vstupy do té tabulky rizik a benefitů jsou daleko obsáhlejší než samotná tabulka. Když už jsme stanovili kritéria, nebylo už samotné klinické hodnocení problém.

• Jak dlouho celý proces certifikace podle MDR trval?

Podařilo se nám dodat technickou specifikaci zdravotnického prostředku tak, že byla přijata na první pokus. I tak celý proces od přípravy po získání certifikátu trval tři čtvrtě roku.

• Stapro bylo jedním z prvních poskytovatelů klinických informačních systémů ve střední Evropě, který dosáhl certifikace na úrovni MDR IIb. Jste tedy napřed?

Víme o některých specializovaných zdravotnických softwarech, které už certifikaci podle MDR získaly, například asistenční systém pro čtení rentgenových snímků hrudníku nebo software pro vyhodnocování digitálních snímků očí. Mezi robustními klinickými informačními systémy jsme ale, pokud vím, skutečně napřed.

• Vaše informační systémy podporují vedení plně elektronické zdravotnické dokumentace. O tom se už opravdu velmi dlouho mluví. Jak jsou na tom v současnosti české nemocnice, bude výhledově nějaká česká nemocnice bezpapírová?

Už celou řadu let je jedna nemocnice bezpapírová, je to psychiatrická nemocnice v Červeném Dvoře. Dá se to brát jako důkaz, že to jde. Pak jsou nemocnice, které vedou dokumentaci částečně elektronickou. A dále jsou v Česku také nemocnice, které vedou částečně elektronickou zdravotnickou dokumentaci, ale nevedou ji správně. Některé věci třeba netisknou, i když by je tisknou měly. Někteří uživatelé nebo nemocnice si s pravidly vedení zdravotnické dokumentace hlavu příliš nelámou.

• Očekáváte v dohledné době pro bezpapírovou zdravotnickou dokumentaci nějaký impuls?

Vidím na obzoru dva impulsy, jedním je návrh novely zákona o zdravotních službách, který má některé relikty ze stávajícího zákona uvést na správnou míru. Například dosud zákon předpokládá, že má existovat identifikátor záznamů v elektronické dokumentaci pacienta a jeho poskytování dálkovým přístupem. Z podstaty věci plyne, že tento identifikátor by měl být jedinečný, tedy jeden záznam rovná se právě jeden identifikátor, a to napříč všemi informačními systémy. Očekávali jsme, že konkrétní podobu identifikátoru určí ministerstvo zdravotnictví vyhláškou. To se ale dosud nestalo. Novela by tento aspekt mohla lépe specifikovat. Potom očekáváme novelu vyhlášky o zdravotnické dokumentaci. Samostatným problémem pak je skartace elektronicky vedené zdravotnické dokumentace. V ČR předepsaný skartační postup je tak složitý, že si nikdo není zcela jistý, jak to má správně být.

Také očekávané zavedení resortního elektronického podpisu bude fajn, nemocnice za něj nebudou muset platit, a to bude určitě dobrým impulsem pro vedení elektronické zdravotnické dokumentace, nicméně samo o sobě to nestačí.

Návrh novely zákona o elektronizaci předpokládá, že si nemocnice budou moci zjednodušit postupy při podepisování zdravotnické dokumentace. Osobně si myslím, že by byla chyba ustupovat od toho, že mají být jednotlivé dokumenty elektronicky podepsány. V rámci zajištění větší právní jistoty je elektronický podpis silný bezpečnostní prvek.

• Stapro působí i na Slovensku. Můžete srovnat stav digitalizace nemocnic v praxi u nás a u našich sousedů?

V praxi bych řekl, že jsme přeci jen o něco dál než Slováci. I když některé věci bychom se od nich mohli učit. Zrovna pro skartaci elektronických dokumentů, o které jsem mluvil, tam mají dvě pravidla a je to naprosto jasné, my jich máme asi dvacet a nikdo neví, jak je naplnit.

• Pomůže lepšímu sdílení dat ze zdravotnické dokumentace její standardizace, kterou se snaží ministerstvo zdravotnictví prosazovat? Aktuálně například propouštěcí zprávy…

To je dobrý počin. Bohužel se mi ale zdá, že chceme zase být papežštější než papež. V některých ohledech chceme, aby ta standardizace byla opravdu až do poslední kolonky. Na rovinu, pokud lékař například u alergií dosud vyplňoval jenom to, na co je pacient alergický a jak se alergie projevuje, tak když mu přibude dalších osm údajů, které by měl vyplňovat, nebude to dělat rád. Standardizace je správná cesta, ale měli bychom pečlivě zvažovat, co je ještě potřeba a co už není.

Každý inženýr by chtěl mít standardizováno úplně všechno. Na elektronizaci zdravotnictví se ale nemůžeme dívat jen pohledem inženýrů.