Healthcare AI agent · Revenue cycle
Prior-Authorization & Claims-Coding AI Agent
Check whether an order needs authorisation, assemble the clinical packet, submit and track it, and propose codes with the documentation behind them — the payer decides coverage, a certified coder signs the code.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Code sign-off
- Certified coder
- After launch
- Agent Care
What this agent does
Does the paperwork, not the determination
In
- 01
Read the order, the encounter and the coverage on file, and take the charge as it was captured.
- 02
Retrieve the payer's authorisation requirement and criteria for that code and plan, stamped with the date read.
Reason
- 03
Assemble the documentation the published criteria ask for, and mark each criterion met, unmet or not evidenced.
- 04
Propose diagnosis and procedure codes, modifiers and linkage from what the encounter documents, not reimbursement.
- 05
Run the pre-bill checks: code-pair edits, coverage policy, units, place of service and the authorisation on file.
Decide
- 06
Hold anything where a criterion is unmet, the record is thin, or the payer's policy has moved since it was last read.
- 07
Route every proposed code to a certified coder and every packet to the person who submits it.
Out
- 08
Submit on the approved channel, track status, and draft the response to an additional-information request.
- 09
Retain the criteria version, the documents sent, the codes proposed, the coder's change and every payer response.
Product statement
The agent prepares and submits what a person approves. It does not decide coverage, and no code it proposes reaches a claim without a certified coder.
Example workflow
One request, end to end
- 1Order or charge receivedAn order signed in the EHR, or a charge captured from a completed encounter
- 2Requirement checkedPayer, plan, code and place of service against the payer's current requirement, with the date it was read
- 3Criteria and evidence matchedEach published criterion set beside the notes, results and prior therapy in the record that speak to it
- 4Codes and edits proposedDiagnosis, procedure, modifiers and linkage, then code-pair, coverage-policy and unit checks before anything is billed
No human action required
Stages 1 to 4 run without a person in the loop — the requirement check, the packet and the coding proposal are finished before anyone is asked to read anything.
Reaches the approver ready to send.
Held with the gap named, not submitted.
Coder and authorisation approver
A certified coder confirms or changes the codes; the approver checks the packet against what the payer asked for and sends it.
Approve · Correct the code · Send back
Approved — handed back
- 6Submitted and trackedOn the portal, EDI 278 or API the payer accepts; status, pends and information requests are followed to close
- 7Outcome evaluatedRequirement detection, first-pass approval, coder agreement, turnaround and appeal result by payer and service line
Coder changes
Every code the coder changes is counted, in both directions.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Deciding that a service is medically necessary.
- Finalising any code that goes on a claim.
- Submitting an authorisation request to a payer.
- Adding a diagnosis the encounter does not document.
Automation boundary
Agent acts unaided
- ✓Check the payer's current requirement for that code, plan and setting.
- ✓Assemble the documentation the published criteria ask for.
- ✓Propose codes, modifiers and linkage from what the encounter documents.
- ✓Track status, pends and information requests across every channel.
Write actions run only inside the approval boundaries agreed during implementation. Sending a request and finalising a code are not among them.
- Applying a modifier that clears an edit pair.
- Choosing what clinical documentation leaves the organisation.
- Appealing, withdrawing or accepting a payer determination.
- Changing coding rules, edits or criteria sources.
Example output
One authorisation request, annotated
Everything the agent proposes is attached to the order and the record it came from.
Prior-authorisation output · single order
Illustrative example- Order
- Advanced imaging, outpatient
- Payer
- Commercial, in network
- Policy version
- Read today
- Requirement
- Authorisation required
- Criteria evidenced
- 88%
- Coding
- Proposed, not final
As received
The order and the coverage as they stand in the EHR, and the date the payer's policy version was read — nothing on this side is inferred.
Evidence used
- Payer policy, dated
- Prior conservative therapy
- Imaging report on file
Why it is held
One criterion — a documented trial of conservative therapy — is not evidenced. The agent names the gap.
What the score decides
It decides how much the approver re-reads before sending, not whether the payer will approve.
Action
ApproveCorrect the codeSend backValue
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 order and charge
From EHR orders and charge capture
Apply the payer's own current rules
Use the requirement, clinical criteria and edits the payer publishes, read at the time of submission and stamped with the date.
Take the assembly work off the queue
The requirement check, the criteria mapping and the document pull are done before a person opens the case, so the approver reviews rather than gathers.
Surface the gap before submission
Cases where a criterion is unmet or the note does not support the code are held now, instead of returning as a denial three weeks later.
Build an evidence trail
Retain the criteria version, the documents sent, the codes proposed, the coder's change, the payer's response and the reason given — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
EHR & charge capture
- Epic
- Oracle Health
- athenahealth
- MEDITECH
- order and charge APIs
Payer submission
- Payer portals
- clearinghouses
- EDI 278
- payer authorisation APIs
Code sets & policy
- ICD-10-CM/PCS
- CPT/HCPCS
- Code-pair edits
- payer medical policy
Agent
Prior authorisation & claims coding
- Checks requirement
- Assembles packet
- Proposes codes
Coding & documents
- CDI platforms
- encoders
- Document management
- attachments
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the payer
Each control wraps the one inside it. A request clears every layer before it is sent, and the coverage decision sits outside all six.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Decide whether the proposal may stand
- L3
- Decides who signs the code and sends
- L4 – L5
- Keep disclosure narrow and the trail intact
- L6
- Pulls automation back when signals degrade
How Nestack evaluates it
Evaluate the whole submission — not only whether it was approved.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the packet and the codes a person approves
- E1Final-output evaluationWas authorisation actually required, and did the packet meet the stated criteria?
- E2Step-level evaluationDid it read the payer's current policy and evidence each criterion from the record?
- E3Tool evaluationDid it submit to the correct payer, channel, patient and service?
- E4Coder agreement and driftDo the codes match a certified coder's, and does error drift up or down?
- E5Slice evaluationHow does performance change across payers, service lines and request types?
- E6Business outcomeFirst-pass approval, turnaround, and the denials the agent's own work caused.
Floor — the claim that is paid and stays paid
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 →
01 · Requirement lookup
2 modes
- PA-01
Requirement missed
The service needed one and none was sought.
- PA-02
Superseded payer criteria
The packet is built against a policy the payer has replaced.
Stage checks
Payer, plan, code, setting and the policy version
02 · Criteria & coding
2 modes
- PA-03
Necessity link unsupported
A criterion is marked met with no note behind it.
- PA-04
Upward code drift
The proposed level exceeds what is documented.
Stage proposes
Criteria mapping, codes, modifiers and linkage
03 · Submission
1 mode
- PA-05
Over-disclosure in the packet
The whole chart goes where three documents were asked for.
Stage sends
Only on the channel and scope a person approved
04 · Tracking
1 mode
- PA-06
Pend lost between channels
A portal records request never reaches the case.
Stage follows
Status, pends and additional-information requests
05 · Change / Version
1 mode
- PA-07
Silent edit-file regression
A rule change shifts modifier use unnoticed.
Stage tracks
Model, prompt, edit-file and criteria-source changes
- Sev-1 · a claim would not survive audit
- Sev-2 · the submission is wrong or over-broad
- Sev-3 · the case stalls and a deadline is at risk
Affected slices
First-pass approval is not the same across payers
Aggregate approval and coder-agreement rates can look acceptable while a few payer and service-line cohorts carry most of the rework, most of the code changes and nearly all of the denial risk. Nestack reports performance by slice, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Medicaid and managed-Medicaid plans | 5.5% | 3.4× | Review | |
| Behavioural-health service lines | 4.4% | 2.8× | Review | |
| Payer policies changed this quarter | 3.1% | 1.9× | Watch | |
| Repeat in-network routine orders | 1.1% | 0.7× | Normal |
Bar: lift vs. routine in-network baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
The ground truth moves whether or not the agent does
Payer criteria are rewritten mid-quarter and code sets turn over with the year. A cycle that never re-dates the source it reads closes the wrong thing.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Approval, coder agreement or a denial reason moves in one payer or service line.
- 02
Diagnose
Traced to the requirement lookup, a stale criteria source, a coding rule or the edit file.
- 03
Improve
The source, rule or edit is refreshed, re-approved by coding and compliance, and version-linked.
- 04
Verify
Re-run against held-out cases from that payer, including the ones that were denied.
- 05
Learn
The denial becomes a regression case and the changed rule enters the coding runbook.
Learn → Detect
The return edge. Every cycle also re-dates the payer sources the agent reads — a correct answer last quarter is not one now.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, requirement and criteria sourcing, coding and edits, evaluation, submission, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Workflow discovery and automation-boundary definition.Week 1
- 02EHR order and charge-capture API assessment.Week 1, Week 2
- 03Payer requirement and clinical-criteria sourcing.Week 1, Week 2
- 04Coding rules and edit-file mapping.Week 2
- 05Minimum-necessary document assembly.Week 2, Week 3
- 06Code, modifier and necessity-linkage proposal.Week 3
- 07Pre-bill edit checks and hold rules.Week 3, Week 4
- 08Coder review and approval workflow.Week 4
- 09Coder-agreement and drift evaluation.Week 4, Week 5
- 10Submission channels — portal, 278 and API.Week 5
- 11Status tracking and deadline monitoring.Week 5, Week 6
- 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 tier | PilotOne payer, one service line | ProductionProduction EHR integration | AdvancedMulti-payer / multi-site |
|---|---|---|---|
| Introduced at Pilot | |||
| Requirement and criteria lookup | ✓ | ✓ | ✓ |
| Documentation assembly | ✓ | ✓ | ✓ |
| Code and modifier proposals | ✓ | ✓ | ✓ |
| Certified-coder sign-off | ✓ | ✓ | ✓ |
| Baseline evaluation | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Payer-specific criteria sources | — | ✓ | ✓ |
| Pre-bill edit and hold rules | — | ✓ | ✓ |
| Portal, EDI 278 and API — approver sends | — | ✓ | ✓ |
| Status tracking and observability | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Appeal-packet preparation | — | — | ✓ |
| Multi-payer and enterprise controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on payers and service lines in scope, submission channels, EHR and clearinghouse integrations, request volume, coding review 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.
You bring
We build with it
01The payers and service lines you want in scope
→Payer requirement and clinical-criteria sourcing
Week 102Your coding rules, edit files and modifier policy
→Coding-rule, edit-file and modifier policy mapping
Week 203Access to EHR order, charge and clearinghouse APIs
→Epic order and charge APIs, clearinghouse and payer-portal setup
Week 204Minimum-necessary and release-of-information rules
→Minimum-necessary document assembly and scoping
Week 305Real denials and appeals, including the ones you lost
→Evaluation suite, regression cases and failure-mode testing
Week 406Named certified coders and authorisation approvers
→Coder review and authorisation approval workflow
Week 407The channel each payer actually accepts today
→Submission channels, status tracking and deadline monitoring
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 coder-agreement evaluation and the first live submissions.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Payers and service lines in scope; who signs a code
W2Requirement lookup, criteria sourcing and coding-rule mapping
W3Documentation assembly, code proposal and pre-bill edits
W4Coder review workflow, evaluation suite and payer slices
W5Submission channels, first live requests and targeted corrections
W6Live requests sent under approval, then Agent Care monitoring
- Reading the band
- Coder review is built in week 4, before a single request goes out in week 5. The bars show that dependency, not a smooth ramp.
- At the end of W6
- Requests have gone out under approval and a certified coder has signed every code, 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 prior-authorisation and coding agent around your revenue cycle.
Show us the payers and service lines that generate your authorisation work, how a request reaches a payer today, and who signs a code. We'll take one payer and one service line end to end, then scope from there.
- Typical delivery
- 4–6 weeks
- Deployment
- Your EHR and revenue-cycle stack
- Code sign-off
- Certified coder, always
- After launch
- Agent Care available
Nestack Agents · Prior authorisation & claims coding
AGT-HC-03 · Agent Care available after launch