HIPAA-Compliant Websites: What Your Practice Must Fix

If your practice runs Google Ads or Meta Ads, there is a real chance your appointment-request page is quietly forwarding patient information to two of the largest advertising companies on earth. Not on purpose. Because someone pasted a tag into your site header three years ago and nobody read the rules.

This is a build spec, not legal advice. We build websites and run ad accounts; we are not your lawyer, and every compliance call belongs with your privacy counsel. What we can hand you is the exact list of code on your site that creates exposure, what HHS has actually published about it, and how to keep your conversion tracking alive without sending protected health information to a third party.

What makes a medical practice website HIPAA-compliant?

There is no such thing as a HIPAA-certified website. HIPAA regulates what your site does with protected health information (PHI) — not what platform it runs on. A WordPress site can be clean and a $40,000 custom build can be a breach waiting to happen.

The HHS Office for Civil Rights guidance on online tracking technologies puts it bluntly: individually identifiable health information collected on a regulated entity's website "generally is PHI, even if the individual does not have an existing relationship with the regulated entity." Not just diagnoses. An email address plus the fact that someone requested an appointment is enough.

So compliance is a data-flow question, and there are only four flows to audit:

• What a patient types. Appointment forms, symptom checkers, callback requests, portal logins. Anything a person keys in that relates to their health, care, or payment for care.
• What third-party code watches while they type it. Pixels, analytics tags, session-replay scripts, chat widgets, heatmap tools. These see the page, the URL, and sometimes the form fields.
• Where the submission goes. Your form plugin, its SMTP relay, your inbox, your CRM, your call-tracking number. Every hop is a vendor.
• What sits at rest. Form entries in your WordPress database, PDFs on your host, exports in a shared Google Drive.

Fix those four and you have fixed the website. Everything else — the badge in the footer, the privacy policy your agency copied from another clinic — is theater.

Is your Meta Pixel sending protected health information to Meta?

If the Meta Pixel fires on a page where a patient requests an appointment or names a reason for their visit, then yes — and HHS says that makes the tracking vendor a business associate who must have a signed BAA before that data moves.

The OCR bulletin gives the exact scenario: "if an individual makes an appointment through the website of a covered health clinic for health services and that website uses third party tracking technologies, then the website might automatically transmit information regarding the appointment and the individual's IP address to a tracking technology vendor. In this case, the tracking technology vendor is a business associate, and a BAA is required."

This is not hypothetical. The Markup's Pixel Hunt investigation, published June 16, 2022, tested Newsweek's top 100 US hospitals and found the Meta Pixel on 33 of them "sending Facebook a packet of data whenever a person clicked a button to schedule a doctor's appointment." They also found the pixel installed inside the password-protected patient portals of seven health systems. If hospital IT departments with compliance staff got this wrong, your three-person front desk and a $900/mo agency got it wrong too.

Two escape hatches people reach for, and why HHS closes both:

• The cookie banner. HHS: "Website banners that ask users to accept or reject a website's use of tracking technologies, such as cookies, do not constitute a valid HIPAA authorization." A consent popup is not consent under HIPAA.
• The vendor promises to scrub it. HHS: "it is insufficient for a tracking technology vendor to agree to remove PHI from the information it receives or de-identify the PHI before the vendor saves the information." The disclosure happens at transmission, not at storage.
• The privacy policy disclosed it. HHS: the Privacy Rule "does not permit disclosures of PHI to a tracking technology vendor based solely on a regulated entity informing individuals in its privacy policy" that it plans to.

The practical read: unless you hold a signed BAA from the tracking vendor, a client-side pixel has no business firing on any page a patient can type into. Not the appointment form. Not the thank-you page. Not the portal login.

Does Google Analytics on your appointment page create exposure?

Google's own policy already forbids the input: Google Analytics help states that "Google policies mandate that no data be passed to Google that Google could use or recognize as personally identifiable information (PII)," and names email addresses and personal mobile numbers as examples.

Which means the entire burden of keeping PHI out of GA4 sits on you, and GA4's defaults are working against you. Enhanced measurement fires form_start and form_submit automatically. Page URLs and referrers are collected on every hit. If your booking flow lands on a URL like /request-appointment/?service=std-testing or /thank-you?provider=oncology, you just wrote a diagnosis into an analytics hit.

The build rules for any practice site we'd ship:

• No condition, service line, or provider specialty in a URL path or query string on any post-form page. Use a generic /thank-you.
• Strip query parameters before they reach GA4, or exclude them at the property level.
• Turn off enhanced measurement form interactions on clinical forms. You do not need GA4 to tell you a patient started typing.
• Never pass an email, phone number, patient ID, or user_id as an event parameter. Not raw, not hashed.
• Do not load analytics at all on the patient portal login or registration page — HHS treats what a patient enters there as PHI even though the page is public.
• Ask Google in writing whether they will execute a BAA covering Analytics, and get the answer in writing before you rely on it. Assume no BAA until you are holding one.

Is your contact form emailing PHI in plain text?

This is the most common leak in a practice website, and almost nobody looks at it: a standard WordPress contact form takes what a patient wrote, stores it in your database, pushes it through an SMTP relay, and drops it in a personal inbox — three or four vendors deep, usually with zero BAAs.

Trace it once and you will see it. Contact Form 7 or Gravity Forms captures the message. The submission is written to your WordPress database on a shared host. It leaves through your host's mail server or a relay like SendGrid. It lands in a Gmail or Outlook inbox that may or may not sit under a Workspace BAA. Each of those hops is a vendor "transmitting" PHI on your behalf, which is exactly HHS's definition of a business associate.

TLS on the website is the easy half. The half everyone forgets is the mail hop and the inbox, and HHS Security Rule obligations follow the ePHI wherever it goes.

The lazy compliant design — which is also the highest-converting one — is a form that collects the minimum necessary and hands off. Ask for what you need to call the person back, not for their medical history:

Verdict: the condition dropdown is the single field to delete today. It is the one that turns an ordinary lead form into a structured PHI feed for every tag on the page, and it is almost always there because a marketer wanted cleaner segmentation. Every field you add is a liability you now have to encrypt, store, account for, and breach-notify on. Design accordingly, the same way you'd design any conversion-focused website — fewer fields, faster response, more booked appointments.

Who needs to sign a business associate agreement, and did they?

HHS defines a business associate as a person or entity outside your workforce "who performs functions or activities on behalf of, or provides certain services to, a covered entity that involve access by the business associate to protected health information" — and for a website that usually means five or six vendors you have never thought about as vendors.

The BAA is not a formality. HHS requires the written contract to establish permitted uses, require safeguards including the Security Rule for ePHI, require the vendor to report breaches to you, require the same terms to flow down to their subcontractors, and let you terminate for a material violation.

And here is the line that should end the debate in your practice: HHS states that "a tracking technology vendor is a business associate if it meets the definition of a business associate, regardless of whether the required BAA is in place." Not having a BAA does not mean the obligation does not exist. It means you are already out of compliance with it.

Honest verdict: the two vendors most likely to be missing a BAA are the two nobody thinks of as healthcare vendors — your web host and your marketing agency. Start there.

What questions should you ask your host and your marketing agency?

Six questions, written answers, one week. If your agency cannot answer them, that is the answer — and it tells you more about them than any deck they have ever sent you.

• Will you sign a BAA? Send it. If the answer is 'we don't need one,' ask them to put that sentence in writing, in an email, with their name on it. Watch how fast the tone changes.
• List every third-party script on our site and what data each one receives. A competent agency produces this in an hour. If they need a week, they don't know what is on your site.
• Which of our pages can a patient type into, and which tags fire on those pages? This is the whole audit in one question.
• Where do form submissions physically go? Which server, which mail relay, which inbox, which CRM. Names, not categories.
• Is our conversion tracking client-side or server-side, and exactly which parameters are sent? If they say 'the standard pixel setup,' you have your answer.
• Who owns our ad accounts, our analytics property, and our site? The answer should be you. If it isn't, read who should own your Google Ads account before you sign anything else.

Our stance on the last one is not negotiable: the client owns everything — the ad accounts, the analytics, the codebase, the content. An agency that holds your Meta pixel hostage in their own Business Manager is also an agency that controls the evidence of what it sent to Meta from your appointment page.

How do you track conversions without transmitting PHI?

Send an event, not a patient: your server reports "a lead happened, value $X, internal ID 4471" — with no name, no email, no hashed phone, no URL parameter, and no clinical detail attached. That is the whole trick, and HHS effectively endorses the architecture.

The bulletin says that if a tracking vendor will not sign a BAA, a regulated entity "can choose to establish a BAA with another vendor, for example a Customer Data Platform vendor, that will enter into a BAA with the regulated entity to de-identify online tracking information that includes PHI and then subsequently disclose only de-identified information to tracking technology vendors that are unwilling to enter into a BAA." In plain English: put a layer you control between the patient and the ad platform, and only let de-identified data out.

Concretely, for a practice running Google Ads or Meta Ads:

• Kill automatic advanced matching in your Meta Pixel settings. It scrapes form fields — email, phone, name — off the page and sends them to Meta. On a medical site that is the exact behavior you are trying to stop.
• Move the conversion to the server. The form posts to your backend. Your backend, not the browser, decides what leaves the building. Our Meta Pixel + CAPI server-side setup guide covers the plumbing — but the standard build there sends hashed emails and phone numbers for match quality. For a medical practice, strip them.
• Do not use hashed PHI as a loophole. Hashing an email address does not de-identify it for HIPAA purposes, and HHS already said a vendor scrubbing data after receipt is insufficient. Offline conversion uploads of patient emails are the same violation with extra steps.
• Accept the cost. Without emails and phones, match rates drop and attribution gets fuzzier. That is the price of not putting a diagnosis in a Facebook payload. Pay it.
• Measure where it actually counts. Booked appointments, show rate, and cost per booked appointment out of your practice management system — not clicks and pixel conversions. That's a longer-window measurement problem, and tracking conversions across long sales cycles is the same discipline.

This does not blind you. You still get campaign-level cost, click, and lead counts. You lose granular audience retargeting built on patient behavior — which, for a mental health practice or an addiction-treatment clinic, you should not want in the first place.

What should you fix first, and what can wait?

Fix the pages a patient can type into — appointment request, contact form, symptom checker, portal login and registration — this week. The pages about your office hours, your staff bios, and your parking situation can wait, and a federal court is the reason why.

HHS's own note at the top of the tracking guidance says that on June 20, 2024, the U.S. District Court for the Northern District of Texas vacated part of it. Specifically, the court struck the guidance "to the extent it provides that HIPAA obligations are triggered in 'circumstances where an online technology connects (1) an individual's IP address with (2) a visit to a[n] [unauthenticated public webpage] addressing specific health conditions or healthcare providers.'" HHS says it "is evaluating its next steps in light of that order."

Read what that actually removed. It removed the most aggressive edge — the theory that an IP address plus a visit to your public cardiology page is automatically PHI. It did not touch authenticated pages, and it did not touch unauthenticated pages where the patient enters information. The appointment form is still the appointment form. That is why it is P0 and the service page is P2.

• P0, this week: remove all third-party tags from appointment/contact/symptom/portal pages. Delete the condition dropdown. Strip clinical detail from URLs.
• P1, this month: trace the form-to-inbox path, get BAAs from your host, form vendor, and agency, or replace them. Rebuild conversion tracking server-side without PHI.
• P2, this quarter: privacy policy that reflects what your site actually does, risk analysis that names your tracking technologies, and a written vendor inventory you can hand to counsel.

One more reason not to file this under "probably fine." If you are convinced you're not a covered entity, the FTC has the same behavior covered from the other side. Under a February 2023 FTC order, GoodRx will pay a $1.5 million civil penalty for failing to report its unauthorized disclosure of consumer health data — it had shared users' prescription medications and personal health conditions with Facebook, Google, and Criteo. BetterHelp was required to pay $7.8 million for revealing email addresses, IP addresses, and health questionnaire information to Facebook, Snapchat, Criteo, and Pinterest. Neither was a HIPAA penalty. "We're not a covered entity" is not the shield people think it is.

The good news: none of this costs you patients. A form with fewer fields converts better, a page with fewer third-party scripts loads faster, and clean server-side tracking still tells you which campaigns booked appointments. Compliance and conversion pull in the same direction here — most practices just never rebuilt the site to reflect it. If yours was built by an agency that never mentioned any of this, the rest of the healthcare SEO stack is probably just as unexamined.

If you want the pages a patient types into rebuilt properly — minimum-necessary forms, no leaking tags, server-side conversions that still let you run ads — that's what our website design service is for, month to month, no lock-in. Get my free audit and we'll tell you which scripts are firing on your appointment page before you pay us a dollar.