Prior authorization packets, drafted for your review.
Prior Auth turns a planned service and your clinical notes into a payer-aware packet for dental, aesthetics and physiotherapy practices. Your team reviews, edits, locks and submits it. Nothing is sent automatically.
Already invited? Sign in.
From planned service to submitted packet
The same five steps for every request, whatever the payer. Each one is a screen you can see and a decision someone on your team makes.
1.Start a request
Pick the patient, describe the planned service with its procedure and diagnosis codes, and choose the payer. Your practice's notes about that payer's requirements appear alongside.
2.Add clinical context
Paste chart notes, fill in the structured findings for your specialty, and attach supporting files for the record.
3.Get a draft packet
Prior Auth writes a clinical justification, a supporting-documentation summary and a request letter, and lists what the payer may expect that you haven't provided.
4.Review, edit and lock
Your team edits every section, marks it ready for review and locks it. A locked packet can't change, and it exports as a tagged PDF on your practice letterhead.
5.Submit, record, appeal
You send the PDF through the payer's own channel, then record the submission and the decision. If the payer denies or only partly approves, an appeal is drafted from the original packet, the stated reason and any new notes.
What stays in human hands
Prior Auth drafts. It doesn't decide, certify or send. Prior authorization is a clinical and administrative judgment, and it stays with your staff.
- A person picks the patient, the service and the payer.
- Every draft section is editable, and nothing is final until someone locks it.
- Locking is deliberate, asks for confirmation, and can't be undone.
- Nothing is ever sent to a payer by Prior Auth. You download the PDF and submit it yourself.
- The payer's decision is recorded by a person, in their words.
- An appeal is a draft too: reviewed, edited and locked before it goes out.
Privacy and safety, stated plainly
What the product does today to protect patient information, and where its limits are.
Identifiers removed before drafting
Patient name, date of birth, member ID, the payer reference and the provider's name are replaced with placeholders before any text goes to the AI model. Dates become an age band or vague timing. The real values are put back locally in your copy.
Prompts and answers aren't kept
We store that a draft was made, how many tokens it used and which prompt version produced it. We don't store the prompt or the model's raw answer.
Each practice is separate
Data is isolated per practice in the database itself, not just in the app. A user from one practice can't read another's requests, even through a bug in a page.
Invite-only, with an audit trail
There is no public sign-up: owners and admins invite people by email. Locks, submissions, exports, generations and member changes are written to an audit log that records ids, not patient details.
Limits you can see
Each practice has a monthly AI budget and plan limits, checked before a draft is generated. If a limit is reached the draft is not made, and the message says why.
Built with privacy in mind, not certified
This is not a HIPAA-compliance claim. There are no business associate agreements in place yet, so it must not be used with real patient information. See the status section below.
De-identification works from the patient record and recognizable patterns. A name typed into a note with no label and no link to the patient can slip through, so staff are asked not to type names into notes. Read the details.
Four roles, one practice
Access follows the role, and the role is decided on the server, never by the browser.
- Owner
- Everything an admin can do, plus inviting and removing other owners. Every practice has at least one.
- Admin
- Invites and removes team members, sees plan, trial and usage under Billing.
- Provider
- Creates and works requests: context, drafts, edits, locking, outcomes and appeals.
- Staff
- The same day-to-day access as providers. Staff can't see billing or manage the team.
Accounts are invite-only. How the team works.
Where things stand
Prior Auth is in early access. This is what works now and what doesn't, so you can judge whether it's useful to you yet.
Works today
- Dental, aesthetics and physiotherapy have their own code lists and structured findings; other practice types use a generic set.
- The new-request flow, packet drafting, editing, locking and PDF export.
- Recording submission and outcomes, and appeal drafts with as many rounds as you need.
- Invites, four roles, audit trail, monthly AI budget and plan limits.
- Light and dark mode, and screens built for keyboard use.
Not yet
- Real patient data. It runs on synthetic data only, and no business associate agreements are in place.
- Billing. Stripe isn't connected: there is a trial, placeholder plans and no pricing. Plan changes are made by us, not in the app.
- Reading uploaded files. They are stored and can be downloaded, but the AI doesn't read them yet; only pasted notes and structured findings are used.
- Languages other than English.
- A production run of the AI gateway. Drafting has been tested end to end with a stand-in model; the live model path hasn't been exercised in production.
Want to try it on synthetic data?
Early access is by invitation. Tell us your specialty and the payers that give you the most trouble, and we'll set up a practice for you to try. We'll say honestly whether it fits yet.