Why Your RCM Dashboard Might Be Telling the Wrong Story

JB HUMAN ANALYTICAINSIGHTS & PERSPECTIVES

Data can be correct—and still be wrong—when the model does not represent the workflow behind the number.

By Jessica Burnett, Founder, JB Human AnalyticaPublished July 25, 2026

SCOPE AND EVIDENCE DISCLOSURE

This article reports findings from a controlled synthetic radiology revenue cycle management (RCM) portfolio created solely for JBHA. No record or value was copied, adapted, or derived from any client, employer, consulting engagement, or other organization with which Jessica Burnett has worked. The results are not industry benchmarks or evidence of prevalence in live practices. Numerical findings were cross-checked against authoritative CSVs, SQL acceptance materials, and the QA truth ledger.

Operational plausibility and business-rule correctness remain subject to human and subject-matter review.

A dashboard does not literally lie.

It can, however, faithfully display an incomplete or poorly defined model. The calculation may follow its programmed rule while the result still fails to represent the operational event a leader thinks it represents.

That distinction matters in RCM. Claims, service lines, submissions, denials, payments, adjustments, reversals, payer order, and authorization decisions do not always share one grain or one timeline. When a summary collapses those relationships, the arithmetic can be reproducible while the interpretation remains unsafe.

What does JB Human Analytica do?

JB Human Analytica (JBHA) is a founder-led healthcare data-validation and decision-readiness consultancy. We trace a reported result back to calculations, and relationships; compare that technical logic with the real operational workflow; and identify what still requires human or subject-matter confirmation.

JBHA is not a billing platform, an accounting firm, or a compliance auditor. It provides an independent Human Validation layer before data informs dashboards, leadership decisions, automation, or AI.

What the controlled portfolio test revealed?

The portfolio contained intentionally imperfect records and exceptions that required investigation. The following statements are limited to what the source files actually establish.[1]

Observed condition	Verified portfolio evidence	Defensible conclusion
Claims referenced a payer absent from the payer dimension.	8 claims; $7,220.27 in billed exposure; 8 related payment records totaling $4,437.88.	The governed load quarantined the affected claims and related payments instead of allowing an invalid payer relationship into reporting.
Payments exceeded the billed charge on Claim 21.	Two payment transactions totaled $1,717.72 against $1,586.86 billed.	The records establish that payments exceeded the billed charge and require investigation. They do not prove that either payment was a duplicate.
A claim marked Paid retained a transaction-level balance.	Claim 124: $304.15 billed - $89.32 payment - $10.67 write-off + $31.18 reversal = $235.34.	The programmed balance formula is reproducible. Whether that amount is collectible, contractual, provisional, or otherwise classified requires validated business rules.

CONTROLLED PORTFOLIO EVIDENCE - CONTINUED

Observed condition	Verified portfolio evidence	Defensible conclusion
Required dates were missing or out of sequence.	15 claims lacked a first submission date. 8 payments were dated five days before the related first submission date.	The sequences violate the model's stated chronology and should be surfaced as exceptions, not silently averaged into cycle-time measures.
The same apparent denial-date problem had two causes.	30 denial events lacked an adjudication date: 18 were originally rejections miscoded as denials, and 12 were genuine denials with the date defect.	A single missing-date count would hide two different corrective actions. The label and the missing field both matter.

WHAT THIS TABLE DOES NOT CLAIM?

It does not establish fraud, duplicate posting, payer liability, the collectibility of a remaining balance, or the prevalence of these patterns in live RCM data. Those conclusions require additional evidence such as remittance records, contracts, fee schedules, adjustment definitions, submission history, and human workflow review.

The structural gaps matter as much as the row-level defects

Some questions cannot be answered by cleaning a field because the model does not yet store the relationship needed to answer them.

1. Claim summary versus service-line detail

The portfolio's initial claim table stores one CPT code per claim. That is a limitation of this model, not a statement about all claims systems. CMS claims-processing guidance repeatedly distinguishes claim-line items and line-level coding. A one-code summary can therefore conceal services, modifiers, or adjudication outcomes that belong at the service-line grain.[2]

2. Prior authorization workflow

The portfolio does not contain an authorization request, decision, supporting documentation status, or linkage from authorization to service and claim. CMS describes prior authorization as a process in which a provider or supplier submits a request and receives a decision before services are rendered. A claims-only model cannot reliably reconstruct that pre-service workflow from a downstream denial label alone.[3]

3. Professional and technical components

CMS recognizes separate professional and technical components for applicable diagnostic tests and identifies them through its PC/TC indicators and modifiers. A summary that collapses those components may obscure separate billing or payment paths.[4]

4. Primary and secondary payer relationships

The portfolio stores a single payer link per claim. CMS defines coordination of benefits as determining the relative payment responsibilities of health plans when a person is covered by more than one plan. The current model cannot represent that relationship fully, so it should not be used to claim secondary-payer completeness.[5]

Technical validation is necessary—and not sufficient

A repeatable SQL deployment can prove that the same input and rules reproduce the same output. It can prove row counts, referential checks, reconciliation equations, and exception logic. It cannot, by itself, prove that an allowed amount is contractually valid, that a reversal was posted for the right reason, that a denial label reflects the real workflow, or that an aging endpoint supports the intended decision.

That is why JBHA separates four layers that are often blurred together: technical validation, workflow validation, subject-matter review, and client approval. Passing one layer does not authorize claims about the others.

The Human Analytica Method

01	Define the decision	Name the decision, audience, materiality, time frame, and consequence of error before choosing a metric.
02	Trace the evidence	Connect the result to source records, grains, definitions, calculations, dates, and exclusions.
03	Confirm the human reality	Compare the programmed interpretation with the actual operational workflow and the people responsible for it.
04	Deliver clarity and controls	State what is supported, what is inferred, what remains unresolved, and what control or review is required before use.

Where does AI belong?

AI can accelerate profiling, testing, comparison, and documentation. It can also produce unsupported conclusions or repeat the same assumption across multiple systems. A second AI agreeing with the first is useful evidence of consistency, but it is not proof of truth.

NIST's Generative Artificial Intelligence Profile recommends reviewing and verifying sources and citations in generative-AI outputs. JBHA applies the same principle to analytical claims: identify the source, classify the statement, expose disagreements, and preserve a human decision point.[6]

"AI accelerates the investigation. The human validator remains accountable for meaning, limitations, and decision readiness."

The honest conclusion

The controlled portfolio demonstrates that technical rules can detect important defects and reproduce the same reconciliations. It also demonstrates why a technically consistent result can remain operationally unresolved.

The next step is not to declare the model human-validated. It is to take representative claims, trace every related record, expose each assumption, and review the unresolved workflow questions with an experienced RCM subject-matter expert. That is where technical evidence meets human reality.

THE JBHA READINESS STATEMENT

Technically cross-checked against the programmed portfolio rules; not yet workflow-validated, subject-matter reviewed, or client-approved.

Data can be correct—and still be wrong. The purpose of Human Validation is to determine when the number is safe to trust, what it actually means, and what must still be confirmed before it drives a decision.

Learn more or schedule a Human Reality Check at www.JBHumanAnalytica.com.

Sources and evidence notes

[1] JB Human Analytica. JBHA RCM Governed SQL Deployment - Pass 2 v3, including authoritative synthetic CSVs, qa_truth_ledger_results.csv, expected_results.md, and deployment acceptance materials. July 2026. Internal controlled portfolio source, created solely for JBHA; see the Scope and Evidence Disclosure for provenance.

[2] Centers for Medicare & Medicaid Services (CMS). Medicare Claims Processing Manual, Chapter 23 - Fee Schedule Administration and Coding Requirements. CMS guidance uses claim-line items and line-level coding instructions. Accessed July 25, 2026.

[3] CMS. Prior Authorization and Pre-Claim Review Initiatives. CMS distinguishes prior authorization and pre-claim review and describes the timing of the request and decision. Accessed July 25, 2026.

[4] CMS. Medicare Claims Processing Manual, Chapter 13 - Radiology Services and Other Diagnostic Procedures and CMS Status Indicators - PC/TC Indicator. These sources describe professional and technical components for applicable diagnostic tests. Accessed July 25, 2026.

[5] CMS. Coordination of Benefits. CMS explains payer responsibility when a person is covered by more than one health plan. Accessed July 25, 2026.

[6] National Institute of Standards and Technology (NIST). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). The profile includes source and citation verification among generative-AI risk controls. July 2024.

© 2026 JB Human Analytica. All rights reserved.