RXNT · Billing · Practice Management · 2026
A Held Claim Is Useless If Nobody Knows Why It's Held
A rules engine that lets practices catch billing mistakes before payers do, and tells billers exactly what to fix.
ROLE
Sole Product Designer
TEAM
Me · 1 PM · 2 Engineers
TIMELINE
Nov 2025 - Apr 2026
USERS
Practice Admins who write the rules · Billers who fix the flagged claims
OVERVIEW
Practices kept getting claims denied for mistakes a rule could have caught: a missing modifier, a code a payer won't accept, a payer-specific quirk. RXNT had rules, but they were buried inside each payer's setup and could only target one payer at a time. I designed a rules engine that puts every rule in one place, reads like a sentence, and makes every flagged claim explain itself.
OUTCOMES
THE PROBLEM
Claims Were Getting Stopped. Nobody Could Say Why.
Payers deny claims over details: a missing modifier, an incompatible code pair, a formatting rule one payer cares about and another doesn't. Practices were catching these after submission, when a fix means a delay and rework.
RXNT already had payer rules. They just lived at the bottom of Practice Setup → Insurance Companies → [one payer], one payer at a time, with no way to write a rule across payers.
And when a claim did get held, billers couldn't see which rule caused it. Every flag turned into a dig through raw claim logs.
The ask came straight from clients: more customization, more automation. Support tickets told the other half of the story: customers couldn’t tell why their claims were getting flagged in the first place.
Four clicks deep, one payer at a time
THE INSIGHT
Billers Didn't Need More Rules. They Needed Every Flag to Explain Itself.
The obvious ask was "let us write more rules." But a rule that holds a claim without saying why just moves the investigation somewhere else.
A rule is only as good as the time it saves. If the biller can't tell what to fix, the rule hasn't saved anyone any time.
WHAT I DESIGNED
Rules Anyone on the Team Can Read, Write and Trust.
Four decisions shaped the solution.
1. One home for every rule, with the existing ones in view.
Why → Rules moved out of individual payer setup and into Utilities, admin-only. The builder sits directly above the saved rules, so admins check what already exists while they write, which is the cheapest way to avoid duplicate or conflicting logic. Legacy payer rules stay visible as read-only references that link to the new engine, so nothing disappears on anyone.
Write the new rule with every existing rule in view.
2. Logic you can read back in plain English.
Why → IF/THEN rules with AND between parameters and OR inside a multi-select are powerful and easy to get wrong. So every rule writes itself out as a sentence while you build it ("If claims have Payer (Aetna) and Charge Amount (Less than $50), then flag…"). Picked parameters drop out of the next dropdown, a rule needs at least two, and an info icon explains that rules check the whole claim. The team considered cutting the preview from the saved-rules grid over performance concerns; we kept it, visible in a tooltip on hover, because the preview is how admins audit rules without opening each one.
If the sentence reads wrong, the rule is wrong, and you find out before it touches a claim.
3. Every flag explains itself.
Why → A Correction Reason is required to save a rule, and it shows as a tooltip right on the flagged claim in the Corrections Required tab. The biller sees "why" in the same place they fix it. No logs.
Written once by an admin. Read every time a biller hits the flag.
4. Safe to change, hard to break.
Why → These rules sit in front of a practice's revenue, so editing them can't feel risky. Active/inactive works as a pause button. Deletes are soft and recoverable. A lightweight history shows who changed what and when. A blocker stops exact duplicates on save. Rules that reference something later deactivated (like a payer) keep working instead of breaking. Validation runs on save, not on blur, so the form doesn't jump around while someone's mid-thought.
Nothing an admin does here is permanent by accident.
WHAT I’M WATCHING
Success Signals.
After the beta release, we will track these metrics to validate our solution.
Denials on claims that match a custom rule: should drop, since those mistakes now get caught first.
Time from flag to resubmission: should shrink, because the reason is on the claim.
Rules created per practice: rules created = adoption, and shows whether admins trust it.
Support tickets about held claims: fewer questions re "why is this claim stuck?".
WHAT I LEFT OUT, ON PURPOSE
A Smaller MVP That Actually Shipped.
Full history UI: deferred. Full version history records in the background; the MVP shows a lightweight event summary so the core scrubbing integration could ship and be tested sooner.
Reporting: cut from MVP. The reports module wasn't ready, and rules were useful without it.
Alerts for newly deactivated values: moved to a later sprint. Existing rules keep their saved values in the meantime.
User-specific views under Utilities: dropped. Nice idea, no clear need yet.
Line-item rules and automatic fixes: saved for Phase 2 (below).
Each cut kept the first release focused on one job: catch the claim, explain the fix.
THE IMPACT
Fewer Surprises. Faster Fixes.
Rules only matter if they change what happens after a claim leaves the building. Within 90 days of beta, practices using custom rules were catching mistakes before payers did, and billers were fixing flagged claims without digging through logs.
The ticket number is the one I care about most. Clients asked for automation; support tickets asked for an explanation. This number shows whether we delivered the second one.
WHAT’S NEXT
The Questions Phase 2 Is Already Asking.
When should the system fix a claim instead of flagging it?
Phase 2 lets rules act: swap a code, add a missing modifier. Automatic fixes save time, but a silent change to a claim is a trust problem. Where's the line, and how does the biller see what changed?
Claim-level or line-level?
Iteration 1 checks the whole claim (e.g. total charge, not one line). Line-item rules are more precise and much harder to explain in one sentence. Can the preview keep up?