Austria finalizuje w 2026 roku ścieżkę refundacji aplikacji cyfrowych. Większość wniosków zostanie odrzucona i nie z powodów klinicznych.

Pracujemy z zespołami healthtech z całego regionu DACH i kiedy na początku 2026 roku pojawiły się pierwsze szczegóły austriackiego systemu DiHA, zobaczyliśmy znajomy schemat reakcji. Founderzy przesyłali artykuły swoim product leaderom. Product leaderzy mówili inżynierom, żeby „upewnili się co do FHIR”. Zespoły kliniczne zaczęły pytać o design badań.

Wszystkie te osoby rozwiązywały zły problem.

W Niemczech, gdzie ten model działa od 2019 roku, głównym powodem odrzucania wniosków nie jest słaba ewidencja kliniczna. To infrastruktura danych, która nie przejdzie audytu BSI, dokumentacja cyklu życia oprogramowania, której nigdy nie stworzono, i luki w interoperacyjności z krajowym systemem dokumentacji medycznej. Austria przez trzy lata obserwowała te błędy. Buduje swoją ścieżkę z tymi samymi pułapkami w polu widzenia i z wyżej ustawioną poprzeczką techniczną.

Czym jest refundacja DiHA w Austrii

DiGA (Digitale Gesundheitsanwendung) to certyfikowana aplikacja zdrowotna, do której pacjent ma dostęp przez ustawowe ubezpieczenie zdrowotne, bez żadnych opłat własnych. Niemcy stworzyły tę kategorię w 2019 roku w ramach Digital Versorgung Gesetz, jako pierwszy kraj na świecie umożliwiając wypisywanie aplikacji na receptę. Austria buduje swój odpowiednik w Erstattungskodex, krajowym rejestrze refundacyjnym prowadzonym przez Österreichische Gesundheitskasse – pierwsze zatwierdzenia DiHA (Digital Health Application) spodziewane są od 2026 roku.

Co 5 lat niemieckiej DiGA naprawdę pokazuje

Niemcy zatwierdziły ponad 50 DiGA od 2019 roku. Bardziej pouczający jest wskaźnik odrzuceń. Badania opublikowane w PMC, analizujące ścieżkę do austriackiego systemu DiHA, wskazują, że błędy w dokumentacji technicznej i regulacyjnej odpowiadają za więcej odrzuceń niż niewystarczająca ewidencja kliniczna.

Schemat jest niemal zawsze taki sam. Firma przeprowadza 18-miesięczne badanie kliniczne, po czym podczas przeglądu technicznego okazuje się, że infrastruktura logowania nie spełnia wymagań BSI TR-03161. Albo że środowisko chmurowe nie spełnia wymagań suwerenności danych zdrowotnych w kontekście niemiecko-austriackim. Albo że implementacja HL7 FHIR przechodzi podstawowe testy, ale nie działa poprawnie, kiedy podmiot certyfikujący sprawdza ją w rzeczywistym środowisku krajowego systemu dokumentacji medycznej.

Widzieliśmy każdą z tych sytuacji w projektach, do których wchodziliśmy w połowie drogi, zwykle kiedy zespół zdał sobie sprawę, że oryginalna architektura nie była projektowana z myślą o żadnym z tych wymagań. Austria projektuje swój system tak, żeby te błędy były niemożliwe do przeoczenia.

Żeby w ogóle złożyć wniosek, aplikacja musi jednocześnie spełniać trzy nakładające się na siebie ramy regulacyjne: unijne Rozporządzenie o wyrobach medycznych (MDR), austriackie standardy infrastruktury danych ELGA oraz — w przypadku każdej aplikacji z algorytmicznym wspomaganiem decyzji – unijną Ustawę o AI. Spełnienie jednej z tych ram bez pozostałych nie prowadzi do złożenia wniosku. Prowadzi do odrzucenia z długą listą braków.

3 problemy techniczne, które eliminują wnioski przed oceną kliniczną

Ścieżki audytu. Certyfikacja DiHA wymaga kompletnych, odpornych na manipulację logów każdej interakcji z danymi pacjenta. Nie systemowych logów do debugowania, klinicznych ścieżek audytu rejestrujących kto, co, kiedy, z jakiego kontekstu klinicznego i z jakim wynikiem. Większość aplikacji skierowanych do konsumentów ma logging zaprojektowany pod śledzenie błędów. To architektonicznie różna rzecz od tego, czego oczekuje audyt certyfikacyjny. Dorobienie tego do działającego produktu to nie sprint to zmiana strukturalna dotykająca warstwy danych.

Dokumentacja MDR obejmująca historię rozwoju produktu. Aplikacje ubiegające się o status DiHA zazwyczaj kwalifikują się do klasy IIa MDR, która wymaga dokumentacji technicznej obejmującej cały cykl życia oprogramowania: proces wytwarzania, metodologię testowania, zarządzanie zmianami i dokumentację ryzyka, wszystko ustrukturyzowane zgodnie z IEC 62304. Ta dokumentacja dotyczy historii rozwoju produktu, nie tylko jego aktualnego stanu. Jeśli aplikacja była budowana bez procesów zgodnych z IEC 62304, nie ma czego dokumentować. Trzeba przebudować sposób pracy wstecz.

Interoperacyjność HL7 FHIR z ELGA. Austriacki krajowy system elektronicznej dokumentacji medycznej używa HL7 FHIR jako standardu wymiany danych. Aplikacja DiHA, która nie wymienia danych w formacie zgodnym z FHIR R4 z ELGA, nie przejdzie oceny zgodności technicznej. Budowaliśmy warstwy integracji FHIR zarówno w nowych platformach zdrowotnych, jak i w produktach z latami danych produkcyjnych za sobą to drugie to zasadniczo inny projekt, typowo 6–9 miesięcy przy rzetelnym wykonaniu. W naszym artykule o integracji systemów healthcare opisujemy, jak wygląda ten zakres w praktyce.

Warstwa AI Act, o której większość zespołów nie myśli

Jeśli aplikacja korzysta z algorytmicznego wspomagania decyzji: scoringu ryzyka, triaż, personalizowanych rekomendacji na podstawie danych zdrowotnych – kwalifikuje się do klasyfikacji wysokiego ryzyka w AI Act na mocy artykułu 6. Digital Omnibus przesunął pierwotny termin z sierpnia 2026 na grudzień 2027 dla systemów samodzielnych i sierpień 2028 dla AI wbudowanego w produkty regulowane przez MDR. Pisaliśmy o tym szczegółowo w kontekście zgodności AI Act i SaMD.

Dla austriackich wniosków DiHA kluczowe jest jedno: podmiot certyfikujący traktuje zgodność z AI Act jako warunek wstępny, nie równoległy projekt. Aplikacja z komponentem AI, która nie przeszła oceny zgodności dla systemów wysokiego ryzyka, nie otrzyma statusu DiHA, niezależnie od badania klinicznego, które za nią stoi. Ten sprawdzian jest wczesny w procesie.

Połączenie wymagań MDR, AI Act i ELGA to miejsce, gdzie większość wniosków upada. Każda z tych ram ma własną logikę dokumentacji, testowania i audytu. Prowadzenie trzech równoległych projektów compliance’owych na bazie kodu, który nie był projektowany pod żadne z nich, jest kosztowne i powolne. I jest dokładnie tą sytuacją, w której większość zespołów się znajduje, kiedy refundacja przestaje być „roadmapą na przyszłość” i staje się „składamy wniosek za 12 miesięcy.”

Co widzieliśmy w produktach, które przez to przechodzą

Aplikacje zdrowotne, przy których pracowaliśmy i które sprawnie przeszły przez procesy certyfikacyjne, w tym projekty z mySugr/Roche i 9amHealth, łączyły kilka wspólnych cech, które nie miały nic wspólnego z orientacją na compliance.

Data governance było wymaganiem produktowym od pierwszego dnia, nie projektem compliance’owym dodanym później. Ścieżki audytu, przepływy zgód i pochodzenie danych były wbudowane w podstawowy model danych, zanim pierwszy użytkownik dotknął produktu. Endpointy FHIR nie były projektem integracyjnym zaplanowanym na Q4 – były częścią projektu API od pierwszego sprintu. Dokumentacja IEC 62304 była żywym artefaktem aktualizowanym przy każdej istotnej zmianie, nie składanym wtedy, kiedy ktoś zdecydował się ubiegać o certyfikację.

Żadna z tych rzeczy nie jest technicznie skomplikowana. Wymaga podjęcia tych decyzji zanim zbudujesz główny produkt albo pogodzenia się z tym, że będziesz przebudowywać jego znaczące części później, pod presją czasu, z terminem certyfikacji w tle. Jeśli jesteś na etapie MVP i refundacja DiHA jest gdzieś na horyzoncie, warto przeczytać jak poprawnie skopować healthcare MVP.

Kiedy zacząć

Jeśli refundacja DiHA jest na waszym roadmapie na 2027 lub 2028 rok, fundamenty techniczne muszą powstawać teraz. Technical File MDR obejmuje historię waszego procesu wytwarzania — nie można wstecznie udokumentować czegoś, czego nie robiliście. Warstwa integracji FHIR w dojrzałym produkcie bez wcześniejszego projektu FHIR to 6–9 miesięcy pracy. Procesów zgodnych z IEC 62304 nie da się zadokumentować wstecz.

Program FFG i aws „Digital Health Austria” uruchomiony w 2026 roku jest częściowo zaprojektowany tak, żeby pomagać austriackim firmom healthtech osiągnąć ten techniczny baseline. Jeśli składacie wniosek o to finansowanie, kryteria techniczne są bliskie temu, na co będą zwracać uwagę oceniający certyfikację DiHA.

Jeśli budujecie produkt zdrowotny na rynek austriacki i chcecie wiedzieć, gdzie wasza architektura stoi względem wymagań DiHA- chętnie to ocenimy.