Security & trust — how Provira handles your data

Three things to know.

The core of Provira needs no PHI at all. Scrubbing, denial learning, and benchmarking run on codes and payer data. A practice can get the central value with no protected health information involved.
PHI features are opt-in and gated in the product. Eligibility and COB look-ups need a member ID and date of birth. If you don't want them, they aren't activated — and no PHI is handled.
The shared network never sees a patient. Only de-identified, payer-level statistics leave your workspace.

HIPAA & BAA

PHI stays server-side, under a signed BAA.

Where Provira handles protected health information, it does so as a Business Associate under a signed Business Associate Agreement, inside your practice's own isolated space. PHI is encrypted, and it never crosses to another practice.

PHI and credentials never reach the browser. Nothing sensitive is sent to the client. It's a design invariant, checked in review, not a runtime setting.
The credentialing check keys provider identifiers only. NPI, TIN, and taxonomy — never a portal password.
Tenant isolation. Your workspace derives from your verified identity server-side, not from a request header — so one practice's data isn't reachable from another's session.

The de-identified network

Two planes: your work, and the shared learning.

Working plane

Where the real work happens

Denials, follow-up, eligibility, patient outreach. Any PHI lives here, inside your practice's own walled space, encrypted, under the BAA. Nothing on this plane crosses to another practice.

Learning plane

The shared network

Only de-identified, payer-level statistics reach it — the shape of a rule, like "this payer denies this code without this modifier." No patient. No claim detail. No identifiers.

The value is pooled. The data never is.

Auditable & coder-gated

Deterministic detection. AI explains, never edits.

Findings come from an auditable rules engine you can trace to its source, not from a model's opinion. AI has exactly one job here: putting a finding in plain language and drafting appeal text. It does not invent an edit, apply one, or decide what's correct — and everything it drafts is reviewed by a person before it goes anywhere.

The human gate. Every learned rule is reviewed and promoted by a certified coder before it can act. Until they approve it, a learned rule does not act on your claims, and it never displaces a national edit.
The coder is yours, or ours if you'd rather. By default the promoting coder is your own credentialed coder — the review happens inside your workspace, on your payers. The control isn't "trust the vendor's coder."
Network rules are gated the same way. Nothing learned from another practice acts on your claims until your own coder approves it.
The national rulebook is read-only. NCCI, MUE, and MPFS content is Provira-managed and centrally maintained. No practice can edit it — which is part of why the shared network can be trusted.

Where we are today — the honest part.

Provira's production environment currently runs on synthetic data; no real patient information has been processed. The engine underneath is built and tested. What's still in flight is the last round of infrastructure hardening and the Business Associate Agreements, both of which land before our first live tenant.

The controls below are marked for what's in place now versus what's being completed. We'll walk you through the current checklist on request.

The controls, concretely.

In place today

Minimum necessary — PHI pulled only where a task needs it, used only for that check, never sent to the learning network.
Passwords and tokens hashed and signed; never logged in plaintext.
PHI and credentials never reach the browser — enforced as a design invariant, checked in code review.
Tenant isolation from your verified identity server-side, never a request header.
Secrets management — credentials in a managed secret store, never in code or plain configuration.
Scoped service accounts — the runtime has only the permissions it needs. No owner or editor rights.
Encryption at rest, with application-to-database traffic on an encrypted path.
Application audit log — activity recorded in the application's own audit trail.

Being completed before we process PHI

TLS enforced on every connection path, closing the remaining non-TLS route to the database.
Database-level audit logging, so PHI access is traceable at the data layer as well as the application layer.
Scheduled secret rotation and a formal password policy.
Verified automated backups with point-in-time recovery, documented in our contingency plan.
A formalized periodic access-review process on top of the role-based access control already in place.
Restricted network ingress, so the API is reachable only through a controlled path.

Why we show you both lists: you're going to ask for our security posture in diligence anyway. You may as well have the accurate version now.

Compliance status

Where we are, and where we aren't.

We'd rather tell you this plainly than have you find it out in diligence.

SOC 2. Provira is not SOC 2 certified. SOC 2 is on our roadmap and the underlying control work is underway. We'll say certified when we are certified, and not before.
HIPAA. Provira is built to operate as a Business Associate. Our compliance program is in progress: the documented security risk analysis, written policies and procedures, Security and Privacy Officer designations, and workforce training are being completed ahead of our first PHI engagement.
Subprocessors. We maintain a current subprocessor register, and Business Associate Agreements with each are being executed before any PHI is processed. We'll share the register and the status of each agreement under NDA as part of your security review — that's the point at which it's useful to you, and it keeps the list accurate rather than letting it go stale on a web page.
Breach notification. Our incident-response and breach-notification policy is being written and tested against the Breach Notification Rule's 60-day timeline, and will be in place before we handle PHI.

One thing to confirm on your side.

If you're starting on the Scrub tier, have your counsel confirm the file you send is code content only — no identifiers — so it's genuinely de-identified. We'll tell you exactly what the extract should contain.

Your data stays yours.