Voicebot w przychodni: integracja z HIS i checklista wdrożenia

Naturalny głos to najmniejsza część projektu

Przed wdrożeniem voicebota w przychodni sprawdź, czy HIS udostępnia wymagane operacje, jak potwierdzany jest zapis wizyty i kto przejmuje sprawę po błędzie. Poniższa checklista pomaga zebrać dowody od dostawcy i ustalić warunki odbioru przed uruchomieniem połączeń z pacjentami.

Demo voicebota może brzmieć bardzo dobrze po jednym dniu pracy. Produkcyjne wdrożenie zaczyna się dopiero wtedy, gdy rozmowa ma bezpiecznie zmienić coś w systemie placówki. Rezerwacja, odwołanie, potwierdzenie lub utworzenie zgłoszenia wymagają poprawnych danych, uprawnień, kontroli konfliktów i audytu.

W 2026 roku Narodowy Instytut Kardiologii zamawiał rozwiązanie zintegrowane z HIS CGM CliniNET oraz centralą telefoniczną, obejmujące wizyty ambulatoryjne, badania diagnostyczne, wieloletnie utrzymanie, statystyki i raportowanie. Sam opis zamówienia pokazuje, że prawdziwy voicebot medyczny jest projektem procesowym, nie tylko warstwą głosową.

Ustal jedno źródło prawdy

Najpierw wskaż system, który ostatecznie decyduje o dostępności i statusie wizyty. Może to być HIS, system gabinetowy, kalendarz lub Centralna e-Rejestracja. Voicebot nie powinien samodzielnie utrzymywać równoległej listy terminów, chyba że istnieje formalnie zaprojektowany mechanizm synchronizacji i rozwiązywania konfliktów.

Dla każdej operacji opisz wejście, odpowiedź systemu i wynik biznesowy. „Umów wizytę” to za mało. Potrzebne są typ świadczenia, placówka, lekarz lub poradnia, uprawnienia pacjenta, wymagane skierowanie, zasady pierwszej i kolejnej wizyty oraz kryteria wyświetlenia terminu.

Sprawdź interfejsy, zanim sprzedasz termin wdrożenia

Nazwa systemu HIS nie gwarantuje dostępnego API. Placówka może mieć inną wersję, własne rozszerzenia, umowę ograniczającą dostęp albo integrację przez pośrednika. Trzeba potwierdzić dokumentację, środowisko testowe, sposób uwierzytelnienia, limity, format błędów i wsparcie producenta systemu.

Jeżeli interfejs nie pozwala zapisywać wizyt, można zacząć od wariantu bez zapisu: voicebot udziela zatwierdzonych informacji, zbiera cel rozmowy i tworzy sprawę. To nadal może odciążyć rejestrację. Udawanie pełnej integracji przez wysyłanie wiadomości e-mail prowadzi jednak do rozjazdu między obietnicą a działaniem.

Identyfikacja pacjenta musi odpowiadać ryzyku

Inny poziom pewności wystarczy do podania godzin otwarcia, a inny do zmiany istniejącej wizyty. Proces powinien określać, jakie dane mogą być użyte do odnalezienia sprawy, ile prób jest dozwolonych i kiedy system ma przerwać automatyczną ścieżkę. Nie należy zbierać większej ilości danych tylko dlatego, że rozmowa na to pozwala.

System głosowy nie powinien improwizować sposobu weryfikacji. Pytania, kolejność, komunikaty o błędzie i reguły blokady muszą być zatwierdzone przez placówkę. Wrażliwe dane nie mogą pojawiać się w ogólnych logach technicznych lub powiadomieniach wysyłanych do nieuprawnionych osób.

Zabezpiecz rezerwację przed duplikatem

Między pobraniem wolnego terminu a potwierdzeniem przez pacjenta ktoś inny może go zająć. Voicebot powinien ponownie zweryfikować dostępność, a operacja zapisu musi być odporna na podwójne kliknięcie, ponowienie połączenia i restart systemu. Każde żądanie powinno mieć unikalny klucz i jednoznaczny status.

Jeżeli wynik zapisu jest niejasny, system nie powinien automatycznie próbować drugi raz bez sprawdzenia stanu. Pacjent musi dostać uczciwą informację, a personel widoczną sprawę do weryfikacji. Ta sama zasada dotyczy odwołania i zmiany terminu.

Telefonia i przekazanie do człowieka

Integracja z centralą telefoniczną powinna określać numery, godziny, kolejki, reguły przekazania, identyfikację połączenia i zachowanie po zerwaniu rozmowy. Przekazanie do człowieka bez kontekstu nie rozwiązuje problemu. Rejestratorka powinna zobaczyć powód kontaktu, wykonane kroki i dane, które pacjent już potwierdził.

Trzeba też zdefiniować sytuacje, w których automatyzacja ma się zatrzymać: pilne objawy, skarga, prośba o poradę medyczną, brak zgody na dalszą rozmowę, konflikt danych lub powtarzające się niezrozumienie. Celem nie jest zatrzymanie pacjenta w bocie za wszelką cenę.

Testy odbiorowe, które mają znaczenie

Testy powinny obejmować normalną rozmowę, brak terminu, zajęcie terminu w trakcie rozmowy, błąd HIS, przerwę w telefonii, niepoprawne dane, zmianę języka, odmowę nagrywania, pilną sytuację oraz restart usługi w trakcie operacji. Dla każdego przypadku trzeba określić oczekiwany wynik i ślad w audycie.

Przed uruchomieniem produkcyjnym sprawdź również raporty, alerty i odtwarzanie po awarii. System jest gotowy dopiero wtedy, gdy zespół potrafi wykryć brak działania i bezpiecznie obsłużyć zaległe sprawy. Brak błędu na ekranie nie oznacza, że proces wykonał się poprawnie.

• Centralna e-Rejestracja: obowiązki placówki
• Dane pacjentów i nagrywanie rozmów

Przykład testowy: brak odpowiedzi po rezerwacji

To scenariusz do testów, a nie opis wdrożenia u klienta. Pacjent wybiera wolny termin. Voicebot wysyła żądanie rezerwacji, lecz połączenie z HIS urywa się przed odpowiedzią. Nie wiadomo jeszcze, czy wizyta została zapisana.

Asystent informuje, że termin wymaga sprawdzenia. Integracja odczytuje wynik po identyfikatorze żądania. Jeżeli potwierdzi zapis, przekazuje pacjentowi datę, godzinę i placówkę. Jeżeli nie potrafi rozstrzygnąć wyniku, tworzy sprawę dla rejestracji zamiast wysyłać drugą rezerwację. Test jest zaliczony, gdy kalendarz, komunikat dla pacjenta i zapis sprawy są ze sobą zgodne.