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.
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
AgentHuman
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.
5DecisionSplits on criteria evidenced and coding confidence
Criteria evidenced, coding clean
Reaches the approver ready to send.
Criterion unmet or coding unclear
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 required8 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 boundaryAgent 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 orderIllustrative example
Order
Payer
Policy version
Requirement
Criteria evidenced
Coding
Advanced imaging, outpatient
Commercial, in network
Read today
Authorisation required
88%
Proposed, not final
As receivedThe 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 usedPayer policy, datedPrior conservative therapyImaging report on file
Why it is heldOne criterion — a documented trial of conservative therapy — is not evidenced. The agent names the gap.
ActionApproveCorrect the codeSend back
What the score decidesIt decides how much the approver re-reads before sending, not whether the payer will approve.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every order and chargeFrom EHR orders and charge capture
03Requirement & criteria
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.
01Approved path
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.
02Human review
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.
04Build 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 captureEpic · Oracle Health · athenahealth MEDITECH · order and charge APIs
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 aggregateIllustrative 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 threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Approval, coder agreement or a denial reason moves in one payer or service line.
02Diagnose
Traced to the requirement lookup, a stale criteria source, a coding rule or the edit file.
03Improve
The source, rule or edit is refreshed, re-approved by coding and compliance, and version-linked.
04Verify
Re-run against held-out cases from that payer, including the ones that were denied.
05Learn
The denial becomes a regression case and the changed rule enters the coding runbook.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Workflow discovery and automation-boundary definition.
02EHR order and charge-capture API assessment.
03Payer requirement and clinical-criteria sourcing.
04Coding rules and edit-file mapping.
05Minimum-necessary document assembly.
06Code, modifier and necessity-linkage proposal.
07Pre-bill edit checks and hold rules.
08Coder review and approval workflow.
09Coder-agreement and drift evaluation.
10Submission channels — portal, 278 and API.
11Status tracking and deadline monitoring.
12Observability, deployment and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal 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 service lineProductionProduction EHR integrationAdvancedMulti-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 priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed 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 buildBuild 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 bringWe build with it
01The payers and service lines you want in scope→Payer requirement and clinical-criteria sourcingWeek 1
02Your coding rules, edit files and modifier policy→Coding-rule, edit-file and modifier policy mappingWeek 2
03Access to EHR order, charge and clearinghouse APIs→Epic order and charge APIs, clearinghouse and payer-portal setupWeek 2
04Minimum-necessary and release-of-information rules→Minimum-necessary document assembly and scopingWeek 3
05Real denials and appeals, including the ones you lost→Evaluation suite, regression cases and failure-mode testingWeek 4
06Named certified coders and authorisation approvers→Coder review and authorisation approval workflowWeek 4
07The channel each payer actually accepts today→Submission channels, status tracking and deadline monitoringWeeks 5–6
Nothing else is requiredDeployment, 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.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Payers and service lines in scope; who signs a codeW2Requirement lookup, criteria sourcing and coding-rule mappingW3Documentation assembly, code proposal and pre-bill editsW4Coder review workflow, evaluation suite and payer slicesW5Submission channels, first live requests and targeted correctionsW6Live requests sent under approval, then Agent Care monitoring
Reading the bandCoder 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 W6Requests have gone out under approval and a certified coder has signed every code, then Agent Care takes over monitoring.
DurationSix-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.
