Main site

Healthcare AI agent · Revenue cycle

Denials-Management & AR-Follow-Up AI Agent

Read remittance advice, classify why each claim denied, assemble the appeal with its supporting record and work aged AR by payer — with deadline tracking, audit trails and a person signing every appeal and write-off.

Typical delivery
4–6 weeks
Deployment
Your stack
Appeal sign-off
A named person
After launch
Agent Care

What this agent does

Builds the appeal, does not sign it

In

  1. 01

    Ingest remittance and denial lines from the 835, the payer portal or a paper EOB, against the claim as submitted.

  2. 02

    Pull the open balance, the claim and payment history, and any appeal already filed on the same claim.

Reason

  1. 03

    Read the group code, reason code and remark code together, and translate them into the cause the payer is asserting.

  2. 04

    Check that cause against the payer's own policy, the contract terms and the window that applies at each appeal level.

  3. 05

    Retrieve the order, note, authorisation and coding detail that would support the claim, and mark what is missing.

Decide

  1. 06

    Separate a corrected claim from an appeal, and mark the medical-necessity ones for a physician advisor.

  2. 07

    Hold a claim whose window is closing, whose evidence is thin, or whose balance would move to the patient.

Out

  1. 08

    Draft the packet — the letter, the level it is filed at and the record extract that supports it — for a named person to sign.

  2. 09

    Retain the denial line, the classification, the evidence attached, the deadline and every reviewer correction.

Product statement

The agent classifies, drafts and chases. Signing an appeal, approving a write-off and changing what a patient owes stay with a person.

Example workflow

One denial, end to end

  1. 1Remittance received835 file, payer portal or paper EOB, matched to the claim as it was submitted
  2. 2Denial line readGroup code, reason and remark codes, the adjustment amount and the line it lands on
  3. 3Root cause classifiedWhat the payer is asserting, read against its own policy and your contract terms
  4. 4Remedy and evidence assembledCorrected claim, appeal or hold; the level and deadline calculated; the supporting record pulled

No human action required

Stages 1 to 4 run without a person in the loop — reading, classifying and evidence-gathering finish before anyone is asked to look. A claim near its filing window ends that stretch early.

5DecisionSplits on classification confidence and what is at stake
Clear reason, evidence complete

Packet drafted and queued for signature.

Ambiguous reason or thin evidence

Goes to a specialist before anything is drafted.

Denials specialist

Reads the denial line, the proposed cause, the evidence pulled and the deadline, then signs — a physician advisor signs the medical-necessity ones.

Sign and file · Correct · Escalate

Signed — handed back

  1. 6Packet filed and AR workedOnly where write access and approval policy allow it; the appeal carries a person's signature
  2. 7Outcome evaluatedClassification accuracy, appeal outcome, deadline adherence and sampled write-offs by payer

Corrections

Root causes a reviewer re-classifies are counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Signing or filing an appeal.
    • Approving a write-off or a contractual adjustment.
    • Posting an adjustment to a patient's balance.
    • Deciding a denial is not worth appealing.

  • Automation boundary

    Agent acts unaided

    • ✓Read the remittance line and classify what the payer is actually asserting.
    • ✓Calculate the appeal level, the filing route and the window that applies.
    • ✓Assemble the appeal packet and the record extract that supports the claim.
    • ✓Work aged AR by payer and hold near-deadline and disputed accounts for review.

    Write actions run only inside the approval boundaries agreed during implementation. A patient's balance is not one of them.

    • Judging medical necessity or level of care.
    • Moving a balance to statements or collections.
    • Releasing records beyond what the appeal needs.
  • Changing appeal templates, deadline rules or write-off thresholds.

Example output

One denial line, annotated

Everything the agent proposes is attached to the remittance line it came from.

Denial output · single remittance line

Illustrative example
Claim
Outpatient infusion, one line
Filing window
Level 1, 41 days left
Denial line
CO-50, N115
Root cause
Medical necessity (LCD)
Confidence
88%
Proposed remedy
Appeal, not a corrected claim

As received

The remittance line, the claim it posted against and the window the payer's own notice opens — nothing on this side is inferred.

Evidence used

  • Payer coverage policy
  • Order and clinical note
  • Prior claim history

Why an appeal, not a resubmission

The payer is disputing coverage, not how the claim was built. A corrected claim would come back a duplicate.

What the score decides

Below the threshold the denial goes to a specialist before anything is drafted. A person signs on either path.

Action

Sign and fileCorrectEscalate

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every denied and unpaid claim

From the 835, the portal or the EOB

03Classification & evidence

Apply the payer's own rules

Use that payer's published policy, your contract terms, the appeal levels it actually runs and the window each one carries.

01Approved path

Take the reading and keying off the AR team

Remittance lines are read, classified and matched to a remedy before anyone opens the account.

02Human review

Work the queue by deadline and value

Ambiguous reasons, thin evidence and closing windows reach a specialist early, instead of the queue draining toward whatever closes fastest.

04

Build an evidence trail

Retain the denial line, the classification, the policy read, the evidence attached, the deadline and the reviewer's correction — on both paths.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Patient accounting & billing

    • Epic Resolute
    • Oracle Health
    • MEDITECH
    • patient-accounting APIs

  • Clearinghouse & EDI

    • 835 remittance
    • 837 claims
    • 277 status
    • clearinghouse APIs

  • Payer portals & policy

    • Payer portals
    • coverage policies
    • Fee schedules
    • contract terms

Agent

Denials management & AR follow-up

  • Classifies denials
  • Drafts the packet
  • Chases the balance

  • Clinical record & documents

    • EHR chart extract
    • orders and notes
    • Document management
    • appeal submission

  • Analytics & evaluation

    • Denials dashboards
    • OpenTelemetry
    • Langfuse
    • supported monitoring sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the patient's account

Each control wraps the one inside it. A denial clears every layer before anything is filed, and posting to a patient's balance sits outside all six.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeRestrict automation if evaluations or production signals degrade.Roll back
L5TraceabilityRecord the denial line, policy read, evidence sent, action and override.Record
L4Human approvalA person signs the appeal, the write-off and any patient adjustment.Gate
L3Disclosure scopeAttach only the record the appeal needs, and log what was sent.Restrict
L2Deadline guardrailsBlock a filing that is late, at the wrong level or already in flight.Block
L1Confidence thresholdsAmbiguous denial reasons go to a specialist before anything is drafted.Require review
Model coreDenial proposal — root cause, remedy, appeal level, evidence and classification confidence
L1 – L2
Decide whether the appeal may be filed
L3
Decides how much record leaves the building
L4 – L5
Keep money decisions with a person
L6
Pulls automation back when signals degrade

How Nestack evaluates it

Evaluate the whole denial — not only the appeals that were filed.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the worklist the AR team opens

  1. E1Final-output evaluationWas the denial's root cause classified correctly?
  2. E2Step-level evaluationDid it read the right policy, appeal level and filing window?
  3. E3Tool evaluationDid it read and write the correct claim, account and record?
  4. E4Packet evaluationDid the attached evidence support the claim, and was it overturned?
  5. E5Slice evaluationHow does performance change across payers and denial types?
  6. E6Business outcomeWere deadlines met, and were write-offs appropriate on sampling?

Floor — the balance that is recovered, appealed or written off

Failure modes

Where each failure originates in the agent

Seven failure modes plotted against the five stages of the agent lifecycle.

Agent lifecycle

Direction of processing →

  1. 01 · Remittance read

    2 modes

    • DN-01

      Catch-all reason code

      The payer's code carries no cause anyone can act on.

    • DN-02

      Adjustment read as patient debt

      A contractual reduction lands on the patient's balance.

    Stage gathers

    The denial line, the claim history and the open balance

  2. 02 · Classification

    2 modes

    • DN-03

      Wrong remedy chosen

      A billing error is appealed instead of corrected and resent.

    • DN-04

      Wrong level or missed window

      Filed late, or at a level that payer does not run.

    Stage proposes

    The cause, the remedy, the level and the deadline

  3. 03 · Evidence & packet

    1 mode

    • DN-05

      Packet proves the wrong thing

      The extract does not support that claim, or shows far more.

    Stage assembles

    The record extract and the letter a person signs

  4. 04 · Filing / write

    1 mode

    • DN-06

      Written off, not appealed

      A recoverable denial is queued as an adjustment.

    Stage files

    Only where write access and approval policy allow it

  5. 05 · Change / Version

    1 mode

    • DN-07

      Silent payer-rule drift

      A payer changes policy and the classifier keeps the old one.

    Stage tracks

    Model, prompt, payer-rule and threshold changes

  • Sev-1 · a patient is billed or a right lapses
  • Sev-2 · the wrong remedy reaches the payer
  • Sev-3 · the reason is unclear, it routes to review
See the complete Healthcare failure-mode catalogue

Affected slices

Denial performance is a payer-by-payer question

Aggregate classification quality can look acceptable while two or three payer and denial-type cohorts carry most of the misclassification, most of the reviewer corrections and nearly all of the deadline risk. Nestack reports performance by slice, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Medical-necessity denials5.1%3.4×Review
Medicare Advantage post-acute4.2%2.8×Review
Medicaid and dual-eligible accounts2.9%1.9×Watch
Routine contractual adjustments1.0%0.7×Normal

Bar: lift vs. contractual-adjustment baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

Working the same denial twice means nothing went upstream

A recovered claim is not a closed case. Where the cause sat in registration, authorisation or coding, the fix belongs there — and with that team.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Misclassification, corrections or days-to-file move in a payer slice.

  2. 02

    Diagnose

    Traced to the code read, the policy version, the deadline rule or the remedy chosen.

  3. 03

    Improve

    The code mapping, deadline rule or evidence template is re-approved and version-linked.

  4. 04

    Verify

    Re-run against held-out remittances from that payer, including the ones that failed.

  5. 05

    Learn

    That denial becomes a regression case and, where preventable, a front-end change request.

  6. Learn → Detect

    The return edge. A preventable denial is handed to registration, authorisation or coding — not absorbed by the AR team.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, remittance, classification and evidence, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Workflow discovery and automation-boundary definition.Week 1
  2. 02Clearinghouse and patient-accounting access.Week 1, Week 2
  3. 03Payer matrix: appeal levels and deadlines.Week 1, Week 2
  4. 04Remittance ingestion and normalisation.Week 2
  5. 05Root-cause classification and remedy routing.Week 2, Week 3
  6. 06Deadline and duplicate-filing guards.Week 3
  7. 07Evidence retrieval and disclosure scope.Week 3, Week 4
  8. 08Appeal-packet drafting and signature workflow.Week 4
  9. 09Write-off and adjustment approval controls.Week 4, Week 5
  10. 10Payer-slice evaluation and regression cases.Week 4, Week 5
  11. 11AR worklist, filing and posting write-back.Week 5, Week 6
  12. 12Observability, deployment and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne payer, one denial typeProductionProduction AR integrationAdvancedMulti-payer / multi-facility
Introduced at Pilot
Denial root-cause classification✓✓✓
Deadline and duplicate guardrails✓✓✓
Minimum-necessary disclosure scope✓✓✓
Appeal and write-off signed by a person✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Payer matrix and policy retrieval—✓✓
Appeal-packet drafting with evidence—✓✓
AR worklist, write-back after approval—✓✓
Observability and evaluation—✓✓
Introduced at Advanced
Multi-payer and multi-facility——✓
Enterprise controls and audit reporting——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on payer mix, clearinghouse and patient-accounting integrations, denial volume, appeal routes, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your payer matrix — appeal levels, routes and deadlines

    Payer matrix: appeal levels, deadlines and filing routes

    Week 1

  2. 02A representative sample of remittance files and denied claims

    Remittance ingestion, denial-line normalisation and the classification baseline

    Week 2

  3. 03Access to patient accounting, the clearinghouse and payer portals

    Epic Resolute, clearinghouse 835/837 and payer-portal integration

    Week 2

  4. 04Minimum-necessary and release-of-information rules

    Evidence retrieval scope, redaction and disclosure logging

    Week 3

  5. 05Your write-off, adjustment and patient-billing policy

    Write-off and patient-adjustment approval controls

    Week 4

  6. 06Appeals you lost, and the ones you should have filed

    Evaluation suite, regression cases and failure-mode testing

    Week 4

  7. 07Named denials specialists and a physician advisor

    Signature workflow, then pilot filings and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Phases are drawn over the weeks they actually occupy. Week 5 carries both the payer-slice evaluation and the first supervised filings.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Payer matrix mapped: appeal levels, routes and deadlines

W2Remittance ingestion and the denial-classification baseline

W3Remedy routing, deadline rules and evidence retrieval scope

W4Evaluation suite, write-off controls and failure-mode testing

W5AR worklist integration, supervised filings and corrections

W6A full appeal cycle filed under signature, then Agent Care starts

Reading the band
Week 5 carries two bars: the first supervised filings are what the evaluation suite is run against, not something that follows it.
At the end of W6
A full appeal cycle has been drafted, signed and filed under supervision, then Agent Care takes over monitoring.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Healthcare AI agent

Build a denials agent around the way your AR team already works.

Show us a month of remittance, your payer matrix and how a write-off gets approved today. We'll classify that month's denials against the causes you already track, then agree what a person signs before anything is filed.

Typical delivery
4–6 weeks
Deployment
Your revenue-cycle stack
Appeal sign-off
A named person, always
After launch
Agent Care available

Nestack Agents · Denials management & AR follow-up

AGT-HC-06 · Agent Care available after launch

Build a denials and AR agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your systems

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.