The Franken-stack: Why Your HIPAA-Compliant Tools Don't Add Up to a Compliant Practice

Every independent healthcare practice we talk to has one. They don't call it that, because no vendor is going to sell them something called a Franken-stack. They call it "our setup." They call it "what's working." They call it, with a certain amount of pride, "the tools we chose."

We call it a Franken-stack because that is what it is: a collection of disparate software, stitched together over months or years, each piece chosen under pressure to solve a specific operational gap, each piece individually defensible, none of them designed to operate together. The front desk uses one tool to send intake forms. The clinicians use another to message each other. Billing uses a third. The owner's personal email is on a fourth. Somewhere in there is a cloud storage account nobody set up on purpose. Somewhere else is a fax line that runs through an app. Each addition was rational at the moment it happened. The aggregate is not rational at all.

This post is the one we wish we could have handed to every practice that has asked us, over the past year, whether their current setup is HIPAA compliant. The short answer: your individual tools might be compliant. Your Franken-stack almost certainly is not. The long answer is below.

What a Franken-stack looks like

Picture an independent dental office with four operatories, six staff, and a manageable schedule. Over the past five years they have assembled the following:

• Google Workspace Starter for email (free tier, no BAA on file).
• Zoom Pro for the occasional consult (personal plan paid by the owner's debit card; not the Healthcare plan).
• Dropbox Personal for scanned records (it was already installed on the old front-desk laptop).
• An eFax app for referrals (consumer tier).
• iMessage group chats for shift coordination (because everyone already uses it).
• A Chrome extension one of the hygienists added to summarize visit notes with an AI model (opt-out for training was never configured).
• A secure portal built into the practice management software for patient messaging (this one has a BAA).

If you ask that practice whether they are HIPAA compliant, they will tell you yes. They encrypt their patient portal. They lock their computers. They have antivirus. They had a compliance consultant come through once and everyone signed something. From inside the office, it feels handled.

From the outside — from any auditor's view — this is a risk surface with seven entry points and no unified control plane. Six of the seven tools have no Business Associate Agreement. At least three are consumer-tier products that Google, Zoom, and Dropbox themselves say cannot be used for PHI. The AI extension is a separate disclosed-to-nobody data exfiltration channel. The iMessage chat is not encrypted in the way HIPAA means the word. And none of this is written down anywhere. No data flow map. No vendor inventory. No incident response plan that accounts for any of these systems.

This practice is one intake form attached to the wrong email thread away from a reportable breach.

Why Franken-stacks happen

We want to be clear about something before we go further. Practices don't build Franken-stacks because they are careless or unserious. They build them because every individual decision, in the moment, was defensible.

The front desk needed to send a PDF. Gmail was already open. That was a Tuesday problem.

The owner needed a consult with a specialist. Zoom was already installed on the laptop. That was an eleven-o'clock-patient problem.

The hygienist was drowning in documentation. The AI extension saved her forty-five minutes a day. That was a sanity problem.

None of those decisions, in isolation, was unreasonable. What is unreasonable — and what is actually dangerous — is the aggregate pattern: a practice making each of those decisions independently, without a stack architect, without a compliance frame, without anyone asking the question does this piece belong here. That is the structural problem. The Franken-stack is what you get when operational pressure meets the absence of a compliance architecture. It is the default outcome.

Three ways the Franken-stack breaks

There are a lot of specific ways a Franken-stack can generate a breach. They fall into three families.

1. The integration gap

You have Zoom for Healthcare with a signed BAA. You have a patient portal with a signed BAA. A clinician finishes a telehealth visit, wants to send the patient a recap, and drops the summary into their personal Gmail because that is what they use for quick notes. The two tools on either end of the handoff were compliant. The handoff itself was not. The PHI is now sitting in a consumer Gmail inbox.

The Franken-stack fails at the seams. Every additional tool multiplies the number of seams. Six compliant tools arranged badly produce more risk than three compliant tools arranged well, because the attack surface is not the tools — it is the connections between them.

2. The consumer-tier default

Staff installs Zoom. Staff installs Dropbox. Staff installs Slack. In every case, the default version offered is the consumer tier: Zoom Basic, Dropbox Personal, Slack Free. In every case, the user interface of the consumer tier is nearly identical to the enterprise tier. The user cannot tell the difference from the screen.

What is different is invisible. Whether Zoom, Dropbox, or Slack will sign a BAA with the practice. On consumer tiers, none of them will. This is a commercial decision by the vendor: consumer-tier customers sit outside their PHI-handling boundary. Using the consumer tier for PHI means using software that the vendor has explicitly told you cannot be used for PHI. Auditors treat it as unmitigated risk. Insurers treat it as a policy violation.

This is the scenario we hear most often. A practice believes they are covered because they pay for a version of a tool. They are only covered if they pay for the specific version that permits a BAA, have actually signed the BAA, and have configured the settings the vendor requires. Zoom Pro is not Zoom for Healthcare. Google Workspace Starter is not Google Workspace with HIPAA Compliance enabled. Dropbox Plus is not Dropbox Business. These are commercially distinct products that share a name.

3. The unsanctioned addition

Someone on the team installs a browser extension, a desktop app, a Chrome-based AI summarizer, a personal note-taking tool, a photo-sharing app. They do this to solve a real problem, usually a workload problem. They do not tell anyone because nothing in the practice has ever told them they need to.

A month later, the practice has a tool that has access to PHI, has no BAA, has no record in any vendor inventory, has no seat in the risk assessment, and was never evaluated by anyone with a compliance frame. It may also be quietly training a third-party AI model on patient data. This has already happened, at scale, across healthcare. It will happen more.

The failure mode is that the Franken-stack has no immune system. Nothing in the architecture catches a new tool showing up. Compliance cannot work that way.

Why the Franken-stack is a broken premise

Here is the conceptual point underneath all three failure modes.

Compliance is an emergent property of a system, not a sum of properties of components. You can have ten HIPAA-compliant tools and zero HIPAA compliance. You can have a perfectly compliant video conferencing platform and a perfectly compliant email service and still be in violation, because the behavior that connects them, the policies that govern them, the training that informs their use, and the monitoring that flags their misuse all sit at the system level. None of that is inherited from the tools.

The Franken-stack treats compliance as an adjective attached to each piece of software. Is Zoom compliant. Is Gmail compliant. Is Dropbox compliant. This framing is how the healthcare tool market markets itself, which is why almost every practice absorbs it. The right question lives one level up: is my practice compliant as an operating system, and does every tool in it reinforce or degrade that system?

Most practices cannot answer that question, because no one has ever given them the frame. Their compliance consultant checked the boxes on each tool. Their IT person confirmed each tool supported encryption. Nobody asked whether the tools belonged together. Nobody drew the data flow map. Nobody inventoried the vendors. Nobody owned the architecture.

This is the work we do.

What to do instead

If you have read this far and some of it sounds like your practice, the response is structural. In order:

1. Inventory every tool that touches PHI. Include the ones nobody sanctioned. The browser extensions. The personal accounts. The apps the hygienist uses. If it has seen a patient name or a date of birth, it belongs on the list.

2. Map the data flows between them. Where PHI originates, where it moves, where it rests. Our free ePHI Flow Mapper will generate this for you in about fifteen minutes.

3. Check every tool for a signed BAA on the correct tier. Our tool compliance guides cover the specific plans and settings required for Zoom, Gmail, Google Workspace, Microsoft Teams, Dropbox, Slack, faxing, and email. If your version does not support a BAA, upgrade, replace, or decommission.

4. Consolidate where possible. Every tool you remove removes a seam. A smaller stack with a clean BAA perimeter and consistent admin policy is more defensible than a larger stack of individually-compliant tools.

5. Install a continuous compliance layer over the whole thing. This is what our platform does. Risk assessment, policy generation, vendor inventory, training tracking, and continuous monitoring against the system as a whole — not one tool at a time. Starting at $39/month.

The question to carry

One question, if you carry something out of this post:

If I had to show an auditor every tool that has touched a patient record in my practice this year, and prove each one has a signed BAA, correct configuration, and documented training — could I do it in an hour?

If the answer is yes, your stack is architected. If the answer is no — or the answer is "I would need to ask a few people" — what you have is a Franken-stack, and the distance between those two answers is the size of your breach exposure.

The Franken-stack is the default outcome of running a practice without a compliance architecture. No moral failing required. The good news is that it has a structural fix. Start with the inventory. Go from there.