Katalog / Dialogassistenten / CONV-010

Assistent für Patientenaufnahme und Symptom-Ersteinschätzung

Ein Chat- oder Sprachassistent, der vor einem Besuch Symptome und Vorgeschichte erfasst, eine strukturierte Dringlichkeitsempfehlung gibt und Patientinnen und Patienten auf die passende Versorgungsstufe lenkt, für Praxen, Krankenhäuser, Versicherer und Gesundheitsportale.

Bausteine für den EigenbetriebAgenten & AutomatisierungSprachmodellSprache & Audio

Praxen und Krankenhäuser verwenden viel Personalzeit auf Telefonate, Papierformulare und das erneute Abtippen derselben Vorgeschichte, während Patientinnen und Patienten nicht wissen, ob sie abwarten, einen Termin buchen oder in die Notaufnahme gehen sollen. Ein Dialogassistent erfasst Symptome und Vorgeschichte in der Sprache der Patientin oder des Patienten, erkennt Warnzeichen, empfiehlt eine Versorgungsstufe und übergibt den Behandelnden eine strukturierte Zusammenfassung. Die entscheidende Frage ist regulatorisch: Alles, was eine Dringlichkeit oder Versorgungsstufe empfiehlt, ist in der Regel Medizinprodukte-Software und muss CE-gekennzeichnet sein, kein allgemeiner Chatbot.

Problem & Nutzen

  • Heute: Aufnahme per Telefon, Klemmbrett oder Portalformular; das Personal führt die Ersteinschätzung nach Protokoll durch; Patientinnen und Patienten schätzen sich selbst mit Suchmaschinen ein. Telefonleitungen sind überlastet, und dringende Fälle warten gemeinsam mit Routinefällen.
  • Nutzen der KI: strukturierte, mehrsprachige Datenerfassung vor dem Besuch; frühere Erkennung von Warnzeichen; Lenkung der Patientinnen und Patienten auf die richtige Stufe (Selbsthilfe, Hausarzt, dringende Versorgung, Notfall); weniger Abtippen für das Personal; bessere Terminplanung und Kapazitätsnutzung.
  • Die Evidenz ist gemischt und muss sorgfältig gelesen werden. Peer-reviewte Tests allgemeiner LLMs zeigen sowohl Übertriage als auch gefährliche Untertriage. Eine Studie in Nature Medicine von 2026 zu einem Verbraucher- Gesundheits-Chatbot berichtete Untertriage bei 52 % der Notfälle nach Goldstandard, und die Empfehlungen verschoben sich in Richtung weniger dringender Versorgung, wenn Angehörige Symptome herunterspielten [1]. Andere Studien zu Gesprächen in der Notaufnahme zeigen hohe Sensitivität, aber geringe Spezifität, also häufige Übertriage [2]. Eigens entwickelte, zertifizierte Ersteinschätzungs-Engines mit festgelegter klinischer Logik werden anders bewertet. Prüfen Sie jede Herstellerangabe an Ihrer eigenen Patientenpopulation.

Varianten

  • Aufnahme vor dem Besuch (ohne Dringlichkeitsempfehlung): Formulare als Dialog plus Zusammenfassung für die Behandelnden; häufig kein Medizinprodukt, wenn nur Daten erfasst und weitergegeben werden.
  • Symptom-Ersteinschätzung / Versorgungssteuerung: Dringlichkeitsempfehlung. Medizinprodukte-Software.
  • Eingang im Krankenhaus: Aufnahme per Kiosk oder Tablet zur Unterstützung der pflegerischen Ersteinschätzung (Manchester, ESI).
  • Kostenträger / Gesundheitsportal: Mitglieder werden in die Versorgung gelenkt, neben dem Dienst 116117 in Deutschland.
  • Telefonische Sprachaufnahme: Voicebot mit Eskalation an Menschen (CONV-002).
  • Private Nutzung: Symptomchecker-Apps für Verbraucher, siehe Weg A.

So funktioniert es

  1. Kanal (Web-Chat, App, Messenger im WhatsApp-Stil, Sprache, Kiosk)
  2. Identitäts-/Einwilligungsschritt + Transparenzhinweis (KI, keine Ärztin und kein Arzt)
  3. Warnzeichen-Prüfung (deterministische Regeln, immer zuerst; Brustschmerz, Schlaganfallzeichen, Blutung, Suizidalität)
  4. bei Treffer: sofortige Eskalationsmeldung + Übergabe an Mensch/Notruf
  5. adaptives Interview (medizinische Wissensbasis oder eingeschränktes LLM; stellt die jeweils beste nächste Frage)
  6. Ersteinschätzungs-Engine (zertifiziertes Modell/Regeln)
  7. Dringlichkeitsstufe + Versorgungsempfehlung
  8. Erstellung der Zusammenfassung (LLM entwirft, Behandelnde prüfen)
  9. Weiterleitung: Buchung, Rückruf durch Pflegekraft, Entwurf für Patientenakte/FHIR
  10. Protokollierung, Nachverfolgung des Ergebnisses, Qualitätsüberwachung
  • Zwei Architekturfamilien. (1) Zertifizierte probabilistische/regelbasierte Engines (auf Bayes-Netzen oder Wissensgraphen beruhend) steuern die Fragen und die Dringlichkeitsentscheidung; das LLM übernimmt nur die natürliche Sprache ein- und ausgehend. (2) LLM-zentrierte Assistenten schlussfolgern frei; diese sind schwerer zu validieren und sollten auf nichtklinische Aufgaben wie Formularausfüllung und Zusammenfassungen beschränkt bleiben.
  • Deterministisches Sicherheitsnetz: Warnzeichen-Regeln und Eskalation hängen nie von einer LLM-Antwort ab.
  • Mensch-in-der-Schleife (Human-in-the-Loop): Eine Ärztin oder ein Arzt bzw. eine Pflegekraft in der Ersteinschätzung sieht die Zusammenfassung und kann sie übersteuern; Grenzfälle oder Fälle mit geringer Sicherheit, Kinder, Schwangerschaft und psychische Krisen gehen an Menschen. Patientinnen und Patienten können jederzeit einen Menschen oder die Notrufnummer erreichen.

Datenaufbereitung

Benötigte Daten: die Aufnahmefragebögen der Einrichtung, Ersteinschätzungsprotokolle und Leitlinien, Termin- und Fachgebietskataloge sowie anonymisierte frühere Aufnahmedatensätze zum Testen. In einer Praxis oder einem Krankenhaus liegen diese im Praxis- bzw. Krankenhausinformationssystem, im DMS, als Papierformulare am Empfang, als eingescannte Überweisungsschreiben und als PDFs interner SOPs. Typische Lücken: handschriftliche oder gescannte Formulare, unstrukturierte Freitext-Anamnese, uneinheitliche Fachgebietsnamen, veraltete Protokolle, keine gekennzeichneten Ergebnisse und strenge Zugriffsrechte auf Patientenakten.

Aufbereitungsschritte: (1) Quellen und Verantwortliche mit der Praxisleitung und der ärztlichen Leitung erfassen (GUIDE-003); (2) Papierformulare digitalisieren und auf digitale Erfassung an der Quelle umstellen (PREP-006, PREP-008); (3) mit den Behandelnden einen maßgeblichen Protokollsatz vereinbaren (PREP-013, PREP-016); (4) einen Evaluationssatz aus Fällen mit von Fachleuten gekennzeichneten Dringlichkeitsstufen aufbauen (PREP-018, PREP-019); (5) alle zum Testen verwendeten Datensätze pseudonymisieren (PREP-022) und die Rechtsgrundlage für die Zweitnutzung prüfen (PREP-025). Werkzeuge: Paperless-ngx oder ein DMS mit OCR, Presidio, FHIR/HL7-Export aus dem Praxissystem. Rechnen Sie mit etwa 30 % des Aufwands für Datenarbeit, überwiegend Protokollpflege und Testsätze.

Umsetzungswege

Welcher Weg für wen

  • KMU: Weg A, weil Praxen ein CE-gekennzeichnetes, in der EU gehostetes Produkt mit klinischer Validierung brauchen; eine selbst gebaute Ersteinschätzungslogik begründet Haftung als Medizinprodukt.
  • Unternehmen: Weg C, weil Krankenhausgruppen Gesundheitsdaten in großem Umfang verarbeiten und einen Open-Source-Stack auf einer gemeinsamen internen Plattform betreiben können.
  • Entwicklung: Weg B, weil EU-Region-APIs einen schnellen Prototyp der Aufnahmeabläufe erlauben, der vor jeder klinischen Nutzung zertifiziert werden muss.
  • Öffentlicher Sektor: Weg B in einer souveränen EU- oder deutschen Cloud, weil Vergaberecht und Datensouveränität kontrolliertes Hosting begünstigen; Weg A nur für zertifizierte Produkte.
  • Privat: Weg A, weil Patientinnen und Patienten einen regulierten Symptomchecker statt eines allgemeinen Chatbots nutzen sollten.

Weg A — Kaufen (Standardsoftware) (empfohlen)

  • Zertifizierte Ersteinschätzungs-/Aufnahmeplattformen: Infermedica (PL/EU; gibt an, dass seine Medical Guidance Platform mit Triage, Intake und Conversational-Triage-API ein Medizinprodukt der Klasse IIb nach EU-MDR ist) [3], Ada Health (DE; Ada Assess von TÜV SÜD als Klasse IIa zertifiziert) [4], Isabel Health, Symptoma (AT), in Klinik-/Praxissysteme integrierte Werkzeuge wie Doctolib und Patientenportale von Dedalus. Prüfen Sie stets selbst das aktuelle Zertifikat und den Verwendungszweck.
  • Nur Aufnahme und Formulare: Module von Patientenakten-/PVS-Systemen und Patientenportale.
  • A wählen, wenn: Sie eine Dringlichkeitsempfehlung brauchen, kein Regulierungsteam haben und in wenigen Monaten live sein müssen. Prüfen Sie Hosting in der EU, einen Auftragsverarbeitungsvertrag, den Geltungsbereich des MDR-Zertifikats, Sprachen und Schnittstellen zur Patientenakte (HL7 FHIR, KIM, Praxissysteme).

Weg B — Auf Cloud-KI-Diensten aufbauen

  • Nutzen Sie eine zertifizierte Ersteinschätzungs-API für die Dringlichkeitsentscheidung (z. B. die Infermedica Conversational Triage API, eine zustandsbehaftete API, bei der der Server das Gespräch hält [3]) und ein LLM eines Anbieters mit Datenhaltung in der EU (Mistral, Azure OpenAI EU-Regionen, Google Vertex EU, AWS Bedrock Frankfurt) für Sprache, Zusammenfassungen und Formularausfüllung.
  • Integration: Schreibzugriffe über FHIR R4, Kalender- und Warteschlangen-APIs, n8n oder Power Automate für die Weiterleitung.
  • Vorsicht: Gibt Ihr eigenes LLM Dringlichkeitsempfehlungen aus, werden Sie zum Hersteller von Medizinprodukte-Software mit allen Pflichten nach MDR.

Weg C — Selbst betreiben (Open Source)

  • Modelle: LLMs mit offenen Gewichten wie die Familien Mistral, Qwen, Llama oder Gemma, betrieben mit vLLM oder Ollama; medizinisch angepasste offene Modelle (z. B. MedGemma) für Zusammenfassung und Extraktion bei der Aufnahme; Whisper/faster-whisper für ASR; FHIR-Server wie HAPI FHIR.
  • Leitplanken: NeMo Guardrails oder Klassifikatoren im Stil von Llama Guard plus deterministische Warnzeichen-Regeln.
  • Hardware: HW3 für ein quantisiertes 30-70B-Modell, das ein Krankenhaus bedient; HW2 nur für die Aufnahme. Ersteinschätzungsentscheidungen brauchen weiterhin eine validierte, regulierte Komponente.

Weg D — Eigenes Training

Gerechtfertigt für große Krankenhausgruppen oder Krankenversicherer mit historischen Ersteinschätzungsergebnissen: Klassifikatoren auf Basis von Ersteinschätzungsstufen und Ergebnissen (Aufnahme, Wiedervorstellungen) feintunen. Erfordert Tausende von gekennzeichneten, de-identifizierten Fällen, ein Ethikvotum, eine klinische Validierungsstudie und, für die Ausgabe einer Dringlichkeit, eine vollständige Konformitätsbewertung nach MDR einschließlich Überwachung nach dem Inverkehrbringen.

Stand der Technik (2026)

  • Zertifizierte Symptombewertung ist ausgereift: Mehrere EU-Anbieter besitzen eine MDR-Zertifizierung der Klasse IIa/IIb für die Ersteinschätzung; Infermedica gibt außerdem an, dass seine Produkte nach der KI-Verordnung als Hochrisiko eingestuft sind [3][4][8].
  • LLM-Frontends auf validierten Engines sind das vorherrschende Muster: natürlicher Dialog, darunter strukturierte medizinische Logik. Allgemeine Gesundheits-Chatbots für Verbraucher kamen 2026 auf den Markt, doch unabhängige Tests zeigten erhebliche Untertriage bei Notfällen [1].
  • Retrieval-gestützte Ersteinschätzung mit Leitlinienkontext senkte in einer retrospektiven Auswertung die Übertriage (von 28,8 % auf 12,7 % in einer Studie) bei weiterhin geringer Untertriage, braucht aber eine prospektive Validierung [5].
  • Grenzen und Fehlerbilder: Untertriage bei vagen oder heruntergespielten Symptomen; Übertriage, ausgelöst durch Schlüsselwörter wie Blutung oder Schmerz [2]; schwach bei Kindern, Multimorbidität, atypischen Verläufen und Dialekten; halluzinierte klinische Aussagen; Automatisierungsbias beim Personal.

Gemeinsame Bausteine & Kombinationen

Aufwand, Kosten & Kennzahlen

  • Weg A: 2-4 Monate einschließlich Datenschutz-Folgenabschätzung, Anbindung der Patientenakte und klinischer Freigabe; Lizenz je Patienteninteraktion oder je Standort.
  • Weg B: 4-9 Monate; Lizenz für die zertifizierte API plus LLM-Nutzung; die Integration ist der Hauptkostenfaktor.
  • Weg C/D: 9-18+ Monate, wenn die Ausgabe einer Dringlichkeit im Umfang liegt; nur Aufnahme deutlich kürzer.
  • Kennzahlen: Abschlussquote der Aufnahme, Anteil der ohne Änderung akzeptierten Zusammenfassungen, Untertriage- und Übertriage-Rate gegenüber der ärztlichen Referenz (wichtigste Sicherheitskennzahl), Personalzeit je Patient, Wartezeit an der Telefonleitung, Quote nicht wahrgenommener Termine, Anteil der an Menschen eskalierten Patienten, Patienten- zufriedenheit, Barrierefreiheit/Sprachabdeckung, Meldungen unerwünschter Ereignisse.

Menschen & Veränderung

Beginnen Sie mit der ärztlichen Leitung und der Praxis- bzw. Krankenhausleitung, dann mit dem Pflege- und Empfangspersonal, das die Ausgabe täglich nutzt; ziehen Sie die IT für die Integration ins Praxissystem hinzu. Binden Sie die oder den Datenschutzbeauftragte(n) früh ein: Gesundheitsdaten sind Daten besonderer Kategorien, daher sind eine DSFA (Art. 35 DSGVO) und ein AVV (Art. 28 DSGVO) mit jedem Auftragsverarbeiter erforderlich. Recht/Compliance klärt den MDR-Status und die Hochrisiko-Pflichten der KI-Verordnung, die für Systeme nach Anhang III ab dem 2. Dezember 2027 und für KI in Produkten nach Anhang I ab dem 2. August 2028 gelten. Betriebsrat: abhängig. Dient das Werkzeug nur Patientinnen und Patienten, löst es womöglich keine Mitbestimmung aus; sobald aber Interaktionen des Personals oder Übersteuerungsquoten protokolliert werden, ist es zur Leistungsüberwachung geeignet, und §87 Abs. 1 Nr. 6 BetrVG greift; §90 Abs. 1 Nr. 3 verlangt Unterrichtung, wenn sich Arbeitsverfahren ändern, und §80 Abs. 3 erlaubt eine KI-Sachverständige oder einen KI-Sachverständigen. Krankenhäuser in kirchlicher oder öffentlich-rechtlicher Trägerschaft nutzen ihre jeweilige Mitarbeitervertretung.

KI-Kompetenz: Ergreifen Sie nach Art. 4 der KI-Verordnung Maßnahmen zur Förderung der KI-Kompetenz des Personals; schulen Sie das Ersteinschätzungspersonal zu Grenzen, Automatisierungsbias und dazu, wann die Ausgabe zu ignorieren ist. Starten Sie mit einem Pilot an einem Standort oder in einem Fachgebiet, kommunizieren Sie, dass der Assistent vorbereitet, aber nie entscheidet, und begegnen Sie der Sorge vor fehlgeleiteten dringenden Fällen mit der verpflichtenden Warnzeichen-Eskalation an einen Menschen. Siehe GUIDE-005, GUIDE-004 und GUIDE-009.

Risiken, Regulierung & Compliance

  • KI-Verordnung (AI Act): Hochrisiko. Software mit medizinischem Zweck nach MDR/IVDR, die eine Bewertung durch eine benannte Stelle braucht, fällt über Art. 6 Abs. 1 unter Anhang I, und Systeme zur Patientenersteinschätzung in der Notfallversorgung sind in Anhang III Nr. 5 Buchst. d genannt. Datumsprüfung: Das Digital Omnibus (Verordnung (EU) 2026/1744 laut Sekundärberichten) verschiebt Hochrisiko-Pflichten, mit Anhang III laut Berichten auf den 2. Dez. 2027 und in Produkte eingebetteten Systemen nach Anhang I auf den 2. Aug. 2028; gleichen Sie dies mit dem Amtsblatt ab [6]. Die Transparenzpflicht (Art. 50: Menschen mitteilen, dass sie mit KI sprechen) und die KI-Kompetenz (Art. 4) gelten bereits.
  • Art. 5: keine manipulativen Techniken, keine Emotionsableitung, wo sie verboten ist.
  • Medizinprodukte: MDR (EU) 2017/745 Regel 11 stuft Software, die Informationen für diagnostische oder therapeutische Entscheidungen liefert, in Klasse IIa oder höher ein; die Leitlinie zur Qualifizierung MDCG 2019-11 ist anzuwenden [7]. Wer ein LLM für Dringlichkeitsempfehlungen einsetzt, wird Hersteller; nutzen Sie ein zertifiziertes Produkt innerhalb seines Verwendungszwecks und ändern Sie diesen nicht per Prompt.
  • DSGVO: Gesundheitsdaten sind Daten besonderer Kategorien (Art. 9); erforderlich sind ausdrückliche Einwilligung oder eine andere Grundlage nach Art. 9 Abs. 2, eine DSFA (Art. 35), Datenminimierung, Verarbeitung in der EU, kein Training mit Patientenchats ohne Rechtsgrundlage und strenge Aufbewahrungsfristen. Art. 22: Lassen Sie nicht allein automatisierte Entscheidungen den Zugang zur Versorgung verwehren. In Deutschland beachten Sie §203 StGB (Berufsgeheimnis; Dienstleister als Gehilfen verpflichten) und den AVV.
  • Ethik: keine Diagnoseversprechen, gleicher Zugang (Sprachen, digitale Kluft), Tests auf Verzerrungen, Schutz vor Prompt-Injection.
  • Gegenmaßnahmen: deterministische Warnzeichen-Schicht, zertifizierte Engine, klinischer Sicherheitsnachweis, laufende Überwachung der Untertriage, Vorfallprozess, Übersteuerung durch Menschen.

Erste Schritte

  1. Legen Sie den Umfang fest: nur administrative Aufnahme und Zusammenfassung oder Dringlichkeitsempfehlung. Letzteres bedeutet MDR; ziehen Sie zuerst Datenschutz- und Regulierungsberatung hinzu.
  2. Erfassen Sie die bestehenden Aufnahmeabläufe und Basis-Kennzahlen (Anrufe pro Tag, Aufnahmeminuten, Quote nicht wahrgenommener Termine).
  3. Wählen Sie 2-3 zertifizierte Produkte in die engere Wahl; fordern Sie MDR-Zertifikate, Verwendungszweck, klinische Bewertung, Hosting und Unterauftragsverarbeiter an; führen Sie eine DSFA durch.
  4. Starten Sie einen Pilot in einer Einrichtung, in dem Behandelnde jeden Fall prüfen, und vergleichen Sie die Ersteinschätzung im Schattenmodus mit der Entscheidung der Pflegekraft.
  5. Prüfen Sie die Sicherheitskennzahlen (insbesondere Untertriage) monatlich, bevor Sie Umfang oder Kanäle erweitern.

Quellen

  1. Nature Medicine (2026) — ChatGPT Health performance in a structured test of triage recommendations — https://www.nature.com/articles/s41591-026-04297-7
  2. BMC Emergency Medicine (2025) — Performance of ChatGPT, Gemini and DeepSeek for non-critical triage support using real-world conversations in the ED — https://link.springer.com/article/10.1186/s12873-025-01337-2
  3. Infermedica — Regulatory compliance and developer documentation (Conversational Triage API) — https://infermedica.com/regulatory-compliance and https://developer.infermedica.com/documentation/conversational-triage-api/faq/
  4. Ada Health — EU-MDR Class IIa certification press release — https://about.ada.com/press/221215-ada-health-receives-eu-mdr-certification/
  5. JMIR/PMC — Multi-evidence clinical reasoning with RAG for emergency triage, retrospective evaluation — https://www.ncbi.nlm.nih.gov/pmc/articles/PMC12887567/
  6. DLA Piper — Digital AI Omnibus: deferral of high-risk obligations under the AI Act — https://knowledge.dlapiper.com/dlapiperknowledge/globalemploymentlatestdevelopments/2026/The-Digital-AI-Omnibus-Proposed-deferral-of-high-risk-AI-obligations-under-the-AI-Act
  7. European Commission — MDCG 2019-11 guidance on qualification and classification of software — https://health.ec.europa.eu/medical-devices-sector/new-regulations/guidance-mdcg-endorsed-documents-and-other-guidance_en
  8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj