The Security Rule, read as an engineering checklist.
Each safeguard below names the component that implements it, so an auditor's question has a concrete answer rather than a policy document. These are hard rules — no configuration, tier, feature flag or customer request disables any of them.
Tenancy is enforced twice, and the second time is in the database.
The subdomain and the token must agree
The session cookie is host-only — never scoped to the parent domain — so a session on one hospital's subdomain cannot bleed to a sibling. As a backstop, middleware compares the token's tenant against the subdomain, and a mismatch is a 403 with the cookie cleared, before routing.
Row-level security below that
Every tenant-owned table carries a tenant ID and an RLS policy that makes cross-tenant reads impossible even for buggy application code. CI asserts that every new table has RLS enabled — a table without it fails the build.
Per-tenant encryption keys
Each tenant's data is encrypted under its own key. Offboarding ends with key destruction, which makes erasure provable rather than promised.
One authorization point, no bypass
The policy engine is called identically by the web UI, the report builder, the public API and the AI gateway. There is no path to data that goes around it — including the assistant's.
Where each rule actually lives in the system.
| Safeguard | Rule | Where it lives |
|---|---|---|
| Access control | §164.312(a) | Policy engine evaluating role × module × field × row. Unique user IDs always — never shared logins. Auto-logoff with clinical-floor defaults. Break-glass access requires the tenant's own consent, is time-boxed, and is logged on both sides. |
| Audit controls | §164.312(b) | An append-only, hash-chained event log covering all ten modules, with the AI action log in the same chain. Six-year retention. Your compliance officer reads it in-product — no support request, no export ticket. |
| Integrity | §164.312(c) | No direct database access paths. Domain validations on every write, including the public API and the assistant. The hash chain detects tampering and is verified daily. |
| Authentication | §164.312(d) | SSO (SAML/OIDC) with MFA enforced, and SCIM deprovisioning so a directory deactivation removes VeloERP access in the same minute. The demo tenant is isolated from production auth entirely. |
| Transmission security | §164.312(e) | TLS 1.3 everywhere; mutual TLS or SFTP+PGP on EDI. No PHI in URLs, logs, error messages or analytics events — enforced, not advised. |
| Encryption at rest | §164.312(a)(2)(iv) | Per-tenant KMS keys and encrypted backups. Offboarding ends with key destruction — cryptographic erasure, provable to your compliance team rather than asserted in a contract. |
| Business associate duties | §164.308(b) | A BAA is signed before production data loads — the go-live gate enforces it. Subprocessor BAAs are maintained and published, including both model vendors. |
| Contingency | §164.308(a)(7) | Point-in-time recovery and cross-region backups. RTO ≤ 4 hours, RPO ≤ 15 minutes. Restore drills are on the calendar and the results are retained. |
| Minimum necessary | §164.502(b) | Field masking and row scoping by default. Exports and API responses are masked identically to the screen — a matrix that only governs the navigation is decoration. |
| Accounting of disclosures | §164.528 | Every access to identified PHI is recorded with role, purpose and unmasking justification. Queryable and exportable by your compliance officer directly. |
Five rules, and the fifth is the one that matters.
A hospital's tolerance for AI depends entirely on being able to tell where it has been — and on knowing the product still works when it is switched off.
BAA-covered vendors only — both of them
Model calls go exclusively to vendors under a signed BAA, listed publicly: Anthropic for inference, OpenAI for embeddings. A model without a BAA is not evaluated, regardless of capability.
No training on tenant data
Contractually and technically. It is the first question a hospital's privacy officer asks about AI, and a hedged answer ends the conversation — so the answer is flat.
Minimum necessary context
A coding question sends charge lines and diagnosis codes, not the clinical narrative. An appeal draft sends the claim, the contract clause and the auth record — not the chart. Context assembly is a gateway responsibility, not a prompt convention.
We do not embed patient-identified text at all
Item masters, payer rules, contract text, vendor records and configuration go into the vector path. Patient-identified content does not. That removes the risk class rather than managing it — a stronger guarantee than a correctly-configured BAA.
Every AI feature is independently disableable
The product remains fully operable with no model reachable at all. AI is an augmentation layer over complete manual workflows, never a dependency — which is also what makes an accredited federal deployment possible.
Published, not requested.
| Subprocessor | What it processes | Inside PHI boundary |
|---|---|---|
| Anthropic | Model inference for the assistant | Yes — BAA required |
| OpenAI | Embeddings for retrieval (never patient-identified text) | Yes — BAA required |
| Microsoft Azure | Compute, storage and per-tenant key management | Yes — BAA required |
| SendGrid | Transactional and notification email | No — no PHI in email bodies |
| Clearinghouse partner | X12 claim and remittance transport | Yes — BAA required |
What is not done yet
VeloERP is pre-GA. SOC 2 Type II is on the path, not attested — we will publish the report date rather than imply the badge. Subprocessor BAAs are executed per vendor before that vendor is used in production, and no production tenant loads data until its own BAA is countersigned. If a security questionnaire needs an answer we do not have yet, we say so instead of routing around the question.
Send us the questionnaire.
We would rather answer your compliance team's spreadsheet now than discover a blocker in week ten of an implementation.
Contact us