Our HIPAA-compliant patient portal for a Boston-area medical practice is a good reference point for this, because the compliance requirements weren't a separate workstream from the engineering — they were the engineering. Four things came up constantly: who else touches this data, how it's encrypted, what counts as PHI versus what doesn't, and what happens if any of that goes wrong.
This article focuses on what HIPAA means for software architecture — the technical safeguards under 45 CFR §164.312. It is not a complete compliance program: regulated organizations also need documented policies, workforce access controls, training, incident response, contingency planning, and appropriate physical safeguards, alongside the technical safeguards covered here.
One administrative requirement is worth naming even in an architecture-focused piece: a current, documented Security Risk Analysis. Unlike encryption, this one isn't addressable — it's a required standard under 45 CFR §164.308(a)(1)(ii)(A), though the rule itself doesn't prescribe a universal annual schedule — HHS's guidance is that it should be an ongoing process, reviewed periodically and whenever material operational or technical changes occur, not a once-a-year form. OCR treats its absence as one of the most commonly cited failures in enforcement actions — often more common than any specific technical gap. If your organization doesn't have a current, documented risk analysis, that's a higher-priority fix than most of what follows.
Every vendor that handles PHI generally needs a BAA — not just AWS
A Business Associate Agreement is a contract that makes a vendor legally accountable for protecting PHI under HIPAA. Every vendor that creates, receives, maintains, or transmits PHI on your behalf generally needs an appropriate BAA — not just AWS (HHS does carve out specific exceptions, like certain treatment disclosures and incidental access, but they're narrow and not something to lean on as a compliance strategy). The part that trips teams up isn't signing one BAA — it's realizing how many vendors are actually "in the data path." Hosting is the obvious one. Error tracking, email delivery, SMS reminders, analytics, customer support chat widgets, log aggregation, and backup services are the ones that get missed, because none of them feel like "the healthcare system" — they're just tools a developer added. If any of them touch PHI and don't have a signed BAA, that's a HIPAA problem regardless of whether anything ever leaks.
In practice this means a BAA with AWS, plus a business-associate and subcontractor review for every other service in the stack — and a real answer, in writing, for each one about whether it ever sees PHI. The honest fix for most of these isn't "get everyone to sign a BAA" — it's designing the system so most vendors never see PHI in the first place, which is cheaper and more durable than chasing paperwork from services that were never built for this.
The vendor blind spot that's new: AI-powered tooling
The "vendors nobody thinks of" problem has a 2026-specific version: AI-assisted error tracking that triages exceptions through an LLM, a support chatbot reading ticket contents, a copilot-style feature summarizing production data — each one is a PHI egress path the same way an email service or analytics tool is, except it's usually added by a product or engineering team, not procurement, and the vendor may not offer a BAA at all. If a model provider won't sign one, wiring it to anything that can see PHI isn't a policy violation to manage around — it's simply not an option for that feature. The same instinct that keeps most vendors out of the data path in the first place — minimize what reaches them — is the right answer here too: route AI features at de-identified or non-PHI data, or don't route PHI through them at all.
How encryption actually gets used, not just claimed
For any modern cloud application, treat encryption at rest and encryption in transit as mandatory. HIPAA's Security Rule currently classifies encryption as an addressable implementation specification, not a strict universal requirement — an organization can implement an equivalent alternative if it documents why encryption isn't reasonable and appropriate for its situation. That's changing: the January 2025 HIPAA Security Rule NPRM proposes eliminating the addressable/required distinction entirely — making encryption at rest, MFA, and regular vulnerability scanning flatly mandatory rather than "implement or document why not." That's a proposed rule, not yet final, but treat "best practice" framing for these three as already dated: build as though they're required, because by the time a system built today is still in production, they likely will be. In practice this rarely changes anything: AWS requires encryption for PHI handled under its BAA, and operating without it would need an unusually strong documented justification. At rest, the database — Amazon RDS for PostgreSQL, in our case — is encrypted with AES-256, backed by AWS KMS-managed keys, including automated snapshots (an unencrypted snapshot of an encrypted database is a real, common way teams accidentally create an unprotected copy of PHI). In transit, everything runs over TLS 1.2+, so data is never readable in flight between the app, the database, and the browser. The services differ on other clouds — Azure Key Vault or Google Cloud KMS instead of AWS KMS, Azure Monitor or Cloud Audit Logs instead of CloudTrail — but the underlying requirement is identical regardless of provider.
Encryption alone doesn't satisfy HIPAA's audit requirement, though — you also need to know who accessed what, when. It's worth being precise about what AWS CloudTrail and CloudWatch actually give you here: infrastructure and service-level audit evidence — API calls, console actions, resource changes — not record-level PHI access. CloudTrail doesn't automatically know that an authenticated user opened a specific patient's record; the application has to log that itself: who viewed, created, changed, exported, or disclosed a given patient's information, and when — written to an append-only, tamper-evident store, since an audit log an administrator can quietly edit isn't one OCR will credit as a real control. CloudTrail and CloudWatch cover the infrastructure layer, sitting inside a VPC with private subnets so the data tier isn't reachable from the public internet at all regardless of application-layer bugs; the application-level audit log covers the PHI-access layer, and HIPAA requires both.
Separating PHI from everything else is an architecture decision, not a label
The cheapest way to reduce HIPAA risk is to minimize how much PHI your system actually holds. The patient portal doesn't attempt to become a second medical record — it uses HL7/FHIR integration to pull provider schedules and push appointment data back to the practice's existing EHR, which stays the system of record for clinical data. The portal stores what it needs for scheduling, intake, and messaging; it doesn't duplicate the chart.
The same principle applies inside the data model, not just at the system boundary: PHI-bearing tables live in their own clearly-scoped part of the schema, distinct from operational data — plan tiers, usage logs, marketing preferences — that never needs BAA-grade controls at all. Concretely, that means the join between the two lives behind an opaque identifier: an appointment or patient row gets referenced elsewhere in the system by a surrogate key, not by name, date of birth, or diagnosis, so a reporting query can join on "patient #4471" without that query or its output ever needing to retrieve direct identifiers or sensitive clinical fields. This does not automatically make the resulting data de-identified under HIPAA — a surrogate key can still be linkable back to a specific person, and formal de-identification requires satisfying HIPAA's Safe Harbor method or Expert Determination standard, not just swapping a name for an ID. What it does do is keep routine reporting and analytics workloads from unnecessarily touching PHI at all. Fields that are PHI but still need to be searchable or joinable in a limited way — an identifier used for lookups, say — are candidates for column-level encryption rather than table-level encryption alone, so the specific sensitive fields carry their own protection independent of where the row physically lives. That separation is what keeps most analytics and reporting work out of PHI's blast radius entirely, without pretending the underlying data has been de-identified when it hasn't.
This is the same instinct as keeping a search index as a thin layer over the real data or not giving a function more access than the one thing it actually needs — scope the sensitive surface down to exactly what has to be sensitive, and everything around it gets simpler and cheaper to secure.
What it actually costs to get this wrong
HHS's Office for Civil Rights enforces HIPAA through a tiered civil penalty structure. As of the 2024 inflation-adjusted figures HHS publishes, per-violation tier minimums start around $137, and the annual cap per identical violation category runs up to roughly $2.1 million — these get inflation-adjusted again periodically, so check HHS's current schedule at the link above rather than treating these as fixed. That's before the costs that actually dominate: mandatory breach notification to every affected patient (and to HHS, and to media if over 500 records are involved), a corrective action plan and follow-up audits, and the reputational cost of a healthcare practice or partner deciding you're no longer someone they can work with. Industry breach-cost research (IBM's Cost of a Data Breach report, among others) has consistently found healthcare breaches to be the most expensive of any sector — IBM's 2025 report puts the global average healthcare breach at $7.42 million, with overall U.S. breach costs now exceeding $10 million, once notification, remediation, legal exposure, and lost business are counted.
The number that matters most in practice isn't the fine — it's that a documented HIPAA failure follows a vendor. Healthcare organizations doing due diligence ask about your compliance history, and "we had a breach" is disqualifying in a way that "our fine was survivable" doesn't capture.
Leaning on third parties for risk mitigation: the real trade-off
AWS being HIPAA-eligible does a genuine amount of work for you — physical security, infrastructure compliance certifications, mature encryption and audit primitives (KMS, CloudTrail) that would be expensive and risky to build yourself, and a signed BAA covering the infrastructure layer. That's a real advantage: it shifts a large compliance burden onto a vendor built to carry it, and it gets a compliant system to production faster than building the equivalent controls from scratch.
The disadvantage is the shared responsibility model itself: AWS being HIPAA-eligible does not make your application HIPAA-compliant. That's on how you configure it — VPC isolation, encryption settings, IAM policies, logging — and no vendor BAA covers a misconfigured security group or a debug endpoint that logs PHI to a non-BAA'd error tracker. Every additional third-party service is also another BAA to track, another vendor whose own security posture becomes your risk, and another place someone can quietly wire up PHI access without anyone noticing during a code review. Third parties reduce infrastructure risk; they don't remove the need to actually design the system correctly.
A HIPAA technical safeguards checklist
Everything above rolls up into a short list of things a real HIPAA-facing system needs to have an actual answer for — not just the architecture pieces, but the operational ones that go with them:
- HIPAA risk analysis — a documented, ongoing analysis of where PHI lives and what could go wrong, reviewed periodically and after material changes, not on a fixed annual clock.
- Role-based access control and MFA — least-privilege access to PHI, with multi-factor authentication on anything that can reach it.
- Application-level audit logs — who viewed, created, changed, exported, or disclosed a specific patient's data, and when.
- Encryption at rest and in transit — treated as mandatory in practice, per the earlier note.
- Backup and disaster recovery — encrypted backups, tested restores, and a documented recovery plan.
- Incident response — a plan for what happens in the first 24 hours of a suspected breach, before you're improvising one.
- Data retention and secure deletion — policies for how long PHI is kept and how it's actually destroyed when it isn't anymore.
- Vendor and BAA management — a living list of every vendor touching PHI and the status of each agreement.
- HIPAA-eligible AWS services — using only the services AWS has designated eligible for PHI under its BAA, not assuming every AWS service qualifies.
Where this leaves you
None of this is exotic — VPC isolation, encrypted RDS, CloudTrail, least-privilege IAM, a real BAA review of every vendor, and a data model that keeps PHI's footprint small are all well-understood patterns. The failures we see aren't usually sophisticated attacks; they're a logging tool, an email service, or a support widget that quietly started seeing PHI without anyone deciding that on purpose. If you're building or inheriting a system that touches patient data, see how we approach HIPAA-compliant architecture, or tell us what your current stack looks like and we'll give you a straight read on where the actual exposure is.