A website tag may receive the page address, a browser identifier or information typed into a form. A call platform may hold a recording and the caller’s number. Before deciding whether either tool belongs on a healthcare site, you need to know what it actually receives and why.
That review is more useful than a blanket promise that a marketing stack is “HIPAA compliant.” HHS guidance on online tracking asks regulated entities to examine the information disclosed to vendors and whether the HIPAA rules permit that disclosure. The answer can differ by page, interaction and recipient. Marketing, privacy, security and the people who run intake each have part of the picture.
Key Takeaways
- Inspect what each marketing tool actually receives. A vendor list alone will not reveal sensitive information in URLs, form fields, or call reports.
- Assess each disclosure in context with qualified privacy reviewers. Neither every public-page visit nor every healthcare tracking setup has the same answer.
- A business associate agreement, hashed identifier, or server-side route does not by itself make a transfer permissible. Review the actual recipient and intended use.
- Check platform policies separately and retest after changes. Keep an approval record of the permitted pages and data flows.
First, identify the data a tool can see
List every analytics tag, advertising pixel, session-replay tool, chat widget, form processor and call-tracking service on the site. For each one, record the pages where it runs, the events that trigger it, the fields and URLs it receives, and any onward sharing. A vendor name or a tag-manager inventory alone does not show the final payload.
Test the actual network requests and vendor records for representative visits. Include a general information page, a service page, an appointment or insurance form, and any signed-in area. Check what happens before and after someone submits a form. A URL parameter, form value or event label can disclose information even when the visible page looks ordinary.
HHS draws an important distinction. Authenticated patient pages generally give tracking tools access to protected health information (PHI). On public pages, some visits and interactions involve PHI and others do not. A visit to a public oncology page, combined with an IP address, is not by itself enough to establish that the visitor’s health information was disclosed. A person researching a school paper is different from a person seeking care for themselves. A public appointment form that sends an identifiable reason for seeking care to a vendor raises a different question again. HHS notes that a 2024 court order vacated its earlier blanket interpretation of IP addresses paired with visits to public pages about conditions or providers. Read the current HHS bulletin with the particular flow in mind.
The practical response is neither to label every public page safe nor to call every page view a violation. Document what is collected, the context that gives it meaning, and what reaches each outside recipient. Have qualified privacy staff make the PHI and disclosure assessment.
Then ask whether each disclosure is permitted
If a vendor creates, receives, maintains or transmits PHI on behalf of a HIPAA-regulated organization for a covered function, determine whether it is a business associate and put the required agreement in place before a permitted disclosure. HHS explains that simply selling software does not create that relationship; access to PHI for the service can. The agreement defines safeguards and permitted uses. It is not a general permission slip to send patient data to every marketing tool.
A call report can contain protected health information even without a diagnosis or medical record. For a HIPAA-covered provider, a caller’s name or phone number linked to a request for treatment can reveal identifiable information about that person’s care. PHI includes identifiable information about health status, healthcare received or sought, and payment for care when held or transmitted by a covered entity or its business associate.
Suppose your marketing team wants an AI tool to analyze call reports alongside Google Ads performance. If those reports contain PHI, the AI vendor would be processing protected information on the provider’s behalf. A business associate agreement must be in place before uploading it, and the agreement must cover the particular service you intend to use.
Turning off model training is not a substitute for a BAA. That setting addresses one possible use of the data; it does not establish the vendor’s full obligations for protecting PHI. Have your legal and compliance team confirm that the proposed analysis is permitted and review the service’s configuration, including access and retention controls. Share only the information necessary for the approved purpose.
A BAA with the AI vendor also does not authorize sending patient information to Google Ads. Each recipient and proposed disclosure needs its own review.
Ask the reviewer to record four things for each proposed transfer:
- Data: Which identifiers, health-related details, URLs, recordings or free-text fields could leave the organization?
- Recipient: Which company receives them, and can that company or its subcontractors use or disclose them further?
- Purpose and permission: Why is the transfer needed, and what legal basis permits that particular use or disclosure?
- Contract and controls: Does the recipient’s actual role require a business associate agreement, and what security, access and retention controls apply?
HHS says a website privacy notice or ordinary cookie banner does not, by itself, authorize a disclosure of PHI to a tracking vendor. A vendor’s promise to remove PHI after receiving it also does not resolve an impermissible initial disclosure. These points belong in the review before a tool is enabled, not in a cleanup plan after launch.
Treat a server route as a control, not a verdict
A server-side route can give an organization more control over what goes to an analytics or ad platform. It can also pass along a sensitive event, a URL, a click identifier or a value that remains linkable to a person. Moving the transfer off the browser does not change the nature of the information or make the recipient’s use permissible.
If a team proposes a proxy, test both sides of it: what arrives from the browser and what leaves for every vendor. Review event names, parameters, headers, identifiers and logs. Confirm that changes to forms and pages do not quietly add fields later. A hash or synthetic ID is not automatically anonymous. HHS describes two methods for de-identification, Expert Determination and Safe Harbor, with requirements beyond simply hashing a name or removing an IP address.
The same caution applies to calls and chat. Decide whether recording or transcription is needed at all. If it is, review where the audio or text is stored, who can reach it, how long it is kept, and what other services process it. Do not assume a tool either records every keystroke or masks every sensitive field; verify its configuration and observed behavior.
Check the platform’s own rules
Google’s guidance for Analytics says HIPAA-regulated organizations must not expose PHI to Google Analytics, that Google offers no business associate agreement for Analytics, and that legal teams should identify pages where its collection would be permissible. An IP setting, a server proxy or a privacy notice does not replace that page-level and payload-level review.
Healthcare advertising has separate rules. Google restricts personalized advertising for health-related content, including advertiser-curated audiences built from sensitive signals. It also applies healthcare and medicines restrictions to some services. These are platform-policy questions in addition to, not substitutes for, the provider’s privacy review. A search campaign can be planned around relevant queries and accurate service information without assuming that a visitor may be retargeted or that an admission record may be sent back to an ad platform.
Organic search avoids some ad-platform targeting choices, but it is not inherently free of privacy risk. A search landing page can still carry tags, forms and third-party tools. Useful content should answer real patient and family questions accurately, show verified clinical information where appropriate, and offer a clear way to contact the provider. Its measurement needs the same data-flow inventory as a paid landing page.
Keep the review current
A workable approval record names the owner of each tool, the approved pages and events, the permitted recipients, and the person who signed off. Recheck it when a vendor, form, page template, tag trigger or campaign objective changes. If a test shows an unexpected transfer, stop that transfer while the relevant team assesses it.
The next step is to review the actual site and tools with the provider’s marketing, technical and privacy teams. The provider’s qualified privacy and legal advisers should determine whether a proposed arrangement is permissible before it is used with patient information. To discuss the marketing questions for a specific site or campaign, contact Morpheus Consulting Inc..
Frequently asked questions
Does every visit to a public treatment page involve PHI?
No. HHS says the page visit and an identifier alone do not establish PHI when the visit is unrelated to the person’s health, care or payment for care. Some public-page interactions can involve PHI, especially when a person supplies identifiable information about seeking care. Review what a tool collects and the circumstances of the visit rather than applying one rule to every page.
Can we use Google Analytics on a healthcare website?
That depends on the pages and data it would collect. Google says HIPAA-regulated entities must not expose PHI to Analytics and that it does not offer an Analytics business associate agreement. Have your legal and privacy team identify pages and events where its use would not send PHI, and verify the actual transfer before enabling it.
Does server-side tagging make an ad or analytics tool safe to use?
No architecture gives that assurance on its own. A server route can limit outbound data, but the remaining identifiers, event meaning, recipient, purpose and legal basis still need review. Test the outbound payload and monitor it after changes.
Do all marketing vendors need a business associate agreement?
No. The question is whether a vendor is acting as a business associate and creates, receives, maintains or transmits PHI on behalf of a regulated entity. If so, a required agreement must be in place before a permitted disclosure. A BAA does not by itself permit every marketing use of PHI.
Can we hash an identifier before sending a patient-related event?
Hashing alone does not establish that data is de-identified or that sharing it is permitted. A recipient may still be able to match or link the value, and the event may reveal health information. Have qualified reviewers apply the relevant HIPAA de-identification standard and the recipient’s policy to the exact proposed data flow.
