How we protect patient data

An important distinction

We do not describe EMR Chart as “HIPAA compliant.” Compliance is a property of an organization, not of software: it depends on your policies, workforce training, executed agreements, and how your team actually uses the system. What we provide is the technical foundation, documented below, plus the agreements needed to support it.

Access control

• Unique accounts only. Shared logins are not supported.
• Role-based permissions are enforced in a server-side service layer, not in the browser.
• Time-based one-time password (TOTP) multi-factor authentication is supported, with a minimum twelve character password policy and account lockout.
• Sessions time out when idle, and sessions are revoked when an account is deactivated or its password changes.
• Emergency “break-glass” access is time-boxed, requires a stated reason, and is recorded for review.

Auditing

Reads of patient information are recorded, not just writes. Patient profile views, chart note views, file downloads and uploads, exports, prints, message sends, and form submission views all write an entry to an append-only audit log. Application logs record record identifiers only, never patient names, contact details, or note content.

Data protection

• Patient data is stored in Amazon RDS PostgreSQL with encryption at rest, automated backups, and a multi-availability-zone configuration.
• Uploaded files are stored in private object storage with server-side encryption using a managed key, and can only be retrieved through an authorized, audited application route. There are no public file URLs.
• All traffic is served over HTTPS with strict transport security.
• Restore drills are performed and recorded, so backups are verified rather than assumed.

Clinical record integrity

A signed chart note is immutable. Corrections are made by adding an addendum and a new version, so the original signed content and its author remain intact. Pricing and authorization decisions are made on the server, never trusted from the browser.

No tracking on pages with patient data

Authenticated pages carry no third-party analytics, advertising pixels, session replay, or externally hosted fonts. A strict content security policy restricts scripts, styles, and network connections to our own origin, and all assets are served from it.

Vendors and agreements

Infrastructure that can touch patient data is covered by a business associate agreement with the relevant provider, and the product tracks those agreements internally. Optional integrations that would introduce a new vendor stay disabled until an agreement is in place; our own code fails closed rather than sending patient data to an uncovered service.

Email

Authentication email contains no clinical information. Our sending practices, including automatic bounce and complaint suppression, are documented on the email practices page.

Reporting a vulnerability

Send security reports to the address on our contact page. Please include enough detail to reproduce the issue, and do not access, modify, or retain anyone else’s data while testing.