Minimal PHI Architecture: Shrink Your HIPAA Scope 70% (Simply Explained)

The Lie Every Health Startup Tells Itself

"We don't store sensitive health data."

I hear founders say this with total confidence. Then I open their database and find a customer's email sitting right next to their answers about symptoms and medical history.

That is protected health data. Full stop.

Here is the rule that trips everyone up. Protected health data is not just diagnoses and prescriptions. It is any piece of info that identifies a person (name, email, phone) combined with the fact that they sought treatment.

So if you store a customer's email next to the fact that they filled out a health questionnaire, you are holding the regulated stuff. It does not matter that you feel like a marketing company. The law does not care how you feel.

When an auditor shows up, they follow the data. They trace where the health answers go, where the ID upload lands, where the messages live. If any of that touches a system you control, the "we don't store health data" line falls apart instantly.

Here is the part nobody wants to hear. You cannot avoid health data in a health business. Trying to is a fantasy.

So the goal flips. Instead of dodging the rules, you accept them, then shrink your exposure to the smallest possible size. You can cut your risk by roughly 70% just by being smart about where the data lives.

Why Storing Everything Multiplies Your Risk

Think of it like this. Every place you store sensitive data is a door someone has to lock, guard, and inspect. More doors, more risk.

In a typical telehealth business, there are four big sources of sensitive data:

The intake questionnaire (symptoms, history, conditions)
ID and license uploads (government identifiers tied to a treatment request)
Messages between patient and doctor
Prescription records (medications, dosages, refills)

Every system that touches any of these gets pulled into the audit. The database, the backups, the logging tools, all of it.

Now picture a break-in. If your database holds prescription histories and private medical messages, that leak is a front-page disaster. You are calling regulators, notifying patients, and explaining to the world that you spilled people's medication records.

Run the same break-in on a database that holds only emails and payment IDs. Same attack, completely different outcome. It is an annoyance, not a catastrophe.

The data you choose to hold decides whether a breach is a crisis or a footnote. Most startups never make that choice on purpose. They just store everything because it was easy, and the risk piles up quietly until someone forces the reckoning.

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

The Split-Stack Approach

The setup I keep coming back to has three parts. The idea is simple. You become a traffic director, not a warehouse for medical records.

Part one: a marketing site that holds nothing sensitive.

Your public website is pure top-of-funnel. Who you are, what you offer, pricing, testimonials, an email signup. None of that is regulated, because there is no treatment context attached yet.

It can run on cheap, normal hosting because there is nothing sensitive on it. The discipline is keeping it that way. The second you drop a "quick health quiz" on your homepage, you drag the whole site into the regulated zone.

Part two: a tiny handoff service that remembers nothing.

This is the clever bit. You build a small program, about 50 lines of code, whose only job is to pass the customer along to the clinical platform. It holds the info for a split second, then forgets it completely. Nothing saved, nothing logged.

Because it stores nothing, there is no sensitive data sitting in your systems. It is a baton handoff, nothing more.

Part three: the medical experience lives on a certified platform.

This is where the actual sensitive data goes. The intake, the ID uploads, the messaging, the prescriptions, all of it is hosted by a certified clinical platform. You connect it under a web address like care.yourbrand.com, so it still looks and feels like your product.

The customer never notices the handoff. But the medical data lives on the platform's secure, regulated infrastructure, under their certifications and their legal obligations.

You own the brand. They own the regulated data. The four big sources of sensitive data never touch a system you control.

What Actually Lives in Your Database

Let me get specific. Your own database holds exactly four things:

Email, to reach the customer and tie records together
A payment ID, a reference to the charge handled by your payment processor
A link code, which connects your record to the platform's medical record without exposing any of it
Subscription status, active, cancelled, or paused

That is the whole list. No diagnosis. No medication. No symptom answers. No message contents. None of it ever lands in your system.

That link code is the key trick. It lets you handle billing, renewal emails, and cancellation tracking without ever reading a single medical detail. You know that a customer is active. You never know what they are being treated for.

The hard part is not the code. It is the discipline.

It is tempting to save "just one" medical field for convenience. Just the medication name, so support can answer faster. Just the condition, so you can group emails better.

That single decision drags you right back into full scope. One medical field, and you are auditing everything again.

So the rule is absolute. No medical detail ever gets stored in your database. Not for convenience, not for marketing, not for support. If you need that context, you ask the platform and you do not keep the answer.

The Money Bonus

Here is the part buyers always perk up at.

Most clinical platforms charge a premium for hosting sensitive data on their secure infrastructure. We are talking $20k a year or more, sometimes much more. That cost is real, because running certified, audited infrastructure is genuinely expensive.

When you split the stack, you keep that expensive bill off your own books. Your marketing runs on cheap hosting. Your handoff service stores nothing, so it needs no special tier. And the medical part, the only piece that actually requires that pricey infrastructure, lives on the platform, which already pays for it as part of their business.

You are not paying twice. You are using the infrastructure you are already paying for.

I want to be honest. This is good architecture that happens to save money, not a loophole. The data genuinely lives where it should, under the right agreements, on certified systems. You are not hiding anything. You just designed it so the sensitive data never lands somewhere that would force you to buy your own enterprise tier.

Design for This From Day One

Here is the catch. This only works if you build it this way before you launch. Not after a breach. Not after the auditor's email lands.

Untangling sensitive data that has already spread across five systems is miserable and expensive. I have seen teams spend more cleaning it up than it would have cost to build it right the first time.

The discipline is a series of small refusals. Refusing to save the medical field. Refusing to keep the intake answer "for analytics." Refusing the convenient shortcut that would make one support ticket easier.

Each refusal feels like a minor hassle in the moment. Together they keep your risk tiny.

I should be straight about the 70% number. It is a directional estimate, not a precisely audited figure. Your exact result depends on your setup. But the structural point holds. This decision moves the bulk of the risk off your books and onto a platform whose entire business is carrying it.

The question I would ask you: is your data setup 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