Overview
priorauth.in prepares prior authorization requests for medical practices and submits them to health plans over X12 278. Software does the assembly; a licensed human releases anything consequential.
#The one rule
The agent never sends
No authorization reaches a payer, and nothing reaches a clinical record, without a named licensed human releasing that specific action. There is no autonomy level that removes this, no configuration a practice can change, and no customer who gets it turned off.
Everything else in this documentation is downstream of that sentence. The gateway exists to enforce it, the autonomy levels exist to describe what is permitted below it, and the eval harness exists to prove it still holds after a change.
#What the platform actually does
- Finds the workReads scheduled surgeries and in-office procedures out of the practice EHR, before anyone has thought to ask about them. This is the trigger for everything else.
- Asks the payerRather than consulting a code list we curated, it asks the health plan whether this member's plan requires authorization for this procedure, through the eligibility rail. The plan answers; the platform does not guess.
- Assembles the requestPulls the order, the diagnoses and the coverage, reconciles that the source systems agree about who the patient is, and builds the 278.
- StopsA licensed human reviews and releases. The release is single-use and bound to the exact content approved.
- Chases the answerDurable, leased polling that tightens as the CMS decision window closes. A payer taking four days is still being chased on day four.
- Writes backPuts the authorization number on the appointment and the payer status in the chart - both released by a human, both marked in the record itself as automated.
#What it will not do
- It does not practise medicine. No diagnosis, no treatment recommendation, no coverage determination.
- It does not guess a payer rule. Where no verified source answers, it abstains, says so, and raises a task. An unanswered question never becomes a silent clearance.
- It does not claim to be HIPAA compliant. Compliance is a determination made about a deployment by people who examined it, not a property a vendor asserts about itself. What is documented here is the controls that exist.
- It does not train on customer data. PHI is not used to train, tune or improve any model.
#How to read these docs
Integrating with us
You send a task, we get it authorized. Start here if you are building against us.
Architecture
Every layer and where the boundaries sit.
The gateway
One door, nine checks, and why nothing routes around it.
Authorization lifecycle
The whole flow end to end with every gate marked.
A2A
Connecting an external agent, and where the human gate surfaces.
External APIs
Availity and Veradigm, including the traps.
Tool registry
Every callable capability, generated from the code.
Synthetic data
The deployment these docs describe runs on synthetic data and is not in clinical use. Every patient name, member id and payer rule in the system is invented, and the knowledge base is explicitly marked as such so it cannot be served as an answer.