Centene Recovery Platform

Speeding up claim recovery at a Fortune 25

Leading a $40M initiative, enabling hospitals to more effectively communicate with insurance companies, challenge costs, and speed up claim processing.

  • Strategy
  • Facilitation
  • Team Leadership
  • Consultation
  • Product Design
Role
Lead Product Designer
Led a team of 10
Product
0 → 1 enterprise web app
Fortune 25 healthcare
Methods
Agile & Lean UX
Usability testing
Hypothesis-driven design
Tools
Figma
PrimeReact
AI

The Problem

Manual claim recovery took months and cost $38M a year

Recovering overpaid claims took Centene’s analysts two to four months, spread across separate tools, endless emails and outside vendors.

The process was slow and error prone, and those costs ultimately reach patients.

What I Did

I led design on a 0 → 1 platform that replaced Palantir

As lead product designer on a team of 10, I designed one web app where analysts could validate claims, see each claim’s history and manage vendors in one place.

I set up how the team worked: a Product Canvas workshop to agree on users and goals, Dual-track Agile to keep design a sprint ahead of development, and Lean UX hypotheses ranked by value and effort. We shipped 31 tested iterations, checked with users in 64 usability tests.

Impact

Two years in: claims processed 34% faster with 62% fewer errors

2 years later, the Centene Recovery Platform completed 149 business goals, 53 specific outcomes, and 182 hypotheses tested resulting in 31 published and tested iterations.

Speed
+34%Increase in claim processing speed
Errors
-62%Reduction in data errors
Challenges
-17%Reduction in reimbursement challenges

Leading a new team while writing the playbook

Our internal teams ran a decentralized team formation to product development. I worked as an embedded consultant, leading the design initiatives of multiple product teams simultaneously.

Building a foundation before anyone writes a line of code

Before the work could begin, the team needed a shared foundation. I introduced three frameworks to shape how we’d operate — Agile product design, Lean thinking, and a clear understanding of the end-to-end design process.

A Product Canvas workshop aligned the team on users, goals and problems

Every new product team starts with the same problem: team chaos. Where should we start? Who is doing what? What are we even building?

I facilitate a Product Canvas exercise as a method of gathering team alignment. This exercise allows the team to form a shared basis of understanding.

Moving forward, we can build momentum knowing we all agree on where we currently are and the fundamental problems we’re trying to solve.

The Problem

Parking Lot

Business Goals

Users

User Needs

The current process is costing us $38 million dollars annually.
— Business Analyst

“It takes two to four months to process recoveries in our current environment.”

— Product Owner

“Every claim is overpaid by design. That's just how the current system works.”

— Business Analyst

“We heavily rely on 3rd party vendors to manage this process for us.”

— Senior Manager

Better quickly instead of perfect later

Fixing the insurance claim process could go many directions. Some of those directions are good, some not so good, and some completely unattainable. It’s more important to be better quickly than perfect later.

Now

Focused effort

  • Replacing Palantir
  • Improving the current process
  • Automating data flow
  • Outdating the need for Excel
Later

Parked, not abandoned

  • Solving a larger healthcare problem
  • Innovating the adjudication process
  • Inventing a new claim adjustment flow
Project Goal

Increase claim validation speed, minimize errors, and simplify the recovery calculation process.

Dual-track Agile kept design one sprint ahead of development

To maximize momentum in an Agile framework, I introduced the team to Dual-Track Agile. This cadence enables the product team to know their involvement with the design process and when those involvements will occur.

This cadence cycles with each iteration, enabling the design momentum to stay ahead of development.

DesignDevelopmentSprint 1Sprint 2Sprint 3Sprint 4Sprint 5Sprint 6
Iteration 1
Iteration 2
Iteration 3
Iteration 4
Iteration 5
Infrastructure Setup
Iteration 1
Iteration 2
Iteration 3
Iteration 4

I further break down each sprint and introduce a design cadence. This enables the team to understand what is expected of them and when those expectations are required.

ProcessInvolvementDay 1Day 2Day 3Day 4Day 5Day 6Day 7Day 8Day 9Day 10
Prioritize Effort
Research & Design
PO / Dev Design Review
Refine & Write Documentation
Full-Team Demo & Acquire Sign-offs
Resolve Challenges & Acquire Sign-Offs
Full Team
Design Team
Product Owners, Developers
Design Team
Full Team, Users, Stakeholders
Individual Stakeholders

Turning Product Canvas findings into hypotheses, then ranking them by value and effort

With an Agile mindset and an objective of publishing quickly, the goal is to determine where we can provide the most value with the least amount of effort.

The Hypothesis Prioritization process from Lean UX builds team alignment while prioritizing momentum. We can use the data collected from our Product Canvas to quickly build hypotheses.

We will achieve

Increased claims processing speed

  • If this personBusiness Analyst
    AttainsA list of claims in order of priority
    ThroughTimeliness indicator
  • If this personBusiness Analyst
    AttainsAn organized / grouped list of claims
    ThroughClaim Sorting
  • If this personPI Analyst
    AttainsAbility to export a list of claims
    ThroughCSV Exporting
  • If this personPI Analyst
    AttainsA customized / grouped list of claims
    ThroughClaim Filtering
  • If this personBusiness Analyst
    AttainsAccess to a specific claim
    ThroughClaim Search
  • If this personBusiness Analyst
    AttainsView the edit history of a claim
    ThroughClaim Audit Log

Hypotheses were presented to the greater team for prioritization. Product Owners can evaluate the value of each outcome while developers and analysts can evaluate the effort involved with building the feature.

Hypothesis Prioritization

Quick wins

High value · low effort

  • View an organized / grouped list of claims

    through Claim Filtering

  • View claims organized by priority

    through a timeliness indicator

  • Take action on a claim

    through ‘Approve’, ‘Pend’, and ‘Deny’ actionables on every claim

  • View an organized / grouped list of claims

    through Claim Sorting

  • View the edit history of a claim

    through a ‘View history’ screen that displays historical data

Strategic bets

High value · high effort

  • Filter quickly

    through applying multiple saved filters simultaneously

  • Measure denials

    through specifying why a denial occurred via a dropdown of generic reasons

  • View specific and customized claim details

    through customized dashboard layouts

Fill-ins

Low value · low effort

  • PI Analyst

    Export a list of claims

    through CSV exporting

  • Prioritize which claims to view

    through applying multiple sorts simultaneously

Later

Low value · high effort

  • Find claims quickly

    through error prevention via form validation

  • Healthplan Analyst

    Communicate claim actionability to the PI team

    through the ability to write comments on claims

  • See relevant claims quickly

    through saving specific filter criteria

  • Compare claims to contra claims

    through a comparison table that flags differing fields

  • Use subtractive filtering

    through ‘or’ filtering

  • View more information about a claim quickly

    through expanding and collapsing rows with user-created notes

  • Find claims more easily

    through conditional filtering (contains, between, more than)

PrimeReact gave us a data-heavy design system that fit our tech and legal limits

The team chose PrimeReact, an open-sourced, federated design system to meet our constraints with tech stack, legal, and maintenance requirements. This system excels at presenting and manipulating data — a mechanic paramount to our users’ workflows.

Skipping wireframes and using Slicing to show each iteration’s scope

Based on our two-week sprint cycles and values of a lean, Agile workflow, we spent our effort on quick, high-fidelity mockups over wireframes.

To communicate iterations and effort, we use a process called Slicing.

Demos with users after every iteration turned feedback into new hypotheses

To validate the momentum of this iteration, I demo with various stakeholders and users to challenge if the output drives toward the intended outcome. Feedback was gathered enabling us to build new hypotheses as we begin tackling the next iteration of outcomes.

“I need to see the history behind the claim, the story it has gone through, and the decision-making that has been made along the way.”

— Business Analyst

“Would love to not have to open Amysis, Excellis, or other applications. It would be great to be able to see everything in one place.”

— Business Analyst

“I hate emails. We get far too many of them and things are getting lost.”

— Business Analyst

“A big part of this process is vendor management — who gets what and how much. Looking at trend data has helped in the past but we could use deeper analytics.”

— Product Owner

Outcome and feature roadmaps kept stakeholders up to date on each iteration

To maintain communication with the broader stakeholder team, momentum is captured through Outcome Prioritization and Feature Rollouts.

Tracking outcomes across iterations

Enables any stakeholder to view a team’s discovery effort and areas of focus.

Iteration01
Dashboard

A single view for all recoveries

through a claim dashboard that displays both claim lists (master and Payment Integrity Exclusions)

Claim View

The ability to review specific claims

through a Claim Details page

We will know we succeeded when

Team alignment and a baseline for future innovation.

Iteration02
Dashboard

A customized, grouped list of claims

through claim filtering

Access to a specific claim

through claim search

High-level information about a claim

through additional data columns on the claims dashboard

Claim View

A simplified view with only relevant details

through expanding / collapsing tables

We will know we succeeded when

Reduction in the excel documents needed to build a requested claim list.

Iteration03
Dashboard

An organized, grouped list of claims

through claim sorting

Access to claims further down the list

through pagination

More specific information about a claim from the dashboard

through expanding a row to see additional information / notes

The ability to quickly filter

through quick-filtering table columns

Claim View

The ability to view a claim's edit history

through a claim audit log

We will know we succeeded when

Analysts no longer use excel to prioritize effort.

Iteration04

And so on…

Output momentum across iterations

Enables all stakeholders to view the output momentum of the application within each iteration.

Iteration01
Dashboard

Claims Dashboard

Master and Payment Integrity Exclusions claim lists in a unified view.

Claim View

Claim Details Page

A focused interface for reviewing a single claim.

Iteration02
Dashboard

Filtering & Search

Customized, grouped lists and quick access to specific claims.

Data Columns

High-level claim information surfaced on the dashboard.

Iteration03
Dashboard

Sorting & Pagination

Organized, navigable claim lists.

Inline Detail & Quick-filter

Row expansion plus column quick-filtering.

Iteration04

And so on…

From a Palantir replacement to a full recovery platform across 31 iterations

What started as a replacement for Palantir became a full-scale recovery platform handling everything from claim validation to vendor management.

Below: a short tour through four notable views, pulled directly from the working Figma file and annotated using the documentation that shipped with each slice. Together they trace how the analyst’s view evolved across 31 tested iterations.

The dashboard

The analyst's home. A left-rail navigator across all six recovery-platform surfaces, a persistent claims toolbar (batch actions, filter, settings, search), and a sortable table that doubles as the link out to a single claim view. Every claim arrives here after the exclusions process.

  1. Sidebar — Service Lines, Post Pay DRG Selection, Post Pay Audit Results, Rules Management, Direct Bill Claims, and Value Simulator. The platform grew well beyond a single dashboard; the sidebar is how analysts pivot between surfaces without losing place.
  2. Claims toolbar — Batch Actions for multi-row workflows, Filter for narrowing the queue, Settings for column visibility, and Search for jumping straight to a known claim. Always-visible above the table so the workflow doesn't dead-end.
  3. Sortable claims table — Claim Number, Vendor, Business Line, Adjustment Amount, Program, Recovery Sent, Provider, HP Deadline, TIN, and Status. Every column carries a sort affordance; the column set grew well beyond Slice 1's four as analyst hypotheses shipped.
  4. Status — one of four states (Approved, Denied, On Hold, Pending). Non-approved tags hover-reveal which exclusion stage caught them (Master Exclusions, PI Lookback, or Exclusion Set) plus any analyst comments, using the Disclosure component.
  5. User profile + feedback — surfaced at the bottom of the sidebar so analysts always know whose context they're in, with a one-click feedback link out to the team.

Anatomy of a claim

A single claim's full story on one scannable page. The header carries at-a-glance status, audit-log access, and a lookback timer; below it, the Healthplan Manager's verdict, prior adjustment comments, and the full structured property set.

  1. Header section — Provider, Claim Number with status tag, plus the at-a-glance metadata: Submitted On, Lookback Period (with a warning icon when the deadline is tight), Adjustment Product, and Adjustment Amount. The Audit Log button opens the full action history over the page (next screen).
  2. Health Plan Review — the Healthplan Manager's verdict on the claim. When approved, the card collapses to a header plus the date. When denied (as here), it expands to surface the analyst, the reason, and the full comment. Change Status triggers a confirmation modal.
  3. Adjustment Comment — surfaces any prior comments left on the claim so context isn't lost between handoffs, with the vendor reference inline.
  4. Properties — the full structured data table about the claim itself: claim metadata, provider details, adjustment modifiers, and Medicare / OIC fields. "No Value" placeholders keep the rhythm scannable when fields are unset.

The Audit Log

The Audit Log modal opens over the claim view so the analyst doesn't lose their place in the queue. Every action on the claim, indexed and searchable — the team's answer to "how did this claim get into this state?"

  1. Audit Log table — every item is organized in a table with three columns. Item Number simply numbers each edit so analysts can reference a single line even when dates or notes look similar. Date is when the action occurred. Notes describes the action in plain language.
  2. Bolded items — anything tied to passing or failing an exclusions step renders bold so the eye lands on what changed.
  3. Modal scrim — the table is scrollable so history can grow without bounding the page; the scrim keeps the underlying claim view in soft focus.

Saved filter Setups

By the latest 🟢 Advanced Filter slice, the right-rail filter rolls up into named Setups — analysts can save the exact configuration they use on a Tuesday morning, then reload it on Wednesday without rebuilding it field-by-field.

  1. Default Setup — always present in the Setups list, can't be edited or removed, and reloads the original pre-customization filter. The escape hatch when a saved setup goes sideways.
  2. Save as New — names and saves the current setup without overriding existing ones. Switches the user to the Setups tab on save so they can confirm the new entry landed.
  3. Save (existing) — overwrites the currently loaded setup with the new field selection. Disabled when the loaded setup is the Default, forcing Save as New for any modification.
  4. Setup management — the kebab menu offers Rename or Delete on any user-created setup. Delete loads an inline confirm so it can't fire on a misclick.

Component details

The small craft — modals, controls, and brand moments that make the platform feel like a single, considered system.

Measuring the team, not just the product

While not as paramount as measuring impact, these softer metrics assist in validating application and process momentum. Less about user outcomes and more about team health.

Complete Business Goals
149
Outcomes Delivered
53
Hypotheses Tested
182
Hypotheses Developed
125
Developed Iterations
31
Usability Tests
64
Unique Personas
17
Completed User Needs
207

Why this work matters to me: faster claims mean real savings for real people

The American healthcare system isn’t perfect — and I know that more personally than professionally. I got into this work because financial barriers have a way of outweighing human health, and I’ve felt that cost firsthand.

Projects like this one don’t fix everything, but they move the needle. Faster claims, fewer errors, less time lost in a broken process — that’s real impact for real people. It’s not the whole problem solved, but it’s progress. And progress is worth building.