Zdravotnické aplikace: proč je vývoj složitější než ostatní projekty

Když jsme v roce 2013 dokončili první verzi projektu Doktor v kapse, přiznali jsme si jednu věc: vývoj zdravotnické aplikace je jiný druh výzvy. Není to proto, že by byl technicky nemožný – je to proto, že technologie je jen jedna část rovnice. Druhou jsou regulace, třetí jsou data pacientů a čtvrtá je samotný uživatel, který v těžkých chvílích potřebuje aplikaci, jež nikdy neselže.

1. Regulatorní prostředí: co musíte vědět před zahájením

V EU i na většině světových trhů platí přísné regulatorní předpisy pro zdravotnické prostředky – v Evropě jde primárně o MDR (Medical Device Regulation). Ne každá aplikace, která se týká zdraví, je automaticky zdravotnický prostředek – ale pokud pomáhá s diagnózou, monitoringem nebo léčbou, pravděpodobně se pod regulaci dostane.

V praxi narážíme na tuto otázku prakticky u všech aplikací zaměřených na adherenci k léčbě – tedy všude tam, kde pomáháme pacientům dodržovat léčebný režim. Právě tato funkce se pohybuje na hranici regulace. Věnujeme proto značnou část přípravy konzultacím s právníky a regulatorními odborníky ještě před napsáním prvního řádku kódu.

Dobrou zprávou je, že správně navrženou architekturou a volbou funkcí lze aplikaci udržet mimo definici zdravotnického prostředku – a vyhnout se tak nákladné certifikaci MDR. Pomáháme klientům tuto hranici identifikovat ještě ve fázi specifikace a navrhnout funkcionalitu tak, aby přinášela maximální hodnotu pacientům, aniž by projekt zbytečně prodražila.

2. GDPR a zdravotní data: zpřísnění na druhou

Zdravotní data patří mezi zvláštní kategorie osobních údajů podle GDPR (čl. 9). To znamená přísnější pravidla pro souhlas, omezenější možnosti zpracování a vyšší požadavky na zabezpečení než u běžných osobních dat. V praxi to má dopad na architekturu celé aplikace.

Při vývoji pacientského portálu pro privátní kliniku jsme propojili klinický systém a proprietární informační systém kliniky – dvě prostředí, která nebyla navržena pro vzájemnou komunikaci. Každý datový tok musel být právně podložen – typ souhlasu, účel zpracování, doba uchování. Architektura musela počítat s tím, že uživatel může svůj souhlas kdykoli odvolat, a data musí být skutečně smazána ze všech vrstev systému.

Praktický dopad: plánujte pseudonymizaci dat na úrovni databáze, šifrování at-rest i in-transit, auditní logy a oddělení identifikačních dat od zdravotních dat. Není to paranoia – je to standard.

3. Integrace zdravotních systémů: každý mluví jinak

Zdravotnictví je globálně fragmentované. Nemocnice, kliniky a pojišťovny používají různé systémy – každý s jiným formátem dat a jinou ochotou ke spolupráci. Vezměte třeba DASTA, proprietární datový standard českého zdravotnictví: bez hluboké zkušenosti s ním integraci neuděláte. Podobné lokální standardy a proprietární formáty ale najdete v každé zemi.

Aplikace pro porodní asistentky, kterou jsme vyvinuli, čte data z e-kartiček pojištěnce podle standardu platného v Německu a Rakousku – a ta pak synchronizuje s vlastním informačním systémem provozovatele. Přímé napojení na třetí strany tak odpadá, ale přesné dodržení formátu karty je podmínkou spolehlivosti celého systému.

Naše doporučení: počítejte s tím, že integrace zabere 30–50 % celkového času projektu. A nikdy nepodepisujte smlouvu bez přístupu do sandboxu cílového systému.

4. UX pro pacienty: pokora a jednoduchost

Pacient, který používá vaši aplikaci, pravděpodobně není v nejlepší situaci. Možná mu bylo právě diagnostikováno chronické onemocnění. Možná hledá výsledky vyšetření s velkou úzkostí. Uživatelský zážitek musí být proto navržen s mimořádnou pokorou.

Při vývoji deníku záchvatů pro pacienty s chronickým neurologickým onemocněním jsme testovali UI s reálnými pacienty. Zjistili jsme, že v akutní fázi záchvatu potřebují zadat informace co nejrychleji – jasná tlačítka, žádné zbytečné kroky, možnost ovládání jednou rukou. Tento insight změnil celý návrh aplikace.

• → Přístupnost je požadavek, ne bonus. Starší pacienti, lidé se zrakovým postižením, motorickými omezeními – navrhujte pro ně od začátku. Pokud váš projekt vyžaduje soulad s evropskými požadavky na přístupnost (EAA), zajistíme to jako součást vývoje.
• → Chybové stavy jsou kritické. Co se stane, když aplikace ztratí síť uprostřed zadávání dat? Offline-first přístup, automatické uložení, jasná komunikace stavu.
• → Notifikace mohou zachránit léčbu. Připomenutí léku nestačí – musí být doručeno spolehlivě i při úsporném režimu baterie, s potvrzením přijetí.
• → Lokalizace je víc než překlad. Naše aplikace běží ve více než 10 zemích a jazycích – každá verze zohledňuje specifika místního pojistného systému, regulatorní požadavky dané země a kulturní rozdíly v komunikaci s pacienty.

5. Co z toho plyne pro váš projekt

Zdravotnická aplikace je náročnější projekt než průměrná komerční aplikace – ale není nedosažitelný. Klíč je přijít ke konzultaci co nejdříve, ne po tom, co je funkční specifikace hotová. Regulatorní požadavky a požadavky GDPR ovlivňují architekturu od základu.

Za 20 let jsme prošli více než 8 zdravotnickými projekty – od aplikací pro pacienty přes portály pro lékaře až po middleware integrující nemocniční systémy. Rádi sdílíme zkušenosti a pomůžeme vám rozmyslet projekt ještě před zahájením vývoje.