Methodology & Limits

One code, one question

The review never produces a whole-chart score. It asks one question, separately, for every submitted diagnosis code that carries risk-adjustment weight. Codes with no payment category are listed as out of scope and are not reviewed.

When a firm sends us a chart set for a RADV (Risk Adjustment Data Validation) audit or a risk-adjustment False Claims Act matter, the question is the same for each submitted code: does this encounter's documentation support it, on its own terms? A chart carrying ten submitted codes produces ten separate answers, never one grade for the chart. A well-documented code next to it says nothing about whether this one holds up.

Every finding traces back to one submitted code and the note it came from — never inferred sideways from a different code, a different encounter, or a different chart. A person, not the software, signs whatever goes out.

Our software

Reads every submitted code that carries risk-adjustment weight against the note it was billed from.
Pulls the verbatim line the code rests on, where the note has one.

History of malignant neoplasm of the right breast, status post mastectomy in 2019, no evidence of recurrence.
Gives the code a read: supported, not supported, or needs review. It decides nothing and signs nothing.

In scope

A person

The code reaches the reviewer with the software's read and the note evidence it found, whatever the read, including supported.

The reviewer works it against the note and decides whether a finding issues.

The reviewer signs the finding.

Out of scope

Listed, not reviewed

The code carries no payment category, so it is listed as out of scope and no finding is made on it.

The absence of a finding is not a finding. This instrument does not clear codes. Codes it did not surface have not been adjudicated and are not represented as supported.

Illustrative, with a synthetic note line. This shows the path of one submitted code. It does not show how many codes take each branch.

What has to be true for a code to be read as supported

For each code, the software reads it as supported only if every one of the following holds. Anything less sends the code to a person as needing review.

Present, at this visit, for this patient. Both readings find the condition present at this visit and about this patient.
Addressed and managed. Both readings find it addressed in the assessment and plan, and managed at this visit.
Quoted, word for word. The quotations behind those answers pass a word-for-word recheck against the note.
Same payment category. Any code the readings list as documented falls in the same payment category (HCC) as the submitted code.
Nothing marks it otherwise. Neither reading finds anything in the note that marks it as resolved, historical, ruled out or someone else's.

Whether the note is signed, and the date of service and provider, are chart-level checks that flag to the reviewer what they find (the date check runs once an engagement supplies its audit period); they do not by themselves change a code's read. A supported read is the software's suggestion, not a finding, and every code that carries risk-adjustment weight goes to a person whatever its read.

The software can read a code as supported only for a listed set of codes in three condition groups: COPD and related chronic lung disease, morbid obesity, and Alzheimer's disease. For every other code its best read is "needs review," so the reviewer decides it from the note evidence.

Two AI models, two separate readings

Nothing about this review runs on one model call. Two different AI models each read the note for every code in scope, separately, and answer the same questions.

Both models read. Each reads the whole note and answers the same questions about the code's condition — is it present at this visit, is it about this patient, is it addressed in the assessment and plan, and how is it managed — quoting the note for every yes. The second is told to read skeptically, and to look through the whole chart for anything that says the condition is absent, ruled out, resolved, historical or someone else's.

Neither model decides. Fixed rules, written down and applied the same way on every chart, read a code as supported only when both readings agree and every check passes; any disagreement or doubt sends the code to review. What the check after them is permitted to do is covered below.

Neither model is hardcoded to a diagnosis code. The questions the models are asked, the lists of codes and section names, and the result wording live in one versioned configuration file, approved by named people before it is used; the fixed checks are the engine's own code, and the deliverable states the version of each. There's no per-code special case buried in application code for either model to fall back on.

The words that decide it

Most of what separates a supported diagnosis from one at risk isn't a missing fact — it's how the note says it, and each reading judges that from the whole sentence.

Each reading judges, from the whole sentence and not from single words, whether the condition is present at this visit or is ruled out, resolved, historical, a family history or someone else's. If either reading is unsure, the code goes to review.

The evidence behind every supported or not-supported read is a verbatim quotation from the note — never a paraphrase, never a synonym standing in for the actual words, never a summary written after the fact. It has to survive being checked, word for word, against the source document it came from. A code sent for review says why it was sent.

Built to fail toward review

The two mistakes this kind of review can make are not equal, and the design does not treat them as equal.

Detected uncertainty resolves to review, not to a favorable read

Missing something is a bad outcome. Telling counsel a code is fine when it isn't is a worse one. So the review leans one direction on purpose: an unreadable section, an unclear answer from either reading, a payment-category mismatch, a quotation that fails its word-for-word recheck — any one of those sends the code to review, and none of them is ever read as a pass. The software can still misread a code as supported without detecting any doubt, so every code it reads as supported also goes to a person before anything is released.

The final check can only send a code to review, never the other way

Before a person sees the queue, one more automated check looks again at each code read as supported or not supported, against its quoted evidence. It can send a code to review; it is never permitted to move a code toward supported. It runs on the same model as the second reading, so it is an internal check, not an independent one.

Two kinds of error, reported separately

A review like this can be wrong in two different directions: holding back a code for review that the reviewer finds supported, or reading a code as supported that the reviewer does not. Those are different problems with different costs, and the methodology keeps them as two separate figures — never blended into one number that would flatter whichever direction happened to look better.

Every code in scope reaches a person, including the ones read as supported

Every code that carries risk-adjustment weight goes to a person before anything is released, including every code the software reads as supported. The software's read and the note evidence it found come with it. Codes with no payment category are listed as out of scope and are not reviewed.

A failed check stops the release unless a named person waives it

Before anything reaches a firm, an engagement's output runs through a series of automated checks. The blocking checks work in one direction: they can stop a package from going out. Others report on the release record without blocking. A failed blocking check stops the release unless a named person waives it and the reason is recorded on the run; a waiver is never silent.

Where your records go

We keep two separate bodies of charts and they never mix.

The first is synthetic. Every chart in it is fabricated and contains no real patient information. All of our development and testing runs against it, and it stays permanent and versioned, so the method can be examined without anyone's records being involved.

The second is your matter's records. They are processed on our own equipment for that matter, except that the note text is sent to our AI vendor to be read. They never enter the synthetic corpus. We never use them to train or tune any model; what the AI vendor may do with what it receives is governed by its terms and, for real records, the business associate agreement. They are destroyed on your instruction and on your schedule.

No real record is processed until business associate agreements covering every processor in the chain are in place. Part of that is enforced in the software: once real records are declared, it refuses to send them to an AI vendor that has no agreement on file.

SOC 2 Type II is not in hand. Your vendor-risk review will take as long as it takes, and we plan that lead time into the pilot.

What we will not sign

If a matter needs a statistical sample and an extrapolation from it — projecting a finding across claims nobody actually reviewed — that opinion belongs to a statistician, not to us, and we say so up front. The reviewer's signature covers what was actually reviewed, one submitted code at a time. It does not stand in for a sampling methodology that neither the reviewer nor the software is positioned to offer. Our coding lead, who approves the clinical criteria the software applies, holds no coding certification today, and the FAQ says what that means for your engagement.