The HIPAA-Compliant Marketing Stack
An AI-powered marketing stack for addiction and mental-health treatment centers — where every vendor that touches PHI has a signed BAA, and everything that does not is deliberately kept PHI-free.
humbearmedia.com ↗## the problem
We market addiction and mental-health treatment centers, so almost everything we touch is regulated. Under HIPAA, any third party that handles protected health information on our clients' behalf needs a signed Business Associate Agreement, and there is no move-fast-and-break-things version of that. Compliance is the first constraint, not an afterthought. If a tool cannot be made compliant, it does not touch PHI, full stop — I will make a business decision that costs us before I cut a compliance corner.
The hard part is that a modern marketing stack is dozens of tools: CRM, ad platforms, call tracking, analytics, AI models, automation, hosting, a database. Each one is a place PHI could leak if you are not deliberate. So the real problem was never picking tools. It was drawing a hard line — deciding exactly which systems are allowed inside the PHI zone, and therefore need a BAA, and which are kept permanently outside it.
## what I built
A HIPAA compliance boundary that every tool sits on one side of. Inside it — anything that can touch PHI — every vendor has a signed BAA: the CRM, automation, call tracking, the database, hosting, the cloud, and the AI engine. Outside it sit the tools we use for non-PHI work, and PHI never reaches them by design. The full, current list with each vendor's status is published on our sub-processor page, so this is not a claim you have to take on faith.
Claude is the AI engine, with a rule that matters: any time PHI is in play, we use Claude (Opus 4.6) through AWS Bedrock, which we hold a BAA with — never the consumer Claude.ai app, and never the Claude Code desktop app. Same model family, completely different compliance footprint. The consumer and desktop apps are for internal, non-PHI work only.
The agent backbone is a self-hosted n8n on Railway with a Neon Postgres database, both under BAA, so the automation that orchestrates client work runs on infrastructure we control and have agreements for. Make.com handles the non-AI plumbing on its enterprise BAA, and GoHighLevel is the white-labeled CRM where the client relationships actually live.
PHI never reaches the ad platforms in the clear. Everything we send to Meta — including Conversions API events for lead generation — is normalized and hashed into an irreversible match key before it leaves our boundary. A name becomes a string of characters, never a name. The platform can match and measure without ever receiving a raw identifier. Audience optimization runs through an exclusive data partner, also under BAA.
## how Claude was actually used
- 01
Mapped every tool against the PHI boundary
I had Claude work through the whole stack and sort each tool by one question: does this touch PHI or not? If yes, it needs a BAA and lives inside the boundary; if no, it stays outside and PHI never reaches it. That sorting is the entire compliance model, and Claude helped make it explicit and written down instead of living in my head.
- 02
Pinned the Claude-for-PHI rule in writing
Claude helped document the rule that PHI only ever goes to Claude through AWS Bedrock under our BAA — never the consumer app, never the desktop app — and exactly where each is and is not allowed, so no one on the team is guessing.
- 03
Stood up the agent backbone on BAA infrastructure
Claude Code helped set up the self-hosted n8n on Railway with a Neon Postgres database, both chosen because a BAA was available, so the automation layer runs on infrastructure we have agreements for rather than whatever was easiest to spin up.
- 04
Designed the hashed path to the ad platforms
Claude helped design the flow that normalizes and hashes identifiers before any conversion data reaches Meta's Conversions API, so the platform receives a match key and never a readable identifier.
- 05
Kept the receipts public and current
The sub-processor list, with each vendor's BAA status, is published rather than buried. Claude helps keep it accurate as tools and agreements change.
## stack
## results (the verifiable kind)
- ✓Every third party that receives PHI has a signed BAA. The current per-vendor list is public at humbearmedia.com/sub-processor-list and updated as it changes.
- ✓PHI to Claude only ever goes through AWS Bedrock (Opus 4.6) under BAA. The consumer Claude.ai app and the Claude Code desktop app are never used for PHI.
- ✓Ad platforms never receive raw PHI. Data sent to Meta, including Conversions API events for lead generation, is normalized and hashed into an irreversible match key first.
- ✓The automation backbone runs self-hosted on Railway with a Neon Postgres database, both under BAA, rather than on shared infrastructure we have no agreement for.
- ✓Tools without a BAA are kept out of the PHI path entirely, by design — not used carefully with PHI, just not used with PHI at all.
## what I learned
- →In healthcare, compliance is the first design constraint, not a feature you bolt on later. We decide what a tool is allowed to touch before we decide whether it is convenient, and we will make a business decision that costs us rather than cut a corner.
- →Draw the boundary first, then place the tools. Sorting every vendor into can-touch-PHI or cannot up front is what makes every downstream decision easy and defensible.
- →Same model, different door. Claude through Bedrock under a BAA and Claude through the consumer app are not interchangeable when PHI is involved — the model is identical, the compliance footprint is not.
- →Publish the receipts. A public sub-processor list with real BAA statuses is harder to fake, and easier to trust, than a HIPAA-compliant badge in a footer.
- →The ideas are never the bottleneck — discipline is. We will have a hundred and fifty ideas in a quarter, and the win is choosing the three to five that actually ship in the next ninety days. This stack got built in phases for that exact reason: backbone first, then the AI agents, then content, then data.
$ follow --the-build
Watch it happen, don't take my word for it
Every build on this site gets documented as it happens — the prompts, the dead ends, the results. No course at the end of this funnel. There is no funnel.
follow on x →