HIPAA-compliant software: the architecture and the parts teams get wrong

01What actually falls in scope

The Security Rule applies to electronic protected health information - health information that identifies an individual. The scope question that catches teams out is that PHI does not stay where you put it. It ends up in application logs, error tracking payloads, database backups, analytics events, support tickets and local development environments.

Scope reduction is the highest-leverage architectural decision available. The less of your system that touches PHI, the smaller your compliance surface, and the cheaper every subsequent audit becomes. Isolate PHI into a well-defined boundary rather than letting it diffuse through the application.

• Identify every store, log and third party that could receive PHI.
• Scrub PHI from logs and error reporting at source, not in review.
• Keep PHI out of analytics events entirely.
• Never use production PHI in development or test environments.
• Treat backups and exports as in-scope, because they are.

02The Security Rule, translated for engineers

The Security Rule divides into administrative, physical and technical safeguards. Some are required, others are 'addressable', which does not mean optional - it means you either implement it or document a reasoned justification and an equivalent alternative.

03Audit logging is where implementations fail

The requirement is to record and examine activity in systems containing PHI. Teams generally implement the recording and neglect the examining, then discover during audit that they have logs nobody has ever reviewed and no process for reviewing them.

The logs also need to be genuinely useful. Recording that a user called an endpoint is insufficient; you need to know whose PHI was accessed, by whom, when and from where. And the logs must be tamper-evident - an administrator who can quietly delete access records defeats the purpose of keeping them.

• Log the subject of the PHI accessed, not just the endpoint called.
• Make logs append-only and separate from application infrastructure.
• Retain in line with your policy - six years is the common benchmark.
• Implement an actual review process, with evidence that it happens.
• Alert on anomalous access patterns rather than reviewing only on request.

04Business Associate Agreements and the vendor chain

Any vendor that handles PHI on your behalf needs a BAA, and that includes cloud providers, error tracking, log aggregation, email delivery, analytics and any development partner with production access. The major cloud providers all sign BAAs, but the BAA typically covers only a defined subset of their services.

Using a non-covered service for PHI puts you out of compliance even though your provider is 'HIPAA compliant' in general. Check the covered-services list rather than the marketing page, and re-check it when you adopt a new managed service.

05A pragmatic implementation order

For a team starting from nothing, the sequence below front-loads the controls that reduce risk most and are hardest to retrofit. Documentation matters, but it should describe a system that exists rather than one you intend to build.

• Define the PHI boundary architecturally before writing schema.
• Encryption in transit and at rest, with managed keys.
• Unique identity, RBAC and MFA for anything touching PHI.
• Audit logging with the subject recorded, append-only.
• PHI scrubbing in logging and error-reporting pipelines.
• BAAs with every in-scope vendor, checked against covered-services lists.
• Risk analysis and policies documenting what you actually do.