HIPAA-Compliant Architecture Diagrams for Healthcare (2026)

HIPAA architecture diagrams are technical documentation artifacts that map how Protected Health Information (PHI) flows through a healthcare application, what controls protect it at each stage, and how the system demonstrates compliance with the HIPAA Security Rule. For health tech startups, digital health platforms, and healthcare SaaS products, a clear architecture diagram is not just good engineering practice — it is often required by compliance officers, enterprise customers, and cloud providers when executing Business Associate Agreements (BAAs). A well-structured HIPAA architecture diagram shows auditors and security reviewers exactly where PHI lives, how it's encrypted, and who can access it.

What HIPAA requires from your architecture

The HIPAA Security Rule (45 CFR Part 164) sets specific technical safeguard requirements that must be visible in your architecture:

• Access controls: Unique user identification, automatic logoff, emergency access procedures, and encryption/decryption mechanisms. Your diagram should show identity providers, role-based access control (RBAC) layers, and which services enforce authentication before accessing PHI
• Audit controls: Hardware, software, and procedural mechanisms that record and examine activity in systems containing PHI. Show your audit log pipeline — where logs are written, how they are tamper-evident, and where they are stored (immutable S3, CloudTrail, Azure Monitor)
• Integrity controls: Mechanisms to ensure PHI is not improperly altered or destroyed. Show checksums, database transaction logs, and backup procedures
• Transmission security: Encryption of PHI in transit (TLS 1.2+ for all connections, no unencrypted channels touching PHI) and at rest (AES-256 for databases, S3 objects, and backups)
• PHI data boundaries: Clear demarcation of where PHI exists in the system — which databases contain it, which services process it, and which services operate only on de-identified data — so reviewers can scope controls appropriately

Key diagram annotations for HIPAA compliance

A standard architecture diagram becomes a HIPAA compliance artifact when you add the following annotations:

• PHI boundary boxes: Draw a visible boundary (dashed red or orange box) around all components that store, process, or transmit PHI — databases, queues, object stores, caches, and any third-party APIs that receive patient data
• Encryption labels: Annotate every data store with its encryption method (AES-256 at rest, KMS key ID) and every network link touching PHI with "TLS 1.2+" or "mTLS"
• BAA coverage indicators: Mark each cloud service with its BAA status — AWS, Azure, and GCP offer BAAs for specific HIPAA-eligible services; services not covered by a BAA must not receive PHI
• Audit log flows: Show the audit log pipeline as a distinct flow in the diagram, separate from the application data flow, to demonstrate that access and modification events are captured
• De-identification boundaries: Show where PHI is de-identified (Safe Harbor or Expert Determination) so that downstream analytics systems or ML pipelines operate only on de-identified data and are out of HIPAA scope

Prompt examples for HIPAA-compliant architectures

Patient portal on AWS

Telehealth platform with video and EHR integration

Health data AI pipeline with de-identification boundary

HIPAA-eligible services reference

Common HIPAA architecture mistakes to avoid

• PHI in CloudWatch logs: Lambda functions or application services that log request payloads may inadvertently write PHI to CloudWatch — ensure logging is scrubbed or that PHI fields are excluded at the application level
• Non-BAA services receiving PHI: Third-party error monitoring (Sentry, Datadog) or analytics tools (Amplitude, Mixpanel) do not sign BAAs by default — ensure error payloads and analytics events are scrubbed before they leave the BAA boundary
• Unencrypted S3 buckets used as intermediate storage: Data pipelines that write PHI to unencrypted S3 as an intermediate step create a compliance gap — encrypt all S3 buckets in the PHI boundary at the bucket policy level
• Missing audit trail for PHI access: HIPAA requires audit logs that capture who accessed PHI and when — application-level audit logs (not just infrastructure logs) must be implemented for read operations on patient records
• De-identification applied too late in the pipeline: If de-identification happens in an analytics environment rather than before data leaves the PHI zone, the analytics environment is in HIPAA scope — apply de-identification at the PHI boundary

Related guides: zero trust architecture, EU AI Act compliance architecture, DevSecOps architecture diagrams, and authentication architecture diagrams.