Projects · Case study

One platform for the whole revenue cycle.

A production revenue-cycle management platform for behavioural-health practices. A billing portal, a layer of AI automation agents, integrated calling and clearinghouse EDI — four separate problems, designed and built as a single application.

The workflow

How a claim moves through it.

From the eligibility check before the visit through to a denial decoded, fixed and resubmitted. Agents act at six of these stages. Each one checks its own work and escalates rather than assuming it got it right.

How a claim moves through the platformBefore the visit, eligibility and benefits are verified using 270 and 271 transactions. The encounter is then charged and coded with CPT and ICD-10, and submitted as an 837P claim through a clearinghouse to the payer, which scrubs and adjudicates it. A 277CA acknowledgment comes back as accepted or rejected. An 835 remittance is posted to the ledger. The bank deposit is then reconciled against that remittance, with every transaction on the statement matched back to a claim on the 835, so the money received and the money recorded have to agree. The outcome is paid, denied or underpaid. A denial is decoded from its adjustment codes into a guided fix and resubmitted as a corrected claim, returning to the submission stage. AI agents act at six of these stages — eligibility, coding, submission, acknowledgment, payment posting and denial remediation — and escalate to a person rather than trusting themselves.
The full cycle, and the loop that decides whether the money arrives. Everything left of the dashed boundary happens before the patient is seen.
Watch it work

The same cycle, one step at a time.

Four scenes from the operations console. Each one replays a real shape of work — a clean submission, a remittance that posts itself, a denial decoded and fixed, and an agent reasoning through a case until it reaches the part it will not decide alone.

Claim flow

Encounter through to a clean submission.

  1. done

    Encounter captured

    Jordan Rivera · 90837 · 2026-03-04

  2. suggesting

    Coding check

    Suggests: add modifier 95

    Modifier missing for telehealth place of service.

  3. needs you

    Suggested fix: add modifier 95

    Approved by a person
  4. applied

    Modifier 95 applied

  5. done

    Eligibility confirmed

    Northwind Health Plan · active · copay $20.00

  6. done

    Claim submitted

    837P · Northwind Health Plan

  7. done

    Acknowledged

    277CA · accepted

Clean claim out the door — one suggested fix, approved in place.

Illustrative — dummy data, timings compressed. Not a live feed.

Payment posting (ERA / 835)

A remittance posts itself and reconciles against the bank, except for the one line that does not add up.

  1. done

    Remittance received

    835 · Acme Benefit Systems · $1,240.00 · 12 claims

  2. checking

    Compute expected posting

    Charge 150, allowed 120, paid 96, patient responsibility 24. Underpaid? No — the contractual write-off explains the rest.

  3. applied

    Posted to ledger

    Sam Carter · paid $96.00 · adj $30.00 · PR $24.00

  4. done

    Reconciled against the bank statement

    deposit $1,240.00 ↔ 835 total · 12 of 12 transactions matched

    The deposit on the statement equals the remittance total, and every transaction on it ties back to a claim on the 835. Money received and money recorded agree.

  5. flagged

    Self-check: compute → apply → verify

    One claim: line paid $150.00 but claim paid $0.00. Inconsistent, so it does not get posted.

  6. needs you

    Needs you: a $0 claim carrying a line payment

    Sent to a person to review
  7. done

    Held for a person · the rest of the cheque posted

    11 of 12 auto-posted

Money posts itself; the one odd remittance is stopped and handed to a person.

Illustrative — dummy data, timings compressed. Not a live feed.

Denial management

A denial decoded into a short, ordered worklist.

  1. flagged

    Denial received

    Cobalt Mutual · CO-16 + N290 · $210.00

  2. done

    Decode reason

    CO-16 means the claim lacks information. N290 means the rendering provider NPI is missing. So: fix the rendering NPI, then resubmit.

  3. done

    Fix plan built

    1. Correct rendering NPI 2. Resubmit corrected claim

  4. suggesting

    Rendering NPI

    current: — → suggested: 1-XXXXXXXXX

  5. needs you

    Confirm the corrected NPI

    Approved by a person
  6. applied

    NPI corrected

  7. done

    Resubmitted

    corrected 837P · Cobalt Mutual

Every denial becomes a short, guided worklist — decoded, fixed, resubmitted.

The same step, a different code

Not every denial ends in a resubmission. The group code decides what the fix even is, which is why the plan is built per code rather than per template.

CO-16 + N290
Claim lacks information: rendering NPI missing. Correct the NPI and resubmit the same claim.
PR-27
Coverage had terminated when the service was given. No resubmission. Bill the secondary insurance, or bill the patient.
Illustrative — dummy data, timings compressed. Not a live feed.

How an agent solves a problem

The reasoning trace behind one of those fixes, including the part it refuses.

  1. checking

    Read the case

    Denied line, $180.00. The adjustment codes are at the claim level, not the line level.

  2. checking

    Consult the remediation playbook

    tool: knowledge base

    Looking up CO-16 with N290 in the playbook.

  3. suggesting

    Form a plan

    Deterministic plan: fix the rendering NPI, then resubmit. Confidence high.

  4. done

    Self-verify

    Compute the expected state, apply it, compare against what actually happened. Matches.

  5. needs you

    Escalate the part it cannot attribute

    The second line carries an adjustment I cannot attribute. Routing it to a person rather than guessing.

    Routed to a person

Compute, apply, verify. It proposes, checks its own work, and asks a person when it is not sure.

Illustrative — dummy data, timings compressed. Not a live feed.
The agents

The agents, and what each one does.

Narrow jobs, each with a defined input and a person who can override it. None of them makes a clinical decision, and none of them sends anything to a payer or a patient without a person approving it.

Eligibility and benefits agent

Verifies coverage and benefits before the visit through 270 and 271, and places a call when the payer will not answer electronically.

Coding verifier

Checks CPT and ICD-10 against the session before anything is submitted, and flags the ones likely to come back rejected.

Acknowledgment agent

Reads the 277CA and classifies it: accepted and on its way, or rejected and back in somebody's queue with the reason attached.

Payment agent

Posts the 835 to the ledger and self-checks — compute the expected result, apply it, verify against what actually happened, and escalate on a mismatch instead of trusting itself.

Denial remediation planner

Decodes the adjustment codes on a denial into a specific, ordered fix plan, rather than a queue item that says "denied".

Remediation runner

Carries out the fixes that are safe to automate and resubmits the corrected claim. Anything outside that set goes to a person.

What it is made of

One platform, four systems.

Each of these is a product in its own right. A practice could buy four vendors and spend the following year integrating them. The point of this one is that the four were designed together.

Billing and RCM portal

Practices, providers, patients, insurances and sessions. Claim creation and submission, acknowledgment tracking, remittance and payment posting with a ledger, secondary and coordination-of-benefits handling, and bank reconciliation. Every denial and rejection is decoded from its adjustment codes into a guided, step-by-step fix and resubmitted.

Integration point
The single surface: one operations console where every automated and human action happens, against a plain activity timeline.

AI automation agents

A service layer that verifies coding before submission, analyses denials and composes the fix plan, reads acknowledgments, and posts remittances. Each agent computes the expected result, applies it, then verifies against what actually happened.

Integration point
Runs against the portal's own data and writes back through the same rules a person would, so an agent cannot do anything a person could not.

Voice and VoIP calling

Calling inside the application for eligibility checks and denial follow-up — the parts of this work that still happen on the telephone because a payer will not answer any other way.

Integration point
What the call established is captured back into the claim it belongs to, rather than into somebody's notebook.

Clearinghouse and EDI integration

The X12 transactions the revenue cycle actually runs on: 837 for claims, 835 for remittance, 277CA for acknowledgment and 270/271 for eligibility, exchanged through a clearinghouse.

Integration point
The connective tissue. It is what turns the other three from separate tools into one cycle that closes.
Integration

What holds it together.

The hard part was never any one of the four. It was the seams. A claim submitted by the portal has to be recognisable when its acknowledgment comes back hours later, and again when the remittance arrives weeks after that, and again when a denial on it is worked and resubmitted. That identity has to survive every hop, including the ones through a clearinghouse that reformats things.

So there is one data model underneath, not four synchronised ones. The EDI layer reads and writes against it directly. The agents act on the same records a person sees, through the same permission rules. The calling system attaches its outcome to the claim rather than to a contact. And everything — every agent action, every human override, every file in and out — lands on one timeline in the operations console, so the answer to "what happened to this claim" is a single screen rather than four systems and a phone call.

Portal

  • PHP / Laravel API
  • React
  • TypeScript

Agents

  • Node.js service
  • LLM APIs
  • Evaluation harness

Telephony

  • VoIP stack
  • In-app calling

Exchange

  • X12 EDI
  • Clearinghouse
Capability

What it does.

  • Eligibility and benefits verification before the visit, electronically or by call
  • Charge capture and coding, checked before anything is submitted
  • Claim creation and submission, with acknowledgments tracked to a conclusion
  • Electronic remittance and payment posting against a ledger that has to balance
  • Secondary and coordination-of-benefits handling
  • Bank reconciliation, with the variances raised as work rather than buried
  • Denial and rejection remediation, decoded per adjustment code into a guided fix
  • One operations console, with an activity timeline covering every action taken
How it was built

Designed and built in-house, end to end.

We designed, architected, built and integrated all four systems: the web portal, the backend, the agent layer, the telephony, and the EDI exchange. Not assembled from vendors and glued together — built, by the firm, as one product.

That matters for a reason beyond pride. When a claim goes missing between the portal and the clearinghouse, there is no boundary to argue across and no third party to wait on. The people who wrote the submission code also wrote the parser that reads the acknowledgment, and can follow a single claim from the session that produced it to the payment that closed it.

Something in your revenue cycle shaped like this?

Describe what is not working today. If we are not the right firm for it, we will say so.

Start a conversation See how we work