KI für Praxen und Arztzimmer: Terminverwaltung und Service, keine Diagnose

Eine Praxis mit fünf Ärzten, dreißig Anrufe täglich zur Terminbuchung, drei Viertel davon zur Bestätigung eines Termins oder zur Frage nach der Vorbereitung auf einen Bluttest auf nüchternen Magen. Die Rezeptionistin nimmt jeden einzeln entgegen. Das ist kein Diagnoseproblem. Es ist ein Problem des administrativen Prozesses, das mit KI gelöst werden kann, ohne den klinischen Bereich zu berühren.

Doch dieses Argument wird oft zu weit gedehnt. „KI entscheidet, ob es sich lohnt, zum Arzt zu gehen“ klingt wie eine Entlastung der Rezeption, ist aber ein versteckter Versuch, klinisches Triage durch ein Tool durchzuführen, das weder die Kompetenz noch das Recht dazu hat. Die Grenze zwischen diesen beiden ist konkret. Im Folgenden zeichnen wir sie auf.

Administrative Aufgaben in einer medizinischen Einrichtung sind repetitiv, strukturiert und klar definiert. Genau diese Merkmale, bei denen KI am besten funktioniert.

Terminbuchung und -vereinbarung. Ein KI-Agent mit Zugriff auf die Kalender der Ärzte kann Anfragen für Termine per Chat, SMS oder Formular entgegennehmen, verfügbare Termine vorschlagen und die Reservierung bestätigen. Er kann auch Stornierungen und Verschiebungen verwalten. Er trifft keine klinischen Entscheidungen, sondern verwaltet lediglich die Slots im Zeitplan. Ein vergleichbares technisches Muster beschreiben wir im KI-Agenten zur Terminvereinbarung.

Erinnerungen und Follow-ups. Automatische SMS oder E-Mails 24 Stunden vor dem Termin reduzieren die Anzahl der Nichterscheinungen (Studien schätzen eine Reduktion von 20-40 % der No-Shows in Einrichtungen mit Erinnerungen). Hier findet keine klinische Verarbeitung statt, nur Kontaktdaten und Termin.

FAQ zur Vorbereitung auf Untersuchungen. Die Antwort auf die Frage „Muss ich vor dem TSH-Test nüchtern sein?“ ist eine medizinische Tatsache aus einer Wissensdatenbank, keine klinische Bewertung des Patienten. RAG auf verifizierten Materialien der Praxis (Vorbereitungsprotokolle, Laborstandards) liefert Antworten, die mit den Verfahren der Einrichtung übereinstimmen, ohne das Risiko von Improvisationen des Modells.

Vorläufige Erfassung der Konsultationsgründe. Der Agent kann fragen, worum es bei dem Termin geht, und diese Information vor dem Eintreffen des Patienten an den Arzt weiterleiten. Dies ist eine administrative Strukturierung der Daten, keine Diagnose. Der Unterschied ist einfach: Der Agent fragt „Worum geht es bei dem Termin?“, nicht „Was tut Ihnen weh und wie schwerwiegend könnte es sein?“.

Diese Liste ist kurz, aber absolut.

Interpretation von Symptomen und Behandlungsempfehlung sind dem Arzt vorbehalten. „Ein Patient beschreibt Brustschmerzen und Atemnot — der Agent schlägt vor, dass es wahrscheinlich harmlos ist“ ist ein Szenario mit rechtlichen und medizinischen Konsequenzen, unabhängig davon, wie es in der Benutzeroberfläche verpackt ist.

Klinisches Triage (Bewertung der Dringlichkeit basierend auf Symptomen) obliegt dem medizinischen Personal. Der Agent kann nach dem Grund des Termins fragen und diesen an den Arzt oder die Rezeptionistin weiterleiten. Er darf nicht bewerten, ob der Patient in die Notaufnahme gehen oder eine Woche auf den Termin warten sollte.

Interpretation von Untersuchungsergebnissen. Ergebnisse von Blutbildern, TSH, CRP sind klinische Daten. Die Antwort „Das Ergebnis sieht normal aus“ oder „Das Ergebnis liegt außerhalb des Normbereichs, das bedeutet X“ ist eine Diagnose im rechtlichen Sinne, keine administrative Information.

Der AI Act (Anhang III, Punkt 5) umfasst KI-Systeme, die zur Unterstützung klinischer Entscheidungen eingesetzt werden, als Hochrisikosysteme. Die Implementierung ohne die erforderliche Dokumentation, ohne menschliche Aufsicht und ohne Folgenabschätzung (DPIA) verstößt gegen europäisches Recht. Weiterer rechtlicher Kontext: AI Act in der Medizin und Hochrisikosysteme.

Patientendaten (Name, PESEL, Termin, Grund des Termins) sind personenbezogene Daten. Der Grund des Termins, Untersuchungsergebnisse, Diagnosen sind sensible Daten im Sinne der DSGVO Art. 9 — eine besondere Kategorie, die eine separate Rechtsgrundlage und verstärkte Sicherheitsmaßnahmen erfordert.

Drei architektonische Entscheidungen haben hier den größten Einfluss.

Self-Hosting oder EU-Datenresidenz. Gesundheitsdaten von Patienten sollten die Infrastruktur der Einrichtung oder der EU nicht ohne ausdrückliche Rechtsgrundlage und einen Auftragsverarbeitungsvertrag verlassen. Lokale LLM (Modell, das auf dem Server der Praxis oder in einem EU-Rechenzentrum läuft) beseitigt dieses Problem strukturell. Eine Alternative ist ein Cloud-Anbieter mit Datenresidenz in PL/EU und unterzeichnetem Vertrag gemäß DSGVO Art. 28. Das Muster wird in Self-Hosted LLM und DSGVO besprochen.

PII-Maskierung vor der Verarbeitung. KI-Agenten müssen nicht die vollständigen Patientendaten sehen, um ihre Aufgaben zu erfüllen. PESEL-Nummer, Adresse, Telefonnummer können vor dem Senden an das Modell maskiert werden, wobei nur die Sitzungs-ID erhalten bleibt. Protokolle von Gesprächen, die ohne PII gespeichert werden, verringern das Risiko bei Sicherheitsverletzungen. Die Techniken beschreiben wir in Anonymisierung von PII vor KI.

Aufbewahrung und Recht auf Löschung. Patienten haben das Recht, die Löschung ihrer Daten zu verlangen (DSGVO Art. 17). Die Architektur muss dies technisch unterstützen: Protokolle von Agentengesprächen sollten mit der Patienten-ID verknüpft und auf Anfrage löschbar sein. Die Speicherung von Protokollen in einer inkonsistenten Struktur, aus der nicht ersichtlich ist, wer betroffen ist, ist ein Compliance-Problem, nicht nur ein organisatorisches.

DPIA ist erforderlich, wenn Gesundheitsdaten in großem Umfang verarbeitet werden oder wenn das System automatische Entscheidungen trifft, die den Zugang des Patienten zu Dienstleistungen beeinflussen (z. B. automatische Ablehnung eines Terminantrags basierend auf der Vorgeschichte). Für ein standardmäßiges Terminbuchungssystem ohne automatische Entscheidungen ist eine DPIA möglicherweise nicht erforderlich, aber eine vorläufige Bewertung ist sinnvoll.

Die Implementierung eines KI-Assistenten in einer Praxis dauert 4-8 Wochen für den administrativen Bereich. Die Schritte:

Woche 1-2: Prozessprüfung. Katalog der Fragen, die heute an die Rezeption gerichtet werden. Aufteilung in administrative (automatisierbar) und klinische (immer an den Arzt). Ohne diesen Schritt wird das System auf klinische Fragen antworten, weil Patienten sie stellen.

Woche 2-4: Aufbau der RAG-Wissensdatenbank. Quelldokumente: Vorbereitungsprotokolle für Untersuchungen, Preisliste, Arztpläne, Registrierungsverfahren, FAQ von der Website der Einrichtung. Dies ist der Inhalt, auf dem der Agent basiert. Die Qualität der Wissensdatenbank bestimmt direkt die Qualität der Antworten. Detailliertes Muster: Vorbereitung von Unternehmensdaten für KI.

Woche 3-5: Guardrails und Tests. Jedes System in einer medizinischen Einrichtung muss harte Grenzen haben: eine Liste von Themen, auf die der Agent nicht antwortet (Symptome, Diagnose, Medikamentendosierung), automatische Eskalation zur Rezeptionistin, wenn das Thema den Rahmen sprengt, Disclaimer, dass die Gespräche keine ärztliche Beratung ersetzen.

Woche 5-8: Pilotphase im Shadow-Mode. Der Agent arbeitet parallel zur Rezeptionistin, seine Antworten werden protokolliert und überprüft. Erst nach 2-3 Wochen ohne wesentliche Abweichungen erfolgt die eigenständige Bearbeitung ausgewählter Anfragekategorien. Muster für die Pilotierung: Schritt-für-Schritt-Plan zur KI-Implementierung.

Nicht automatisch. Ein System, das ausschließlich die Administration übernimmt (Terminbuchung, Erinnerungen, FAQ zur Vorbereitung auf Untersuchungen), fällt nicht unter Anhang III des AI Act, der Systeme zur Unterstützung klinischer Entscheidungen betrifft. Die Grenze ist jedoch prozedural, nicht technisch: Wenn der Agent auf Fragen zu Symptomen antwortet oder empfiehlt, ob es sich lohnt, zum Arzt zu gehen, betritt er den klinischen Bereich und die Klassifizierung ändert sich. Der Umfang des Systems muss dokumentiert und durch Guardrails durchgesetzt werden.

Für administrative Daten (Kontakt, Termin) ist die Grundlage meist Art. 6 Abs. 1 lit. b (Vertragserfüllung) oder lit. c (rechtliche Verpflichtung). Für Gesundheitsdaten greift Art. 9 Abs. 2 — in der Praxis einer medizinischen Einrichtung meist lit. h (Gesundheitsvorsorge, medizinische Diagnose, Behandlung durch zur Geheimhaltung verpflichtetes Personal) oder lit. a (ausdrückliche Einwilligung). Die Wahl der Rechtsgrundlage beeinflusst die Möglichkeit der Verarbeitung, die Aufbewahrung und die Rechte des Patienten. Eine Konsultation mit dem Datenschutzbeauftragten wird vor der Implementierung empfohlen.

Ein standardmäßiges System für Termin-Erinnerungen (Name, Termin, Kontaktnummer) erfordert bei typischer Praxisgröße wahrscheinlich keine DPIA. Eine DPIA ist erforderlich, wenn die Verarbeitung ein hohes Risiko für die Rechte natürlicher Personen darstellen kann, insbesondere bei großem Umfang, systematischer Überwachung oder automatischen Entscheidungen mit erheblichen Auswirkungen. Wenn die Erinnerungen Informationen über die Art des Termins oder die Fachrichtung enthalten (was den Gesundheitszustand offenbaren könnte), steigt die Risikoschwelle.

Sie kann strukturierte Informationen sammeln: Grund des Termins (in einem Satz), Dauer der Beschwerden, ob der Patient bereits deswegen behandelt wurde. Sie darf nicht bewerten, die Dringlichkeit klassifizieren oder eine Diagnose aufgrund dieser Informationen vorschlagen. Die gesammelten Daten gehen als Kontext an den Arzt, nicht als Bewertung. Die Grenze ist hier technisch subtil, daher sind präzise Guardrails und Tests vor der Implementierung erforderlich.

Protokolle von Agentengesprächen erfüllen zwei Funktionen: Debugging (kurze Zeit, meist 30-90 Tage) und Nachweisbarkeit des KI-Systems (längere Zeit, verbunden mit der Aufbewahrungsfrist für medizinische Dokumentation). Protokolle, die PII von Patienten enthalten, sollten auf Anfrage gelöscht werden (DSGVO Art. 17) und nicht länger aufbewahrt werden, als es der Zweck erfordert. Die Architektur muss das Auffinden und Löschen von Protokollen eines bestimmten Patienten ermöglichen, ohne die gesamte Systemhistorie zu löschen.