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.
Go-live in as little as 30 minBrowser agentCustomer portal login
We map your process, volume, and exception paths, then recommend a practical first scope.
Building internally? Read the docs →
Overview
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.
How Asteroid runs this workflow
A PA case with its source notes arrives, Asteroid completes the payer's forms and questionnaire from that evidence alone, and the confirmation lands back in your queue, and any question the notes can't answer stops for your staff instead of being guessed.
How it actually runs
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.
A PA case with its source notes and supporting documents is ready
Confirmation back in your PA queue
The authorization reference number and status (pending, approved, in review, or pended) write back to your work queue with the attachment list.
Unanswerable clinical question: The run stops with the payer's exact question reported; your clinical staff answer it once, with the chart open. Clinical judgment never automates.
Closing the loop
Nobody on your team reads this JSON. Your system does. Each run delivers its record wherever the work already lives, and the loop closes on its own: requests in, records back, no one in the middle.
{ "submission_status": "Pending", "reference_number": "A2026•••••7", "member_id": "W••••••04", "procedure": "CPT 70553", "attachment_uploaded": true, "unanswered_clinical_questions": []}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
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
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
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.
We use cookies for analytics and advertising. You can opt out or manage your choices anytime.