Conversion tracking for a medical practice that never lets a patient detail reach the tag

A practice that wants to know which campaign produced which appointment has two bad options in front of it by default. Measure nothing, and every media decision is a guess. Or install the standard tracking a marketing agency installs anywhere else, and within a week the analytics account is holding appointment reasons in page paths, names in form field values, and phone numbers in call-tracking transcripts held by a vendor nobody has a business associate agreement with. Both of those are decisions, and the second one is usually made by accident.

The most common way a practice leaks protected health information is not the analytics tool. It is a thank-you page URL carrying the appointment reason in a query string, indexed and passed to every tag on the page.

1. 01

   The leak is almost always the URL, not the tool

   Booking systems love to write state into the address bar: reason, provider, insurance, date of birth. Every tag on the page receives the full URL by default. Stripping query parameters at the tag layer, and configuring the booking system not to write them in the first place, removes more risk than any setting inside the analytics product.

2. 02

   A call-tracking vendor is a business associate whether or not anyone treated it as one

   Recorded calls to a medical practice contain protected health information within the first fifteen seconds. If the vendor will not sign a business associate agreement, the build uses call counting without recording, and that constraint is decided before the number is provisioned, not after.

3. 03

   A conversion you cannot name is still a conversion you can count

   The event taxonomy carries appointment_request and call_started, never appointment_request_dermatology. Service line lives in a parameter with a fixed allow-list of non-clinical categories, so reporting can still separate new-patient from returning demand without describing anyone's condition.

4. 04

   Consent and containment are different jobs and a banner only does one of them

   A consent banner governs whether tags fire. It does nothing about what those tags receive once they do. The containment work — parameter stripping, field-value suppression, an isolated scheduling frame that passes no data to the parent page — has to exist underneath the banner.

**89% of patients say booking at any hour matters, but only 11% of medical groups say most of their patients can** (Experian Health 2024; MGMA 2024), and physician search converts at **12.43%** at a **$40.04** lead cost (WordStream 2026). You can't optimise a 24/7 booking funnel you're legally barred from measuring the normal way — so measurement is the precondition.

Everything is event-based and nothing is free-text. The scheduling widget renders in an isolated frame that cannot read or write the parent page, so the parent page never sees what was booked. Tag Manager runs a strip-and-allow model: query parameters are removed before any tag receives the URL, form-field values are never read, and only a named list of events and parameters is permitted through. Tagging runs server-side so the payload is inspectable before it leaves. Call tracking is count-only unless the vendor is under a business associate agreement. The result is a reporting layer that can answer which channel produced which appointment type without holding anything about a person.

1. 1

   Week 1

   Data inventory

   Every field, parameter and URL the current site writes, listed and classified

   Owner: OmniFlow

2. 2

   Weeks 1–2

   Containment layer

   Parameter stripping, event allow-list, isolated scheduling frame

   Owner: OmniFlow

3. 3

   Weeks 2–3

   Server-side tagging

   Payloads routed through a server container and inspected before dispatch

   Owner: OmniFlow

4. 4

   Week 3

   Vendor review

   Business associate agreements confirmed or the vendor's capability reduced to counting

   Owner: OmniFlow + practice

This entry makes no performance claim. It documents an architecture and the constraints it was designed against. What it produces is a reporting layer a practice can hand to its own compliance reviewer without a redaction pass first, and a set of decisions that are far cheaper to make before a tag is installed than after eighteen months of data has accumulated in the wrong shape. The artefact worth copying is the written data inventory: every field, parameter and URL the site produces, classified once, so that any later addition has an obvious place to sit or an obvious reason to be refused.

These are the surfaces this engagement is run and measured from, shown with representative figures built around the benchmarks cited on this page. Every account we run reports into views like these, and you keep ownership of all of them.

The first version of the event taxonomy encoded the service line into the event name itself, which made the reports readable and made every event name a small disclosure. It had to be pulled back into a parameter with a fixed allow-list. Naming conventions are a compliance surface in this vertical, and they should be reviewed before anything is instrumented rather than after the reports look good.

Real client work that shipped. No performance figures are published, because none have been verified and approved for release. See all our work