All posts
Industries

HIPAA Compliant Website Design: What Actually Needs to Be Compliant

HIPAA compliant website design explained: why most marketing pages hold no PHI, and how forms, booking, email and tracking pixels create the real exposure.

By Mehdi Hassan8 min read

The short answer

HIPAA compliant website design means any part of the site that collects, stores or sends protected health information runs on vendors that sign a business associate agreement, with encryption, access controls and no leaks to third-party scripts. Most marketing pages hold no PHI. The exposure sits in intake forms, booking, patient portals, notification emails and tracking pixels on sensitive pages.

Key takeaways

  • There's no official HIPAA certification for websites. Compliance is about how PHI is handled, by whom.
  • Marketing pages with no forms usually hold no PHI. Forms, booking and portals usually do.
  • Every vendor that touches PHI, including form, hosting and email tools, needs a signed BAA.
  • Tracking pixels on booking or symptom pages can disclose health information to ad platforms.
  • Map your data first, then design: the riskiest decisions happen before anyone opens Figma.

Part of Healthtech Website Design: Clinical Credibility Meets Startup Speed

What makes a website HIPAA compliant?

A website is HIPAA compliant when every part of it that handles protected health information does so through systems and vendors covered by business associate agreements, with appropriate safeguards, and when nothing on the site discloses PHI to third parties without permission. There is no official HIPAA certification or badge for websites. Compliance describes how data is handled, not how the site looks.

This guide is part of our healthtech website design hub. Its job is to draw a clear line: which parts of a healthcare or digital health website create HIPAA exposure, and which don't. Most guides blur that line, and the result is either panic about pages that hold no data, or carelessness about forms and pixels that do. This is a design brief, not legal advice; confirm your obligations with counsel.

Does HIPAA apply to my website?

HIPAA applies to your website if your organization is a covered entity, such as a healthcare provider that bills insurance electronically, a health plan or a clearinghouse, or a business associate that handles PHI on behalf of one. Many wellness apps and consumer health products aren't covered by HIPAA at all, though other rules may still apply to the health data they collect.

Who you are

Does HIPAA apply?

Notes

Clinic, hospital or practice billing insurance

Yes, as a covered entity

Forms, booking and portals that collect PHI are in scope

Health plan or insurer

Yes, as a covered entity

Member portals and enrollment flows are in scope

Digital health vendor serving providers or plans

Usually, as a business associate

Depends on contracts and what data you handle

Direct-to-consumer wellness app, no insurer or provider link

Often not

The FTC's Health Breach Notification Rule and state laws may apply

Fitness or spa business

Usually not

Unless you bill insurance or act for a covered entity

If you aren't covered by HIPAA, don't relax completely. The FTC enforces its Health Breach Notification Rule against health apps that share data without authorization, and several US states have their own consumer health data laws. Designing as if HIPAA applied is often the safer default for anyone collecting health information.

Which parts of a HIPAA compliant website actually need to be compliant?

The parts of a website that need HIPAA safeguards are the ones that collect, store, transmit or expose PHI: patient intake and symptom forms, appointment booking, eligibility checks, patient portals, notification emails and any scripts that can see those pages. Static marketing pages, blog posts and buyer-facing demo forms that don't ask for health details usually aren't in scope.

Site area

PHI risk

Why

Home, about, service and blog pages

Usually none

No data collected; general information only

B2B demo or partnership form

Low

Business contact details, as long as you don't ask about health

General contact form with a free-text message

Medium

Patients often type symptoms into open fields

Appointment booking

High

A booking with a provider can itself reveal a health relationship

Intake, eligibility and symptom forms

High

Directly collects health information

Patient portal

High

Stores and displays PHI

Analytics and ad pixels

Depends on placement

Can transmit page URLs, form events and identifiers to third parties

What are the HIPAA website requirements for forms, hosting and email?

The HIPAA website requirements for forms, hosting and email come down to three things: a signed business associate agreement with each vendor that touches PHI, technical safeguards such as encryption in transit and at rest with access controls, and no PHI in places that lack those safeguards, such as plain notification emails.

  • Forms. Native form features in most website builders aren't covered by a BAA, so route PHI to a form provider that signs one. Our guide to HIPAA compliant forms on Webflow, Framer and Next.js walks through the setup for each platform.
  • Hosting and backend. If your own server or database stores PHI, your hosting provider needs to sign a BAA for that service. Major cloud providers offer BAAs for eligible services.
  • Email notifications. A form tool that emails the full submission to a staff inbox can undo everything. Send a notification without PHI and have staff log in to view the submission.
  • Access. Limit who can see submissions, use unique accounts and keep audit logs where the vendor provides them.

The rules themselves are set by the HHS Security and Privacy Rules; the HHS HIPAA pages are the primary source.

How do tracking pixels create HIPAA exposure on a website?

Tracking pixels create HIPAA exposure when they run on pages where patients book, check eligibility or describe health conditions, because they can send page addresses, button clicks, form events and device identifiers to ad or analytics companies. For a covered entity, that disclosure can count as sharing PHI with a third party that hasn't signed a BAA.

The HHS Office for Civil Rights published guidance on online tracking technologies, and a federal court later vacated part of it, specifically around some public, unauthenticated pages. The risk on authenticated pages, booking flows and forms remains. Our guide to healthcare website tracking covers which tools and configurations are lower risk.

How does HIPAA compliant website design work in practice?

You design a HIPAA-aware website by mapping where health data enters and moves before you design any pages, then building the regulated parts on BAA-covered tools and keeping marketing scripts away from them. The decisions that matter most are architectural, which is why they belong at the start of the project, not at launch.

  1. Map the data

    List every place the site collects information and what fields it asks for. Mark which ones could contain PHI, including free-text fields.

  2. Separate the regulated zone

    Put booking, intake and portals on dedicated pages or a subdomain with their own, stricter script rules.

  3. Choose BAA-covered vendors

    Confirm in writing that each vendor handling PHI will sign a BAA on the plan you're buying, before design starts.

  4. Set a script policy

    Decide which analytics and ad scripts may run on which pages, and enforce it in the code, not just in a tag manager setting.

  5. Ask for less

    Remove every form field you don't need. Data you never collect can't leak.

  6. Write the privacy notice to match reality

    Describe what the site actually collects and shares, and keep it updated when tools change.

Hypothetical example: a telehealth startup's site, mapped

For example, suppose a telehealth startup's marketing site has a home page, service pages, a blog, an eligibility checker, a booking flow and a contact form, with an ad pixel and analytics site-wide.

The data map shows three PHI risks: the eligibility checker asks about conditions, booking reveals a provider relationship, and the contact form collects symptoms in free text. The redesign keeps the marketing pages on the visual builder with analytics, moves eligibility and booking to a subdomain using BAA-covered tools with no ad pixels, changes the contact form to business inquiries only with a link to the secure patient path, and switches staff notifications to alerts without submission content. This is illustrative and not legal advice.

Is my website HIPAA compliant? A quick check

Your website is likely in good shape if you can answer yes to every question below. Any no is worth fixing, starting with the forms and pixels, where most real exposure sits.

  • Does every vendor that receives PHI from the site have a signed BAA?
  • Are intake, booking and eligibility forms routed through those vendors rather than native builder forms?
  • Are ad pixels and session recordings kept off pages where patients book or share health details?
  • Do notification emails omit health information?
  • Does the privacy policy describe what the site actually collects and shares?
  • Is someone responsible for reviewing new scripts and tools before they're added?

Planning a new site? Our guide to the pages a digital health website needs helps scope it, and our healthcare website cost guide covers budgets. Virtual care products should also read our guide to telehealth website design. If you're vetting partners, our guide to choosing a healthcare website design agency lists the questions to ask.

Frequently asked questions

Can I put a HIPAA compliant badge on my website?
There's no official HIPAA certification for websites, so a badge implying government or official approval is misleading. Some vendors offer third-party assessments, and you can describe your practices accurately on a security or privacy page. Avoid blanket claims like fully HIPAA certified. Describe what you do: BAA-covered vendors, encryption and access controls, and keep it accurate.
Is SSL enough to make a website HIPAA compliant?
No. SSL, or more precisely TLS, encrypts data in transit between the visitor and the server, which is necessary but not sufficient. HIPAA also covers where the data is stored, who can access it, whether vendors sign BAAs, audit logs and how notifications are sent. A site with SSL that emails form submissions to a regular inbox can still expose PHI.
Do I need a BAA with my website host?
You need a BAA with your host only if PHI is stored on or passes through its servers. If every form and booking tool that handles PHI is a separate BAA-covered service embedded on the site, and the host only serves marketing pages, the host may not need one. Confirm the data flow with your developer and counsel.
Are Google Analytics and Meta Pixel allowed on healthcare websites?
They can be used on marketing pages with care, but standard configurations shouldn't run on pages where patients book, check eligibility, use a portal or share health details. These tools typically don't sign BAAs for their standard products. Some healthcare teams use privacy-focused analytics or server-side setups that strip identifiers. Review your setup with counsel.
Does a HIPAA compliant website cost more?
Usually somewhat more, because of BAA-covered tool subscriptions, extra design and development work on forms and booking, a script policy and testing. The marketing pages themselves cost about the same. The bigger cost is often fixing a site after launch, when pixels and native forms have already collected data they shouldn't, so plan for it from the start.

· CEO & Design Director

Copywriter, designer and developer, and founder of Designify Studio. Over five years, 60+ projects across 14+ industries, for startups that have raised $300M+.

Want this done for you? Website, $8,000.

A multi-page marketing site, designed by us, developed in Next.js and animated. $8,000, one-time, up to 6 pages. Book a free 30-minute call to see if it fits.

Schedule Call