Insurance billing workflow, optimized against the treatment that was actually provided — not against the claim form somebody already typed. Findings are scoped to the date of service and every one of them cites the rule it came from.
The claim is the output. The record is the input.
A claim already passes through an editor in the billing software, an edit at the clearinghouse, and an edit at the payer. Adding a fourth check in the same vocabulary at the same point in the chain does not change an outcome. We started from that objection rather than around it.
Code requirements and diagnosis pairings are revised on a calendar cycle and apply to a range of service dates. Validate last year's claim against this year's rules and the finding is confidently wrong.
There is a nominal industry standard, and then there is what each carrier actually adjudicates against. The rules that decide whether you get paid are held by the payer, not by the code set.
By the time a code is on a form, the decision that caused the denial has already been made — in what was documented and how the code was derived from it. Validating the form checks the symptom.
Field-level completeness checks belong in the billing system, at the moment of data entry, and they are not an AI problem. We deliberately do not compete for that work. What we build is the part that requires reading: whether the documentation supports the code, whether the pairing is valid for that date of service, and whether a specific payer's own published policy says otherwise.
Stated by status, because the difference matters to anyone deciding whether to spend time on this.
| Capability | What it means | Status |
|---|---|---|
| Procedure-to-diagnosis consistency | Whether the codes on a claim support each other, at the service-line level, with pairing suggestions for codes that should be present and are not | Working |
| Denial risk with reasons | Severity-ranked findings against a retrieval corpus of authoritative coding and billing documents, each showing its source passage | Working |
| De-identification before inference | PHI is tokenized in the middle layer; the model never receives patient identity alongside the clinical detail. Access logged, MFA enforced | Working |
| Batch processing | Whole datasets processed unattended, so a backlog can be reviewed rather than a sample | Working |
| Claim-level dialogue | Ask a question about a specific claim and get an answer grounded in the same corpus | Built, in testing |
| Patient-level, multi-claim view | Analysis across a patient's claims rather than one at a time | Built, in testing |
| Service-date rule versioning | Rule sets versioned and retrieved as of the date of service, so historical claims are judged by the rules that governed them | In build — priority one |
| Payer-specific policy | Carrier-published policy as a distinct, attributable rule source separate from the general code set | In build |
| Documentation-to-code derivation | Starting from the chart note: is the code supported by what was written, and does the documentation carry the elements the payer requires? | In build |
| Denial-history feedback | Findings scored against what the payer actually did, so the system learns from real adjudication rather than from rules alone | Designed, not built |
Not a list of features. These are the only claims we think survive contact with someone who has spent twenty-five years inside billing operations.
Most tooling answers "is this code valid?" The correct question is "was this code valid on the date this service was performed?" Rule sets are versioned and retrieved by service date. Findings on historical claims are judged by historical rules.
Every flag shows the passage from the source document behind it. That is what makes a finding appealable rather than merely assertive — and it is what lets a reviewer who is not a certified coder act on it responsibly.
The same extraction layer that reads a claim reads the note behind it. That is the path to answering the question providers actually ask: can the visit be coded from the documentation, rather than checked after someone has coded it?
As a component, not a replacement. It sits alongside the billing platform and the clearinghouse rather than in place of either. Two insertion points are practical today: a pre-submission pass over a batch of charges, and a post-denial pass that reads the denial and the record together to identify what caused it. Neither requires an EHR integration — an export is enough, which matters because most billing operations do not have an API to the systems their clients use.
Revenue Integrity runs on its own corpus with its own access control. Nothing analyzed here is used for manufacturer reporting, and no clinical analysis in our other division is conditioned on reimbursement outcome. The two share an extraction layer and nothing more.