Online booking widgets on a practice website: data, tracking and claims

A “Book online” button is a useful thing for a practice website to have. A patient picks a reason for the visit, a clinician, a time, and types a name, phone number and date of birth. In those few screens, the website has collected information about a person’s health care and handed it to a scheduling company, and possibly to an analytics or ad tool as well. The button is also a promise: that the times shown are real and that booking works the way the page says.

This guide covers the booking widget itself: who the scheduling vendor is under HIPAA, what to keep off booking pages, the state consumer health data laws that reach practices outside HIPAA, accessibility of the booking flow and the accuracy of booking claims. Related topics are in our guides to website contact and appointment forms, online patient intake forms and tracking pixels on practice websites. If you add a price estimator next to booking, see online price estimators on practice websites.

The short version

• A booking vendor that creates, receives, maintains or transmits protected health information for a HIPAA covered practice is generally a business associate, and the practice needs a written business associate agreement before patient information flows (45 CFR 160.103; 164.502(e); 164.504(e)).
• HHS uses booking as its example: if a patient makes an appointment through a clinic website that runs third party tracking, the tracking vendor can receive appointment details and the IP address, and a BAA is required (OCR online tracking bulletin).
• A federal court vacated one part of that bulletin in 2024, about IP addresses on unauthenticated public pages. The part about appointment and booking pages was not what the court vacated, per the HHS note on the bulletin.
• Washington’s My Health My Data Act and Nevada’s consumer health data law can apply to practices that are not covered by HIPAA, such as a cash-pay practice that does not bill insurance electronically (RCW 19.373; NRS 603A.400 to 603A.550).
• The booking flow is part of your website for accessibility: keyboard use, labels, error messages and time limits all matter (DOJ web accessibility guidance; WCAG 2.2).
• “Book online 24/7” and “same-day appointments” are factual claims, and the FTC Act bars deceptive acts or practices in commerce (15 USC 45(a)(1)).

What a booking widget actually collects

Booking tools come in a few shapes: a link that opens the vendor’s own booking page, a frame embedded in your page, or a script that draws the booking form inside your page. In each case, the patient’s choices and details go to the vendor’s servers. Depending on how you set it up, that can include the reason for the visit, the type of clinician, new or existing patient status, insurance, date of birth, contact details and free-text notes.

Under the HIPAA definitions, protected health information is individually identifiable health information, and that includes information that relates to the provision of health care to an individual and identifies the individual (45 CFR 160.103). A name with an appointment for a stated reason at your practice fits that description. The OCR bulletin lists dates of appointments among the kinds of information that tracking tools on a website can disclose.

Before choosing or reconfiguring a tool, write down each field the booking flow asks for and where each answer goes: the vendor, your practice management system, email or text confirmations, and any analytics or ad tools on the page.

The scheduling vendor as a business associate

HIPAA defines a business associate as a person who, on behalf of a covered entity and outside its workforce, creates, receives, maintains or transmits protected health information for a regulated function or activity, and the definition names practice management among those activities (45 CFR 160.103). A booking vendor that receives appointment requests with patient details for your practice fits that description.

A covered entity may let a business associate create, receive, maintain or transmit protected health information on its behalf only if it obtains satisfactory assurance that the business associate will safeguard the information, and that assurance must be documented in a written contract or other written arrangement that meets 45 CFR 164.504(e) (45 CFR 164.502(e)(1)(i), (e)(2)). Among other things, that contract must:

• Set the permitted and required uses and disclosures of the information by the vendor (164.504(e)(2)(i)).
• Require the vendor to use appropriate safeguards and comply, where applicable, with the Security Rule for electronic protected health information (164.504(e)(2)(ii)(B)).
• Require the vendor to report uses or disclosures not provided for by the contract, including breaches of unsecured protected health information (164.504(e)(2)(ii)(C)).
• Require the vendor to make sure its own subcontractors that handle the information agree to the same restrictions (164.504(e)(2)(ii)(D)).
• Require the vendor, at the end of the contract and if feasible, to return or destroy the information, or extend the contract’s protections to it if that is not feasible (164.504(e)(2)(ii)(J)).

No federal rule we found tells a practice which booking product to use. We recommend reading the vendor’s agreement before setup and asking three plain questions: Will you sign a BAA for this product and plan? Does it cover the booking widget, reminders and any built-in analytics? Which subcontractors receive our patients’ details?

Tracking on booking pages

The OCR bulletin explains how tracking technologies on a regulated entity’s website can send information to third parties. It gives this example: if an individual makes an appointment through the website of a covered health clinic for health services and the website uses third party tracking technologies, the website might automatically transmit information about the appointment and the individual’s IP address to a tracking technology vendor. In that case, the bulletin says, the tracking vendor is a business associate and a BAA is required.

The bulletin also says a privacy policy or terms of use that mention the tracking are not enough on their own to permit disclosures of protected health information, and that cookie banners asking users to accept or reject tracking do not constitute a valid HIPAA authorization.

On June 20, 2024, the U.S. District Court for the Northern District of Texas, in American Hospital Association v. Becerra (No. 4:23-cv-1110), vacated part of the bulletin. The HHS note at the top of the bulletin says the court vacated the guidance to the extent it provides that HIPAA obligations are triggered where an online technology connects an individual’s IP address with a visit to an unauthenticated public webpage addressing specific health conditions or healthcare providers. A booking flow, where a patient enters details and requests an appointment, is a different situation from a visit to a public information page. Our guide to tracking pixels covers the ruling in more detail.

No federal rule we found requires a particular setup. We recommend:

• Keep ad pixels, session replay and third party analytics off booking pages and confirmation pages, unless the vendor has signed a BAA that covers that use and counsel has confirmed a permission applies.
• Check what an embedded widget loads on its own. A booking frame can carry the vendor’s scripts, and a script-based widget runs inside your page next to your own tags.
• Do not send “booked an appointment” events with visit reasons or patient details to ad platforms. If you measure bookings, count them without patient details.
• Test the page after each change to the site or the widget, using the browser’s network tools, and keep a dated note of what loaded.

Chat tools and session replay on the same page raise separate wiretap law questions, covered in our guide to website chat and session replay.

When HIPAA does not apply: state consumer health data laws

Not each practice is a HIPAA covered entity. A health care provider is covered only if it transmits health information electronically in connection with a HIPAA standard transaction (45 CFR 160.103). A cash-pay practice that does not bill insurance electronically may fall outside HIPAA. State laws can still reach its booking widget.

Washington. The My Health My Data Act defines consumer health data as personal information linked or reasonably linkable to a consumer that identifies the consumer’s past, present or future physical or mental health status, and lists data that identifies a consumer seeking health care services among its examples (RCW 19.373.010). A regulated entity or small business may collect consumer health data only with consent for a specified purpose or to the extent necessary to provide a product or service the consumer requested, and may share it only with separate consent or to that same extent (RCW 19.373.030(1)). It must keep a consumer health data privacy policy and link to it from its homepage (RCW 19.373.020(1)). The act also makes it unlawful to implement a geofence around an entity that provides in-person health care services to identify or track consumers seeking care, collect their health data or send them ads related to it (RCW 19.373.080). Information that is protected health information under HIPAA is exempt (RCW 19.373.100(1)(a)(i)), so the act matters chiefly for information HIPAA does not cover. A violation is treated as an unfair or deceptive act under the state Consumer Protection Act, chapter 19.86 RCW (RCW 19.373.090).

Nevada. Nevada’s law has similar consent rules for collecting and sharing consumer health data (NRS 603A.500) and requires policies and practices for the security of that data (NRS 603A.525). It differs from Washington’s in one useful way for practices: it does not apply to a person or entity that is subject to HIPAA (NRS 603A.490(1)(a)).

For a cash-pay practice with Washington or Nevada patients, the booking flow is where consumer health data is first collected. Collecting a booking request the patient makes can fall under the exception for providing a service the consumer requested. Sending the same details to an ad platform is not needed to provide that service, so under the Washington act it would need separate consent (RCW 19.373.030(1)(b)). Other states have health data or general privacy laws too, summarized in our guide to consumer health data privacy laws, and your website privacy policy should describe the booking tool accurately.

Confirmations and reminders

Booking tools send confirmation and reminder emails or texts. A covered health care provider must permit patients to request, and must accommodate reasonable requests, to receive communications of protected health information by alternative means or at alternative locations (45 CFR 164.522(b)(1)(i)). In practice, that means your booking setup needs a way to honor a patient who asks not to receive texts at a shared phone or emails at a work address.

No federal rule we found sets the content of a reminder. We recommend keeping reminders to the date, time, location and a way to reschedule, and leaving the reason for the visit out. Email rules are covered in our guide to practice email and fax under HIPAA.

Accessibility of the booking flow

The Department of Justice guidance on web accessibility says businesses open to the public must make sure the goods and services they provide, including those provided online, are accessible to people with disabilities. It names online forms among the features to check, including labels, keyboard access, clear instructions and telling screen reader users when a field is entered incorrectly. It points to WCAG as an existing technical standard that helps.

Booking widgets bring a few WCAG 2.2 success criteria to the front:

• Keyboard (2.1.1). All functionality, including choosing a date from a calendar and picking a time slot, must be operable through a keyboard.
• Timing adjustable (2.2.1). If the widget holds a slot for a limited time, the user can turn off or adjust the limit, or is warned before it expires and given at least 20 seconds to extend it with a simple action, with listed exceptions.
• Labels or instructions (3.3.2) and error identification (3.3.1). Each field has a label, and an error is identified and described in text.
• Redundant entry (3.3.7). Information the patient already entered in the same process is filled in or available to select, rather than typed again, with listed exceptions.
• Name, role, value (4.1.2). Custom controls such as date pickers expose their name, role and state to assistive technology.

You do not control the vendor’s code, but the widget is on your site. We recommend asking the vendor for its accessibility documentation, testing the booking flow with a keyboard and a screen reader before launch, and keeping a phone number next to the button for patients who prefer to call. Our guide to website accessibility for medical practices covers the wider rules.

Claims about booking

Section 5 of the FTC Act makes unfair or deceptive acts or practices in or affecting commerce unlawful (15 USC 45(a)(1)). Booking claims are factual: a patient reads “same-day appointments” and expects to see a time today. No rule we found sets specific wording. We recommend:

• Say “request an appointment online” if staff confirm each request, and “book online” only if the patient gets a confirmed time.
• Say “book online 24/7” only if the tool takes bookings at all hours, and say when staff will confirm requests made after hours.
• Show only real open slots. Hiding slots that are held for other reasons is fine, but showing slots that cannot be booked is not.
• Make the visit types clear: if new patients, certain plans or certain services cannot book online, say so before the patient fills in the form.
• Keep the website, your Google Business Profile booking link and any ads pointing to the same working booking page.

Availability claims such as “accepting new patients” and “same-day” are covered in depth in our guide to availability claims. For requests that are started but never finished, see following up on abandoned appointment requests.

Questions to ask a booking vendor

• Will you sign a business associate agreement for the product and plan we are buying, and what does it cover?
• Which subcontractors receive our patients’ booking details?
• Which scripts, cookies or analytics does the widget load on our page or in its frame?
• Can we turn off built-in tracking or ad integrations?
• Can we choose which fields the booking form asks for, and leave out the reason for the visit?
• What happens to our patients’ data if we end the contract?
• What accessibility testing has the widget had, and against which version of WCAG?
• Can patients choose how they receive confirmations and reminders?

Use and avoid

• Use: “Request an appointment online. Our team confirms requests during office hours.”
• Avoid: “Book instantly, 24/7” when staff confirm each request the next day.
• Use: a booking form that asks only for what you need to schedule.
• Avoid: a free-text box that invites patients to describe symptoms.
• Use: a booking page with no ad pixels or session replay.
• Avoid: sending “booked: dermatology consult” events to an ad platform.
• Use: reminders that give date, time and place.
• Avoid: reminders that name the procedure.

An illustration

This example is invented. [Practice name] is a physical therapy clinic that bills insurance and wants to add online booking. The owner reads the vendor’s agreement and confirms the BAA covers the booking widget and reminders. The office manager lists each field and removes a free-text “tell us about your pain” box. The web developer checks the booking page with the browser’s network tools, finds an ad pixel loading from the site’s tag manager and removes it from booking and confirmation pages. The button says “Request an appointment” because staff confirm each request, and the page says requests made after 5 p.m. are confirmed the next business day. Before launch, a staff member books a test visit using only a keyboard and finds that the calendar cannot be reached. The vendor fixes it, and the clinic retests before going live.

Checklist

• Map each booking field and where each answer goes.
• Sign a BAA with the booking vendor before patient information flows, and confirm what it covers.
• Remove ad pixels, session replay and unapproved analytics from booking and confirmation pages, and retest after site changes.
• Measure bookings without sending visit reasons or patient details to ad platforms.
• If you are not covered by HIPAA and see Washington or Nevada patients, review consent and privacy policy duties under RCW 19.373 and NRS 603A.
• Keep reminders free of visit reasons, and honor requests for alternative contact methods.
• Test the booking flow with a keyboard and a screen reader, and keep a phone option next to the button.
• Match the button and page wording to how booking actually works, and keep the Google Business Profile link and ads pointing to the same page.

How we help

We build websites, local and organic search, Google Ads and lead generation and an AI front desk for independent practices. For online booking, that means a booking page without ad tracking, measurement that leaves patient details out, an accessible booking flow and button wording that matches how your scheduling works. Our tools are built with HIPAA in mind. We confirm in writing what a BAA covers before any patient information flows through a tool, and if it is not covered, we do not route patient information through it. We are not a healthcare provider and we do not give legal or medical advice. For the wider rules, see our healthcare marketing rules guide.

Sources

• 45 CFR 160.103: Definitions (business associate, health care provider, protected health information)
• 45 CFR 164.502: Uses and disclosures of protected health information: General rules
• 45 CFR 164.504: Uses and disclosures: Organizational requirements
• 45 CFR 164.522: Rights to request privacy protection for protected health information
• HHS OCR: Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates
• HHS OCR: Business Associates
• Washington RCW 19.373: Washington My Health My Data Act
• Nevada NRS 603A: Security and privacy of personal information (consumer health data, NRS 603A.400 to 603A.550)
• U.S. Department of Justice: Guidance on Web Accessibility and the ADA
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• 15 USC 45: Unfair methods of competition and unfair or deceptive acts or practices

More in Practice websites, privacy and tracking