Denial & Appeals Assistant
Reads a remittance and the provider's records, explains each denied line in plain English, decides whether it is worth an appeal, a corrected claim or nothing, and drafts the appeal letter from evidence it has verified.
Rework on both sides of every denial
A denied claim costs the provider staff time to understand and the payer staff time to process again on appeal. Many denials are fixable: a missing modifier, a record that was never sent, a filing date the payer lost track of. Others aren't worth pursuing. The hard part is telling them apart quickly and sending the right evidence the first time. The same assistant works for a provider's billing team or a health plan's provider-services desk.
Two model calls, with code checks between them
| Step | Who does it | Why |
|---|---|---|
| 1. Remittance parsing | Code | Denied lines, group codes and CARC/RARC meanings come from lookup tables, not from the model. |
| 2. Identifier redaction | Code | Names, dates of birth, MRNs, account numbers and phone numbers are removed first. |
| 3. Denial analysis | Claude Opus 5.5 | Per denied line: plain-English reason, category, suggested action and verbatim evidence. |
| 4. Evidence check | Code | A line is pursued only if verified quotes from the provider's own records answer the denial. Strength is scored from how many. |
| 5. Appeal letter | Claude Opus 5.5 | Drafted only for lines that passed step 4, and only from their verified quotes. |
| 6. Letter check | Code | Every quoted passage in the letter is matched against the records and policy before a person signs it. |
Corrected-claim instructions are assembled in code (replacement claim, frequency code 7, original claim number), so the model only supplies the fix for each line.
Measured against labeled lines
Live run on claude-opus-5-5, 2026-11-01. Labeled set: 3 synthetic claims, 5 denied lines.
| Metric | Result | Definition |
|---|---|---|
| Action accuracy | 100% | Final recommendation (appeal, corrected claim, don't pursue) matches the label |
| Category accuracy | 100% | Denial category matches the label |
| Citation verification rate | 100% | Quotes found verbatim in the cited record or policy |
| Unsupported appeals | 0 | Lines recommended for appeal or correction that the label says not to pursue (target: 0) |
Five labeled lines demonstrate the pipeline; they don't make a benchmark.
Three synthetic denials
What changes in a real deployment
Integration
- Read 835 remittances and 277CA acknowledgments from the clearinghouse feed
- Pull records from the EHR document store; full CARC/RARC tables, updated with each X12 release
- Submit corrected claims as 837 replacements and appeals through the payer portal or API
Learning loop
- Record appeal outcomes and train an overturn model to replace the rule-based strength score
- Report denial trends by code and payer so front-end billing fixes the root cause
- Human sign-off on every letter, with an audit trail of what was sent
The same engine in TypeScript and Java
Both versions return the same JSON for every demo case. Contract tests generated from the TypeScript engine run against the Java service on every build.
TypeScript (this site)
- Engine: the model call, checks and decision rules
- API route and pages
- Synthetic data and recorded runs
Java (Spring Boot)
- appeals-engine-java: the service, with its contract test
- payer-ai-common: shared model calls, live limits and checks
- Contract tests: the expected output for each case