Patient message reply drafting & triage for clinicians (in-basket assistant)

Since patient portals became common, clinicians receive a steady stream of non-visit messages (symptom questions, results, refills, forms) that is largely unreimbursed and a recognised contributor to burnout. An in-basket assistant sorts incoming messages by urgency and topic, routes them to the right role, and drafts a reply using chart context. A clinician reviews, edits and sends every reply. The documented gain is mostly lower cognitive burden and a faster start on the reply, not large measured time savings.

Problem & value

• Today: messages land in a shared or personal inbox. Physicians answer clinical questions, often after hours; nurses and staff pre-sort. Tone, completeness and speed vary, and urgent messages ("chest pain since this morning") can hide among routine ones.
• AI value: (1) safety-oriented triage so urgent messages surface first, (2) routing so that refills and admin requests do not reach physicians, (3) a draft that is empathetic, accurate to the chart and in the patient's language, (4) less writing from a blank page.
• Evidence: a quality-improvement study at Stanford Health Care found that physicians using AI draft replies in the EHR reported lower task load and burnout-related scores, while measured reply time did not fall significantly [1]. A Lancet Digital Health study showed that LLM drafts can contain unsafe content if sent unedited and can anchor clinicians on the draft's content [2]. Treat "better experience, uncertain time savings, non-zero safety risk" as the realistic baseline.
• Context: German practices and hospitals increasingly offer patient apps and, from 2025, the electronic patient record (ePA); message volume is expected to rise with them.

Variants

• Hospital / large group practice: drafts and triage inside the EHR in-basket.
• Primary care / Hausarztpraxis: triage of app, email and practice-software messages for MFA/nurses.
• Specialty clinics (oncology, cardiology, fertility): protocol-specific triage and education snippets.
• Telehealth and insurers' nurse lines: same pipeline with a protocol library.
• Pharmacy and chronic-care programmes: refill and adherence messages.
• Multilingual: reply drafted in the patient's language, clinician reviews in their own.
• Private use: none directly; patient-facing self-service chatbots are a different case (CONV-001).

How it works

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 layer: a small fine-tuned classifier or LLM plus deterministic keyword/red-flag rules. Rules are a safety net, not an optional extra: if the model is wrong, red flags still fire. Safety-critical messages should also trigger an automatic standard notice ("in an emergency call 112") independent of the draft.
• Draft layer: a general LLM with retrieval of chart data. Smaller models are enough for style; bigger ones help when chart reasoning is needed.
• Human-in-the-loop: mandatory at send. Good designs show the source chart facts next to the draft, default to "edit" rather than "send", and disclose AI assistance to the patient.

Data preparation

• Data and location: patient messages in the portal, app, e-mail or practice software; chart context (problem list, medications, allergies, labs, visits) in the EHR/KIS; triage protocols, patient-education texts and clinic policies as PDFs or Word files on file shares; past clinician replies in the message archive.
• Typical gaps: protocols that are outdated or contradictory, scattered patient-education content, no urgency or routing labels on past messages, free-text chart notes with abbreviations, patient identifiers mixed into message text, and inconsistent role-based access rights.
• Preparation steps: curate one authoritative protocol and education knowledge base (PREP-013, PREP-014); define the topic and urgency scheme with clinicians (PREP-019); have clinicians label 300-500 de-identified messages as the evaluation set (PREP-018, PREP-022); build a clinic terminology and abbreviation list (PREP-015); expose chart data via FHIR or practice-system APIs (PREP-005); clean up access rights so the assistant only sees what the sender role may see (PREP-023).
• Tools: HAPI FHIR, Presidio for PII handling, pgvector or Qdrant for retrieval.
• Effort share: about 30-40 percent, dominated by labelling and protocol curation. A readiness check helps scope it (GUIDE-003).

Implementation paths

Which path for whom

• Enterprise: Path C. Patient messages are special-category data and a hospital typically runs one governed internal LLM gateway; a self-hosted model keeps chart context in the network (Path A if the EHR vendor ships a certified, EU-hosted feature).
• Developer: Path B. Fastest way to build and evaluate a FHIR-integrated prototype on EU-region models with zero data retention before committing to hosting.
• Public: Path C. Public hospitals face procurement rules, professional secrecy (§203 StGB) and sovereignty requirements that favour on-premise or sovereign German cloud.

Path A — Buy (off-the-shelf)

• EHR-native: Epic (In Basket generative drafts, running on Microsoft Azure OpenAI; used at Stanford, UC San Diego and others), Oracle Health clinical AI agent, Meditech with Google.
• Ambient/assistant vendors with inbox features: Microsoft Dragon Copilot (formerly Nuance DAX), Abridge, Suki, Nabla (EU: France), Doctolib AI assistant (EU), Tandem Health (EU: Sweden).
• DACH/EU: check KIS vendors (e.g. Dedalus, CGM, Meierhofer, Doctolib) for roadmap items; availability in German-language workflows is still patchy.
• Choose A when: a major EHR is already in place. Ask for EU data residency, MDR status of the triage function, audit logs and no training on your data.

Path B — Build on cloud APIs

• Models: Mistral (EU), Claude, Gemini and GPT-class models via EU regions with zero data retention and a signed DPA (Azure OpenAI EU Data Zone, Vertex AI EU, AWS Bedrock Frankfurt).
• Integration: HL7 FHIR R4 (Patient, Condition, MedicationRequest, Observation, Communication) via SMART on FHIR, or practice-system APIs; deliver drafts into the inbox as unsent suggestions.
• Orchestration: retrieval for chart context, structured outputs for classification (urgency, topic, rationale), guardrail model for PII and unsafe advice, evaluation harness.
• Choose B when: your EHR has no native feature, or you need German-language and local protocols.

Path C — Self-host (open source)

• Models: Llama, Qwen3, Mistral Small/Medium, Gemma and medically tuned open models (e.g. MedGemma) served with vLLM; small encoder (e.g. German medical BERT variants) for triage.
• Stack: FHIR server (HAPI FHIR), vector store (pgvector/Qdrant), Langfuse for tracing, Presidio or similar for PII handling, n8n for workflow.
• Hardware: HW3 for 30-70B models at clinic scale; HW2 works for a ~8-14B drafting model. Needed where patient data may not leave the hospital network.

Path D — Custom training

Worth it for the triage classifier: fine-tune on a few thousand de-identified, clinician-labelled messages with urgency and routing labels, in the local language. Style adaptation of drafts from past clinician replies is possible but raises privacy and quality-bias issues (copying poor replies). Training on patient messages needs a legal basis, de-identification and ethics/DPO sign-off.

State of the art (2026)

• Production reality: EHR-embedded drafting is available at many large US systems; the focus moved from "can it write?" to evaluation, safety monitoring and measuring effect on workload.
• Quality: studies find drafts judged empathetic and complete, sometimes more than clinician replies, but with occasional factual or safety errors and readability above the recommended level [2][3]. Evaluation uses clinician rating, error taxonomies and "would send as is" rates.
• Techniques: retrieval over the structured chart, protocol-grounded triage, red-flag rules, automated output checks, per-clinician style preferences, and monitoring of edit rates.
• Limits and failure modes: missed urgency, invented reassurance, wrong medication or dose, ignoring context in older notes, automation bias (clinician sends without reading), patients receiving a reply that sounds caring but is generic, and added message volume because replying becomes easier. Non-English and low-literacy messages perform worse.

Shared resources & combinations

• Chart retrieval + summaries: HLTH-018 (record summarisation) provides the same context layer.
• Documentation stack: HLTH-003 ambient scribe and HLTH-011 report generation share the LLM, FHIR and audit infrastructure; one governed hospital LLM gateway serves all three.
• Clinical logic: HLTH-004 decision support for medication or protocol questions; HLTH-007 remote monitoring generates alert messages that enter the same inbox.
• Generic counterparts: LANG-002 (correspondence), AGENT-001 (email triage), CONV-001 (service chatbot) share tooling but lack clinical safety design.
• Hardware: same HW3 inference server as other HLTH language use cases.

Effort, cost & KPIs

• Path A: weeks to months, mostly governance, training and pilot with a few clinicians; licence per user or per organisation.
• Path B: 3-6 months incl. FHIR integration, evaluation set and clinical safety review.
• Path C/D: 6-12 months with ML and clinical informatics staff; GPU and operations cost.
• KPIs: draft usage and edit rate, time to first response (urgent vs. routine), clinician burden and burnout scores, after-hours inbox time, safety events and near-misses per 1,000 drafts, triage sensitivity for urgent messages, patient satisfaction, message volume trend.

People & change

• Involve early: management, the medical lead and nursing lead as process owners, the practice or ward staff who sort messages (MFA, nurses), IT, the DPO and legal/compliance. Include the works council or staff council from the planning stage.
• Works council: yes, likely. Draft acceptance, edit and response-time logs are objectively suited to monitor clinician performance (§87(1) no. 6 BetrVG, BAG case law); the works council must be informed when work processes are planned with AI (§90(1) no. 3), and may engage an AI expert (§80(3)). In public hospitals the Personalrat applies (GUIDE-004).
• Data protection: health data (Art. 9 GDPR) means a DPIA (Art. 35), an AVV with every processor and early DPO involvement (GUIDE-005). Clarify MDR status of the triage function with legal.
• AI literacy: take measures to support clinicians' AI literacy (Art. 4): automation bias, reading the source chart facts, reporting unsafe drafts (GUIDE-006).
• Pilot and communication: start with volunteer clinicians and admin, refill and result messages (GUIDE-009). Typical concerns are liability, more message volume and surveillance; address them with mandatory review before every send, no auto-send for clinical content, AI disclosure to patients, and a works agreement limiting log use (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: depends on function. Drafting admin and routine replies with full clinician review is generally limited/minimal risk (transparency to patients, AI literacy Art. 4). A function that classifies clinical urgency and steers care may count as medical device software (MDR Rule 11) and thus a high-risk AI system via Art. 6(1) with the conformity assessment of MDR. Decide intended purpose carefully and document it; a pure "suggestion to a clinician" reduces but does not remove device status. No Art. 5 prohibition applies, but avoid inferring emotions of patients.
• GDPR: health data is special-category data (Art. 9); needs a legal basis, DPIA (Art. 35), processor contract, EU hosting or valid transfer mechanism, minimisation of chart context sent to the model, and no vendor training on patient data. In Germany also hospital state laws and professional secrecy (§203 StGB) for external processors. The European Health Data Space Regulation (EU) 2025/327 will shape access and interoperability [4].
• Professional duty: the clinician remains responsible for the reply (duty of care); document AI assistance and tell patients.
• Mitigations: red-flag rules, mandatory review, no auto-send for clinical content, edit-rate and incident monitoring, red-teaming for emergencies, rollback switch, periodic audit of triage accuracy across languages and patient groups.

Getting started

1. Measure the baseline: message volume per clinician, categories, response times, after-hours work.
2. Define intended purpose and scope: start with admin, refill and results messages; keep emergency routing rule-based.
3. Build a 300-500 message de-identified evaluation set labelled by clinicians; test two or three products.
4. Run a limited pilot with volunteer clinicians, with chart facts shown beside drafts and AI disclosure.
5. Complete DPIA, MDR/AI Act assessment and monitoring plan before scaling.

Sources

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