Healthcare HIPAA platforms: an architecture brief

HIPAA-aligned healthcare platforms have a specific architectural shape. Most attempts to build them by teams without HIPAA experience fail in the same predictable ways: PHI in places it shouldn’t be, audit logs that don’t satisfy auditor requirements, BAA gaps in the third-party stack, deletion workflows that don’t actually delete. The fixes are expensive after the fact and cheap to design in upfront.

This is the architecture brief we hand to clients building HIPAA-aligned platforms in 2026.

The PHI boundary

The single most important architectural decision is where PHI (Protected Health Information) is allowed to exist. The right answer is: as few places as possible, with explicit boundaries.

The pattern we ship:

1. PHI lives in a designated PHI store (typically an encrypted RDS instance, encrypted at rest with KMS, in a private subnet, no public IP).
2. All PHI access is mediated by an application layer with structured logging of every read and write.
3. No PHI in logs, no PHI in metrics, no PHI in error messages. Application code uses PHI-safe identifiers (internal IDs, not patient names) in all observability surfaces.
4. No PHI in third-party services without a BAA. Anthropic, OpenAI, Stripe, Twilio, and most major cloud providers will sign BAAs; many smaller SaaS vendors will not. Architecture is designed around the BAA-eligible vendor list.

The boundary is enforced by code review, by linters, and by integration tests that scan for PHI patterns in non-PHI-eligible surfaces.

Audit logging that satisfies auditors

HIPAA Security Rule §164.312(b) requires audit controls. The typical audit reads:

• Who accessed what, when, from where, with what authentication?
• Was the access authorised under the user’s role?
• For PHI access, what was the clinical or operational justification?

The architecture pattern:

1. Per-PHI-access log entry. Every read or write of a PHI record produces a log entry with: actor, action, resource, timestamp, source IP, session ID.
2. Immutable storage. Audit logs land in append-only S3 with object-lock, retention policy (typically 6 years), and KMS encryption.
3. Justification capture for sensitive accesses. For high-sensitivity PHI access (psychiatric notes, HIV status, etc.), the application requires a justification field at point of access.
4. Periodic access review. Automated reports flagging anomalous access patterns (after-hours access, cross-patient access by single user, etc.) for security team review.

This pattern satisfies typical HIPAA audits. Less rigorous patterns (best-effort logging, sampled logging, log aggregation without immutability) typically don’t.

The BAA-in-the-loop processor pattern

Every third-party that touches PHI must have a BAA. The architectural implication: the third-party list is curated, not opportunistic.

Our default BAA-aligned stack for HIPAA platforms:

• Cloud: AWS (BAA-eligible services only — see AWS HIPAA Eligibility list).
• LLMs: Anthropic via AWS Bedrock (BAA covered) or Anthropic direct with BAA.
• Database: RDS (PostgreSQL or Aurora), encrypted at rest.
• Storage: S3, encrypted at rest, with default-deny bucket policies.
• Email: AWS SES (BAA covered) or Postmark (BAA available on enterprise tier).
• SMS: Twilio (BAA covered).
• Observability: AWS CloudWatch, AWS X-Ray. Datadog requires their BAA tier.
• Payments: Stripe (BAA available, requires application).

When a client wants to add a vendor not on this list, the BAA conversation happens before the integration is built. Architecturally, the integration is gated on the BAA being signed.

Deletion that actually deletes

HIPAA’s right-of-amendment + state-level patient rights increasingly include deletion rights for non-medical-record PHI. The architecture has to support this.

The pattern we ship:

1. Soft-delete is not deletion. Marking a row deleted=true does not satisfy a deletion request. The architecture must support actual record deletion.
2. Cascading deletion across PHI stores. A patient deletion request must clear PHI from primary storage, derived caches, search indexes, audit logs (where regulation permits), and S3 backups (subject to legal hold review).
3. Audit trail of the deletion itself. The deletion operation produces an audit log entry that itself does not contain PHI but documents the request, the requesting party, and the affected record IDs.
4. Documented runbook with verification. The deletion procedure is documented, tested, and includes a verification step confirming that data is no longer queryable from any system.

Many platforms ship without (1)–(4). Patching them in later is expensive.

Common architectural mistakes

Six patterns we see in healthcare platforms built without HIPAA experience:

1. PHI in CloudWatch logs (via unfiltered application logs).
2. PHI in error tracking (Sentry / Bugsnag) without filtering.
3. PHI in third-party analytics (Mixpanel / Amplitude) without BAA.
4. PHI in email subject lines (because the email body is “secured” but the subject leaks).
5. Audit logs in mutable storage (deletable by application code).
6. No documented deletion procedure (so the procedure is invented when the first deletion request lands, often incorrectly).

All six are preventable in the original architecture and expensive to remediate later.

What we ship

For HIPAA-aligned healthcare platform clients, our default deliverables include:

• The architecture above, in the client’s AWS account, with documented data flow diagrams.
• Security control evidence kit aligned to the HIPAA Security Rule.
• BAA register tracking the third-party stack.
• Audit logging with immutable storage and 6-year retention.
• Documented deletion runbooks with verification.
• Code-review checklist enforcing the PHI boundary.

We work with the client’s HIPAA counsel on the policy and contractual layer. We don’t substitute for them. The architecture is designed to make their job tractable.

---

Read more: /sectors/healthcare · /case-studies/wound-care-ai-mobile · /build/