Axiom OrderFlow / Trust Center
Built for healthcare data from the first line of code.
Axiom OrderFlow handles EEG order intake for neurodiagnostics departments. Protecting that data, and proving how, is a first-class part of the product rather than an afterthought, described here in terms your IT and security teams can verify.
Human-reviewed. Built specifically for EEG. Designed to complement your EHR and EEG acquisition system.
Isolation
PostgreSQL row-level security scoped to your organization on customer-data tables.
Encryption
TLS in transit. AES-256 at rest by the managed Postgres platform.
Audit
The actor is stamped from the server session, never supplied by the client.
PHI gate
De-identified or synthetic data only, by contract and by operating practice.
Contractual, not a technical control.
The security boundary, end to end.
This is the production data path in plain language. It deliberately separates identity, application authority, database enforcement, and optional AI processing.
- 01
Authenticated user
A hospital team member signs in over HTTPS. Optional TOTP MFA is enforced across private pages and APIs.
- 02
Server authority
Next.js server routes re-check the signed-in role. Browser visibility is never treated as authorization.
- 03
Tenant-protected data
Supabase Auth, Postgres, and private Storage enforce organization-scoped access through row-level security.
- 04
Gated extraction
When enabled, document extraction runs server-side. Validated output still requires human approval before tracker entry.
The interface only hides what a role cannot do. The enforced authority lives in server checks and RLS policies, so the UI is convenience, never the security boundary.
Nothing reaches the tracker without a person.
- AI extraction never writes to your tracker directly.
- Every extracted field passes a strict validation gate, then a human review and approval, before it becomes a row.
- Structurally invalid AI output is routed to manual review, never inserted unchecked.
- Order PDFs live in a private storage bucket with no public URLs, streamed only to authorized members of the owning organization.
Captured from the live application running a synthetic demo workspace. No patient information appears in any image.
Subprocessor register.
Named services used by the application, their purpose, and the current PHI gate.
| Service | Purpose | Before patient-identifying mode is unlocked |
|---|---|---|
| Supabase | Authentication, managed Postgres, and private file storage | HIPAA add-on and signed BAA are required before PHI unlock. |
| Vercel | Application hosting and server compute | BAA or a verified no-PHI-in-logs posture is required before PHI unlock. |
| Anthropic | Optional AI-assisted order-document extraction | A BAA or PHI-safe terms are required; otherwise AI stays disabled for PHI. |
| Resend | Optional transactional and operational email | Messages are designed to remain PHI-minimal; contractual review remains part of PHI readiness. |
| Sentry | Optional error monitoring | Request data and user context are scrubbed; contractual review remains part of PHI readiness. |
Each posture above states what is required before patient-identifying mode is unlocked for a workspace. It is not a description of agreements already in place.
The controls in place today.
Every item below is implemented in the product. Nothing here describes a plan, and nothing describes a safeguard we have not built.
Governed EHR interfaces
Axiom supports governed HL7 v2 and FHIR R4 interface workflows through a hospital’s interface engine. Each production connection is separately scoped, tested, and accepted with the customer’s interface team. Interface intake is fail-closed and synthetic-only until an administrator activates production, every message is idempotent and human-reviewed, and failures are quarantined with supervised replay.
Tenant isolation at the database, not just the app
Tenant-isolation controls are implemented at the database layer (PostgreSQL row-level security scoped to your organization on customer-data tables) and at the application layer, and are continuously tested against supported access paths, including cross-tenant reads and writes with leaked record identifiers. Because the boundary lives in the database, it is enforced even if application code has a defect on a covered path.
Encryption in transit and at rest
All traffic is TLS/HTTPS end to end. Data at rest is encrypted with AES-256 by the managed Postgres platform (Supabase). Order PDFs live in a private storage bucket with no public URLs; files are streamed only to authenticated, authorized members of the owning organization.
Role-based access control
Four roles (viewer, staff, supervisor, admin) are enforced on the server and re-checked in the database on protected routes and data access paths. The interface only hides what a role cannot do; the enforced authority lives in server checks and RLS policies, so the UI is convenience, never the security boundary. Role and cross-tenant denial behavior is exercised by automated test matrices.
Append-only audit trail
Application mutations (approvals, edits, deletions, plan and permission changes) are written through audited paths, with core clinical writes committed in the same database transaction as their audit entry. The actor is stamped from the server session, not supplied by the client, and the audit table carries no update or delete policy for application users. Deleted records keep their data and history.
Two-step verification (MFA)
Any account can enable TOTP two-factor authentication, and organizations can require it for all members. Once enabled, the second step is enforced in middleware across private pages and APIs, not just at the login screen, and a failed verification check fails closed.
Human approval before anything is recorded
AI extraction never writes to your tracker directly. Every extracted field passes a strict validation gate and then a human review and approval before it becomes a row. Structurally invalid AI output is routed to manual review, never inserted unchecked.
Least-privilege service access
The privileged service key exists only in server environment variables, never shipped to a browser. Its use is a short, inventoried list (scheduled jobs, tokenized inbound feeds, the public demo), each independently authenticated. Everything a user initiates runs under their own session, so row-level security stays in force.
Controlled data retention
A nightly job purges stored order PDFs older than your configured retention window, for settled orders only. The extracted data, tracker rows, and audit history remain, and each purge is itself audited. Retention is a policy you set, enforced automatically.
Protected Health Information: a deliberate gate.
We are direct about what “HIPAA-ready” means. The engineering controls a HIPAA posture depends on (encryption, access control, audit, isolation, retention) are implemented and listed above. Turning on real patient data is gated behind business and legal steps, in this order.
Demo workspaces are for synthetic data only, and that restriction is contractual and operational rather than technical. A database constraint pins the patient-identifying mode off, but it governs the mode flag, not the contents of a field: this release does not technically prevent someone typing patient information into an order, so please do not enter or upload real PHI. No PHI readiness is claimed until production security hardening, compliance review, signed Business Associate Agreements with our data and AI subprocessors, and facility approvals are complete. Ask us where that pathway stands before any production use.
- Today, by contract and by practiceToday the platform is restricted to de-identified or synthetic data by contract and by operating practice. A database constraint pins the patient-identifying mode off, and turning it on takes a deliberate, reviewed migration rather than a setting. That constraint governs the mode flag, not the contents of a field: this release does not technically prevent someone typing patient information into an order, so please do not enter or upload real PHI.
- Signed Business Associate AgreementsBefore a workspace is authorized for real patient information, Axiom completes signed Business Associate Agreements (BAAs) with its data and AI subprocessors. We describe that as the sequence we follow, not as agreements already in place.
- Security review, then a reviewed migrationA security review is completed against your environment, and patient-identifying mode is unlocked through a deliberate, reviewed database migration, never a toggle.
Until those steps are complete for your organization, use de-identified or synthetic data only. That restriction is contractual and operational: this release has no technical control that blocks patient information from being typed or uploaded, so treating it as one would put your department at risk. We will not claim certification we do not hold, and we will not describe a safeguard we have not built.
Questions, reviews, and disclosure.
We welcome security reviews from prospective customers and will walk your IT and compliance teams through the architecture, our subprocessors, and where each stands on a BAA.
- Architecture walkthrough with your security reviewer, using the data path above.
- Subprocessor register, retention settings, and the PHI gate, in writing.
- Interface scope reviewed with your interface team before any production connection.
Responsible disclosure
If you believe you have found a vulnerability, please report it privately to info@axiomeeg.com so we can address it before any disclosure.
Security questionnaires, the trust package, and review scheduling go to the same address.
The controls described here are implemented in the deployed build identified by the public build manifest at axiomorderflow.com/api/version, and are exercised by automated role, cross-tenant, and session-lifecycle test matrices. This page is updated as the platform changes. It describes controls. It is not a certification, and no page can prove the absence of all defects.
Send us your security questionnaire.
We will walk your IT, compliance, and interface teams through the architecture, the subprocessor register, and the PHI gate.
Or email info@axiomeeg.com · View live system status · Full evidence index