HIPAA compliance was a day-one design constraint, not an afterthought. Tenant data is isolated at the database. Permissions resolve per request. Every PHI read writes an audit entry. AWS sits under a signed BAA.
Most CRM platforms treat HIPAA as a tier upgrade. A “secure” plan at 2x the regular price, with a few extra features bolted on. That model creates a two-track product, where the compliance posture is a marketing line, not an architectural one.
Lumè doesn’t have a “secure tier.” Every customer is on the HIPAA-compliant architecture because there’s only one architecture. Tenant isolation, role-based permissions, audit logging, and PHI containment are foundational. They’re built into the models and the middleware, not patched on as an upsell.
Lumè is built on a defense-in-depth architecture: least privilege, traceability, change management, separation of duties. Production runs on AWS services covered by a Business Associate Agreement. Postgres is KMS-encrypted at rest. Email goes through SES with the right SPF, DKIM, and DMARC posture. Backups are encrypted, key rotation is automated, access is logged.
The product also makes the hard choice consistently. Email containing PHI (a signed-consent copy, for example) sends only when an operator initiates it, because automated PHI delivery would require per-customer authorization most spas don’t capture today. CSV exports of per-customer data fire a confirmation gate before the download. Every confirmation is logged.
Each commitment references the architecture decision record it was written down in.
Every PHI-bearing model carries a tenant FK at the database schema level. Queries route through a tenant-scoped manager exclusively. Cross-tenant data access is impossible without explicit code paths that don't exist in the API surface.
Reference: ADR 0001
A 36-permission catalog resolved per request. Six default roles — owner, manager, front desk, provider, bookkeeper, marketing — each with a defensible default permission set. Per-user overrides are explicit and audit-logged. Locked permissions cannot be granted ad-hoc.
Reference: ADR 0003
Every PHI read, every state transition, every report run, every CSV export writes an audit log entry. Production enforces append-only via a Postgres trigger that rejects UPDATE and DELETE on the audit table. Satisfies HIPAA §164.312(b) and maps to the SOC 2 CC 6.1 control criteria.
Reference: ADR 0004
Audit metadata records what happened, never the PHI itself — a customer name appears in the chart, never in the audit log. Email addresses are reduced to their domain in the audit trail. Reports that surface per-customer data require explicit confirmation before CSV export.
Reference: ADR 0013
256-bit URL-path tokens (never query string) for the public form-fill page and similar customer-facing surfaces. Single-use for state-changing actions. The rest of the application is session-cookie authenticated with CSRF protection.
Reference: ADR 0011
AWS under a signed Business Associate Agreement: Fargate compute, RDS Postgres encrypted at rest with KMS, SES for email with DKIM/SPF/DMARC. Email containing PHI sends only on operator action with the customer's request on file.
Reference: ADR 0012
The audit log is append-only at the database trigger level — UPDATE and DELETE statements on the audit table are rejected. Owners and managers can query by date, user, or resource. The log includes IP and user-agent on every entry.
Entries shown right are illustrative. The real surface is identical.
Audit log
Last 60 minutes · append-only
Production runs on AWS under a signed BAA. Postgres encrypted at rest with KMS. Backups encrypted, key rotation automated. SES handles email with DKIM, SPF, and DMARC configured. Audit log tables are append-only at the database trigger level. UPDATE and DELETE statements are rejected.
If your compliance team needs documentation — architecture diagrams, control mappings, or answers to a vendor questionnaire — we respond directly. Contact us at info@getlumecrm.com.