--- url: "https://dfylegitscript.com/blog/tracking-pixels-and-patient-data-on-a-telehealth-site" title: "The tracking on your intake pages is a compliance artefact" description: "Analytics, advertising pixels, session recorders and chat widgets on pages where a patient describes a condition are a live regulatory issue independent of LegitScript, and a certification reviewer reading your site with developer tools open sees exactly the same tags an enforcement lawyer would." published: "2026-06-01T11:39:15+00:00" modified: "2026-06-01T11:39:15+00:00" --- # The tracking on your intake pages is a compliance artefact Analytics, advertising pixels, session recorders and chat widgets on pages where a patient describes a condition are a live regulatory issue independent of LegitScript, and a certification reviewer reading your site with developer tools open sees exactly the same tags an enforcement lawyer would. ## Key takeaways - The tags loading on your intake pages are visible to anybody with developer tools, so a reviewer and an enforcement lawyer see the same thing in about thirty seconds. - Risk here is a property of the page rather than of the vendor, which is why an analytics tag that is unremarkable on a blog post is not unremarkable on a condition page. - Health information leaks without any pixel at all: URLs naming a drug, session replay, chat transcripts, support tickets and email subject lines all carry it. - The root cause is usually who can publish to the tag manager, so restricting that container is a more durable fix than removing one tag. Every telehealth site accumulates tags. An advertising pixel for each channel, a session recorder the growth team installed, a chat widget, a heat mapper, three analytics tools because nobody removed the previous two, and a tag manager that lets anyone with access add more. On a general ecommerce site that is untidy. On a page where a patient is answering questions about their health, it is a different category of problem, and it is one of the few compliance issues on a telehealth site that a reviewer can assess in thirty seconds without asking anybody. ## Why this is sharper for telehealth The data is not a browsing preference. A patient who reaches a page about a specific condition, and then answers questions about symptoms and medications, has generated information about their health. Where that flows to a third party whose business is advertising, the disclosure is the point of the transfer rather than an accident of it. State laws reaching health data inferred from browsing have made this an enforcement area in its own right, and the exposure exists whether or not the business considers itself a covered entity. Certification is not the reason to fix it. Certification is where an unfixed version becomes visible to somebody whose job is to notice. ## What a reviewer actually sees Open your own intake in a browser with the network panel showing and watch what fires. In most telehealth funnels the answer includes at least one advertising pixel on a page that names a condition, an event fired on quiz completion carrying the answer, and a session recorder capturing the form. None of that is hidden. It is client-side code served to anybody who loads the page, which is why "we have a data processing agreement" does not settle it: the question is not whether you have paperwork, it is what the page does. ## The audit, in an afternoon Go page by page rather than tool by tool, because the risk is a property of the page rather than of the vendor. - **List the pages where a patient reveals something.** Condition pages, the quiz and every screen of it, the result screen, the intake, the checkout, the patient portal, and any support or chat surface. - **For each, list what loads.** Every tag, including the ones injected through a tag manager, and every third party the page contacts. - **For each tag, ask what it receives.** URL and page title (which frequently name the condition), form field values, event payloads, and any identifier that ties a session to a person. - **Decide whether it needs to be there.** Most do not. Measurement can happen after the sensitive step rather than during it. The single highest-value change in most audits is removing advertising tags from the clinical part of the funnel entirely and measuring conversion at a point that carries no condition in the URL, the title or the payload. ## The things that leak without a pixel **URLs and page titles.** A path naming a drug or a condition is health information in every referrer header and every analytics record. **Form autocompletion and session replay.** Recorders that capture keystrokes capture what was typed into a free-text symptom field. **Chat transcripts.** A widget that stores conversations with a vendor is a disclosure route, and patients use chat to describe exactly what the intake was careful about. **Support tooling.** Ticket systems containing clinical detail, and the macros support agents use to answer clinical questions, which is a claims problem as well. **Email and messaging.** Subject lines naming the product, and link tracking that identifies the recipient alongside it. ## Who can add a tag, and how you would know The structural problem behind almost every finding here is access. A tag manager with fifteen users, most of them at agencies, is a system in which anybody can add a third party to a clinical page on a Tuesday afternoon and nobody will notice until somebody checks. Three changes fix most of it, and none is expensive. **Restrict publishing rights** on the container to people inside the business, and make agencies request rather than deploy. **Separate the clinical pages** into their own container or their own consent configuration, so a tag added for the marketing site cannot reach the intake by default. **Diff the tag list monthly** against the register and read what changed. This is a ten-minute job and it is the only control that reliably catches the tag somebody added for a two-week test in March. Where a consent mechanism is in use, check what it actually gates. A banner that appears while the tags have already fired is a design decision somebody made for measurement reasons, and it is visible in the network panel in the order the requests appear. ## Where this meets the certification file Two connections, and both are practical rather than theoretical. The first is that the privacy documents have to be right and distinct. A website privacy policy describes what the site collects. A Notice of Privacy Practices is the document a covered entity provides describing how protected health information is used and disclosed. Publishing one under both names is a common, cheap and highly visible defect. The second is that what the documents say has to match what the pages do. A privacy policy stating that health information is never shared with advertisers, served on a page firing an advertising pixel mid-intake, is a discrepancy on a single screen. That is the same class of finding as [a claim the website cannot support](/blog/what-disqualifies-a-legitscript-application), and it is found the same way. ## What to keep afterwards A short tag register: page, tag, purpose, what it receives, who approved it, and the date. Add a rule that new tags on clinical pages need the same approval as new claims copy, because both are ways the site says something the business did not intend. That register also answers the diligence questionnaire from the enterprise buyer and the security review from the partner, which is the usual pattern with this work: the artefact outlives the reason you built it. ## Frequently asked questions ### Are advertising pixels on a telehealth site actually a certification problem? They are a privacy problem first, and an independent regulatory issue. They become a certification problem because a reviewer reads your site closely and can see what loads, and because tracking that contradicts your own privacy policy is a discrepancy on a single page. ### Can I keep measuring conversions if I remove pixels from the intake? Usually yes. Most funnels can fire a conversion event after the sensitive step, from a URL and payload that name no condition. That is a measurement design question rather than a choice between compliance and analytics. ### Is a privacy policy enough, or do I need a Notice of Privacy Practices? They are different documents. A privacy policy describes what a website collects and how it is used, while a Notice of Privacy Practices is the HIPAA-mandated document describing how a covered entity uses and discloses protected health information. A covered entity needs both. ## Disclaimer LegitScript is a trademark of LegitScript LLC. VeriScripts is an independent application-preparation service. It is not affiliated with, endorsed by, or certified by LegitScript LLC, and claims no sponsorship or partnership with it. We prepare, submit, and manage the application; LegitScript alone decides whether certification is granted. "LegitScript" is used here only to name the certification these applications are for.