Healthcare AI agent · Risk-adjustment & RADV
Risk-Adjustment & RADV Audit-Defence AI Agent (HCC)
Read the retrieved chart against each submitted diagnosis, show what it supports and what it does not, and propose additions and deletions, encounter attached, for a certified coder to accept.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Coder sign-off
- Pre-submission
- After launch
- Agent Care
What this agent does
Reviews both directions, decides neither
In
- 01
A chart is retrieved from the EHR or scanned record, alongside the diagnoses already submitted for that member.
- 02
Normalise provider type, encounter type, date of service and diagnosis code across sources.
Reason
- 03
Read the chart against every submitted diagnosis, and against what else the record could support.
- 04
Apply the acceptable-provider and acceptable-encounter rules configured for the plan, never assumed.
- 05
Bind each proposed change to the encounter that supports it, and mark what the chart leaves unclear.
Decide
- 06
An encounter is read for provider type, encounter type and whether it documents the condition at all.
- 07
Route every proposed addition and every proposed deletion to a certified coder for acceptance.
Out
- 08
Retain the chart excerpt, the proposed change, the coder's decision and the reason against the member record.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
The agent proposes an addition or a deletion; a certified coder decides, and the plan stays responsible for the record a RADV audit would review.
Example workflow
One diagnosis, chart to acceptance
- 1Chart retrievedEHR chart pull, HIE feed, scanned record or prior submission file
- 2Support assessedProvider type, encounter type, date of service, prior submissions and model-year rules
- 3Change proposedProposed addition or deletion, the cited encounter and confidence
- 4Controls appliedProvider-type checks, encounter-type checks, prior-submission checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is submitted or deleted at any of them — the agent is proposing, and the coder's lane opens at the confidence gate.
Goes to a certified coder to accept.
Adds a clinical-validation read first.
Coder acceptance
The change is held with its cited encounter, the chart excerpt and the confidence.
Accept · Edit · Send for clinical review
Accepted — ready to submit
- 6Coding and submission system updatedOnly where write access and approval policy allow it
- 7Outcome evaluatedSupport accuracy, coder edits, deletions confirmed and audit findings
Coder edits
Every coder edit made at acceptance is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Adding or deleting a diagnosis on a submission.
- Deciding whether a chronic condition is still active.
- Overriding the acceptable-provider or encounter-type rule.
- Estimating or promising a RADV audit outcome.
Automation boundary
Agent acts unaided
- ✓Read the chart against each submitted diagnosis, both ways.
- ✓Propose additions and deletions against configured support rules.
- ✓Cite the encounter and excerpt behind every proposed change.
- ✓Flag what needs clinical judgment, and hold it for the coder.
Any write happens inside the boundaries agreed at implementation, never ahead of acceptance.
- Leading a provider query toward a specific diagnosis.
- Treating an in-home-assessment-only finding as fully supported.
- Setting incentive pay tied to how many diagnoses are added.
- Changes to support rules or model-year configuration.
Example output
One diagnosis, annotated
Everything the agent proposes is attached to the chart it was drawn from.
Support output · single diagnosis
Illustrative example- Member
- Chronic-condition chart review
- Proposed change
- Diabetes with chronic complications, confirmed at a face-to-face visit
- HCC category
- HCC 18
- Encounter source
- Endocrinology office visit
- Confidence
- 91%
- Support status
- Face-to-face encounter confirmed
As received
Taken from the retrieved chart and the encounter it cites — nothing on this side is inferred by the agent.
Chart evidence used
- Office-visit progress note
- Signed by the provider
- Prior-year submission
Why this reads as supported
The note ties the diagnosis to today's visit and a credentialed provider.
What the score decides
Below the configured threshold the change picks up a clinical-validation read.
Action
AcceptEditSend for clinical reviewValue
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 diagnosis on file
From the chart and the submission file
Read for both directions
Weigh what's already submitted against what the chart newly supports, and what it no longer does.
Review that only adds is not review
A code proposed for addition and a code proposed for deletion move through the same read, not two.
Point the coder at what needs judgment
In-home-assessment findings and low-confidence changes are marked, so the coder's read starts where support is thinnest.
Build an evidence trail
The diagnosis, the encounter it was read from and the coder who accepted it stay on the member record.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
EHR and chart systems
- Epic
- Cerner
- Allscripts
- MEDITECH
- HL7/FHIR chart feeds
Risk-adjustment platforms
- Inovalon
- Cotiviti
- Episource
- HCC suspecting and coding platforms
HIE and document sources
- Regional HIEs
- scanned records
- Retrieval and abstraction vendors
Agent
Risk-adjustment & RADV audit-defence
- Reads the chart
- Proposes the change
- Holds for acceptance
Submission systems
- RAPS/EDPS submission tools
- Coding-workflow and audit-trail systems
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 submission
The layers sit inside one another. What none of them catches is listed in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a proposed change may stand
- L3
- Puts the release in a coder's hands
- L4 – L5
- Keep the diagnosis and the encounter behind it
- L6
- Narrows to chart retrieval when signals degrade
How Nestack evaluates it
Evaluate the review workflow — not only the final code.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the code the submission carries
- E1Final-output evaluationDid the proposed addition or deletion match what the chart actually supports?
- E2Step-level evaluationDid the agent use the right chart, support rules and model-year configuration?
- E3Tool evaluationDid it read and write the correct chart, member and diagnosis field?
- E4Confidence calibrationDo low-confidence changes actually draw more coder edits?
- E5Slice evaluationHow does performance change across specific chart types?
- E6Business outcomeHow many proposed changes needed a coder edit or a post-submission correction?
Floor — the outcome the plan answers for
Failure modes
Where each failure originates in the agent
Seven failure modes, mapped to the review stage where each one begins.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- RA-03
Excluded source accepted
A hospice note or unsigned transcription is read as if it were a visit.
Stage gathers
Chart, prior submissions and support rules
02 · Reasoning
2 modes
- RA-04
Leading provider query
A suggested diagnosis is embedded in the question sent to the treating provider.
- RA-06
Condition carried as current
A prior-year diagnosis is carried forward as though still being actively managed.
Stage proposes
Proposed change, the encounter and confidence
03 · Tool / write
2 modes
- RA-02
Unlogged accept on write
A proposed change reaches the file with no coder decision on record.
- RA-05
Identified deletion left open
An unsupported code is flagged, and nothing forces the correction to a deadline.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- RA-01
Excerpt not reconstructable
The chart excerpt behind a submitted code can't be produced on demand.
Stage returns
The code the coder accepts and the submission carries
05 · Change / Version
1 mode
- RA-07
Silent model-year drift
The HCC model updates for a new payment year without the review logic tracking it.
Stage tracks
Model, prompt, support rules and model-year configuration
- Sev-1 · writes outside the boundary
- Sev-2 · unsupported code is submitted
- Sev-3 · chart degrades, routes to review
Affected slices
A contract-level number hides where support fails
A contract-level support rate can look acceptable while one diagnosis source accounts for most of what an audit would strike. Nestack reports the rate by slice, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Conditions found only in a home assessment | 7.7% | 4.0× | Review | |
| Chronic conditions carried from a prior year | 5.3% | 2.8× | Review | |
| Acute conditions coded at discharge | 3.4% | 1.8× | Watch | |
| Conditions documented at a face-to-face visit | 1.9% | 0.8× | Normal |
Bar: unsupported-code rate lift vs. the face-to-face baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
The loop closes on the chart, not the score
A cycle is done when the unsupported code has become a case the next release must pass. That suite is what the next chart reviewed is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Unsupported-code rate rises in a contract slice.
- 02
Diagnose
The chart that supported nothing is traced to the source, the rule or the query that missed it.
- 03
Improve
Version-stamp the change and attach the charts that exposed it.
- 04
Verify
The affected cases run again, and a failure stops the release.
- 05
Learn
It becomes a standing test, and the review rules change with it.
Learn → Detect
The return edge. The next review runs against a suite one chart case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, review workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Chart-review workflow and boundary scope and boundary definition.Week 1
- 02EHR and chart-source assessment.Week 1, Week 2
- 03Provider and encounter-type rule mapping and rule mapping.Week 1, Week 2
- 04Chart ingestion and normalisation.Week 2
- 05Support retrieval and scoring logic.Week 2, Week 3
- 06Confidence scoring and flag routing.Week 3
- 07Coder acceptance workflow.Week 3, Week 4
- 08Chart-source and HIE integration.Week 5
- 09Support and deletion cases.Week 4, Week 5
- 10Guardrails and acceptance controls.Week 4
- 11Chart-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation 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 contract, one plan | ProductionProduction chart integration | AdvancedMultiple contracts / lines |
|---|---|---|---|
| Introduced at Pilot | |||
| Support recommendations, both ways | ✓ | ✓ | ✓ |
| Coder acceptance | ✓ | ✓ | ✓ |
| Support-accuracy baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by contract | — | ✓ | ✓ |
| Acceptance workflow in your systems | — | ✓ | ✓ |
| Approved submission write-back | — | ✓ | ✓ |
| Chart-source integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-contract support rules | — | — | ✓ |
| Multi-stage acceptance chains | — | — | ✓ |
| High chart volume | — | — | ✓ |
| Multi-contract review controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, transaction volume, 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.
You bring
We build with it
01Your EHR access, chart sources and submission history
→Chart ingestion and prior-submission mapping
Week 102Representative charts across contract cohorts
→Support baseline and encounter-citation extraction
Week 203Your acceptable-provider and encounter-type rules
→Provider and encounter-type rule mapping
Week 104Access to relevant APIs, feeds or exports
→Chart-source and HIE assessment, then integration setup
Week 205Codes you would not want submitted
→Deletion cases and the evaluation suite
Week 406What no diagnosis may rest on
→Confidence scoring, flag routing, guardrails and acceptance controls
Week 307Named certified coders to accept proposed changes
→Coder acceptance workflow, then pilot 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
The phases are drawn on the weeks they occupy, so week 5 genuinely doubles rather than padding the plan.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Review workflow discovery, support-rule mapping and boundary
W2Chart-source integration and the support baseline
W3Review logic, confidence scoring and acceptance controls
W4Evaluation suite, guardrails and failure-mode testing
W5Submission-system integration, pilot charts and corrections
W6One submission cycle reviewed under the coding lead, then Agent Care handover
- Reading the band
- A bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
- At the end of W6
- The final checks clear on a live submission and monitoring moves to Agent Care.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Healthcare AI agent
Build a risk-adjustment agent around your chart-review workflow.
Show us your chart sources, your support rules and who accepts a change. Not a score to raise. A record that holds up under audit.
- Typical delivery
- 4–6 weeks
- Deployment
- Your EHR and chart sources
- Coder sign-off
- Pre-submission
- After launch
- Agent Care available
Nestack Agents · Risk-adjustment & RADV
AGT-HC-13 · Agent Care available after launch