⏏ eject

side A · case study

Killing the DUR

Rebuilding How People Claim Their Health Money

A redesign of the claim Plum members file after they’ve already paid a hospital bill. The single biggest reason these claims stall isn't the money. It's the documents. A missing bill, an unreadable scan, a mismatched name triggers a Document Update Request (DUR): the insurer bounces the claim back, and a week or more evaporates. I redesigned three connected journeys (the discharge-led flow, bills & receipts, and reports & prescriptions) around one goal: get every document right the first time, so the claim never comes back.

Role
Product Designer
Year
2026
Platform
Mobile
Surface
Reimbursement claims
Status
Discharge-led flow live and under funnel evaluation; bills & receipts and reports in build.

I. Why claims break

A high-stakes task at a low-capacity moment

Reimbursement is the hardest path in the product, and the one people fall back to when cashless fails. It carries real money and real health context, and the person filing is usually a patient or a caregiver mid-recovery, not a power user.

  • Every claim demands a specific, insurer-dependent set of documents the member has never been asked for before.
  • Mistakes are expensive and invisible: a wrong or low-quality scan becomes a deduction or a document query (DUR) weeks later.
  • Delays compound when a member's health ID or policy is still pending at the time they file.

The failure modes I designed against

Problem map

I grounded the redesign in three recurring, costly failures observed across claims operations and support.

  • Duplicate claims. Members forgot a document, assumed the claim was lost, and re-filed the same claim for the same patient, doubling ops load.
  • Missed & mis-matched documents. Bills left out, reports with issues, and bank proofs whose name didn't match the insured. Each one was a silent dead-end.
  • No sense of “what happens next.” Once submitted, the claim disappeared into a black box with no expectation-setting on timelines or delays.
Fig. 1 One document hub orchestrates all three journeys, with mandatory vs. optional made explicit upfront.

II. The approach

Four principles that held the system together

Rather than redesign screens one at a time, I set principles that made the three journeys feel like one product.

  • Anchor on the one document everyone has. The discharge summary becomes the backbone that validates and pre-fills the claim.
  • Catch errors before the insurer does. Validate documents in-app and let people fix every issue in a single pass.
  • Make every requirement legible. Mandatory/optional tags, per-section status, and progress counters so nothing is ambiguous.
  • Never lose progress. Drafts resume, nudges prevent duplicates, and payouts verify in seconds.

III. The three journeys

Discharge-led journey

Discharge summary as anchor

Internally called “Discharge Summary Driven Reimbursement, V2”, this was the move that reframed the entire claim. Instead of asking members to hand-key admission dates, hospital, and treatment reason, the flow leads with the discharge summary and reads the claim out of it.

  • Validate first. The flow confirms the uploaded file is actually a discharge summary and blocks the member from proceeding on the wrong document, stopping a whole class of downstream rejections at the door.
  • Pre-fill the rest. Basic details (hospital, admission/discharge dates, reason for treatment) are carried forward into treatment details and the final review, instead of re-asked.
  • Set the category honestly. Hospitalization, day-care, pre/post-hospitalization, consultations, and home treatments each carry a plain-language definition so people self-classify correctly.
Fig. 2 Discharge summary validation and treatment details auto-fill.

Reports & Prescriptions

Error recovery

This is where the system earns its trust: catching document problems in-app rather than letting the insurer bounce them. I designed the review to handle the messy real-world combinations claims ops actually sees.

  • Resolve the full matrix of issues: one report with one issue, one report with multiple issues, a missing report sub-class, and a report that implies additional needs (e.g. medicines).
  • Fix everything in one pass. “Upload all your files again to review for all the issues in a go”, so members aren’t ping-ponged through repeated single-file rejections.
  • Reports stay optional in the hub, so the flow never blocks a valid claim on a document that isn’t required, but flags issues clearly when they are provided.
Fig. 3 Errors found in reports: missing documents and a single batch re-upload.

Bills & Receipts

Nudge-driven

The insight that shaped this journey: 25% of people filing an OPD claim miss at least one bill, “leading to wasted effort, slower claims processing or forgotten expenses.” I turned that data point into a contextual callout placed exactly where the mistake happens.

  • Clear requirement hierarchy: final hospital bill and its payment receipt are mandatory; other bills & receipts are optional, each with a status tag.
  • A single total claim amount field ties the uploaded bills to the money being claimed, reducing mismatch queries.
  • The missed-bill nudge sits in-context on the upload screen rather than as a generic warning, turning an analytics finding into a prevention.
Fig. 4 Bills and receipts, with the contextual 25% missed-bill callout.

IV. The connective tissue

The systemic moves that made it one product

The three journeys only pay off because of the scaffolding around them. This is where “overhaul” rather than “redesign” shows up.

  • Duplicate-draft nudge. When someone starts a claim for a patient who already has one in drafts, the flow surfaces “There is a claim in your drafts for the same patient” and routes them to resume it, directly attacking the duplicate-claim failure mode.
  • Penny-drop bank verification. A ₹1 transfer verifies account details in ~30 seconds, replacing manual cancelled-cheque/passbook uploads. When the account name doesn’t match the insured, the flow degrades gracefully to an HR-letter upload instead of a dead-end.
  • Upfront delay warnings. If a member’s health ID or policy is still pending, a callout warns that “this can affect the reimbursement timeline” before they file, setting expectations instead of apologizing later.
  • Progress never lost. Drafts save and resume (“you can always resume from where you left off”), and a post-submission status page maps the claim from “submitted to Plum” through “money credited.”

Craft & system notes

Decisions that kept a document-heavy flow from feeling heavy.

  • A shared component language (status tags, section lists, progress counters, spot icons), so a new document type is a configuration, not a new screen.
  • Progressive disclosure: “things to keep in mind,” sample documents, and a “why do we need this?” rationale sit one tap away rather than crowding the primary action.
  • An embedded help path (“book a slot with our claims expert,” in beta) for the cases where self-serve isn’t enough.

V. Impact & what’s next

Shipped, with measurement in flight

Live

The discharge-summary-led claim (V2) shipped in August 2026; the reports and bills journeys build on it as the document system matures. I’m tracking three outcomes to validate the bets above. This section will harden as the numbers land.

  • Fewer duplicate claims per patient, attributable to the draft-resume nudge.
  • Lower document-query (DUR) and deduction rates, from in-app validation and batch re-upload.
  • Faster, cleaner payouts via penny-drop verification and a single claim-amount reconciliation.

Note: Outcome metrics are being instrumented; figures will be added once post-launch data is available. The 25% missed-bill figure is the pre-redesign baseline that motivated the bills journey.