CMS metrics template keeps counts, percentages, and timing separate

A percentage needs its operating population

The direct answer in the CMS template is that public prior-authorization reporting is not one approval-rate field. The template identifies an affected payer population, a prior calendar-year measurement period, medical items and services rather than drugs, and separate metrics for standard and expedited requests. It also recommends showing counts with percentages so a reader can see the scale represented by a rate.

A reporting system should preserve the reporting entity, line of business, product or program, measurement dates, request class, item or service scope, numerator, denominator, exclusions, and calculation version. A percentage displayed without those fields cannot show whether two disclosures describe comparable populations. A corrected request, duplicate transmission, withdrawn request, reopened case, or appeal can change the population depending on the governing definition and should not be silently recategorized.

Standard and expedited requests remain separate

CMS asks for distinct reporting on standard and expedited prior-authorization requests. That boundary matters because the request class, decision timeframe, escalation path, clinical urgency, and volume can differ. Combining the classes may produce a single average that describes neither workflow and can hide where delays or denials actually occur.

The underlying event ledger should capture when a complete request was received under the applicable definition, how the request class was determined, requests for additional information, status changes, final determination, notice, and any later appeal. If the request changes class, the system should retain who changed it, when, why, and how the reporting logic treats the event. A dashboard total should be reproducible from immutable or versioned transaction records.

Initial decisions and appeals answer different questions

The template separates initial outcomes from approvals after appeal. An appeal result is not evidence that the initial request was approved, and an initial denial rate is not a clinical-quality score. The reported figures need their own event definitions and links so a reader can understand whether an appeal relates to the same request, which level of review it represents, and which period governs its inclusion.

Payers and technology providers should demonstrate how a request identifier, denial reason, notice, appeal, supporting information, reviewer role, decision, and final disposition remain connected without overwriting the original history. The model should also expose unresolved relationships and late appeal outcomes rather than forcing every event into the prior year's table. CMS's template supplies a reporting structure; it does not resolve every data-quality or attribution question.

Timing metrics require clock definitions

CMS's metrics include decision timing for standard and expedited requests. A useful implementation must define the start and stop events, calendar treatment, pauses, incomplete requests, withdrawn cases, outliers, and whether the reported value is an average or median. A time produced by subtracting two convenient timestamps may not represent the measure CMS expects or the experience of the requesting provider.

Buyers should ask a payer or reporting vendor to reproduce one published value from source events and then test a late, appealed, incomplete, and reclassified request. This analysis does not determine how a particular payer must calculate or publish a metric. The final rule, program-specific requirements, current CMS instructions, and the payer's actual data and definitions control the report.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Prior Auth Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.