Was wir beim Aufbau eines Gesundheits-Chatbots für internationale Patienten gelernt haben

💡 Kurzfassung:

• Das Projekt: VaniBot unterstützt bei Vanity Hospital die Kommunikation vor der Beratung und die strukturierte Erfassung internationaler Patientenanfragen. Anschließend übergibt das System das Gespräch an das zuständige Team.
• Die technische Entscheidung: In unserer damaligen Bewertung erfüllte ein gehostetes OpenAI-Modell unsere Anforderungen an Gesprächsqualität, Zuverlässigkeit und Betrieb besser als die von uns getesteten selbst betriebenen Alternativen.
• Die Erkenntnis: In dieser Anwendung reduzierte der Chatbot wiederkehrende Kommunikationsarbeit, ohne medizinische Beurteilung oder folgenreiche Entscheidungen von qualifizierten Menschen zu übernehmen.

Bei Vanity Cosmetic Surgery Hospital beginnen die meisten Anfragen internationaler Patienten über digitale Kanäle. Sie kommen im Tagesverlauf aus verschiedenen Ländern und Zeitzonen.

In unserem Ablauf bedeuteten verspätete Antworten häufig, dass ein Gespräch nicht fortgesetzt wurde. Reaktionszeit war damit ein betriebliches Problem, nicht nur eine Messaging-Kennzahl. Wir starteten VaniBot, um diese Verzögerungen zu verkürzen und zu verhindern, dass passende Anfragen ins Stocken gerieten.

Das Projekt ging bald über die Chat-Oberfläche hinaus. Es veränderte interne Abläufe, Zuständigkeiten, Integrationen und die Zusammenarbeit der Patientenbetreuung mit der Technik.

Wir betreiben das System seit ungefähr einem Jahr. Intern nennen wir es VaniBot, doch sein Umfang entspricht nicht dem eines FAQ-Bots im Einzelhandel. Anfragen internationaler Patienten können persönliche und medizinische Informationen zu einer folgenreichen Entscheidung wie einer Operation enthalten.

Eine Grenze ist wesentlich: VaniBot unterstützt Kommunikation und Datenerfassung vor der Beratung. Die endgültige medizinische Beurteilung oder Behandlungsentscheidung trifft das System nicht. Sobald fachliches Urteil erforderlich ist, gehört das Gespräch in die Hände der Patientenbetreuung und qualifizierten medizinischen Personals.

Die Datenarchitektur von VaniBot dokumentiere ich in diesem Beitrag nicht. Jedes Team, das ein gehostetes Modell in einem Gesundheitsablauf einsetzt, muss gesondert prüfen, welche Daten das Modell erreichen, wer darauf zugreifen kann, wie lange sie gespeichert werden und welche Datenschutzpflichten gelten. Auch die aktuelle Dokumentation von OpenAI zu Datenkontrollen der API stellt klar, dass Aufbewahrung und die Berechtigung für Zero Data Retention vom Endpunkt, der Funktion und der Konfiguration abhängen.

Die folgenden Erkenntnisse betreffen den Betrieb des Gesamtsystems: Zuständigkeit, Kanäle, Integrationen, Modellwahl und den Punkt, an dem Automatisierung an einen Menschen übergeben muss.

Zentrale Erkenntnisse aus dem Prozess

1. Das Projekt ist nach dem Start nicht erledigt

Einen Chatbot baut man nicht einmal und wendet sich dann dem Nächsten zu. Antwortzeiten, Qualität der Übergaben, Fehler im Ablauf und tatsächliche Nutzerinteraktionen müssen regelmäßig überprüft werden. Verbesserungen müssen nach dem Start weitergehen.

Das ist nicht allein Aufgabe der IT. Alle, deren Arbeit der Bot unterstützt oder verändert, müssen beteiligt sein.

2. In unserem Team unterstützte der Bot Menschen, statt sie zu ersetzen

In unserem Team verlor niemand wegen VaniBot seinen Arbeitsplatz. In dieser Anwendung nahm das System wiederkehrende Kommunikationsaufgaben ab und schuf mehr Raum für Tätigkeiten, die Kontext und Urteil erforderten.

Mit der Zeit behandelte das Team VaniBot wie einen gemeinsamen digitalen Assistenten. Wie stark sich die tägliche Arbeit um das System herum angepasst hatte, wurde zum deutlichsten Zeichen der betrieblichen Nutzung.

3. Die tatsächlichen Kosten bestehen nicht nur aus Geld

Ein verbreitetes Missverständnis lautet: „Wir zahlen einem Anbieter 5.000 im Monat, dann wird alles erledigt.“

Damit etwas wirklich funktioniert, benötigen Sie:

• echte Aufmerksamkeit Ihres Teams
• Zusammenarbeit zwischen Abteilungen
• eine belastbare IT-Infrastruktur
• laufende Unterstützung und klare Zuständigkeit
• auch bei einem Anbieter einen langfristigen Partner, der das Ziel versteht

Andernfalls verbrauchen Sie sowohl Ihr Geld als auch Ihre Erwartungen.

4. Die Integration mehrerer Kanäle ist der schwierigste Teil

Einen Bot in eine Website einzubinden, war für uns der einfachere Teil. Denselben Ablauf über Kanäle wie WhatsApp und Instagram zuverlässig zu betreiben, erzeugte deutlich mehr Komplexität.

5. Eine solide interne API-Schicht half erheblich

Für unser CRM und andere betriebliche Systeme verfügten wir bereits über stabile interne APIs. Deshalb mussten wir die Integrationsschicht nicht neu erfinden. Wir konnten uns auf die Logik des Bots und die Gestaltung der Gespräche konzentrieren, was Zeit und Komplexität sparte.

6. Unsere Modellentscheidung: selbst betreiben oder verwalteten Dienst nutzen?

Wir erwogen ein selbst betriebenes Open-Source-Modell, und ich führte einige kleinere Tests durch. Für die damals verfügbaren Modelle, die Infrastruktur und unsere Anforderungen passte ein gehostetes OpenAI-Modell besser.

Die Entscheidung galt für dieses konkrete Projekt:

• Das gehostete Modell schnitt in unseren Tests bei Gesprächszusammenhang, Kontextbeibehaltung und dem benötigten Interaktionsstil besser ab.
• Selbstbetrieb hätte GPU-Kapazität, Leistung, Verfügbarkeit, Skalierung und Protokollierung zu zusätzlichen Aufgaben des Teams gemacht.
• Während dieses Nutzungsjahres war der gehostete Dienst für uns betrieblich zuverlässig, abgesehen von ein oder zwei globalen Ausfällen.

Das ist keine allgemeingültige Rangfolge gehosteter und quelloffener Modelle. Ein selbst betriebenes Modell kann besser passen, wenn die Aufgabe enger abgegrenzt ist oder mehr Kontrolle über Daten und Infrastruktur erforderlich wird. Für uns war betriebliche Zuverlässigkeit ebenso wichtig wie Modellqualität.

Wo Automatisierung endet und die Übergabe an Menschen beginnt

Mit einer begrenzten Gruppe von Anfragen testeten wir außerdem einige Bot-Abläufe. Wir wollten sehen, ob sie den Prozess vor der Beratung voranbringen konnten, ohne Druck oder Verwirrung zu erzeugen.

Das Ziel war nicht, einen Bot Menschen zu einer medizinischen Entscheidung überreden zu lassen. Das System sollte erkennen, wann es allgemeine Informationen geben, wann es die nächste notwendige Angabe erfassen und wann es einem Menschen Platz machen musste. Wir veröffentlichten aus diesen Tests weder Konversions- noch klinische Ergebnisdaten. Deshalb behandle ich sie als betriebliches Experiment, nicht als Beleg wirtschaftlicher Wirkung.

Abschließende Gedanken

Von außen kann der Aufbau eines Chatbots wie ein weiteres Softwareprojekt wirken. Was wir entwickelten, wurde zu einem umfassenderen betrieblichen System.

Das haben wir aus dem Prozess mitgenommen:

• Ein guter Chatbot ist das Ergebnis der gesamten Organisation, nicht nur des Technikteams.
• Erfolg entsteht durch einfache Logik, starke Integration und eine Kultur kontinuierlicher Verbesserung.
• In unserer Anwendung unterstützte der Bot Menschen, statt sie zu ersetzen.
• Ohne geeignete Backend-Systeme kann selbst der intelligenteste Bot wenig bewirken.
• Automatisierung kann routinemäßige Teile eines Gesprächs voranbringen. Medizinisches Urteil und folgenreiche Entscheidungen brauchen jedoch eine eindeutig verantwortliche Person.

Wir bauten nicht nur eine Chat-Oberfläche. Wir bauten ein betriebliches System, das das Team überwacht, verbessert und als Teil seiner täglichen Arbeit nutzt.