Table overload
Stakeholders worked from large tables and spreadsheets, which made trend analysis slow.
01 / R1 RCM / 4 WEEKS
Revenue Cycle Analytics Platform.
Finance teams went from reading static tables to seeing claim delays and denial trends at a glance. Executives get the summary. Operators get the detail.
Lead UX DesignerData visualisation, dashboard system, stakeholder discoveryFigma · FigJam · Power BI
The impact
+0%Task completion, with cognitive load down about 70% and NPS up 35+.
The problem
Finance teams read static tables and fragmented datasets, so claim delays and denial trends were hard to spot.
The solution
Executive and operational dashboards with drill-down, trend-first visuals and a lightweight design system built inside Power BI.
Screening Rate dashboard · R1 RCM analytics
- My role
- I led UX for the analytics experience: stakeholder discovery, KPI definition, the dashboard design system and the interactive prototype.
- The central decision
- Summary first, detail on demand. Separate executive and operational views and connect them with drill-down.
- Project scope
- Four Power BI revenue-cycle dashboards (Screening Rate, Solution Rate, CWL and Conversion) and a lightweight design system, delivered in a 4-week engagement.
01 / Context
Hospital finance teams could not spot revenue problems early.
R1 RCM runs the financial lifecycle of patient care for US hospitals and health systems. I led UX for the analytics layer that tells finance teams how that engine is performing.
R1 RCM provides technology-driven revenue cycle management to hospitals, health systems and physician groups. The brief was to raise hospital revenue efficiency while improving the patient financial experience, by giving finance teams a centralised, visual view of revenue-cycle health in real time.
The lifecycle the platform supports
- Registration & scheduling
- Medical coding
- Claim submission
- Payment reconciliation
- Revenue analytics
- Improve visibility of revenue-cycle performance
- Identify billing and claim issues faster
- Support both operational and executive decisions
- Turn complex datasets into clear visual insight
02 / Problem
Finance teams were reading tables, not trends.
Revenue data flowed in from hospitals, insurers, billing systems and claims platforms. Reporting presented it as static tables and fragmented datasets.
Two audiences
Executives needed high-level summaries; operational teams needed claim-level detail.
Platform limits
Every solution had to live within Microsoft Power BI’s visualisation capabilities.
Even the data model worked against readers. Datasets arrived labelled Series 1, Series 2 and so on, with no meaningful categorisation, so anomalies and trends could not be read at a glance. The first design decision was to give the data a structure people could reason about.
03 / Research
Start with the decisions, then the KPIs.
Discussions with three groups defined what the dashboard had to answer, before any chart was chosen.
Stakeholders consulted
- Revenue operations teams
- Financial analysts
- Data engineering
The five KPIs that anchor the experience
- Days in Accounts Receivable
- Net Collection Rate
- Clean Claim Rate
- Denial Rate
- First-Pass Claim Acceptance
04 / Strategy
Summary first. Detail on demand.
Two dashboard levels separate what executives monitor from what operators fix. Drill-down connects them.
Two views, one data model
Separating the audiences reduced cognitive overload.
01
Executive dashboard
- High-level financial KPIs
- Revenue performance summaries
- Trend indicators
02
Operational dashboard
- Detailed claim insights
- Denial tracking
- Workflow monitoring
Try the dashboards
One live interaction per dashboard, built from the final Figma design. Illustrative data, as in the design file.
Trend-first visuals
Trends over raw numbers surface anomalies and operational risk faster.
Progressive disclosure
Show the summary; reveal detail only when someone asks for it.
Insight over decoration
Every visual earns its place by supporting a decision.
05 / Design
Designing inside Power BI’s limits.
Power BI offers a limited set of native visuals and the data was dense. The constraints became the design brief.
Limited visualisation options
Combined multiple charts to express complex datasets, simplified the visual hierarchy and structured the data for readability.
High-density data
Prioritised critical KPIs, segmented data into smaller visual modules and used drill-downs for progressive disclosure.
One anatomy, four dashboards
Every screen reads top to bottom: set the scope, check the KPI, see the trend, act on the account.
Navigate
Four dashboards as tabs, with a breadcrumb and an information link on every screen
Filter
Two zones: time (encounter and admit dates, date range) and scope (facility, patient type, activity)
Level 1
KPI cards: target against actual for each patient type, with a 6-week trend and change
Level 2
Week-over-week trend, comparison and distribution charts
Level 3
Account-level tables, so operators can act on the exact accounts
Green: healthy
Performance within target.
Red: operational risk
Needs attention from the operations team.
Neutral: information
Context, not a signal.
06 / Final design
Four dashboards, one revenue journey.
The final product is four Power BI dashboards. Their tab order follows the patient financial journey: screened, matched to a funding solution, worked from the backlog, converted to coverage.
The final dashboards
Select a dashboard to see the question it answers.
Step 01 of 04
Are accounts being screened, and where are the gaps?
On this screen
- Inpatient, emergency and surgery screening rates against target, each with a 6-week trend
- The top 5 unscreened inpatient accounts by balance
- Screening rate by facility, week over week, against a target line
- Complete against incomplete screening by patient type, with the defect account list beside it
Scroll inside the frame · select to enlarge
Step 02 of 04
Once screened, how many accounts reach a funding solution?
On this screen
- Solution rates by patient type against target
- Accounts by solution: financial assistance, injury assistance, Medicaid disability and non-disability
- Solution rate by funding source, and identified against activated rates by week
- Defect account lists for surgery and emergency
Scroll inside the frame · select to enlarge
Step 03 of 04
What is still unworked, and how risky is the backlog?
On this screen
- Unworked overdue accounts and their open AR sum for the current week
- High-risk accounts (risk levels 4 and 5) and their share of the backlog
- Presumptive eligibility activity: passed, failed and in process, week over week
- Overdue accounts by age since discharge, a risk-level snapshot and account-level details
Scroll inside the frame · select to enlarge
Step 04 of 04
Which accounts convert to coverage, and which facilities fall behind?
On this screen
- Inpatient, emergency and surgery conversion rates against target
- Facility performance, coloured red to green on the risk level 1 and 2 backlog
- Conversion by funding source and by patient type, week over week
- Converted against non-converted accounts by coverage type
Scroll inside the frame · select to enlarge
07 / Impact
A reporting system became a decision tool.
The redesign changed how stakeholders monitor and manage revenue-cycle operations.
Reported impact
% change versus the previous reporting experience.
View as table
| Measure | Value |
|---|---|
| Reduced cognitive load | −70% |
| Task completion | +25% |
| Support staff performance | +15% |
| Decision-making time (up to) | −13% |
- Improved visibility of revenue-cycle performance metrics
- Faster identification of claim-processing delays and denial trends
- Better monitoring of operational team performance
- NPS up by 35+ points
08 / Learnings
What this project reinforced.
Three principles I now start every analytics project with.
Stakeholder alignment is critical
Early collaboration surfaced the KPIs and business goals that mattered most.
Insight over decoration
Effective dashboards focus on actionable metrics, not aesthetic charts.
Constraints drive creativity
Working within platform limits forced a more thoughtful data structure and hierarchy.
09 / PROCESS
How it came together.
- 01
Discover
Stakeholder sessions with revenue ops, analysts and data engineering.
- 02
Analyse
Dataset audit and the critical revenue-cycle KPIs.
- 03
Strategy
Executive and operational views, drill-down, trends.
- 04
System
Colour, type, components and layout rules.
- 05
Prototype
Interactive prototype validated before build.
Contact