Minimal PHI Architecture: Shrink Your HIPAA Scope 70%

The Lie Every Health Startup Tells Itself

"We don't store PHI."

I have heard founders say this with total confidence, right before I open their database and find an email sitting next to a row of intake answers. That is PHI. Full stop. The minimal PHI architecture conversation has to start by killing this comfortable lie, because almost every health startup tells it to itself.

What actually counts as PHI

PHI is not just diagnoses and prescriptions. It is any individual identifier (name, email, phone, payment record) combined with treatment context. That combination is the trigger.

A longevity or telehealth startup that stores "what are your symptoms" answers in the same table as a customer email has PHI. It does not matter that you feel like a marketing company. The moment that email is linked to the fact that this person sought treatment, you are holding protected health information.

You can have the cleanest schema in the world. If you store the fact that a person filled out a health questionnaire, alongside something that identifies them, you are in scope.

Why "we don't store PHI" rarely survives an audit

The claim falls apart the second an auditor follows the data. They trace where intake answers go, where the license upload lands, where the message thread lives. If any of those touch a system you control, you are a covered entity or a Business Associate, and the "we don't store PHI" line evaporates.

Here is the thing nobody wants to hear: you cannot avoid PHI in a health business. Trying to is a fantasy.

So the goal flips. You stop trying to dodge HIPAA and instead accept Business Associate status, then shrink your footprint to the smallest possible surface. You cannot avoid the regulation, but you can cut your audit perimeter and breach blast radius by roughly 70%.

That structural decision (how much PHI actually lands in systems you control) matters more than any policy binder you will ever write.

Why Storing Everything Multiplies Your Liability

Every PHI surface you own is a surface someone has to audit, log, and defend. More columns, more risk. The math is brutally simple.

The four surfaces that blow up your audit scope

In a typical telehealth flow, four data surfaces explode your scope:

Four High-PHI Surfaces That Expand Audit Scope

• Intake and health questionnaire answers, symptoms, history, conditions. High PHI.
• ID and license image uploads, government identifiers tied to a treatment request. High PHI.
• Clinical messages between patient and provider. The body of these is some of the most sensitive data in the system.
• Prescription records, medication names, dosages, refill history. As sensitive as it gets.

Each one is a high-PHI surface. And here is what founders miss: every system that touches any of these falls inside the audit perimeter. The database, the backups, the logging service, the queue, the analytics pipeline. All of it.

Blast radius math

More PHI columns means more systems to audit, more access logs to maintain, more BAAs to manage, and a much wider breach exposure.

Run the scenario honestly. A breach hits your database. If that database holds clinical messages and prescription records, the disclosure is catastrophic. You are reporting to regulators, notifying patients, and explaining to the world that you leaked medication histories.

Now run it again with a database that holds only emails and payment ids. Same breach, completely different outcome. It is an inconvenience, not a front-page disaster.

The data you choose to hold determines whether a breach is a crisis or a footnote. Most startups never make that choice deliberately. They just store everything because it was convenient, and the liability compounds quietly until an auditor or an attacker forces the reckoning.

You get to decide this on purpose. That is the whole game.

The Split-Stack Minimal PHI Architecture

This is the part worth getting right. The approach I keep coming back to is a thin Business Associate architecture: you become an orchestration layer, not a clinical data store. Three pieces.

Split-Stack Minimal PHI Architecture

Marketing layer with zero PHI

Your marketing site lives on standard hosting and never touches PHI. Ever.

It is pure top-of-funnel: who you are, what you offer, why someone should sign up. Landing pages, pricing, testimonials, an email capture for a waitlist. None of that is PHI on its own, because there is no treatment context attached yet.

This layer can run on whatever stack you like, with no special compliance hosting, because there is nothing sensitive on it. Keep it that way with discipline. The second you let a "quick health quiz" land here, you have dragged your marketing site into scope.

The transient PHI micro-service

The handoff is the clever bit. You build a tiny PHI micro-service, roughly 50 lines of code, that is completely transient. It never persists anything.

Its only job: receive the user, create a voucher or handoff token, and redirect them to the clinical platform. It holds data in memory only for the duration of a single request, then it is gone. Nothing written to disk, nothing logged with identifiers, nothing cached.

Because it persists nothing, there is no PHI at rest in your infrastructure. The service exists purely to pass the baton cleanly from your brand to the certified platform.

Clinical UX hosted by the platform

Here is where the actual PHI lives. The entire clinical experience (intake, license upload, messaging, prescriptions) is hosted by the certified clinical platform, served under a care subdomain wired via CNAME.

So care.yourbrand.com looks and feels like your product. The user never senses a handoff. But the PHI lives on the platform's compliant infrastructure, under their BAA, behind their certifications and their audit obligations.

You own the brand experience. They own the regulated data. The split-stack telehealth data architecture means the four high-PHI surfaces I described earlier never touch a system you control. They live where the compliance machinery already exists.

This is not a clinical data store. It is an orchestration layer that routes a customer to where their sensitive data belongs, and steps out of the way.

What Actually Lives in Your Own Database

Let me get specific, because vagueness is where this architecture dies.

The four fields

Your own database holds exactly four things:

The Four-Field Database Schema

1. Email, to reach the customer and tie records together.
2. A payment id, a token reference to the charge, handled by your payment processor.
3. A correlator id, links your record to the platform's clinical record without exposing any clinical data.
4. Subscription status, active, cancelled, paused.

That is the entire schema for the part that matters. No diagnosis. No medication. No intake answer. No message body. None of it ever lands in a column you control.

The correlator id is the key abstraction. It lets you run billing, lifecycle emails, churn analysis, and renewal logic without ever reading a single clinical field. You know that a customer is active. You never know what they are being treated for.

Why no clinical column ever exists

The discipline here is harder than the code. It is tempting to cache "just one" clinical field for convenience. Just the medication name, so support can answer faster. Just the condition, so you can segment emails.

That single decision drags you straight back into full scope. One clinical column and you are auditing everything again.

So the rule is absolute: no clinical column ever exists in your database. Not for convenience, not for analytics, not for support. If you need clinical context, you query the platform through their compliant interface, and you do not persist the answer.

For the few fields you do hold, encrypt any PHI you do touch. And be clear-eyed that encryption alone doesn't make you compliant. Encryption is a security control. Compliance is about scope, BAAs, and where data legally lives. Those are different problems, and conflating them gets startups in trouble.

How This Shrinks the Audit Perimeter and Breach Blast Radius

Now the payoff, in plain terms.

Audit scope before and after

Before: Four high-PHI surfaces (intake, uploads, messages, prescriptions), multiple systems in scope, every access path audited, BAAs with every vendor touching that data, access logs on all of it.

Audit Scope Before vs After Split-Stack

After: The only system you control holds emails, payment ids, correlator ids, and subscription status. The clinical platform carries the heavy compliance load under their BAA and their certifications.

Your audit perimeter collapses to a thin orchestration layer. There is far less to document, far fewer access paths to log, and far fewer vendors to wrangle into agreements.

What a breach actually exposes now

This is the part that helps you sleep. If your database gets breached, what leaks? Emails and payment ids. Data that is already lower sensitivity and, frankly, already exposed through normal commerce. Your email is in a hundred breach databases already. Your payment id is a token, not a card number.

Breach Blast Radius Comparison

There is no clinical disclosure, because there is no clinical data to disclose. The catastrophic stuff lives on the platform's infrastructure, behind their controls.

I want to be honest about the 70% figure. That is a directional estimate of how much you reduce your audit perimeter and breach exposure, not a precisely audited metric. Your exact number depends on your flows.

But the structural point stands: this decision moves the bulk of regulated risk off your books and onto a platform whose entire business is carrying it. You are reducing audit scope by design, not by hope.

The Bonus: Sidestepping the $20k Enterprise Hosting Tier

There is a money angle here that buyers always perk up at.

Why the enterprise tier existed

Many clinical and hosting platforms gate compliant hosting behind an enterprise plan. You want PHI on their infrastructure under a BAA with the right certifications? That will be $20k+ a year, sometimes a lot more.

The tier exists because compliant hosting is genuinely expensive to operate. Someone has to pay for the certifications, the audits, the controls. That cost gets passed to whoever holds the PHI.

The split-stack workaround

When you split the stack, you keep that expensive PHI-bearing infrastructure off your own bill.

Marketing runs on standard hosting (cheap). The transient micro-service persists nothing, so it needs no special compliance tier (cheap). And the clinical UX (the part that actually requires compliant hosting) lives on the platform, which already carries that cost as part of their core offering.

You are not paying twice for compliant infrastructure. You are using the platform's, which you are paying for anyway.

Let me be honest: this is a workaround, not a loophole. The data genuinely lives where it should, under the right BAA, on certified infrastructure. You are not hiding PHI to dodge a fee. You are architecting so that the PHI never lands somewhere that would require you to buy your own enterprise tier.

It is good architecture that happens to save money. The savings are a side effect of doing the right thing structurally, not a hack that quietly adds risk. That distinction matters, because the hacks always come due.

Designing for the Smallest Footprint From Day One

Here is the catch: this only works if you architect for it before you ship. Not after a breach. Not after the auditor's email lands.

Retrofitting minimal PHI onto a stack that already sprawls clinical data across five systems is miserable. You are untangling caches, rewriting flows, migrating data out of columns that should never have existed, and renegotiating BAAs. I have seen teams spend more on the cleanup than they would have spent building it right the first time.

The discipline is a series of small refusals. Refusing to cache the clinical field. Refusing to persist the intake answer for "analytics." Refusing the convenient column that would make one support ticket easier. Each refusal feels like a minor inconvenience in the moment. Together they keep your audit perimeter tiny.

I have rebuilt six regulated industries on AI, and the pattern repeats every time. The right architecture shrinks liability more than any policy document ever will. You cannot write your way out of a sprawling data footprint. You have to design your way out of it before the footprint exists.

If you are building anything that touches health data, and you are trying to avoid taking on a giant compliance and breach liability, this is the kind of decision worth getting right before the first line of clinical code gets written.

The question I would ask you: is your data architecture carrying risk it does not need to? Most are.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together