EHDS i HL7 FHIR: co dostawca oprogramowania medycznego musi przygotować do 2029 roku

Jeśli tworzysz system dla gabinetów, przychodni, laboratoriów albo telemedycyny, w najbliższych latach klienci zaczną pytać: „czy jesteście gotowi na EHDS?”. Ten artykuł zbiera to, co wiadomo dziś, i pokazuje, od czego zacząć, żeby nie zostawiać wszystkiego na 2028 rok.

To nie jest porada prawna. Szczegóły techniczne określą akty wykonawcze Komisji Europejskiej, więc część wymagań może się jeszcze zmienić.

EHDS w jednym akapicie

EHDS, czyli Europejska Przestrzeń Danych Dotyczących Zdrowia, to rozporządzenie (UE) 2025/327. Ma dwa cele. Pacjent ma mieć dostęp do swoich danych i móc je przekazać lekarzowi w innym kraju (to tzw. wykorzystanie pierwotne). Dane mają też być dostępne, na określonych zasadach, do badań i polityki zdrowotnej (wykorzystanie wtórne). Dla dostawcy oprogramowania najważniejsza jest część pierwsza, bo nakłada obowiązki na producentów systemów EHR.

Terminy

Data	Co się dzieje
26 marca 2025	rozporządzenie wchodzi w życie, zaczyna się okres przejściowy
26 marca 2027	stosowanie ogólne, Komisja ma przyjąć kluczowe akty wykonawcze
26 marca 2029	wymiana pierwszej grupy danych: karta pacjenta, e-recepta i jej realizacja
26 marca 2031	druga grupa: badania obrazowe, wyniki laboratoryjne, wypisy ze szpitala

Daty 2029 i 2031 dotyczą też komponentów, które muszą mieć systemy EHR przetwarzające dane z danej grupy.

Co musi mieć system EHR

Rozporządzenie opisuje dwa zharmonizowane komponenty:

1. Komponent interoperacyjności. System musi umieć zaimportować i wyeksportować dane w europejskim formacie wymiany dokumentacji (EEHRxF, European Electronic Health Record Exchange Format).
2. Komponent logowania. System zapisuje, kto i kiedy miał dostęp do danych pacjenta, żeby pacjent mógł to sprawdzić.

Do tego dochodzą obowiązki formalne producenta:

• spełnienie wymagań zasadniczych z załącznika II i wspólnych specyfikacji,
• przetestowanie komponentów przed wprowadzeniem systemu na rynek (państwa członkowskie mają udostępnić cyfrowe środowiska testowe),
• dokumentacja techniczna, deklaracja zgodności UE i oznakowanie CE,
• rejestracja systemu w unijnej bazie systemów EHR,
• bezpłatna instrukcja używania.

Jeśli system jest też wyrobem medycznym albo zawiera AI, obok EHDS mogą obowiązywać rozporządzenie o wyrobach medycznych (MDR) i AI Act.

Gdzie w tym jest HL7 FHIR

Europejski format wymiany (EEHRxF) ma opierać się na zaleceniu Komisji z 2019 roku i obejmować wspólne zbiory danych, kody i specyfikacje techniczne. Wytyczne, które go przygotowują, powstają w HL7 FHIR. Przykład to HL7 Europe Patient Summary, czyli europejska karta pacjenta w FHIR R4, rozwijana we współpracy z projektem Xt-EHR i sprawdzana pod kątem wymagań EHDS. W połowie 2026 roku miała status wersji do głosowania (1.0.0-ballot), więc jeszcze się zmienia.

W Polsce HL7 Polska rozwija HL7 FHIR PL Base, czyli polską specyfikację bazową. Jest wciąż we wczesnej wersji.

Warto pamiętać o jednym: dokumentacja medyczna wymieniana dziś przez platformę P1 opiera się na dokumentach HL7 CDA w polskiej implementacji krajowej. FHIR nie zastępuje dziś integracji z P1. Jest za to językiem, w którym powstaje europejska wymiana danych, i dobrym wyborem do łączenia własnych systemów z partnerami.

Plan prac na najbliższe lata

Nie trzeba czekać na ostatnie akty wykonawcze, żeby zacząć. Większość pracy nie zależy od szczegółów formatu, tylko od jakości Twoich danych.

1. Inwentaryzacja danych. Które dane z priorytetowych kategorii przetwarza Twój system i gdzie leżą w bazie. Karta pacjenta to m.in. alergie, problemy zdrowotne, leki, szczepienia, wyniki.
2. Kody i słowniki. Sprawdź, czy rozpoznania, badania i leki są zakodowane (ICD-10, LOINC, SNOMED CT, słowniki krajowe), czy zapisane wolnym tekstem. Przemapowanie kodów to zwykle najdłuższa część projektu.
3. Identyfikacja pacjenta. Jeden pacjent musi być jednym rekordem. Duplikaty, które dziś przeszkadzają tylko w raportach, w wymianie danych stają się błędem.
4. Warstwa FHIR. API FHIR na istniejącej bazie albo osobny serwer FHIR z synchronizacją. Nie trzeba przepisywać systemu, żeby wystawić dane w standardzie.
5. Zapis dostępu. Jeśli system nie zapisuje dziś, kto oglądał dane pacjenta, to dobry moment, żeby to zaprojektować, z myślą o udostępnieniu tego zapisu pacjentowi.
6. Testy i dokumentacja. Walidacja względem profili, testy w środowiskach testowych, gdy będą dostępne, i dokumentacja techniczna, która i tak będzie potrzebna do deklaracji zgodności.

Punkty 1-3 możesz zrobić już teraz, niezależnie od tego, jak skończą się prace nad aktami wykonawczymi.

Jak możemy pomóc

Przygotowujemy techniczną część: analizę i mapowanie danych, warstwę FHIR, walidację względem profili, komponent wymiany i zapisu dostępu oraz integracje z partnerami. Formalności, czyli deklarację zgodności, oznakowanie CE i rejestrację, składa producent systemu. Doświadczenie z HL7 FHIR zespół zdobył w projektach poza Fide-Soft, a jako Fide-Soft od lat robimy integracje systemów i API.

Szczegóły są na stronie integracja HL7 FHIR i przygotowanie do EHDS. Jeśli chcesz sprawdzić, jak daleko jest Twój system, opisz go krótko: jakie dane przetwarza, z kim się dziś wymienia i w jakim formacie.