HIPAA compliant website design that keeps patient data out of the wrong places

What is HIPAA compliant website design?

HIPAA compliant website design is the practice of planning and building a healthcare website so that any protected health information it touches is handled the way the HIPAA Privacy, Security and Breach Notification Rules expect. It is less about how the site looks and more about where data flows.

A website is never “HIPAA compliant” on its own. Compliance is a property of your whole organisation: policies, risk analysis, training, vendor agreements and the systems you run. The site is one of those systems. What the build can do is remove easy mistakes, such as a contact form that emails symptoms in plain text, or an advertising pixel sitting on an appointment page, and put the right technical safeguards in place for the pieces that genuinely need PHI.

So when a practice asks us for HIPAA compliant website design, we start by separating the site into two zones. The public zone is marketing: services, providers, locations, blog posts, insurance lists. The PHI zone is anything where a patient types or uploads information about their health, identity or care. The public zone can use normal hosting and careful analytics. The PHI zone needs vendors under a business associate agreement, encryption, access control and logs. Keeping the zones apart is the single design decision that makes everything else manageable.

Does my practice website need to be HIPAA compliant?

If your practice is a HIPAA covered entity and the website collects, stores or transmits PHI, then yes, that part of the site falls under your HIPAA obligations. If the site only publishes information and never receives patient details, the HIPAA exposure is much smaller, though tracking tools can still create risk.

Covered entities are health plans, health care clearinghouses and health care providers that conduct certain standard transactions electronically, such as billing insurance. Most US clinics, dentists, therapists and chiropractors who bill insurers fit that description. Vendors that handle PHI on their behalf are business associates and have their own obligations.

The practical test is simple. Walk through your own site as a patient would and write down every point where you can type something: contact form, appointment request, new-patient paperwork, chat widget, review request, newsletter sign-up, payment page. For each, ask whether a person could reasonably enter health or identity details. A “Request an appointment” form that asks for date of birth and reason for visit clearly collects PHI. A newsletter box that asks only for an email address, on a page with no condition content, usually does not. That list becomes the scope of your HIPAA compliant website design project.

• Covered entity plus PHI on the site: HIPAA safeguards apply to that part
• Covered entity, information-only site: focus on tracking and forms that might invite PHI
• Not a covered entity (for example, a wellness app sold direct to consumers): look at FTC and state health-data rules instead

When does a website form collect PHI?

A form collects PHI when it links individually identifiable information, such as a name, email, phone number or IP address, with information about a person's health, care or payment for care, and it is received by or for a covered entity. A name plus “reason for visit” is PHI; a name alone on a general enquiry often is not.

The trouble is that patients do not read form labels carefully. A plain “Message” box on a dermatology site will eventually receive a description of a rash and a photo request. That is why HIPAA compliant website design treats open text boxes as PHI-capable by default. Either the form is built to handle PHI properly, or it is worded and structured so patients are steered away from sharing it (“Please don't include medical details here; we will call you back”).

We prefer the honest route: if a practice genuinely needs clinical information before a visit, build the secure form and route it correctly, rather than pretending patients will follow a disclaimer. If the practice only needs a call-back, strip the form to name, phone and preferred time, and keep it on a page without condition-specific context. Fewer fields means less PHI, less risk and a shorter form that more patients actually finish.

Which vendors need a BAA in a HIPAA compliant website design?

Any vendor that creates, receives, stores or transmits PHI for your practice needs a business associate agreement with you. For a website, that usually means the hosting or cloud provider for the PHI zone, the form or intake service, secure email, scheduling, chat and any analytics or tag tool that could see PHI.

Hosting surprises people. HHS guidance on cloud computing and HIPAA says a cloud service provider that stores electronic PHI is a business associate even if it only holds encrypted data and lacks the encryption key. The narrow “conduit” exception covers transmission-only services with transient access, not a server that keeps your forms.

Many vendors offer BAAs, but often only on specific plans or for specific services within their platform, so read the list of covered services rather than the marketing page. The agreement has to be between the vendor and your practice. We do not sign BAAs, and we do not need to: we design the site so that PHI flows only into your BAA-covered accounts, and we build and test with dummy records. If a feature would require us to see real patient data, we flag it and you decide how to handle it with your counsel.

• Cloud hosting or database for intake data
• HIPAA-eligible form or e-signature service
• Secure email or messaging used for patient replies
• Online scheduling and reminder tools
• Live chat or chatbot on pages patients use
• Customer data platforms or analytics that may receive PHI

What did the HHS tracking technology guidance say, and what did the 2024 court ruling change?

The HHS Office for Civil Rights bulletin on online tracking technologies explains that pixels, cookies and similar tools can disclose PHI to vendors. In June 2024 a federal court vacated one part of it, the part treating IP address plus a visit to an unauthenticated public page about a health condition as enough to trigger HIPAA.

According to the HHS bulletin on tracking technologies, tracking on user-authenticated pages such as patient portals and telehealth platforms generally has access to PHI, and the practice must make sure disclosures are permitted and put a BAA in place with the tracking vendor. The bulletin also says consent banners that ask users to accept cookies are not a valid HIPAA authorization, and that a vendor promising to strip or de-identify PHI after receiving it is not sufficient.

The court decision, American Hospital Association v. Becerra in the Northern District of Texas on June 20, 2024, declared unlawful and vacated the guidance to the extent it said HIPAA is triggered when an online technology connects an IP address with a visit to an unauthenticated public page about specific health conditions or providers. HHS notes it is evaluating next steps. The rest of the bulletin still stands: portals, login and registration pages, appointment tools and symptom checkers remain places where tracking can reach PHI.

For design, that means a condition page with no form is lower risk than it looked in 2023, but an appointment page, login page or intake flow still needs tracking kept out unless a BAA covers the vendor.

Can you use Google Analytics or a Meta Pixel on a HIPAA compliant website?

You can use analytics on public marketing pages with care, but keep ad pixels and general analytics off patient portals, login and registration pages, intake forms and appointment flows unless the vendor signs a BAA. Most mainstream ad and analytics tools do not offer one, so the safe default is to exclude them from the PHI zone.

In a HIPAA compliant website design we handle this at the template level rather than by memory. The PHI-zone layout simply does not load the tag manager, so a marketer adding a new pixel next year cannot accidentally put it on the intake page. On public pages, we configure analytics to avoid collecting form contents, strip query strings that could carry identifiers and avoid event names that describe conditions (“booked_oncology_consult” tells a vendor too much).

Measuring bookings is still possible. One approach is to count completions inside your own BAA-covered system and report totals, not individuals. Another, described in the HHS bulletin, is a customer data platform vendor that signs a BAA, de-identifies the data and passes only de-identified information on to tools that will not sign one. The trade-off is less granular ad attribution. Most practices find that acceptable once they see the risk on the other side.

• PHI zone: no tag manager, no pixels, no session recording, no third-party chat without a BAA
• Public zone: analytics configured without form capture or identifying parameters
• Conversion data: aggregate counts from your own system, or a BAA-covered data platform
• Every tag documented with its purpose and owner in the handover pack

How to build encrypted intake forms for a practice website

In HIPAA compliant website design, an encrypted intake form sends answers over TLS straight to a BAA-covered database or form service, stores them encrypted at rest, and notifies staff that a new submission exists without putting the answers in the email. Staff then read the submission after logging in.

That last point matters more than it sounds. The most common leak we find in practice websites is not hacking; it is a form plugin that emails the full submission, date of birth and symptoms included, to a shared inbox on an ordinary email plan. Changing the notification to “New intake received, sign in to view” removes the problem without changing the patient experience at all.

On a custom build, the form posts to an API running in your own cloud account under that provider's BAA. The database encrypts data at rest, backups are encrypted too, and files such as insurance card photos go to private storage with short-lived signed links. Each staff member signs in with their own account and multi-factor authentication, and every view or export is logged. On a vendor build, we embed the HIPAA-eligible form service, check that your plan includes the BAA, and make sure the form loads without your site's analytics on the same page.

Either way, we minimise fields first. If you do not use a question in the visit, do not ask it online.

Secure hosting for HIPAA compliant website design

For HIPAA compliant website design, host the public marketing site wherever it performs best, and host the PHI zone in a cloud or vendor account that signs a BAA and offers encryption, access control and logging. Splitting the two keeps the expensive, locked-down environment small.

The HIPAA Security Rule's technical safeguards in 45 CFR 164.312 name the controls to plan for: access control with unique user identification, an emergency access procedure, automatic logoff, encryption and decryption, audit controls, integrity protections, person or entity authentication, and transmission security. Some are labelled required and some addressable, which means you assess whether they are reasonable and appropriate and document the decision. That assessment is your practice's job; our job is to make each control available and switched on by default.

In practice, a typical PHI zone we build runs in the practice's own cloud account: a small API, an encrypted managed database, private file storage, a web application firewall, and centralised logs retained for the period your policies set. The public site can be a static build on a content delivery network, which is fast, cheap and has no database to breach. Both live in accounts your practice owns, so the credentials, the BAA and the billing relationship all sit with you, not with us.

Access control and audit logs in a HIPAA compliant website design

Every HIPAA compliant website design with a back office should give each staff member a named account, require multi-factor authentication, grant only the access each role needs, and log who viewed, changed or exported PHI. Shared logins make audit trails useless.

The workflow side is where HIPAA compliant website design meets daily clinic life. Front-desk staff might see new intake submissions but not billing notes; a clinician sees full questionnaires for their own patients; the practice manager can export. We model those roles in plain language with you before building them, because a permission scheme that is too strict gets bypassed with shared passwords, and one that is too loose defeats the purpose.

Audit logs should answer three questions quickly: who opened this record, when, and from where. We write logs to storage that ordinary staff accounts cannot edit, set automatic logoff after a period of inactivity you choose, and include a simple screen for the practice manager to review recent access. For offboarding, the admin panel has a one-click “disable user” action, so an employee who leaves on Friday cannot sign in on Saturday. Documentation of these settings goes into your compliance file.

How much does a HIPAA compliant website cost?

With us, a practice website starts at US$150, a content-heavy site with many condition and location pages starts at US$300, and custom encrypted intake or a portal front end starts at US$900. Your BAA-tier vendor subscriptions are separate and paid directly to those vendors.

The cost of HIPAA compliant website design depends less on page count and more on how much PHI the site handles. Four drivers move the quote most. First, whether you use an off-the-shelf HIPAA-eligible form service or need custom intake logic. Second, how many staff roles and permissions the back office needs. Third, integrations, for example sending intake data to your EHR through its API. Fourth, how much existing tracking and plugin clutter needs to be audited and removed from your current site.

Across the market, quotes vary widely, partly because some providers price in the ongoing platform subscription and others price only the build. When comparing, ask each one to list which vendors will hold PHI, who signs the BAA with each, and what you pay monthly after launch. A lower build price with PHI flowing through an uncovered plugin is not cheaper in any sense that matters. For general practice site budgets, our page on what a small business website costs covers the non-health baseline.

How to choose a developer for HIPAA compliant website design

Choose a developer who can explain, in writing, where every piece of PHI goes on your future site, which vendor holds it and who signs the BAA. If the answer is vague or “our hosting is HIPAA compliant”, keep looking.

Good questions to ask: Will you need access to real patient data during the build? (The answer should usually be no.) Which tags will load on the intake page? How are form notifications worded? Where are backups stored and are they encrypted? What happens to logs, and for how long? Who owns the cloud account? Can you give me a data-flow diagram my counsel can review?

Red flags are just as telling. Be wary of anyone who calls their work “HIPAA certified” without explaining what that means and who issued it, promises that a consent banner solves tracking, installs a chat widget without asking about BAAs, or keeps the hosting account in their own name. Also be wary of the opposite extreme: a developer who refuses to build any form at all and tells you to use phone calls only, when a properly scoped secure form would serve patients better. A sensible partner explains the trade-offs and leaves the legal judgement to your counsel.

Beyond HIPAA: FTC, state health-data laws and accessibility

HIPAA is not the only rule that shapes HIPAA compliant website design for a US health business. Non-covered health apps and services may fall under the FTC Health Breach Notification Rule, some states have their own consumer health-data laws, and the ADA applies to the websites of businesses open to the public.

The FTC says its Health Breach Notification Rule covers vendors of personal health records and related entities not covered by HIPAA, and that July 2024 amendments make clear that makers of health apps and connected devices must comply. The Washington Attorney General describes the state's My Health My Data Act as protecting consumer health data outside HIPAA's scope, with main provisions effective March 31, 2024 for most businesses and June 30, 2024 for small businesses, and a requirement to link a consumer health data privacy policy from the homepage.

Accessibility is the other half of a patient-friendly site. The Department of Justice's March 2022 guidance says the ADA's requirements apply to goods and services that public accommodations offer on the web. We build forms with proper labels, keyboard support and readable error messages, which also cuts form abandonment. Our accessibility-focused website page and California privacy page go deeper. None of this is legal advice; your counsel decides which rules apply to you.

HIPAA compliant website design with a team in India: how it works from the US

From the US, you work with us through video calls in your Eastern morning, which is our evening, plus WhatsApp or Slack in between. Quotes and invoices are in USD, paid by wire, Wise or PayPal. The key difference on health projects is that we are set up to never need your patients' data.

India is nine and a half hours ahead of US Eastern time during daylight saving and ten and a half in winter, so an 8:30 a.m. call in Chicago or New York is early evening for us; Pacific clients usually take early calls. Your practice creates the cloud account, form service and domain registrar login, signs the BAAs with those vendors, and invites us with limited roles. We deploy into your environment using test data only; production PHI appears only after launch, inside your accounts, visible to your staff.

The first two weeks look like this. Days one and two: you send your current site, forms and workflow notes; we return questions and, about two working days later, an itemised quote. Week one after approval: we produce the PHI flow map and tag inventory, you review it with your compliance lead, and we agree which forms stay, go or change. Week two: wireframes of the public pages and the intake flow, the cloud environment skeleton, and the first staging link you can click through. Contract terms, confidentiality and ownership are set out in the written quote; defaults are on our terms page. We don't visit clinics, and invoices come from India.

Does HIPAA compliant website design hurt SEO or AI-search visibility?

A HIPAA compliant website design can still rank well. Search visibility comes from public content, page speed and local signals, none of which require PHI. The only change is how you measure results.

Condition, treatment, provider and location pages are public and should be written for patients: what the treatment is, who it suits, what to expect, insurance accepted, how to book. We add structured data for the practice and its locations, keep pages fast (Google's web.dev guidance treats an LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less at the 75th percentile as good), and link each service to its booking route. Google Search Console reports queries and clicks in aggregate and does not need tags on patient pages, which makes it a natural fit.

AI assistants such as Google's AI Overviews and chat-based search tend to quote short, self-contained answers from clear pages. Provider bios with real credentials, plain-English FAQ blocks and consistent practice details across your site and Google Business Profile help. For ongoing work, see our local SEO service, and ask us how to keep review requests free of health details.

Worked example: a hypothetical two-location physical therapy practice in Denver

Say a physical therapy practice with clinics in Denver and Aurora wants online new-patient intake and better search visibility. This is an illustrative scenario, not a past client.

Their current site runs a page builder with a contact form that emails every submission, injury details included, to a shared inbox, and an ad pixel loaded on every page, including the appointment request. The PHI flow map shows three problem points: the form email, the pixel on the booking page, and a chat widget whose vendor has no BAA.

The plan splits the site. The public side is rebuilt as a static site with provider bios, condition pages for back pain, sports injuries and post-surgical rehab, and a page per clinic. That part is quoted from our US$300 line because of the number of pages. The intake side becomes a custom form in the practice's own cloud account under the provider's BAA, with file upload for referral letters, staff roles for front desk and therapists, and audit logs; that portion starts from US$900. The chat widget is removed, the pixel is limited to public pages, and bookings are counted as monthly totals from the intake system.

The practice's compliance consultant reviews the flow map before build, which is how HIPAA compliant website design should always run: counsel reviews the plan, not just the finished site. After launch, staff read intakes after signing in, and no health details travel by email.

HIPAA compliant website design launch checklist

Before go-live, confirm that every PHI path ends in a BAA-covered service, that no tracking loads in the PHI zone, and that your staff can sign in, view and export only what their role allows. Then have your counsel or compliance officer review the documentation.

• PHI flow map approved, listing every field and destination
• Signed BAAs on file for hosting, forms, email, scheduling and chat vendors
• Tag inventory: no pixels, session replay or tag manager on PHI pages
• TLS everywhere; data and backups encrypted at rest
• Form notifications contain no PHI
• Named staff accounts with MFA; automatic logoff configured
• Audit logs enabled, protected from edits and reviewed on a schedule
• Accessible labels, keyboard navigation and clear error messages on forms
• Privacy policy and notice of privacy practices linked where patients expect them
• Incident contact and steps written down for your team

HHS breach rules under 45 CFR 164.408 set different reporting routes for breaches involving 500 or more individuals and those involving fewer, which is one more reason to keep PHI paths short and logged. Ready to check your current site against this list? Send it via our contact page.