Case studyCase 02
Medical coding worked by the system, checked by people
- Hospital coding team
- 100,000+ records a year
- 94% accuracy
Results
What changed, and what each number rests on.
94%
Coding accuracy
Basis: Measured against coder review in production
~87%
Faster per record
Basis: Operating baseline versus after
100,000+
Records a year
Basis: Production throughput
Full audit trail
Every code and every decision logged
Basis: By design
Source-traced
Each code linked to the text it came from
Basis: By design
Review queue
Low-confidence records wait for a coder
Basis: By design
Company profile
- Company
- A hospital coding team
- Stack
- The hospital's record system, the current ICD-10, ICD-10-PCS, and CPT code sets, and the team's review queue
- Operating need
- Work a growing backlog of records without adding coders or letting accuracy slip.
The challenge
Where the work was stuck.
A trained coder read each record, assigned diagnosis and procedure codes by hand, and checked them against rules that change every year. The work was slow, expensive, and unforgiving: a wrong code meant a denied claim, a compliance question, or both. The backlog set the pace of billing.
The team had looked at coding software before. What it found were tools that suggested codes without showing their reasoning, which meant a coder still had to re-read the record to trust the suggestion. The team needed a system that could do the reading, show its work, and know when it was unsure.
The audit
Six systemic patterns.
- Each record passed through the same three steps, extraction, coding, and validation, but one person did all three, so throughput was capped by reading speed.
- Most of the time went to finding the relevant text, not to the coding decision itself.
- Code-set updates arrived on a calendar, and every update meant relearning edge cases.
- Errors were caught downstream, at claim denial, long after the record was closed.
- There was no record of why a code was chosen, so a review meant starting over.
- The backlog hid the difference between routine records and the hard ones that deserved a coder's attention.
The coders were not the bottleneck. The team was missing the layer that reads, drafts, validates, and shows its work.
The architecture
Five components, installed in order.
- 01ExtractionAn agent that reads each record and pulls the clinical facts a coder would mark: diagnoses, procedures, laterality, and context, each tied to the text it came from.
- 02CodingA second agent that maps those facts to codes, using retrieval over the current code sets with hybrid search and re-ranking so candidate codes come from the official text, not from memory.
- 03ValidationA third agent that checks the draft against coding rules and record consistency, and assigns a confidence score to every code.
- 04Code-set managementYear-wise versions of ICD-10, ICD-10-PCS, and CPT, so a record is coded against the set in force on its date of service.
- 05Review queue and audit trailLow-confidence records go to a coder with the source text beside the draft. Every decision, prompt, and result is logged, exportable, and retained to the hospital's policy.
Anonymization
The hospital is not named. The architecture and the numbers are as they ran.
- Names withheld: the hospital, its departments, and its staff are not identified.
- Numbers from the operating baseline: accuracy and speed are measured against how the team worked before.
- Uncertain records go to a person: any code below the confidence threshold waits for a coder, and still does.
Implementation
Four stages, one set price.
| Stage | Focus | Key results |
|---|---|---|
| Map | How a record moved from close to claim, where the time went, which records were routine, and how errors surfaced. | An operating map, a baseline of minutes per record, and a written scope with one set price. |
| Build and review mode | Extraction, coding, and validation agents running on real records, with coders reviewing every draft before it stood. | Drafts with source text beside every code, accuracy measured against coder decisions. |
| Controls | Confidence thresholds, the review queue, code-set versioning, and the audit trail. | Routine records coded on their own. Everything uncertain to a coder. |
| Launch and run | Live on the full record flow, monitored in production, reported weekly. | 94% accuracy, about 87% faster per record, 100,000+ records a year. |
Ownership
What the client keeps.
- Every outcome: the coded records and the faster billing cycle belong to the hospital.
- The data: records, drafts, and review decisions never leave the hospital's environment.
- The documentation: the coding rules, the thresholds, and the runbook for code-set updates.
- The named owner: the coding lead who owns the review queue and reads the weekly report.
The next phase
What this makes possible next.
The planned next phase is denial handling on the same layer: reading the payer's reason, matching it to the record and the code, and drafting the response for a coder to approve. The extraction and audit layers already exist, so it is an addition, not a second build.
Related analysis
Healthcare compliance and AI automationThe hospital's identity is withheld. The numbers are from the system running in production.
Your first department
Bring the process you still run by hand.
One mapping call. You leave with the system design, the price in writing, and the date it goes live.
How it works
From the first call to a system in production.
The six steps every installation follows, with the output and the control at each one, and the 90-day shape.
See the process