Skip to content

PriorAuth Copilot

Start a pilot

Security & architecture · what’s true today

Everything on this page is current state, not roadmap.

Where something isn’t done, it says so and names the remaining step. Your security review can read this page before anyone signs anything — and hold us to it afterwards.

Security contact →

dave@priorauthcopilot.com

One deployment per health system

Your instance is entirely separate

Its own database, its own application instance, its own infrastructure. No shared infrastructure, and no path by which data could comingle across customers.

The AI-vendor boundary

Chart data never goes to an AI vendor

No AI vendor call happens from inside an open patient case, today. The AI-assisted routes that exist are admin/setup-time only and touch public payer-policy text — never chart or case data — and are screened against patient-identifying fields regardless.

01

PHI encryption at rest

Every patient-identifying field — labels, outcome notes, payer notes, intake answers, uploaded contracts — is encrypted with AES-256-GCM using a fresh random key per write, layered on top of cloud-disk encryption.

Application-level · verifiable per field
02

Access control

Individual, auditable credentials over session-based, CSRF-protected connections. Role-based access separates reviewer from administrator, and repeated failed sign-ins lock an account automatically.

No shared logins
03

Audit logging

Every chart access, document generation and case action is written to a durable audit trail — available to your own security and compliance teams, not only to us.

Yours to read
04

Data retention

Records persist according to your retention policy — we never unilaterally purge data your compliance program needs. One exception: self-attested intake answers auto-expire after 180 days.

Your policy, not ours
05

Epic integration

A standards-based SMART-on-FHIR OAuth2 connection to your existing Epic instance, built on the official SMART Health IT client library rather than a homegrown integration. Read-only: no changes to your Epic build, configuration or change-control process.

Read-only
What’s ahead, honestly

The two things we can’t claim yet.

A vendor who names its own gaps is easier to diligence than one who doesn’t have any.

Production validation

Validated against Epic’s public sandbox today

Validation inside your own Epic environment — your Hyperspace instance, real SMART scopes, your BAA — happens during onboarding, before go-live. That is the named remaining step, not a hidden gap.

SOC 2

Not certified — and we won’t imply it

Certification is on the roadmap, scoped to a signed engagement. The product is built to refuse to display the claim until it is real. Readiness, measured honestly, is below.

SOC 2 readiness, ahead of the audit

27 of 32 applicable controls already have real evidence.

The other five have real written policies too — they are waiting on a real event to prove them against, not on a document.

Already strong

Encrypted at rest. AES-256-GCM on every PHI field, a fresh key per write.

Hardened, not assumed. Session security, CSRF protection, account lockout, and a multi-round SSRF fix with real tests behind it.

Found and fixed

A real gap, closed. Every action on a case was already logged — opening one wasn’t. It is now.

Verified, not assumed. Caught by mapping our own evidence against the real audit checklist rather than guessing at it.

Newly documented

Incident response, data retention, a vendor register, a code of conduct, a training standard, a fraud-risk assessment, a trust page and a disaster-recovery plan — all written this pass.

Followed through. Both founders acknowledged the code of conduct, the security contact is live, and the disaster-recovery restore was rehearsed end to end in about 87 seconds.

What’s actually left — five controlsEach already has a written policy. None needs another document.
Incident responseWritten and ready — untested against a real incident
Vendor risk reviewsRegister exists — no annual review cycle run yet
Training standardOnboarding checklist ready — nobody has been onboarded yet
Fraud-risk reviewFirst pass done — not yet a recurring process

Architecture

Live today, built but not connected, or standards-ready.

Three states, labeled per component. Nothing in the first column is aspirational and nothing in the third is claimed as working.

The deployment

Frontend — React applicationHosted on Azure Static Web Apps
Application server — Node / ExpressIts own Azure Container App, per customer
Postgres databasePatient-identifying fields encrypted per field at rest
Live today
Epic FHIRSMART-on-FHIR OAuth2, read-only, against your own Epic instance
Payer policy sourcesPublic policy pages, crawled and version-tracked
Citation matchingLocal, server-cached lookup against your indexed payer policies — no AI vendor call in this path
Denial-reason captureTyped by a reviewer or read straight off the letter — real OCR on scanned and faxed pages, not inferred from a remittance code
Built · not yet connectedClearinghouse

Eligibility, status and e-submission. Vendor-agnostic and ready to wire up — needs one signed vendor account and zero code changes.

Built · not yet connectedFax gateway

Same story: built and tested, waiting on a signed vendor account to go live.

Standards-readyHL7 Da Vinci — PAS, CRD, DTR

Built to spec, and independently conformance-tested against Inferno — HL7’s own reference validator, not a self-report. DTR and PAS pass in full; CRD’s hook authentication passes too, with one named gap left (a payer-facing FHIR endpoint for coverage-rule prefetch). No payer has a live production endpoint to connect any of this to yet, industry-wide — a CMS timeline gap rather than ours.

Trust artifacts

The documents your review will ask for, and how to get each one.

Nothing here requires a sales conversation first. Ask for any of it and you’ll have it the same day.

Business Associate AgreementRequest →

Signed before any PHI moves — including before sandbox work that touches your environment.

Subprocessor registerRequest →

Microsoft Azure for hosting and database; one LLM vendor for admin/setup-time payer-policy research only, never from inside an open patient case. No other party receives your data.

Vulnerability reportsReport →

Send anything you find to the security contact. Our incident-response policy is written and has not yet been exercised against a real incident — stated above, and stated here too.

Disaster recoveryRehearsed · ~87s restore

Plan written this pass and rehearsed end to end, not left as a paragraph in a policy binder.

Audit-log accessAvailable to your team

Chart access, document generation and case actions are readable by your own compliance team, not filtered through us.

Deletion and exportOn your instruction

Retention follows your policy. Deletion or return of data happens when you instruct it — never unilaterally on our side.

Send this page to your security review before you talk to us.

If something here doesn’t satisfy your CISO, we would rather hear it now than at contract stage.

Ask a security question →Start a pilot
RecoupAR · PriorAuth Copilot
Payer coverageSamplesRecovery model