HIPAA Compliance: An Engineer's Practical Guide
I've been building HIPAA-compliant systems for most of my career. And I can tell you that most engineers' understanding of HIPAA falls into one of two categories: "I have no idea what's required" or "I think we need to encrypt everything and we're good."
Neither is right. Here's what you actually need to know.
HIPAA in 60 Seconds
HIPAA (Health Insurance Portability and Accountability Act) protects patient health information (PHI). If your software touches PHI — names, diagnoses, medications, insurance info, anything that can identify a patient in a healthcare context — you need to comply.
The key rules that affect engineers:
- Privacy Rule: Limits who can access PHI and for what purpose
- Security Rule: Requires administrative, physical, and technical safeguards
- Breach Notification Rule: You must report breaches within specific timeframes
What This Means in Code
Encryption at rest and in transit. This is the easy part. TLS for all network communication, AES-256 for stored data. Most cloud providers handle this by default now, but you need to verify it's configured correctly.
Access controls. Not everyone who can log into your system should see PHI. Implement role-based access control (RBAC) that limits access to the minimum necessary. Log every access event.
Audit trails. Every time PHI is accessed, modified, or transmitted, it must be logged. Who, what, when, from where. These logs need to be tamper-resistant and retained for at least six years.
Minimum necessary standard. Your API shouldn't return a patient's entire record when the requesting service only needs their eligibility status. Design your interfaces to return only the data that's needed for the specific purpose.
Business Associate Agreements (BAAs). Every third-party service that touches PHI needs a BAA. That includes your cloud provider, your logging service, your email provider — anything that could see PHI.
Common Mistakes
Logging PHI in application logs. I've seen this more times than I can count. An engineer adds debug logging that includes patient names or IDs, and suddenly your application logs — which probably don't have the same security controls as your database — contain PHI.
Solution: build a PHI-aware logging framework that automatically redacts sensitive fields. Make it the default, not the exception.
PHI in error messages. Similar problem. An API returns an error like "Patient John Smith (ID: 12345) not found." That error message just leaked PHI.
Solution: use opaque references in error messages and log the details server-side only.
Forgetting about backups. Your database is encrypted. Great. Are your backups? Are they stored in a location covered by your BAA? Can they be accessed by people who shouldn't have access to PHI?
Development environments. Using production data in development is a HIPAA violation if those environments don't have the same controls. Use synthetic data or properly de-identified data for development and testing.
The Architecture Approach
The approach I've found most effective is to create a clear PHI boundary in your system architecture. Designate specific services as "PHI-handling" and apply the strictest controls there. Other services communicate with them through well-defined interfaces that never expose raw PHI.
This is where bounded contexts from DDD align beautifully with compliance requirements. Your PHI-handling bounded context has its own data store, its own access controls, its own audit logging. Other contexts get only the data they need, in the form they need it.
It's Not Just About Fines
Yes, HIPAA violations can result in significant fines. But the real reason to care about compliance is simpler: you're protecting real people's most sensitive information. The moment you internalize that, compliance stops feeling like a burden and starts feeling like a responsibility.
Build systems that treat patient data with the respect it deserves. The regulatory compliance will follow naturally.