Why HIPAA compliance in martech goes beyond BAAs

A business associate agreement won't fix risky data flows. Here's what to check across tracking tools, EHR feeds, and ad platforms.

By Kevin Haag ,

Chief Data Officer, Qualified Digital

Published on 2026-10-09 • Last updated on 2026-10-09 • 6 minutes read

Share this article

Table of Contents

Health marketers ask the same question in every tool evaluation: Will the vendor sign a business associate agreement (BAA)? It’s the wrong first question. A BAA is a contract. It doesn’t make a tool compliant, and it doesn’t tell you whether HIPAA applies.

HIPAA regulates entities, not data. It covers health plans, clearinghouses, and providers that bill electronically, as well as the business associates who handle protected health information (PHI) for them. A hospital system is covered. An agency that runs campaigns using its patient data is likely a business associate. A direct-to-consumer supplement brand isn’t covered.

They aren’t in the clear. The FTC treats unauthorized sharing of health data with advertisers as a breach under its Health Breach Notification Rule, and several states have their own consumer health data laws. Different, not zero, rules apply.

For covered entities, the question is whether the data is PHI: identifiable information tied to someone’s health, care, or payment for care. In martech, the identifier is rarely a name. It’s an IP address or a hashed email next to a URL, a form field, or an appointment date. The compliance risk depends on where that data goes, who receives it, and how it’s used.

5 common misconceptions about HIPAA compliance

1. ‘We signed a BAA, so we’re covered’

A BAA covers the vendor who signed it. It does nothing for the ad platform you sync audiences to or the pixel another team added last quarter.

2. ‘De-identified data isn’t PHI’

True, if it’s actually de-identified. HIPAA allows two methods: removing 18 specified identifiers or a formal expert determination. The identifier list includes IP addresses, device IDs, and URLs. Hashing an email doesn’t qualify. In marketing, hashing exists so records can be matched. That’s the opposite of de-identification.

3. ‘IP addresses and device IDs aren’t PHI’

Alone, maybe not. Next to health context, they can be. A 2024 federal court ruling vacated the portion of federal tracking guidance that covered IP addresses on public pages about conditions or providers. The rest stands. Patient portals, apps, and pages where people book care or enter symptoms remain in scope.

4. ‘Server-side tagging solves it’

Server-side changes where data is collected, not what gets sent onward. Forward PHI to a vendor without a BAA, and it’s the same disclosure through a different pipe. A vendor’s promise to strip PHI after receipt doesn’t cure it. Federal guidance says so directly. The value is the control point, where you filter before anything leaves.

5. ‘Our privacy policy covers this’

Disclosing PHI to a third party for marketing requires a HIPAA authorization with specific required elements, including the right to revoke. A privacy policy isn’t one. Neither is a cookie banner.

When electronic health records (EHRs) feed the martech stack

The website is half the exposure. Health systems increasingly pipe EHR data into CDPs, marketing automation, and journey orchestration tools, including appointment history, service lines, discharge dates, and sometimes diagnosis codes. That data is PHI the moment it lands, and the platform vendor is a business associate. Its BAA needs to cover the modules and features you actually use.

Purpose matters next. Communications about your own services generally don’t need patient authorization. Communications a third party pays for do, and so does disclosing patient data for anyone else’s marketing.

Then watch the exits. An audience synced from a CDP to an ad platform is a patient list handed to a company that typically won’t sign a BAA. A journey triggered by a diagnosis can reveal it in an email subject line or a text preview. The minimum necessary standard applies to these uses. Send each platform the fields a use case needs, not the whole feed.

What a BAA covers — and what it doesn’t

A BAA defines what the vendor may do with PHI and binds it to HIPAA’s rules. Expect terms on permitted uses and disclosures, Security Rule safeguards, breach and incident reporting, and flow-down to the vendor’s subcontractors.

A signed BAA still leaves several compliance risks unaddressed.

It doesn’t fix structural problems

If the vendor won’t sign, or its terms let it use the data for its own ad products, a pixel on a page with a condition in the URL is still an impermissible disclosure.

It doesn’t expand what HIPAA allows

Retargeting and lookalike modeling usually require the ad platform itself to receive PHI, and few will under a BAA. No BAA can authorize a vendor to use identifiable PHI for its own commercial purposes.

It doesn’t transfer your obligations

You still own the risk analysis and the map of where PHI goes.

It doesn’t cover every product or feature

Vendors often limit BAAs to certain products or configurations. Some prohibit PHI in the exact fields your team plans to use. Others exclude add-ons like ad integrations or AI features. A BAA used outside its scope is paperwork, not protection.

How enforcement shapes compliance decisions

The 2024 ruling narrowed the federal position on public pages. Class actions under state wiretap and medical confidentiality laws, already underway since 2022, are the bigger financial exposure. Class periods reach back to when tracking started, so a tag installed years ago is still a liability. The federal regulator says its tracking investigations focus on whether organizations assessed and mitigated the risk under the Security Rule. Not knowing a tag existed is evidence that the risk analysis missed something.

Much of this isn’t settled. Is a visit to a service-line page tied to the visitor’s own care? Is a hashed patient list uploaded only to suppress ads still a disclosure? Reasonable lawyers answer these differently. That’s why legal and compliance belong in the process early, not at final sign-off.

Marketing knows what the tools do and where data moves. Legal knows how to read ambiguity and what the organization can defend. Together, they set the actual risk tolerance: which page types get tracking, which data can leave the EHR. Then they document the reasoning.

A written, good-faith interpretation holds up far better than an unwritten assumption. Marketers waiting for one universal “compliant” answer will keep waiting. The answer is organizational, and someone has to decide it on purpose.

Where to start

Map the stack in both directions. On the collection side, inventory every tag and SDK on every web and app property, including the ones nobody remembers adding, and note what each sends from which pages. On the data side, trace every feed out of the EHR: which fields go into which platforms and where those platforms send data next.

Ad audiences, enrichment vendors, SMS gateways, and agency exports all count. Check each destination against a BAA, its actual scope, and whether the use itself is permitted. The gaps are usually obvious once you look.

Contributing authors are invited to create content for MarTech and are chosen for their expertise and contribution to the martech community. Our contributors work under the oversight of the editorial staff and contributions are checked for quality and relevance to our readers. MarTech is owned by Semrush. Contributor was not asked to make any direct or indirect mentions of Semrush. The opinions they express are their own.