Back to acuityod.com Security & privacy

How Acuity protects patient data

Acuity handles real clinical and billing data for optometry practices, so security isn't an add-on feature — it's built into how the system is structured. Here's a plain, honest look at what's actually in place.

A note on terminology: there is no single government-issued "HIPAA certification" that a software vendor can obtain — HIPAA compliance is a shared responsibility between a practice (the covered entity) and the systems it uses, not a badge a product earns once. What follows is a factual description of the technical and administrative safeguards Acuity has actually built, so you can evaluate them yourself or share them with your own compliance advisor. We're glad to discuss a Business Associate Agreement (BAA) and answer specific compliance questions directly — reach out any time.

Keeping one practice's data separate from every other's

Acuity is used by more than one practice, so data isolation between practices is foundational, not an afterthought.

A separate database per practice

Every practice's patients, appointments, records, and billing live in a completely separate database — not a shared database with a "which practice" column. A bug in a query's filter can leak data within a shared database; it can't leak data across an entirely different database connection. That's a structural guarantee, not a policy.

Re-verified on every request

Which practice your session can access is signed directly into your login token and re-checked against a live, active membership on every single request — not cached, not assumed. A staff member removed from a practice loses access immediately, not at their next login.

Logins and access

Getting into the system, and controlling what you can do once you're in.

Passwords are never stored in readable form

Passwords are one-way hashed (bcrypt) before being saved — even someone with direct database access can't recover the original password. Login attempts are rate-limited to slow down password-guessing.

Sessions expire deliberately fast

Sessions expire after 12 hours and disappear entirely when the browser fully closes — a deliberately short leash appropriate for a system holding health information, sometimes called an "auto-logoff" posture. Session cookies can't be read by page scripts and only travel over encrypted connections.

Role-based permissions

Staff are assigned a role (Admin, Provider, Staff) with a sensible default set of permissions, individually adjustable per person without inventing a custom role. A permission change takes effect on that person's very next action, not their next login.

No unmanaged shared logins

New staff are added by a one-time, single-use email invite link (valid 7 days) — there's no shared "front desk" login floating around outside the system's own access controls.

Tracking who did what

Accountability matters as much as prevention.

A full audit log, automatically

Every save, edit, and delete against a practice's data — not just page views — is automatically recorded: who did it, when, and what was submitted. This powers the History button on records throughout the app and a practice-wide Audit Log for admins.

Sensitive fields are redacted automatically

Anything that looks like a password, token, or similarly sensitive value is automatically blacked out before being written to the audit log.

Vendor access is logged in your own audit trail

On the rare occasion Acuity's own support staff needs to look inside a practice's account to help, that access is logged twice — once for our own records, and once directly into the practice's own audit log, visible to that practice's admins with no special tooling required.

Records can be signed, locked, and recovered

Clinical records (Rx, notes, referrals) can be signed and locked to prevent further edits, with the signer's name and signature snapshotted at that moment so a later change can't retroactively alter a signed record. Deleting a record never destroys it outright — it's recoverable by an authorized administrator, guarding against accidental or malicious data loss.

Infrastructure & data handling

The technical foundation underneath all of the above.

Encrypted connections to the database

Connections to the database are encrypted and cryptographically verified against the database server's own certificate, not just password-protected — guarding against a network-level interception attempt, not only an unauthorized login.

Secrets are never stored in plain configuration

Database credentials, session-signing keys, and similar sensitive values are stored in a dedicated secrets-management service and handed to the running application only at startup — never written directly into configuration files.

Redundancy and backups

The production database runs with an automatically-failing-over standby copy in a second physical data center, plus 14 days of point-in-time-recoverable backups, and deletion protection so it can't be accidentally destroyed.

Someone's watching

Automated monitoring alerts a real person immediately if the system starts erroring, a server stops responding, or the database runs low on resources — problems tend to surface as an alert before they surface as a complaint.

Have a specific compliance question?

Whether it's a BAA, a security questionnaire, or something specific to your practice's requirements, we're happy to talk it through directly.