Asystent AI dla przychodni.

Sytuacja

Przychodnia pracuje na komercyjnym systemie gabinetowym: wizyty, grafik, rozliczenia z ubezpieczycielami. Producent nie daje dostępu do bazy, a w godzinach przyjęć program jest zbyt obciążony, żeby dokładać mu pracy.

Właściciel chciał dwóch rzeczy: żeby dane o wizytach wychodziły z programu same i żeby personel mógł o nie pytać zwykłym językiem, bez informatyka. Warunek brzegowy od pierwszej rozmowy: tożsamość pacjentów nie trafia do żadnego modelu językowego.

Co nie działało

Dane były w programie, ale program nie oddawał ich nikomu poza ekranem.

• Każdy raport to ta sama sekwencja: logowanie, widok wizyt, data, drukarka, podgląd wydruku, eksport, zapis pliku. Dzień po dniu, ręcznie.
• Eksport to wydruk przełożony na CSV: preambuła placówki, nagłówek zawinięty na dwie linie, lekarz w osobnym wierszu zamiast w kolumnie. Przed analizą trzeba było go czyścić.
• Pytanie w rodzaju „ilu pacjentów danego ubezpieczyciela mieliśmy w sierpniu” wymagało kogoś, kto usiądzie i policzy.

Co zbudowaliśmy

Trzy elementy, każdy z jednym zadaniem.

• Ekstraktor (.NET 8, UI Automation): loguje się do systemu gabinetowego na koncie technicznym z rolą rejestracji i klika w interfejs tak jak człowiek. Nie dotyka bazy, nie czyta siatki wizyt z ekranu, nie uruchamia się w godzinach pracy. Pliki dzienne scala w jedną płaską tabelę z kolumnami lekarza i daty.
• Baza i czat: pliki trafiają do PostgreSQL, a zespół dostaje kanały w Rocket.Chat z botem w Pythonie podpiętym do Claude API. Bot zamienia pytanie po polsku na zapytanie tylko do odczytu i odpowiada w kanale.
• Porównywarka ubezpieczeń dla recepcji: zestawia dzienne listy wizyt z rozliczeniami ubezpieczycieli. Nocne eksporty są jej wejściem, więc dostała świeże dane bez dodatkowej pracy.

Jak to działa na co dzień

Wieczorem zadanie harmonogramu uruchamia ekstraktor na ostatnie cztery dni. Dni z gotowym plikiem pomija, bieżący zawsze odświeża, więc przerwany przebieg dokańcza się sam następnego wieczoru. Każdy plik musi zawierać w treści zadaną datę, inaczej dzień jest odrzucany: lepsza dziura niż wizyty pod złą datą. Błąd jednego dnia nie przerywa reszty.

Kilka zasad, które kosztowały nas najwięcej nauki: daty wyłącznie w formacie ISO, bo 07-08-2026 znaczy co innego w Polsce i w USA, a argumenty będzie kiedyś generował model; twardy limit 62 dni na zakres, żeby literówka nie uruchomiła setek przejść po GUI systemu medycznego; przycisk fizycznej drukarki nie jest klikany nigdy.

Dane pacjentów, RODO i koszty

Przed wysłaniem czegokolwiek do modelu PESEL, imiona, nazwiska, telefony, e-maile i adresy są zamieniane na tokeny w rodzaju OSOBA-0001. Mapowanie zostaje w lokalnej bazie, osobno dla każdego pokoju czatu, a bot podstawia prawdziwe wartości dopiero w odpowiedzi, po stronie przychodni.

Każde zapytanie ląduje w dzienniku audytu: kto, kiedy, o co i za ile. Budżet dzienny liczymy z kosztu, nie z tokenów, bo cache promptu wielokrotnie zawyża ich licznik. Dostęp do danych jest ustalany per dział. Zmiana w trakcie: czat i baza miały stanąć na VPS w UE, ale serwer przychodni okazał się wystarczająco mocny, więc całość stoi u klienta i dane nie opuszczają placówki.

Stan prac i czego się nauczyliśmy

Ekstraktor działa produkcyjnie od września 2026 i eksportuje dzień w około 25 sekund. Pierwsza wersja potrzebowała 4 do 5 minut, bo przeszukiwała całe drzewo kontrolek razem z siatką wizyt; płytkie szukanie z pominięciem tabel dało dziesięciokrotne przyspieszenie. Ładowanie do bazy i czat są w budowie.

Uczciwie: gdyby producent dawał API albo zaplanowany eksport, ekstraktor byłby zbędny i zaczęlibyśmy od czatu. Automatyzacja interfejsu to ostatnia deska, nie pierwszy wybór, i wymaga pilnowania po każdej aktualizacji programu. Tu innej drogi nie było, więc zbudowaliśmy ją tak, żeby wolała się zatrzymać, niż kliknąć coś złego.