is zapier hipaa compliant? what a practice can automate with it

the question i get asked is whether zapier is hipaa compliant. that is the wrong question to bring to an audit. the right question is whether zapier will sign a business associate agreement for the tier a practice can actually afford, and what happens to protected health information when a webhook fails halfway through a run.

the short answer: no, not on the plans most practices buy. zapier does not offer a baa on its standard tiers, full stop. that single fact should end most of the debate, but it rarely does, because the workflow already exists, it already saves someone an hour a week, and nobody wants to be the person who rips it out.

the baa problem is not a technical setting

a business associate agreement is not a checkbox in account settings. it is a signed contract where a vendor accepts legal liability for how it handles phi on your behalf. no baa means no covered vendor relationship, which means any phi that touches that tool is a violation the moment it arrives, regardless of encryption, regardless of who can see it.

zapier's own stance is that a baa is not available on its core plans. some vendors solve this with an enterprise tier built around compliance, with dedicated contracts and infrastructure controls. zapier is not built that way. you cannot pay more to turn on encryption and call the problem solved, because the problem was never encryption. it was always whether a signed agreement exists. toggling a security setting does not create one.

this is why "we only use it internally" is not a defense. hipaa does not care whether data left the building. it cares whether an uncovered third party processed it at all.

where data actually leaks in multi-step zaps

practices that think they are being careful usually still leak phi, because the leak is not in the obvious step. it is in the exhaust.

every zap keeps a task history. every multi-step automation logs the payload at each hop, often in plain text, so it can show you what happened if something breaks. an intake form that passes a patient name, a date of birth, and a chief complaint through three connector steps writes that same information into a log three times, stored on infrastructure the practice does not control and never signed an agreement to use.

error payloads are worse. when a zap fails, the tool often captures the full request body so a human can debug it later. that means the exact phi you were trying to move now sits in an error log, unencrypted, searchable, and retained on a timeline the practice does not set.

third-party connector hops compound this. a zap that touches a scheduling tool, then a spreadsheet, then a slack channel has created three additional places where the same patient data now lives, each with its own retention and access rules that nobody at the practice has reviewed.

none of this throws an error. the automation runs, the task completes, and the only trace is in logs nobody reads until something goes wrong and a regulator asks for them.

[[FIGURE:1]]

why make and n8n change the math differently

the secondary question practices ask is whether make or n8n solve this instead. the honest answer is: it depends which one, and at what tier.

make offers a baa, but generally only on its enterprise tier, with pricing and contract terms that put it out of reach for a lot of single-location practices. if a practice is paying for a mid-tier make plan and assuming that covers them, that assumption is the gap an auditor finds.

n8n is different because it is open source and can be self-hosted. run inside a clinic's own private infrastructure, with no external vendor processing the execution state, and the baa question changes shape entirely: there is no third party to sign one with, because there is no third party touching the data. that is a real architectural difference, not a licensing tier. but it comes with a cost most practices underestimate: someone now owns the server, the patching, and the uptime. self-hosting moves the liability away from a vendor and directly onto whoever administers that box.

so the three tools are not interchangeable answers to the same question. they are three different trade-offs between cost, control, and who is legally on the hook when something goes wrong.

the split architecture: tokenize before you automate

the fix i build toward is not "avoid automation." it is separating what the automation sees from what the record-keeping system holds.

a deterministic internal function, one that lives inside the practice's own infrastructure and that no external model or vendor ever touches, extracts the phi and stores it locally. what gets passed out to zapier, make, or any external tool is an anonymous record id and a routing trigger. the external tool fires a reminder, moves a task, or posts a notification based on that id. it never sees a name, a diagnosis, or a date of birth. it cannot leak what it never received.

this is the same split i use everywhere i put automation near regulated work: the tool that talks to the outside world reads and routes, it never holds the sensitive record. the system that holds the record is boring, internal, and auditable line by line, because nothing about a deterministic function changes behavior based on what a model guessed. when the practice wants to know exactly where a piece of phi has been, the answer is one place, not three logs and a slack channel.

what a practice can safely automate tomorrow

this is not an argument for doing nothing. plenty of practice operations carry zero phi and are safe to automate on a standard zapier plan today: staff shift reminders, equipment maintenance alerts, supply reorder triggers, internal meeting scheduling, and marketing list syncs that never touch a patient record.

what must never pass through a standard automation tool is anything identifiable tied to a patient: name, date of birth, diagnosis, insurance id, appointment reason, or anything that lets someone reconstruct who the record belongs to. if a zap's trigger or payload includes any of those fields, that zap is a liability sitting in plain sight, whether or not it has ever caused a problem yet.

the test is simple to say and hard to apply without actually tracing the data: could this step run with only an anonymous id, or does it need the real record. most practices have never actually traced it, because the zap was built to solve a scheduling headache on a tuesday afternoon, not audited for what it touches.

that tracing is exactly what the Workflow Audit does: two weeks mapping a practice's existing zaps and automations, tracing where phi actually flows, and separating what can stay on consumer tools from what needs to move behind a deterministic, baa-backed system. it costs $2,500 and is credited toward a build if the practice moves forward.