Prior Authorization

Prior Authorization on Utilization-Management Portals

Submit and track prior authorizations on the utilization-management portals payers delegate them to. When the payer’s answer is “that service goes through our UM vendor,” the authorization leaves the payer’s portal entirely, and this is the workflow that follows it there.

Go-live in as little as 30 minBrowser agentCustomer portal login

See it run on your systems.

We map your process, volume, and exception paths, then recommend a practical first scope.

Building internally? Read the docs →

How Asteroid runs this workflow

Following the authorization onto the UM vendor's own system

A PA request the payer has delegated arrives, Asteroid submits it on the UM vendor's portal and re-checks the pend on schedule, and a normalized submission-and-status record lands back in your queue. A peer-to-peer request or unanswerable question goes to a person immediately.

UM vendor portals

How it actually runs

  1. 01Sign in to the UM portal with credentials from an agent profile.
  2. 02Enter the member, provider, and service details, from your inputs only. A missing required field is a named failure, never a guess.
  3. 03Attach clinical documentation where the portal takes it. A question the inputs don’t answer is reported by name, never invented.
  4. 04Capture the tracking number and review status.
  5. 05Re-check pended authorizations on schedule and report each status change with the portal’s exact wording.

A peer-to-peer review request, a demand for more information, or anything the portal disputes goes to a person immediately, with the reviewer’s actual ask attached.

A PA request is ready for a utilization-management platform

  1. A normalized record in your PA queue

    The tracking number, review status, portal messages in their exact wording, and the evidence used land as one normalized submission-and-status record, with pends re-checked on schedule.

No confident match or open question: The case returns with the reviewer's actual ask attached (a peer-to-peer request, a demand for more information, or a question the inputs don't cover), and clinical staff resolve it once.

“Pending clinical review” needs a schedule, not a watcher.

UM portals are where authorizations sit the longest, because clinical review happens there, and “pending” is where scheduling quietly dies. Staff re-checking pended auths is a person being used as a polling loop. Run as agents, every pended authorization gets re-checked on cadence, and your team gets the changes, not the checking.

At scale

What runs today

These UM-portal agents are in the catalogue pipeline. The same submission discipline already runs in production on clearinghouse-style portals and payers’ own provider portals; see the prior authorization workflow library for the full set. If delegated services dominate your PA queue, scoping a build against your UM mix is the fastest path to running.

Questions

Frequently asked questions

UM-portal agents are built against your specific UM vendor mix, so the forms, review states, and re-check cadence are scoped to each portal. Your side stays familiar: inputs are the member, provider, and service details you already collect, credentials live in an agent profile you control, and results (tracking number, review status, every status change in the portal's exact wording) return in your output format. Pended-auth re-check schedules and escalation routing follow your SOP. Scoping against your UM mix is where those rules get set.

Disclaimer

Third-party names, including government agencies and registries, are used only to identify systems commonly involved in healthcare operations workflows. Asteroid is not affiliated with, endorsed by, sponsored by, or certified by those third parties unless expressly stated. Workflow availability depends on customer authorization, account permissions, configuration, and applicable system terms.