Case studyHealthcare enterpriseWorkflow design
From paper checks to digital payments.
Designing a claims payment and reconciliation system for an enterprise healthcare platform — batch processing, real-time status tracking, and full audit trails integrated with Zelis for ACH and check disbursement.
Challenge
A manual, paper-based claims payment workflow with no real-time visibility, limited audit trails, and growing compliance risk.
My role
Senior Product Designer. Led design end-to-end — workflow mapping, batch processing UI, status tracking, and the Zelis integration surface — alongside engineering.
Outcome
A digital payment workflow with batch processing, real-time status, and complete audit trails — built for the people who answer to auditors.
Context
The last mile of the claims process.
In healthcare claims, the part most people think about is the adjudication — the decision about whether a claim is approved. But adjudication is just a ruling on paper. The money still has to move.
That's what this module does. It sits at the end of the claims pipeline and handles the disbursement — generating payments, getting them approved, sending them to providers, tracking whether they landed, and reconciling the books. When it works, nobody notices. When it breaks, providers don't get paid and finance teams spend days fixing it manually.
The problem
Four ways the existing workflow was costing the business.
The existing payment process had been built incrementally over years. Each piece worked in isolation. Together, they produced real operational drag:
- Paper processing. Claims managers generated checks manually, one at a time. No batch processing, no scheduling.
- Zero visibility. Once a payment left the system, it was a black hole. Settlement failures showed up days or weeks later — sometimes from a provider calling to ask where their money was.
- Compliance risk. Limited audit trails for approvals, no configurable controls for payment thresholds, and no clear way to track combined or reversed payments.
- Operational cost. Finance teams spent hours per week on manual reconciliation. Duplicate payments and errors sometimes went undetected. Provider relationships strained.
The organization needed to digitize the workflow and integrate with a payment partner (Zelis) for ACH transfers and automated check processing. Both, at once.
The workflow
Before a payment could be redesigned, it had to be re-drawn.
I spent the first weeks mapping what the workflow actually looked like — not what the docs said, but what claims managers and finance staff were really doing. Paper mapping, interviews, screen-sharing sessions. Then I drew what it should look like, step by step, and used that as the contract for every design decision after.
Paper-based, serial, invisible.
- Manager pulls approved claims list from system
- Generates a physical check for each one, individually
- Checks mailed out, logged offline
- Weeks later, bank statements arrive
- Finance team manually matches statements to claims
- Discrepancies investigated by hand
Digital, batched, trackable.
- Manager selects approved claims into a batch
- System generates payment instructions for Zelis
- Configurable approval thresholds trigger the right sign-offs
- Zelis dispatches via ACH or check per provider preference
- Real-time status returned to the platform
- Reconciliation auto-matches; exceptions surface for review
Approach
Three decisions that shaped the design.
Make status the spine of the interface.
In a paper workflow, status is a feeling — “I think that went out last week.” In a digital workflow, status should be a fact. I made payment status the primary organizing element of every screen.
Every payment carries its current state visibly — Pending approval · Approved · Dispatched · Settled · Reconciled · Failed — with timestamps and the last actor. Users never have to guess where a payment is in the pipeline. Auditors never have to reconstruct a sequence.
Batch first, exceptions second.
Most payments are routine. A small percentage are exceptions — combined payments, reversals, flagged compliance items, provider preference changes. The old workflow treated every payment as a one-off, which meant routine payments drowned in the same friction as exceptions.
The new design prioritizes batch processing as the default path, with exception handling as a dedicated, deliberate flow. Most of a manager's day is now fast. The minority of payments that genuinely need attention get it — with the right controls and audit trail.
Audit trail by construction, not by report.
The easiest way to ship an audit trail is to build a report generator. That works for auditors, but it doesn't help the operator. Worse, it means audit data lives in a separate place from the workflow — truth split across two systems.
I pushed for audit trails that are part of the workflow itself: every action logged in context, every decision attributed, every override explained. When an auditor asks “who approved this, when, and why?”, the answer lives on the same screen as the payment.
Outcome
What changed, qualitatively.
Payment time collapsed.
What used to take days of manual processing now runs in minutes of batch configuration. Finance teams stopped being a bottleneck and started being a control point.
Audit defensibility by default.
Every payment carries its full history in context. Approval chains, overrides, and exceptions are discoverable on the payment itself — not pieced together from logs.
Provider trust restored.
Real-time status replaced “call the insurer to find out.” Settlement visibility cut down on the support calls that were straining provider relationships.
Errors became visible, early.
Reconciliation that used to catch problems weeks later now surfaces exceptions within hours. Duplicate and failed payments are investigated before they turn into provider complaints.
Reflection
Designing in a regulated domain.
The biggest lesson from this project: in regulated workflows, the user isn't just the operator — it's also the auditor, the regulator, and the provider on the other end of the payment. Every screen has to serve all of them at once.
That changes the design brief. You can't just optimize for operator speed; you also need a trace someone else can read, months later, to reconstruct what happened and why. In the best case, those two goals reinforce each other — the operator does the right thing by default, and the right thing happens to be auditable. That's what this module tries to do.