The Discovery Phase Explained: What US Payer and Provider Group Executives Get Before a Line of a Custom Prior Authorization Platform Is Written

This article is part of our series on Custom Prior Authorization Automation Platform Development for US Payers and Provider Groups: Building a Rules Engine, Attachment and Status Tracking System

Find Out Where the Days Go

Before any platform conversation, and before a prior authorization discovery phase can produce anything useful, take a hundred requests and account for every day between the order and the determination.

Days before submission, while documentation was gathered. Days in transit or in a queue. Days to first touch by a reviewer. Days pended awaiting information. Days from the provider receiving the pend to responding. Days from response to determination.

Most organizations find the distribution surprises them, and almost all find that one or two stages dominate.

A payer discovering that most elapsed time is pend-response time has a precision problem in how it asks for things. One discovering most time is pre-review queue has a capacity problem. A provider discovering most time is pre-submission has a documentation problem.

Those are three different projects and only some of them are software.

The exercise takes a few days and uses records you already have, which is why a prior authorization discovery phase starts here rather than with a feature list. Discovery is the decision layer of the full custom software development guide to custom authorization platform development, whose working surfaces are web application development for reviewers and coordinators.

The Second Exercise: Read Your Pends and Denials

Pull a hundred pend notices and a hundred denial notices and read what they actually say.

For pends: does the notice identify precisely what is needed, or does it request additional clinical information. The second phrasing produces a resubmission of everything and a second pend, and it is extremely common.

For denials: does the notice identify which criterion was not met and why, or does it carry a code and a generic phrase. If somebody receiving it could not tell whether to resubmit with a document or to appeal a clinical judgment, it has not communicated.

Then count how many denials were overturned on appeal or resolved by supplying one additional document.

That last figure is the clearest measure of how much of the denial volume was a documentation failure rather than a clinical disagreement, and it is usually higher than anybody expects.

Both exercises work from either side and both are actionable immediately, since clearer pends and denials cost nothing to write.

What the Sprint Should Establish

The Delay Distribution

The day accounting from the first exercise, broken down by service category, payer or line of business, and urgency. Identifies which project you actually have and whether software addresses it.

The Regulatory Position

Whether you are an impacted payer under the federal requirements and on what timeline, which lines of business sit under which appeal framework, which state requirements apply to which plans, and what exemption programs you operate or are subject to. Established with counsel rather than assumed.

The Policy Inventory

On the payer side, how many policies exist, in what form, how consistently structured, and who would express them as configuration. The largest and least estimated workstream. On the provider side, the equivalent is how payer requirements are currently known, which is usually somebody’s spreadsheet.

The Communication Audit

The pend and denial specificity findings, with the overturn and one-document-resolution rates quantified. Frequently actionable this month regardless of the software decision.

The Connectivity Map

Payers and their submission paths on the provider side, or trading partners and clearinghouses on the payer side, with what each supports today and what the newer guides would require. Where staff track those submissions away from a workstation, custom mobile app development is part of the same inventory. 

The obligations a sprint must establish are set out in The CMS Interoperability and Prior Authorization Final Rule Timelines, HIPAA Transaction Standards, State Turnaround and Gold Carding Laws and ERISA Appeal Rights.

What the Executive Team Receives

A delay distribution analysis identifying which stage dominates and therefore which project is worth funding.

A regulatory position covering federal scope and timeline, appeal frameworks by line of business, applicable state requirements and exemption programs.

A policy inventory with the authoring and migration effort estimated, which is the workstream most often discovered late.

A communication audit with pend and denial specificity assessed and the overturn and one-document resolution rates quantified.

A connectivity map with current paths and what the newer implementation guides would involve.

A metrics baseline, since public reporting obligations and gold carding measurement both require knowing current figures.

A platform evaluation on the appropriate side, tested on connectivity breadth and regulatory tracking rather than feature lists.

A defined first release with the determination and outcome positions written in as non-negotiable.

And a costed comparison of at least three paths, adopt a platform, adopt and integrate, and build, with policy authoring and regulatory change shown as standing lines in the last two. The budget a sprint protects is detailed in the Custom Prior Authorization Platform Budget Guide.

Reading the Recommendation

Fix the communication when the audit shows pends and denials are vague, since clearer notices reduce resubmission volume at close to zero cost and no platform compensates for an unclear request for information.

Adopt a platform when connectivity breadth or a maintained payer requirement library is the gap, which for most provider organizations it is and which scales terribly in-house.

Adopt and integrate when the gap is connection into your own clinical and administrative systems.

Build when you are a payer for whom this is core infrastructure with federal obligations attached, a delegated utilization management vendor, or an organization for whom authorization is the product.

Fix capacity when the delay analysis shows most time is queue time before first review, which is a staffing finding rather than a software one.

One consideration applies whichever path is chosen: if you are an impacted payer, the federal timeline is running regardless of this decision and the gap assessment is urgent independently.

A consultant who recommends rewriting your pend notices before building anything has read the data correctly.

What a Consultant Should Know About This Process

Four questions establish whether a consultant has worked in authorization.

Ask why the standard transaction has not solved this. A good answer names the gap between the envelope and the clinical argument immediately. Anyone describing adoption as the obstacle has not understood the problem.

Ask where the rules engine stops. The right answer is at clinical judgment, with administrative auto-approval against published objective criteria described as a distinct and legitimate capability. Anyone offering automated determination as a feature should be pressed hard on exactly what it decides.

Ask how the platform handles a pend. A good answer specifies that the pend names precisely what is needed and raises the clock question unprompted. Anyone treating pends as a queue management tool has described something that harms patients.

And ask about fax. A consultant who says it needs building properly rather than calling it legacy understands the channel most requests still travel.

Red Flags in the Conversation

A sprint offered free and contingent on winning the build. A fixed price before the policy inventory exists. Federal requirement scope assumed rather than established. Policy authoring absent from the estimate. Regulatory change missing from running costs. No platform comparison. Fax dismissed.

And the ones that should end the conversation: automated medical necessity determination presented as a feature, denial rate improvement offered as a benefit, approval likelihood scoring to shape submissions, documentation generation that produces clinical assertions, pend or clock management described as an operational lever, and generic denial reasons treated as adequate.

The strongest positive signal is a partner who asks to read a hundred of your pend notices.

Conclusion

Account for every day between order and determination before deciding anything, since the distribution tells you which project you have and only some of them are software.

Read a hundred pends and denials, because vague notices are the cheapest thing to fix and the most expensive to leave.

Inventory your policies, as that workstream is large and usually discovered late. And if you are an impacted payer, the timeline is running regardless. Apply that prior authorization discovery phase standard to every partner, including the software companies in the United States who would like to build it.

If you are weighing a custom platform, accounting for the days on a hundred recent requests is the few days to spend before any vendor conversation.

FAQ