Czego dowiesz się z tego artykułu?

  • Jak oddzielić wpis do Centralnej e-Kolejki od kwalifikacji do planowego zabiegu.
  • Gdzie system lub AI mogą wskazać brak, a gdzie decyzję zatwierdza lekarz.
  • Jaką kartę odpowiedzialności i trzy metryki przygotować przed wdrożeniem.

8 lipca 2026 r. Ministerstwo Zdrowia zapowiedziało Centralną e-Kolejkę dla planowych zabiegów szpitalnych. Pacjent ma wybrać placówkę albo skorzystać z automatycznego przypisania do szpitala w województwie, a etapy mają być widoczne w systemie. To zapowiedź, nie gotowa specyfikacja: komunikat nie podaje finalnych reguł ani terminu uruchomienia.

Dla polskiej prywatnej placówki z kontraktem NFZ granica brzmi: przypisanie placówki lub terminu nie jest kwalifikacją kliniczną. Wewnętrzna AI może oznaczyć brak statusu, duplikat albo niespójność, lecz lekarz zatwierdza kwalifikację, a rejestracja przekazuje potwierdzony stan.

Najważniejsze

  • Traktuj e-Kolejkę jako zapowiedziany mechanizm zapisów, nie automat kwalifikujący do zabiegu.
  • Rozdziel trzy role: system prowadzi status, rejestracja pilnuje wpisu, lekarz decyduje klinicznie.
  • AI może oznaczać braki i wyjątki, ale nie ustala priorytetu medycznego.
  • Najpierw zmapuj jedną ścieżkę zabiegową, dopiero potem oceniaj integrację.

Termin nie jest kwalifikacją do zabiegu

Placówka powinna rozdzielić wpis, przydzielenie szpitala i kliniczne potwierdzenie zabiegu. Każdy status potrzebuje autora i czasu zmiany. Komunikat „zabieg potwierdzony”, gdy lekarz zatwierdził jedynie konsultację kwalifikacyjną, tworzy ryzyko organizacyjne i kliniczne.

Ja bym wpisał do procedury zasadę: system zarządza kolejnością, człowiek znaczeniem klinicznym. AI może porównać statusy i wskazać wyjątek, ale nie interpretuje skierowania ani nie zmienia decyzji lekarza. Dane pacjenta pozostają w zatwierdzonym środowisku z uprawnieniami i logiem — nie w publicznym modelu.

Karta decyzji: system – rejestracja – lekarz

Poniższa karta jest roboczym standardem placówki, nie opisem finalnej specyfikacji e-Kolejki. Pokazuje, gdzie kończy się automatyczny status, a zaczyna odpowiedzialność osoby uprawnionej.

EtapSystem lub AIRejestracjaLekarz
Wpiszapisuje status, wskazuje duplikatpotwierdza dane administracyjnenie kwalifikuje na podstawie wpisu
Wyjątekoznacza niespójnośćkieruje ją do właściwej roliocenia znaczenie kliniczne
Potwierdzenieutrwala zmianę i autoraprzekazuje zatwierdzony komunikatzatwierdza kwalifikację
Zmianazachowuje historięzamyka zadania w systemachponownie ocenia przesłanki kliniczne

Human-in-the-loop wymaga właściciela wyjątku, terminu reakcji i śladu decyzji. Żaden status nie powinien znikać po nadpisaniu, a komunikat dla pacjenta musi odróżniać zapis, konsultację i potwierdzony zabieg.

Przykład: prywatna placówka szpitalna mapuje jedną ścieżkę zabiegową. System widzi podwójny wpis, zatwierdzona AI oznacza niespójność, rejestracja sprawdza warstwę administracyjną, a lekarz potwierdza kwalifikację i priorytet. Pacjent dostaje komunikat dopiero po tej decyzji; przykład nie wykorzystuje realnych danych pacjenta.

To ma sens, gdy placówka ma osobne statusy, właściciela wyjątku i log zatwierdzenia. To nie ma sensu, gdy automatyczne przypisanie jest przedstawiane jako obietnica zabiegu albo AI ma ustalać priorytet kliniczny.

Trzy liczby i pierwszy krok

Po starcie mierz czas do potwierdzenia statusu, liczbę wykrytych duplikatów oraz odsetek wyjątków zatwierdzonych przez lekarza z zachowanym śladem. Liczba przydzielonych terminów nie pokaże, czy proces jest bezpieczny.

Sugeruję zacząć od mapy jednego rodzaju zabiegu: statusy, role, komunikaty, wyjątki i logi. Nie wdrażaj integracji na podstawie samej zapowiedzi; najpierw uzyskaj aktualną specyfikację MZ, CeZ lub dostawcy systemu i przypisz osobę do jej weryfikacji.

Źródła