RCM Dashboard Data Dictionary: Define the Work Behind Every Metric

An RCM dashboard needs a data dictionary before it needs more charts. For each metric, define the unit counted, eligible cohort, source event, calculation, observation window, and accountable owner. Otherwise, two accurate-looking numbers can describe different workloads and support the wrong decision.

Use this template when evaluating AI RCM reporting or specifying a pilot. The definitions below are proposed project definitions, not universal industry benchmarks. Agree them with operations and finance, and map them to any reporting standard your organization already uses.

Start with the decisions the dashboard must support

An operations supervisor needs to know which items require attention and who owns them. A finance reviewer needs to know whether a financial result reconciles to the underlying records. A pilot sponsor needs to understand eligible workload, review effort, completion, and limitations.

These decisions may share a dataset, but they should not share an ambiguous “processed” metric. A recommendation, a human approval, an executed action, and a verified outcome describe different events. Make those events visible before combining them into a summary.

For broader context, see the existing denial management KPI guide. This page supplies the reporting contract needed to implement and test selected measures.

Create a metric definition record

Give each metric a stable name and version. Record the purpose and owner before writing a formula.

Dictionary field	What to specify	Why it matters
Business question	The decision this number supports	Prevents attractive but unused reporting
Unit of analysis	Request, file, claim, claim line, action, account, or dollar	Stops mixed-unit comparisons
Eligible cohort	Inclusion rules, exclusions, client, workflow, and period	Establishes what the software could actually process
Source event	System, record identifier, event type, and timestamp	Makes the number reproducible
Calculation	Numerator, denominator, aggregation, and rounding	Makes rates comparable
Time basis	Event date, receipt date, service date, or cohort date	Explains which period receives the result
Outcome maturity	Observation window and unresolved-item treatment	Avoids comparing recent and mature cohorts
Data status	Refresh time, missing inputs, partial data, and corrections	Exposes uncertainty
Owner and version	Definition approver, change date, and reason	Preserves meaning when the system changes

Add the fields required to segment the chosen workload, such as client, location, payer grouping, service cohort, and workflow configuration. Use only approved operational identifiers in the reporting environment; do not transfer patient or claim details into public website analytics.

Define a small set of workflow measures

The following definitions are a starting point for an evaluation. Replace them deliberately when your organization needs another unit or boundary.

Proposed measure	Example definition	Essential qualification
Eligible work items	Distinct items meeting the agreed workflow inclusion rules	Exclude neither failures nor difficult cases after the fact
Reviewed recommendations	Recommendations with a recorded permitted reviewer decision	Separate approval, correction, and dismissal
Executed actions	Approved actions with recorded execution evidence	An attempted action is a separate state
Verified completions	Items whose agreed destination result has been independently checked	Define what “complete” means for each workflow
Open exceptions	In-scope unresolved items at a specified snapshot time	Show owner, reason, age, and next action
Review effort	Recorded staff time for review, correction, exceptions, and reconciliation	State sampling and missing-time limitations
Reconciled recovery	Payment attributed to the defined recovery cohort and reconciled to its records	Show reversals, remaining balances, and observation window

A dashboard can support a useful operational pilot without claiming that every completed action has produced cash. Keep the financial evidence in its own measure. CMS's explanation of payment-remittance reassociation is relevant here: payment information and remittance information must be connected to reconcile the transaction, rather than treated as interchangeable events.

Make the denominator visible with a synthetic example

Suppose a fictional pilot receives 100 claim lines. Eighty meet its pre-agreed inclusion rules, 60 have recorded approved actions, and 54 have independently verified destination results at the reporting cutoff.

The approval proportion is 60 divided by 80, or 75% of eligible lines. Verified completion is 54 divided by 80, or 67.5% of eligible lines. A figure of 54 divided by 60, or 90%, answers a different question: the share of approved lines verified by that cutoff. None of these figures is an observed QuickIntell result or a financial return.

Display the numerator, denominator, unit, and cutoff beside the selected rate. Preserve the 20 excluded lines with their reasons and the six approved lines still awaiting verification. An improvement caused by excluding more work is different from an improvement within the same eligible cohort.

Specify missing data and revisions

Distinguish zero from unavailable. Zero means the source supports a measured count of none. Unavailable means the report cannot establish the value, perhaps because an input is missing or a connection failed. A partial report should say which source or period is incomplete.

Keep an operational snapshot for open work and a separate cohort view for outcomes that develop over time. A payment received this month for an older denial should not silently move the original work into this month's intake count.

Define how corrected source records, reversals, duplicate events, and late-arriving outcomes change prior reports. The report should reveal its refresh time and definition version. If a metric changes meaning, annotate the break instead of presenting the historical line as fully comparable.

Test the dashboard from records to totals

Select approved synthetic records with known outcomes. Trace each from the source event through its workflow state to the displayed count. Include a duplicate event, an unresolved exception, a late result, a reversed financial entry, and a missing source period.

Check that an event replay does not inflate the count, a missing input does not become zero, and a partial completion does not become a completed financial outcome. Reconcile aggregates by client and workflow before accepting a portfolio total. The billing company onboarding checklist adds the client boundary controls needed for that review.

Use the pilot acceptance testing template to record expected values and evidence. Link the resulting workload and effort measures to your AI RCM business case, with explicit assumptions about how capacity or cash benefits will be realized.

Ask for a reporting demonstration with your definitions

Bring the dictionary to a QuickRCM evaluation and ask which fields and calculations are available in the proposed configuration, which need implementation work, and which remain unverified. A screenshot of a dashboard does not establish its source coverage or metric meaning.

Find the connected workflow templates in the AI RCM evaluation toolkit. A scoped discussion can then focus on a small report whose records, calculations, and decisions your operational and finance owners can verify.