Reference
Privacy and de-identification
Prior Auth is built with privacy in mind. This page describes what it does, and where that stops. It is a description of how the software works, not a compliance certification.
Status: synthetic data only
What is removed before drafting
Before any text goes to the AI model, identifiers are replaced with placeholders such as [PATIENT]. After the draft returns, the real values are put back in your copy, on your side. The model never sees them.
| Removed | Becomes |
|---|---|
| The patient's name, in any order, case or possessive form, with or without accents | [PATIENT] |
| Date of birth, in any common format | An age band (ages 90 and over are grouped) |
| Member ID, with any spacing or punctuation | [MEMBER_ID] |
| The payer reference number | [REFERENCE] |
| The provider's name | [PROVIDER] |
| Other dates in notes | [DATE], or only the year when a month and year are given |
| Your planned service date | Vague timing such as “about 3 weeks from now” |
| Emails, phone numbers, Social Security numbers, web addresses, labelled ID numbers, street addresses | Removed |
| Names with a title (“Dr. …”), a label (“Name: …”), or a relative relationship (“her mother, …”) | Removed |
A second check
The finished prompt is checked again for any known identifier. If one survives, nothing is sent, the attempt fails and you are told to check the notes for names or numbers.
What staff must not type
De-identification is based on the patient record and on patterns. It can't recognise a name that has no label and no link to the patient, such as a neighbour called Priya in the middle of a sentence.
- Don't type the names of anyone in notes, labels or the service description. Write “the patient” or “the patient's spouse”.
- Don't paste scans or letters with a full letterhead block, signature block or address into a note.
- Remove names from the payer's denial text when you can, though appeals scrub it again.
- Don't put identifiers in file names or labels. File names are never sent, but they are visible to your team.
- Put identifiers only where they belong: in the patient record fields.
What is never sent
- The contents or names of uploaded files. They aren't read.
- Anything your practice hasn't entered in the request: other patients, other practices, billing details.
- Your account email or password.
What we store
- Your requests, notes, packets and files, kept per practice. The database itself prevents one practice from reading another's data.
- For each draft attempt: that it happened, its outcome, token counts and the prompt version. Not the prompt, and not the model's raw answer. Only the finished packet you can see and edit is saved.
- An audit log of locks, status changes, exports, generations and member changes. It records identifiers of records, not patient details.
The people who operate the service can access the underlying database for support during early access. It is one of the reasons it must stay on synthetic data until agreements and further controls are in place.
Access and accounts
Accounts are invite-only, and roles limit who can manage the team or see billing (Team and roles). Emailed links need a deliberate click, so mail scanners can't use them up. Signing out reloads the page fully so patient data is cleared from the browser.