HIPAA-Compliant Marketing Tracking and Analytics

HIPAA is not a general health privacy law. It is a law about a specific set of organisations and the vendors working for them, and its scope is much narrower than the way the word gets used in marketing.

• Covered entities

  US healthcare providers who bill electronically, health plans and healthcare clearinghouses. Hospitals, clinics, dental and therapy practices, telehealth companies that bill insurance.

• Business associates

  Anyone creating, receiving, maintaining or transmitting PHI on a covered entity's behalf. Your CRM, your call tracking, your analytics vendor, your agency.

• Everyone else

  Med spas paying cash, supplement and wellness brands, fitness and mental wellness apps, and every healthcare business outside the United States. HIPAA does not reach them.

That third box is bigger than the industry admits. A cash-pay aesthetics clinic that never touches insurance is usually not a covered entity. A wellness app that no provider has hired is not one either. And a clinic in Munich, Zurich or Dubai is outside the statute entirely, whatever a US vendor's sales deck implies.

So establish this before you buy anything. If you are a covered entity or a business associate, the BAA requirement below is absolute. If you are not, you are reading the wrong law, and the sections from "If HIPAA does not apply to you" onward are the ones written for you.

Protected health information is health information that identifies a person, held by a covered entity or its business associate. Marketers underestimate how easily ordinary tracking data crosses that line, because the identifier and the health context usually arrive separately and get joined by the tool rather than by anyone's decision.

• The identifier is rarely a nameAn IP address, a cookie id, a device id, an advertising id or a hashed email all identify a person for this purpose. Removing the name removes very little.
• The URL carries the diagnosisA page path like /treatments/fertility or a query string with a condition name is health information about whoever loaded it, and it travels with every pixel by default.
• The appointment is the disclosureA booking confirmation that fires a conversion event with the specialty attached tells the recipient that this person is being treated for that thing.
• The call recording is the whole recordCall tracking that records and transcribes a patient describing symptoms is holding clinical information, not a marketing touchpoint.

The pattern that produced the enforcement actions is the combination: a tracker that knows who somebody is, running on a page that says what they are being treated for, sending both to a company that never signed anything. The tool did not need a name to create the problem.

No, and it cannot be made so. This is the most searched question in the topic and it has a one-word answer, but the reason matters more than the answer, because it applies identically to a dozen other tools.

Google signs business associate agreements for a defined list of HIPAA-eligible services under Google Workspace and Google Cloud. Google Analytics is not on that list, and neither is Google Ads. Google's own Analytics terms go further and prohibit sending it data that could be used to identify a person, with its HIPAA guidance telling customers not to use Analytics on pages where PHI is in play.

The workarounds that do not work

• IP anonymisation. GA4 does not log IP addresses the way Universal Analytics did, and it still holds a client id that identifies a returning person. The BAA is what is missing, and this does not supply it.
• Stripping PHI before it is sent. Genuinely de-identified data is out of HIPAA's scope, but the standard is the Safe Harbor or expert determination method in §164.514, not a judgement call about which fields look harmless. Most attempts fail on the identifiers nobody thought of.
• Server-side GTM. Moving the tag to a server changes who sends the request, not who receives it. If the destination is still Google Analytics, the recipient still has not signed a BAA.
• Consent from the patient. A HIPAA authorization for marketing use of PHI is a specific document with required elements. A cookie banner is not one, and treating it as one is the most common mistake in this area.

In December 2022 the HHS Office for Civil Rights published a bulletin on online tracking technologies, revised in March 2024. Its most aggressive claim was that an IP address collected on a public, unauthenticated page about a health condition was already individually identifiable health information, purely because of the page it was collected on. The industry called this the proscribed combination, and it would have made almost any analytics on a hospital website unlawful.

The American Hospital Association sued. On 20 June 2024 the US District Court for the Northern District of Texas held that OCR had exceeded its authority and vacated that part of the bulletin. OCR filed an appeal and then withdrew it on 29 August 2024, which left the vacatur standing.

So the ruling narrowed one aggressive interpretation on public pages. It did not legalise pixels in healthcare, and it did not touch the part of the exposure that has actually cost money. The settlements in this field have run into eight figures, and they were brought by plaintiffs' lawyers under wiretap statutes rather than by OCR under the bulletin. A page can be compliant with HIPAA and still be the subject of a class action.

Here is the structural bind that no tool solves. A covered entity's marketing goal is to send conversions back to Meta and Google so the algorithms optimise on patients rather than clicks. HIPAA says you may not disclose PHI to a party that has not signed a BAA. Meta does not sign BAAs. Google excludes Ads from its own. The two requirements cannot both be met.

• A Conversions API does not fix it. Sending server to server changes the transport, not the recipient. Meta receives the same data with the same agreement in place, which is none.
• Hashing does not fix it. A hashed email is precisely as identifying as the email to anyone holding the address, which is the entire reason the platforms can match on it. Hashing is data minimisation, not de-identification.
• Offline conversion import does not fix it. Uploading a closed case with a treatment type attached is a disclosure of PHI in a file rather than in a pixel.

What covered entities do in practice is send less, not send differently: a conversion signal with no health context, fired from a page that reveals nothing, with the specialty and the outcome kept on their own side. You lose optimisation quality and you keep the licence. That is the trade, and a vendor who tells you there is no trade is describing something other than compliance.

Analytics gets the attention, but the two systems that most reliably collect real clinical detail are the phone and the intake form, and they are usually bought by whoever runs marketing rather than by whoever owns compliance.

Call tracking

Dynamic number insertion itself is ordinary attribution plumbing. The exposure is what the platform does next: recording, transcription, keyword spotting and the AI summaries that are now on by default in most call tracking products. A recorded call in which somebody describes a symptom is clinical information sitting in a marketing vendor's account. Several call tracking vendors do offer a HIPAA plan with a BAA, and it usually turns recording and transcription off rather than securing them. For how the mechanism works in general, see tracking phone calls back to the ad.

Form tracking

Session replay and form analytics are the sharpest edge in the whole stack, because they capture keystrokes rather than submissions. A tool that records what somebody typed into a symptom field and then abandoned has collected information the person specifically chose not to give you. Field-level masking is the mitigation, and it needs to be an allowlist rather than a blocklist: anything not explicitly masked will eventually carry something it should not.

There is no HIPAA certification. No regulator inspects a vendor and issues a badge, which is why the badges on vendor websites are self-declared and worth nothing on their own. Compliance is a state you maintain, and for a marketing stack it comes down to four things.

1. A signed BAA with every vendor that touches PHI

This is the non-negotiable one. It has required content: permitted uses, safeguards, breach reporting to you without unreasonable delay and within 60 days, the same terms flowed down to the vendor's own subcontractors, and return or destruction of PHI when the contract ends. A GDPR data processing agreement is not a BAA. They cover different obligations under different law, and a vendor offering you a DPA when you asked for a BAA has answered a different question.

2. The Security Rule, including the half nobody buys

• Technical safeguards: access control, audit logging, integrity controls, encryption in transit and at rest.
• Administrative safeguards: a documented risk analysis, a named security official, workforce training, sanction and incident response policies. This is the half that gets cited in enforcement, and it is the half no software purchase provides.
• Physical safeguards: facility access and device controls, which for a cloud stack largely transfer to the hosting provider under its own BAA.

3. Minimum necessary, applied to marketing data

Disclose the least PHI needed for the purpose. Applied to attribution, that usually means the conversion signal travels and the clinical context does not: the campaign learns that a booking happened, not what it was for.

4. A defensible record that the above is true

A vendor inventory with a BAA against each entry, a dated risk analysis, and evidence the policies are followed rather than filed. The penalty tiers were raised again with effect from 28 January 2026, and they scale with whether you knew: the top tier is willful neglect left uncorrected, which is what an undocumented programme looks like from the outside.

If you are a covered entity, this is the only vendor question that matters, and the answer is public for every serious tool. The table below is the state of play as of September 2026 and should be confirmed with each vendor in writing, because plan-level availability changes and a BAA is often gated behind an enterprise tier.

Note the second row. No ad platform signs a BAA, which means the covered-entity playbook is never "find a compliant pixel". It is to keep PHI on your own side and send the platforms a signal that carries none of it.

This is the larger group, and it is the one being badly served by the current search results. If you are a cash-pay aesthetics clinic, a wellness or supplement brand, a fitness or mental wellness app, or a healthcare business anywhere outside the United States, HIPAA does not bind you, and building your marketing measurement as though it does costs you the ability to run a business.

What replaces it is the privacy law that does reach you, which for most of the world is the GDPR. Health data is a special category under Art. 9, which raises the bar on consent and on documentation, but it does not put measurement out of reach the way a misapplied HIPAA reading does.

• Collect first-partyRun tracking on a subdomain you own so no third-party cookie is set and there is one inspectable point where data leaves your control.
• Separate the signal from the contextSend the ad platform that a booking happened. Keep the treatment, the specialty and the page path on your own side. Good practice under any framework.
• Get consent properlyGranular, genuinely refusable, and respected at the boundary rather than at the banner. Verify it by declining on your own site and checking that nothing arrived.
• Document the flowA signed DPA, a current sub-processor list, a retention policy that is enforced, and a privacy notice a patient could actually follow.

Done this way you keep accurate attribution and a defensible position, which is the combination a misapplied HIPAA reading makes people believe they cannot have. The full version of this argument is in our guide to GDPR-compliant conversion tracking.

We would rather answer this plainly than sell past it, because the fastest way to lose a healthcare buyer is to be caught implying a compliance you do not hold.

What we are built for is the group in the section above, and for the part of a covered entity's marketing that carries no PHI at all. Production infrastructure is in Frankfurt, inside the EU. Server-side tracking runs on your own subdomain, so no third-party cookie is set and the collection point is yours. Traffic is served over TLS, and OAuth tokens, two-factor secrets and personal data in the database are encrypted with AES-256-CBC. Every sub-processor with access to data is listed publicly on the GDPR page, and the control-by-control account is on the security page.

For a clinic in Europe, that combination is usually the whole answer: first-party collection, one processor with a signed agreement, EU residency, and campaigns credited with the appointments they produced. For a US covered entity it is a good stack for the marketing that never touches PHI, and the wrong stack for the marketing that does. Both of those sentences are true at once, and any vendor telling you only the first one is selling you a liability.

Carry on with GDPR-compliant conversion tracking, Consent Mode v2 for lead generation and tracking phone calls back to the ad. For our own documentation, see the GDPR and data protection page, the security page and the technical and organisational measures. If you run a practice or a clinic, the healthcare providers page covers the attribution side in your own vocabulary.