Healthcare Websites: Privacy, Consent and Compliance Basics

Healthcare website compliance comes down to one question: where does information about a person's health go after they type it, click it or just load a page? On a typical clinic site the answer includes a form plugin's database table, three staff inboxes, an analytics account and an advertising pixel, and nobody chose most of those on purpose.

Below, we follow that information through an ordinary website and separate what a developer can fix from what a lawyer has to decide. It is general information from a development team, not legal advice. No hosting plan, plugin or checklist makes a site meet a law by being installed.

Which rules may apply depends on who and where you are

HIPAA is the United States law most people think of. Broadly, it is concerned with protected health information held by "covered entities" (health plans, health care clearinghouses and providers that send health information electronically for standard transactions such as billing) and by the "business associates" that handle it for them. The US Department of Health and Human Services explains who counts as a covered entity.

GDPR may apply if you are established in the European Union or offer services to people there. It treats health-related data as a sensitive category with stricter conditions than ordinary personal data.

Others may reach you as well. In the US, the Federal Trade Commission has rules for health apps and similar services outside HIPAA, several states have health privacy laws, and many countries have national equivalents. Which laws apply to you and what they require are decisions for your own counsel.

A brochure site can still handle health information

"We only have a marketing site" is rarely the whole story. The same site often has an appointment request form with a "reason for visit" box, a contact form where people describe symptoms, a chat widget and a newsletter sign-up on the page about one condition.

Follow a single form submission and count the copies:

• an entry in the WordPress database, if the form plugin stores entries (Gravity Forms does, Contact Form 7 by default only sends email)
• a plain-text notification email in one or more staff inboxes
• a row in a CRM, spreadsheet or help desk through an integration set up years ago
• every backup taken since
• a view open to every administrator account on the site

The cheapest fix is to collect less. Ask for a name, a phone number and a preferred time, and take the clinical detail by phone or inside a system built for it. Where a form must stay, send staff a notification that links to the entry without repeating its content, and set entries to expire. In Gravity Forms that is the retention policy under Form Settings > Personal Data, which can also stop IP addresses being stored. Our Gravity Forms team sets this up routinely.

Audit trackers and pixels first

Analytics and advertising scripts send data to another company on every page load: the page address, an IP address, cookie identifiers and often button clicks. On a health site the page address alone says a lot. A visit to a page about one treatment, followed by a click on "Book now", is information about a person.

For organizations subject to HIPAA, HHS has published guidance on online tracking technologies. It separates pages behind a login from public pages, and a US federal court set aside part of it in 2024, the part dealing with visits to public pages. Where that leaves your public pages is a matter for counsel.

Google states that it does not offer business associate agreements for Google Analytics and that customers subject to HIPAA must not place its tags on HIPAA-covered pages, as set out in Google's note on HIPAA and Google Analytics. Session recording tools and chat widgets need particular attention, because they can capture what a visitor types.

What a developer can do in the meantime:

• list every third-party script on the site and who asked for it
• remove scripts with no owner
• keep advertising pixels off booking, portal and condition pages, or off the site entirely
• move to analytics you host yourself that do not build visitor profiles
• limit who can publish changes in the tag manager

Vendor agreements, including the BAA

In HIPAA terms, a business associate is a person or company that creates, receives, stores or transmits protected health information on behalf of a covered entity. HHS expects a written contract between the two, usually called a business associate agreement or BAA, that sets out what the vendor may do with the information and commits it to safeguards. HHS guidance on cloud computing adds that a provider storing only encrypted data, without the key, is still a business associate.

The practical step is the same for every vendor that could touch patient information: hosting, backups, forms, email, text messages, chat, scheduling and analytics. Ask whether they will sign a BAA for the exact product and plan you use. Many offer one only on certain plans. Some do not offer one at all, and then patient information should not go there. Under GDPR the comparable document is a data processing agreement.

A signed agreement is a starting point, because the service still has to be configured and used in line with it. Keep a register of vendors, what each receives and which agreement covers it.

Hosting, access and backups

If the website stores patient information, the host is one of those vendors and the server needs real controls: HTTPS on every page, encryption at rest, encrypted backups, named accounts with two-factor sign-in, access removed the day someone leaves, activity logs and prompt updates. Staging copies should not contain real form entries. Our WordPress security checklist covers the technical baseline.

The simpler architecture is the one we suggest most often: keep the public website free of patient data. Let it explain and link out, and send booking, intake and messaging to a patient portal or practice system whose vendor is set up for health data. The website then carries far less risk, and routine WordPress maintenance keeps it sound.

Consent is more than a cookie banner

Three different things get called consent, and a site may need all of them.

Consent to tracking. In the EU and some other places, non-essential cookies and similar trackers generally need the visitor's agreement before they run. A banner that informs while the scripts load anyway does not do that. Test yours in a private window with the browser's network panel open, and see what is requested before you click anything. We maintain a consent plugin for Google Tag Manager, and tags that fire ahead of the banner are the fault we find most.

Consent to be contacted. Newsletters and text reminders usually need an opt-in of their own: an unticked checkbox with plain wording, separate from the submit button.

Permission to use health information. Laws define when a patient's written permission is needed and what it must say. Counsel supplies the wording, and the website presents and records it.

For all three, store what the person agreed to, the version of the text they saw and the time. Make withdrawing as easy as agreeing.

An audit you can run in an afternoon

1. List every form and every field. Delete fields nobody reads.
2. For each form, write down where entries are stored, who is emailed, where else the data is sent and when it is deleted.
3. Open the home page, one condition page and the booking page with the network panel open. Note every outside domain contacted, before and after you answer the cookie banner.
4. List every vendor from steps 2 and 3, whether it could see patient information and what agreement you hold.
5. List the administrator accounts. Remove any you cannot put a name to and turn on two-factor sign-in.
6. Find the backups: where they are, how long they are kept and who can download them.

That document is what counsel needs from you, and it doubles as a developer's work list.

Who decides and who fixes in healthcare website compliance

Counsel decides which laws apply, what notices and permissions are needed and which agreements you must hold. A developer removes trackers, rebuilds forms, sets retention, moves hosting, tightens access and makes the consent banner control the scripts. You can run the audit yourself, and most of the fixes are small. Moving patient data off the website is the change worth planning properly. We build to the requirements a client's counsel sets and test against them. We do not certify compliance, and nobody selling a website can. See our work for healthcare and wellness organizations.

Frequently asked questions

Does a simple clinic website have to worry about HIPAA?

It may. That depends on whether the practice is a covered entity and whether the site collects or passes on information tied to patients. Forms and trackers are the usual points of concern, so take a list of both to counsel.

Is WordPress suitable for a healthcare website?

As a public, informational site, yes. What matters is which data the site holds and which vendors receive it. Many organizations keep WordPress free of patient information and link to a separate portal for booking and messaging.

Can we use Google Analytics on a healthcare site?

Google says it does not sign business associate agreements for Google Analytics and tells customers subject to HIPAA not to use it on HIPAA-covered pages. Which of your pages are covered is a legal judgment. If the answer is unclear, self-hosted analytics without visitor profiles is the lower-risk choice.