Almost every practice website has one: a scheduling widget, an intake form, a review carousel or a chat box, dropped in from a third party and rendering inside the page as though it belonged there. It looks like part of your site to a visitor, and it is not part of your site in any of the ways that matter for embedded forms and consent.
This is the one category where an honest consent implementation has a genuine limit rather than a configuration gap, and it is worth understanding precisely, because the workarounds people reach for do not work and the ones that do work require a decision rather than a setting.
Why embedded forms and consent do not mix
An iframe creates a separate browsing context. The browser treats the embedded document as its own page with its own scripts, its own cookies and its own network requests, and the same-origin policy that makes the web safe also means your page cannot read into it or control it.
What a consent gate can and cannot do here
It can prevent the iframe element from being created at all, which stops everything inside it. It cannot allow the frame to load and then selectively disable the trackers within it, because the code inside the frame is not yours to reach. The choice is binary: the embed loads, or it does not.
That binary is the whole problem. A scheduling embed is usually load-bearing for the business. Practices are reluctant to hide the thing that books appointments behind a consent decision, so the embed gets exempted, and the exemption quietly covers the page where the most sensitive interaction on the entire site happens.
The exemption is rarely made as a deliberate decision, either. It happens because someone classified the embed as an essential script, which is defensible on its face: the page does not function without it. Essential is a category that exists to cover things a site genuinely cannot operate without, and a booking widget looks like a member of that family. The trouble is that essential in a consent taxonomy means necessary to deliver a service the visitor asked for, and it is not a licence for whatever else that vendor's code happens to do while delivering it.
Worth noticing how the reasoning about embedded forms and consent tends to run in practice. Nobody decides to exempt the most sensitive page on the site. Someone decides that the booking widget is essential, which is true, and the consequence follows silently three steps later.
What leaks around the edges anyway
Even setting aside what happens inside the frame, three things escape that practices rarely account for. All three are on your side of the boundary, which is the good news buried in this section: they are yours to fix without anyone's cooperation.
Your own tags see the page. The visitor is on your URL while they type into the embed. Every analytics and advertising tag on that page records the visit to a page whose address may name a treatment, alongside a persistent identifier. Nothing about the embed changes that, and it is the more common exposure of the two.
The vendor learns which page framed it. An embed request typically carries the referring URL, so the vendor knows the frame was loaded from your consultation page even before anyone interacts with it.
The interaction itself may be observable. Depending on implementation, form submissions can trigger page-level events, redirects to thank-you URLs, or parent-page messages carrying parameters. A thank-you URL containing the service requested is a widespread pattern and it is fully visible to every tag on your site.
That last point reframes the problem usefully. Before worrying about what the vendor's iframe does, deal with what your own page does around it, which is entirely within your control and covered in where tracking tags actually load.
The vendor question underneath
The technical boundary can distract from a prior contractual question. If the embedded vendor receives protected health information on your behalf, 45 CFR 164.502 requires a business associate contract, and the fact that the code renders in a frame is irrelevant to that analysis.
For a scheduling or intake vendor the answer is usually straightforward: they are handling appointment requests containing health context, they know it, and they will sign. That is their business. The decision tree is in do you need a BAA with your analytics vendor, and it applies unchanged here.
The harder question is what the vendor loads inside its own frame. A form vendor with a signed agreement may still run its own analytics, its own error monitoring and, occasionally, its own advertising tags within that frame. Those are the vendor's subprocessors, not yours, and the only way to know is to ask them directly and read the answer. It is a fair question and a reputable vendor will answer it.
Embedded forms and consent: the options that actually work
Four approaches, and the trade-offs are real rather than rhetorical.
Gate the embed. Hold the iframe until the visitor agrees, replacing it with a short explanation and a button. This is the technically correct answer and it costs conversions, because a proportion of visitors will not click through a placeholder to reach a booking form. How large that proportion is depends on how the placeholder is written, and it is worth measuring rather than assuming.
Link out instead of embedding. Send visitors to the vendor's own hosted page. Less elegant, and arguably a cleaner boundary: the interaction happens in a context the vendor is plainly responsible for, rather than one that appears to be yours. It also removes your page's tags from the interaction entirely, since the visitor is no longer on your site while completing it.
Clean the page around the embed. Keep the embed and remove non-essential tags from that page specifically. This does not address what happens inside the frame and does address the more common exposure, and it costs nothing in conversion. For most practices this is the highest-value first move.
Use a first-party form. A form you host, posting to a system you control under a contract you hold, removes the boundary problem altogether. More build effort, and it puts the data where you can govern it.
A word on the fix that gets suggested most often and does not work: adding a sandbox attribute to the iframe. Sandboxing restricts what the embedded document may do, and it is a genuinely useful security control, but the restrictions it offers do not include preventing the frame from loading its own resources or contacting its own vendors. Applying it tightly enough to block those generally breaks the form. It addresses a different threat model than this one.
Two other things regularly proposed and worth dismissing quickly. Loading the embed only when it scrolls into view delays the requests without preventing them, so it changes the timestamp rather than the outcome. And placing the embed behind a tab or accordion hides it visually while the iframe usually still loads with the page, which is the worst combination: no visitor benefit, unchanged exposure, and a plausible belief that something was done. Whether any of it is loading is answerable from a network panel in the way described in consent mode is not tag blocking.
Most practices end up combining the third with either the first or the fourth, which is a reasonable place to land. What does not work is treating the embed as though it were covered by your consent implementation because a banner appears on the page. It is not, and a scan will say so.
One last thing worth checking, because it is invisible from the front end: what the thank-you page does. If a submission redirects to a URL naming the service requested, and that page carries your ordinary advertising tags, then the most sensitive fact in the whole interaction is being announced to every third party on your site at the exact moment it becomes true. That pattern is extremely common, it has nothing to do with iframes, and it is usually fixed in ten minutes by whoever configured the form. Holding non-essential tags by default, which is what consent gating does, means the pattern cannot fire silently while you work out whether to keep it.
Key takeaways
- An iframe is a separate browsing context. A consent gate can stop it loading entirely but cannot disable trackers inside it.
- The most common exposure on an embedded-form page is your own tags recording the visit, not the frame's behaviour.
- The vendor learns which page framed it through the referrer, before anyone interacts with the form.
- A vendor receiving PHI on your behalf needs a business associate contract whether or not its code renders in a frame.
- Ask the vendor what runs inside its own frame. Their subprocessors are not visible to you and a reputable vendor will tell you.
- Check the thank-you page. A redirect to a URL naming the requested service announces it to every tag on your site.
Common questions
Can a consent banner block tracking inside an embedded form?
No. An iframe loads in its own browsing context with its own scripts, and same-origin policy prevents your page from reading or controlling what happens inside it. A gate on your page can prevent the iframe from loading at all, but it cannot selectively disable trackers within it.
Is the practice responsible for what an embedded form vendor collects?
The practice chose the vendor and placed the embed, so the arrangement is generally the practice's to govern. If the vendor receives protected health information on the practice's behalf, the business associate contract analysis applies to that vendor in the ordinary way, regardless of the fact that the code renders in a frame.
What is the safest way to use a third-party scheduler?
Hold the embed until the visitor has been told what it does and agreed, or replace the in-page embed with a link to the vendor's own hosted page. Linking out is less elegant and it moves the interaction to a context the vendor is responsible for, which is a cleaner boundary than an embed that appears to be yours.
Sources
- 45 CFR 164.502, uses and disclosures of protected health information, including the business associate contract requirement Electronic Code of Federal Regulations
- Consent mode overview, Google Tag Platform documentation For which tags participate in a consent signal and which do not
Find the pages where a form sits next to an ad tag
The free scan checks your health-intent pages specifically and flags any that pair a form with advertising or analytics tracking.