Separating Work Queues from Reporting Views
A work queue assigns specific items to an owner for action; a reporting view summarizes activity, outcomes, or risk for analysis. The two may use the same source data, but they need different definitions, controls, and refresh expectations.
Updated 2 min read
On this page
Key takeaways
- A queue routes individual work; a report explains a defined population.
- Both need stable definitions, but their fields and timing are different.
- Reconciliation prevents dashboards and operating teams from telling conflicting stories.
What it controls
A work queue assigns specific items to an owner for action; a reporting view summarizes activity, outcomes, or risk for analysis. The two may use the same source data, but they need different definitions, controls, and refresh expectations.
When a dashboard is treated as a queue, users may lack the fields, priority, history, and closure states needed to finish work. When a queue is treated as a report, changing assignments can distort trends and make historical results impossible to reproduce.
Design the work
Define a queue by entry criteria, item identifier, reason, owner, priority, next action, deadline, and closure evidence. Define a report by metric, population, time convention, dimensions, refresh schedule, and data-through date.
Reconcile the two surfaces through stable identifiers and documented filters. The report should explain why its population differs from the live queue, including completed, reassigned, suppressed, or late-arriving records.
Minimum controls
- Documented entry and exit rules for every operational queue.
- A reproducible population and data-through timestamp for every report.
- Stable identifiers connecting summarized results to controlled work.
- Periodic reconciliation of queue counts to reporting populations.
Keep claim-specific information in the approved system
Put it into practice
Classify each surface
State whether its primary purpose is action, monitoring, or analysis.Write separate contracts
Document queue states and report definitions without forcing one design to serve both.Reconcile the difference
Test known items and explain population differences before publication.
Review and improve
Review the control on a fixed cadence and after a material policy, payer, system, staffing, or workflow change. Compare the current process with its documented design, sample the evidence it produces, and record exceptions separately from completed routine work. A control that exists only in a policy but leaves no observable evidence cannot be evaluated reliably.
Use findings to change the upstream process, not merely to clear the current queue. Assign one owner, one next action, and one follow-up date. Preserve the definition and baseline used for the review so a later result can be compared without changing the measurement after the fact.
Frequently asked questions
Can a dashboard link to a work queue?
Yes. Keep the analytical definition separate, then link authorized users to the controlled queue or filtered work list.
Should completed work disappear from a report?
Not automatically. Reports often retain completed records for historical measurement while the live queue removes or closes them.
Operational terms
Authoritative sources
- General Compliance Program Guidance (opens in a new tab)
HHS Office of Inspector General
- Internet-Only Manuals (opens in a new tab)
Centers for Medicare & Medicaid Services
- Medicare Learning Network resources and training (opens in a new tab)
Centers for Medicare & Medicaid Services