Diskuse o eReceptu v ČR – aneb další pokus, jak oživit nenarozené dítě
V rámci diskuse, která se při této příležitosti rozpoutala jak v Poslanecké sněmovně, tak na stránkách médií, se opět objevují argumenty kritiků i zastánců povinné e‑preskripce. Většina se tak či onak dotýká finanční stránky systému, mnoho z argumentů je však účelových či zavádějících, často jsou také prezentovány spíše dojmy a přání než fakta. MUDr. Jan Bruthans, Ph.D., který se v rámci svého postgraduálního studia zabýval ekonomikou eHealth, se v rozhovoru pro Medical Tribune zamyslel nad stavem a perspektivami eReceptu.
| Jak by se podle vás dala charakterizovat současná situace kolem eReceptu?
Předně je potřeba odlišit různá mediální vyjádření od skutečnosti. Zastánci eReceptu veřejně mluví hlavně o možnostech, které by elektronická preskripce mohla přinést za předpokladu, že bude funkční lékový záznam pacienta, popř. další nadstavbové funkce, tedy zabránění interakcí mezi léčivy, kontrola dávky konkrétního léku konkrétnímu pacientovi podle jeho zdravotního stavu, zabránění plýtvání s léčivy, omezení administrativy atd.
Smutnou pravdou však zůstává, že za desítky až stovky milionů z veřejných prostředků máme nyní k dispozici datové rozhraní na posílání údajů od lékaře k lékárníkovi. Je to jistě bezpečnější, než když si pacient nese rukou „naškrabaný“ recept. Ale není to o nic bezpečnější, než když lékař pacientovi recept vytiskne z počítače, což už celá řada lékařů a nemocnic stejně dělá – a nic to nestojí.
Zjednodušeně řečeno, eRecept neumožňuje nic víc než poslat datový záznam od lékaře do lékárny. Lékař nemůže nahlédnout do celého lékového záznamu pacienta, vidí pouze jím předepsaná léčiva. A i kdyby měl přístupný celý lékový záznam, což naráží na Úřad pro ochranu osobních údajů a vůbec celý koncept dobrovolnosti sdělování informací pacientem, systém nemá integrované žádné funkce pro kontrolu interakcí či další nadstavbové funkce. A i kdyby lékař viděl, že již léčivo bylo předepsáno někým jiným, stejně neexistuje žádný legislativní podklad, na základě kterého by bylo možné další lék nepředepsat. Výsledkem je, že využití eReceptu je zcela minimální, i když všechny lékárenské systémy již umožňují eRecept přijmout.
| Jaké jsou tedy hlavní nedostatky současné podoby elektronické preskripce a co bychom měli udělat pro jejich nápravu?
Jak už jsem řekl, základním problémem je, že systém v současnosti nemá žádnou z deklarovaných funkcí, kterou by měl mít. Právní rámec a do značné míry i společenská atmosféra v České republice zatím vylučuje, že by mohl fungovat tak, jak by měl. Určitě bychom však neměli zamítnout myšlenku eReceptu jako takovou a rušit to, co dosud v této oblasti bylo vykonáno. To by byla velká chyba. Na druhou stranu bychom se neměli vydávat cestou jakýchsi provizorních řešení s tím, že zavedeme povinnost elektronické preskripce a budeme spoléhat, že se tím problém vyřeší.
Při dalším rozvoji elektronické preskripce můžeme využít dosavadních zkušeností i nasbíraných dat, do určité míry nejspíš i datové rozhraní, které bylo na SÚKL zprovozněno, nicméně bezpodmínečně nutné je na základě studií proveditelnosti a cost‑benefit analýz redefinovat, co by měl systém umět, komu přináší jaké výhody a povinnosti, popř. jaká rizika z jeho zavedení vyplývají. Vše je také nutné řešit v návaznosti na legislativní změny a po široké diskusi v odborné, popř. i laické veřejnosti. V ideálním případě by měla jak v laické veřejnosti, tak mezi politiky a odpovědnými úřady panovat shoda na tom, že údaje o pacientovi ze systému může použít každý oprávněný lékař. Pokud totiž bude fungování systému podmíněno tím, že pacient musí dávat souhlas s nahlédnutím do svého lékového záznamu vždy každému lékaři zvlášť, tak systém patrně nebude nikdy dobře fungovat.
| Při takovém pojetí systému se ale mohou objevit námitky o zneužitelnosti citlivých zdravotních dat pacienta…
Určitá pravděpodobnost zneužití dat bude existovat vždy, ale pokud se tak stane, mělo by následovat rychlé odhalení viníka a tvrdý postih. Snažit se zamezit zneužití za cenu enormního omezení funkčnosti systému není řešením. V takovém systému budou sice data dokonale chráněna, ale nikdo ho nebude používat. Zamysleme se nad tím, komu vlastně vadí „zneužití“ dat o jeho zdravotním stavu. Zjistíme, že jde především o mladé lidi, nejvíce v případech, kdy trpí chronickým potenciálně letálním či jinak velmi omezujícím onemocněním. Logicky takoví lidé nemají zájem zpřístupňovat informace o svém zdravotním stavu ať zaměstnavateli, nebo různým institucím. Na druhou stranu pokud mi bude 70 let, budu mít více různých diagnóz a přivezou mě vozem záchranné služby do nemocnice, kde mě neznají, budu rád, že se ošetřující lékař snadno dostane k informacím, na základě kterých rychle stanoví diagnózu a nasadí bezpečnou léčbu.
Navíc již v současné době existuje mnoho jiných, mnohem „pohodlnějších“ způsobů, jak se dostat ke zdravotním údajům jednotlivce. Tak proč se bát zrovna eReceptu?
| Často se na podporu prosazení e‑preskripce používají argumenty, že systém by měl ušetřit významné finanční prostředky. Myslíte, že tyto předpoklady jsou reálné, nebo jsou to jen teorie, které v praxi nemohou být naplněny?
Pokud bychom se přenesli v čase do doby, kdy systém bude funkční bez zbytečných uživatelských omezení, lékaři díky němu snadno zjistí lékové záznamy pacienta, které upozorní na potenciálně nebezpečné lékové interakce, na duplicity či multiplicity v preskripci, tak si myslím, že by systém byl schopen generovat i úspory, byť asi ne v tak velkém měřítku, jako bývá dnes někdy prezentováno. Hlavní výhodou systému by nebyl jeho potenciál k finančním úsporám. Klíčová by byla bezpečnostní role systému, tedy prevence poškození pacienta v důsledku nevhodných lékových interakcí.
Z toho také vyplývá, že rozhodující funkcionalitou systému je přístupný lékový záznam pacienta, tedy přehled aktuálně předepsaných léčivých přípravků v nějaké předem definované a strukturované podobě. K tomu se následně dají přidávat další nadstavbové funkce. Tento záznam by měl být snadno přístupný pro všechny účastníky systému, tedy lékaře, lékárníky i pacienty. Podmínkou by byla jednoznačná identifikace toho, kdo do systému přistupoval a k jakým datům. Zbývá dořešit, jak co nejlépe tento přístup zabezpečit a popř. cíleně omezit.
Lékové interakce však mohou být jen jednou ze základních nadstavbových funkcí. Po propojení s nemocničními či ambulantními systémy by mohl být předepsaný lék konfrontován se základními klinickými parametry pacienta, ať už je to známá alergie, nedostatečná funkce ledvin nebo jater nebo nadváha či obezita, na základě kterých by mohl být zvolen vhodnější lék či změněno dávkování. Do budoucna se dá také uvažovat o tom, že lékový záznam by obsahoval i volně prodejné léky či medikaci podanou v rámci hospitalizace. Další supernadstavbovou funkcí by mohly být nejrůznější druhy farmakoekonomických a jiných analýz.
| A jaké jsou obecné výhody používání elektronické preskripce, pokud pomineme prevenci lékových interakcí a další medicínské dopady?
Ty se do jisté míry shodují s výhodami zavádění eHealth obecně. Člověk je kreativní tvor, který si dovede poradit v různých nepředvídatelných situacích, ale na rozdíl od počítačů neumí systematicky pracovat s velkým množstvím dat a mechanicky vyhodnocovat velké množství informací. K tomu jsou počítače ideální, navíc dělají nastavenou funkci metodicky stále dokola a nikdy na ni nezapomenou. Při množství léků, které jsou k dispozici na trhu, nemají lékaři šanci zapamatovat si je všechny a znát jejich vzájemné interakce. Je známým faktem, že většina omylů v medicíně vzniká v důsledku přehlédnutí, nepozornosti, podcenění či špatného vyhodnocení situace. Většinu těchto omylů však počítače dokáží odhalit, pokud mají k dispozici správné nástroje.
| Něco jste již naznačil, ale můžete naopak shrnout, jaká hlavní rizika by ze zavedení systému elektronické preskripce vyplývala?
Kromě již zmíněného rizika zneužití zdravotnických dat pacientů můžeme uvažovat i o zneužití lékových dat, která umožní sledovat objemy předepsaných léků v určité nemocnici či regionu nebo preskripční zvyklosti lékařů pro obchodní účely. Ale znovu – takříkajíc všechny informace už v současné době v systému jsou, i když ne na jednom místě. A pokud by někdo chtěl tyto informace zneužít, může tak učinit i dnes, i když musí nejprve pro něj zajímavá data zkompletovat a doplnit.
| Rizika jsou ale i na straně samotného systému, hlavně v případě jeho výpadku. Co by taková situace znamenala pro pacienty?
Představme si, že již máme funkční systém elektronické preskripce, který by náhle zkolaboval. Znamenalo by to, že bychom byli ve stejné situaci jako dnes, kdy žádný funkční systém neexistuje. Jediná výjimka by se týkala těch pacientů, kteří by právě šli od lékaře s elektronickým receptem do lékárny. Ale i těm by se zřejmě problém vyhnul, protože pro tyto případy bychom měli mít systém zálohovaný, aby nedošlo k podobným výpadkům jako například u registru aut.
Jisté riziko je i v samotné záměně dat, i když podle mého soudu velmi teoretické. Můžeme použít paralelu s elektronickým bankovnictvím. Jak často se stává, že někomu z ničeho nic omylem přibude nebo ubude na kontě několik milionů, a nemyslím tím útok hackera? Pokud se takové záměny nedějí v elektronickém bankovnictví, proč by tomu mělo být jinak u lékových záznamů? Záměrné útoky na systém lze samozřejmě řešit cílenou ochranou podobnou jako u jiných citlivých IT aplikací.
| A nebyl by problém s vzájemnou komunikací velkého počtu různých nemocničních, ambulantních a lékárenských systémů či IT aplikací?
Do jisté míry by tomu tak mohlo být. Uvědomme si, že máme více než třicet různých výrobců a dodavatelů ambulantních, nemocničních a lékárenských softwarů, které by měly být schopné se spolu domluvit. Problémům v této oblasti se dá ovšem zabránit tím, že bude stanoveno jednoznačné datové rozhraní a parametry pro přístup, podobně jako je to například u e‑mailů. Dnes je možné přistupovat k e‑mailovému účtu přes webové rozhraní z různých platforem, které mají různé softwarové vybavení, a nikoho to nepřekvapí. V komerční sféře tyto problémy nenastávají nebo se řeší poměrně rychle, státní správa s tím má kupodivu značné problémy.
| Vraťme se k finanční stránce projektu elektronické preskripce. Kritici poukazují na problémy spojené se strukturou dosud proplacených výdajů na stávající Centrální úložiště elektronických receptů, sporná je i celková výše investic nutných pro plošné spuštění elektronické preskripce. Když si k tomu přidáme negativní zkušenosti z jiných IT projektů organizovaných státní správou, nepřekvapí, že se z eReceptu stává i politicky dosti ožehavý projekt. Stále se při úvahách o celkových nákladech systému pohybujeme pouze v hrubých odhadech, které mohou být velmi zkreslující. V rámci své disertační práce jste se jako jeden z mála seriózně zabýval vyčíslením celkových nákladů na systém eRecept. Co jste zjistil?
Předem nutno zopakovat, že před spuštěním projektu nebyla provedena jakákoliv ekonomická studie, a proto oficiální údaje o předpokládaných nákladech na eRecept neexistují. Jediné oficiální údaje o aktuálních nákladech pocházejí ze SÚKL. Ten většinou uvádí, že dosud bylo na spuštění eReceptu proinvestováno něco kolem 100 milionů korun, nicméně podle mých výpočtů, které jsem loni publikoval v odborném tisku a v rámci mé disertační práce, převyšují reálné náklady částku 800 milionů korun.
| Tato částka se ovšem s údaji prezentovanými SÚKL dost rozchází. Jak jste k této sumě dospěl?
Tato suma zahrnuje oficiálně udávané náklady na Centrální úložiště elektronických receptů, ovšem včetně systému LEK‑13. Tyto sumy však ilustrují pouze dosud proinvestované finanční prostředky a nezohledňují celkové náklady na zavedení a provozování systému eRecept během dalších let. Řekněme, že bychom uvažovali desetiletý životní cyklus projektu, pak extrapolací na celý životní cyklus získáváme další část nákladů, které jsou se systémem spojeny.
Ačkoliv tuto skutečnost SÚKL nikde nezdůrazňuje, eRecept není úplný systém, ale spíše datové rozhraní. Koncové aplikace jsou tak plně v režii jednotlivých uživatelů, respektive dodavatelů jejich informačních systémů. To ovšem znamená, že jednotliví dodavatelé byli nuceni na vlastní náklady upravit své informační systémy, aby zahrnovaly možnost komunikace s Centrálním úložištěm elektronických receptů a zajistily tak funkčnost eReceptu. I tuto nucenou investici, která se odhaduje na téměř 270 milionů korun, je jednoznačně nutné zahrnout mezi náklady na pořízení systému eRecept – o to více, že se jedná o náklad soukromých subjektů.
| Podle vaší analýzy by nezanedbatelné náklady s využíváním eReceptu nesli i samotní uživatelé systému, tedy, lékaři a farmaceuti. V čem by spočívaly?
Pro použití eReceptu je nezbytně nutný osobní elektronický podpis. Tento podpis je vydáván příslušnou certifikační agenturou a musí si jej pořídit každý zdravotnický pracovník, který by chtěl vystavit či přijmout elektronický recept. Podle odhadů by se cena za vystavení elektronického osobního podpisu pro jednoho uživatele na rok mohla pohybovat kolem částky 300 korun. Pokud vztáhneme cenu elektronického podpisu k počtu všech příslušných zdravotnických pracovníků a zohledníme desetiletý životní cyklus systému, je zřejmé, že náklady na elektronické podpisy převýší částku 150 milionů korun.
Při zahrnutí všech výše uvedených položek převyšují celkové náklady na životní cyklus systému eRecept 800 milionů korun. Alarmující je také, že více než 50 % všech nákladů tohoto systému nepochází ze státního rozpočtu, ale z rozpočtu zdravotního pojištění či dokonce z prostředků soukromých subjektů.
| Celkové náklady, které jste vyčíslil, jsou opravdu enormní. Zdají se vám přiměřené?
Při úvahách o celkových nákladech eReceptu není možné nepřirovnat tento projekt k jiným IT projektům realizovaným nebo spolufinancovaným veřejnou správou, ať už jde o sKarty, Opencard, registry motorových vozidel nebo IZIP. Jejich společným jmenovatelem jsou enormní investice pro jejich pořízení nebo zprovoznění. Nemůžeme se neptat, co na těch IT aplikacích stojí tolik peněz. Ukažte mi jedinou soukromou banku, jejíž kartový systém by stál miliardu. Dovolím si tvrdit, že kdyby se jakákoli banka chovala při zavádění elektronizace podobně jako stát, tak musí nutně velmi brzy zkrachovat. Většina aplikací, o kterých se uvažuje, že by se zavedly v rámci eHealth, je už dávno vyzkoušená a fungují v jiných oblastech, například v rámci elektronického bankovnictví. Jak je možné, že to bez problémů funguje, ale u IT projektů realizovaných státní správou narážíme na tolik problémů? Pokud se vrátím k eReceptu, jedním z vysvětlení je skutečnost, že projektu nepředcházela žádná přípravná fáze, žádná studie proveditelnosti, žádná cost‑benefit analýza.
| Můžete odhadnout, kolik by vybudování funkčního systému elektronické preskripce mohlo reálně stát, pokud by se realizoval v soukromé sféře?
Jak z tohoto pohledu komentovat výdaje, které SÚKL v souvislosti s vybudováním Centrálního úložiště elektronických receptů dosud přiznal? Asi nikdo vám nedokáže říci, co by takovýto systém stál soukromníka. Ale vezměte si, kolik internetových aplikací bylo vytvořeno v podstatě „na koleně“ dvěma či deseti nadšenci v garáži. Naopak státní správa má neuvěřitelný talent protočit stovky milionů, přičemž výsledek je ještě mnohem méně hmatatelný než práce těch dvou nadšenců ze Silicon Valley.
Základním problémem u eReceptu je, že se předem neřeklo, kolik to bude stát, nedefinovalo se přesně, co by systém měl dělat a umět, nezhodnotilo se, zda je to reálné a popř. za jakých podmínek. Další spornou věcí je průběh samotných výběrových řízení na dodavatele Centrálního úložiště elektronických receptů. Povinnost zřídit toto úložiště ukládal lékovému ústavu zákon č. 378/2007 Sb., který začal platit k 31. 12. 2007, nicméně centrální úložiště mělo být zřízeno nejpozději do 31. 12. 2008. Jednotlivá výběrová řízení (pozn. red.: VZ10/2008 až VZ12/2008) však SÚKL vypsal teprve v druhé polovině roku 2008. Všechna tato řízení se vyznačovala velmi krátkou lhůtou mezi vypsáním a vyhodnocením a ještě kratší lhůtou určenou k odevzdání hotového díla. Za zmínku stojí také fakt, že v rámci dvou výběrových řízení se přihlásil vždy pouze jediný zájemce, v jednom případě (pozn. red.: VZ10/2008) byli zájemci dva, ovšem jeden z nich byl vyloučen pro nesplnění zadávacích kritérií. Následně, po zveřejnění vítězů výběrových řízení, musely tyto firmy dodat centrální úložiště, přesněji softwarové aplikace, které umožňovaly jeho chod, během několika málo měsíců, aby se stihl zákonný termín konec roku 2008. Zarážející je také, že za vývoj tohoto software a jeho provoz bylo vyplaceno, podle údajů na stránkách SÚKL, více než 80 milionů korun. Můžeme se pouze ptát, jestli za takových podmínek mohlo vzniknout něco kvalitního.
| Následně ale SÚKL musel ještě řešit problémy s Úřadem pro ochranu osobních údajů…
To je jen dokladem toho, jak nekvalitní byla příprava před spuštěním projektu. Na podobná rizika by studie proveditelnosti určitě upozornila, pokud by ji SÚKL udělal. A ani do současnosti nebyl ze strany ministerstva či SÚKL učiněn žádný pokus o identifikaci skutečných příčin, proč není eRecept používán a proč se nerozvíjí.
Není bez zajímavosti, že samotný systém eRecept SÚKL představil teprve v květnu 2011. Jak již bylo řečeno, dodnes však má jen zcela základní funkce, tj. poslání receptu elektronickou cestou do datového úložiště a možnost sdělit pacientovi pouze kód, s nímž odchází do lékárny, místo předání papírového blanketu, který lékař buď vypíše ručně, nebo vytiskne na tiskárně. Další, rozšířené funkce v provozu nejsou.
| Pokud přijmeme myšlenku, že elektronická preskripce je užitečná jak pro lékaře, tak pro pacienty, máme‑li funkční systém, jak by se mělo postupovat, abychom k němu dospěli? Po zpracování studie proveditelnosti a cost‑benefit analýzy bude jednou z klíčových věcí správně definovat požadavky, které by budoucí dodavatelé měli splnit. Jak se vyhnout tomu, aby v budoucnu systém eRecept nebyl vnímán jako další „černá díra“?
Podle mého je klíčem k úsporám při vývoji systému podrobná definice, co má systém umět a jaké má mít funkce, včetně různých ochranných prvků, než se začne vyvíjet. Čím přesněji se to definuje, tím lépe. Stručně řečeno, měli bychom se soustředit na podrobnou specifikaci toho, co má systém umět a dělat, a nikoli na to, jak má vypadat. Je na dodavatelích, kteří se účastní výběrového řízení, ať navrhnou konkrétní technické řešení. Tím se zajistí, že zakázka nebude „ušita“ někomu na míru, a větší množství zájemců povede ke snížení konečné ceny. Krásné na tom je, že na konci při hodnocení dodávky můžeme říci „chtěli jsme, aby systém uměl to a to a měl takové a takové funkce. Bohužel systém tyto požadavky zcela nesplňuje, takže zatím nebudeme nic platit a počkáme, až to předěláte podle předem dané specifikace…“ A obava, že na takové podmínky by IT firmy nepřistoupily, není podle mého názoru také namístě, protože raději přijmou i méně lukrativní zakázku než nemít žádnou zakázku.
Nebál bych se pilotně začít s malou zakázkou v menším měřítku, například v regionu Praha. Následně se po doladění může systém spustit ve větším měřítku s tím, že softwarové aplikace by měly zvládat větší množství účastníků a kapacitní rozšíření databází by už nemělo představovat exponenciální nárůst nákladů, ale maximálně lineární (většinou ani to ne). Hrubou představu o možných úsporách si můžeme udělat na příkladu elektronické preskripce, která funguje v rámci Všeobecné fakultní nemocnice v Praze a umí přibližně to samé, co eRecept v rámci ČR. Celý tento systém zvládli připravit v rámci své pracovní doby dva pracovníci IT oddělení nemocnice s minimálními náklady na dodatečné hardwarové a softwarové vybavení, takže potřebné investice byly maximálně ve stovkách tisíc – například v oblasti hardwaru se přikoupilo pouze pár laserových tiskáren, servery se nerozšiřovaly vůbec. Rozhodně se nejednalo o desítky až stovky milionů jako u eReceptu.
MUDr. Jan Bruthans, Ph.D., je sekundární lékař a odborný asistent na Klinice anesteziologie, resuscitace a intenzivní medicíny 1. LF UK a VFN Praha. V rámci postgraduálního studia hospodářské politiky na Vysoké škole ekonomické se zabýval ekonomikou eHealth a vyčíslil náklady a přínosy eReceptu a ePACS v ČR.
Zdroj: Medical Tribune