Antwortentwürfe und Triage für Patientennachrichten an Ärztinnen und Ärzte (Posteingangs-Assistent)

Seit Patientenportale verbreitet sind, erhalten Ärztinnen und Ärzte einen stetigen Strom von Nachrichten außerhalb von Besuchen (Fragen zu Symptomen, Ergebnissen, Rezepten, Formularen), der weitgehend nicht vergütet wird und als anerkannter Beitrag zu Burnout gilt. Ein Posteingangs-Assistent sortiert eingehende Nachrichten nach Dringlichkeit und Thema, leitet sie an die richtige Rolle weiter und entwirft eine Antwort mithilfe des Akteninhalts. Eine Ärztin oder ein Arzt prüft, bearbeitet und versendet jede Antwort. Der belegte Gewinn liegt meist in geringerer kognitiver Belastung und einem schnelleren Start in die Antwort, nicht in großen gemessenen Zeitersparnissen.

Problem & Nutzen

• Heute: Nachrichten landen in einem gemeinsamen oder persönlichen Posteingang. Ärztinnen und Ärzte beantworten klinische Fragen, oft nach Feierabend; Pflegekräfte und Praxispersonal sortieren vor. Ton, Vollständigkeit und Geschwindigkeit schwanken, und dringende Nachrichten („Brustschmerzen seit heute Morgen“) können sich unter Routinefällen verstecken.
• KI-Nutzen: (1) sicherheitsorientierte Triage, damit dringende Nachrichten zuerst erscheinen, (2) Weiterleitung, damit Rezept- und Verwaltungsanfragen nicht bei Ärztinnen und Ärzten landen, (3) ein Entwurf, der einfühlsam, aktengenau und in der Sprache der Patientin oder des Patienten ist, (4) weniger Schreiben vom leeren Blatt aus.
• Belege: Eine Qualitätsverbesserungsstudie am Stanford Health Care ergab, dass Ärztinnen und Ärzte, die KI-Antwortentwürfe in der Patientenakte nutzten, geringere Werte für Arbeitsbelastung und burnout-bezogene Skalen angaben, während sich die gemessene Antwortzeit nicht signifikant verkürzte [1]. Eine Studie in Lancet Digital Health zeigte, dass LLM-Entwürfe bei ungeprüftem Versand unsichere Inhalte enthalten können und Ärztinnen und Ärzte auf den Inhalt des Entwurfs festlegen können [2]. Betrachten Sie „bessere Erfahrung, unsichere Zeitersparnis, Sicherheitsrisiko über null“ als realistische Ausgangslage.
• Kontext: Deutsche Praxen und Krankenhäuser bieten zunehmend Patienten-Apps an und ab 2025 die elektronische Patientenakte (ePA); mit ihnen wird ein Anstieg des Nachrichtenvolumens erwartet.

Varianten

• Krankenhaus / große Gemeinschaftspraxis: Entwürfe und Triage im Posteingang des KIS.
• Hausarztpraxis / Primärversorgung: Triage von Nachrichten aus App, E-Mail und Praxissoftware für MFA/Pflegekräfte.
• Fachkliniken (Onkologie, Kardiologie, Kinderwunsch): protokollspezifische Triage und Bausteine für die Patienteninformation.
• Telemedizin und Pflegetelefone von Versicherern: dieselbe Pipeline mit einer Protokollbibliothek.
• Apotheken und Programme für chronisch Kranke: Nachrichten zu Rezepten und Therapietreue.
• Mehrsprachig: Antwort wird in der Sprache der Patientin oder des Patienten entworfen, die Ärztin oder der Arzt prüft in der eigenen.
• Private Nutzung: keine direkte; Self-Service-Chatbots für Patientinnen und Patienten sind ein anderer Fall (CONV-001).

So funktioniert es

1. patient message (portal/app/email)
2. intake + PII/attachment handling
3. classifier: topic (symptom, result, refill, admin, billing) + urgency + red-flag rules
4. routing (physician | nurse | admin | emergency auto-notice to patient)
5. context retrieval (problem list, meds, allergies, labs, last visit, message thread)
6. LLM drafts reply (+ optional suggested order/task) under clinic style and policy prompt
7. guardrails (no new diagnosis/dose not in chart, red-flag escalation, tone, language level)
8. clinician review: edit, discard or send; every send is a human decision
9. audit log (draft, edits, final, who, when) + feedback signal

• Triage-Schicht: ein kleiner, per Feintuning angepasster Klassifikator oder ein LLM plus deterministische Stichwort- und Warnzeichenregeln (Red Flags). Die Regeln sind ein Sicherheitsnetz, kein optionales Extra: Liegt das Modell falsch, greifen die Warnzeichen trotzdem. Sicherheitskritische Nachrichten sollten zudem unabhängig vom Entwurf einen automatischen Standardhinweis auslösen („Im Notfall rufen Sie die 112“).
• Entwurfsschicht: ein allgemeines LLM mit Abruf von Akteninhalten. Für den Stil genügen kleinere Modelle; größere helfen, wenn Schlussfolgerungen aus der Akte nötig sind.
• Mensch-in-der-Schleife (Human-in-the-Loop): zwingend beim Versand. Gute Designs zeigen die zugrunde liegenden Aktenfakten neben dem Entwurf, setzen standardmäßig auf „bearbeiten“ statt „senden“ und weisen die Patientin oder den Patienten auf die KI-Unterstützung hin.

Datenaufbereitung

• Daten und Ablageort: Patientennachrichten im Portal, in der App, per E-Mail oder in der Praxissoftware; Akteninhalt (Problemliste, Medikation, Allergien, Laborwerte, Besuche) im KIS bzw. Praxisverwaltungssystem; Triage-Protokolle, Patienteninformationen und Praxisrichtlinien als PDF- oder Word-Dateien auf Dateiservern; frühere ärztliche Antworten im Nachrichtenarchiv.
• Typische Lücken: veraltete oder widersprüchliche Protokolle, verstreute Patienteninformationen, keine Dringlichkeits- oder Routing-Labels bei früheren Nachrichten, Freitext-Notizen in der Akte mit Abkürzungen, Patientenkennungen im Nachrichtentext und uneinheitliche rollenbasierte Zugriffsrechte.
• Aufbereitungsschritte: eine verbindliche Wissensbasis aus Protokollen und Patienteninformationen pflegen (PREP-013, PREP-014); das Schema für Thema und Dringlichkeit mit Ärztinnen und Ärzten festlegen (PREP-019); 300-500 de-identifizierte Nachrichten von Ärztinnen und Ärzten als Evaluationsdatensatz labeln lassen (PREP-018, PREP-022); eine Liste der Fachbegriffe und Abkürzungen der Praxis erstellen (PREP-015); Akteninhalte über FHIR oder Schnittstellen des Praxissystems bereitstellen (PREP-005); Zugriffsrechte bereinigen, damit der Assistent nur sieht, was die Rolle des Absenders sehen darf (PREP-023).
• Werkzeuge: HAPI FHIR, Presidio für den Umgang mit personenbezogenen Daten, pgvector oder Qdrant für die Suche.
• Aufwandsanteil: etwa 30-40 Prozent, bestimmt durch Labeling und Pflege der Protokolle. Eine Bereitschaftsprüfung hilft bei der Abgrenzung (GUIDE-003).

Umsetzungswege

Welcher Weg für wen

• Enterprise: Weg C. Patientennachrichten sind Daten besonderer Kategorien, und ein Krankenhaus betreibt typischerweise ein geregeltes internes LLM-Gateway; ein selbst betriebenes Modell hält den Akteninhalt im eigenen Netz (Weg A, wenn der KIS-Hersteller eine zertifizierte, in der EU gehostete Funktion liefert).
• Developer: Weg B. Der schnellste Weg, einen FHIR-integrierten Prototyp auf Modellen in EU-Regionen ohne Datenspeicherung zu bauen und zu evaluieren, bevor man sich auf einen eigenen Betrieb festlegt.
• Öffentlicher Sektor: Weg C. Öffentliche Krankenhäuser unterliegen Vergaberegeln, der Schweigepflicht (§203 StGB) und Anforderungen an die Souveränität, die On-Premises oder eine souveräne deutsche Cloud begünstigen.

Weg A — Kaufen (Standardsoftware)

• KIS-nativ: Epic (generative Entwürfe im In Basket, betrieben auf Microsoft Azure OpenAI; im Einsatz in Stanford, UC San Diego und anderen), Oracle Health Clinical AI Agent, Meditech mit Google.
• Anbieter von Ambient-/Assistenzlösungen mit Posteingangsfunktionen: Microsoft Dragon Copilot (früher Nuance DAX), Abridge, Suki, Nabla (EU: Frankreich), Doctolib KI-Assistent (EU), Tandem Health (EU: Schweden).
• DACH/EU: prüfen Sie KIS-Hersteller (z. B. Dedalus, CGM, Meierhofer, Doctolib) auf Roadmap-Punkte; die Verfügbarkeit in deutschsprachigen Arbeitsabläufen ist noch lückenhaft.
• A wählen, wenn: bereits ein großes KIS im Einsatz ist. Fragen Sie nach Datenhaltung in der EU, dem MDR-Status der Triage-Funktion, Audit-Protokollen und dem Verzicht auf Training mit Ihren Daten.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Modelle: Mistral (EU), Claude, Gemini und Modelle der GPT-Klasse über EU-Regionen ohne Datenspeicherung und mit unterzeichnetem AVV (Azure OpenAI EU Data Zone, Vertex AI EU, AWS Bedrock Frankfurt).
• Integration: HL7 FHIR R4 (Patient, Condition, MedicationRequest, Observation, Communication) über SMART on FHIR oder Schnittstellen des Praxissystems; Entwürfe werden als nicht versendete Vorschläge in den Posteingang gelegt.
• Orchestrierung: Abruf für den Akteninhalt, strukturierte Ausgaben für die Klassifizierung (Dringlichkeit, Thema, Begründung), ein Guardrail-Modell für personenbezogene Daten und unsichere Ratschläge, ein Evaluationsrahmen.
• B wählen, wenn: Ihr KIS keine native Funktion hat oder Sie deutschsprachige und lokale Protokolle brauchen.

Weg C — Selbst betreiben (Open Source)

• Modelle: Llama, Qwen3, Mistral Small/Medium, Gemma und medizinisch angepasste offene Modelle (z. B. MedGemma), betrieben mit vLLM; kleiner Encoder (z. B. deutsche medizinische BERT-Varianten) für die Triage.
• Stack: FHIR-Server (HAPI FHIR), Vektorspeicher (pgvector/Qdrant), Langfuse für das Tracing, Presidio oder Ähnliches für den Umgang mit personenbezogenen Daten, n8n für den Workflow.
• Hardware: HW3 für Modelle mit 30-70B Parametern im Klinikmaßstab; HW2 genügt für ein Entwurfsmodell mit rund 8-14B. Nötig dort, wo Patientendaten das Krankenhausnetz nicht verlassen dürfen.

Weg D — Eigenes Training

Lohnt sich für den Triage-Klassifikator: Feintuning auf einigen tausend de-identifizierten, von Ärztinnen und Ärzten gelabelten Nachrichten mit Dringlichkeits- und Routing-Labels in der Landessprache. Eine Stilanpassung der Entwürfe anhand früherer ärztlicher Antworten ist möglich, wirft aber Fragen zu Datenschutz und Qualitätsverzerrung auf (schlechte Antworten werden kopiert). Das Training mit Patientennachrichten braucht eine Rechtsgrundlage, De-Identifizierung und die Freigabe durch Ethik und Datenschutzbeauftragte(n).

Stand der Technik (2026)

• Praxis im Einsatz: In KIS eingebettete Entwürfe sind in vielen großen US-Systemen verfügbar; der Fokus hat sich von „Kann es schreiben?“ zu Evaluation, Sicherheitsüberwachung und Messung der Wirkung auf die Arbeitslast verschoben.
• Qualität: Studien finden Entwürfe, die als einfühlsam und vollständig beurteilt werden, teils stärker als ärztliche Antworten, aber mit gelegentlichen sachlichen oder sicherheitsrelevanten Fehlern und einer Lesbarkeit über dem empfohlenen Niveau [2][3]. Die Evaluation nutzt ärztliche Bewertungen, Fehlertaxonomien und Quoten für „würde ich unverändert senden“.
• Techniken: Abruf über die strukturierte Akte, protokollgestützte Triage, Warnzeichenregeln, automatisierte Prüfungen der Ausgabe, Stilpräferenzen je Ärztin oder Arzt und Überwachung der Bearbeitungsquoten.
• Grenzen und Fehlerbilder: übersehene Dringlichkeit, erfundene Beruhigung, falsches Medikament oder falsche Dosis, Ignorieren von Kontext in älteren Notizen, Automatisierungsverzerrung (Versand ohne Lesen), Patientinnen und Patienten, die eine Antwort erhalten, die fürsorglich klingt, aber allgemein ist, und zusätzliches Nachrichtenvolumen, weil das Antworten einfacher wird. Nachrichten in anderen Sprachen als Englisch und mit geringer Lesekompetenz schneiden schlechter ab.

Gemeinsame Bausteine & Kombinationen

• Aktenabruf + Zusammenfassungen: HLTH-018 (Zusammenfassung von Akten) liefert dieselbe Kontextschicht.
• Dokumentations-Stack: HLTH-003 Ambient Scribe und HLTH-011 Berichtserstellung teilen sich LLM, FHIR und Audit-Infrastruktur; ein geregeltes Krankenhaus-LLM-Gateway bedient alle drei.
• Klinische Logik: HLTH-004 Entscheidungsunterstützung für Fragen zu Medikation oder Protokollen; HLTH-007 Fernüberwachung erzeugt Alarmnachrichten, die im selben Posteingang landen.
• Generische Gegenstücke: LANG-002 (Korrespondenz), AGENT-001 (E-Mail-Triage), CONV-001 (Service-Chatbot) teilen sich Werkzeuge, haben aber kein klinisches Sicherheitsdesign.
• Hardware: derselbe HW3-Inferenzserver wie bei anderen sprachbasierten HLTH-Anwendungsfällen.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis Monate, vor allem für Governance, Schulung und Pilot mit wenigen Ärztinnen und Ärzten; Lizenz je Nutzer oder je Organisation.
• Weg B: 3-6 Monate einschließlich FHIR-Integration, Evaluationsdatensatz und klinischer Sicherheitsprüfung.
• Weg C/D: 6-12 Monate mit ML- und klinischem Informatikpersonal; GPU- und Betriebskosten.
• Kennzahlen: Nutzung und Bearbeitungsquote der Entwürfe, Zeit bis zur ersten Antwort (dringend vs. Routine), ärztliche Belastungs- und Burnout-Werte, Posteingangszeit nach Feierabend, Sicherheitsereignisse und Beinahe-Ereignisse je 1.000 Entwürfe, Sensitivität der Triage für dringende Nachrichten, Patientenzufriedenheit, Entwicklung des Nachrichtenvolumens.

Menschen & Veränderung

• Früh einbinden: Geschäftsleitung, die ärztliche und die pflegerische Leitung als Prozessverantwortliche, das Praxis- oder Stationspersonal, das Nachrichten sortiert (MFA, Pflegekräfte), IT, die(den) Datenschutzbeauftragte(n) und Recht/Compliance. Beziehen Sie Betriebsrat oder Personalrat ab der Planungsphase ein.
• Betriebsrat: ja, wahrscheinlich. Protokolle zu Annahme und Bearbeitung von Entwürfen sowie zu Antwortzeiten sind objektiv zur Leistungsüberwachung von Ärztinnen und Ärzten geeignet (§87 Abs. 1 Nr. 6 BetrVG, BAG-Rechtsprechung); der Betriebsrat ist zu informieren, wenn Arbeitsprozesse mit KI geplant werden (§90 Abs. 1 Nr. 3), und kann einen KI-Sachverständigen hinzuziehen (§80 Abs. 3). In öffentlichen Krankenhäusern gilt der Personalrat (GUIDE-004).
• Datenschutz: Gesundheitsdaten (Art. 9 DSGVO) bedeuten eine Datenschutz-Folgenabschätzung (DSFA, Art. 35), einen AVV mit jedem Auftragsverarbeiter und die frühe Einbindung der(des) Datenschutzbeauftragten (GUIDE-005). Klären Sie den MDR-Status der Triage-Funktion mit der Rechtsabteilung.
• KI-Kompetenz: ergreifen Sie Maßnahmen zur KI-Kompetenz der Ärztinnen und Ärzte (Art. 4): Automatisierungsverzerrung, Lesen der zugrunde liegenden Aktenfakten, Melden unsicherer Entwürfe (GUIDE-006).
• Pilot und Kommunikation: starten Sie mit freiwilligen Ärztinnen und Ärzten sowie mit Nachrichten zu Verwaltung, Rezepten und Ergebnissen (GUIDE-009). Typische Sorgen sind Haftung, mehr Nachrichtenvolumen und Überwachung; begegnen Sie ihnen mit verpflichtender Prüfung vor jedem Versand, keinem automatischen Versand klinischer Inhalte, Hinweis auf KI-Nutzung gegenüber Patientinnen und Patienten und einer Betriebsvereinbarung, die die Nutzung der Protokolle begrenzt (GUIDE-008).

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): hängt von der Funktion ab. Das Entwerfen administrativer und routinemäßiger Antworten mit vollständiger ärztlicher Prüfung ist in der Regel ein begrenztes bzw. minimales Risiko (Transparenz gegenüber Patientinnen und Patienten, KI-Kompetenz Art. 4). Eine Funktion, die die klinische Dringlichkeit einstuft und die Versorgung steuert, kann als Medizinprodukte-Software gelten (MDR Regel 11) und damit über Art. 6 Abs. 1 als Hochrisiko-KI-System mit der Konformitätsbewertung nach MDR. Legen Sie den Verwendungszweck sorgfältig fest und dokumentieren Sie ihn; ein reiner „Vorschlag an eine Ärztin oder einen Arzt“ verringert den Produktstatus, hebt ihn aber nicht auf. Es greift kein Verbot nach Art. 5, vermeiden Sie aber das Ableiten von Emotionen der Patientinnen und Patienten.
• DSGVO: Gesundheitsdaten sind Daten besonderer Kategorien (Art. 9); erforderlich sind eine Rechtsgrundlage, eine DSFA (Art. 35), ein Auftragsverarbeitungsvertrag, Hosting in der EU oder ein gültiger Übermittlungsmechanismus, Minimierung des an das Modell gesendeten Akteninhalts und kein Training des Anbieters mit Patientendaten. In Deutschland gelten zudem Landeskrankenhausgesetze und die Schweigepflicht (§203 StGB) für externe Auftragsverarbeiter. Die Verordnung (EU) 2025/327 zum Europäischen Gesundheitsdatenraum wird Zugang und Interoperabilität prägen [4].
• Berufspflicht: die Ärztin oder der Arzt bleibt für die Antwort verantwortlich (Sorgfaltspflicht); dokumentieren Sie die KI-Unterstützung und informieren Sie die Patientinnen und Patienten.
• Gegenmaßnahmen: Warnzeichenregeln, verpflichtende Prüfung, kein automatischer Versand klinischer Inhalte, Überwachung von Bearbeitungsquote und Vorfällen, Red-Teaming für Notfälle, Rückschalter, regelmäßige Prüfung der Triage-Genauigkeit über Sprachen und Patientengruppen hinweg.

Erste Schritte

1. Ausgangslage messen: Nachrichtenvolumen je Ärztin oder Arzt, Kategorien, Antwortzeiten, Arbeit nach Feierabend.
2. Verwendungszweck und Umfang festlegen: mit Nachrichten zu Verwaltung, Rezepten und Ergebnissen beginnen; die Notfall- Weiterleitung regelbasiert halten.
3. Einen de-identifizierten Evaluationsdatensatz mit 300-500 Nachrichten aufbauen, von Ärztinnen und Ärzten gelabelt; zwei oder drei Produkte testen.
4. Einen begrenzten Pilot mit freiwilligen Ärztinnen und Ärzten durchführen, mit Aktenfakten neben den Entwürfen und Hinweis auf KI.
5. Datenschutz-Folgenabschätzung, MDR-/AI-Act-Bewertung und Überwachungsplan abschließen, bevor Sie ausweiten.

Quellen

1. Tai-Seale M et al. — AI-generated draft replies integrated into health records and physicians' electronic communication, JAMA Network Open 2024 — https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2818093
2. Chen S et al. — The effect of using a large language model to respond to patient messages, Lancet Digital Health 2024 — https://www.thelancet.com/journals/landig/article/PIIS2589-7500(24)00060-8/fulltext
3. Garcia P et al. — Artificial intelligence-generated draft replies to patient inbox messages, JAMA Network Open 2024 — https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2816213
4. Regulation (EU) 2025/327 (European Health Data Space) — https://eur-lex.europa.eu/eli/reg/2025/327/oj
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. Regulation (EU) 2017/745 (MDR), Annex VIII Rule 11 — https://eur-lex.europa.eu/eli/reg/2017/745/oj
7. HL7 FHIR R4 specification — https://hl7.org/fhir/R4/
8. HAPI FHIR — https://github.com/hapifhir/hapi-fhir