Prompt patterns for clinical summarization that hold up in production

A clean Jupyter demo of a SOAP-note generator is not the same thing as a clinical summarization pipeline that runs for a 30-clinician group practice. In production the failure modes are different, the data shape is messier, and a single bad output can mean a regulatory headache. After 18 months of running this in production for behavioral health and primary care, here are the four prompt patterns we keep coming back to, what each is good for, and where each breaks.

Pattern 1: The “single-shot SOAP” prompt

The simplest version. One model call, full transcript in, full SOAP note out. The prompt is something like “You are a clinical scribe. From the transcript below, write a SOAP note. Output exactly four sections: Subjective, Objective, Assessment, Plan.”

This works for short, routine encounters — a follow-up med check, a stable chronic care visit. It breaks for two cases:

Long visits. A 50-minute psychotherapy session at CPT 90837 has roughly 7,000 words of transcript. The model can read all of it, but the Assessment section starts to lose the clinical reasoning thread halfway through.
Complex visits. Multiple new problems, medication changes, lab review. Single-shot generation produces an Assessment that reads like a list of facts rather than a clinical formulation.

Pattern 2: Chain-of-sections

Split the SOAP into four model calls and pass each previous section as context to the next. Subjective first (from transcript only), then Objective (transcript + Subjective), then Assessment (everything so far), then Plan (everything so far).

This gives noticeably better assessments because the model has already committed to what’s in S and O before reasoning about A. It costs 2–3x as many tokens as single-shot. We use it for behavioral health and any visit where the assessment is the clinical product.

The failure mode here is error compounding. If the Subjective section misattributes a symptom — “patient reports insomnia” when the patient actually denied insomnia — every subsequent section inherits that error. The mitigation: a final verification pass that diffs the assessment claims back against the transcript. It’s another model call but the catch rate is high enough to be worth it.

Pattern 3: Extract-then-narrate

Two-stage. Stage one extracts a structured JSON object from the transcript: chief_complaint, hpi_elements, ros_positive, ros_negative, medications_discussed, plan_items. Stage two takes that JSON and renders prose.

The advantages are real:

The structured stage is much easier to audit. A reviewer can scan a JSON object faster than a paragraph and catch missing or wrong items.
The structured stage feeds the billing layer directly. CPT and ICD-10 suggestions come from the JSON, not from re-parsing the prose.
Stage two is deterministic-ish. Same JSON in, very similar prose out, run-to-run.

The downside is that the structured stage is opinionated about what a visit contains. If your schema doesn’t have a slot for “spiritual concerns discussed,” that part of the visit doesn’t make it into the note. We add a notes_other free-text field to catch the long tail.

Pattern 4: The “draft and critic” loop

The model drafts the note, a second prompt critiques the draft against a checklist (was the chief complaint stated? does the assessment match the diagnosis the clinician hinted at? are there contradictions?), and a third pass revises based on the critique.

This is the most expensive pattern and the slowest. It’s also the highest-quality output by a meaningful margin — clinicians edit roughly half as much as they do with single-shot. We use it for complex cases (new diagnosis, medication initiation, suicidality assessment) and not for routine follow-ups, because the cost difference matters when you’re running thousands of visits a week.

The failure mode is critic blindness. If the critic prompt doesn’t know what to look for in a specific specialty, it cheerfully approves bad drafts. We maintain separate critic checklists for psychiatry, primary care, and behavioral health — that’s the unglamorous work that actually makes the pattern function.

Picking a pattern for your use case

A rough decision tree:

High-volume, routine visits → Pattern 1. Don’t overbuild.
Behavioral health, longer visits → Pattern 2. The assessment is the product.
Billing-first workflows → Pattern 3. Structured output feeds the codes.
High-stakes visits, willing to spend → Pattern 4. When the cost of a bad note is high enough.

The mistake we see vendors make is picking one pattern and applying it to every visit type. The cheap path is right for some encounters and not for others. A 2026-vintage pipeline routes visits to different patterns based on visit type, length, and complexity flags — the routing logic is usually simpler than the prompts themselves.

What this means for tech-curious clinic owners

If you’re evaluating a vendor, asking “which pattern do you use?” is a fair question. A confident technical answer — “single-shot for follow-ups, extract-then-narrate for new patients, draft-and-critic for new diagnoses” — tells you they’ve thought about cost and quality as a tradeoff. A vague answer (“we use the latest models”) tells you they haven’t.

If you’re building this internally, start with Pattern 1 and add complexity only when a specific visit type shows a clinician edit-rate problem. Premature optimization in this space is a real money sink.

For background on the underlying APIs, Anthropic’s prompt engineering documentation covers most of the techniques these patterns layer on top of. The patterns themselves come from running the system, not the docs.

Want to talk through which pattern fits your practice? Reach out — we’re happy to share what we’ve broken.

This post was drafted by AI and reviewed by our editorial team. Last updated 2026-05-30.