HIPAA Compliance for Engineers

Why Engineers Should Care

HIPAA (Health Insurance Portability and Accountability Act) is not just a healthcare regulation. If your company builds software that handles health data for hospitals, clinics, insurers, or wellness platforms, you are subject to HIPAA as a business associate. The penalties are steep: $100 to $50,000 per violation, capping at $1.9 million per violation category per year. Criminal penalties can reach $250,000 and imprisonment. OCR (the Office for Civil Rights) has collected over $130 million in enforcement actions, and they publish every case publicly.

The engineering challenge is that PHI has a much broader definition than most developers expect. It includes the obvious things like diagnoses, prescriptions, and lab results. But it also includes demographic data tied to healthcare: names, addresses, dates of birth, Social Security numbers, device identifiers, and even IP addresses when associated with a patient encounter. If your database has a row that connects a person's identity to any health-related information, that row contains PHI.

The Three Safeguard Categories

The HIPAA Security Rule organizes its requirements into three categories. All three are mandatory.

Administrative safeguards are the policies and procedures. Conduct a formal risk analysis (not optional; it is the most commonly cited deficiency in audits). Designate a security officer. Train your workforce on PHI handling. Establish sanction policies for violations. Review and update your risk analysis annually.

Physical safeguards cover facility and device controls. For cloud-native companies, most physical safeguards are inherited from your cloud provider's BAA. But you still own workstation security (encrypted laptops, screen locks, remote wipe capabilities) and media disposal (securely destroying drives that held PHI).

Technical safeguards are where engineers spend most of their time:

• Access controls - Unique user IDs, emergency access procedures, automatic logoff, encryption at rest.
• Audit controls - Record and examine all activity in systems containing PHI. Every access, every modification, every export must be logged.
• Integrity controls - Mechanisms to ensure PHI is not altered or destroyed improperly. Checksums, version history, and write-once storage.
• Transmission security - TLS 1.2+ for PHI in transit. End-to-end encryption where feasible.

Business Associate Agreements

A BAA is a legal contract between a covered entity and any vendor that will access PHI. Without a signed BAA, you cannot legally handle PHI. Full stop.

Your cloud provider must sign a BAA. AWS, GCP, and Azure all offer BAAs, but they only cover specific HIPAA-eligible services. AWS publishes a list of eligible services (currently around 130). If you store PHI in an AWS service not on that list, the BAA does not cover you. You cannot just use any service freely. You must check the eligibility list and architect accordingly.

The BAA also flows downstream. If you use a third-party logging service, email provider, or analytics tool that could touch PHI, they need a BAA too. Map every vendor in your data flow and verify BAA coverage.

Key BAA clauses engineers should understand: breach notification timelines (the BA must notify the covered entity within a specified window, typically 30-60 days), data return or destruction upon contract termination, and restrictions on subcontractor use.

The Minimum Necessary Rule

HIPAA requires that you only access, use, or disclose the minimum amount of PHI needed for a given purpose. This has direct architecture implications:

• Role-based access - Billing staff should not see clinical notes. Developers should not have production PHI access unless actively debugging a production issue (and that access should be time-bounded and logged).
• Field-level controls - If an API endpoint only needs a patient ID and appointment date, do not return the full patient record. Design APIs to return the minimum data set.
• De-identification - For analytics, reporting, and development environments, use de-identified data. HIPAA defines two methods: Safe Harbor (remove 18 specific identifiers) and Expert Determination (a statistician certifies re-identification risk is very small).

Breach Notification

A breach is the unauthorized acquisition, access, use, or disclosure of PHI. When one occurs:

1. Investigate immediately - Conduct a risk assessment using four factors: the nature and extent of PHI involved, who accessed it, whether PHI was actually acquired or viewed, and the extent to which risk has been mitigated.
2. Notify within 60 days - Affected individuals must be notified within 60 days of discovering the breach (not 60 days from when it occurred).
3. HHS notification - Breaches affecting fewer than 500 individuals can be reported annually. Breaches affecting 500+ must be reported to HHS within 60 days and to prominent media outlets in the affected state.
4. The "wall of shame" - HHS publishes all breaches affecting 500+ individuals on a public portal. This is a strong incentive to get security right the first time.

Cloud Architecture for HIPAA

Building HIPAA-compliant systems on cloud infrastructure requires deliberate service selection:

• Compute - EC2, ECS, EKS, Lambda, and Fargate are HIPAA-eligible on AWS. On GCP, use Compute Engine, GKE, Cloud Run, or Cloud Functions. Always encrypt EBS volumes and persistent disks.
• Storage - S3 (with SSE or KMS), RDS, DynamoDB, and Aurora are eligible. Enable encryption at rest by default. Use bucket policies and IAM to enforce access controls.
• Networking - Use VPCs with private subnets for PHI workloads. No public endpoints for PHI-containing services. Use VPN or PrivateLink for cross-network access.
• Logging and monitoring - CloudTrail, CloudWatch, and GuardDuty are eligible. Configure CloudTrail to log all data events for S3 buckets and Lambda functions that touch PHI. Retain logs for a minimum of 6 years (HIPAA retention requirement).
• What to avoid - Do not store PHI in services not covered by the BAA. Do not use personal AWS accounts. Do not put PHI in CloudFormation parameters, environment variables, or service tags where it might appear in non-eligible control plane logs.