PriorAuthdocs

Overview

PriorAuth 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

  1. Finds the work
    Reads 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.
  2. Asks the payer
    Rather 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.
  3. Assembles the request
    Pulls the order, the diagnoses and the coverage, reconciles that the source systems agree about who the patient is, and builds the 278.
  4. Stops
    A licensed human reviews and releases. The release is single-use and bound to the exact content approved.
  5. Chases the answer
    Durable, leased polling that tightens as the CMS decision window closes. A payer taking four days is still being chased on day four.
  6. Writes back
    Puts 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

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.