Telemedicína před evropskou bránou

Kdy se z telemediciální platformy stane systém EHR a co to znamená pro poskytovatele zdravotních a sociálních služeb

Nařízení o Evropském prostoru pro zdravotní údaje nevchází do telemedicíny jedněmi dveřmi. Přichází přes nová práva pacientů, přes povinnosti poskytovatelů a držitelů zdravotních údajů a také přes nový výrobkový režim, který dokáže z pacientského portálu, integrační brány nebo telemonitorovacího modulu udělat regulovaný výrobek. Poprvé v historii EU. I když mu dodavatel pořád říká komunikační platforma.

Most, který se staví nad nedostavěnou tratí

Kdo dnes pořizuje telemedicínskou platformu, staví most ve chvíli, kdy se ještě dopočítává rozchod kolejí, které po něm povedou. To vede řadu lidí k pocitu klidu (anebo k argumentu, že je ještě brzy cokoli řešit), když se vlastně neví. ono je to ale celé trošku složitější. Most musí unést dnešní provoz. Zároveň by neměl za tři roky končit ve svahu jen proto, že dodavatel považoval evropskou regulaci za starost velkých nemocnic.

Nařízení Evropského parlamentu a Rady (EU) 2025/327 o Evropském prostoru pro zdravotní údaje, kterému se všude říká zkratkou EHDS, bylo přijato 11. února 2025, vyšlo v Úředním věstníku 5. března a v platnost vstoupilo o dvacet dní později, 26. března 2025. Obecně se použije od 26. března 2027. Technické podrobnosti se ale teprve skládají. Evropská komise připravuje prováděcí akty, vznikají implementační příručky, testovací prostředí a evropské profily interoperability. Stavba tedy zdaleka není hotová. Její obrysy jsou už ale dost zřetelné na to, aby se promítly do vývoje, do nákupu a hlavně do smluv, které se podepisují dnes.

Dodavatel nemůže v srpnu 2026 poctivě tvrdit, že má EHDS vyřešené. Může ale (a podle by měl) doložit, že ví, do které části regulace jeho výrobek spadá, kdo nese odpovědnost výrobce, jaké údaje systém zpracovává a co udělá, až budou evropské specifikace hotové. Jinými slovy, je čas EHDS prozkoumat a udělat si produktovou roadmapu v návaznosti na něj. Právě rozdíl mezi těmito dvěma postoji dnes odděluje připravenost od obchodního slibu.

Tři větve jednoho nařízení

O EHDS se mluví hlavně jako o evropském prostoru, který má otevřít zdravotní data výzkumu, inovacím a tvorbě zdravotní politiky. To je ale jen jedna třetina obrazu.

První větev nařízení upravuje primární využití zdravotních údajů, tedy jejich používání přímo při péči. Zavádí nová práva pacientů, přeshraniční dostupnost vybraných údajů a požadavky na národní přístupové služby pro pacienty i pro zdravotnické pracovníky. Druhá větev je výrobkovou regulací systémů EHR a míří na výrobce, dovozce, distributory a další hospodářské subjekty, které tyto systémy uvádějí na evropský trh nebo do provozu. Jejím těžištěm je interoperabilita, provozní záznamy o přístupech, technická dokumentace, posouzení shody, označení CE a dozor nad trhem. Třetí větev se týká sekundárního využití. Stanoví povinnosti držitelů zdravotních údajů, pravidla pro zpřístupňování dat a zřízení národních orgánů pro přístup ke zdravotním údajům, kterým se říká HDAB.

Jeden subjekt může stát ve všech třech větvích najednou. Nemocnice je poskytovatelem péče, kupujícím systému EHR i držitelem údajů pro sekundární využití. Dodavatel telemedicínské platformy může být výrobcem systému EHR, zpracovatelem osobních údajů pro svého zákazníka a současně držitelem vlastních neosobních dat, která vznikají provozem výrobku. Nerozhoduje název společnosti ani produktu. Rozhodují konkrétní funkce, právní role a skutečný tok údajů.

Tři data, která patří do smluv uzavíraných dnes

Do 26. března 2027 má Evropská komise přijmout klíčové prováděcí akty, mimo jiné technické specifikace evropského výměnného formátu a společné specifikace k základním požadavkům. Členské státy mají do stejného dne zřídit orgány pro digitální zdravotnictví a určit národní kontaktní místa. Tímtéž dnem se nařízení začíná obecně používat. Tedy, pokud nevystoupíme z EU, ano, bude se to týkat i České republiky.

Od 26. března 2029 se rozbíhá první skupina prioritních kategorií, tedy pacientský souhrn, elektronický předpis a záznam o výdeji léčiv. Začne platit většina pravidel pro primární využití i pro systémy EHR a k témuž dni dopadne také podstatná část pravidel pro sekundární využití.

Od 26. března 2031 se režim rozšíří na druhou skupinu, tedy na obrazovou dokumentaci a související zprávy, na laboratorní a jiné diagnostické výsledky a na propouštěcí zprávy. Ke stejnému datu se sekundární využití rozšíří i na složitější kategorie, například na genetická data, a doběhne přechodná lhůta pro systémy uvedené do provozu dříve.

Taková typizovaná pětiletá smlouva s dodavatelem podepsaná v roce 2026 projde všemi třemi milníky. Otázka EHDS proto nemíří do vzdálené budoucnosti. Míří na to, kdo zaplatí přestavbu, jak rychle ji dodavatel provede a co se stane, když ji nestihne.

EHR není totéž co zdravotnická dokumentace

Většina nedorozumění vzniká hned u pojmů. Anglické electronic health record se překládá jako elektronický zdravotní záznam. V běžné řeči se ale plete se zdravotnickou dokumentací, s pacientskou kartou i s celým nemocničním informačním systémem. Právně jde o různé věci.

EHDS chápe elektronický zdravotní záznam jako soubor elektronických zdravotních údajů o konkrétní osobě, které byly shromážděny ve zdravotním systému a zpracovávají se pro účely poskytování péče. Systém EHR je proti tomu výrobek. Software nebo spojení hardwaru a softwaru, které s prioritními osobními elektronickými zdravotními údaji umí alespoň jednu ze sedmi věcí: ukládat je, zprostředkovat, vyvézt, dovézt, převést, upravit nebo zobrazit. K tomu musí být výrobcem určen k použití poskytovatelem při péči o pacienta nebo pacientem při přístupu k vlastním údajům. Nemusí umět všech sedm operací. Ke vstupu do režimu stačí jediná. Definice je záměrně široká a míří i na systémy, které data pouze dodávají do systémů jiných.

Systémem EHR proto může být prostý pacientský portál, který nedělá nic jiného, než že zobrazí laboratorní výsledek. Může jím být převodník, který překlápí starší dokumenty do evropského výměnného formátu. Nemusí vést úplnou zdravotnickou dokumentaci a nemusí být hlavním informačním systémem poskytovatele. Evropská komise přímo uvádí pacientský portál i převodník starších dat jako učebnicové příklady toho, co do působnosti nařízení spadá.

Český zákon o zdravotních službách rozumí zdravotnickou dokumentací soubor informací, které poskytovatel vede, zpracovává a uchovává kvůli poskytování zdravotních služeb konkrétnímu pacientovi. Je to právní a klinický záznam poskytovatele a poskytovatel za něj ručí. Za jeho řádnost, pravdivost, úplnost, průkaznost, autorizaci, opravy, ochranu i uchování. Současná úprava připouští podobu listinnou, elektronickou i kombinovanou. U elektronických záznamů žádá identifikaci záznamu i zapisující osoby a zachování historie oprav. Informační systém musí umět dokumentaci převést do výstupního datového formátu podle standardu elektronického zdravotnictví.

Rozdíl se dá říct jednou větou. Zdravotnická dokumentace je povinnost a záznam poskytovatele. Systém EHR je regulatorní zařazení výrobku podle jeho funkcí, účelu a zpracovávaných dat.

Telemedicínský portál tedy může být systémem EHR, aniž by byl místem, kde poskytovatel vede svou úplnou a autoritativní dokumentaci. A obráceně, poskytovatel může mít rozsáhlou elektronickou dokumentaci, jejíž starší vnitřní části samy o sobě nesplňují požadavky na harmonizované komponenty nově uváděného systému EHR.

Co s tím dělá česká novela

Novela zákona č. 325/2021 Sb., o elektronizaci zdravotnictví, prochází v létě 2026 vnějším připomínkovým řízením a míří na jednání vlády. Vedle povinných elektronických žádanek, od července 2027 na zobrazovací vyšetření, rehabilitaci a konsilia a o půl roku později také na vyšetření laboratorní, počítá s přechodem k povinnému vedení zdravotnické dokumentace v elektronické podobě od roku 2029. Stále jde o návrh a jeho znění se v legislativním procesu ještě může pohnout. Připomínková místa nemlčela. Česká lékařská komora, Česká stomatologická komora i Hospodářská komora žádají přechodné období bez sankcí a stomatologové navrhují odložit povinnou elektronickou dokumentaci až na 26. března 2031.

Pro naše téma je ale podstatné něco jiného. Návrh zavádí do českého práva pojem elektronických zdravotních záznamů odkazem na definici EHDS a váže na něj přímo evropská data. Od 26. března 2029 by měl poskytovatel povinně vést pacientský souhrn jako elektronický zdravotní záznam a zajistit jeho vytváření, přijímání, ukládání, zpřístupňování a zobrazování ve standardizovaném formátu. Od 26. března 2031 se povinnost rozšíří na další kategorie včetně lékařských zpráv, laboratorních a diagnostických výsledků a propouštěcích zpráv. Starší dokumentace se podle návrhu zpětně převádět nemá.

Důvodová zpráva pracuje s praktickým rozlišením dvou vrstev. Zdravotnická dokumentace zůstává základním vnitřním záznamem konkrétního poskytovatele. Elektronické zdravotní záznamy jsou standardizované části dokumentace nebo odvozené výstupy určené k tomu, aby zdi poskytovatele opustily.

Pro českou architekturu je to rozlišení užitečné. Nedá se ale použít jako klička, kterou by se přímo použitelná evropská definice systému EHR zúžila. O tom, jestli je konkrétní telemedicínský výrobek systémem EHR, rozhoduje jeho určený účel, zpracovávané prioritní kategorie a funkce. Ne to, jak mu říká český poskytovatel ve své vnitřní směrnici.

Kdy se z platformy stane systém EHR

U telemedicíny nerozhoduje, jestli produkt umí videohovor. Rozhoduje všechno, co se děje před hovorem, během něj a hlavně po něm. V praxi se dají rozlišit čtyři situace.

Pouhý komunikační kanál. Platforma zajistí objednání, elektronickou čekárnu, ověření identity a zabezpečené obrazové nebo zvukové spojení. Klinické údaje během hovoru jen protečou. Nic se neukládá a nic se nezobrazuje z pacientského souhrnu, z předpisů, z laboratoří, ze snímků ani z propouštěcích zpráv. Záznam z konzultace vzniká výhradně v ambulantním nebo nemocničním informačním systému. Takové řešení systémem EHR zpravidla nebude. Pořád na ně ovšem dopadají české požadavky na poskytování telemedicínských služeb, na ochranu osobních údajů, na ověření identity, na kybernetickou bezpečnost, na dostupnost služby a na řádný přenos výsledku konzultace do zdravotnické dokumentace. Tedy i co co říká naše Vyhláška 30/2025 a navazující Technický standard telemedicínských zdravotních služeb dle zákona 325/2021 Sb.

Pacientský portál nebo integrační brána. Platforma zpřístupní pacientovi laboratorní výsledky, elektronické předpisy, propouštěcí zprávy nebo obrazovou dokumentaci. Případně je z jiného systému přijme, převede a pošle dál. Tady už jsme velmi pravděpodobně uvnitř definice. Nehraje roli, že portál sám nestanoví diagnózu ani nevede úplnou dokumentaci. Zobrazení nebo převod jediné prioritní kategorie stačí. Evropská komise pacientské portály zpřístupňující prioritní údaje mezi příklady své působnosti výslovně řadí.

Telemonitorovací a klinická platforma. Systém přijímá domácí měření, údaje z přístrojů a odpovědi z dotazníků a spojuje je s laboratorním výsledkem, s propouštěcí zprávou a s léčebným plánem. Zdravotník podle nich upravuje léčbu nebo rozhoduje o dalším postupu. U takového výrobku se právní režimy překrývají jako vrstvy nátěru. Jedna část může být systémem EHR, druhá zdravotnickým prostředkem, třetí vysoce rizikovým systémem umělé inteligence. Označení CE získané podle nařízení o zdravotnických prostředcích samo o sobě o splnění EHDS neříká nic. Každá část výrobku musí vyhovět tomu rámci, který na ni dopadá.

Aplikace pro zdravý životní styl. Sledování spánku, pohybu, kondice nebo jídelníčku mimo poskytování zdravotní péče systémem EHR zpravidla není. Jakmile ale výrobce dobrovolně prohlásí, že je aplikace interoperabilní se systémy EHR, vstupuje do zvláštního režimu. Musí splnit společné specifikace i příslušné základní požadavky, nechat uživatele řídit rozsah a četnost přenosu a zapsat aplikaci do evropské databáze. Tenhle dobrovolný štítek interoperability se nesmí plést s povinným režimem systémů EHR.

A ještě jedna věc, kterou v poptávkách které občas vidím bývá opomenuta. Zařazení se neuděluje doživotně. Platforma, která je dnes videokomunikačním nástrojem, může po přidání pacientského portálu nebo laboratorních výsledků vstoupit do režimu systému EHR během jednoho čtvrtletí. Znovu se posuzuje při změně určeného účelu, po přidání nového algoritmu, po hlubší integraci, při uvedení výrobku pod cizí značkou a při každé podstatné změně funkcí a rizik. Proto se neklasifikuje celý produkt jednou větou. Klasifikují se moduly, datové toky a varianty nasazení.

Kudy to jde do sociálních služeb

U poskytovatelů sociálních služeb je potřeba oddělit dvě části nařízení, protože každá dopadá jinam.

Výrobkový režim systémů EHR se váže na systémy určené k použití při poskytování zdravotní péče nebo pacientem při přístupu k jeho zdravotním údajům. Běžný systém sociální agendy, vykazování služby nebo plánování osobní podpory se proto systémem EHR nestane jen tím, že obsahuje citlivé údaje. Jiné je to ve chvíli, kdy poskytovatel sociálních služeb současně poskytuje zdravotní nebo ošetřovatelskou péči a jeho modul pracuje s prioritními zdravotními údaji. Typicky "zdravotní modul" pobytového zařízení, který přijímá propouštěcí zprávy, zobrazuje laboratorní výsledky, pracuje s pacientským souhrnem nebo předává strukturované zdravotní údaje lékaři.

U sekundárního využití je záběr širší. Definice držitele zdravotních údajů zahrnuje i subjekty působící v oblasti péče, pokud jako správci nebo společní správci zpracovávají osobní elektronické zdravotní údaje pro poskytování zdravotní nebo jiné péče. Samotné působení v sociálních službách ovšem automaticky nestačí. Rozhoduje, jaká data organizace skutečně ovládá a v jakém právním postavení je zpracovává.

Dodavatel, který osobní zdravotní údaje zpracovává jen podle pokynů nemocnice nebo jiného poskytovatele, se pro tato data držitelem nestává jen proto, že provozuje technickou platformu. Držitelem je zpravidla zákazník v postavení správce. Jinak to může být u neosobních provozních dat, u vlastních datových sad a u údajů, jejichž dostupnost dodavatel opravdu ovládá.

Nařízení navíc (naštěstí!) pamatuje na výjimku pro fyzické osoby a mikropodniky, pokud členský stát jejich povinnosti vnitrostátním právem nerozšíří. Mikropodnikem se pro tento účel rozumí podnik s méně než deseti zaměstnanci a s ročním obratem nebo bilanční sumou do dvou milionů eur. Výjimka se týká povinnosti zpřístupňovat data pro sekundární využití. Ostatní povinnosti poskytovatele neruší. Mluvíme tedy o drtivé většině běžných ordinací. Ufff.

Certifikace, která žádnou certifikací není

Základní evropský režim nestojí na tom, že by každý systém EHR dostal certifikát od nezávislého oznámeného subjektu, jak to známe u některých tříd zdravotnických prostředků. Posouzení provádí sám výrobce. Musí ovšem projít předepsanými automatizovanými zkouškami v evropském digitálním testovacím prostředí a výsledek doložit technickou dokumentací. Před uvedením systému na trh nebo do provozu bude muset zajistit dvě harmonizované softwarové komponenty, úspěšně je otestovat, vypracovat a udržovat technickou dokumentaci, dodat informační list a návod, podepsat EU prohlášení o shodě, připojit označení CE, zaregistrovat systém v evropské databázi a mít zavedené postupy pro stížnosti, neshody, nápravná opatření, stažení i aktualizaci výrobku. Protokol z automatizovaných testů se stane součástí technické dokumentace. Systém, který zkouškami neprojde, se na trh dostat nemá.

Označení CE v tomto režimu není medaile za kvalitu telemedicínské služby. Potvrzuje shodu s použitelnými právními požadavky, a víc od něj čekat nelze. Neříká, jestli je dobře navržená cesta pacienta, jestli je platforma použitelná pro člověka se zdravotním postižením, jak rychle reaguje podpora a jestli je klinický provoz bezpečně zorganizovaný.

Dvě komponenty, o které tu jde

Nařízení harmonizuje dvě části systému EHR a vyplatí se vědět, co se u nich bude zkoumat.

Komponenta interoperability musí umět dovézt a vyvézt prioritní údaje v evropském výměnném formátu EEHRxF. Systémy určené k ukládání, zprostředkování nebo zpřístupnění údajů musí podporovat jejich příjem a přístup v tomto formátu a nesmějí stavět nepřiměřené technické překážky oprávněnému přístupu, sdílení, použití, vývozu nebo změně dodavatele. Neznamená to, že by EEHRxF musel být vnitřním databázovým formátem celého systému. Výrobce si svůj datový model může samozřejmě nechat. Na hranici systému ale musí umět údaje spolehlivě převést tak, aby se cestou neztratil jejich význam, původ, vazby ani nezbytná metadata. Toto je bod podstatný i pro následnou českou diskuzi i povinném EZD, kde se tyto pojmy snadno (a rády a k mé frustraci) zaměňují. Interoperabilita nebyla nikdy o intramurálním ukládání (tady by měla být uplatněna metodika, dobrá praxe, nikoli povinnosti, ty by měly být v konceptuálním režimu, tedy čeho se má dosáhnout, nikoli jak), ale vzájemném zpřístupňování. Více jsem se tématu věnoval v článku https://www.umbrellateam.cz/post/povinná-elektronická-zdravotnická-dokumentace-v-české-republice-paměť-poskytovatele-a-řeč-výměny

Komponenta provozních záznamů musí zaznamenat, kdo, kdy a v jakém postavení se zdravotními údaji pracoval. Systém musí umět spolehlivě identifikovat a ověřit zdravotnické pracovníky a nabídnout nástroj pro kontrolu a vyhodnocení záznamů, případně umožnit napojení nástroje cizího. Nejde přitom jen o forenzní analýzu po incidentu. Záznamy mají obsloužit také právo pacienta zjistit, kdo se mu díval do zdravotních údajů (úmyslně používám tento termín, protože nejde jen o český právní prostor zdravotnické dokumentace, viz. například Sdílený zdravotní záznam, který není ze zákona součásti zdravotnické dokumentace). Tisíce řádků s adresami serverů a interními kódy na to nestačí. Výstup musí jít převést do informace, které porozumí správce systému, kontrolní orgán a v přiměřené podobě i sám pacient.

Starší systémy přitom nepůjdou vcelku logicky hromadně do sběrného dvoru... Nařízení nikde neříká, že by každý systém používaný před rokem 2029 musel být okamžitě nahrazen novým výrobkem s označením CE. Poskytovatelé ale budou muset zajistit vstup/výstup příslušných údajů v EEHRxF, ať už aktualizací systému, nebo důvěryhodnou převodní vrstvou. Převodník ovšem není neviditelná trubka. Komise ho sama uvádí jako příklad systému EHR. Je proto nutné vědět, kdo je jeho výrobcem, kdo odpovídá za mapování údajů, co se stane při změně evropské specifikace a jak se ověřuje, že převod nezměnil klinický význam. Stran převodníků a dalších integračních middleware panuje docela logická kontroverze zejména s ohledem na forenzní aspekt transformovaných údajů a chci se tématu věnovat v některém z příštích článků.

FHIR je začátek otázky, ne odpověď na ni

V nabídkách telemedicínských řešení se FHIR občas objevuje jako zaklínadlo. Dodavatel napíše, že má FHIR rozhraní, a považuje interoperabilitu za vyřízenou. To je ta lepší varianta (horší je, že ani o FHIR moc neví).

Tak jednoduché to není. Evropský výměnný formát EEHRxF má zahrnovat nejen technický formát zprávy, ale i harmonizované datové soubory, strukturu klinického obsahu, kódové systémy, povolené hodnoty, standardy a konkrétní profily. FHIR dává společný technický a modelovací základ. Neurčuje ale, které prvky jsou povinné, jaká terminologie se použije, jak se vyjádří původ údaje, jak se identifikuje pacient, jak se řeší oprava a jaké transakce musí systém zvládnout.

Dva systémy mohou oba tvrdit, že podporují FHIR, a přesto si nerozumět ani slovo. Jeden použije jinou verzi, druhý jiný profil, vlastní rozšíření, odlišné kódy nebo jinak chápanou povinnost prvku. Ano, pamětníci, na to jsme přišli už u dvojkové HL7...vzpomínáte? FHIR výměnu usnadňuje, standardizaci významu a použití dat sám o sobě nezaručí.

K srpnu 2026 je už vidět konkrétní technický směr. Portál HL7 Europe publikuje evropské základní a společné profily a samostatné implementační příručky pro laboratorní zprávy, elektronické předpisy a výdeje. Osobně na českém implementaci EHR standardů právě pracuji. Příručky pro pacientský souhrn, propouštěcí zprávy, obrazovou dokumentaci a evropské datové rozhraní jsou v různých fázích publikace, hlasování nebo ověřování. Pracuje se s FHIR R4 (u nás budeme vycházet prozatím ze čtyřky stejně jako zbytek EU) i R5. Z toho ovšem neplyne, že si výrobce vybere verzi, která se mu hodí, a tím má budoucí právní požadavek splněný. Závaznou podobu přinesou až prováděcí akty a na ně navázané konečné specifikace.

Návrh evropského rozhraní EU Health Data API, který vzešel ze spolupráce HL7 Europe a IHE-Europe a je zatím v hlasovací verzi, stojí na FHIR R4. Propojuje mimo jiné IHE MHD pro výměnu dokumentů, SMART Backend Services pro autorizaci mezi systémy a vzory International Patient Access spolu s profilem IHE QEDm pro čtení jednotlivých zdrojů. Sám přitom výslovně říká, že klinický obsah jednotlivých prioritních kategorií upravují samostatné implementační příručky. Není to hotový prováděcí předpis. Je to nejlepší dostupný odhad toho, jak bude vypadat.

Když tedy dodavatel řekne, že podporuje FHIR, mají následovat otázky. Kterou verzi. Které evropské a české implementační příručky. Které profily a povinná rozšíření. Jaké terminologie, číselníky a jednotky. Jak systém zachovává původ, autora, čas a verzi údaje. Čím validuje konkrétní datové instance. Co udělá, až se příručka změní a bude muset chvíli běžet ve dvou verzích současně. A čím to všechno předvede na skutečném scénáři, ne na snímku z prezentace.

Kde je Evropa v srpnu 2026

Evropská komise vydala 26. března 2026, přesně rok po vstupu nařízení v platnost, aktualizovanou sadu často kladených otázek. Sama upozorňuje, že jde o průběžně aktualizovaný dokument vyjadřující předběžné názory jejích útvarů. Závazný výklad to není a poslední slovo má Soudní dvůr Evropské unie (a asi ho nakonec mít bude jak vývoj sleduji). Přesto je to dnes nejpodrobnější praktické vodítko k rozsahu systémů EHR, ke vztahu k jiným předpisům a k rozdělení povinností.

Desátého června 2026 proběhl implementační dialog komisaře Olivéra Várhelyiho se zástupci průmyslu, výzkumu, pacientů a poskytovatelů. Dodavatelé řekli, že přípravy zahájili, a žádali, aby prováděcí akty přišly včas. Poskytovatelé mluvili o nedostatku lidí a peněz a o tom, že menší organizace zatím necítí naléhavost. Nepřipomíná vám to něco? Opakovaně zaznělo volání po jednotném evropském výkladu, po vyjasnění vztahu k dalším předpisům, po ochraně obchodního tajemství a po důrazu na informační bezpečnost.

Technická práce mezitím jde dál. Projekt Xt-EHR připravuje implementační příručky, technické specifikace a rámec posuzování shody pro primární využití. Společná akce TEHDAS2, na které se podílí devětadvacet zemí a která běží do konce roku 2026, vydává specifikace pro národní systémy sekundárního využití a pro jejich připojení k HealthData@EU. V polovině roku 2026 zveřejnila technický popis společných komponent a rozhraní, jimiž si mají členské státy vyměňovat popisy datových sad, žádosti, rozhodnutí a další procesní informace. Samotné zdravotní datové sady touto řídicí vrstvou proudit nemají.

Obraz je tedy dvojí. Nosné zdi stojí, část dveří, rozvodů a technických norem se ještě kreslí. Čekat na poslední prováděcí akt by bylo pozdě. Tvrdit, že je hotovo, je předčasné.

Co má dodavatel skutečně udělat

Příprava na EHDS není úkol pro jednoho programátora, který přidá rozhraní. Vysvětlete to svému šéfovi, až vám dá úkol znějící nějak "načti si to EHDS a dostaňte to tam". Já vím, vysvětlovat se to některým managerům bude špatně. EHDS totiž sahá do samotné architektury výrobku, do řízení změn, do smluv, do cenotvorby, do technické dokumentace a nakonec i do odpovědnosti vedení firmy.

Začíná se u klasifikace, a to po modulech. Dodavatel by měl mít písemné stanovisko, které u každého modulu popíše určený účel, skupiny uživatelů, zpracovávané datové kategorie, podporované operace, dopadající právní režimy a hlavně odůvodnění, proč modul systémem EHR je nebo není. Jedna věta pro celý produkt obvykle nestačí, protože videohovor, pacientský portál, telemonitorování, klinické rozhodování a administrace mohou mít pět různých regulatorních osudů.

Druhá věc, na které se dá uklouznout, je určení výrobce. Musí být zřejmé, která právnická osoba uvede výrobek na trh pod svým názvem, podepíše EU prohlášení o shodě, ponese technickou dokumentaci a bude jednat s orgány dozoru. Ti kteří lokalizují zahraniční produkt zejména ze země mimo EU vědí své. Pár takových vývojových projektů jsme osobně dozoroval a kolegům nezávidím. Pozornost si zaslouží výrobky prodávané pod značkou zákazníka, společný vývoj, skládání modulů od několika firem a případy, kdy si poskytovatel nechá dodat technické jádro a klinickou část si upraví sám. Za hranicí běžné konfigurace se dá převzít kus výrobní odpovědnosti, aniž si toho kdokoliv v tu chvíli všimne.

Pak přijde na řadu mapa prioritních údajů. Nestačí vědět, že systém pracuje s dokumenty. U pacientského souhrnu, elektronického předpisu, záznamu o výdeji, obrazové dokumentace, laboratorních výsledků a propouštěcích zpráv je třeba zvlášť určit, jestli je systém přijímá, zobrazuje, převádí, ukládá nebo předává. U každého údaje pak popsat zdroj, autoritu, formát, terminologii, opravy, verze, dobu uchování a místo, kde vzniká autoritativní klinický záznam.

Architektura by měla dovolit vyvíjet, aktualizovat a testovat komponentu interoperability a komponentu provozních záznamů samostatně. Přilepovat je na hotový systém někdy koncem roku 2028 bude drahé a skoro jistě to skončí u ručních převodů. Do stejné kapitoly patří řízení verzí standardů, protože evropské i národní implementační příručky se budou měnit. Dodavatel má vědět, jak novou verzi zavede, jak dlouho podrží starou, jak provede migraci, jak zvládne souběžný provoz obou a jak změnu zákazníkům oznámí. Validace se přitom nemá probouzet týden před posouzením shody. Vývojový řetězec by měl průběžně ověřovat profily, terminologie, povinné prvky, vazby, kódování, práci s chybami a skutečné výměnné scénáře.

U provozních záznamů se vyplatí rozlišit čtyři věci, které se v praxi slévají do jedné. Technické logy, bezpečnostní záznamy, auditní stopu klinických operací a výstup pro pacienta. Dodavatel má umět doložit, co se zaznamenává, kdo to smí číst, jak jsou záznamy chráněné proti změně a jak dlouho se uchovávají.

Zbývá regulatorní řízení změn a vlastní postavení pro sekundární využití. Každá významnější aktualizace se má posoudit i z hlediska změny určeného účelu, funkce, výkonu a rizika, protože podstatná změna může vyvolat nové posouzení shody. Komise za podstatnou považuje zejména takovou změnu původních funkcí či výkonu, se kterou hodnocení rizik nepočítalo a která současně mění povahu nebezpečí nebo riziko zvyšuje. A dodavatel má vědět, jestli je u jednotlivých dat pouze zpracovatelem, nebo také správcem, společným správcem či držitelem neosobních zdravotních údajů. Pokud může do role držitele vstoupit, potřebuje katalogizaci datových sad, správu metadat, postup pro předání dat a ochranu duševního vlastnictví a obchodního tajemství. Citlivá bývají i samotná metadata, protože prozradí ledacos o vnitřní struktuře databáze, o výzkumném zaměření i o obchodním modelu. S kolegy jsme si experimentálně s tématem hráli a výsledky byly překvapivě pesimistické z pohledu ochrany osobních údajů.

Osm otázek (pro PZS a PSS), které oddělí plán od přání

Obecné „budete připraveni na EHDS?“ nemá cenu. Kladně odpoví každý obchodník. Smysl mají otázky, na které se bez skutečné přípravy odpovídá špatně.

1.         Jaký je váš písemný závěr o postavení výrobku podle EHDS, rozdělený po jednotlivých modulech a řádně odůvodněný?

2.         Kdo je výrobcem? Která konkrétní právnická osoba podepíše EU prohlášení o shodě a systém zaregistruje?

3.         Které prioritní kategorie údajů systém zpracovává a co s nimi dělá? Ukládá je, zobrazuje, převádí, dováží, vyváží, zprostředkovává?

4.         Jaký je váš plán k rokům 2027, 2029 a 2031, kdo je jeho vlastníkem, jaké má milníky a jaký rozpočet?

5.         Co přesně znamená vaše podpora FHIR? Které verze, profily, implementační příručky, terminologie a validační nástroje? Viděli jste česká IG? Dokážete se v nich orientovat?

6.         Co obsahují vaše provozní záznamy a jak vypadá výstup pro pacienta, který chce vědět, kdo se mu díval do karty?

7.         Jaké konfigurace a úpravy smíme provádět, aniž se z nás stane výrobce nebo aniž vyvoláme nové posouzení shody?

8.         Kdo provede a kdo zaplatí povinné regulatorní aktualizace, v jaké lhůtě a co se stane, pokud nebudou včas k dispozici?

Dodavatel dnes nemusí znát detail, který Evropská komise ještě nestanovila. Musí ale umět rozlišit, co už je dané nařízením, co plyne z pracovních evropských specifikací, co je jeho vlastní technický předpoklad a co zatím neví nikdo.

Do poptávky se vyplatí vložit požadavek na stručnou kartu připravenosti, kterou dodavatel pravidelně aktualizuje. Toto je moje oblíbená praxe. Na jedné až dvou stranách má uvést regulatorní zařazení výrobku a jeho modulů, označení výrobce, zpracovávané prioritní kategorie, stav obou harmonizovaných komponent, používané standardy a implementační příručky, způsob a stav testování, plán k evropským milníkům a datum příští revize. Poctivou technickou dokumentaci to ale nenahradí. Je to čitelný výtah pro vedení organizace, nákup, právníka (který umí digitální zdravotnické právo, případně specialista na zdravotnické regulace, ten se v tématu často orientuje lépe), odborného garanta a architekta, tedy pro pět lidí, kteří spolu jinak mluví každý svým jazykem.

Ve smlouvě pak regulatorní změna nemá přijít jako překvapení. Dobré je vyhnout se dvěma krajnostem. První je mlhavý slib, že dodavatel zajistí soulad se všemi budoucími předpisy. Druhou je stav, kdy se z každé povinné změny stane příležitost k nové faktuře bez předem známého stropu. Budoucí změny se proto vyplatí rozdělit alespoň do tří skupin, totiž na změny nezbytné k tomu, aby se výrobek směl dál používat, na změny vyvolané novou evropskou nebo českou specifikací a na nové funkce objednané konkrétním zákazníkem. U každé skupiny pak určit odpovědnost, lhůtu, způsob ocenění, případný cenový strop a akceptační kritéria.

Smluvní příloha by měla popsat současné regulatorní zařazení jednotlivých modulů, označení výrobce a hranice jeho odpovědnosti, povinnost oznámit změnu regulatorního postavení, podporované prioritní kategorie, závazný plán aktualizací, import a export v dohodnutých profilech, kvalitu a použitelnost provozních záznamů, oznamování neshod a bezpečnostních incidentů, přechod na nové verze implementačních příruček, právo smlouvu ukončit při nesplnění povinných požadavků a úplný export včetně součinnosti při migraci. Zvláštní pozornost patří hranici výrobní odpovědnosti. Smlouva nemá mlhavě tvrdit, že jakékoliv nastavení provedené zákazníkem z něj dělá výrobce. Musí rozlišit běžnou konfiguraci, hlubokou úpravu a změnu určeného účelu.

Nekupujte prezentaci, nechte si předvést datovou cestu

A teď moje oblíbené téma (a heslo). Skutečná připravenost se pozná na demonstračním scénáři, ne na snímku s logy standardů.

Vypadá to zhruba takhle. Z jiného systému přijde pacientský souhrn v dohodnutém evropském nebo národním profilu. Platforma ho přiřadí ke správnému pacientovi (protože umí RID, samozřejmě pacient je již referencován ke Kmenovému registru pacientů, ne dle lokálního RČ), zachová původ, autora i čas a zpřístupní ho oprávněnému zdravotníkovi. Ten ho během telekonzultace použije třeba spolu s novým laboratorním výsledkem. Vznikne klinický záznam, který se přenese do autoritativní zdravotnické dokumentace (ideálně nikoli jen pracovní, ale skutečné EZD dle zákona tedy podporujíc i archivaci a skartaci). Pacient potom požádá o informaci, kdo mu do údajů nahlížel. Nakonec se v jednom údaji najde chyba, systém ji opraví, aniž přepíše historii, a celý případ se "vyveze" pro jiného poskytovatele třeba přes Akreditované afinitní domény.

Při předvádění se sleduje sedm věcí. Jestli se cestou neztratil klinický význam. Jestli je dohledatelný původ údajů. Jestli systém pozná rozdíl mezi údajem zadaným pacientem a údajem potvrzeným zdravotníkem. Jestli jsou opravy a změny verzované. Jestli je auditní výstup použitelný pro člověka. Jestli export obsahuje vazby, kódy a metadata. A jestli to všechno proběhlo bez ručního opisování a bez toho, aby někdo od dodavatele musel sáhnout přímo do databáze.

Druhý scénář má ověřit přechod na novou verzi implementační příručky. Třetí odchod od dodavatele a úplnost migračního výstupu. Ten třetí se předvádí nejhůř a řekne toho nejvíc.

Věty, po kterých je dobré zpozornět

Žádná z těchto vět dodavatele sama o sobě nevyřazuje. Každá ale musí otevřít konkrétní otázku, vyžádat si písemnou odpověď a skončit důkazem.

„EHDS se týká státu a velkých nemocnic, ne naší platformy.“

„Jsme provozováni v cloudu, takže nejsme systém EHR.“

„Podporujeme FHIR, tím je interoperabilita vyřešená.“

„Máme CE jako zdravotnický prostředek, takže EHDS je pokryté.“

„Exportujeme do PDF, data jsou tedy přenositelná.“

„Povinné legislativní aktualizace naceníme podle situace.“

„Migraci vyřešíme na konci smlouvy.“

„Výrobce zatím není určen, formálně to doplníme později.“

Dodavatel může být v procesu přípravy. Nesmí být v procesu popírání reality (to je mimochodem základní evoluční mechanismus, ale v tomto případě jej raději vynechme).

Rozhraní se nedá přilepit na hotovou platformu

Největší dopad EHDS nespočívá v nové evropské zkratce ani v dalším formuláři do zadávací dokumentace. Spočívá v tom, že interoperabilita přestane být volitelným příslušenstvím, které se doobjedná ve chvíli, kdy je potřeba propojit dva konkrétní systémy.

Vstoupí do architektury výrobku, do datového modelu, do terminologií, do správy verzí, do provozních záznamů, do testování i do odpovědnosti výrobce. Promítne se do ceny podpory. A hlavně do toho, jestli může zákazník jednou odejít jinam, aniž ztratí souvislosti, historii a klinický význam svých dat.

Poskytovatelům zdravotních a sociálních služeb z toho neplyne povinnost stát se evropským certifikačním orgánem. Plyne z toho povinnost nakupovat s otevřenýma očima. Nechtít po dodavateli odpověď na otázku, kterou dosud neuzavřela ani Evropská komise. Chtít ale, aby věděl, že ta otázka existuje, aby znal hranice svého výrobku a uměl ukázat cestu k důkazu. A nezaměřovat se jen na funkce a vzhled rozhraní.

Dobrá telemedicínská platforma neslibuje, že se jí budoucí změny vyhnou. Pozná se podle toho, že u ní výměna jedněch dveří nevypadá jako bourání celého domu.