Od 2027 roku szpitale mają raportować dane automatycznie. Nie będzie dodatkowej biurokracji.
#### 2027: automatyczne raportowanie danych ze szpitali – kontekst regulacyjny i założenia
Zgodnie z zapowiedziami przywołanymi w źródle, intencją resortu zdrowia jest odejście od dodatkowych formularzy i ręcznych sprawozdań na rzecz automatycznego pobierania wymaganych informacji bezpośrednio z systemów IT placówek. Celem ma być ograniczenie biurokracji po stronie szpitali, poprawa spójności danych oraz ich szybsza dostępność do analiz systemowych.
Na moment publikacji brak pełnego pakietu aktów wykonawczych precyzujących zakres i format danych, punktów końcowych API oraz mechanizmów kontroli jakości. Można jednak zakładać kontynuację kierunku wyznaczonego przez dotychczasowe obowiązki elektroniczne (EDM, zgłaszanie zdarzeń medycznych do P1, e-recepta, e-skierowanie) i rozwój interoperacyjności w oparciu o standardy branżowe.
Dla dyrektorów i menedżerów oznacza to, że w ciągu najbliższych kilkunastu miesięcy kluczowe będzie przygotowanie organizacji i systemów do zautomatyzowanego, bezpiecznego i wiarygodnego udostępniania danych – tak, aby „brak dodatkowej biurokracji” nie oznaczał jednocześnie „więcej pracy gaszącej pożary” w działach IT, kadr i rozliczeń.
#### Co będzie raportowane automatycznie? Zakres danych i źródła w szpitalu
Szczegóły mają zostać doprecyzowane w przepisach wykonawczych. Na dziś można ostrożnie wskazać kategorie, które najczęściej są wymagane w raportowaniu systemowym i które typowo da się pobierać automatycznie:
– dane o zdarzeniach medycznych i hospitalizacjach: rozpoznania, procedury, daty przyjęcia/wypisu, tryb przyjęcia, informacje o świadczeniodawcy;
– zdarzenia ambulatoryjne: wizyty AOS/SOR/POZ (w szpitalach wieloprofilowych), e-skierowania i ich realizacja;
– EDM lub metadane EDM: dostępność dokumentów medycznych w P1, ich typ, identyfikatory pacjenta i lekarza;
– rozliczenia i produkty rozliczeniowe: dane potrzebne do spójności z płatnikiem (bez dublowania istniejących kanałów, jeżeli tak zdecyduje regulator);
– kadry i zasoby: wybrane wskaźniki dotyczące personelu, łóżek, sprzętu – o ile zostaną wskazane w przepisach;
– jakość i bezpieczeństwo: wskaźniki procesowe i wynikowe, jeżeli staną się częścią automatycznego poboru (obecnie brak jednoznacznego katalogu).
W praktyce oznacza to integrację wielu wewnętrznych źródeł:
– HIS/EMR (oddziały, izba przyjęć, bloki operacyjne),
– RIS/PACS (badania obrazowe i opisy),
– LIS (laboratorium),
– szpitalna apteka (farmacja kliniczna, podania leków),
– kadry/płace, rejestry zasobów,
– moduły EDM oraz integracje z P1.
#### Jak to ma działać technicznie: integracje HIS, EDM, zdarzenia medyczne i API
Aby uniknąć „dodatkowej biurokracji”, państwo powinno „pobrać” to, co już powstaje w toku udzielania świadczeń. Realistyczny model techniczny, który wpisuje się w ten cel:
– interfejsy API po stronie szpitala lub dostawcy HIS udostępniające wymagane zbiory w formacie ustalonym w przepisach (często HL7 FHIR lub inne profile interoperacyjności);
– mechanizmy push/pull: automatyczne publikowanie zdarzeń po ich zajściu (near real time) lub harmonogramowane eksporty różnicowe;
– walidacja syntaktyczna i semantyczna po stronie dostawcy/placówki oraz po stronie centralnej (komunikaty błędów z opisem i kodem);
– logowanie i śledzenie przesyłu (audit trail) — nie tylko dla cyberbezpieczeństwa, ale i rozliczalności menedżerskiej;
– środowisko testowe (sandbox) do weryfikacji integracji przed produkcją.
Placówki, które już dziś konsekwentnie raportują zdarzenia medyczne do P1, posiadają EDM i wystawiają usługowo dane (API), będą w lepszej pozycji startowej. Ci, którzy bazują na ręcznych eksportach „na żądanie”, powinni zaplanować migrację do modelu usługowego.
#### Interoperacyjność i słowniki: identyfikatory, klastry danych i jakość
Automatyzacja nie wybacza niespójności. Kluczowe będzie:
– jednoznaczna identyfikacja pacjenta i personelu: PESEL/pseudoanonymizacja, PWZ, wewnętrzne identyfikatory i mapowanie do rejestrów centralnych;
– słowniki i kodowania: kody ICD-10/ICD-9, słowniki leków, procedur, jednostek organizacyjnych; jeżeli pojawią się nowe wymagania (np. profil FHIR dla wybranych domen), konieczne będzie dostosowanie;
– kompletność i terminowość: reguły walidacyjne (np. brak wypisu bez rozpoznania głównego) powinny być egzekwowane na wejściu do systemu, nie dopiero przy eksporcie;
– de-duplikacja: te same zdarzenia nie mogą być raportowane wielokrotnie w różnych ścieżkach.
Dobrą praktyką jest powołanie właścicieli danych (data owners) dla krytycznych obszarów, w tym medycyny, rozliczeń i kadr, oraz wdrożenie prostych mierników jakości (kompletność, spójność, opóźnienie).
#### Bezpieczeństwo i RODO: automatyzacja bez zwiększania ryzyka
Automatyczny transfer danych to korzyści, ale i nowe wektory ryzyka. Zalecane działania zgodne z RODO i standardami cyberbezpieczeństwa:
– minimalizacja i celowość przetwarzania: przekazywanie wyłącznie danych wymaganych prawem lub umową powierzenia;
– pseudonimizacja/anonymizacja, jeśli przewidziano raporty zagregowane;
– szyfrowanie w tranzycie (TLS) i w spoczynku, segregacja uprawnień, kontrola dostępu oparta o role;
– rejestrowanie dostępu i incydentów, gotowość do zgłoszeń naruszeń;
– przegląd umów powierzenia z dostawcami IT oraz DPIA (ocena skutków dla ochrony danych), zwłaszcza gdy integracja wymaga nowych komponentów.
#### Wpływ na procesy, koszty i relacje z dostawcami systemów
„Brak dodatkowej biurokracji” po stronie klinicznej przenosi ciężar na:
– porządkowanie danych u źródła (procesy rejestracji, dokumentowanie rozpoznań, zamykanie hospitalizacji);
– kompetencje analityczne i integracyjne w IT (API, logowanie błędów, monitorowanie kolejek);
– kontraktowanie i utrzymanie integracji z dostawcami HIS/EMR (SLA, aktualizacje, zgodność ze standardami).
Koszty? W krótkim terminie mogą pojawić się nakłady jednorazowe (modyfikacje systemów, integracje, testy). W horyzoncie kilku lat spodziewane są oszczędności czasu personelu administracyjnego i mniejsze ryzyko kar/zwrotów dzięki lepszej jakości danych. Warto aktywnie negocjować z dostawcami kwestie licencji na API, udziału w testach oraz odpowiedzialności za zgodność ze standardami określonymi przez państwo.
#### Dlaczego to ważne dla placówek
– Mniej ręcznej sprawozdawczości: realna ulga dla działów rozliczeń i statystyki, o ile dane będą poprawne „u źródła”.
– Lepsza jakość danych menedżerskich: skoro wymagane pola muszą być uzupełniane, zyskuje na tym analityka wewnętrzna (np. ścieżki pacjenta, obłożenie, produktywność).
– Szybsze decyzje regulacyjne: krótszy czas od zdarzenia do informacji systemowej może wpływać na wyceny, limity czy finansowanie – warto śledzić te mechanizmy.
– Przewaga konkurencyjna: placówki gotowe wcześniej będą mniej narażone na przestoje, błędy w raportach oraz koszty „gaszenia pożarów”.
– Zgodność i mniejsze ryzyko: automaty zaszyte w procesach ograniczają przypadkowe braki i niespójności, które dziś skutkują korektami i zwrotami.
– Przygotowanie do kolejnych zmian: interoperacyjny szpital łatwiej adaptuje się do nowych wymogów (np. rozszerzeń EDM, dodatkowych wskaźników jakości).
#### Najczęstsze ryzyka i jak ich uniknąć
– „Technicznie działa, merytorycznie nie”: integracja przekazuje dane, ale kody/rozpoznania są błędne – rozwiązanie: reguły walidacyjne i odpowiedzialność kliniczna za poprawność wpisów.
– Vendor lock-in: jedyny dostawca kontroluje API i harmonogramy – rozwiązanie: umowy SLA, przenoszalność rozwiązań, dokumentacja interfejsów.
– Różne wersje słowników: systemy modułowe używają innych tabel – rozwiązanie: centralny słownik referencyjny i harmonogram aktualizacji.
– Przeciążenie IT: równoległe projekty konkurują o zasoby – rozwiązanie: program wieloletni z priorytetami, budżet i PMO zdrowotne.
– Bezpieczeństwo: nowe kanały to nowe ryzyka – rozwiązanie: architektura zero trust, testy penetracyjne, audyt logów.
#### Co zrobić teraz (checklista)
– Ustal właścicieli danych i sponsorów:
– wskaż liderów merytorycznych dla obszarów: zdarzenia medyczne, rozliczenia, kadry, EDM.
– powołaj zespół ds. jakości danych i integracji (IT + medycyna + rozliczenia).
– Zrób inwentaryzację systemów i przepływów:
– lista systemów (HIS/EMR, RIS/PACS, LIS, apteka, kadry) i ich interfejsów.
– mapowanie danych do słowników krajowych (ICD-10, procedury).
– identyfikacja braków w API i eksportach.
– Podnieś jakość danych u źródła:
– włącz walidacje obowiązkowych pól w rejestracji i wypisie.
– uzgodnij zasady kodowania rozpoznań/procedur (instrukcje wewnętrzne).
– zaplanuj szkolenia dla personelu.
– Zaprojektuj architekturę integracji:
– wybierz mechanizm (API FHIR/REST, komunikaty HL7, kolejkowanie).
– przygotuj repozytorium logów i monitorowanie (alerty błędów).
– przewidź środowisko testowe/sandbox.
– Uporządkuj kwestie prawne i bezpieczeństwo:
– aktualizuj rejestr czynności przetwarzania i umowy powierzenia.
– wykonaj DPIA dla nowych przepływów danych.
– zweryfikuj szyfrowanie, kontrolę dostępu, audyt.
– Zaplanuj projekt i budżet:
– harmonogram na 12–18 miesięcy z kamieniami milowymi (analiza – budowa – testy – produkcja).
– rezerwa na modyfikacje po publikacji aktów wykonawczych.
– negocjuj SLA i zakres prac z dostawcami.
– Przetestuj z danymi rzeczywistymi:
– pilotaż na wybranych oddziałach/typach świadczeń.
– testy regresji przy aktualizacjach słowników i wersji oprogramowania.
– Monitoruj otoczenie regulacyjne:
– śledź projekty rozporządzeń i specyfikacje techniczne.
– zgłaszaj uwagi przez organizacje branżowe.
– Komunikuj zmianę w organizacji:
– plan komunikacji dla kadr medycznych i administracji.
– tablica wyników jakości danych i raportowanie postępu.
#### Harmonogram i niepewności: co wiemy, a czego jeszcze nie
– Kierunek: automatyczne raportowanie bez dodatkowych formularzy – potwierdzone deklaracyjnie w źródle.
– Termin: wskazywany rok 2027 – należy jednak założyć, że szczegółowe terminy wdrożeń (pilotaże, obowiązki etapowane) będą doprecyzowane w aktach wykonawczych.
– Zakres: najpewniej obejmie dane już generowane w ramach istniejących procesów (EDM, zdarzenia medyczne), ale katalog i formaty nie są jeszcze opublikowane w pełni.
– Standardy: oczekiwane wykorzystanie istniejących rozwiązań (np. P1, interfejsy API, profile interoperacyjności). Szczegółowe specyfikacje mogą się zmieniać w toku konsultacji.
W praktyce warto przyjąć podejście „no regret”: inwestować w jakość danych, porządkować słowniki, budować API i monitorowanie – to działania, które przyniosą korzyści niezależnie od końcowych detali technicznych.
#### Podsumowanie dla zarządzających
Automatyczne raportowanie od 2027 roku to nie tylko wymóg, ale szansa. Szpital, który przygotuje dane, procesy i integracje, ograniczy obciążenia administracyjne, poprawi własną analitykę i łatwiej przejdzie przez audyty jakości i rozliczeń. Kluczem jest wczesny start, jasne role właścicieli danych, partnerska współpraca z dostawcami i konsekwentna praca nad standardami oraz bezpieczeństwem. Największym ryzykiem nie jest sama technologia, lecz pozostawienie porządku danych „na później”.
Źródło: https://www.rynekzdrowia.pl/Prawo/Od-2027-roku-szpitale-maja-raportowac-dane-automatycznie-Nie-bedzie-dodatkowej-biurokracji,277255,2.html