Prior Authorization

Prior Authorization Submission with Attachments and Clinical Q&A

Submit a complete prior authorization through a multi-payer, clearinghouse-style portal such as Availity Essentials: patient and provider details, supporting clinical documentation attached, the payer’s clinical questionnaire answered, and the authorization reference number captured back. One authorization per run, end to end.

This workflowClearinghouse-style payer portal
StatusAvailable today
AccessBrowser agent
AuthCustomer portal login

Overview

What this workflow does

A browser agent files the request the way a PA coordinator does: it signs in to the portal, opens a new authorization, and checks whether one is even required before anything is filed. If the payer’s flow shows no authorization is needed, the run stops and reports that determination with the portal’s exact wording. The cheapest prior auth is the one you never had to file.

When authorization is required, the agent completes the full request: member identity, requesting and rendering providers, facility and place of service, procedure and diagnosis codes, service dates, units, and urgency, all from the inputs you provide.

Step by step

How the submission actually runs

  1. 01The agent signs in to the portal, handling multi-factor authentication through an authenticator-app code.
  2. 02It opens a new authorization request, sets the payer, and enters the member and procedure. Then it runs the payer’s requirement check.
  3. 03If authorization is required, it fills the request form: providers, facility, service codes, dates, units, urgency.
  4. 04It attaches the supporting clinical documentation provided with the run. This is the step a standard EDI transaction can’t carry, and the reason this work still sits with a person today.
  5. 05It answers the payer’s clinical questionnaire using only the clinical notes provided. Anything it can’t answer from the inputs is left blank and reported, never guessed.
  6. 06It reviews the summary against the inputs. If anything is wrong or a required field is blank, it does not submit.
  7. 07It submits, waits for the confirmation screen, and captures the authorization reference number and status: pending, approved, in review, or pended.

Each run returns the reference number, the submission status, whether documentation was attached, and the exact label of any clinical question that couldn’t be answered from the inputs. That last list is your exception queue.

Structured output

What comes back

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.

structured output · json
{
"submission_status": "Pending",
"reference_number": "A2026•••••7",
"member_id": "W••••••04",
"procedure": "CPT 70553",
"attachment_uploaded": true,
"unanswered_clinical_questions": []
}

The fastest way through a payer questionnaire is to guess. The agent refuses.

Payer questionnaires ask medical-necessity questions, and the fastest way through them is to guess. This workflow refuses to. A required question it can’t answer from your clinical notes ends the run with that exact question reported back, so a person answers it once, with the chart open, instead of discovering a fabricated answer inside an approved authorization later. An automation tool that invents clinical answers to get past a questionnaire hasn’t saved you work; it has signed your name to a compliance problem.

The same discipline applies to every field: a required input that’s missing fails the run naming the field. Nothing is submitted on a guess.

At scale

One submission, or the whole PA queue

Each run files one authorization, which makes the unit of work auditable: one request in, one reference number out. At queue scale, runs execute in parallel across your payer mix, and the exceptions, unanswerable clinical questions, missing fields, unexpected portal states, land with your staff while the deterministic majority clears on its own.

Submission is one step in the prior authorization workflow library, alongside payer-portal submission and status, radiology and pharmacy PA, and high-volume submission. For the production version of this pattern, see the prior authorization case study. Upstream of the authorization, the eligibility and benefits check is what flags that a service needs one at all.

Human in the loop

What escalates to a human

Authorization runs carry PHI end to end, so they execute on HIPAA-compliant, SOC 2 Type II infrastructure under a BAA, each with its own execution log. Posture in full on the security page.

A clinical question the notes don’t answer.

The run stops with the exact question label. A person answers it with the chart, once.

A missing required field.

The run fails naming the field, before anything is filed.

An unexpected portal state.

A password-expiry prompt, a terms update, a survey modal: the agent reports it rather than clicking through.

A review-summary mismatch.

If the summary doesn’t match the inputs, it does not submit.

Questions

Frequently asked questions

Yes, before anything is filed. If the payer’s own flow shows no authorization is needed, the run ends there and reports that determination with the portal’s exact wording, which is a result worth having on record, not a failure.

Submission is one workflow in the prior authorization workflow library. Every authorization waiting on manual portal work is a delayed service and an avoidable denial risk.

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.