How a Matter Runs

From intake through a signed, gated release — how a per-submitted-code documentation review moves through one matter.

Where your charts go, and who touches them

Six stages across three hands. What you send us, what we do with it, and what comes back signed.

  1. Your firmYou hold the matter and the privilege.

    1. Intake

      You send the chart set and the claims manifest. We are retained as your subcontractor under your engagement, in a consulting-expert lane. We do not testify, and the engagement letter scopes testimony out.

    Crossing to us: charts, and the codes actually submitted

  2. Us, under your engagementConsulting expert. Non-testifying. Your privilege, not ours.

    1. Chart setup

      Charts arrive as PDFs in whatever layout your EHR or vendor produces. Layouts vary, so we build a reading template for your format before any code review starts.

    2. Our software reads every submitted diagnosis in scope against its note

      Our software reads every submitted code that carries risk-adjustment weight against the encounter it was billed from and, where the note has one, pulls the exact line that supports it, or undercuts it, verbatim. It paraphrases nothing, and it will not use a quote that fails a word-for-word recheck. Codes with no payment category are listed as out of scope and are not reviewed. Every code in scope then goes to a person with the software's read and the note evidence it found, including every code the software reads as supported.

    3. Review and signature

      A person, not the software, reviews every code against the note and signs the findings. Your engagement letter names who that is. The software decides nothing and signs nothing. Where the reviewer disagrees with the software's read, in either direction, the disagreement is recorded.

    4. Gated release

      By default, nothing leaves until the reviewer's sign-off is recorded, every submitted code is accounted for, and the rendered package passes its checks. A failed check stops the release unless a named person waives it and the reason is recorded on the run; a waiver is never silent.

    Crossing back to you: a signed work product, with no dollar column

  3. Your firmThe deliverable is a signed work product you own.

    1. Delivery and invoice

      The signed findings come back to you under your engagement. Every supported or not-supported read cites the line in the note it rests on; a code sent for review says why it was sent. On a first matter your own Kovel-retained coder countersigns. The fee was set at intake and does not move with what the review found.

Two AI Models Read Every Code in Scope, Separately. Neither One Decides.

Two different AI models each read the note for every code in scope, separately, and answer the same questions, quoting the note for every yes. 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. One more automated check then looks again at each code read as supported or not supported. It can send a code to review, never the other way. It runs on the same model as the second reading, so it is an internal check, not an independent one. Whatever the read, what comes out is a queue for the reviewer to work, not a verdict.

  • Reads every chart and sends every code that carries risk-adjustment weight to the reviewer, with the software's read and the note evidence it found
  • Judges from the whole sentence, 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
  • Never issues or signs a finding; that judgment belongs to a person, not the software
  • The final automated check can only send a code to review, never toward supported — an internal check on the same model as the second reading, not an independent one
  • Every rule the models follow is written down and applied the same way on every chart, so the logic stays open to review, not left to guesswork
  • Where a chart is thin or a read is uncertain, the code routes to review; uncertainty never resolves in the client's favor. 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

The deliverable rests on a person's judgment: a person, not the software, reviews every code and signs the findings, and your engagement letter names who that is. Our coding lead approves the clinical criteria the software applies before any version of them is used on a matter. She holds no coding certification today, and the FAQ says what that means for your engagement. The software assembles evidence and a first-pass read; it does not adjudicate, and it does not extrapolate from a sample.

Want the mechanics behind the two models? See how the review works.

Request a Call

The Agreement Record

Every matter produces a record of where the reviewer's read agreed with the software's read, and where it didn't. We report the disagreement in two directions — and we never blend them into one number.

Over-Referral

A code the software held back for review that the reviewer found supported. This costs review time — the reviewer's hours are the real cost of the review — but it is not the direction that can hurt your client.

False Clear

A code the software read as supported that the reviewer did not. This is the direction we build against hardest: the fail-safe is inverted, so uncertainty is designed to route to a person, never past one.

We record both directions on every matter and report them to you separately — never averaged into a single figure. Neither direction has a published rate: that number does not yet exist, and we will not publish one we have not measured.