The compliance industry has a misalignment problem

HIPAA compliance consulting is a $7B/year industry. A significant fraction of that is spent on audits, certifications, and tools that exist to generate audit paperwork, not to protect patient data. After building 11 HIPAA-compliant applications, here is what we have observed.

What HIPAA actually requires from software

HIPAA's Security Rule (45 CFR Part 164) applies to ePHI — electronically protected health information. The Technical Safeguards require five things:

  1. Access control — unique user IDs, emergency access procedures, automatic logoff, encryption
  2. Audit controls — mechanisms to record and examine access to ePHI
  3. Integrity — protecting ePHI from improper alteration or destruction
  4. Person or entity authentication — verifying identity before access
  5. Transmission security — encryption in transit

That is it. The regulation is intentionally technology-neutral.

What actually matters (engineering translation)

Encryption at rest
AES-256 for all ePHI storage. AWS RDS, S3 with SSE, and GCP Cloud SQL with CMEK handle this automatically. This is a configuration, not a feature you build.

Encryption in transit
TLS 1.2 minimum, TLS 1.3 preferred. Enforce ssl=require on all DB connections. Internal VPC traffic between services should also be encrypted.

Access logging (audit trail)
Every read or write of ePHI must be logged with: user ID, timestamp, action, and resource identifier. This is the one most teams underestimate. AWS CloudTrail is not sufficient by itself — it logs API calls, not "which user viewed patient record 4821."

Implementation pattern we use:

CREATE TABLE phi_access_log (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id     UUID NOT NULL,
  action      TEXT NOT NULL,
  resource    TEXT NOT NULL,
  resource_id TEXT NOT NULL,
  ip_address  INET,
  created_at  TIMESTAMPTZ DEFAULT now()
);

Every query that touches ePHI rows fires an INSERT into this table, implemented at the ORM layer so it is impossible to accidentally skip.

Minimum necessary access (RBAC)
A billing user should not see clinical notes. A nurse should not see billing records for patients on other floors. Implement RBAC with explicit permissions per PHI category.

Automatic session timeout
15-minute inactivity timeout. Simple but required.

MFA
HIPAA does not explicitly mandate MFA but it is expected by every auditor. Use TOTP (Google Authenticator / Authy).

BAAs with all vendors
A Business Associate Agreement is legally required with every vendor who touches ePHI: AWS, Twilio, SendGrid/Postmark, Sentry (configure it to scrub PHI from error reports).

What does not matter as much as vendors claim

HIPAA "certification"
There is no such thing as HIPAA certification. The regulation is enforced by HHS. A vendor selling you "HIPAA certification" is selling you a letter of attestation with no legal standing.

Penetration testing at launch
Useful, but the findings of a pentest do not make you HIPAA compliant. You need ongoing vulnerability management (quarterly scans minimum).

Storing PHI in separate "compliant databases"
Some teams create a separate database for PHI while keeping other data elsewhere. This creates join complexity and is architecturally unnecessary. Encrypt the whole database. Log access to all PHI tables.

The practical checklist

Before we launch any HIPAA application:

  • Signed BAA with AWS/GCP/Azure
  • Signed BAAs with all third-party services (error monitoring, email, SMS, analytics)
  • RDS/Cloud SQL encryption at rest enabled
  • TLS 1.2+ enforced everywhere, including internal service traffic
  • Application-level PHI access log table with 6-year minimum retention
  • RBAC with permissions scoped to PHI category
  • MFA enforced for all users
  • 15-minute session timeout
  • Sentry configured with PHI scrubbing rules
  • Incident response runbook written and tested

That list, implemented properly, is HIPAA compliance from a software engineering perspective. Everything else is documentation.