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.
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
AgentHuman
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.
5DecisionBranches at the confidence threshold
High confidence
Goes to a certified coder to accept.
Low confidence
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 required8 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 boundaryAgent 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 diagnosisIllustrative example
Member
Proposed change
HCC category
Encounter source
Confidence
Support status
Chronic-condition chart review
Diabetes with chronic complications, confirmed at a face-to-face visit
HCC 18
Endocrinology office visit
91%
Face-to-face encounter confirmed
As receivedTaken from the retrieved chart and the encounter it cites — nothing on this side is inferred by the agent.
Chart evidence usedOffice-visit progress noteSigned by the providerPrior-year submission
Why this reads as supportedThe note ties the diagnosis to today's visit and a credentialed provider.
ActionAcceptEditSend for clinical review
What the score decidesBelow the configured threshold the change picks up a clinical-validation read.
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 diagnosis on fileFrom the chart and the submission file
03Chart review
Read for both directions
Weigh what's already submitted against what the chart newly supports, and what it no longer does.
01Approved path
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.
02Human review
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.
04Build 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 systemsEpic · Cerner · Allscripts MEDITECH · HL7/FHIR chart feeds
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 aggregateIllustrative 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 threshold2 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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Unsupported-code rate rises in a contract slice.
02Diagnose
The chart that supported nothing is traced to the source, the rule or the query that missed it.
03Improve
Version-stamp the change and attach the charts that exposed it.
04Verify
The affected cases run again, and a failure stops the release.
05Learn
It becomes a standing test, and the review rules change with it.
Learn → DetectThe 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.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Chart-review workflow and boundary scope and boundary definition.
02EHR and chart-source assessment.
03Provider and encounter-type rule mapping and rule mapping.
04Chart ingestion and normalisation.
05Support retrieval and scoring logic.
06Confidence scoring and flag routing.
07Coder acceptance workflow.
08Chart-source and HIE integration.
09Support and deletion cases.
10Guardrails and acceptance controls.
11Chart-trail instrumentation.
12Deployment, documentation 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 contract, one planProductionProduction chart integrationAdvancedMultiple 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 priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval 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
01Your EHR access, chart sources and submission history→Chart ingestion and prior-submission mappingWeek 1
02Representative charts across contract cohorts→Support baseline and encounter-citation extractionWeek 2
03Your acceptable-provider and encounter-type rules→Provider and encounter-type rule mappingWeek 1
04Access to relevant APIs, feeds or exports→Chart-source and HIE assessment, then integration setupWeek 2
05Codes you would not want submitted→Deletion cases and the evaluation suiteWeek 4
06What no diagnosis may rest on→Confidence scoring, flag routing, guardrails and acceptance controlsWeek 3
07Named certified coders to accept proposed changes→Coder acceptance workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, 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.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Review workflow discovery, support-rule mapping and boundaryW2Chart-source integration and the support baselineW3Review logic, confidence scoring and acceptance controlsW4Evaluation suite, guardrails and failure-mode testingW5Submission-system integration, pilot charts and correctionsW6One submission cycle reviewed under the coding lead, then Agent Care handover
Reading the bandA bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
At the end of W6The final checks clear on a live submission and monitoring moves to Agent Care.
DurationSix-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.
