Privacy

Last updated 10 September 2026 · PriorAuth

Draft, pending legal review. This document describes how the platform is built and what it actually does. It has not been reviewed by counsel and it is not a contract. Nothing in it should be relied on as a legal representation until it has been.

PriorAuth processes protected health information on behalf of medical practices, in order to obtain prior authorization from health plans. This page describes what the platform actually does with that information. It is written to be checkable against the software rather than to be reassuring.

We do not claim to be HIPAA compliant. Compliance is a determination made about a specific deployment, under a specific set of agreements, by people who have examined it - not a property a vendor can assert about its own product. What we can describe is the controls that are built, which is what follows. Ask for evidence of any of it.

Our role

The practice is the covered entity. PriorAuth acts as a Business Associate, and only under a signed Business Associate Agreement. We process PHI to carry out the practice's own treatment, payment and health care operations, and for no other purpose.

Where a practice reaches us through a channel partner - an EHR vendor, for example - the practice is still the tenant and still the covered entity. A partner relationship does not give that partner access to a practice's data, and it does not make the partner our customer instead of the practice. Each practice authorises its own connection and can revoke it without the partner's involvement.

What we process

Category	Examples	Why we hold it
Patient identifiers	name, date of birth, member ID, MRN	A prior authorization cannot be submitted without identifying the patient to the health plan.
Clinical detail	procedure codes, diagnosis codes, clinical notes supporting necessity	Health plans require it to decide the request.
Coverage	payer, plan, group, benefit responses	To determine whether a procedure requires authorization and where to send it.
Documents	attachments a practice or its systems send us	Supporting documentation the plan asks for.
Operational records	who did what, when, and why	The audit trail. It is not optional and it is not deletable.

Controls that are actually built

These are implemented and tested, not aspirations:

Practice isolation. Every record carries the practice it belongs to, and a read that does not name a practice is refused rather than returning everything. Cross-practice access requires an explicitly declared, audited reason.
Minimum necessary, by default. List views are masked at the server. The full identifiers are not sent to the browser at all, so they cannot be recovered from the page source, a screenshot, or a browser cache.
Purpose of use on every access. Each read of patient data is recorded with the person or agent that made it, the record, and the stated purpose.
No automated adverse determinations. Software does not communicate or act on a denial. A licensed human releases it.
No PHI in logs or traces. Redaction is applied by field name across the whole object, not by listing the fields somebody remembered.
No model training on your data. PHI is not used to train, fine-tune or improve any model, ours or a vendor's. Vendor agreements carry this term explicitly, or we do not use the vendor.
Untrusted content stays untrusted. Text that arrives from outside - a payer response, an attachment, a fax - is treated as data. Instructions inside it are inert.

Automated processing and AI

The platform uses software agents to prepare prior authorizations. Where that matters to you:

An agent may read a chart, ask a health plan whether a procedure needs authorization, draft a request and prepare documentation.
An agent never transmits an authorization, writes into a clinical record or communicates a decision without a named licensed human releasing that specific action.
Anything an agent writes into a chart says in the chart that it was automated. Not only in our audit trail - in the record itself, where a clinician reading it will see it.
An agent's permission to act is licensed by a test suite and expires. If the evidence goes stale the agent drops to proposing rather than acting.
No agent makes a clinical determination. Where the platform cannot establish something from a verified source, it says so and stops rather than estimating.

Sub-processors

We disclose PHI to a health plan or clearinghouse when submitting an authorization on the practice's behalf, and to infrastructure providers who host the service. Each is under a Business Associate Agreement. The current list is available to any customer on request, and we notify customers before adding one that will process PHI.

Retention and deletion

PHI is retained for as long as the practice's agreement requires and no longer. On offboarding, a practice's data is purged and a verification pass runs afterwards that reads the tenant back; it has to come back empty. The audit record of the offboarding itself is retained, because a deletion nobody can evidence is not a deletion.

Individuals exercise access, amendment and accounting-of-disclosures rights through their practice, which holds the relationship and the legal duty. We support the practice in responding.

Breach

If PHI is acquired, accessed, used or disclosed in a way not permitted, we notify the affected practice without unreasonable delay and within the period our agreement with them specifies. The practice determines its own notification obligations. We provide the audit detail needed to scope what happened.

What we do not do

We do not sell PHI or use it for advertising.
We do not use PHI for any purpose other than the practice's treatment, payment and operations.
We do not use analytics or tracking that would send patient data to a third party. There is no third-party script on the authenticated console at all - the content security policy blocks any outbound connection to another origin.
We do not permit one practice to see another's data, including in aggregate, unless it is de-identified and small groups are suppressed.

Contact

Privacy questions, or to report something that looks wrong: privacy@authprior.com. Security reports: security@authprior.com. We do not pursue researchers who report a vulnerability in good faith and give us a reasonable window to fix it.

The current deployment operates on synthetic data only. No real patient information has been processed by it. This page describes the controls that are in place for when that changes.