Security architected in, not bolted on
Care records are among the most sensitive data there is. ClinivX enforces protection at every layer (database, application, session, and AI), so integrity doesn't depend on everyone doing everything right.
Tenant isolation in the database itself
Every tenant-owned row carries its organization, and PostgreSQL row-level security, forced even for table owners, filters every query by the authenticated organization. The application connects as a deliberately unprivileged role, so isolation holds even if application code has a bug.
Out-of-tenant records return 404, never 403; their existence is never even acknowledged.
Permissions derived, never asserted
Identity and tenancy come only from the authenticated user's active staff assignments, never from anything a client sends. Permissions are facility-scoped strings checked on every request, so a nurse at one facility has exactly nothing at another.
Request schemas reject unknown fields outright, closing off mass-assignment entirely.
Clinical records that cannot be quietly rewritten
Signed notes, reviewed care-plan versions, incident narratives, medication administrations, and controlled-substance counts are locked by database triggers: append-only, even for administrators. Corrections are new versions or reason-tagged addenda, in the open.
The integrity rules hold at the database layer, below the application: there is no privileged path around them.
A tamper-evident audit trail
Sensitive actions append to a per-organization, hash-chained log. Each event's hash incorporates the one before it, so removing or editing any event breaks the chain visibly. Denied attempts are recorded before the denial is returned.
No update or delete path exists for audit events, by construction.
Hardened authentication
Short-lived access tokens ride on rotating refresh tokens with reuse detection: a replayed token revokes the whole session family. TOTP two-factor is built in with encrypted seeds, and the auth endpoints are rate-limited against brute force.
Sessions live in httpOnly cookies via a server-side BFF; tokens never touch browser JavaScript.
Signed notes you can verify without trusting us
Every signature writes a cryptographic seal: a canonical hash of the signed record, signed with an Ed25519 key and chained to the resident's previous seal. Altering a note after signature breaks the chain, and the break is detectable by anyone, not only by us.
A standalone verifier reimplements the check in a different runtime with no shared code, so a surveyor or auditor can confirm integrity without running our software or taking our word for it.
AI that is governed, not trusted
Agents can only create proposals. Executing one requires a recorded human approval, runs under the approver's own permissions through the same domain services, and leaves evidence. Deterministic code, never a model, enforces permissions, signatures, med windows, and deadlines.
The default AI provider is an offline deterministic mock: no clinical text leaves the tenant boundary until a provider is deliberately configured.
Operational practices
- No PHI in logs, errors, or URLs: identifiers only, with PHI-scrubbed error reporting
- Structured JSON logging with request correlation IDs in production
- TLS everywhere; secrets injected at deploy time, never committed
- Password policy enforced server-side with audited changes
- Synthetic data only in every demo environment
ClinivX demonstrates these controls with synthetic data. No real protected health information has ever been processed. This is not a HIPAA-compliance certification, and no such certification is issued by any government body.
The compliance program, as of today
Controls are only half of it. HIPAA is mostly a program: written, owned, exercised. Each of these is a dated artefact, not an intention.
- Security Risk Analysis, signed. 45 CFR 164.308(a)(1)(ii)(A). Asset inventory, egress register, control crosswalk, and a risk register that is published internally with every open finding named.
- Security Officer and Privacy Officer, designated. One named, accountable person, with the authority to halt a release or stop data reaching a vendor.
- Security policy set, adopted. Twelve policies, each stating the rule, what code enforces today, and what is still manual. The split is written down rather than blurred.
- Incident and breach runbook, adopted and exercised. Discovery clock, severity levels, evidence preservation, and the four-factor breach assessment. Tabletop-tested, and the findings from that exercise were entered as risks rather than filed away.
- Workforce security training, delivered. Covering business-associate obligations, incident reporting, and treating external AI tools as subprocessors. Acknowledgements retained.
- Contingency plan with a restore drilled against real provider snapshots. Not a rehearsal against a hand-made copy: the hosting provider's own point-in-time recovery, restored to a scratch instance, secrets reapplied, the application started against it, and records read back through the product. Record integrity is compared to a pre-restore baseline, so a restore that returns rows but breaks a hash chain fails rather than looking like success. The first drill found a recovery path that could not complete, which is exactly what a drill is for.
- Every security control verified by deliberately breaking it, every week. Twenty-one controls, from the application layer down to the database's own row-level security and immutability triggers. Each is removed in turn and the suite re-run, because a control nothing tests is a claim rather than a defence. This runs continuously rather than once: the first sweep found three controls no test defended, including two built the previous day, and moving it into continuous integration immediately found a fourth that had never been checked on the platform we deploy to. It proves a control cannot be deleted unnoticed. It does not prove the control is the right one, and we do not claim otherwise.
What is not done yet
Published deliberately. A security page with no gaps is a marketing page. These are the open items your compliance officer would find anyway, and we would rather they hear it from us.
- No business associate agreements are signed yet, with any subprocessor. Until they are, every external connector stays off and no data leaves the platform.
- Encryption at rest is provided by the hosting platform but not yet confirmed to us in writing, per datastore, with the algorithm named.
- No independent security assessment has been performed. We will not describe ourselves as HIPAA compliant before one has.
- Recovery is exercised against the hosting provider's own point-in-time snapshots, end to end: restore, secrets, application start, and reading records back through the product. Integrity is verified against a pre-restore baseline rather than checked for presence. What we have not yet built is monitoring that tells us when the service stops serving, and until that exists our own detection depends on someone looking.
Until every one of these is closed, ClinivX runs on synthetic data only and makes no compliance claim it has not earned.
See the guardrails for yourself
Try to edit a signed note or peek at another facility in the live demo; the platform will politely decline.