Voicebot medyczny, RODO i nagrywanie rozmów pacjentów: 9 pytań przed startem
Dane zdrowotne, nagrania, transkrypcje, retencja i dostawcy AI. Praktyczna lista kontrolna dla placówki wdrażającej głosowego asystenta.
Rozmowa administracyjna może szybko stać się rozmową o zdrowiu
Pacjent dzwoni, aby przełożyć wizytę, ale w pierwszym zdaniu opisuje objawy, leczenie albo wynik badania. Voicebot może więc zebrać dane dotyczące zdrowia, nawet jeśli scenariusz miał dotyczyć wyłącznie kalendarza. Nagranie, transkrypcja i automatyczne podsumowanie mogą zawierać więcej informacji niż formularz rejestracyjny.
UODO zwracał uwagę na ryzyka związane z danymi zdrowotnymi i cechami biometrycznymi w projektach głosowych. To nie oznacza zakazu voicebotów. Oznacza konieczność precyzyjnego celu, ograniczonego zakresu, właściwej podstawy prawnej, przejrzystości i zabezpieczeń odpowiadających realnemu ryzyku.
1. Jaki jest dokładny cel rozmowy?
Cel „obsługa pacjenta” jest zbyt szeroki. Osobno opisz udzielanie informacji, potwierdzenie wizyty, zmianę terminu, zebranie zgłoszenia, przekazanie do poradni i kampanię przypominającą. Dla każdego procesu określ minimalne dane i wynik, który system może wykonać.
Jeżeli dane są później wykorzystywane do trenowania, analityki, oceny jakości albo tworzenia nowych funkcji, trzeba ocenić te cele osobno. Nie wolno zakładać, że informacja o nagrywaniu automatycznie legalizuje każde dalsze użycie materiału.
2. Czy nagranie jest naprawdę potrzebne?
Nie każdy proces wymaga przechowywania pełnego audio. Czasem wystarczy struktura sprawy i techniczny zapis zdarzeń. W innych przypadkach nagranie może być potrzebne do jakości, reklamacji lub bezpieczeństwa. Decyzja powinna wynikać z celu, a nie z domyślnego ustawienia platformy.
Jeżeli nagrywanie jest włączone, placówka musi ustalić komunikat dla pacjenta, podstawę przetwarzania, dostęp, okres przechowywania i procedurę realizacji praw. Trzeba również wiedzieć, czy nagranie trafia do kolejnych podwykonawców i w jakim kraju jest przetwarzane.
3–4. Co trafia do transkrypcji i jak długo zostaje?
Transkrypcja ułatwia wyszukiwanie i przekazanie sprawy, ale tworzy łatwy do kopiowania dokument zawierający słowa pacjenta. Warto ograniczać widoczność, usuwać zbędne fragmenty, oddzielać log techniczny od treści medycznej i nie wysyłać pełnych transkrypcji zwykłym e-mailem.
Retencja powinna być różna dla różnych danych. Log błędu, nagranie, transkrypcja, podsumowanie i rekord wizyty nie muszą być przechowywane tak samo długo. System powinien technicznie wykonywać ustalone okresy, a nie liczyć na ręczne sprzątanie.
5–6. Kto ma dostęp i którzy dostawcy widzą dane?
Dostęp powinien odpowiadać zadaniu. Administrator techniczny nie potrzebuje automatycznie pełnej treści wszystkich rozmów, a każdy pracownik rejestracji nie musi widzieć spraw każdej poradni. Potrzebne są role, uwierzytelnianie, rejestr dostępu i regularny przegląd uprawnień.
Łańcuch dostawcy może obejmować telefonię, rozpoznawanie i syntezę mowy, model językowy, hosting, monitoring oraz system docelowy. Placówka powinna znać te podmioty, lokalizacje danych, zasady dalszego podpowierzenia, mechanizmy transferu oraz zachowanie po zakończeniu umowy.
7–8. Co system robi przy pilnej sytuacji i sprzeciwie pacjenta?
Voicebot administracyjny nie powinien diagnozować. Musi jednak mieć zatwierdzoną procedurę, gdy pacjent opisuje sytuację mogącą wymagać pilnej pomocy. Może przerwać zwykły proces, przekazać ustalony komunikat i skierować do właściwego kanału, bez oceniania stanu zdrowia.
Pacjent może nie chcieć rozmawiać z AI lub być nagrywany. Placówka powinna określić realną alternatywę: przekazanie do człowieka, oddzwonienie albo inny kanał. Informacja o AI powinna być podana na początku w prostym języku, bez ukrywania jej w długim komunikacie prawnym.
9. Jak wykryjemy błąd i incydent?
Monitoring powinien wykrywać nie tylko awarię telefonu. Potrzebne są alerty dla braku zapisu, nietypowej liczby przerwanych rozmów, nieudanych integracji, nieautoryzowanego dostępu i wysłania danych do niewłaściwego odbiorcy. Każde zdarzenie powinno mieć czas, proces, wynik i osobę odpowiedzialną za reakcję.
Placówka i dostawca muszą z góry ustalić procedurę incydentową: kto analizuje zdarzenie, jak zabezpiecza logi, kiedy informuje inspektora ochrony danych i kto podejmuje decyzję o wyłączeniu systemu. W praktyce prosty wyłącznik jest równie ważny jak atrakcyjny głos.
Dokumenty przed uruchomieniem
Przed startem potrzebne są co najmniej mapa przepływu danych, opis celów, role stron, umowa powierzenia, lista podwykonawców, okresy retencji, matryca dostępu, procedura incydentowa i zatwierdzone scenariusze. W zależności od zakresu oraz ryzyka konieczna może być ocena skutków dla ochrony danych.
To nie jest porada prawna ani uniwersalna checklista zgodności. Każda placówka powinna zaangażować inspektora ochrony danych i osoby odpowiedzialne za bezpieczeństwo, proces medyczny oraz telefonię. Najgorszy moment na pierwsze pytanie o dane pacjenta to dzień przed uruchomieniem.
FAQ
Czy każdy voicebot medyczny musi nagrywać rozmowy?
Nie. Nagrywanie powinno wynikać z konkretnego celu i analizy prawnej. W wielu procesach można ograniczyć się do struktury sprawy i logu zdarzeń.
Czy poinformowanie pacjenta o nagrywaniu wystarczy?
Nie przesądza to o zgodności całego przetwarzania. Trzeba określić cel, podstawę prawną, zakres, retencję, dostęp, odbiorców i prawa pacjenta.
Czy voicebot może pytać o objawy?
Zakres powinien być uzgodniony z placówką. Administracyjny asystent nie powinien diagnozować, a pytania dotyczące pilności wymagają szczególnie ostrożnej, zatwierdzonej procedury.