HIPAA Is An Architecture Problem, Not a Checkbox
Most developers treat HIPAA compliance as something you bolt on at the end — add encryption, sign a BAA, call it done. That approach produces software that is neither truly secure nor legally compliant.
HIPAA compliance starts with how you design your data model, not how you deploy it.
What Counts as PHI?
Protected Health Information (PHI) is broader than most developers assume. It includes:
- Names combined with any health condition, treatment, or payment
- Dates of service, birth dates, or discharge dates linked to an individual
- Phone numbers, email addresses, IP addresses when connected to health data
- Device identifiers and serial numbers
- Any information that could reasonably identify a patient
The common mistake: storing demographics and clinical data in the same database as application data with no separation or additional protection layer.
The Technical Requirements That Actually Matter
Encryption at rest and in transit: AES-256 for stored data, TLS 1.2+ for transmission. AWS RDS supports encryption at rest natively — enable it at creation, not retroactively.
Audit logging: Every access to PHI must be logged with user identity, timestamp, and action. This is not optional. Your logs need to answer "who accessed patient John Doe's record on March 3rd at 2:14am" with certainty.
Access controls: Role-based access where the minimum necessary principle applies. Nurses should not access billing records. Billing should not access clinical notes. Implement this at the data layer, not just the UI layer.
Automatic logoff: Sessions must terminate after a defined period of inactivity. 15 minutes is a common clinical standard.
Business Associate Agreements: Every vendor that touches PHI — AWS, Twilio, SendGrid, your analytics platform — needs a signed BAA. AWS offers one. Many SaaS tools do not. If your analytics vendor cannot provide a BAA, you cannot use them for PHI-touching features.
The Architecture Pattern We Use
We keep PHI in a separate database schema with its own access controls, encrypt identifiers before storing them in application tables, route all PHI queries through an audit-logging middleware layer, and deploy on AWS HIPAA eligible services with signed BAAs in place.
This architecture makes compliance audits straightforward because the compliance controls are structural, not procedural.
What a BAA Does Not Cover
Signing a Business Associate Agreement with AWS does not make your application HIPAA compliant. It means AWS's infrastructure obligations are defined. Your application's security posture is still entirely your responsibility.
We have seen startups announce "we are HIPAA compliant" after clicking accept on the AWS BAA. That is not compliance. That is liability.
Build the compliance into the architecture first. Then the BAA is just paperwork.