Prior Authorization Cycle Time: Measure Each Stage of the Request
Build comparable timing measures by distinguishing staff work, waiting, rework and the final administrative outcome.
A practice can improve its measurement without adopting a national benchmark. A comparable local baseline is more useful than a published average built from different payers, services or endpoints. The aim is to identify a stage your team can examine, not to make a promise about payer decisions.
Choose the question and the cohort
Begin with one operational question: how long does preparation take, how long after preparation does successful submission occur, or how long does it take staff to record a received decision? Each question has a different start and endpoint.
Next, define the cohort. For example, a team could examine requests first received by its authorization desk during one calendar month, limited to one administrative workflow. Record the inclusion rule and the date through which outcomes were observed. A received-in-month cohort is different from a resolved-in-month cohort; do not switch between them without changing the label.
Keep different request types visible. A change in the mix of services, payers or submission channels can change the summary even if the underlying process has not improved. Segment only where there are enough records to interpret the result, and always show the count.
The question of how long prior authorization can take under specific rules belongs to the timing guide. This article measures observed administrative events. It does not interpret compliance clocks.
Create a timestamp dictionary
Use events that the team can identify from a record. Define them once before exporting data.
| Event | Operational definition | Evidence to retain |
|---|---|---|
| Desk received | Request first reaches the measured team's work queue | Queue entry or source record |
| Preparation complete | Team records that the administrative packet is ready under its workflow | Completion event and person or system recording it |
| Submission attempted | A transmission is initiated | Channel event and outcome |
| Payer receipt confirmed | Available evidence confirms receipt | Acknowledgment or reference record |
| Additional information requested | A specific information request is recorded | Communication and timestamp |
| Response transmitted | Requested information is sent | Response record and channel outcome |
| Decision received | Decision communication reaches the team | Source notice or response |
| Administrative disposition recorded | Team records the outcome and next responsibility | Disposition event and owner |
Do not replace a missing timestamp with the next timestamp merely to complete a row. Mark missing evidence explicitly. If the source only records a date, do not pretend it supports hour-level precision.
Choose a common time zone for calculations and preserve the original timestamp where available. Document whether elapsed time uses continuous hours or an operational business-hours calendar. Those measures answer different questions and should not share an unlabeled column.
Separate elapsed time from labor
An interval between sending a request and receiving a reply measures elapsed time. It does not establish how many minutes a coordinator worked. Keep task-duration observations in a separate activity ledger.
Likewise, avoid adding every stage duration together when stages overlap. Staff may perform two different administrative activities while a request awaits an external response. Summing overlapping intervals can produce a number larger than the actual end-to-end elapsed time.
For rework, retain the repeated event and its reason. A second submission is useful evidence about the process, but it should not automatically become a second request in the cohort. Set the unit of analysis before counting it.
The cost of manual prior authorization guide uses staff minutes to calculate labor cost. Keeping the two ledgers separate prevents a long wait from being misreported as continuous paid effort.
Have a timestamp export but unclear definitions? Book a Linear Health demo and use one representative administrative path to discuss the events your workflow needs to expose.
Keep unfinished requests in view
The following tiny dataset is hypothetical. It illustrates reporting logic, not typical turnaround or a recommended service level.
| Request | Elapsed hours to the defined endpoint | Status at cutoff |
|---|---|---|
| Example A | 8 | Completed |
| Example B | 10 | Completed |
| Example C | 12 | Completed |
| Example D | 18 | Completed |
| Example E | 72 hours old | Still open |
The four completed requests have a median of 11 hours: the midpoint between 10 and 12. Their mean is 12 hours. The fifth request has no completed duration yet. Report it as one open request, aged 72 hours at the stated cutoff.
Do not put 72 into the completed-duration column. Do not omit the open request from the accompanying report. Both choices would confuse what the team has actually observed. In a larger dataset, a fast completed subset can coexist with a substantial unresolved backlog.
An operational dashboard can show completed durations and open aging side by side. More formal analysis of time-to-event data may require statistical support; a simple queue report should not imply it has solved that problem.
Report the distribution, counts and missing data
A median identifies the middle of the observed completed values. It does not describe every request. Add a spread measure when the sample supports it, and document the calculation convention used by your reporting tool.
The NIST box-plot reference describes using medians and quartiles to display a distribution. It provides a statistical method, not a healthcare benchmark. For a small cohort, a simple list or range may be more informative than an impressive-looking percentile.
Include these notes with each summary: cohort definition, start and end events, observation cutoff, completed count, open count, records missing required timestamps and any exclusions. A result without those notes is difficult to compare responsibly.
If the apparent improvement disappears when you hold the request mix constant, say so. If a new integration captures events that were previously invisible, record the instrumentation change. Better data can change the metric without changing the work itself.
Turn one finding into a bounded test
Choose a finding the team can investigate. For example, preparation-complete records may wait before successful submission. Check whether the interval represents a batching rule, an unavailable system or a missing handoff before deciding on a change.
Write the proposed test, the stage it should affect and the measure that will show whether it helped. Keep the same definitions for the comparison period. Check open aging and rework as well as the headline duration, so a faster visible stage does not hide work elsewhere.
Use prior authorization tracking for daily ownership and follow-up. Use the prior authorization solution overview when evaluating support for repeatable administrative tasks. Neither a new queue nor an automation claim replaces a comparable measurement design.
Start with events you can verify
A useful baseline has a clear definition and a traceable record behind each interval. Book a demo to discuss the administrative workflow you want to measure with Linear Health.
Frequently asked questions
Where should the cycle-time clock start?
Should open requests be excluded from completed-cycle summaries?
How does staff time differ from waiting?
Why can averages conceal a backlog?
What makes two timing cohorts comparable?
Sources
Sources accessed October 22, 2026.
Linear Health publishes educational articles about operational AI for healthcare.