HIPAA-compliant architecture is six concrete things in your build, not a document you sign before launch: encryption at rest and in transit, an audit log of every access to protected health information, least-privilege access controls, a signed business associate agreement with every vendor that can touch the data, PHI kept apart from everything that isn’t PHI, and breach detection that alerts a human. The HIPAA Security Rule names the technical safeguards in 45 CFR 164.312. Your architecture implements them or it doesn’t. And the bar is moving: a federal proposal published January 6, 2025 would make encryption and multi-factor authentication mandatory instead of addressable.
We’re gmware, a custom software development firm in Austin, TX with engineering centers in Bangalore and Mohali, India, and healthcare builds are part of our delivery history. What follows is the architecture conversation we have before any code gets written: the six things a build has to do to hold PHI, in plain terms, with the trap that hides inside each one.
One opinion up front. The expensive HIPAA mistake isn’t missing a safeguard. It’s deciding where PHI is allowed to live after you’ve already built the system, then discovering it leaked into a logging service, an analytics tool, and three caches nobody mapped. Draw that boundary first.
What HIPAA-compliant architecture has to do
Encryption at rest and in transit
Start here because it’s the one people think they’ve handled and usually haven’t. In transit is the easy half: TLS on every connection, no plaintext anywhere, and reject anything that tries to downgrade. At rest is where it gets missed. Your primary database is probably encrypted. But PHI also sits in backups, in read replicas, in the message queue between two services, in the temp file your export job wrote, and in the cache you added for speed last quarter. Each of those is “at rest,” and each needs encryption.
The HIPAA Security Rule lists encryption as addressable rather than strictly required, which reads to a lot of teams as optional. It isn’t. Addressable means you either implement it or document a reason you didn’t plus an equivalent safeguard, and almost nobody can write that second document honestly. So the practical rule is simple: encrypt everything, everywhere PHI lands, and don’t pretend the cache doesn’t count. The January 2025 proposal would close the addressable loophole entirely, which only confirms the default you should already be running.
Audit logging of every PHI access
The audit log answers one question after the fact: who saw this patient’s record, and when. HIPAA requires you to be able to answer it, which means the log has to record every read, not just every write. That trips people up. Logging who edited a chart feels natural; logging who merely looked at it feels like overhead, right up until an investigator asks and you can’t say.
Three properties make an audit log real. It’s append-only, so a compromised account can’t erase its own tracks. It ties every entry to a unique user identity, not a shared service account that tells you nothing. And it’s queryable in something close to real time, because a log you can only grep through during an incident is the log you needed yesterday. Build it as infrastructure the application can’t bypass, not as a logging call developers remember to add. The ones they forget are the ones that matter.
Least-privilege access control and minimum necessary
HIPAA’s “minimum necessary” standard says a person gets access to the PHI their job requires and no more. In architecture terms, that’s least privilege, and the failure mode is the role that grew. Someone needed broad access for a migration two years ago and still has it. The intern’s account can read every record because nobody scoped it down. Default-deny is the only posture that survives an audit: every role starts with nothing and earns each permission for a stated reason.
Tie access to unique identities with real authentication, add multi-factor for anything that reaches PHI, and set automatic logoff so an unlocked laptop in an exam room isn’t an open door. The proposed Security Rule update would make multi-factor mandatory, so wire it in now rather than retrofitting it onto a live auth flow later. And review the access list on a schedule. Permissions only ever accumulate unless something forces them back down.
The BAA chain, including every subprocessor
A business associate agreement is the contract that makes a vendor legally on the hook for the PHI you hand it. The mistake isn’t forgetting the BAA. It’s forgetting the chain. Your cloud provider will sign one, fine. But PHI also flows to whatever you bolted on top: the logging service, the error-tracking tool, the transactional email provider, the analytics SDK, the queue, the search index. Each is a vendor that can touch the data, and each needs its own signed agreement. The cloud provider’s BAA does not reach up the stack to cover the third parties you run on its infrastructure.
This is why segmentation and the BAA chain are the same conversation. Every system PHI reaches is a system that needs a signed agreement, so the cheapest BAA chain is the one with the fewest links, which means the architecture that lets the least PHI travel. Map the data flow first, list every vendor it crosses, and get a BAA for each. The link you didn’t map is the unprotected one. A vendor that won’t sign a BAA, or buries it behind a sales call and a premium tier, is telling you something about how seriously to take the rest of their security.
PHI segmentation: shrink the blast radius
Segmentation means PHI lives in its own isolated zone, walled off from the data that isn’t health information. The payoff is the blast radius. If your analytics warehouse, your marketing tool, and your product-metrics pipeline never hold PHI, a breach in any of them is not a reportable health-data breach, and they fall outside the strictest controls. That’s a smaller attack surface, a shorter BAA chain, and a cheaper audit, all from one architectural decision.
The boundary has to be deliberate, because PHI spreads by default. It rides along in an event payload, gets denormalized into a reporting table, lands in a log line, sits in a debugging dump. Decide up front exactly which systems are allowed to hold it, then enforce the boundary so the others structurally can’t, by stripping or tokenizing PHI before data crosses into them. Doing this after launch means tracing where health data already leaked across a running system, which is the worst time to find out it’s everywhere.
Breach detection that actually alerts
The last requirement is the one that turns the audit log from forensics into defense. HIPAA expects you to be able to detect and respond to a breach, not just reconstruct it afterward. The difference between monitoring and breach detection is what you’re watching for. Uptime monitoring tells you the system is fast and healthy. Breach detection watches for the shapes of misuse: a login from a country no employee is in, an account pulling ten thousand records when the workflow touches ten, an export at 3am that matches no known job.
That only works if the audit log feeds alerts a human sees. A log nobody reads detects nothing. Wire the access record into anomaly rules, route the alerts to an on-call person, and rehearse the response before you need it. The federal proposal pushes hard in this direction with vulnerability scans every six months and an annual penetration test, which is the regulator saying out loud that “we’ll notice eventually” is no longer the standard.
How gmware builds for HIPAA
We design the PHI boundary before the first sprint, inside our healthcare software development and cybersecurity practices: Austin-based leads own the architecture, the threat model, and the BAA chain on US hours, while our Bangalore and Mohali teams build to it. That structure is also the cost story. On healthcare work, HIPAA engineering adds 20% to 30%, or $15K to $40K, on top of the base build, and a blended US-India team meets the identical compliance bar because HIPAA doesn’t care where the engineer sits. If you want the budgeting side of this, our HIPAA telehealth cost guide and medical app development guide break down where the money goes.
We’ll also tell you when the cheapest move is to hold less PHI. Plenty of products read patient data without ever storing it, which collapses the BAA chain and shrinks the audit to almost nothing. If your design can keep PHI inside the EHR’s own surface, architect for that on purpose, and our EHR integration cost guide covers what that connection actually takes.
Tell us what you’re building and what patient data it has to touch. Send us the shape of it and we’ll come back within 48 hours with a straight read on the architecture, the compliance premium, and where the PHI should and shouldn’t live.