Denials Desk (2026)
A denials work queue for US medical billers, where an AI suggests the next step on each denied claim and the biller decides, with the evidence one click away.
Client
Self-initiated concept (Larkwell Medical Billing is fictional)
Role
Product designer, solo: PRD, design system, Figma, coded prototype, test plan
Timeline
5-day sprint
Platform
Desktop work queue · Claim workspace · Approvals
TL;DR
Denied claims are money a practice has earned but hasn't been paid, and each one hides a deadline and a paper trail. I designed a work queue and claim workspace where a scripted AI suggests the next step and the biller approves, edits or rejects it, with every suggestion traced to the exact field it used. The hardest case is built in on purpose: a timely-filing write-off that looks certain but ignores the payer's 277CA acceptance. Testing with US billers comes next.
“…adjust off the visit since I cannot show proof of timely filing without the transmitted claim report.”
A medical biller on the AAPC forum, 2014
The Challenge
What needed solving.
Denied claims are money a practice has earned but hasn't been paid. An MGMA study put the cost of reworking one at about $25, and found more than half are never reworked at all (Family Practice Management, 2015). To work one, a biller compares the money at risk with the time left, decodes a CARC code, and digs the proof out of claim history, remittances and payer portals.
Each step has a trap. The billed charge isn't the money at risk: DN-1001 billed $3,180.00 but has $1,420.00 at risk. A filing limit, a corrected-claim window and an appeal deadline are different clocks. And proof of timely filing means the payer accepted the claim, not just that the clearinghouse received it. A suggestion that misses one of these sounds right, and a wrong write-off gives the money up for good.
The business case. For a billing company like Larkwell, the queue decides what gets recovered. The goal is to work more denied money before its deadline, without wrong write-offs, and with every decision on record for the supervisor who signs off the large ones. In production I'd measure dollars recovered per biller, write-offs reversed later, how often billers override each evidence label, and claims that pass a deadline while sitting in the queue.
The Approach
How I solved it.
My PRD set one rule for every screen: the problem is not generating an AI answer, it is helping billers decide whether that answer deserves to be trusted. So I didn't try to make the AI more convincing. I designed every suggestion to be checkable: what it recommends, why, the exact field it relied on, and what it didn't check.
The biller stays in charge. Approve records a next step and submits nothing, Edit keeps the original on record, and Reject asks for a reason and an alternative, which can simply be "investigate".
Key Insights
What shaped the design.
01 · From the problem definition
A bigger claim isn't always the more urgent one
DN-1014 has $3,180 at risk and 16 days left. DN-1009 has $28,400 and 153 days. Either can be the right first pick.
What I did about it
No risk score. A single number would hide the trade-off and imply there's one right answer. The queue groups claims into deadline bands, then sorts by amount at risk within each band, and the biller can re-sort.
Every clock says what it is. Each deadline names its type and source, and assumed deadlines say so, so a corrected-claim window is never read as an appeal deadline.
Unknowns get their own place. Unverified and past deadlines have their own bands instead of sinking into "Standard", and urgency is written in words ("Due today", "3 days past"), not shown by colour alone.
02 · From the design
Checking has to be cheaper than skipping
If checking the evidence takes more effort than approving, billers will approve on trust.
What I did about it
Evidence sits beside the decision, down to the field. Each evidence chip opens the document on the exact field the suggestion used, highlighted. "Open source record" opens a synthetic original that names the real format it stands for: an X12 278 for an authorization, a 277CA for a payer acknowledgment, an 835 for a remittance.
Words, not percentages. The labels are Strong match, Likely and Needs your judgment, and each one says what it covers. A number like 87% would claim an accuracy that scripted suggestions don't have.
Approve isn't "done". The result reads "Ready for manual action. Nothing was submitted."
03 · The safety test
The dangerous suggestion looks exactly like a good one
DN-1007's write-off says Strong match and lists nothing missing. It's wrong: the payer accepted the original claim on 03/21, inside the 06/07 filing limit.
What I did about it
Acceptance, not receipt. The 277CA reads "Accepted by payer (not clearinghouse receipt)", because only the payer's acceptance proves timely filing, and payers differ on what proof they take.
No warning, on purpose. Real errors don't announce themselves. If I had flagged DN-1007, the test would measure the flag, not the biller.
Uncited documents are one click away. The 277CA is marked "Not cited by the suggestion", so the biller can see where the AI's view stopped.
Rejecting never forces a guess. The biller has to give a reason ("Contradictory evidence" is its own option) and a next step, and "Investigate" counts as one.
The approval gate can't rescue it. Write-offs above a provisional $2,500 need a second person, but DN-1007 sits below that line on purpose, so the test depends on the biller alone.
Process
How I worked through it.
01
A PRD grounded in the rules
CARC 197, 50 and 29 read against the X12 code list, Medicare's 120-day redetermination window from CMS, and three scenarios (right, uncertain, wrong) with a 4 of 5 detection target.
02
A design system first
Built new for this project: a three-tier token system kept in sync between Figma and code, 39 components and 17 product patterns, including the AI suggestion, the evidence document, the override dialog and the audit entry. Only the sidebar and stat tiles follow patterns from my Payment Resolution console.
03
7 flows, 32 screens
Queue, claim review, rejecting a wrong suggestion, editing, failures, write-off approval and source records, designed at 1512 × 982 with a product log for each flow.
04
Built, then checked like a reviewer
A coded prototype with 14 synthetic claims. Reviewing my own screens, I found a write-off justification that contradicted DN-1009's data, and rebuilt that scenario before it could confuse a tester. axe-core reports 0 accessibility issues on every prototype page.
Selected Screens
A closer look.
Outcomes
How I'd know it works.
Target 4 of 5
billers reject the DN-1007 write-off because of the 277CA, not general distrust
Target <90 s
median time from opening DN-1007 to recording the override
Target 4 of 5
billers notice the unchecked payer policy on DN-1004
Not tested yet. The plan: moderated remote sessions with five US medical billers on the coded prototype, with synthetic claims and scripted suggestions. Billers are told the suggestions are scripted, not that one is wrong, and a rejection only counts if they name the evidence.
The path I designed for (a walkthrough, not research)
A careful biller. DN-1007 is a timely-filing write-off marked Strong match. Timely-filing denials can be overturned with proof of filing, so a careful biller opens Submission history: the cited corrected claim from 07/02, and above it a payer acceptance on 03/21. Next document opens the 277CA, accepted by the payer, inside the 06/07 limit. They reject with Contradictory evidence and choose an appeal.
The risk I designed against
A rushed biller. They see Strong match on a denial type that is often legitimate, and approve. That is automation bias, and it is why uncited documents stay one click away, why each one says what the suggestion didn't use, and why Approve says nothing was submitted.
The honest limits. No billers have used it yet. The walkthrough shows the path the design supports, written by me; only testing shows whether real billers take it, and the results will replace this section. The suggestions are scripted, so testing will measure the interaction model, not AI accuracy.
Reflection
What I'd do differently.
I'd talk to billers before designing the queue. The prioritisation rule, the deadline bands and the write-off threshold all came from my PRD. They should have come from billers, which is why testing with them is the next step.
I'd also watch whether billers check the 277CA unprompted. If they don't, the scenario is too hard, and the fix belongs in the payer message, not a warning in the UI.
Now you know.
A queue nobody trusts? A status that sends people to support?
That's the work I do, and I'm open to new projects. Tell me what you're building, and I'll tell you honestly if I'm right for it.
Next Project
Payment Resolution (2026)
Designed one resolution case for stuck payments in Nigeria and India. In testing, 8 of 10 customers knew to wait instead of paying twice.