Healthcare Technology

AI Claims Platform V2

Event-driven claims decisions you can audit—agents gather evidence, debate conflicts, and a gate stops unsupported denials.

Flagship 8 agents · none can deny

01The situation

In 60 seconds

Business problem

Payers and providers have to defend approve/deny decisions on appeal, in audit, and in disputes. The evidence sits across policy, clinical, coverage and admin systems, and one model score can’t show why a claim was denied.

Unacceptable failure

An automated denial with no positive evidence behind it.

Design move

Split who gathers evidence from who can decide. Agents inform, layered services evaluate, a gate in code blocks unsupported denials, and a human settles conflicts.

What it shows

Every outcome leaves a record of who decided, on what evidence, and how a conflict was resolved.

The problem

Claims teams make approve/deny calls that someone will challenge later. A weak decision costs money after the fact: an appeal, a provider dispute, or an auditor asking for the reason.

Who feels it

  • Payers adjudicating claims
  • Providers recovering denials
  • Compliance and audit reviewers
  • Platform operators running the pipeline

What’s at stake

  • Manual review bottlenecks on every claim that needs a second look.
  • Unsupported auto-denials and opaque scores that are hard to defend on appeal or in litigation.
  • Since January 2026, CMS-0057-F requires impacted payers to give a specific reason for each prior-authorization denial.

Constraints

  • Policy, clinical, coverage, coding and admin data live in separate systems.
  • PHI stays out of logs, and a local inference path is documented for PHI work.
  • Clinical judgment and admin rules stay in separate layers.
  • Every decision must be rebuildable from its record.

Failures this system must never produce

  1. F1

    An auto-deny without positive denial evidence

    Low confidence is a reason to escalate, never a reason to deny.

  2. F2

    A decision nobody can rebuild

    If you can’t say which policy clause or clinical note drove the outcome, you can’t defend it on appeal.

  3. F3

    One weak step deciding silently

    A thin retrieval or a bad score has to show up as a visible state, not flow downstream unnoticed.

02The approach

How AI solves it

Each failure gets one mechanism, and each mechanism has proof further down this page.

Failure Mechanism The model’s role Proof
F1
Mechanism

A verification gate in the claims coordinator checks every proposed denial: required checks complete, critical data present, model confidence at least 70%. If anything is missing, the claim goes to human review.

The model’s role

None. The gate is plain code that reads the model’s confidence; it never asks a model.

F2
Mechanism

Six specialists return cited evidence packets. ATE writes an append-only, hash-chained record for every decision.

The model’s role

Models retrieve and cite. A service writes the record, and corrections land as new rows.

F3
Mechanism

Evidence, medical evaluation, rules, debate and adjudication are separate event-driven layers. A real conflict opens a debate so it can’t be averaged away.

The model’s role

Medical evaluation is model-assisted. Business rules are deterministic and kept apart from clinical judgment.

Where the model works, and where it doesn’t

Model-assisted

  • Six specialist evidence agentsLLM + MedCPT retrieval over OpenSearch. Every passage cited.
  • Medical-necessity evaluationConfigured LLM at temperature 0 with a per-claim seed, kept apart from admin rules.
  • Debate arguments and moderationWeighted votes. Escalation is preferred when support is weak.

Rule-bound or human

  • Claim intakeParsers and schema validation run before any model call.
  • Coding and eligibility gatesDeterministic checks stop invalid cases before model evaluation.
  • Business rulesDeterministic rules service.
  • Denial verification gatePlain code: checks complete, critical data present, confidence at least 70%. Otherwise the claim goes to review.
  • ATE recordAppend-only and hash-chained. Corrections are new rows.
  • Human reviewTakes the final action on weak or conflicting cases.

V1 cascade

  • Intake → single pipeline step → next step → score → outcome.
  • A weak policy retrieve still advanced the case with a thin trail.
  • Hard to answer “which clause changed the denial?” after the fact.

V2 events

  • Coordinator emits claim events; specialist agents publish evidence packets.
  • Conflict opens a debate session; gate and human review are first-class states.
  • ATE (Accountability, Traceability, Explainability) appends who decided, on what evidence, and how conflict resolved.

Agents and who holds authority

Eight agents gather evidence and argue. None of them can approve or deny a claim. A gate in code and a human reviewer are the only places a denial can be stopped or settled.

Click any card for its contract: inputs, outputs, decision authority, and guardrails.

LLM model-assisted Code deterministic Human person in the loop
Informs

Evidence

Six parallel specialists. Each returns a cited fragment into the claim packet, then exits.

Evaluates

Evaluation

Two layers, kept apart so clinical judgment and admin rules never mix.

Escalates

Conflict

Runs only when the medical and business layers disagree.

Blocks · Decides

Authority

The only two places a denial can be stopped or settled.

Records

Record

Append-only provenance for every decision event.

Guardrails & trust

  • Layered decisions: clinical evaluation, administrative rules, and adjudication stay separate.
  • Denial verification gate blocks unsupported automated denials.
  • Human review on conflict or weak support.
  • Merkle-chained ATE rows — Accountability, Traceability, Explainability.

03See it work

See it run

A 30-second walkthrough of one synthetic claim, and a live demo you can run yourself. Both use synthetic data only.

Live demo · cloud

Coming soon

Run a synthetic claim yourself

  • Pick a sample claim and submit it
  • Watch six evidence agents fill the packet, with citations
  • Trigger a medical-vs-admin conflict and read the debate
  • See the gate block an unsupported deny
  • Open the ATE row for the decision
Open live demo · soon Book a walkthrough
  1. 0:00–0:06 Intake

    The claim lands on the journey board with status “evidence pending”.

  2. 0:06–0:14 Evidence

    Six agents fill the packet. One citation opens in place.

  3. 0:14–0:22 Conflict

    The medical and admin layers disagree. A debate opens and the moderator posts the vote.

  4. 0:22–0:30 Gate and audit

    The gate blocks the unsupported deny. The case goes to human review, and the ATE row shows why.

Interactive architecture

Walk a real request through agents, services, stores, and human gates. Click any node for its contract.

Proof on synthetic data

Three views of one synthetic knee-replacement claim (CPT 27447). No PHI.

From claim packet to evidence

Before

Synthetic claim excerpt

Illustrative · no PHI

CPT 27447 · R knee arthroplasty
Dx: M17.11 primary OA
LOS: 2 days inpatient
Prior auth on file: yes (partial)
Note snippet: “ambulatory with cane; failed PT × 8 wk; MRI shows bone-on-bone.”

After

Evidence packet (agent outputs)

Cited excerpts · synthetic

  • Policy Plan medical policy §4.2 — TKA medical necessity requires documented failed conservative care ≥6 wk. pol://demo/mp-tka-4.2
  • Clinical Guideline fragment: progressive OA with functional limit + imaging congruence supports elective TKA discussion. clin://demo/aaos-oa-frag
  • Learning Similar coded cases in learning store often escalate when prior-auth is partial and LOS coding is borderline. learn://demo/pattern-117

Illustrative synthetic contrast—no patient, claimant, or personal data shown.

04The result

What changes for the claims team

Reviewers see why a case escalated

Both evidence packets and the vote summary come attached to the case.

Fewer unsupported automated denials

The gate blocks any deny without verified checks and evidence (F1).

Audit detail for appeals

Who decided, on what, and how the conflict resolved (F2), within the limits disclosed below.

How I check it behaves

Run against a fixed set of synthetic claims with known expected paths. Development observations, not production KPIs.

Check What it counts Target Last run
Unsupported auto-denies F1 Denials issued without positive denial evidence 0 Run pending
Conflicts escalated F1 Medical-vs-business conflicts that reached human review All Run pending
Citation coverage F2 Evidence lines that carry a resolvable source ID Every line Run pending
Rebuildable decisions F2 ATE rows whose evidence IDs all resolve All Run pending
Debate on real conflict only F3 Debates opened when the layers actually disagreed All opened Run pending

05Looking back

Architecture decisions

  • Event-driven layers over a sequential cascade F3

    So one weak step can’t silently decide.

    Cost acceptedMore services to run. The compose stack declares 90+.

  • Agents supply evidence; authority stays in services and the gate F1

    So no model output alone can deny a claim.

    Cost acceptedMore cases land in human review while support is weak.

  • Debate only on genuine conflicts F3

    So a vote never manufactures consensus.

    Cost acceptedNeeds a dependable conflict signal between the medical and business layers.

  • Local, PHI-aware inference where configured

    So patient data stays inside the boundary.

    Cost acceptedModel choice is limited to what runs inside that boundary.

Known limits and next step

Gap · disclosed

On the measured path, retrieved passages are recorded but don’t yet reach the final medical-necessity prompt.

The evidence agents show their work in the audit trail, but on this path they don’t yet shape the medical evaluation. The denial gate still applies.

Next step

  1. Pass the evidence packet into the medical-necessity prompt with a citation-required output schema.
  2. Re-run the evaluation set and publish citation coverage before and after.
  3. Leave the denial gate unchanged, so the fix can’t loosen F1.

Also disclosed

  • Raw prompt and response text isn’t always kept for byte-level replay. Integrity relies on hashes and provenance instead.

Project demo