Going Beyond Power BI

Picture a fourteen-provider, four-location orthopedic group that finally builds a live dashboard, wiring Power BI straight into the practice management export. After years of month-end spreadsheets stitched together by hand, there's a view of margin per encounter that updates every morning. It gets presented at the partner meeting with real pride: average margin per encounter, $96, up from $81 the year before. Numbers moving the right direction, on a screen that looks like it belongs to a much bigger company.

Then one of the partners, who also happens to run the checkbook, asks why that number doesn't match what's actually landing in the bank. Not a hostile question. A real one. Nobody in the room has an answer, so someone spends the next two weeks finding it.

The dashboard wasn't broken. It had drawn exactly what it was told to draw. The problem was upstream, in a single field inside the EHR called "paid," which flips to true the moment the system posts an expected payment against a claim — the second the payer's fee schedule says a code should pay $178, not the day $178 actually shows up in the operating account. For claims still moving through adjudication, that gap runs two to four weeks. Every claim sitting in that window got counted as revenue in the dashboard before the practice had the money. Rebuild the number off the bank's actual cleared deposits instead of the EHR's internal flag, and average margin per encounter comes out to $79, not $96. Multiply a $17 gap across roughly 2,900 encounters a month and a practice like this would be reporting itself about $49,000 richer than it is, every single month, to a room of partners making staffing and expansion decisions off that chart.

The chart did exactly what it was told

A BI tool takes whatever table you point it at and renders it faithfully. Give it clean numbers and it draws clean charts. Give it a number that's technically present but three weeks premature, and it draws that just as cleanly, with the same crisp axis labels and the same confident color fill. Nothing in Power BI, or Tableau, or the analytics tab bolted onto most practice management systems, has any way of asking whether the number it just received agrees with what a different system, looking at the same claim, would say. That question sits entirely outside what a visualization layer is built to do. It was never supposed to check its inputs against anything; it was built to make whatever input it gets look good.

That's not a design flaw. A rendering tool that second-guessed every number fed into it would be useless for the ninety percent of charting work where the source data is fine. The trouble only shows up in a specific, narrow place: a medical practice's real financial picture never lives in one system. It's split across the EHR's clinical and billing record, the clearinghouse's version of what actually got submitted and adjudicated, and the bank's version of what actually cleared. Any two of those three can disagree, quietly, for weeks, and a dashboard built on only one of them has no way to notice.

A second number, counted twice

The EHR timing gap isn't the only thing that turns up in a case like this. Going through denials from earlier in the year often surfaces a claim — say $340 — denied for a coding error, corrected, and resubmitted three weeks later at a slightly adjusted allowed amount of $310. The corrected claim paid. The original, denied claim never got deleted from the system — it just sat there, a $340 line item with a "denied" status that, during a batch reconciliation run, picked up a payment reference pointing at the resubmission's remittance. Nobody did that on purpose. It's a side effect of how the clearinghouse links corrected claims back to their originals in the export file.

Sum "paid amount" across all claim rows in a given month without tracing which claims are corrections of other claims already in the file, and that single episode of care — one patient, one procedure, one actual payment of $310 — shows up twice: once on the original row, once on the resubmission. A BI tool has no concept of "these two rows describe the same clinical event." It sees two rows with dollar amounts and adds them, which is precisely what it's supposed to do with two rows that have dollar amounts in them.

What a chart can't check

None of this is a knock on the tools. Power BI does nothing wrong in a case like this. The actual work that's missing happens earlier, and it's a different kind of problem than visualization:

• Whether a claim the EHR calls "paid" has a matching, cleared deposit in the bank record, not just a matching expected-payment flag.
• Whether a corrected or resubmitted claim gets linked back to its original so the pair counts as one payment, not two.
• Whether a secondary payer's payment, which often lands weeks after the primary and gets posted in a different batch, gets attributed to the month the care happened rather than the month the check happened to clear.
• Whether the clearinghouse's record of what was actually submitted matches what the EHR thinks it sent, since resubmissions and corrections sometimes fork the two records apart.

Each of those is a question about whether independent systems agree with each other. A chart, however well designed, only ever answers questions about the one table it was pointed at.

Reconcile before you draw anything

The fix isn't a smarter dashboard. It's doing the reconciliation work first, at the claim level, across all three systems, and only then handing the output to something like Power BI to draw. That means matching every claim in the EHR against its counterpart in the clearinghouse and against an actual cleared deposit in the bank, before a single number gets labeled "revenue." It means timing recognition to the deposit date, not to an internal status field that flips early. It means tracing corrected claims back to their originals so a resubmission replaces a number instead of adding to it. Where two systems disagree — and they will, regularly, on some percentage of claims — the right output is a flag showing the disagreement, not a silent average that picks one version and hides the other.

Rebuild a margin number that way and the chart usually looks almost the same. Same axes, same monthly trend line, same clean styling. The number underneath it is just finally the real one — and that's usually enough to change which locations are actually worth the Saturday hours they've been running.