HIPAA Compliant Website Design: What the Regulations Actually Require

HIPAA doesn't mention websites. The regulations cover Protected Health Information regardless of medium. Your website becomes subject to HIPAA when it collects, transmits, or stores PHI - that's the line. A pure marketing site that describes your services and provides a phone number has different obligations than a site with intake forms, appointment scheduling, or a patient portal.

Protected Health Information (PHI) is any individually identifiable health information. Under HIPAA, there are 18 specific identifiers that can turn health data into PHI: names, geographic data smaller than state, dates related to individuals, phone numbers, fax numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate/license numbers, VINs, device identifiers, web URLs, IP addresses, biometric identifiers, full-face photos, and any other unique identifying number or code.

The key phrase is "individually identifiable." The 18 identifiers matter because combining any of them with health information creates PHI. A person browsing your "STD testing" page is not PHI. That person's IP address logged alongside that visit is. This is why analytics is the most common compliance failure on healthcare websites - most practices have no idea they're creating PHI by running Google Analytics on health-related pages.

Electronic Protected Health Information (ePHI) is PHI stored or transmitted electronically. Everything on your website is electronic, so the Security Rule's technical safeguards apply to any PHI your site touches.

Covered entities are the healthcare providers, health plans, and clearinghouses HIPAA directly regulates. Business associates are vendors who handle PHI on their behalf - your hosting provider, your form processor, your analytics platform, your CMS, your email service. Every business associate needs a signed Business Associate Agreement (BAA) before PHI can flow to them. Without a signed BAA, sharing PHI with a vendor violates HIPAA regardless of how secure their infrastructure is.

The HIPAA Security Rule requires administrative, physical, and technical safeguards for ePHI. For websites, the technical safeguards carry the most weight: Access controls mean role-based permissions and unique user identification. Every staff member who logs into your CMS or views patient form submissions needs their own credentials with appropriate access levels. No shared passwords.

Audit controls require tracking who accessed what data and when. Your hosting and CMS should maintain logs of all PHI interactions for a minimum of six years. These logs must be tamper-evident - users cannot modify or delete records of their own access.

Integrity controls ensure ePHI isn't altered or destroyed improperly. Backup systems, version control, and documented recovery procedures all apply here.

Transmission security requires encryption for data in transit. TLS 1.2 is the current minimum; TLS 1.3 is strongly preferred and will likely become mandatory when the proposed Security Rule updates finalize.

Authentication - multi-factor authentication for all systems accessing ePHI is already best practice and explicitly proposed in the 2025 Security Rule NPRM.

This is where most healthcare websites fail without realizing it. Google Analytics, Meta Pixel, and similar tracking tools collect IP addresses and browsing behavior. When a visitor browses your "depression treatment" page or clicks through from a targeted ad about "anxiety counseling," their browsing history combined with their IP address becomes PHI.

In December 2022, HHS/OCR issued guidance stating that tracking technologies collecting individual health information require HIPAA compliance. A wave of class action litigation followed. But in June 2024, a federal judge in the Northern District of Texas ruled that OCR's guidance had partially overstepped its regulatory authority - specifically around the "proscribed combination" theory that IP address plus health page visit automatically equals PHI. OCR withdrew its appeal in August 2024.

Here's what that ruling actually means for your website: the formal OCR guidance was partially vacated, but the underlying HIPAA Privacy and Security Rules were not. The class action litigation against health systems that used Meta Pixel and Google Analytics has not abated. The prudent position remains: don't run unauthenticated third-party tracking scripts on pages where patients exchange health information, because the private litigation risk hasn't diminished even if OCR's formal guidance did.

For authenticated patient portals - logged-in users - the rules are clear regardless of the court ruling. Any tracking on authenticated pages without a BAA is a direct violation.

A signed BAA is not optional decoration. It's the legal foundation that makes vendor relationships HIPAA-compliant. Without one, PHI flowing to that vendor is a violation.

The most important regulatory development since 2013 is also the most uncertain. HHS/OCR published a Notice of Proposed Rulemaking to significantly modify the HIPAA Security Rule on January 6, 2025. The proposal would make sweeping changes - but its path to becoming law is unclear.

What the NPRM proposes:

• Eliminating the distinction between "required" and "addressable" safeguards - everything becomes mandatory with limited exceptions. Under the current rule, encryption is "addressable," meaning organizations can document a rationale for not using it. Under the proposed rule, encryption of ePHI at rest and in transit becomes a mandatory requirement.
• TLS 1.3 or higher for all ePHI transmission
• Multi-factor authentication mandatory for all interactive workforce access to ePHI
• Biannual vulnerability scanning and annual penetration testing
• A written technology asset inventory documenting every system touching ePHI, updated at minimum annually
• A network map illustrating how ePHI moves through electronic information systems
• 72-hour system restoration capability after an incident
• Anti-malware protection on all systems touching ePHI

The political situation: The Trump administration has signaled skepticism. OCR Director Paula Stannard declined to confirm whether the rule will proceed as proposed, noting that "the Trump administration may have a different view on the burdens and benefits of some of the proposed changes." A coalition of more than 100 hospital systems and provider associations petitioned HHS to withdraw the rule, calling it counter to the deregulatory agenda. A final rule is still listed as anticipated on HHS's regulatory agenda, but its scope may be narrowed or it may not finalize at all in its current form.

What this means for your website today: Build to the proposed standard anyway. TLS 1.3, MFA, documented technology inventory, vulnerability scanning - these are security best practices regardless of whether the rule finalizes. The organizations that get penalized are the ones who treat compliance as a legal minimum rather than a security floor.

Already in effect: The requirement to update Notices of Privacy Practices took effect February 16, 2026. Healthcare websites must display current NPP content reflecting this.

HIPAA compliance and accessibility compliance are separate, parallel obligations. A site that passes every HIPAA requirement can still expose a healthcare provider to significant liability if patients with disabilities can't use it. Meeting one does not satisfy the other.

Development and operational costs are two separate categories. Most conversations about "how much does HIPAA compliance cost" conflate them.

Ongoing monthly operational costs:

Development costs (one-time):

Small practice website with HIPAA-compliant forms and compliance infrastructure: $5,000–$15,000. Growing practice with online scheduling and more complex requirements: $15,000–$30,000. Mid-size clinic with patient portal integration: $30,000–$60,000. These are ranges based on real project scope - not minimum viable packages that create compliance theater.

I build healthcare websites on SvelteKit rather than WordPress or template-based site builders. The technical characteristics of the framework align directly with compliance requirements: Smaller attack surface. No plugin ecosystem creating security vulnerabilities. A typical SvelteKit site ships around 42KB of JavaScript compared to 120KB+ for other frameworks. Fewer third-party dependencies means fewer BAA obligations and fewer vectors for data exposure.

Server-side security. Sensitive operations happen on the server, not in client-side JavaScript where they can be inspected or manipulated. Form processing, access validation, and any PHI handling stay off the client entirely.

Custom CMS integration. Content management built into the same codebase eliminates external CMS vendor dependencies. No headless CMS with its own terms of service, no separate admin domain to secure, no API calls to third-party infrastructure.

Performance that supports accessibility. Faster sites work better for elderly patients, patients with cognitive disabilities, and visitors on slower connections. Performance and accessibility aren't independent of compliance - they're part of it.

For projects requiring patient data handling, I architect solutions that minimize PHI touchpoints. Marketing content stays separate from patient data flows. Forms route to compliant processors - Jotform Healthcare or HIPAAtizer depending on the complexity - with signed BAAs in place. Analytics use Plausible on non-PHI pages, with Piwik PRO or Freshpaint for any pages where health information may be exchanged.

The Korawells wellness clinic project is a good example: the site runs on Railway, which doesn't offer a HIPAA BAA. It doesn't need to, because the site itself stores no PHI. Form submissions route directly to Jotform's compliant infrastructure. The architectural decision to keep PHI off the primary server entirely eliminates the hosting BAA requirement.