Manager placówki nie powinien czekać do 2029 roku z pytaniem, czy jego system dokumentacji medycznej jest gotowy na EHDS. Najważniejsza decyzja na dziś to zmapowanie obiegu danych i uzyskanie od dostawcy pisemnego planu zmian w eksporcie, wymianie danych między systemami, rejestrach operacji oraz uprawnieniach. Poniżej pokazuję, co dokładnie zmieni się etapami, gdzie zaczyna się osobna ocena wykorzystania danych przez AI i jakie pięć pytań zadać dostawcy.
EHDS (Europejska Przestrzeń Danych Dotyczących Zdrowia) to unijne ramy dostępu, wymiany i ponownego wykorzystywania elektronicznych danych zdrowotnych. EDM (elektroniczna dokumentacja medyczna) to dokumentacja prowadzona w systemie placówki; w praktyce obejmuje różne zbiory i formaty, a nie jeden plik pacjenta. Rozporządzenie EHDS weszło w życie 26 marca 2025 roku, ale większość obowiązków będzie stosowana później.
Dla projektu AI granica jest prosta: większa dostępność techniczna danych nie tworzy automatycznie prawa do dowolnego ich użycia. System może ułatwić opiekę, badanie lub rozwój narzędzia, lecz cel, podstawa prawna, zakres danych i dostęp muszą być ocenione oddzielnie. EHDS porządkuje drogę do danych; nie daje placówce ani dostawcy ogólnej zgody na trenowanie modelu.
EHDS zmienia prawa pacjenta i wymagania wobec systemów EDM
W części dotyczącej podstawowego wykorzystania danych EHDS ma ułatwić pacjentowi bezpłatny i natychmiastowy dostęp elektroniczny do priorytetowych kategorii danych, między innymi kart pacjenta i e-recept, pobranie ich kopii oraz sprawdzenie, kto korzystał z dokumentacji. Pacjent ma też móc zgłosić błąd i w określonych warunkach ograniczyć dostęp. To oznacza, że wygodny portal jest tylko warstwą widoczną na zewnątrz. Pod nim musi istnieć uporządkowany zapis danych, tożsamości i zdarzeń.
Po stronie placówki znaczenie ma nie tylko to, czy dokument powstał. Dla priorytetowych kategorii system powinien zachować aktualność danych oraz identyfikację profesjonalisty, podmiotu i czasu rejestracji. Pochodzenie wpisu staje się częścią jego użyteczności, zwłaszcza gdy informacja przechodzi między organizacjami albo zasila proces wspierany przez AI.
EHDS wyróżnia w systemach EHR (systemach elektronicznej dokumentacji zdrowotnej) dwa elementy, których zasady będą ujednolicone w UE. Pierwszy odpowiada za interoperacyjność, czyli import i eksport priorytetowych danych w europejskim formacie wymiany elektronicznej dokumentacji zdrowotnej. Drugi dotyczy rejestrowania dostępu i działań. Producent nie musi przebudowywać całego wewnętrznego formatu bazy tylko dlatego, że potrzebny jest eksport, ale ma wykazać działanie wymaganych elementów i przygotować dokumentację techniczną.
Dla managera wniosek jest praktyczny: rozmowa o zgodności nie może skończyć się na zdaniu, że system ma interfejs do automatycznej wymiany danych (API). Trzeba ustalić, jakie dane da się rzeczywiście zaimportować i wyeksportować, w jakiej wersji formatu, z jakim śladem oraz kto zobaczy ten rejestr (log).
Obowiązki wejdą etapami, więc placówka potrzebuje planu zmian
Do 26 marca 2027 roku Komisja Europejska ma przyjąć istotne akty wykonawcze, między innymi ze szczegółowymi zasadami dotyczącymi jakości i wymiany danych. Dzisiejsza odpowiedź dostawcy nie powinna więc brzmieć tylko tak lub nie. Potrzebny jest plan zmian z wersjami systemu, zależnościami od specyfikacji i sposobem informowania klientów o zmianach.
Od 26 marca 2029 roku mają być stosowane pierwsze kluczowe obowiązki: dotyczą między innymi kart pacjenta, e-recept i e-realizacji recept, pierwszej grupy zasad wtórnego użycia oraz wymagań dla odpowiednich systemów EHR wprowadzanych na rynek. Od 26 marca 2031 roku dołączą kolejne priorytetowe kategorie, w tym obrazowanie medyczne z raportami, wyniki laboratoryjne i diagnostyczne oraz wypisy ze szpitala.
Te daty nie są pozwoleniem, by odłożyć temat do kolejnego budżetu IT. Migracja list dozwolonych wartości, naprawa niepełnych pól i odtworzenie historii uprawnień mogą potrwać dłużej niż zakup modułu. Najkrócej: porządkowanie odpowiedzialności i umów trzeba zacząć wczesniej niż migrację systemu. Plan zmian powinien prowadzić od dzisiejszej jakości danych do konkretnego wydania produktu, a nie od obietnicy sprzedawcy do daty w kalendarzu.
Nie należy też zakładać, że każda mała praktyka będzie miała identyczny zakres obowiązków w roli posiadacza danych, czyli podmiotu zobowiązanego do udostępnienia ich do wtórnego użycia. Rozporządzenie przewiduje w tym obowiązku wyjątek dla mikroprzedsiębiorstw, a państwo członkowskie może objąć nim także takie podmioty. Zakres dla konkretnej placówki trzeba potwierdzić w polskich przepisach wykonawczych z inspektorem ochrony danych (IOD) lub prawnikiem, zamiast wyprowadzać go z samej wielkości systemu EDM.
Więcej danych do opieki nie oznacza dowolnego trenowania AI
EHDS rozdziela wykorzystanie pierwotne, czyli dane używane do świadczenia opieki, od wykorzystania wtórnego, na przykład badań, statystyki, polityki zdrowotnej lub określonych prac rozwojowych. Wśród dozwolonych celów wtórnych rozporządzenie wymienia rozwój, trenowanie, testowanie i ocenę algorytmów oraz systemów AI w ochronie zdrowia. To ważna możliwość, lecz nie skrót prawny.
Jeżeli projekt AI korzysta z trybu wtórnego użycia EHDS, użytkownik danych potrzebuje właściwego zezwolenia lub innej przewidzianej ścieżki, może działać wyłącznie w zatwierdzonym celu i otrzymuje dostęp w bezpiecznym, kontrolowanym środowisku przetwarzania, z którego nie można dowolnie pobierać danych. Obowiązuje ograniczenie zakresu danych do niezbędnego minimum, zakaz ponownej identyfikacji i ograniczenia dotyczące decyzji szkodzących osobie, ubezpieczenia, zatrudnienia czy marketingu. Z takiego środowiska mają wychodzić tylko anonimowe wyniki.
Tu pojawia się praktyczne napięcie. Dobrze ustrukturyzowane dane zwiększają szansę na ciągłość opieki i wartościowe projekty AI, ale ten sam porządek ułatwia kopiowanie i łączenie dużych zbiorów. Dlatego dostępność, uprawnienie i cel nie mogą być jednym przełącznikiem. Konto lekarza, eksport dla pacjenta, zasilenie rejestru i zbiór do badania modelu wymagają oddzielnych ról oraz śladów.
AI może pomóc zespołowi wykryć niespójne nazwy pól, zduplikowane rekordy albo braki w katalogu danych. Nie powinno jednak samodzielnie rozstrzygać, czy cel jest prawnie dopuszczalny, dane są niezbędne ani kto ma uzyskać dostęp. To decyzje właściciela procesu, IOD, zespołu prawnego i osoby odpowiedzialnej klinicznie. Dopiero po tej ocenie zespół techniczny konfiguruje integrację.
Pytania do dostawcy EDM: pięć punktów
Publiczna strona Medyc.pl opisuje obsługę EDM, komunikację z centralnym Systemem P1 oraz dokumenty w standardzie wymiany HL7 CDA i uprawnienia zależne od roli. To deklaracje dostawcy o obecnych funkcjach, nie dowód przyszłej zgodności z EHDS. Tak samo należy czytać materiały każdego producenta: jako punkt startu do pytań, które wymagają pisemnej i wersjonowanej odpowiedzi.
- Które priorytetowe kategorie danych system już importuje i eksportuje maszynowo, w jakich wersjach i wariantach standardu oraz co dziś trafia wyłącznie do PDF? Przy obrazach poproś też o rozdzielenie standardu danych od usługi wymiany; pomaga w tym opis webowej wymiany obrazów DICOMweb.
- Jaka wersja produktu ma obsłużyć europejski format wymiany, kiedy będzie dostępna i jakie wyniki testów oraz dokumentację techniczną otrzyma placówka? Odpowiedź powinna wskazywać zależności od aktów wykonawczych z 2027 roku.
- Co dokładnie zapisuje log: użytkownika, pacjenta, rodzaj operacji, czas, wynik eksportu i zmianę uprawnień? Zapytaj, czy pacjent i administrator mogą zobaczyć właściwy zakres historii oraz jak długo jest przechowywany.
- Jak system chroni jakość i pochodzenie danych przy migracji: słowniki, identyfikatory, autora, podmiot, czas i wersję dokumentu? Sam eksport bez zachowania znaczenia pól nie wystarczy do bezpiecznej wymiany ani analizy.
- Jak dostawca oddziela użycie pierwotne od wtórnego i od własnego rozwoju AI? Poproś o role stron, domyślne wyłączenie danych klienta z trenowania produktu, minimalizację, obsługę zezwoleń i sposób pracy w bezpiecznym środowisku.
Te pytania warto wpisać do mapy integracji AI obok właściciela systemu, umowy i planu wycofania. Dobra odpowiedź wskazuje dane, wersję, test i odpowiedzialną rolę. Hasło zgodne z EHDS bez tych elementów jest materiałem sprzedażowym, nie planem zmian.
Karta decyzji: zmapuj dane przed rozmową o zgodności
Przed spotkaniem placówka powinna, najpierw opisać własny obieg danych. Nie wpisuj danych pacjentów. Dla każdego zbioru podaj kategorię, cel, system, realny eksport, dostęp i log. Puste pole jest wynikiem audytu: pokazuje pytanie, którego dostawca albo właściciel procesu jeszcze nie rozstrzygnął.
| Zbiór danych | Cel pierwotny | System, eksport i ślad dostępu | Ewentualny cel wtórny |
|---|---|---|---|
| Karta pacjenta / podsumowanie | ciągłość opieki | system źródłowy, format, próbka eksportu, role i historia działań | np. badanie jakości — do osobnej oceny |
| E-recepta i realizacja | ordynacja i wydanie leku | System P1, dokument, identyfikatory, odczyt i zmiana | np. analiza populacyjna — do osobnej oceny |
| Wynik laboratoryjny | diagnoza i monitorowanie | system laboratoryjny/EDM, kod, jednostka, autor, czas i odbiorca | np. sprawdzenie modelu AI — do osobnej oceny |
| Obraz i opis badania | diagnoza i konsultacja | system obrazowy/EDM, format obrazu, raport, transfer i błąd | np. badanie naukowe — do osobnej oceny |
Użyj tabeli w wąskim pilotażu: wybierz jedną kategorię danych, prześledź jeden zapis od utworzenia do eksportu i poproś dostawcę o pokazanie odpowiadającej mu historii działań. Następnie wyślij pięć pytań i wymagaj odpowiedzi przypisanej do wersji produktu.
Rozsądnie iść dalej, gdy próbka eksportu zachowuje znaczenie oraz pochodzenie danych, log daje się odczytać, a dostawca pokazuje terminy i dowody testów. Nie zaczynaj integracji AI, gdy dane klienta mają trafiać do trenowania domyślnie, nie ma rozdzielenia celów albo nie wiadomo, kto zatwierdza dostęp. Pierwszym rezultatem nie powinien być certyfikat gotowości, lecz lista potwierdzonych luk, właścicieli i terminów.
Źródła
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2025/327 — EUR-Lex — tekst prawny: prawa pacjenta, priorytetowe kategorie danych, komponenty EHR, dozwolone i zakazane cele wtórne, zezwolenia oraz bezpieczne środowisko. Dziennik Urzędowy UE: 5 marca 2025; sprawdzono: 2026-09-08.
- Komisja Europejska — Europejska przestrzeń danych dotyczących zdrowia — zakres EHDS i harmonogram wdrażania na lata 2027, 2029 i 2031. Sprawdzono: 2026-09-08.
- Komisja Europejska — pytania i odpowiedzi o EHDS — prawa pacjenta, podział na użycie pierwotne i wtórne, interoperacyjność, logowanie oraz wyjątki; aktualizacja: 26 marca 2026; sprawdzono: 2026-09-08.
- Komisja Europejska — certyfikacja systemów EHR — zakres komponentów interoperacyjności i logowania, testowanie oraz dokumentacja producenta. Sprawdzono: 2026-09-08.
- Ministerstwo Zdrowia — wejście w życie rozporządzenia EHDS — polski kontekst wejścia w życie i trzy obszary regulacji; 26 marca 2025; sprawdzono: 2026-09-08.
- Medyc.pl — Elektroniczna Dokumentacja Medyczna — publiczne deklaracje dostawcy o bieżącej obsłudze EDM, P1, HL7 CDA i dostępie zależnym od roli; nie traktujemy ich jako potwierdzenia zgodności z EHDS. Sprawdzono: 2026-09-08.
- Okładka: Tima Miroshnichenko na Pexels
