priorauth.indocs

Going live

Every integration starts on synthetic data and widens deliberately. This is not a formality - it is where the duplicate-task and timeout behaviours get caught.

#Sandbox

The sandbox behaves like production, including the parts that are inconvenient. It holds tasks at the release gate, returns denials, returns unknown for payers that do not populate an answer, and rate limits you. An integration tested only against the happy path is an integration that has not been tested.

To exerciseUse
A task held for releaseAny prior_auth_intake. It always holds.
A denialProcedure 70553 with payer BCBSF.
An unknown authorization answerPayer UHC - it does not populate the indicator.
A network-dependent answerProcedure 29881 with payer BCBSF.
An identity mismatchSend a member id and a patient name that do not match.
A payer outagePayer DOWN.

#Before we connect a real practice

  1. Your handling of input-required is reviewed. This is the one we always check.
  2. You send an Idempotency-Key on every message/send.
  3. You do not time out a task in under an hour.
  4. You surface denials to a person rather than retrying them.
  5. You handle practice_not_connected as a customer decision, not an outage.
  6. Your BAA is executed and your sub-processors are named.

#Canary

The first practices connect with a lower autonomy ceiling and are reviewed by a person on both sides for the first weeks. Widening is a decision, not a schedule.

A practice can decline you individually
Being live does not mean every practice on the platform is reachable. Each one authorises you separately and can revoke without telling us first. Build for a practice list that changes.

#Your obligations once live

  • Do not store more patient data than your feature needs, and do not keep it longer than your agreement allows.
  • Do not use anything we return to train a model.
  • Report a suspected breach to us and to the practice without delay.
  • Keep your credentials in a secret manager, not in configuration.

Security contact: security@priorauth.in. We do not pursue researchers who report a vulnerability in good faith.