What UM Ops Teams Actually Need From an SLA Dashboard (and Rarely Get)

Before 2026, a missed prior-auth turnaround at most payers was an internal metric — regrettable, coached, occasionally escalated. Under CMS-0057-F it is a regulatory boundary: expedited requests decided within 72 hours, standard requests within 7 calendar days, for Medicare Advantage, Medicaid, and CHIP programs (QHP issuers escaped the federal timeframe provision, though state rules still apply). And once a year, your aggregate timeliness goes on your public website for regulators, journalists, and competitors to read.

Most UM reporting was not built for this. It was built to describe last month — average TAT, volumes by category, a compliance percentage. Those reports document breaches; they don't prevent any. Having sat with UM operations teams through this transition, here is the working specification for a dashboard that actually runs the floor.

The one question that comes first

Everything else is secondary to: which open requests are going to breach, and when? Concretely, that means every open request carries a computed deadline and the primary operational view is a queue sorted by time-to-breach — not by age, not by receipt date, by remaining time.

Computing that deadline honestly is harder than it sounds, and it's where most homegrown dashboards quietly lie:

• The applicable rule varies per request. The federal floor is 72 hours expedited / 7 calendar days standard, but state Medicaid contracts are often tighter, state UM statutes differ, and lines of business differ (a QHP request and an MA request for the same service carry different clocks). The dashboard must resolve, per request, the strictest applicable rule for that member's program and state — and show which rule it applied, so a supervisor can trust the number.
• Clock-start discipline. When does the clock start — first receipt, or receipt through the specific channel your policy defines? If the EDI gateway timestamps a 278 at 11:58 PM Friday and the UM system ingests it Monday morning, which timestamp governs? Pick the defensible answer (receipt), enforce it in data, and make sure the dashboard and the public metrics use the same one.
• Calendar time, always. The federal clocks run through weekends and holidays. A dashboard that hides Saturday from the countdown is an instrument that reads safe while the plane descends.

Pends are where breaches are born

Nearly every late determination spent most of its life pended — waiting on clinical documentation, medical review, or a callback. (In 278 terms, HCR01 = A4.) So the second screen of the dashboard is pend management:

• Pend age against remaining clock, not pend age alone. A 3-day-old pend on a 14-day state clock is fine; a 1-day-old pend on a 72-hour expedited request is an emergency.
• Pend reason and ball-in-whose-court. "Awaiting records from provider, requested day 0, re-requested day 2" is manageable; an unreasoned pend is a future violation. Every pend needs a reason code, an owner, and a next action date the dashboard can nag about.
• Pend-to-decision conversion patterns. Which pend reasons resolve into approvals at high rates? Those are candidates for eliminating the pend entirely — either by fixing intake so the documentation arrives up front (the DTR promise) or by relaxing a documentation demand that isn't changing outcomes.

Channel-blind, or it's fiction

Requests arrive by portal, fax, phone, X12 278, and — increasingly — the FHIR Prior Authorization API. The clocks don't care. A dashboard fed only by the UM platform's native intake misses the requests that stalled before reaching it: the 278 that died in a 999 rejection nobody monitors, the fax queue that backed up over a holiday weekend, the API request that failed validation. Coverage means instrumenting every front door, including the failure modes upstream of the UM system — because the provider's clock (and the regulator's sympathy) started when they sent it, not when you ingested it. This gets harder, not easier, in the dual-rail era; the dual-stack tax is partly a monitoring tax.

Expedited requests deserve their own physics

The 72-hour queue is a different operational regime, and the dashboard should treat it as one: separate view, weekend-and-holiday coverage plan visible in the staffing overlay, and — critically — downgrade tracking. Requests submitted as expedited and reclassified to standard are an audit magnet; inappropriate downgrading is one of the fastest ways to turn a staffing problem into a compliance finding. Every downgrade needs a reason, a reviewer, and a trend line someone looks at monthly.

The retrospective views must reconcile to the public numbers

You now publish prior-auth metrics annually — approval and denial rates, appeal outcomes, decision timing — with the first reports having landed by March 31, 2026. The dashboard's historical views and the published report must be the same pipeline, or at minimum reconcile exactly. The failure mode to avoid: operational dashboards that exclude administrative rejections from the denominator while the public report includes them (or vice versa), leaving your compliance officer explaining a discrepancy to a regulator with a spreadsheet. Definitions — what counts as received, decided, denied, appealed — belong in version control, applied identically everywhere. See the metrics CMS makes you publish for the definitional traps in detail.

What to leave out

Discipline about exclusions keeps the tool usable. Leave out vanity aggregates that no decision hangs on (all-time averages, this quarter's "requests processed" trophy number). Leave out anything that duplicates the UM platform's case view — the dashboard routes attention; the platform does the work. And resist per-reviewer leaderboards as a primary surface: they optimize for closing easy cases fast, which is not the same thing as protecting the clocks on hard ones.

The numbers that belong on the wall

If the primary screen is the time-to-breach queue, the secondary wall display is a small set of daily numbers the whole floor can see and argue about. Keep it under seven:

• Requests at risk — open requests with less than 24 hours (expedited: less than 12) remaining on their clock.
• Oldest pend without a next action — should be zero; anything else has a name attached.
• Expedited queue depth and coverage — how many urgent requests are open, and who owns them through the next weekend or holiday.
• Today's straight-through rate — the share of requests answered with no human touch, because every point of automation is breathing room on everything above.
• Rejections returned to providers — intake failures bounced back today, since each one is a request whose real clock is still running somewhere.

Numbers on a wall change behavior in a way reports never do. When the "requests at risk" figure is visible to everyone, the informal escalation that used to require a supervisor noticing happens by ambient pressure — reviewers pull from the top of the risk queue without being asked. That cultural effect, more than any feature, is what separates teams that treat the 2026 clocks as a constraint to design around from teams perpetually surprised by Friday afternoon.

The maturity test

A one-question test for whether your SLA tooling is real: can your UM director, on Friday at 4 PM, see every request that will breach by Monday morning — across every channel, program, and delegate — on one screen? If yes, the 2026 requirements are an operating rhythm. If no, your compliance posture is a bet that nothing arrives on Friday night — and under a calendar-day clock, something always does.