Streszczenie przed lekturą
- Podpis lekarza nie tłumaczy historii każdego zdania. Przy szkicu AI liczy się także to, z czego powstał fragment i kto go zmienił.
- AI może przygotować tekst roboczy, ale nie staje się autorem obserwacji klinicznej. Finalne znaczenie wpisu oraz decyzję o zapisie zachowuje lekarz.
- Najpewniejszy ślad powstaje w chwili zdarzenia. Późniejsze rozpoznawanie stylu albo watermark nie zastąpi historii generowania, korekty i akceptacji.
- Nie trzeba kopiować pełnego promptu ani nagrania do każdego wpisu. Placówka potrzebuje minimalnego, eksportowalnego rejestru zdarzeń i zasad retencji uzgodnionych z IOD.
W polskiej placówce szkic AI może zacząć się od dyktanda, transkrypcji albo danych już zapisanych w EDM. Potem ktoś dopisuje zdanie, usuwa fragment, kopiuje część notatki do kolejnej wizyty i w końcu składa podpis. Po kilku takich ruchach finalny akapit może wyglądać całkiem zwyczajnie, choć nikt nie potrafi już powiedzieć, czy jego rdzeń powstał z obserwacji lekarza, podpowiedzi narzędzia czy starego szablonu.
To nie jest argument za blokowaniem AI w dokumentacji. Jest to argument za tym, aby od początku odróżnić tekst roboczy od obserwacji klinicznej. Model może uporządkować materiał, wskazać brak albo zaproponować szkic. Lekarz sprawdza znaczenie, koryguje je i zatwierdza wpis. Gdy system nie potrafi pokazać tej historii, placówka powinna potraktować to jako problem procesu, a nie drobny brak w panelu.
Stan na 15 lipca 2026 r.: świeża perspektywa w npj Digital Medicine opisuje traceability jako rozpoznanie wkładu AI, źródła rekomendacji i kontekstu wejściowego. Nie jest to jednak instrukcja prawna ani dowód, że jeden konkretny sposób logowania działa w każdej placówce. Dla polskiego lekarza ważniejsza od efektownej etykiety jest możliwość odtworzenia zdarzeń przed podpisem.
Najważniejsze
- Nie wykrywaj AI po stylu gotowego tekstu. Proś o zapis zdarzenia w chwili generowania oraz o historię późniejszych korekt.
- Oddziel fragment, jego źródło i decyzję kliniczną. AI może mieć rolę narzędzia w historii wpisu, ale nie przejmuje roli osoby sporządzającej dokumentację.
- Zapisuj minimum potrzebne do wyjaśnienia pochodzenia. Identyfikator wersji, czas, źródło wejścia, wersja narzędzia, zakres korekty i finalna akceptacja są użyteczniejsze niż kopia całej rozmowy.
- Wymagaj eksportu historii zdarzeń. Jeżeli po zmianie dostawcy nie da się odtworzyć, co zmienił człowiek, a co przygotował system, ślad audytowy zostaje zamknięty w jednym produkcie.
Karta śladu fragmentu przed zapisem
Najprostszy standard nie musi oznaczać nowego ekranu dla każdej frazy. Chodzi o powiązanie fragmentu z krótką historią zdarzeń, którą lekarz może zobaczyć przed podpisem, a placówka może wyeksportować przy kontroli lub migracji systemu. Pełne dane wejściowe nie powinny być bezmyślnie duplikowane tylko po to, aby ślad wyglądał imponująco.
| Pole śladu | Co zapisuje system | Po co lekarzowi |
|---|---|---|
| Identyfikator fragmentu i wersji | Powiązanie zdania lub bloku z konkretną wersją wpisu | Pozwala sprawdzić, czy fragment wrócił z poprzedniej wizyty albo został zastąpiony |
| Zdarzenie i czas | Generowanie, edycja, akceptacja albo podpis wraz z czasem | Odtwarza kolejność pracy bez zgadywania po wyglądzie tekstu |
| Rola AI oraz wydanie narzędzia | Czy narzędzie transkrybowało, streszczało czy zaproponowało szkic; identyfikator wersji lub release | Ułatwia rozmowę o ograniczeniach danego zastosowania, nie o ogólnym haśle AI |
| Wskaźnik do źródła wejścia | Identyfikator rekordu, odcinek czasu transkrypcji lub zbiór użytych danych, bez automatycznej kopii pełnej treści | Pokazuje, z czego powstał szkic i pomaga ograniczyć zbędną retencję |
| Korekta człowieka | Identyfikator osoby uprawnionej, zakres zmiany lub diff | Odróżnia redakcję lekarza od tekstu, który system jedynie zaproponował |
| Decyzja końcowa | Akceptacja, odrzucenie albo podpis oraz osoba podejmująca decyzję | Zostawia jasny punkt odpowiedzialności za wpis kliniczny |
Taką kartę warto traktować jako minimalny kontrakt procesu, a nie obietnicę zgodności prawnej. Zespół z IOD ustala, jak długo zachować poszczególne elementy i kto ma do nich dostęp. Lekarz potrzebuje zaś odpowiedzi na prostsze pytanie: co dokładnie zatwierdzam i skąd to się wzięło?
Podpis lekarza nie opisuje historii zdania
Polskie rozporządzenie o dokumentacji medycznej nie wprowadza dziś osobnego obowiązku etykietowania każdego słowa wygenerowanego przez AI. Wymaga jednak integralności treści i metadanych, identyfikacji osoby sporządzającej wpis lub zmianę, czasu oraz zakresu zmiany. To jest praktyczna podstawa do wymagania historii zdarzeń od systemu, nawet jeśli przepisy nie używają słowa proweniencja.
Sam podpis, nie odpowiada jeszcze na pytanie, skąd wzięło się zdanie w poprzedniej wersji. Jeżeli lekarz poprawił szkic, podpis wskazuje osobę odpowiedzialną za finalny wpis, ale nie powinien zamieniać niezweryfikowanej frazy w domniemaną obserwację kliniczną. Właśnie dlatego widok różnicy i źródła ma znaczenie przed zatwierdzeniem, nie dopiero po incydencie.
Podobny problem pokazuje świeże badanie jakościowe z jednej amerykańskiej placówki: klinicyści poprawiali notatki ambient AI z powodu dokładności, specjalistycznej precyzji oraz wymogów dokumentacyjnych. To nie jest dowód dla polskiego rynku ani miernik bezpieczeństwa konkretnego produktu. Jest natomiast rozsądnym ostrzeżeniem, że korekta jest częścią procesu, a nie wstydliwym wyjątkiem.
Gdzie zaczyna się granica odpowiedzialności
Źródło fragmentu i jego znaczenie kliniczne to dwie różne sprawy. AI może wskazać, że zdanie pochodzi z transkrypcji albo ze szkicu, lecz nie może samo przesądzić, że zdanie prawidłowo opisuje stan pacjenta. Finalna interpretacja należy do lekarza, podobnie jak decyzja, czy dany fragment w ogóle zostaje w dokumentacji.
Właśnie tu nie warto mieszać tematu z samą zgodą na nagranie lub retencją audio. Jeśli placówka korzysta z transkrypcji, te zasady opisuje osobno artykuł o workflow zatwierdzania transkrypcji w gabinecie. Ślad fragmentu odpowiada na późniejsze pytanie o jego drogę w EDM, także wtedy, gdy materiał wejściowy dawno został usunięty zgodnie z procedurą.
AI Act przewiduje automatyczne logi w cyklu życia systemów wysokiego ryzyka. Zwykły szkic dokumentacji nie staje się przez to automatycznie systemem wysokiego ryzyka; klasyfikacja zależy od przeznaczenia i trzeba ją sprawdzić z dostawcą oraz w odpowiednim procesie prawnym. Dla każdego rozwiązania warto jednak zadać operacyjne pytanie: czy po tygodniu da się odtworzyć, który tekst przygotował system i co zmienił człowiek?
Karta decyzji dla lekarza
Można bezpieczniej rozważać szkic AI, gdy przed zapisem widać historię fragmentu, lekarz może ją przeczytać, a system pozwala wyeksportować zdarzenia wraz z wersją wpisu. Nie chodzi o to, by lekarz analizował każdy przecinek, lecz o możliwość sprawdzenia fragmentu, który budzi wątpliwość.
Zatrzymaj rozszerzanie użycia, jeśli narzędzie pokazuje wyłącznie finalną notatkę, nie odróżnia korekty od ponownego generowania albo nie daje historii po migracji czy zmianie abonamentu. W takim układzie podpis lekarza pozostaje konieczny, ale sam nie daje placówce dobrej odpowiedzi na pytanie o pochodzenie.
Nie buduj tego śladu na kopiach wszystkiego. Pełne prompty, nagrania i zrzuty danych mogą zwiększać zakres retencji bez poprawy decyzji lekarza. Minimalizację danych, okres przechowywania i uprawnienia trzeba ustalić z IOD oraz osobą odpowiedzialną za dokumentację.
Czy system potrafi to pokazać?
W rozmowie z dostawcą nie wystarczy pytanie, czy narzędzie ma audyt log. Poproś o demonstrację na syntetycznym wpisie, w której system pokaże generowanie fragmentu, korektę lekarza, odrzucenie jednej propozycji i eksport historii. Pytaj o wersję narzędzia, zakres diffu, identyfikator źródła i zachowanie danych po migracji.
To porząduje rozmowę z dostawcą, ale nie zwalnia zespołu z przeczytania finalnego wpisu. Dobra odpowiedź dostawcy ma pokazać działanie, nie tylko deklarację w regulaminie. Jeżeli demo kończy się na pięknie sformatowanej notatce, a pytanie o historię prowadzi do zrzutu ekranu bez eksportu, brakuje części procesu ważnej dla placówki.
Technicznym wzorcem może być zasób FHIR Provenance, który opisuje kto lub co utworzyło albo zmieniło zasób, kiedy to nastąpiło i z jakimi danymi jest powiązane. Nie jest to automatyczny wymóg dla polskiego EDM ani skrót do zgodności z P1. Jest natomiast zrozumiałym językiem wymagań dla dostawcy: generacja AI, korekta lekarza i podpis są oddzielnymi zdarzeniami.
Co mierzyć bez udawania ROI
W tym procesie liczby mają odpowiadać na pytanie o kontrolę, nie o to, ile wizyt uda się dopisać do grafiku. Mierz odsetek wpisów wspartych AI, dla których da się pokazać źródło i osobę zatwierdzającą. Druga sensowna miara to liczba późnych korekt, gdy fragment był już zaakceptowany, oraz czas potrzebny na odtworzenie jego pochodzenia.
Warto też zapisać liczbę przypadków, w których lekarz odrzucił szkic albo oznaczył brak wystarczającego źródła. Wzrost tych zgłoszeń na początku nie musi oznaczać porażki narzędzia; może pokazać, że zespół wreszcie widzi wcześniej niewidoczne korekty. Nie porównuj takich wyników między specjalizacjami bez kontekstu procesu i bez przeglądu lekarza.
Przejście przez syntetyczny wpis
Zamiast uruchamiać tę zasadę na całej dokumentacji, weź jeden fikcyjny wpis bez danych pacjenta. Przejdź przez generowanie, korektę, akceptację i eksport historii razem z lekarzem, osobą od jakości oraz przedstawicielem dostawcy. Celem nie jest sprawdzenie, czy model ładnie pisze, lecz czy każdy etap zostawia zrozumiały ślad.
Po tym przejściu zespół powinien umieć wskazać, który element trzeba wyłączyć, gdy brakuje źródła, oraz kto podejmuje decyzję o poprawie procesu. Dopiero wtedy można ocenić, czy szkic AI rzeczywiście pomaga w dokumentacji, czy tylko przyspiesza tworzenie tekstu bez historii. To mały sprawdzian, ale skutecznie oddziela funkcję demonstracyjną od narzędzia, które da się bezpiecznie włączyć do codziennej pracy.
Źródła
- Nargesi i in. — Tracing the Pen: Electronic Health Records Amid the Rise of Generative AI — Perspective z npj Digital Medicine; opisuje rozróżnienie wkładu AI i człowieka, źródła rekomendacji oraz ograniczenia wykrywania post hoc. Version of Record: 2026-06-23. Sprawdzono: 2026-07-15.
- Guo i in. — Clinicians’ rationale for editing ambient AI-drafted clinical notes — jakościowe badanie z jednej placówki w USA; przydatne jako sygnał typów korekt, ale nie jako wynik dla Polski. Numer wydania: 2026-07-01. Sprawdzono: 2026-07-15.
- Rozporządzenie Ministra Zdrowia w sprawie rodzajów, zakresu i wzorów dokumentacji medycznej oraz sposobu jej przetwarzania — polskie źródło pierwotne dla integralności dokumentacji, osoby sporządzającej wpis lub zmianę, czasu i zakresu zmiany. Sprawdzono: 2026-07-15.
- Rozporządzenie UE 2024/1689 — AI Act — źródło pierwotne dla obowiązku automatycznych logów w systemach wysokiego ryzyka; nie przesądza klasyfikacji zwykłego szkicu EDM. Sprawdzono: 2026-07-15.
- HL7 FHIR R5 — Provenance — techniczny wzorzec relacji kto, co i kiedy utworzył lub zmienił zasób; nie jest samodzielnym wymogiem polskiego systemu P1. Sprawdzono: 2026-07-15.
- Okładka: Plato Terentev na Pexels
