Building HIPAA-Compliant Software: Architecture Decisions That Matter

If you are building software that touches Protected Health Information (PHI), HIPAA compliance is not something you bolt on after launch. It is an architecture decision that affects your database design, your API structure, your deployment infrastructure, and your team's development workflow. Getting it wrong is not just a regulatory risk -- it is a fundamental security failure.

Encryption: At Rest and In Transit

This is the baseline. All PHI must be encrypted at rest (AES-256 is the standard) and in transit (TLS 1.2 or higher). But encryption alone is not sufficient -- you also need proper key management. Your encryption keys should never live in the same system as the data they protect.

On AWS, this means using KMS (Key Management Service) for key management, enabling default encryption on RDS and S3, and ensuring all internal service-to-service communication uses TLS. On other cloud providers, the equivalent services exist -- the principle is the same.

Access Controls and the Minimum Necessary Rule

HIPAA's "minimum necessary" rule means that every user, service, and system should only have access to the PHI they need to perform their function. In practice, this means:

• Role-based access control (RBAC) at the application level -- a DSP sees their own clients, a supervisor sees their team, an admin sees aggregate data
• Row-level security in the database -- even if a query runs, it should only return rows the authenticated user is authorized to see
• API-level authorization -- every endpoint checks both authentication (who you are) and authorization (what you can access)
• Infrastructure-level isolation -- production databases are not accessible from development environments

Audit Logging

Every access to PHI must be logged. Not just logins -- every read, write, update, and delete of protected data. These audit logs must be tamper-proof (write-once storage), retained for at least six years, and available for review during audits.

The audit log should capture: who accessed the data, when, from what IP address, what action they took, and which records were affected. On AWS, CloudTrail handles infrastructure-level logging, but you still need application-level audit logs for PHI access within your own system.

The Business Associate Agreement

Every third-party service that touches PHI needs a signed Business Associate Agreement (BAA). This includes your cloud provider, your database hosting, your email service (if you send PHI via email), your monitoring tools, and any API integrations. AWS, Google Cloud, and Azure all offer BAAs -- but you need to execute them explicitly. Services not covered by a BAA cannot process PHI.

Infrastructure Choices

Not all cloud services are HIPAA-eligible. On AWS, for example, only specific services are covered under the BAA. Before using any service to store or process PHI, verify it is on your cloud provider's HIPAA-eligible services list. Common gotchas: some managed services that seem like obvious choices (certain serverless offerings, specific caching layers) may not be HIPAA-eligible.

Your deployment architecture should include network isolation (VPCs with private subnets for databases), security groups that follow least-privilege principles, and automated vulnerability scanning for your application containers.

Development Workflow

HIPAA compliance affects how your team works day to day. Developers should never have access to production PHI -- use synthetic test data in development and staging environments. Code reviews should include security considerations. Dependency updates should be automated and timely, since unpatched vulnerabilities are a compliance violation.

At FY Network, we build HIPAA compliance into our development process from the start. Our infrastructure runs on AWS with an executed BAA, all PHI is encrypted with KMS-managed keys, and our audit logging captures every data access event. This is not a feature we market -- it is how we build.