Reference · Healthtech
The HIPAA architecture checklist, written from the build side.
Most checklists on this subject restate the rule. This one is 13 decisions an engineer has to actually make, in the order they come up, with what goes wrong when each is answered late. It is free, ungated, and useful whether or not you ever hire me.
Written by Eric P. Hassey, who serves as fractional CTO of a preventive-health platform running AI analysis over retinal imaging. It is an architecture document, not a compliance instrument — see the caveats.
Phase 01
Draw the PHI boundary
Everything downstream depends on this line being in the right place. It is also the only decision on this list that gets harder every single week it is deferred, because each new service either sits inside the boundary or does not, and code written without an answer tends to assume the convenient one.
Which specific data elements are protected health information — at the field level, not the system level?
Why it is load-bearing — Teams that answer this per-system end up with a boundary drawn around a database rather than around data, and the first analytics pipeline or CSV export walks straight through it. The identifiers are the part people miss: an appointment time attached to a name is PHI, and it rarely lives in the table anyone thinks of as the clinical one.
Settled looks like — A written list of fields, each marked in or out of scope, that a new engineer can check a schema against on their first week without asking anyone.
Are identity and clinical data separable, or does every clinical record carry a name?
Why it is load-bearing — This is what determines whether de-identification for analytics is a query or a rewrite. Deciding it after the schema is in production means backfilling every historical record, which is the expensive version of a decision that costs nothing on day one.
Settled looks like — Clinical records reference a subject by an internal identifier, and the mapping from that identifier to a human lives in one place you can point at.
Which services are inside the boundary, and which are being deliberately designed out of the PHI path?
Why it is load-bearing — The alternative to designing a service out is granting it an exception, and exceptions are what you spend the security review defending. Every service inside the boundary is a service that needs a BAA, an access review, and a place in the audit story.
Settled looks like — An architecture diagram where the boundary is drawn as a line, and every service is unambiguously on one side of it.
Phase 02
Close the vendor surface
A Business Associate Agreement is necessary and not sufficient. The failure mode here is almost never the vendor you thought about — it is the one that receives data as a side effect of doing something else.
Which vendors can technically touch PHI, and which of those have an executed BAA?
Why it is load-bearing — These are two different lists, and the gap between them is the finding. "Can technically touch" is broader than "is supposed to touch" — it includes anything that receives a payload you have not audited.
Settled looks like — One inventory, reviewed when vendors change rather than when an auditor asks, where every row has either an executed agreement or a note explaining why that vendor cannot receive PHI.
What do your error tracker and log aggregator actually receive when a request fails?
Why it is load-bearing — A stack trace serialises whatever was in scope. Request bodies, query parameters, and ORM objects routinely carry patient data into a third-party tool that has no BAA and was never part of anyone's compliance review, because nobody thinks of the error tracker as a place data goes. The sharpest version of this is inside a single vendor: Google's BAA covers Firestore, Firebase Authentication, Cloud Functions, Cloud Storage, Hosting, Realtime Database, App Check, Cloud Messaging, Remote Config, and Test Lab — and does not cover Crashlytics, Performance Monitoring, Google Analytics for Firebase, or the ML Kit cloud APIs. A team that reasonably concluded "we are on Firebase and we have a BAA" can still be shipping PHI into Crashlytics from the same console.
Settled looks like — Scrubbing configured at the SDK level and verified by triggering a real error against a real record, rather than assumed from documentation.
Does product analytics widen PHI scope, and if not, what makes that true?
Why it is load-bearing — Analytics tools are adopted by whoever needs a number this quarter, usually without an architecture review. Event payloads accumulate context over time, and the property that was safe when the event was written is not necessarily safe after six months of additions.
Settled looks like — A de-identification step between the application and the analytics vendor that events cannot bypass, rather than a convention that each event author is trusted to follow.
Phase 03
Enforce access and produce evidence
Two questions a security reviewer will ask that a compliance policy cannot answer for you: where is authorization enforced, and can you tell me who read this record.
Is authorization enforced at the data layer, or checked in application code?
Why it is load-bearing — When checks live in application code, correctness depends on every future query remembering to include one. The consequence of a single missed check is a disclosure, and missed checks are the normal outcome of a codebase growing faster than the people who understand it.
Settled looks like — Access decisions evaluated where the data is served — security rules, row-level security, or an equivalent — so that a query written without the check returns nothing rather than everything.
How this works with Firebase custom claims →How long does a revoked role stay usable?
Why it is load-bearing — Token-embedded roles remain valid until the token refreshes. For an offboarding that is a scheduling detail; for a role revoked because of an incident, the lag is the incident. Most teams discover the number during the review rather than choosing it during the build.
Settled looks like — A known, stated revocation path — forced refresh for the ordinary case, server-side token revocation for the urgent one — and a number you can say out loud.
The 1,000-byte limit and the propagation delay →Can your audit trail answer "who read this patient's record last March", as a query?
Why it is load-bearing — The Security Rule requires mechanisms to record and examine activity without dictating a schema, which teams reasonably read as latitude and unreasonably read as "any log will do." A log that captures that a request happened, but not which record was disclosed to which user under what role, does not answer the question it exists to answer.
Settled looks like — Entries that record who, which record, what action, when, from where, and under what authorisation — and an index that makes the per-record question cheap rather than a full scan.
A schema for this in Firestore →Where does audit data live at year five, and what does that cost?
Why it is load-bearing — Six years is the documentation retention floor under the Security Rule, and some state laws and contracts go longer. Keeping all of it in your primary operational database is the default outcome of never deciding, and it is the version where the audit log eventually costs more than the product it protects.
Settled looks like — A hot window that stays queryable for investigations and support, older data tiered to object storage, and a stated path for querying the cold tier when it is genuinely needed.
Tiering without losing queryability →If the audit write fails, does the read succeed anyway?
Why it is load-bearing — Both answers are defensible and the wrong one for your product is the one nobody chose. Failing the request trades availability for evidence; letting it through trades evidence for availability, and produces a log with silent gaps exactly when the system was under stress.
Settled looks like — A deliberate answer, written down, with the failure path instrumented so the gaps are visible rather than silent.
Phase 04
Inference and review readiness
Two things that arrive later than the architecture and reopen it: a model in the PHI path, and a hospital security questionnaire.
Does model inference over PHI stay inside infrastructure a BAA covers?
Why it is load-bearing — Vendors become HIPAA-eligible; uses become compliant. An executed BAA says nothing about whether your minimum-necessary determination was sound, whether the output is being logged somewhere uncovered, or whether retention carve-outs apply to abuse monitoring. The gap between "the vendor signed" and "this use is defensible" is where the risk sits.
Settled looks like — Written confirmation from the vendor of exactly what is and is not retained, a zero-retention configuration where offered, and an output path that does not land PHI in an uncovered log.
A decision framework for PHI and LLM APIs →Can you answer the enterprise security questionnaire from artifacts you already have?
Why it is load-bearing — These arrive as 200-question spreadsheets mapping to roughly 20 underlying controls, and they arrive attached to a deal with a date on it. Answering from memory under deal pressure is how teams commit in writing to controls they have not actually implemented.
Settled looks like — The recurring answers assembled once, each pointing at a real artifact — a diagram, a policy, a configuration — rather than reconstructed per deal.
I add to this as the failure modes come up
This list grows out of real builds, and the additions tend to be the things that were not obvious until something went sideways. Leave an email and you get them when they land — nothing else, no sequence, no pitch.
What this is and is not
Is there an official HIPAA architecture checklist? +
No. The Security Rule is deliberately non-prescriptive — it requires administrative, physical, and technical safeguards, and specifies outcomes rather than implementations. There is no government-issued schema, vendor list, or reference architecture, which is why two compliant systems can look nothing alike. Any checklist, including this one, is one engineer’s reading of which decisions carry the most weight, not a compliance instrument.
Does this replace a compliance assessment or legal advice? +
No, and it is not trying to. This is an architecture document about decisions that are cheap early and expensive later. Whether your programme as a whole satisfies the rule is a question for a qualified assessor and your counsel, and nothing here substitutes for either.
When is the right time to work through this? +
Before the schema is in production. Most of these decisions cost nothing to make correctly on day one and require a backfill or a migration to change afterwards. The common pattern is a team that reaches for a checklist when a hospital security questionnaire lands, at which point several of these have already been decided by default.
Does using a HIPAA-eligible cloud provider cover most of this? +
It covers the infrastructure layer and nothing above it. A HIPAA-eligible provider under a BAA gives you compliant hosting; it does not draw your PHI boundary, decide where authorization is enforced, keep your error tracker from receiving a patient record in a stack trace, or make your audit trail answerable. Those are all application-architecture decisions and they remain yours.
What usually fails an enterprise security review? +
In practice it is rarely encryption, which teams handle early because it is the part everyone knows about. It is more often the audit trail being unable to answer a per-record question, authorization being enforced in application code rather than at the data layer, and a vendor in the stack — typically an observability tool — that receives PHI without an agreement covering it.
Working through this on a live platform?
The list is the easy part. The hard part is sequencing it against a roadmap that already has commitments on it, and knowing which of these you can defer without creating a migration. That is the engagement.