You're building healthcare software. Somewhere between the demo and the contract, a hospital's security team sends you a 200-line questionnaire, your customer's lawyer asks you to sign a BAA, and your investor asks whether you're "HIPAA compliant" as if that were a checkbox.
It is not a checkbox. There is no certificate. No auditor stamps your forehead. HIPAA compliance is a property of your system — how PHI moves, who can touch it, what you can prove after the fact. Either your architecture supports those properties or it doesn't.
The teams that treat it as a checklist discover the truth during their first real security review: their database has no field-level controls, their logs include patient names in plaintext, and three of their subprocessors never signed a BAA. The fix is not a policy document. It's a rebuild.
PHI is a data-flow problem before it's a policy problem
The first question is not "are we encrypted." It's "where does PHI go." Most teams cannot answer this. PHI leaks into places nobody intended: error-tracking payloads, analytics events, support tickets, CDN logs, that one debug endpoint someone left in.
Before you write a line of compliance policy, draw the actual flow. Every system that touches a name, a medical record number, a diagnosis, a date of birth tied to a patient. Email addresses. IP addresses in some contexts. The flow has to include the boring edges — the queue, the cache, the backup, the third-party email provider.
// the PHI inventory nobody wants to make
intake → app server → primary DB → backups
↘ queue → notification service → SMS provider
↘ error tracker (does it capture request bodies?)
↘ analytics (does it forward user properties?)
Once you have the map, the design rule is brutal and simple: shrink the surface. PHI should exist in as few systems as possible. Everything outside that boundary should never see it. If your error tracker doesn't need patient data — and it doesn't — scrub it at the boundary, not in a code-review comment that gets forgotten.
This is the single decision that separates a clean review from a six-week remediation. The smaller the PHI footprint, the smaller the audit surface, the fewer BAAs you need, the less there is to get wrong.
Encryption is table stakes — and table stakes still trip people
Encryption in transit means TLS everywhere, including internal service-to-service calls. Reviewers check this. "It's behind the VPC" is not an answer when the question is whether traffic between your app and your database is encrypted.
Encryption at rest means the database, the backups, the object storage, the queue if it persists, the search index if you have one. Managed encryption (AES-256 via your cloud provider's KMS) covers most of this. The mistake is assuming "the disk is encrypted" handles everything. Disk encryption protects against a stolen drive. It does nothing against a leaked database credential, a misconfigured bucket, or an over-broad query.
For the most sensitive fields — the ones that would make a breach notification ugly — consider field-level or column-level encryption with keys held separately from the data. It costs you query flexibility on those columns. That's the trade. You can't fuzzy-search an encrypted SSN, and you shouldn't want to.
Access control: minimum necessary, enforced by code
HIPAA's "minimum necessary" standard is not a vibe. It means a user, a service, a role gets access to exactly the PHI required for the task — and no more. Auditors translate this into a concrete question: show me who can see patient records, and prove that a billing clerk can't read clinical notes.
If your answer is "we have an admin role and a user role," you fail. Role-based access has to map to actual job functions, and the enforcement has to live in the system, not in a Slack norm that engineers follow when they remember to.
Three things make this pass:
- Authorization at the data layer, not just the route. Checking permissions in the API handler is necessary but insufficient. The query itself should be scoped to what the caller is allowed to see. A bug in one handler shouldn't expose every record.
- No standing god-mode. Engineers do not have permanent production PHI access. Break-glass access is time-boxed, justified, and logged. The hospital reviewer will ask specifically about this.
- De-identified data in non-prod. Staging and dev never get real PHI. The number of breaches that trace back to a developer's laptop holding a prod dump is not small.
Audit logging is the thing you can't fake later
When a patient's record is accessed, you need to know who accessed it, when, and from where. Not for most records. For all of them. This is the requirement teams discover too late, because audit logging is invisible until someone asks for the report — and then it's the whole ballgame.
Application console logs do not count. They rotate, they're mutable, they mix PHI access with deploy noise, and they live in the same system an attacker would compromise. Audit logs need to be a separate, append-only, structured record: actor, action, resource, timestamp, outcome. Tamper-evident. Retained for years, not days.
We treat audit logging as its own subsystem with its own storage from the first commit, because retrofitting it means reconstructing access history you never recorded — which is to say, it can't be retrofitted at all. (We went deep on this in audit logging architecture that passes SOC 2; the same spine carries HIPAA.)
The BAA chain is where most startups have a quiet hole
You sign a Business Associate Agreement with your customer. Fine. But every vendor that touches PHI on your behalf — your cloud provider, your email service, your SMS gateway, your managed database, your error tracker if it sees PHI — is your subprocessor, and you need a BAA with each of them.
This is the part nobody checks until it's a problem. Your cloud provider offers a BAA; you have to actually accept it and stay within their HIPAA-eligible service list. Your transactional email provider may offer a BAA on an enterprise tier only. That cheap SMS API you wired in during the hackathon? Probably no BAA, which means you can't send PHI through it, which means an architecture change.
The chain is only as strong as its weakest link, and the weakest link is usually a tool someone added without asking the question. Maintain a live subprocessor list. Every new vendor gets the question before integration, not after the hospital asks.
What auditors and hospital security teams actually check
They are not impressed by your policy binder. They want evidence the system behaves as claimed:
- Show the data flow and the PHI boundary.
- Prove encryption in transit and at rest, including backups.
- Demonstrate role-based access with minimum-necessary scoping.
- Produce an audit log report for a specific record over a date range.
- List your subprocessors and the BAAs covering them.
- Show how break-glass access works and where it's logged.
- Walk through your breach-notification path.
Every one of these maps to architecture you either have or you don't. The policy describes the system. It doesn't substitute for it.
What fixed looks like
PHI lives in a deliberately small set of systems, mapped and documented. Everything at the boundary scrubs or tokenizes before data crosses into tools that don't need it. TLS internal and external. Encryption at rest on every store including backups, with the crown-jewel fields encrypted at the column level under separately held keys.
Access is role-based, scoped at the data layer, with no standing production access for engineers and time-boxed break-glass that logs itself. Non-prod environments never see real patient data. Audit logging is a separate append-only subsystem capturing every PHI access, retained for the required years, queryable on demand.
Every subprocessor that touches PHI has a signed BAA, tracked in a list that's reviewed when anyone adds a vendor. The result is a system where the hospital's security questionnaire is a description exercise, not a remediation sprint — because the answers are already true.
The cost difference is stark. Building this in adds maybe 15–25% to the early architecture effort. Retrofitting it after a failed review — re-scoping data flows, adding audit infrastructure you never had, renegotiating vendor relationships, and doing it under a deal-blocking deadline — routinely costs more than the original build and stalls the contract that needed it.
This is for you if
You're a funded founder building software that handles PHI — telehealth, clinical tools, patient-facing apps, anything selling into health systems or payers — and you need the architecture to survive a BAA and a hospital security review the first time, not the third. Regulated builds like this typically start around $100k and go up with scope; the engineering rigor is the product.
It's not for you if you need a fully on-prem deployment with your own procurement, infrastructure, and security org — at that point you're buying a platform team, not a build partner. And it's not for you if you want a compliance consultant to write policies around a system you've already shipped. We build the system the policies describe. If the system isn't right, no document fixes it.
If you're early enough that the architecture isn't poured yet, that's the moment with the most leverage. See how we built a compliance-ready SaaS from the data model up.