Security & compliance

Built for the diligence, not just the badge.

Corevia is deployed on SOC 2 Type 2 and HITRUST-certified infrastructure under a Business Associate Agreement, with HIPAA and HITECH safeguards implemented in the platform itself. What follows is how the system is actually built — the isolation model, where PHI is allowed to go, and what we can hand your security team when they ask.

Architecture

Isolation and attribution, decided by the server.

Every control below is enforced where it cannot be talked around — in the data layer and on the server — rather than in application code that a future feature might forget to call.

Per-tenant data isolation

Each brand is a separate clinical project with its own access policies. Isolation is enforced at the data layer, not by a filter in application code, so a missing WHERE clause cannot leak one tenant's patients into another's view.

PHI never leaves the boundary

AI documentation and the clinical assistant run inside Corevia's own cloud account under a Business Associate Agreement. No third-party model provider receives patient data, and nothing is used to train anyone's model.

Append-only audit trail

Every PHI access, clinical decision and prescription is recorded and attributed to a named clinician — never to a service account. No role in the system, including administrators, may alter or delete an audit entry.

Least privilege per role and membership

Access is scoped by role and by the specific practice or network membership a user holds. The server decides what a request may return; the browser only renders what it was given.

Encryption in transit and at rest

TLS for everything on the wire, encryption at rest for the clinical record, documents and backups, with keys held in a managed key service rather than in application configuration.

FHIR R4 portability

The record is standards-based by construction. There is no proprietary schema to escape from, so an exit, a migration or a second system is an export — not a rebuild.

Diligence pack

What we can hand your security team.

Security review is a normal part of onboarding, not an obstacle. These are the documents and descriptions we can provide, in the form they actually exist in today.

Compliance posture summary

A written account of the HIPAA and HITECH safeguards implemented, the certifications held by the underlying infrastructure, and what is and is not in scope for Corevia itself.

Subprocessor list

Every vendor that touches the environment, what it does, whether it can see PHI, and the agreement in place with it.

Business Associate Agreement

Our standard BAA, executed before any production data exists, and the BAAs we hold with the infrastructure providers beneath us.

Architecture and data-flow description

Where PHI is created, stored, processed and transmitted; which components sit inside the boundary; and where the boundary ends.

Access-control model

Roles, memberships, the policies attached to each, how access is granted and revoked, and how administrative access is separated from clinical access.

Incident response and breach notification

How an incident is detected, triaged, escalated and communicated, and the notification obligations we take on as a business associate.

Penetration testing and vulnerability management

Our testing cadence and scope, how findings are tracked and remediated, and how dependencies and infrastructure are patched.

Business continuity

Backup and restore design, recovery objectives, and what a clinical team is expected to do while a degraded service is being restored.

We will not send you a certification we do not hold or an audit report that does not exist. Where something is in progress, we say so and tell you what stage it is at.

Clinical safety

The guardrails are in the platform, not the playbook.

Safety controls that depend on someone remembering them are not controls. These are enforced server-side, on every request, for every brand.

Drug–drug and drug–allergy interaction checking

Screened against the patient's complete active medication list and documented allergies before a prescription can be signed.

Risk-tiered identity and age verification

Government-ID verification at intake, with deeper assurance automatically required for hormone therapy and controlled-substance programs.

Immutable, attributed documentation

Signed notes become append-only. Corrections are addenda with their own authorship and timestamp — the record cannot be quietly rewritten.

Credentialing enforced at the point of care

License status, expiry and state coverage are checked when a chart is opened, not only when a physician is onboarded.

Idempotent prescribing

A failed or retried sign-off can never issue a second prescription — every issuance is keyed and deduplicated at the source.

Complete medication reconciliation

The chart shows every medication the patient is on across programs and prescribers, so interaction checking never runs on a partial list.

Straight answers

The questions security teams actually ask.

Do you sign a Business Associate Agreement?

Yes — as a matter of course, and before any production patient data exists. We also hold BAAs with the infrastructure and cloud providers beneath us, including for the environment the AI features run in.

Where is data hosted?

In a dedicated AWS environment in the United States. Patient data does not leave that environment, and there is no offshore processing of PHI.

Does any AI vendor see patient data?

No. The ambient scribe and the clinical assistant run inside Corevia's own cloud account under a Business Associate Agreement. No third-party model provider receives PHI, and no patient data is used to train an external model.

Can we get a penetration test report?

Yes, under NDA, to prospective clients in active diligence. Ask during the security review and we will route it to your team with the remediation status attached.

Keep going

The rest of the platform

Send us your security questionnaire.

We'll answer it honestly, including the questions where the answer is "not yet".