Rivinu

What I found, and what I need from you

Seventeen deep research passes on US dental claims — payer rules, clearinghouses, practice management systems, denial data, plan documents, and compliance. This is the condensed result, plus the five questions only you can answer. Dotted terms open a definition.

Prepared Sep 2026 Reports 17 Status Pre-build Read time ~15 min
5
Questions for you
60%+
Denials never reworked
<50%
Eligibility fields returned
2
Blocking diligence items
Action

Five questions for you

Each one changes what gets built. None can be answered by more research.

These are ordered by how much they change. The first two are the ones I'd want answered before writing product code.

Q1Workflow · who operates

Who actually works your claims day to day?

You, an insurance coordinator, an office manager, or an outsourced billing company? If it's more than one person, who owns which part. Research mapped the real workflow at roughly twenty steps and found the dentist is accountable for accuracy but almost always delegates execution — but a small practice can break that pattern, and yours might.

Unblocks who the interface is designed for. Building for the buyer instead of the operator produces software that demos well and never gets opened.
Q2New approach · feasibility

Could your patients produce their actual plan documents — and would you ask them to?

We think we can skip payer-rule guesswork entirely by reading the patient's own certificate of coverage or SPD, where the binding rules actually live. The law and the technology both check out. What nobody could verify is whether patients can hand over that document — current practice everywhere is to call the payer on the day. Two parts: could they, and would you accept the front-desk friction of asking?

Unblocks the highest-upside idea we have. Testing it costs nothing; building on it untested would risk the whole MVP.
Q3Baseline · measurement

What is your first-pass paid rate today, and can we get your historical remittances?

Of the claims you submit, how many are paid without rework? And separately — can we pull your historical remittances? No competitor can prove they improve this number, so proving it is our opening move. But without your starting number there's no zero point, and no way to show the product did anything.

Unblocks the first thing the product ships. Your baseline isn't a gap in our research — it's our first deliverable.
Q4Technical · integration

Which PMS do you run, and which payers make up most of your billing?

The PMS answer is close to binary. Open Dental is the only system with verified programmatic access to tooth-level history and treatment plans — and it publishes no fee at all: a practice simply switches API access on. What Open Dental leaves undisclosed is the commercial terms for a third-party billing product built on top, which is exactly the first blocker in Limits ↓. Dentrix sits at the other extreme: $5,000 for read plus $5,000 for write plus a monthly royalty — and it lists insurance claim processing as a protected category, which may exclude us outright. Your payer mix decides which rules we encode first: yours, not national market share.

Unblocks the build sequence. Open Dental means we start in weeks; anything else means a commercial negotiation first.
Q5History · prior version

What survived from the earlier version of Rivinu?

Specifically the Change Healthcare / Optum connection. Three things matter: whose name it was in — yours, the practice's, or the developer's — whether it's still active, and whether it predates the February 2024 incident. Anything else left over helps too: contracts, credentials, onboarding email, documentation.

Unblocks possibly months of onboarding. If the relationship is in your name it may still be live. If not, we route through a modern clearinghouse instead.
Method

The seventeen research reports

Every figure on this page traces back to one of these. R-numbers elsewhere point here.

Before designing anything, we commissioned seventeen deep-research passes — each a standalone report with cited sources, kept in the project repository. This is what each one set out to answer.

  • R0How a US dental practice actually gets paid, end to end — every step, who performs it, in which software, and where it breaks
  • R1Whether a library of payer rules exists to buy or license (it doesn't — the verdict was: build and curate our own)
  • R2Every clearinghouse's real onboarding posture toward a new small software vendor — who offers a test environment before a contract
  • R3What each practice-management system lets outside software read and write, verified against public documentation
  • R4The licensing around the claim file format (X12) and the procedure code set (CDT) — what may legally live in our code
  • R5How much benefit data payers actually return when asked electronically — versus what the standard allows them to return
  • R6Why dental claims get denied — ranked causes with codes, industry benchmark numbers, and how appeals actually work
  • R7Where each payer's processing policy actually lives, and whether monitoring it for changes can be automated
  • R8How X-rays, narratives and perio charts actually reach payers today — every rail an attachment can travel
  • R9The minimum compliance posture for a small vendor handling patient data, and which cloud and AI vendors sign the required contracts
  • R10The competitive landscape, mapped by where each product intervenes in the workflow — and what none of them can prove
  • R11Who buys dental software, what practices pay today, and what a one-point improvement in paid rate is worth
  • R12What a patient's insurance plan documents actually contain, rule type by rule type, and at what precision
  • R13The legality of collecting and machine-reading those documents — privacy, copyright, and who may demand them
  • R14Whether extracted rules can be cached per employer group and reused across patients and practices
  • R15Whether anyone already extracts benefit rules from plan documents (no dental vendor does), and how accurately AI reads contracts
  • R16Running AI over patient data without owning any hardware — which inference platforms sign the required contracts, at what cost
Premise

What we're building, stated as a number

The objective, the North Star, and the two metrics that keep each other honest.

The objective is not a feature list. It's a rate: maximize the percentage of claims paid on first submission.

“100% of claims accepted” is not reachable — some denials are correct, and a product that chases them would be lying. Zero preventable denials is reachable, and it's measurable. That's the North Star.

Two metrics, never summed into one

MetricDefinitionWhy it exists
First-pass paid rateOf claims submitted, the share paid without reworkPrimary. This is the number the product exists to move.
Billed-production guardThe total dollar value of procedures billed each period, watched right next to the paid rateThe brake. The fastest way to fake a better paid rate is to bill less — a system could hit 99% by telling you to skip every risky claim. If our recommendations ever push billing down, this number exposes it immediately.
Recovery rateOf denied claims, the share reversed on appealSecondary and subordinate. High recovery with falling first-pass means the product is getting worse.

An appeal you win is simultaneously a recovery success and a first-pass failure. That's correct, and it's why these can never collapse into a single figure — one number would hide bad prevention behind good recovery, and recovery is expensive.

MVP versus the finished product

  • MVP — helps a human operator hit the highest achievable rate.
  • Finished — fully agentic: files claims correctly by itself, no human for the ordinary case.
Domain

Where claims actually fail — and when it's still preventable

The eight failure modes, mapped to the earliest moment each can be stopped.

Your brief listed six failure modes. Research surfaced two more, and both are among the most predictable that exist.

Failure modeEarliest point it's preventableWhat must be known then
Frequency limitsBefore the appointment is bookedPatient's own history + the plan's window
Missing tooth clauseAt treatment planningTooth status before coverage start date
Prior authorizationAt treatment plan acceptanceThe plan's PA trigger list
BundlingAt coding, before claim buildCDT pair edits for that payer
Date-of-serviceAt procedure completionStart-vs-completion rule for that payer
DowncodingAt narrative and coding timeClinical criteria + narrative strength
Annual maximum addedBefore elective treatmentPlan year, maximum, paid and pending claims
Timely filing addedContinuously after serviceDeadline, transmission receipt, claim status

Read the middle column: most prevention has to happen before the claim exists. That kills “intercept the claim on its way out” as a sufficient design — by then it's too late for six of the eight.

Denial families, by share

FamilyEst. sharePreventable before submission?
Eligibility, coverage, member identity29%Usually
Missing or insufficient documentation22%Yes
CDT, frequency, procedure errors19%Yes
Coordination of benefits16%Usually
Timely filing14%Yes

Source: report R6 — the shares come from a single 2026 consulting model. No audited national dental census exists, so treat them as directional weights, not measurements. The two vendor compilations R6 reviewed rank the same families at the top.

One distinction that costs real money

A rejection never entered the payer's system — no appeal rights, because formally the claim never existed. A denial was adjudicated and refused — appealable, expensive to reverse. They don't even share a code vocabulary. The trap: on a rejection, the timely-filing clock keeps running. A rejected claim nobody reworks becomes a total loss, silently.

Strategy

The two findings that reshaped the plan

Why “works for every payer” is half true, and where the defensible opening is.

Finding one — coverage is asymmetric

The goal was a product that works for every payer and every clearinghouse. Cross-referencing all seventeen reports: that's impossible for rule-based prevention and achievable by design for lifecycle tracking.

Half of the productHow far it can reachWhat reaching costs
Lifecycle tracking
submission → acknowledgment → remittance, alert on silence, compare paid against billed
Universal by design. The same three messages exist for every payer in the countryBuilt once; no per-payer work after that
Rule-based prevention
block the claim before it goes out
~2 payers return frequency data specific enough to act onOne payer at a time, curated by hand

To be clear: neither half is built yet — this compares how far each can reach, not progress. Sources: R5 (ADA analysis of what payers return), R7 (Delta Dental's structure), R1 (no rule library exists to buy).

Why so few: the ADA measured that the 25 largest payers return under half of the recommended eligibility fields on average. Cigna doesn't accept procedure-code-level queries at all. And Delta Dental isn't one payer — it's 39 independent state companies whose policies don't transfer between them.

Finding two — nobody is measuring

Across the entire competitive landscape, not one product — not a page, not an independent review — establishes an audited improvement in first-pass paid rate. Everyone claims; nobody measures.

Report R10 — competitive landscape

Set that against two numbers: over 60% of denied dental claims are never resubmitted, and rework runs roughly $117 per claim. Money is being abandoned quietly and at scale, and no vendor can prove they reduce it.

Source: R6 — vendor-published figures. Never-resubmitted appears as “over 60%” and “65%” in two separate compilations; the rework cost as $117 in one and $25–118 in another. Directionally consistent across sources, but none is an audited study — which is itself part of the point above.

So the opening claim is: “Here is your real first-pass paid rate, by payer and by procedure, and here are the dollars you're currently walking away from.”

  • Computed from remittances alone — no rule library required
  • Works for every payer from day one
  • Produces the baseline that proves everything built afterwards
  • Nobody credibly occupies it

Which is why the sequence is measure first, then prevent. Prevention built before the baseline exists has no way to prove it worked.

Idea

Reading the patient's contract instead of guessing the payer's rules

New to this market. Legally clear. One untested assumption — see Q2.

Payer manuals are the weak source. The member's own plan document legally controls — Delta says coverage documents govern in conflict; UnitedHealthcare says the member-specific benefit document determines what is covered, excluded, and limited.

That also explains why no vendor sells a rule library: there isn't one corpus to sell. There are hundreds of thousands of employer contracts, each designed separately.

What the research settled

QuestionAnswer
Are the rules in the contract?9 of 14 rule types. Frequency, missing tooth, waiting periods, cost sharing, age limits, alternate benefit, exclusions, COB. Not attachments, bundling, or multi-visit date logic (R12)
At what precision?By service category, not by CDT code. Real certificates say “two cleanings per year,” not an edit table (R12)
Is collecting it legal?Conditional yes. Benefit verification is already a permitted use — no separate authorization ordinarily needed (R13)
Does copyright block it?No. Copyright protects the wording, not the underlying rule (R13)
Can it be demanded?Federal law obliges the plan to furnish it on written request, penalties up to $110/day — but that right belongs to the patient, not the practice. Courts have held assignment doesn't transfer it (R12, R13)
Does anyone already do this?No dental vendor. Document analysis exists in benefits consulting; nothing converts a certificate into claim-level rules (R15)
Can AI read it reliably?65–70% of valid points when a single model reads the whole contract alone (a published benchmark on legal contracts — and human + AI review beat either working alone). That number is exactly why no single model reads alone here: we split the document so each reader works one small section with the contract's own definitions at hand, a second AI hunts for what the first missed, and a third settles disagreements — a design built to push accuracy well past the solo number, and measured against a hand-annotated test set before it's trusted. Drawn in full below ↓ (R15)
Can patients produce it?unverified No evidence either way. This is Q2 ↑

The economics work because a plan is per employer group, not per patient. Extract once, apply to everyone on that plan — and roughly 90% of plans carry over unchanged year to year, with 83% of employer dental coverage sitting in large groups. One expensive read amortizes across many patients and many years.

Report R14, citing NADP — the National Association of Dental Plans

Caveat worth stating: the group number alone isn't sufficient as a key. Large employers split staff into benefit classes and divisions with genuinely different designs, so two people at the same company can have different rules.

How it stays honest

Every extracted rule cites the page it came from and carries an explicit confidence state. A missing field means unknown — never “covered,” never “eligible.” With payers returning under half their fields, treating silence as permission is precisely the failure this product exists to eliminate.

Then each rule becomes a prediction, and the next remittance confirms or refutes it. The measurement layer is what corrects the reading layer.

Limits

Constraints and the two open blockers

What the research fixed in place, what only a contract can answer — and what we do about each.

Two blockers — neither solvable by more research

ItemStatusWhat's at stakeWhat we do about it
Open Dental commercial licence
Does it permit a third-party RCM product? Royalty, revenue share, exclusivity, non-compete are undisclosed, not absent
blockingIt's the only PMS with verified access to tooth-level history. If the licence forbids us, most of the prevention surface is unreachableRead the licence agreement a practice accepts when switching the API on, then email Open Dental's developer team with our exact use case, in writing — before a single line of integration code
Dentrix eligibility
It names insurance claim processing a protected category, and bills even for read-only access
blockingIf the largest PMS excludes competing billing products, the initial market narrows to Open Dental practicesAsk Henry Schein's API programme in writing whether a third-party RCM product is eligible at all, and at what cost. Their answer sizes how much of the market has a front door

Fixed constraints

ConstraintConsequence — and the plan
Everything we touch is PHIWe operate as a business associate with direct legal liability, and every vendor in our chain — cloud, database, AI — signs the same contract down the line. No real patient data ever enters our code or test data: a leaked test file is a legally reportable event
Two licences stand between us and the wireSeparate things, easy to confuse. CDT is the ADA's dictionary of procedure codes: embedding it in software needs a signed ADA licence, so the codes stay out of our source until then — a diligence email, not a blocker. X12 is the format every US claim travels in; its standards body charges $1,200/year to develop against it. A small, known cost that every claims vendor in the country pays — and possibly avoidable at first, if we submit through a clearinghouse's modern API and never touch the raw format ourselves (to be confirmed in writing before we rely on it)
Rule identity is compoundPayer alone is never the key. It's payer + employer group + plan variant + effective date
Attachments ride a separate railX-rays and narratives aren't embedded in the claim — they travel as a separate transaction with a control number that must match. And no universal dataset says which procedure needs which document for which payer. The plan: deliver through the rails that already exist (NEA FastAttach, DentalXchange, or the clearinghouse's own attachment API), and fold “which document, for which procedure, for which payer” into the same curated rulebook as every other rule — helped by the timing below
Certification is a purchasing gate, not a legal oneSOC 2 Type II runs 3–12 months and $50–100k. No law requires it, and solo practices don't ask for it. DSOs do — their procurement demands the audit before signing. So: sell to practices now with a credible security posture, budget the audit for when the DSO pipeline opens

One piece of timing in our favour

In March 2026, CMS finalised a rule that picks one national standard for electronic claim attachments and gives every payer 24 months to comply (effective 26 May 2026). In plain terms: the messiest, most payer-specific corner of the entire workflow is being standardised during exactly the window in which we build. It doesn't make attachments universal on day one — payers will comply at different speeds, and prior-authorization paperwork was left out of the rule — but it means we build against one converging standard instead of thirty different portals, and we arrive as it lands rather than retrofitting after.

Design

How the system is shaped

Three layers, where the alerts surface, and what the AI is and isn't allowed to decide.

Three layers

LayerWhat it doesSource
Look upLive per-patient eligibility and benefitsBought — Vyne (Onederful), Zuub, or the clearinghouse's own API. Stedi publishes $0.08–0.30 per eligibility check and $0.08–0.20 per claim; most others price on contact. Cents per patient, not a cost driver
CurateVersioned, auditable rule graph with provenanceBuilt. This is the defensible part
LearnDenial risk from your own remittance historyDerived. Produces a risk score — never a rule

Where alerts appear

Prevention happens during treatment planning, which happens inside your PMS. A separate screen would be the easiest thing to build and the easiest to ignore. So, two tiers — and neither modifies the PMS's software:

  • Inside Open Dental: alerts arrive as notes and flags in the patient's chart itself, through the interface Open Dental publishes for exactly this purpose. Your coordinator sees them where they already work — nothing extra to open.
  • Everywhere else: a small companion window that floats above whatever screen is open — think picture-in-picture on a TV — always showing the alerts for the patient currently on screen. It reads what's displayed; it never touches the PMS itself, which is why it can work with any of them.

What AI does, and where it stops

The model writes the rulebook. The rulebook decides the claim.

AI reads contracts and drafts narratives. It does not decide whether your claim goes out. The test: ask “why was this claim held?” — the answer must be a rule and a citation, never “the model thought so.” Three reasons this matters, in order of weight:

  • Explainability. When a payer denies, we have to point at a rule, a page and an effective date. “The model judged it likely” isn't defensible when you've lost money following our advice.
  • Testability. A rule engine can be tested against known cases in an automated build. A model's judgement can't.
  • Silent drift. A rule engine changes when we change it. A model changes when its vendor updates it, with no warning.

The model's work isn't discarded — it's frozen into an inspectable artifact, reviewed once per plan, then applied identically thousands of times. The full pipeline is drawn in the next section ↓

Blueprint

How a contract becomes rules

The reading pipeline, the deterministic engine, and the loop that corrects both.

Three zones. AI reads — once per plan, not per patient. A deterministic engine decides — every claim, identically. And reality grades the whole thing — every payment that comes back.

How a contract becomes rules Pipeline in three zones: AI reads the plan document once — readers per section, a cross-reference sweep, an adversary and an arbiter, with one human look when unsure — producing a cited rulebook that a deterministic engine applies to every claim; each payment that comes back grades the rules. Zone 1 · AI reads — once per plan Zone 2 · The rulebook decides — every claim Zone 3 · Reality grades — every payment SECTION SPLIT OBSERVATIONS CONFLICTS ONLY IF UNSURE ANSWERED SETTLED RULES CLAIMS FEEDBACK The plan document collected once · covers the whole plan AI The readers one small slice each · pages cited Cross-reference sweep every “see Section 7” chased down AI The adversary hunts what the readers missed AI The arbiter settles only the conflicts One human look covers every patient on that plan The rulebook each rule: page cited + confidence state NO AI The rule engine same answer for every claim, every time The payer decides each payment grades the rules it tested LEGEND INPUT / OUTCOME THE ARTIFACT ONLY WHEN UNSURE FEEDBACK

The rulebook's five confidence states: confirmed available · confirmed blocked · rule known, patient history missing · no usable history · needs a human. A fact the document doesn't settle is stored as unknown — never as “covered.” And every extracted rule is a prediction: the feedback line is how the system finds its own reading mistakes, without anyone re-reading the contract.

Cost, for scale: the entire reading pipeline, at expected volume, prices between $340 and $1,200 per year in AI inference (R16). Accuracy decides its shape — cost doesn't have to.

Settled

What's already decided

The decisions on record, each with its reasoning.

DecisionReasoning
Objective is a rate, not a feature listEvery design choice gets argued against “does this move the number?”
North Star: zero preventable denials100% isn't reachable. This is, and it's measurable
Measurement first, prevention secondThe only half that's universal on day one, and it produces the baseline everything else is proved against
Appeals are in scopeMaximize the hit rate at every stage, not only the first. A denial left to die is as real a loss as one we caused
Reading each patient's insurance contract — the “plan-document route” — is phase twoIt's the highest-upside idea on this page, and it rests on one unverified assumption: that patients can actually produce the document (Q2 ↑). The test is free and takes a week — ask the next twenty patients at check-in and count. High yield → this becomes the product's core. Low yield → we request documents from the plan in the patient's name instead: legal, works, slower
Rules extracted by three roles, not three votesReaders working a fixed checklist with page citations, an adversary hunting what they missed, an arbiter only on conflicts. Identical voters agree on the same blind spot. Drawn in full above ↑
AI outside the claim decisionExplainability, testability, and protection against silent model drift
Layer over the PMS, never replace itNo practice changes its practice management system for a new tool
Coverage stated positively“Deep rules for these payers” rather than “only these.” Honest in behaviour without advertising the gap
Confidence is explicit, never a yes/noEvery coverage fact carries one of five states: confirmed available · confirmed blocked · rule known, patient history missing · no usable history · needs a human. A payer leaving a field blank means unknown — never “covered”

Full decision log, the seventeen reports with citations, and the domain glossary are in the project repository.