Austriacki system elektronicznej dokumentacji medycznej ma konkretne wymagania integracyjne, które większość zespołów odkrywa dopiero po ustawieniu architektury. Oto co zdecydować, zanim napiszesz pierwszą linię kodu.
Większość founderów budujących produkty digital health dla rynku austriackiego spędza pierwsze miesiące na klasyfikacji MDR i zgodności z GDPR i odkrywa ELGA pół roku później, kiedy zespół inżynierski zaczyna pytać, jak dane pacjentów faktycznie wchodzą i wychodzą z systemu. Ten moment jest kosztowny. W fireup.pro budujemy produkty healthcare dla regionu DACH od 2018 roku, w tym platformy obsługujące ponad 1,8 miliona użytkowników i architektura ELGA wciąż zaskakuje kolejne zespoły z tych samych powodów.
Czym jest ELGA i dlaczego to nie jest „austriacki TI”
ELGA (Elektronische Gesundheitsakte) to ogólnokrajowy system elektronicznej dokumentacji medycznej w Austrii, działający od 2015 roku i obowiązkowy dla szpitali, aptek i większości placówek ambulatoryjnych. Daje pacjentom i uprawnionym świadczeniodawcom dostęp do wyników laboratoryjnych, danych o lekach, raportów radiologicznych, pism wypisowych i e-recept.
Kluczowe rozróżnienie dla zespołów deweloperskich: ELGA to nie to samo co niemiecka Telematikinfrastruktur (TI), a wymagania integracyjne różnią się znacząco. Produktu już zintegrowanego z TI w Niemczech nie można „rozszerzyć” na ELGA w Austrii. Standardy nakładają się na poziomie konceptualnym, oba używają HL7, ale profile implementacyjne, typy dokumentów, infrastruktura tożsamości i governance są całkowicie odrębne.
ELGA jest operowana przez ELGA GmbH, podmiot non-profit współwłasnością austriackiego rządu federalnego, landów i instytucji ubezpieczeń społecznych. Dostęp wymaga rejestracji jako uczestnik ELGA i integracji z austriacką infrastrukturą tożsamości poprzez eCard – elektroniczną kartę ubezpieczenia zdrowotnego, którą posiada każdy mieszkaniec. Dla startupu oznacza to, że integracja z ELGA to nie wywołanie API z kluczem dewelopera. To proces instytucjonalny z konkretnymi krokami certyfikacyjnymi, które trzeba wpisać w harmonogram projektu od pierwszego dnia.
Tranzycja CDA na FHIR: co oznacza, jeśli budujesz teraz
Aktualną podstawą techniczną ELGA jest HL7 CDA (Clinical Document Architecture) standard dokumentowy, w którym dane zdrowotne wymieniane są jako ustrukturyzowane dokumenty XML: pisma wypisowe, wyniki laboratoryjne, e-recepty, każdy zgodny z austriackim profilem implementacyjnym.
Zespoły planujące produkty w 2026 roku stoją przed realnym dylematem. Standard jest w trakcie transformacji. HL7 Austria opublikowało FHIR Core Implementation Guide, a Austriackie Podsumowanie Pacjenta jest rozwijane w FHIR R4. ELGA GmbH aktywnie pracuje nad wymianą dokumentów opartą na FHIR, zgodną z wymogami unijnymi z Europejskiej Przestrzeni Danych Zdrowotnych. Ale ELGA nie jest dziś FHIR i zespół, który zbuduje warstwę wymiany danych wyłącznie w oparciu o FHIR, trafi na lukę w produkcji.
Europejska analiza z 2023 roku wykazała, że tylko 7 z 38 przeanalizowanych aplikacji digital health było kompatybilnych z aktualnym standardem austriackiego ELGA. Główną barierą w większości przypadków nie były kwestie regulacyjne, były to luki interoperacyjności na poziomie typów dokumentów, których zespoły nie uwzględniły przy projektowaniu architektury danych.
Praktyczne podejście, które rekomendujemy klientom, to projektowanie pod transformację: implementacja obsługi dokumentów CDA dla bieżącej integracji ELGA przy jednoczesnym modelowaniu wewnętrznej struktury danych wokół zasobów FHIR. Kiedy pracowaliśmy nad mySugr – platformą zarządzania cukrzycą przejętą przez Roche z 1,8 miliona użytkowników. Decyzje dotyczące reprezentacji danych podjęte we wczesnych sprintach zdeterminowały zakres przebudowy wymagany przy kolejnych zmianach standardów. Ta lekcja kształtuje to, jak dziś doradzamy zespołom wchodzącym na rynek austriacki.
Co EHDS zmienia dla produktów budowanych w Wiedniu
Rozporządzenie o Europejskiej Przestrzeni Danych Zdrowotnych weszło w życie w marcu 2025 roku. Dla austriackich startupów digital health kluczowy termin to marzec 2029: do tego czasu państwa członkowskie UE muszą obsługiwać transgraniczny wymianę priorytetowych kategorii danych, podsumowań pacjentów i e-recept, w znormalizowanym formacie.
Austria jest w relatywnie dobrej pozycji. Kraj prowadzi ELGA od 2015 roku, utrzymuje infrastrukturę HealthData@AT do wtórnego wykorzystania danych i uczestniczy w transgranicznej infrastrukturze wymiany eHDSI. Trajektoria regulacyjna nakłada się na istniejącą infrastrukturę, zamiast wymagać całkowitej przebudowy. W praktyce oznacza to, że architektura budowana dziś pod integrację ELGA jest jednocześnie fundamentem pod zgodność z EHDS w 2029 roku.
„Zespoły, które sprawnie przechodzą przez przygotowania do EHDS, to te, które traktują go jako ograniczenie architektoniczne od pierwszego sprintu, a nie projekt migracyjny na 2028 rok. Standardy zbiegają się w kierunku FHIR i wewnętrzny model danych powinien to już odzwierciedlać.” – Jarek Szczotka, Strategic Growth Advisor, fireup.pro
3 obszary wymagają decyzji przed pierwszym sprintem. Sposób obsługi zgody pacjenta i logowania dostępu do danych – EHDS wprowadza koncepcję wtórnego wykorzystania, która wykracza poza istniejące ramy zgody GDPR, i model zgody musi odróżniać użycie w podstawowej opiece zdrowotnej od użycia badawczego na poziomie danych. Sposób wewnętrznej reprezentacji danych pacjentów – EHDS buduje na FHIR, więc wewnętrzna reprezentacja FHIR jest właściwym długoterminowym wyborem nawet tam, gdzie CDA jest nadal wymagane na warstwie wymiany. I sposób obsługi tożsamości pacjenta w wymiarze transgranicznym – Austria używa eCard i krajowej infrastruktury ID; EHDS wymagać będzie mapowania do europejskiego identyfikatora pacjenta.
Stack zgodności dla wiedeńskiego startupu digital health w 2026 roku
| Warstwa | Co wymaga | Kiedy dotyczy |
|---|---|---|
| GDPR | Zgoda, logi dostępu, prawa podmiotów danych, umowy DPA z dostawcami | Zawsze, od pierwszego dnia |
| MDR 2017/745 | Oznakowanie CE, dokumentacja techniczna, jednostka notyfikowana dla klasy IIa+ | Jeśli oprogramowanie kwalifikuje się jako wyrób medyczny |
| Integracja ELGA | Zgodność CDA, rejestracja uczestnika ELGA GmbH, IdP eCard | Jeśli produkt odczytuje lub zapisuje dane zdrowotne pacjentów w Austrii |
| EU AI Act | Klasyfikacja ryzyka, nadzór ludzki, logowanie audytowe (wysokie ryzyko od sierpnia 2028) | Jeśli produkt zawiera funkcje AI wpływające na decyzje kliniczne |
| EHDS | Zgodność FHIR, obsługa podsumowania pacjenta, governance wtórnego użycia | Pełne zastosowanie od marca 2029 |
Austria rozwija również własny framework DiHA (Digitale Gesundheitsanwendungen) dla refundacji aplikacji zdrowotnych przez ustawowe ubezpieczenie zdrowotne – austriacki odpowiednik niemieckiego DiGA. Framework jest nadal w fazie kształtowania przez 2026 i 2027 rok, ale zespoły planujące refundację ubezpieczeniową powinny budować dokumentację dowodową z uwzględnieniem kryteriów DiHA od początku. Szczegółowe omówienie tego, jak EU AI Act nakłada się na ten stack, znajdziesz w naszym artykule o tym, co termin 2028 oznacza dla zespołów medical AI w DACH.
3 decyzje architektoniczne, które determinują koszt integracji ELGA
Nasz zespół healthcare zbudował systemy produkcyjne obejmujące ten stack dla klientów takich jak mySugr/Roche, 9amHealth, Selfapy i Mentalyc. Zespoły, które sprawnie przeprowadzają integrację ELGA, dzielą trzy decyzje podjęte wcześnie.
1. Zakres typów dokumentów. ELGA obsługuje zdefiniowany zestaw typów: wyniki laboratoryjne, pisma wypisowe, raporty radiologiczne, dane o lekach, e-recepty. Decyzja z góry, które typy produkt odczytuje, zapisuje lub jedno i drugie, determinuje zakres prac nad zgodnością CDA. Przy 9amHealth – wirtualnej klinice, która w samym 2026 roku przyciągnęła 40 000 nowych użytkowników przez programy benefitów pracodawców — decyzje dotyczące modelu danych podjęte w pierwszych dwóch sprintach ukształtowały wszystko, co nastąpiło później. Zespoły, które próbują definiować zakres dokumentów w połowie projektu, regularnie odkrywają, że zbudowały zły model danych pod złą strukturę dokumentu.
2. Architektura tożsamości. ELGA używa austriackiej infrastruktury tożsamości e-government: uwierzytelnianie eCard dla pacjentów, określone typy poświadczeń dla świadczeniodawców. Wpływa to na przepływy autentykacji, obsługę sesji i kontrolę dostępu od pierwszego sprintu, nie da się tego zaślepić w developmencie i dodać przed launchem. Przy Selfapy – cyfrowej platformie terapii CBT, która uzyskała certyfikację BSI IT-Grundschutz w Niemczech spełniając ponad 120 indywidualnych wymagań bezpieczeństwa przed launchem, architektura tożsamości była zdefiniowana zanim zbudowano jedną funkcję produktową.
3. Standard wewnętrznej reprezentacji. Jeśli wewnętrzny model danych ma kształt CDA, migracja do FHIR później oznacza przebudowę kluczowych struktur pod presją czasu. Jeśli wewnętrzny model jest oparty na FHIR z warstwą translacji CDA dla wymiany ELGA, ta warstwa kurczy się w miarę jak ELGA migruje, a model wewnętrzny pozostaje stabilny. Drugie podejście kosztuje więcej na początku i znacznie mniej przez cały cykl życia produktu.
🚀 Jeśli budujesz produkt digital health na rynek austriacki i chcesz technicznej weryfikacji podejścia do integracji ELGA, zanim decyzje architektoniczne zostaną zablokowane 👉 chętnie porozmawiamy. Zbudowaliśmy produkty healthcare na pełnym austriackim stacku zgodności – od pierwszej integracji ELGA, przez dokumentację MDR, po architekturę pod EHDS.
Porozmawiaj z naszym zespołem → · Zobacz nasze case studies z healthcare →
