← All articles

HIPAA Compliance for Engineers: What Actually Matters

Every healthcare startup has a "we need to be HIPAA compliant" conversation. What follows is usually a mix of anxiety, misinformation, and checkbox compliance that does not actually protect patient data. As an engineer who has built HIPAA-compliant systems from scratch, I can tell you: HIPAA is not as complicated as the compliance industry wants you to believe, but it is more specific than most engineers assume.

This guide cuts through the noise and focuses on the technical controls that matter.

What HIPAA Actually Requires (Technically)

HIPAA's Security Rule has three categories of safeguards: Administrative, Physical, and Technical. Engineers primarily own the Technical Safeguards, though you will touch all three. Here is what the Technical Safeguards actually require:

Access Controls (Required)

  • Unique user identification — every person accessing PHI must have a unique identifier. No shared accounts. No service accounts that multiple humans use.
  • Emergency access procedure — a documented process for accessing PHI in an emergency that bypasses normal controls.
  • Automatic logoff — sessions must timeout after inactivity. The regulation does not specify a duration, but 15 minutes is the de facto standard.
  • Encryption and decryption — encrypt PHI when stored (at rest) and when transmitted (in transit). This used to be "addressable" (meaning you could document why you chose not to encrypt). As of the proposed 2025 Security Rule updates, encryption is moving toward being required in all circumstances.

Audit Controls (Required)

  • Audit logs — you must record who accessed what PHI, when, and what they did with it. This is the single most important technical control. When OCR (Office for Civil Rights) investigates a breach, the first thing they ask for is audit logs.

Integrity Controls (Addressable)

  • Mechanism to authenticate PHI — ensure that PHI has not been altered or destroyed in an unauthorized manner. In practice, this means checksums or digital signatures on stored data.

Transmission Security (Required)

  • Encryption in transit — TLS 1.2+ for all data transmission. No exceptions.
  • Integrity controls — ensure data is not modified during transmission.

The Controls That Actually Save You

1. Encryption: Do It Everywhere

At rest: Use AES-256 encryption for all stored PHI. If you are on AWS, enable default encryption on S3, RDS, and EBS volumes. On GCP, use CMEK (Customer-Managed Encryption Keys) for additional control. On Azure, enable Transparent Data Encryption for SQL databases.

In transit: TLS 1.2 minimum, TLS 1.3 preferred. This covers API calls, database connections, and internal service-to-service communication. Yes, even within your VPC. Internal network traffic encryption is increasingly expected.

Application-level encryption: For particularly sensitive fields (SSN, diagnosis codes), consider application-level encryption on top of storage-level encryption. This protects against database admin access and certain classes of attack that bypass storage encryption.

// Example: field-level encryption for sensitive data
import { createCipheriv, createDecipheriv, randomBytes } from 'crypto';

function encryptField(plaintext, key) {
  const iv = randomBytes(16);
  const cipher = createCipheriv('aes-256-gcm', key, iv);
  let encrypted = cipher.update(plaintext, 'utf8', 'hex');
  encrypted += cipher.final('hex');
  const authTag = cipher.getAuthTag();
  return `${iv.toString('hex')}:${authTag.toString('hex')}:${encrypted}`;
}

2. Audit Logging: Your Most Important Control

When a breach happens (not if), OCR will ask: "Show us who accessed this patient's data in the last 90 days." If you cannot answer that question definitively, you are in serious trouble.

What to log:

  • User identity (who)
  • Action performed (read, write, delete, export)
  • Resource accessed (which patient, which record)
  • Timestamp (when, in UTC)
  • Source IP address (where)
  • Success or failure (outcome)

How to implement:

  • Use structured logging (JSON) with immutable storage (append-only log streams)
  • Ship logs to a centralized, tamper-evident store (CloudWatch Logs, Datadog, Splunk)
  • Set retention to minimum 6 years (HIPAA requires 6 years for policies; OCR investigations can look back this far)
  • Make logs queryable — you need to answer "show me all access to Patient X" quickly

3. Access Controls: Least Privilege, Enforced

Role-based access control (RBAC) is the minimum. For healthcare applications:

  • Clinicians see only their patients (or their organization's patients)
  • Admin staff see demographic and billing data, not clinical notes
  • Support engineers access de-identified or synthetic data, never production PHI
  • System accounts have narrowly scoped permissions with audit trails

Break-glass procedures must exist for emergencies. A clinician treating a walk-in patient in an emergency needs access immediately, not after a 2-hour approval workflow. Log the break-glass access, review it retroactively, but do not block care.

4. Business Associate Agreements (BAAs)

If any third-party service touches PHI, you need a BAA with them. This includes:

  • Cloud providers (AWS, GCP, Azure all offer BAAs)
  • Email services (Resend, SendGrid — make sure they sign a BAA)
  • Analytics services (most analytics tools cannot sign a BAA; do not send PHI to them)
  • Monitoring and logging services
  • Payment processors (if they see patient identifiers alongside payment data)

Common mistake: Using a service that explicitly does not support PHI (like standard Google Analytics) and sending it patient-identifiable data. This is a breach waiting to happen.

The 2025-2026 Security Rule Changes

The HHS proposed significant updates to the HIPAA Security Rule in late 2024, with finalization expected in 2025-2026. Key changes engineers should prepare for:

  • Encryption becomes required (no longer addressable) — if you are not already encrypting everywhere, start now
  • Multi-factor authentication becomes required for all PHI access
  • 72-hour incident notification — security incidents must be reported more quickly
  • Annual security risk assessments are explicitly required
  • Technology asset inventory — you must maintain an inventory of all systems that touch PHI

Architecture Patterns for HIPAA Compliance

The Segregated Data Pattern

Keep PHI in its own data store, separate from application data. The application layer queries PHI through a dedicated service with access controls and audit logging built in.

[App Layer] → [PHI Access Service] → [Encrypted PHI Store]
                    ↓
              [Audit Log Stream]

This pattern makes it easy to answer "where is PHI in our system?" and simplifies BAA scope.

The De-identification Pipeline

For analytics and reporting, de-identify data before it leaves the PHI boundary. HIPAA defines two methods: Safe Harbor (remove 18 specific identifiers) and Expert Determination (statistical verification that re-identification risk is minimal).

For most engineering teams, Safe Harbor is the practical choice. Strip names, dates (generalize to year), zip codes (truncate to first 3 digits), and all unique identifiers.

Infrastructure Isolation

Run PHI workloads in a dedicated VPC or account. This creates a clear compliance boundary and simplifies audit scope. AWS Organizations with dedicated accounts for PHI workloads is a common and effective pattern.

What Does Not Matter (as Much as You Think)

  • Specific technology choices — HIPAA does not mandate any specific technology. PostgreSQL, MongoDB, DynamoDB — all are fine if properly configured with encryption and access controls.
  • SOC 2 Type II certification — helpful but not a substitute for HIPAA compliance. SOC 2 covers general security controls; HIPAA has specific PHI requirements that SOC 2 does not address.
  • Perfect prevention — HIPAA does not require that breaches never happen. It requires reasonable safeguards, documentation, and proper response when breaches occur. The emphasis is on "did you take reasonable steps?" not "did you prevent all possible attacks?"

Getting Started

  1. Conduct a risk assessment — identify where PHI lives in your system, who can access it, and what controls protect it
  2. Implement encryption at rest and in transit for all PHI
  3. Build audit logging from day one — retrofitting it is painful
  4. Execute BAAs with every service that touches PHI
  5. Document everything — policies, procedures, risk assessments, training records
  6. Train your team — annual HIPAA training is required and should cover real scenarios, not just slide decks

Building a HIPAA-compliant healthcare application? 1Putt Health helps digital health teams design compliant architectures, implement security controls, and prepare for audits. Book a Discovery Call to discuss your compliance needs.