Skip to content
HHemlineAnalytics
Request a call
All workCase study · Healthcare services · Fabric app

A manual QA process, rebuilt as an app inside Fabric.

Utilization QA Console: a review app on the same semantic model as the reports, so the team checks and corrects client data before any report goes out.

$250K+
of workload absorbed by the app
2 roles
of engineering work covered after both engineers left
1 model
behind the reports, the app and client PDFs
01The problem

Client utilization reports depended on a manual QA process that was slow, easy to get wrong, and carried by two engineers. When both left, the work had nowhere to go, and every correction still had to land in the reports before the next refresh.

02What we built
  1. 1An app inside Fabric. It reads the same semantic model as the reports, so the numbers on screen are the numbers clients see.
  2. 2Edits with an impact preview. The before and after, including billing impact, show before anything is written.
  3. 3A change log with undo. Corrections write to Fabric SQL with the value they replaced and a reason, and flow back into the lakehouse first.
  4. 4Client PDFs on demand. Built in the browser from the model, watermarked until they’re final.
03The result

Review cycles now run from one screen, every correction can be traced and undone, and the app absorbed more than $250K of workload.

04 · Inside the app

Rebuilt on fictional data, screen by screen.

Overview screen: review countdown, readiness, sign-off, progress by account manager and an action queue
Review cycle at a glance. Countdown, readiness and sign-off, standings by account manager, and a queue of what needs attention.
An edit panel showing a value’s before and after, with the estimated billing impact and a reason field
Edit with impact preview. Pick a field and a value; the before and after, billing included, show before anything is written.
A matrix of every client report section, with counts by quarter
Report matrix. Every client report section in one view, with pending edits projected before the refresh.
A PDF preview dialog with layout and section options for one organization
Client report PDF. Scope to one organization, choose sections and layout, and preview a watermarked report.
An organization’s change history with each edit, its old value and its reason
History and undo. Every change logged with the value it replaced and a reason; any change can be undone.
05 · How an edit flows

Read with DAX, write through GraphQL, closed on the next refresh.

The app reads and writes through two different systems. Step through a correction, or let it play.

Lumenwell Data Platformqa_consoleHow an edit flowsSample data
Read and write are two systems
The loop closes on the next refresh
QA consoleApp in Fabricwrite · GraphQLqa_consoleSQL databaseauto-mirrorOneLakeMirrored tablesshortcut · viewlh_goldGold lakehouse06:00 build, then model refreshUtilizationSemantic modelread · DAX
8 of 8 · Closed

The model now says 4,420. The app, the reports and client PDFs agree.

Result
Q3 2026 covered lives  4,420
reports · app · client PDFs agree
  1. UtilizationSemantic model read · DAX
  2. QA consoleApp in Fabric write · GraphQL
  3. qa_consoleSQL database auto-mirror
  4. OneLakeMirrored tables shortcut
  5. lh_goldGold lakehouse 06:00 build, then model refresh
  6. UtilizationSemantic model

Closed. The model now says 4,420. The app, the reports and client PDFs agree.

Pinecrest Senior Living
Published

Report preview · utilization summary

RowQ4 2025Q1 2026Q2 2026Q3 2026
Covered lives4,0204,0904,1504,420
Case utilization12.1%11.2%11.8%10.8%
Program utilization30.8%31.1%32.4%29.6%

Change log

Oct 27 4:12 PMs.delacroixLives 4,180 → 4,420 Undo
Oct 14 9:03 AMo.brennanPEPM $2.10 → $2.25 Undo
Oct 9 2:40 PMi.solbergRun group → Quarterly Undo

What moves A covered-lives edit changes three report rows. Nothing else divides by it.

The edit loop. A reviewer corrects covered lives, sees the projected report, and the change mirrors into the lakehouse before the model refreshes.

Next case studyMetadata-Driven Lakehouse One pipeline for every source. A new table onboards with a config row, and schema checks stop bad data at the door.
Corrections living in spreadsheets and email threads?Talk to us