PriorAuthdocs

Integrations

Two connections make this platform work for your practice: your clearinghouse, so authorizations can reach payers under your own trading relationship, and your practice systems, so we can see the work and write the answer back.

#You write no code

Neither connection is a development project. You enable our application in systems you already own, create a service account for it, and paste a handful of values into Settings → Connections. We do the calling; nothing is ever pushed to us.

#The credentials stay yours

WhatWhy it is yours and not ours
Clearinghouse entitlementYour trading relationship with payers, your audit trail at the payer, and revoking it needs nothing from us.
EHR service accountYour patient record. You decide what our application may see, and you can disable it in your own console without asking us.
Write permissionHeld separately from read. Connecting is not consent to write into your chart, and we refuse chart writes until you turn that on deliberately.
One thing we do not ask you for
An AI model account. The platform holds one model credential under one agreement, so no practice has to do vendor procurement to use the product. There is no per-practice model key to buy, manage, or rotate.

#What happens to a value you paste in

  1. It is validated before it is stored
    We authenticate against the vendor with exactly the values you gave. If they are wrong, nothing is stored at all, and you are told which part failed. A wrong credential that is stored anyway fails later, at a real authorization, in front of a patient appointment.
  2. Secrets are encrypted and never shown again
    Passwords and client secrets go to a managed secret store. They are never returned by any screen, never written to a log, and never included in an audit record. You see a short fingerprint instead, so you can match it against your own vendor console without either of us handling the value.
  3. Non-secret values stay readable
    Endpoints, client ids and application names are shown in full, because you have to be able to check your own setup.
  4. Revoking is immediate and complete
    A revoked connection stops being handed out before the store is even read. It is not merely marked revoked while still working.

#Your data does not mix with anyone else's

Each practice's connection is resolved from that practice's own record at the moment of every vendor call. A practice with no connection gets no vendor access at all: the platform refuses rather than falling back to a shared credential. That refusal is deliberate, and there is a test that fails if a shared credential is ever reintroduced.

#After both are connected

  • Scheduled procedures start appearing without anyone entering them.
  • You can mint API keys for your own integrations. Those are gated on a working connection, so a key cannot be issued against a rail that does not function.
  • Nothing reaches a payer and nothing reaches your chart without a named person releasing that exact action. Connecting does not change that, at any autonomy level.