Health marketers often start every martech vendor conversation with a single question: will you sign a business associate agreement? That question creates a false sense of safety. A BAA is a legal contract between specific parties. It does not certify that a tool is compliant, and it does not automatically tell you whether HIPAA even applies to your data flows.
The first issue is that HIPAA regulates entities, not data. It covers health plans, clearinghouses, providers that bill electronically, and the business associates that handle protected health information for them. A hospital system is clearly covered. An agency running campaigns on a health system’s patient data is likely a business associate. A direct-to-consumer supplement brand usually sits outside HIPAA’s direct reach.
That does not mean those brands are in the clear. The US Federal Trade Commission treats unauthorized sharing of health data with advertisers as a breach under its Health Breach Notification Rule, and a patchwork of state health privacy laws applies beyond HIPAA. The rules are different, not zero.
Where martech risk actually hides
For covered entities, the central question is whether data is protected health information: identifiable details tied to health, care, or payment for care. In martech, the identifier is often not a name. It can be an IP address, a hashed email, a URL, a form field, or an appointment date sitting next to health context. Risk depends on where that data goes, who receives it, and how it is used.
Several mistaken assumptions keep appearing in tool evaluations:
- A signed BAA covers the vendor that signed it, not the ad platform where you sync audiences or the pixel another team added later.
- De-identification only works under HIPAA’s specific methods, and hashing an email does not qualify because hashing is built for matching.
- IP addresses and device IDs may become PHI when they appear next to health context, even after a 2024 federal ruling narrowed tracking guidance for public pages.
- Server-side tagging changes where data is collected, not what is forwarded; sending PHI to a vendor without a BAA is still a disclosure.
- A privacy policy or cookie banner is not a HIPAA authorization for marketing disclosures.
Watch the EHR exits
The website is only one part of the exposure. Health systems increasingly feed electronic health record data into CDPs, marketing automation and journey tools. Appointment history, service lines, discharge dates and sometimes diagnosis codes become PHI the moment they land, so the platform vendor needs a BAA that covers the modules and features actually in use.
Purpose matters next. Communications about your own services generally do not need patient authorization. Communications a third party pays for do, and so does disclosing patient data for another company’s marketing. The minimum necessary standard applies: send each platform only the fields the use case needs.
What a BAA covers, and what it leaves open
A BAA defines what a vendor may do with PHI and binds it to HIPAA’s rules, including safeguards, breach reporting, and flow-down to subcontractors. But a signed BAA still leaves several gaps. It does not fix structural problems, such as a vendor that refuses to sign or wants to use data in its own ad products. It does not expand what HIPAA allows; retargeting and lookalike modeling usually require the ad platform itself to receive PHI, which few will accept under a BAA. It does not transfer the covered entity’s own obligation to assess and map risk. And it does not cover every product or feature, because vendors often limit BAAs to certain configurations or exclude add-ons such as ad integrations and AI features.
Start the audit in both directions
Marketers waiting for a single “compliant” answer will keep waiting. The practical answer is organizational: legal and compliance should be involved early, and marketing should document the joint risk position. That written, good-faith interpretation holds up better than an unwritten assumption.
Start by mapping the stack from both ends. On the collection side, inventory every tag and SDK on every web and app property, including forgotten ones, and note what each sends from which pages. On the data side, trace every EHR feed: which fields go into which platforms, and where each platform sends data next. Ad audiences, enrichment vendors, SMS gateways and agency exports all count. Check each destination against the BAA, its actual scope, and whether the use itself is permitted. The gaps usually become obvious once you look.
Source: MarTech
