Building software that handles protected health information (PHI) is not a matter of adding encryption and checking a compliance box. HIPAA compliance is a set of technical, administrative, and physical safeguards that must be woven into every layer of your application, from infrastructure provisioning to API design to employee training. Getting it wrong carries penalties up to $2.13 million per violation category per year, plus the reputational damage that can end a healthcare technology company. Getting it right opens access to a $370 billion U.S. healthcare IT market that most software vendors are afraid to enter.
Understanding What HIPAA Actually Requires
HIPAA is not a single standard. It is a set of rules, and the ones that matter for software development are the Privacy Rule, the Security Rule, and the Breach Notification Rule.
The Privacy Rule defines what PHI is and how it can be used or disclosed. PHI includes any individually identifiable health information: names, dates, medical record numbers, Social Security numbers, biometric identifiers, and 14 other categories of identifiers when combined with health data. The Privacy Rule does not prescribe specific technologies. It prescribes principles: minimum necessary access, patient rights to their data, and limitations on disclosure.
The Security Rule is where software engineering intersects with compliance. It requires three categories of safeguards for electronic PHI (ePHI):
- Administrative safeguards: Risk analysis, workforce training, contingency planning, information access management, and security incident procedures.
- Physical safeguards: Facility access controls, workstation security, and device and media controls.
- Technical safeguards: Access controls, audit controls, integrity controls, transmission security, and authentication.
The Breach Notification Rule requires notification to affected individuals within 60 days of discovering a breach, notification to HHS, and for breaches affecting 500+ individuals, notification to media outlets. The definition of “breach” is broad: any unauthorized acquisition, access, use, or disclosure of PHI, unless you can demonstrate a low probability that PHI was compromised.
A critical point that many development teams miss: HIPAA does not specify technologies. It does not mandate AES-256 encryption, specific database platforms, or particular authentication protocols. It requires “reasonable and appropriate” safeguards based on the organization’s size, complexity, and risk profile. This is both liberating (you have architectural flexibility) and challenging (you must justify your choices through documented risk analysis).
The Business Associate Agreement: Your Legal Foundation
If you are building software that handles PHI on behalf of a healthcare organization (a “covered entity”), you are a “business associate” under HIPAA. Before you touch any PHI, you need a Business Associate Agreement (BAA) with every covered entity you serve and with every subcontractor who handles PHI on your behalf.
This means BAAs with: - Your cloud provider (AWS, Google Cloud, and Azure all offer BAAs) - Your database hosting provider - Your email service provider if any PHI travels through email - Your monitoring and logging tools if they capture PHI in logs - Your error tracking service (Sentry, Datadog, etc.) if error reports might contain PHI - Your backup and disaster recovery providers
AWS signs BAAs for eligible services (a specific list, not all services). Google Cloud signs a comprehensive BAA covering all Cloud services. Azure has a similar arrangement. Critically, the BAA must be signed before PHI enters the system. Retroactive BAAs do not resolve prior compliance violations.
Vendors without BAAs are off-limits for PHI workflows. This eliminates many popular tools. You cannot send PHI through a standard Twilio SMS (though Twilio does offer a HIPAA-eligible product). You cannot store PHI in a standard Firebase database (Google Cloud’s HIPAA-eligible services are distinct from Firebase’s consumer offerings). You cannot log PHI to a monitoring service that has not signed a BAA.
Encryption Architecture: At Rest and In Transit
HIPAA’s Security Rule requires both encryption at rest and encryption in transit for ePHI. While the regulation technically lists encryption as an “addressable” specification (meaning you can document an alternative if encryption is not “reasonable and appropriate”), in practice, no auditor will accept an unencrypted system. Encryption is a baseline requirement.
Encryption at rest. All databases, file storage, and backups containing PHI must be encrypted. On AWS, enable encryption for RDS instances (AES-256 via AWS KMS), S3 buckets (SSE-S3 or SSE-KMS), and EBS volumes. On Google Cloud, data is encrypted at rest by default, but use Customer-Managed Encryption Keys (CMEK) for additional control and auditability.
Database-level encryption protects against physical media theft and unauthorized access to storage. Application-level encryption protects specific fields (Social Security numbers, diagnosis codes) even from database administrators. For the most sensitive fields, implement application-level encryption using a library like AWS Encryption SDK or Google Tink, with keys managed in a hardware security module (HSM) through AWS KMS or Google Cloud HSM.
Encryption in transit. All API communication must use TLS 1.2 or higher. Enforce HTTPS with HSTS headers. Internal service-to-service communication should also be encrypted, even within a VPC. Use mutual TLS (mTLS) for service-to-service authentication in microservices architectures. Terminate TLS at the load balancer for external traffic, and use encrypted connections from the load balancer to application instances.
Key management deserves dedicated attention. Use a managed KMS (AWS KMS, Google Cloud KMS, Azure Key Vault) rather than managing keys yourself. Implement key rotation on a defined schedule (annually at minimum). Maintain key access logs and restrict KMS key usage to specific IAM roles. The principle: even if an attacker gains access to encrypted data, they should not be able to access the keys through the same path.
See also: HIPAA Patient Portal Development
Access Controls and Audit Logging
The Security Rule requires access controls that limit PHI access to authorized users and audit trails that record every access.
Role-based access control (RBAC) with minimum necessary. HIPAA’s “minimum necessary” principle requires that users access only the PHI they need for their specific role. A billing specialist needs patient financial data but not clinical notes. A nurse needs clinical data for their assigned patients but not patients on another floor. Implement RBAC with granular permissions tied to specific data categories and patient populations.
Attribute-based access control (ABAC) extends RBAC for complex scenarios: “Dr. Smith can access clinical records for patients assigned to her, in departments she is credentialed for, during her shift hours.” ABAC policies are more expressive but harder to audit. Many healthcare applications use RBAC as the foundation with ABAC overlays for specific requirements.
Automatic session management. Sessions must time out after a period of inactivity. HIPAA does not specify the duration, but 15 minutes is the de facto standard in healthcare. Implement server-side session expiration (not just client-side timers that can be bypassed) and require re-authentication after timeout.
Audit logging must be comprehensive and tamper-evident. Log every access to PHI: who accessed it, when, from what IP address, what action they took, and what data they viewed or modified. Log failed access attempts. Log administrative actions (role changes, permission grants, configuration modifications).
Store audit logs in a write-once, tamper-evident system. AWS CloudTrail combined with S3 Object Lock (in compliance mode) provides immutability. Alternatively, stream logs to a dedicated log management system with its own access controls, separate from the application’s database administrators.
HIPAA requires audit log retention for six years. Plan your storage accordingly: a system processing 10,000 PHI access events per day generates roughly 15 GB of audit data per year, depending on log verbosity.
Infrastructure and Deployment Considerations
Network isolation. PHI-handling components should run in isolated network segments. On AWS, use a dedicated VPC with private subnets for application servers and databases. No PHI-handling resource should have a public IP address. Access from the internet flows through a load balancer in a public subnet; everything else is private. Use security groups and network ACLs to restrict traffic to only the necessary ports and source addresses.
Backup and disaster recovery. HIPAA’s contingency plan requirements mandate data backup, disaster recovery, and emergency mode operation plans. Implement automated daily backups with cross-region replication. Test recovery procedures quarterly and document the results. Define and test your Recovery Time Objective (RTO) and Recovery Point Objective (RPO). For most healthcare applications, an RTO under 4 hours and an RPO under 1 hour is appropriate.
Vulnerability management. Conduct vulnerability scans monthly and penetration tests annually. Remediate critical vulnerabilities within 72 hours and high vulnerabilities within 30 days. Document your vulnerability management process, scanning cadence, and remediation timelines. Tools like Qualys, Nessus, or AWS Inspector automate scanning. Third-party penetration testing firms provide the external perspective that internal scans miss.
Secure development lifecycle. Train developers on HIPAA requirements and secure coding practices annually. Implement code review processes that include security review for any code touching PHI. Use static analysis tools (Semgrep, SonarQube) configured with healthcare-specific rules to catch common vulnerabilities. Maintain a software bill of materials (SBOM) and monitor dependencies for known vulnerabilities.
Risk Analysis: The Document That Ties It All Together
HIPAA requires a documented risk analysis that identifies threats to ePHI, assesses the likelihood and impact of each threat, and documents the safeguards in place to mitigate each risk. This is not a one-time exercise. It must be reviewed and updated whenever the system changes significantly.
A practical risk analysis for a healthcare application includes:
- Asset inventory: every system, database, and third-party service that handles ePHI.
- Threat identification: unauthorized access, data interception, insider threats, malware, natural disasters, vendor failures.
- Vulnerability assessment: for each threat, what vulnerabilities could be exploited?
- Risk rating: likelihood x impact for each threat-vulnerability pair.
- Mitigation measures: what safeguards address each risk? Are they implemented and tested?
- Residual risk acceptance: what risks remain after mitigation, and has leadership formally accepted them?
This document is the first thing an auditor requests. It is also the document that transforms HIPAA compliance from a checklist into a genuine security program. The process of creating it forces you to think systematically about where PHI lives, how it moves, and what could go wrong.
Building HIPAA-compliant software is more work than building a standard web application. But it is not mysterious. It is a known set of requirements applied to your specific architecture, documented in your risk analysis, implemented in your code and infrastructure, and verified through regular audits.
Need to build healthcare software that meets HIPAA requirements without slowing development to a crawl? Let us talk about your project. We have built compliant systems that pass audits and ship on schedule.