Written for the review you are about to run.
Praxa executes administrative work inside your environment, under credentials your team issues and can revoke, and writes an attributable record of every action it takes. In both customer-hosted deployment models, protected health information stays inside your perimeter, with one exception we state plainly below: the model call.
This page is the long version: the trust boundary, what crosses it, how data is handled, what the audit record actually contains, and where our compliance posture stands today — including the attestations we do not yet hold and will not imply.
- PHI residency
- Your environment — VPC and on-premise
- Credentials
- Issued, scoped and rotated by you
- Standing human access
- None — break-glass only, time-boxed and logged
- Training on your data
- Never on a shared model
- Audit record
- Per action, signed, exportable
- SOC 2 Type II
- Not yet held — see [ 06 ]
Praxa deploys on your side of the boundary.
The operator runtime — the component that reads documents, signs into systems of record, and takes actions — runs inside the customer environment. Praxa's control plane ships it versioned workflows and reads back operational telemetry. That is the entire relationship across the boundary.
- Runtime location
- Inside your network. Sessions to your systems of record are opened from your environment and never traverse Praxa infrastructure.
- Direction of connection
- The runtime opens an outbound, mutually authenticated channel to the control plane. Praxa cannot initiate an inbound connection to your environment. There is no listener for us to reach.
- Isolation
- One runtime per customer. No shared execution, no shared storage, no shared queues, no multi-tenant worker pool.
Customer environment
You own the network, the keys and the account
Systems of record
EHR, payer portals, document and fax intake, shared inboxes. Praxa signs in as a service account your team created.
Operator runtime
Reads, decides, acts. Containerised, single-tenant, pinned to a release your change process approved.
Document and field store
Source documents and extracted fields are written to storage you own, encrypted with keys held in your KMS.
Audit log
Written locally first. Readable and exportable by you without Praxa in the path, and it outlives the contract.
Trust boundary · mutual TLS · outbound-initiated only
Leaves your environment
Operational telemetry only: run counts, step durations, error codes, confidence distributions, and the operator version in use. No payloads, no document text, no identifiers.
Enters your environment
Signed operator release bundles, workflow definitions, scope declarations and model routing policy. Nothing executes until the release is approved in your change window.
Praxa control plane
No PHI · no credentials · no inbound path
Workflow registry
Versioned operator definitions and signed release bundles. Every release carries a scope diff so a permission change is visible before it ships.
Model routing policy
Which model class handles which document type, and the confidence thresholds attached to each. Policy crosses the boundary; data does not.
Telemetry store
Counts, durations, error codes. Sized to answer "is it running and is it accurate" without ever answering "what did it say".
Support console
Read-only over telemetry. No route to your data, no stored session into your environment, no credential that would open one.
Where PHI lives, and what we are permitted to do with it.
Four questions decide most vendor assessments: where does the data sit, how is it protected, does it train anything, and how does it get destroyed. Answers below, without qualifiers.
Residency
In the two customer-hosted models, your VPC or your data centre, PHI stays inside your perimeter with one exception: the model call. If a workflow routes to a hosted model provider, the text it sends crosses to that provider. That is an egress path, and calling it zero-retention-under-BAA describes what happens to the data there, not whether it left. Serve models locally and the exception disappears. We will not describe a hosted model call as staying inside your perimeter, because it does not. Documents are ingested, parsed and acted on inside your environment, and extracted fields are written to storage you own.
In the managed model, PHI would be processed in a dedicated single-tenant environment that Praxa operates, and only under an executed Business Associate Agreement. None is in place today, because there is no customer yet. That is the one deployment where the perimeter is ours rather than yours. It is stated here rather than buried in an appendix, because your questionnaire will find it either way.
Encryption
TLS 1.3 for every connection, including service-to-service traffic inside the runtime. TLS 1.2 is the floor, and it exists only for legacy payer endpoints that still refuse 1.3; those endpoints are enumerated per deployment so you can see exactly which ones they are.
At rest: AES-256. In customer-hosted deployments the keys live in your KMS and Praxa holds no key that decrypts your data. Secrets are never written to disk by the runtime and are redacted from every log line before it is emitted.
Model training
No customer data trains a shared model. Your documents, extracted fields and reviewer corrections are not used to train, fine-tune or evaluate any model that another customer can reach. There is no opt-out to configure, because there is nothing to opt out of.
Where a workflow calls a third-party model provider, it must call a zero-retention endpoint covered by a Business Associate Agreement. That is a requirement on the routing policy, not a description of an arrangement we hold today: a provider that cannot offer both cannot be routed to. The full subprocessor list ships with the security package.
Retention and deletion
Retention is a per-workflow setting you own. Source documents, extracted fields and audit records each run on their own clock, so you can keep a seven-year audit history without keeping the seven-year-old fax it describes.
Deletion is a real delete. Records are removed from primary storage on request and age out of encrypted backups within the backup window, which is 35 days. On termination we return your audit history in full, destroy our copy, and give you written confirmation within 30 days.
Praxa uses credentials you issue, scope and can revoke.
An operator is an account in your directory with a narrow job. It holds no privilege you did not grant it, it cannot grant itself more, and switching it off is something your team does without calling us.
Customer-owned credentials
Every account an operator uses is created in your identity provider or your system of record, by your team, under your naming convention. Praxa holds no master credential and never reuses an account across customers.
Secrets live in your vault. The runtime fetches them at execution time, holds them in memory for the life of the step, and never persists them to disk, to a cache, or to a log.
Least privilege, per workflow
Each operator gets its own service account, scoped to the exact screens, endpoints and record types that one workflow needs. A prior authorization operator cannot open a chart it has no reason to read.
Scopes are declared in the workflow definition, reviewed at deployment, and diffed on every release. A permission expansion arrives as a reviewable change, not as a surprise in next quarter's access audit.
Rotation and revocation
Credentials rotate on your schedule — 90 days by default — through your vault, with no Praxa involvement and no coordination window. The runtime re-reads the secret on the next step and continues.
Revocation takes effect within the current step. In-flight work stops and is queued for a human rather than retried against a dead credential, so a revoked account produces a visible backlog instead of a silent failure. Nothing is cached past the revocation.
No standing human access
No Praxa engineer holds a standing session into a customer environment or a standing path to PHI. Day-to-day support runs on telemetry, which is why telemetry is built to be useful without payloads.
When an investigation genuinely needs more, access is requested, approved by your team, scoped to a named system and a time box, recorded in the same audit stream as operator activity, and expires on its own. Break-glass is an event with a record, not a role somebody holds.
Every action an operator takes is a record with a name on it.
Automation that cannot be reconstructed after the fact is a liability, not a saving. Praxa writes one signed record per action — not per run — so a reviewer can answer who did what, under which permission, on what evidence, and whether it can be undone.
- Attributable
- Each record names the operator, its exact version, the service account, the scopes that account held at the time, and the run and step it belonged to.
- Reproducible
- Inputs are hashed and the operator version is pinned, so any run can be replayed step by step against the same inputs and diffed against what happened in production.
- Tamper-evident
- Records are appended in a hash chain and signed. An altered or missing record breaks the chain, and you can verify the chain yourself without Praxa in the loop.
- Reversible where it can be
- When an action has an undo, the record carries the compensating action that performs it. When it does not, the record says so — and that action needed a human first.
- Exportable
- Stream to your SIEM over syslog, or to an object bucket you own, as newline-delimited JSON. The log lives in your storage and survives the end of the contract.
Audit record — one actionFig. 02 · synthetic sample
{
"schema": "praxa.audit/v1",
"event_id": "evt_7K3QW2-SAMPLE",
"recorded_at": "2026-04-17T14:32:08.194Z",
"prev_hash": "sha256:9b1c…0f72",
"run": {
"run_id": "run_5ZTD41-SAMPLE",
"operator": "prior-auth.submit",
"operator_version": "2026.03.4+a19f2c",
"step": 7,
"of_steps": 11
},
"actor": {
"type": "service_account",
"id": "svc-praxa-priorauth-01",
"credential_ref": "vault://customer/priorauth#current",
"granted_scopes": ["portal.auth.read", "portal.auth.submit"],
"human_approver": null
},
"subject_ref": "tok_A41F9C-SAMPLE",
"action": "payer_portal.submit_authorization",
"inputs_digest": "sha256:4c1f…b8e2",
"decision": {
"mode": "autonomous",
"confidence": 0.962,
"threshold": 0.940,
"policy": "prior-auth.autonomy.v6"
},
"result": "accepted",
"external_ref": "SAMPLE-AUTH-4471902",
"reversible": true,
"compensating_action": "payer_portal.withdraw_authorization",
"duration_ms": 4180,
"signature": "ed25519:MEUCIQD…SAMPLE"
}subject_ref is a token that resolves to a patient only inside your environment. The audit stream carries no names, no medical record numbers and no document contents — so it can be shipped to a SIEM, handed to an auditor, or kept for seven years without widening the PHI footprint by a single field.
Three ways to run it. The trade-offs are real.
Every deployment model trades control against speed somewhere. Below is where each one gives ground — stated by us, so you do not have to extract it in the third call.
Customer VPC
Praxa deploys the runtime into a cloud account you own, inside your network, under your controls. This is the default recommendation for production.
- Runs in
- Your cloud account, your subnets, behind your egress controls
- Key custody
- Your KMS. Praxa holds no decryption key
- PHI leaves your perimeter
- No
- Release cadence
- Your change window
- Trade-off
- You own the infrastructure. Capacity, patching and the change process are yours — which is the point, and which means upgrades move at your speed, not ours.
On-premise
The runtime sits in your data centre with no dependency on a public cloud. Releases arrive as signed bundles and can be installed with the control-plane channel fully closed.
- Runs in
- Your data centre, optionally air-gapped
- Key custody
- Yours, entirely
- PHI leaves your perimeter
- No
- Release cadence
- Manual, on your schedule
- Trade-off
- The strictest boundary and the slowest loop. Models must be served locally, which narrows the set available to a workflow and usually costs accuracy on the hardest documents. Telemetry and releases become a manual exchange.
Managed, single-tenant
Praxa operates a dedicated environment for you. Same isolation guarantees, same audit record, same access model — but the perimeter is ours.
- Runs in
- A single-tenant environment Praxa operates
- Key custody
- Per-tenant keys held by Praxa, under a BAA
- PHI leaves your perimeter
- Yes — the only model where it does
- Release cadence
- Praxa's, with advance notice
- Trade-off
- Fastest to stand up and least work for your team. In exchange, your assessment of Praxa becomes load-bearing rather than advisory. Our own advice: use it for a bounded pilot, and move to VPC before production volume.
What we hold today, stated exactly.
Certifications are easy to imply and slow to earn, and the gap between the two is where vendors lose a security team permanently. Praxa is early. Here is the actual position — nothing below is a claim of an audit we have not completed.
SOC 2 Type II
Not held
Praxa does not hold a SOC 2 Type II report. Controls are being implemented against the Trust Services Criteria, and a Type II requires an audited observation window that has not run.
We will publish a report date when an auditor gives us one, and not before. If your procurement requires a completed Type II at signature, we do not meet that bar today — and we would rather you learn that here than in month four of a pilot.
HIPAA
BAA-ready · no certification exists
There is no such thing as HIPAA certification. What exists is a Business Associate Agreement and a set of required and addressable technical safeguards. Praxa will execute a BAA, and the architecture on this page is built to those safeguards: access control, unique user identification, audit controls, integrity, authentication and transmission security.
Any vendor telling you they are "HIPAA certified" is describing something that cannot exist. Treat that as a signal about the rest of their answers.
GDPR
Not applicable today
Praxa's deployments are US-based, and we do not currently process the personal data of individuals in the EU or the UK. GDPR obligations — lawful basis, a data processing agreement, a lawful transfer mechanism, and a representative or DPO where required — attach when that changes.
That work is sequenced ahead of any EU deployment, not retrofitted after one. We are not claiming GDPR compliance for processing we do not do.
HITRUST CSF
Not started
On the roadmap, sequenced after SOC 2 Type II, and pursued when a customer contract requires it. HITRUST is expensive and slow, and starting it before the underlying controls are audited is theatre rather than assurance.
Independent penetration test
Gate on first production deployment
An independent test of the runtime and the control plane is a gate on our first production deployment, not a later milestone. Until that report exists we will not point you at one, and we will not describe internal testing as if a third party had done it.
Once it exists, summary findings and remediation status are available under NDA.
Praxa executes. It does not decide what is clinically true.
An operator moves work through a process. It does not diagnose, it does not determine medical necessity, it does not triage, and it does not assign a final code.
Where a workflow brushes against clinical meaning — a charge that looks unsupported, a document whose intent is ambiguous — the operator's output is a flag for a qualified human, with the source attached. That boundary is a product constraint, not a policy we ask staff to remember.
- 01Shadow
- 02Reviewed
- 03Thresholded
- 04Held
Confidence thresholds are yours
Every extraction and every action carries a confidence score. You set the threshold per workflow. Below it, the item routes to a human queue with the operator's reasoning and the source document attached.
Thresholds are a customer setting. Praxa does not quietly tune them to improve an automation rate on a slide.
Autonomy is earned per workflow
New workflows start in shadow mode: the operator runs, proposes, and changes nothing, while its output is scored against what your team actually did.
Autonomy is granted only after measured accuracy on your data, over a review period you define, for that workflow alone. Accuracy on referral intake buys nothing for appeals.
Irreversible actions stop for a human
An action that cannot be undone — a submission that starts a clock, a release of records — requires a person at the point of action unless you have explicitly granted autonomy for it against a reviewed accuracy history.
Where a compensating action exists, the audit record carries it, so an undo is a documented step rather than an improvisation.
Model changes are gated and pinnable
Model and prompt changes run against per-workflow evaluation sets before release. A regression blocks the release. The evaluation summary ships with the release note, not on request.
You can pin a workflow to a version and decline an upgrade. An operator's behaviour does not change underneath you between one Tuesday and the next.
Take the documentation before you take the call.
Security reviews move faster when the vendor hands you the packet instead of making you ask for it twice. Tell us what your process needs and we will send it, questionnaire included, in your format.
If something on this page is wrong, vague, or does not survive contact with your control framework, say so in the first email. We would rather rewrite the page than argue with a reviewer.
- 01Architecture and data-flow diagrams, at the depth your reviewers work at
- 02Completed vendor questionnaire — HECVAT, CAIQ, or your own template
- 03Business Associate Agreement and data processing agreement templates
- 04Deployment runbook, network requirements and egress allow-list
- 05Per-workflow scope inventory: exactly what each operator can reach
- 06Subprocessor list, including every model provider in the routing policy
- 07Incident response and breach notification plan, with notification timelines
- 08Audit record schema and a sample export against synthetic data