Claude as a Clinical Abstractor: The Agent Architecture

A clinical abstractor reads a messy patient chart and pulls out structured truth: the principal diagnosis, the procedures, the staging, the medication reconciliation. They do it with a specific discipline — every value they record can be traced back to a sentence in the source. If you have ever tried to make a language model do this job, you have probably watched it confidently fabricate a stage IV when the note said stage II, or merge two encounters into one because the dates blurred together. The fix is not a better prompt alone. It is an architecture that forces evidence-bound reasoning at every step.

This post walks through that architecture end to end — the pieces, the data flow, and the design decisions that make Claude behave less like a chatty assistant and more like a disciplined abstractor. We are not building a toy. We are describing the shape of a production system you could actually run against thousands of charts.

What a clinical abstractor actually does

Before you design the system, name the job precisely. Clinical abstraction is the process of reading unstructured clinical documentation and producing structured, source-attributed data elements according to a defined schema and coding standard. The three load-bearing words are structured, source-attributed, and defined schema. A model that returns plausible JSON but cannot point to the exact span that justified each field has not done abstraction — it has done creative writing.

That definition drives every architectural choice below. Structured output means the schema is a first-class artifact, not an afterthought. Source-attributed means the system must carry evidence spans alongside values. Defined schema means the abstraction rules — what counts as a comorbidity, how to break ties between conflicting notes — live somewhere the model can read, not in a human's head.

The end-to-end pipeline

The system decomposes into five stages: ingestion, retrieval, a reasoning loop where Claude works the chart, validation against the schema and coding rules, and a human-review gate for low-confidence elements. Each stage has a narrow contract, which is what keeps the whole thing debuggable. When abstraction quality drops, you want to know whether retrieval missed the relevant note or whether the reasoning step misread it — and a clean stage boundary tells you that.

flowchart TD
  A["Raw chart: notes, labs, meds"] --> B["Ingestion & section parsing"]
  B --> C["Chunk + index by encounter"]
  C --> D{"Element needs evidence?"}
  D -->|Yes| E["Retrieve candidate spans"]
  E --> F["Claude reasons over spans"]
  D -->|No| F
  F --> G["Schema & coding validation"]
  G -->|Low confidence| H["Human abstractor review"]
  G -->|Confident| I["Attributed structured record"]

The arrow that matters most is the one from F back through validation. Claude does not get to emit the final record directly. Its proposed values pass through a deterministic validator that checks the schema, applies coding-standard rules, and recomputes confidence. This is the architectural seam where you convert a probabilistic model into a system you can put a quality SLA on.

Why retrieval comes before reasoning

A single inpatient chart can run to hundreds of pages. Even with Claude's large context window, dumping the entire chart into every abstraction request is wasteful and, worse, it dilutes attention across irrelevant material. The abstractor pattern instead retrieves a focused candidate set per element. When you ask for the principal diagnosis, you want the discharge summary's assessment section and the problem list — not the dietary notes.

The retrieval layer indexes by encounter and by document section, because clinical reasoning is encounter-scoped. A medication active during one admission may be irrelevant to another. By tagging every chunk with its encounter id, document type, and timestamp, the retriever can hand Claude a tight, temporally coherent slice. The model reasons better over five relevant pages than over five hundred mixed ones, and the smaller payload keeps latency and token spend in check.

Evidence linking as a structural requirement

The single most important architectural decision is that evidence is not optional metadata — it is part of the output contract. Every value Claude proposes must arrive with the span that justifies it: a document id, a character range or quoted snippet, and the model's reasoning for why that span supports that value. If Claude cannot produce a span, the value is rejected before it reaches validation.

This changes the model's behavior more than any instruction phrasing. When the output schema literally requires { value, evidence_span, document_id, rationale } for each element, the path of least resistance is to find the supporting text. Hallucination becomes harder than honesty. You enforce this with a tool definition or a structured-output schema that has no field for an unsupported value, so there is no place for an invented one to go.

Where Claude's models fit

Not every step deserves the most expensive model. A practical deployment routes by difficulty. Section parsing and routine field extraction — patient demographics, admission date — run well on Claude Haiku 4.5, which is fast and cheap. The genuinely hard reasoning — reconciling conflicting notes, inferring staging from scattered pathology and imaging, judging whether a documented condition meets the abstraction definition — is where Claude Opus 4.8 earns its keep. Sonnet 4.6 sits comfortably in the middle for the bulk of well-specified extractions.

This tiering is an architectural choice with real cost implications. A chart might involve dozens of element extractions; sending all of them to Opus is rarely justified. Profile your elements by how often the cheaper model disagrees with the expensive one on a labeled set, then route accordingly. The hardest 10–20% of elements typically drive most of the error, and those are the ones worth the strong model.

The validation and review gate

The validator is deliberately boring and deterministic. It checks that codes exist in the relevant code set, that dates fall inside the encounter window, that mutually exclusive fields are not both set, and that every value carries evidence. It assigns a confidence score that combines the model's self-reported certainty with rule-based signals — a value contradicted by another retrieved span gets demoted automatically.

Anything below the confidence threshold routes to a human abstractor, who sees Claude's proposed value and the evidence span side by side. This is the difference between a system that replaces abstractors and one that makes them several times faster: the human reviews evidence rather than re-reading the whole chart. Over time, the reviewed disagreements become your eval set, and the architecture tightens itself.

Frequently asked questions

Do I still need retrieval if Claude has a huge context window?

Usually yes. A large window lets you fit the chart, but focused retrieval still improves accuracy and cuts cost. Attention is finite even at a million tokens, and per-element retrieval gives you cleaner attribution because you know exactly which slice produced each value.

How does this architecture prevent hallucinated diagnoses?

By making evidence a required part of the output schema and rejecting any value without a verifiable source span. The model cannot emit a diagnosis it cannot point to, and the deterministic validator double-checks that the cited span actually exists in the document.

Where does the abstraction rulebook live?

In a place the model reads at runtime — typically an Agent Skill or a retrieved policy document — not baked into a single prompt string. This lets clinical informaticists update definitions without redeploying code, and keeps the same rules consistent across every element.

Can one Claude agent do all of this, or do I need multiple?

A single agent with good tools can run the whole loop, but many teams split it: a retrieval-and-extraction subagent per element type and an orchestrator that assembles the final record. Multi-agent runs cost several times more tokens, so reserve the split for charts complex enough to justify it.

Bringing agentic reasoning to your phone lines

The same evidence-bound, tool-driven discipline that makes Claude a reliable abstractor is what makes a voice agent trustworthy on a live call. CallSphere applies these agentic-AI patterns to voice and chat — assistants that retrieve the right record mid-conversation, act on it, and book work around the clock. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.