Security & Encryption

Effective June 9, 2026

This page describes the technical safeguards Epithel (operated by Bash Enterprise IO, LLC) applies to Protected Health Information ("PHI") in accordance with the HIPAA Security Rule (45 CFR Part 164 Subpart C) and Epithel's Safety and Legal Risk Profile.

1. Encryption at rest

All PHI stored in Epithel's application database and object storage is encrypted at rest using AES-256.
Encryption keys are managed by an enterprise Key Management Service (KMS) operated by our infrastructure providers under an executed Business Associate Agreement. Application code never sees the raw data-encryption keys.
Wound photographs are held in a private object-storage bucket with server-side encryption and access-controlled, short-lived signed URLs; no PHI-bearing bucket is publicly listable or publicly readable.
Automated hourly self-checks verify that PHI storage remains private and that Row-Level Security is enabled on every PHI table.

2. Encryption in transit

All connections between browsers, the Epithel application, the database, and third-party subprocessors use TLS 1.2 or higher with strong cipher suites.
HTTP requests to Epithel are automatically upgraded to HTTPS.
Session tokens are transmitted only over TLS and never logged.

3. Secrets management

API keys, signing keys, and other credentials are held in an encrypted secret vault and injected into server-side workloads at runtime. Secrets are not stored in source control, in client-side bundles, or in browser storage.
Access to production secrets is restricted, logged, and rotated on a documented schedule and immediately on suspected compromise.

4. Access control

Multi-tenant isolation is enforced in the database via Row-Level Security. Every PHI row is scoped to a facility, and every read/write is filtered by has_facility_access(user_id, facility_id). Cross-facility PHI leakage is architecturally prevented at the database layer — not merely blocked by application code that could be bypassed.
Roles are stored in a dedicated user_roles table and checked through a security-definer function to prevent privilege escalation.
PHI writes are blocked at the database trigger layer until an active, non-revoked Business Associate Agreement is on file for the facility.
The client enforces an idle-time privacy overlay and session timeout to reduce shoulder-surfing risk at the point of care.

5. Auditing & anomaly detection

Every PHI insert, update, and delete is written to an append-only audit_logs table capturing the actor, facility, entity, and timestamp.
"Break-glass" emergency accesses require a typed justification and are logged to a separate table for after-the-fact review.
A scheduled anomaly scan flags bulk PHI access, off-hours writes, and repeated break-glass use for review.

6. Shared responsibility

Epithel provides the technical controls above. Customers are responsible for provisioning and de-provisioning their staff accounts promptly, keeping devices patched, and reporting suspected incidents to Epithel without undue delay per the executed BAA.