Submit a prior authorization on a payer’s own provider portal, such as the UnitedHealthcare Provider Portal, and capture the authorization reference number and status the payer shows back. For the payers whose authorizations live only behind their own front door.
Overview
Some payers put prior authorization behind their own provider portal, with their own login, their own request tool, and their own status screens. This workflow runs that flow end to end: the agent signs in, checks whether an authorization is even required for the member and procedure, and if it is, files the complete request and captures what the payer says back, the reference number and the status.
If the payer’s own check shows no authorization is required, the run stops there and reports that determination with the portal’s exact wording. That’s not a failed run; it’s a submission you didn’t have to make, on record.
Step by step
Each run returns the reference number, the status, and the exact label of anything it couldn’t answer. One authorization per run, every run logged.
Structured output
Every run ends as a record like this in your system, not a portal screenshot someone transcribes. This is the part your team stops doing by hand.
{ "determination": "auth_not_required", "portal_message": "No authorization is required for these procedure codes.", "member_id": "W••••••04", "procedures": [ "CPT 99213", "CPT 20610" ], "checked_at": "2026-07-16T14:02:11Z"}A prior auth that was “definitely submitted” but has no reference number attached is a follow-up phone call waiting to happen: someone re-searching the portal, re-verifying the member, holding for the payer. This workflow treats the payer’s reference number and displayed status as the point of the exercise. Every submission ends with both captured, so follow-up starts from evidence instead of from memory, and the status conversation with the payer, if one is ever needed, starts with a number they recognize.
At scale
Each run files one request, which keeps the unit of work auditable. At queue scale, runs execute in parallel across the payers whose auths live on their own portals, alongside the clearinghouse-style submission workflow covering the multi-payer portals, and staff work the exceptions from both. Submission and status are part of the prior authorization workflow library; for the production pattern, see the prior authorization case study. The same discipline extends across the rest of the family: radiology PA on imaging-review portals, drug PA on ePA portals, high-volume queues, and the long tail of IPA portals.
Human in the loop
Runs handle member and clinical data on HIPAA-compliant, SOC 2 Type II infrastructure under a BAA, with an audit trail per authorization. Details on the security page.
A missing required field.
The run fails naming the field, before anything is filed.
A clinical question the notes don’t answer.
Left blank and reported, or if it blocks submission, the run stops naming the exact question.
A member or procedure the portal doesn’t recognize.
Reported with the portal’s wording, rather than forced through.
A review-summary mismatch.
If the summary doesn’t match the inputs, it does not submit.
Questions
Payer-portal submission is one workflow in the prior authorization workflow library. Every authorization stuck in a manual portal queue is a service that can’t be scheduled and revenue that can’t be booked.
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.