Czego dowiesz się z tego artykułu?

  • Które decyzje w polskiej placówce medycznej AI może tylko przygotować, a które musi zatwierdzić człowiek.
  • Jak rozpisać human-in-the-loop dla rejestracji, komunikatów, zaleceń, triage, dokumentacji, płatności i skarg.
  • Jakie logi i metryki bezpieczeństwa monitorować bez tworzenia nadmiarowego magazynu danych pacjenta.
  • O co zapytać lekarza, IOD, managera i dostawcę przed pilotażem AI.

Największe ryzyko w AI dla placówki medycznej nie brzmi: model się pomyli. Większe ryzyko brzmi: nikt nie wie, kto miał zatrzymać proces, kiedy model się pomylił albo działał poza zakresem. Wtedy odpowiedzialność rozmywa się między recepcją, lekarzem, dostawcą i managerem.

Dlatego human-in-the-loop nie jest ozdobnym hasłem w prezentacji. W polskiej przychodni lub klinice oznacza konkretne punkty zatwierdzenia, role osób uprawnionych, logi decyzji i zasadę, że AI może przygotować materiał roboczy, ale nie przejmuje decyzji klinicznej, prawnej ani organizacyjnej wysokiego ryzyka.

Ja bym zaczynał od mapy decyzji, nie od narzędzia. Jeśli zespół potrafi powiedzieć, co AI może zaproponować, kto to sprawdza i jak mierzymy bezpieczeństwo, dopiero wtedy warto rozmawiać o pilotażu. Bez tego nawet najlepszy model staje się kolejnym nieopisanym skrótem w pracy z danymi pacjenta.

Najważniejsze

  • Human-in-the-loop działa tylko wtedy, gdy człowiek ma realny czas, kompetencje i prawo zatrzymać wynik AI, a nie tylko zatwierdza go automatycznie.
  • Decyzje kliniczne, triage objawów alarmowych, treść zaleceń i finalna dokumentacja medyczna wymagają zatwierdzenia przez lekarza lub uprawniony personel.
  • Rejestracja, płatności i komunikaty organizacyjne też potrzebują kontroli, bo błąd może naruszyć prywatność, prawa pacjenta albo dostęp do świadczenia.
  • To ma sens, gdy placówka ma powtarzalny proces, opisane role, zgodę IOD na zakres danych i metryki bezpieczeństwa po 30 dniach.
  • To nie ma sensu, gdy AI ma samodzielnie klasyfikować pacjentów, wysyłać zalecenia, zmieniać dokumentację albo rozstrzygać skargi bez człowieka.

Najpierw nazwij decyzję, nie narzędzie

Wdrożenia AI często zaczynają się od funkcji: chatbot, voicebot, transkrypcja, podsumowanie, automatyczny follow-up. To jest zrozumiałe, bo funkcje dobrze wyglądają w demo. W placówce medycznej trzeba jednak zejść niżej i zapytać: jaką decyzję podejmuje proces oraz czy ta decyzja dotyka zdrowia, danych pacjenta albo prawa do świadczenia.

Przykład: AI w rejestracji może zebrać powód kontaktu i zaproponować kategorię sprawy. To nie jest jeszcze decyzja kliniczna. Ale jeśli system zaczyna sugerować, że pacjent może poczekać kilka dni mimo opisu objawów alarmowych, wchodzimy w zupełnie inny poziom ryzyka. Granica nie leży w nazwie narzędzia, tylko w skutku dla pacjenta.

Sugeruję rozdzielić trzy warstwy. Pierwsza to wsparcie administracyjne: porządkowanie informacji, przypomnienia, kompletowanie braków. Druga to wsparcie kliniczne: szkic notatki, lista pytań, podsumowanie historii, oznaczenie niepewności. Trzecia to decyzja: kwalifikacja pilności, treść zalecenia, finalny wpis w EDM, odpowiedź na skargę. Im bliżej trzeciej warstwy, tym twardszy musi być nadzór człowieka.

Tabela kontroli: siedem procesów placówki

Poniższa tabela jest praktycznym punktem startu dla managera. Nie zastępuje DPIA, opinii IOD ani decyzji kierownika medycznego, ale pomaga zobaczyć, gdzie AI może przyspieszyć pracę, a gdzie ma się zatrzymać. Najważniejsze jest to, żeby przy każdym procesie przypisać właściciela zatwierdzenia, a nie tylko właściciela narzędzia.

Proces w placówceCo może zrobić AICo musi zatwierdzić człowiekMetryka bezpieczeństwa do monitorowania
RejestracjaZebrać powód kontaktu, zaproponować typ wizyty, wykryć braki w danych kontaktowychKierownik rejestracji lub personel potwierdza termin, kanał kontaktu i wyjątki wymagające pilnej eskalacjiOdsetek spraw przekazanych do człowieka oraz liczba błędnych kategorii wizyty wykrytych przed potwierdzeniem
Komunikat do pacjentaPrzygotować szkic SMS-a, e-maila lub komunikatu w portalu pacjentaUprawniony pracownik zatwierdza treść, grupę odbiorców i brak danych nadmiarowychLiczba wstrzymanych komunikatów z powodu danych wrażliwych lub niejasnej treści
Zalecenie po wizycieUporządkować szkic zaleceń na podstawie zatwierdzonej notatki lekarzaLekarz zatwierdza każde zalecenie kliniczne, dawkowanie, termin kontroli i ostrzeżenia dla pacjentaOdsetek szkiców wymagających dużej korekty oraz liczba błędów klinicznych wyłapanych przed wysyłką
Triage kontaktuOznaczyć słowa kluczowe, objawy alarmowe i potrzebę rozmowy z personelemLekarz, pielęgniarka lub przeszkolony personel decyduje o pilności i dalszej ścieżceCzas eskalacji objawów alarmowych oraz liczba przypadków błędnie nieeskalowanych w audycie próbek
DokumentacjaPrzygotować transkrypt, streszczenie i listę brakujących informacjiLekarz zatwierdza finalny wpis do dokumentacji medycznej i usuwa treści zbędneRóżnica między wersją AI a wersją zatwierdzoną oraz liczba fragmentów oznaczonych jako niepewne
Płatność i rozliczeniePrzypomnieć o płatności, wykryć niezgodność usługi z cennikiem, przygotować status sprawyPracownik administracyjny zatwierdza korektę płatności, zwrot, reklamację lub zmianę świadczeniaLiczba korekt wykonanych po ręcznej weryfikacji oraz odsetek reklamacji płatniczych
Skarga pacjentaSklasyfikować temat skargi, przygotować streszczenie i listę dokumentów do sprawdzeniaManager, osoba ds. jakości lub kierownik medyczny zatwierdza odpowiedź i działania naprawczeCzas pierwszej reakcji, liczba spraw eskalowanych do kierownika oraz kompletność dokumentacji skargi

Warto czytać tę tabelę w poprzek, nie w pionie. AI prawie wszędzie może przygotować materiał roboczy, ale prawie nigdzie nie powinna kończyć procesu bez człowieka. Nawet w płatności czy komunikacie błąd może ujawnić dane pacjenta, wysłać informację do złej osoby albo uruchomić niepotrzebny konflikt.

Gdzie człowiek ma prawo powiedzieć stop

Human-in-the-loop nie działa, jeśli człowiek nie ma realnej możliwości zatrzymania procesu. Jeśli system wysyła komunikat automatycznie, a personel tylko dostaje raport po fakcie, to nie jest nadzór. To jest monitoring zdarzenia. Nadzór zaczyna się przed skutkiem dla pacjenta, nie po nim.

W praktyce placówka powinna ustawić stopery. Pierwszy stoper: dane pacjenta są niepełne albo niepewne. Drugi: treść dotyczy zdrowia, dawkowania, objawów alarmowych, rozpoznania lub dalszego postępowania. Trzeci: komunikat może trafić do wielu pacjentów albo do opiekuna osoby zależnej. Czwarty: sprawa dotyczy skargi, roszczenia, odmowy świadczenia lub błędu organizacyjnego. W każdym z tych miejsc decyzja wraca do człowieka.

Ja bym też wymagał widocznej informacji o pewności systemu. Nie chodzi o magiczny procent, który wszyscy będą udawać, że rozumieją. Chodzi o proste oznaczenia: fragment niepewny, brak danych, konflikt informacji, wymagana weryfikacja. Dobre AI nie powinno udawać pewności, gdy pracuje na słabym nagraniu, niepełnym formularzu albo chaotycznej wiadomości pacjenta.

Dane pacjenta: logi bez zbierania wszystkiego

Placówka potrzebuje śladu audytowego, ale nie powinna przy tej okazji tworzyć drugiej dokumentacji medycznej w logach. Minimalny zestaw zwykle obejmuje: kto użył narzędzia, kiedy, w jakim procesie, jaka była wersja promptu lub konfiguracji, co zaproponowała AI, kto zatwierdził wynik i jaka akcja końcowa została wykonana. To ma pozwolić odtworzyć odpowiedzialność, a nie kolekcjonować pełne historie choroby.

UODO zwraca uwagę na ryzyko utraty kontroli nad celem, zakresem i odpowiedzialnością za przetwarzanie danych przy AI. Dla managera oznacza to bardzo praktyczną zasadę: najpierw decyzje prawne i organizacyjne, potem narzędzie. Jeżeli zespół używa publicznych narzędzi poza wiedzą placówki, nie ma ani rozliczalności, ani kontroli nad tym, jakie dane wyszły poza proces.

Logi powinny być krótkie, celowe i objęte retencją. Nie zapisuj pełnego promptu z danymi pacjenta, jeśli wystarczy identyfikator wersji promptu i opis procesu. Nie trzymaj całego wyniku AI w logu, jeśli wersja zatwierdzona jest w dokumentacji, a roboczy szkic ma określony czas życia. Rozliczalność nie jest zgodą na nadmiarowe gromadzenie danych.

W tematach klinicznych trzeba dodać jeszcze jedną zasadę: lekarz nie może stać się biernym operatorem automatu. Kodeks Etyki Lekarskiej przy korzystaniu z algorytmów AI wskazuje m.in. informowanie pacjenta, zgodę w określonych sytuacjach, stosowanie dopuszczonych algorytmów i to, że ostateczną decyzję diagnostyczną i terapeutyczną podejmuje lekarz. To jest bardzo mocna granica dla każdego procesu z rekomendacją kliniczną.

Przykład z przychodni: poranny triage i skarga

Przykład modelowy - scenariusz pokazuje sposób myślenia o pilotażu. Liczby ilustrują metryki, nie gwarantują wyniku wdrożenia.

Wyobraźmy sobie przychodnię specjalistyczną, która rano dostaje 80 wiadomości i telefonów. Część pacjentów chce zmienić termin, część pyta o przygotowanie do badania, kilka osób opisuje nasilone objawy, a jedna składa skargę na brak informacji po wizycie. Manager chce włączyć AI, żeby uporządkować kolejkę. To rozsądny pomysł tylko wtedy, gdy AI sortuje sprawy, a nie rozstrzyga ich skutki.

W pilotażu AI oznacza wiadomości jako: administracyjne, kliniczne do lekarza, pilne do kontaktu, płatnicze, skarga. Rejestracja zatwierdza sprawy organizacyjne i przekazuje wyjątki. Pielęgniarka lub lekarz sprawdza sprawy z objawami alarmowymi. Manager jakości dostaje streszczenie skargi, ale sam zatwierdza odpowiedź. Pacjent nie dostaje automatycznej odmowy, automatycznego zalecenia ani automatycznej odpowiedzi na skargę.

Po tygodniu placówka mierzy trzy rzeczy: ile spraw AI poprawnie skierowała do właściwej roli, ile razy człowiek zmienił kategorię oraz ile spraw wysokiego ryzyka zostało zatrzymanych przed wysyłką odpowiedzi. Jeżeli system przyspiesza sortowanie, ale człowiek nadal kontroluje skutki, pilotaż ma sens. Jeśli zespół zaczyna przepuszczać wyniki bez czytania, trzeba ograniczyć zakres albo zatrzymać wdrożenie.

Karta pilotażu na pierwszy tydzień

Pierwszy tydzień nie powinien obejmować całej placówki. Wybierz jeden proces i jedną rolę zatwierdzającą, na przykład porządkowanie wiadomości do rejestracji albo szkice komunikatów organizacyjnych. Dopiero gdy zespół rozumie stopery, metryki i logi, można wejść w dokumentację lub wsparcie lekarza.

Poniższy prompt jest do warsztatu wewnętrznego. Nie wklejaj do niego danych pacjenta, PESEL, nazwisk, pełnych historii choroby ani realnych transkryptów. Opisuj proces i role, nie konkretne osoby.

Przygotuj kartę pilotażu human-in-the-loop dla polskiej placówki medycznej.

Kontekst procesu:
- proces: rejestracja / komunikat / zalecenie / triage / dokumentacja / płatność / skarga
- role: rejestracja, lekarz, pielęgniarka, manager, IOD, dostawca narzędzia
- systemy: EDM, grafik, telefonia, portal pacjenta, CRM lub system płatności

Zwróć:
1. co AI może przygotować jako materiał roboczy,
2. które decyzje musi zatwierdzić człowiek,
3. kto ma prawo zatrzymać proces,
4. jakie dane pacjenta mogą się pojawić i jak je ograniczyć,
5. minimalny log: kto, kiedy, wersja konfiguracji, wynik, zatwierdzenie, akcja końcowa,
6. metryki bezpieczeństwa po 7 i 30 dniach,
7. sytuacje, w których pilotaż trzeba zatrzymać.

Nie używaj realnych danych pacjentów ani pełnych opisów medycznych przypadków.

Po tygodniu zrób krótkie spotkanie z lekarzem, rejestracją, managerem i IOD. Nie pytaj tylko, czy było szybciej. Zapytaj, czy zespół wiedział, kiedy zatrzymać AI, czy logi są czytelne, czy pacjent mógłby zrozumieć rolę systemu i czy ktokolwiek musiał obchodzić procedurę, żeby wykonać pracę. To są lepsze wskaźniki dojrzałości niż liczba wygenerowanych odpowiedzi.

Pytania do lekarza, IOD i dostawcy

Do lekarza zapytałbym: które elementy procesu są tylko administracyjne, a które mogą zmienić ocenę kliniczną pacjenta? Kiedy szkic AI pomaga, a kiedy tworzy dodatkową pracę? Jak oznaczać fragmenty niepewne? Lekarz powinien mieć prosty sposób odrzucenia wyniku, bez tłumaczenia się systemowi.

Do IOD zapytałbym: jaka jest podstawa i cel przetwarzania danych w danym procesie, czy potrzebna jest ocena skutków dla ochrony danych, jak ograniczyć zakres logów, jaka ma być retencja i kto po stronie dostawcy może mieć dostęp. IOD nie powinien dostawać gotowego narzędzia do zaakceptowania po fakcie, tylko mapę procesu przed pilotażem.

Do dostawcy zapytałbym: czy dane są wykorzystywane do trenowania modeli, gdzie są przetwarzane, jak wygląda usuwanie, czy system wspiera role i logi, czy da się wyłączyć automatyczną wysyłkę, czy można wersjonować prompty i konfigurację. Jeżeli dostawca nie umie opisać kontroli człowieka, to nie jest jeszcze bezpieczny partner dla procesu z danymi pacjenta.

Na koniec decyzja managera jest prosta, choć nie zawsze wygodna. AI może wejść tam, gdzie placówka umie zatrzymać proces, ograniczyć dane i zmierzyć błędy. Nie powinna wchodzić tam, gdzie człowiek ma tylko podpisać się pod wynikiem, którego nie rozumie albo nie ma czasu sprawdzić. Human-in-the-loop to projekt organizacyjny, nie funkcja w panelu administracyjnym.

Źródła