HIPAA Compliant Website Design

Healthcare websites often handle more information than visitors can see. A simple appointment form, patient message, or login can involve sensitive health information that needs careful handling.

For organizations covered by HIPAA, website design must go beyond appearance and usability. The way a website collects, stores, transfers, and protects information can affect its compliance responsibilities.

Businesses can work with professional website development companies to build secure systems and review how website features handle sensitive data. HIPAA compliance also depends on the organization, the type of information involved, and how that information moves through the website.

There is no universal “HIPAA website certificate” that makes a website compliant. Understanding these factors is the first step toward building a website that supports privacy, security, and appropriate data handling.

In this article, we will explain how to determine whether HIPAA applies to a website and what organizations should consider when designing, developing, testing, and maintaining one.

Read along to understand how HIPAA requirements can influence website architecture, UX, third-party tools, accessibility, and day-to-day website management.

There is no universal “HIPAA website certificate” that makes a website compliant. HIPAA applicability depends on the organization, its role under HIPAA, and how health information is collected, used, stored, or transmitted.

HHS does not recognize private HIPAA certifications as substitutes for an organization’s legal obligations. A website may also handle electronic protected health information (ePHI) through forms, patient portals, integrations, or other digital systems, making appropriate administrative, physical, and technical safeguards important.

This article focuses on HIPAA requirements and website practices in the United States and has been reviewed for accuracy as of October 2026. It is intended for educational purposes only and does not constitute legal advice.

Organizations should assess their specific circumstances and consult qualified legal or compliance professionals when determining their HIPAA obligations.

HIPAA does not automatically apply to every healthcare website. It applies to covered entities, such as certain healthcare providers, health plans, and healthcare clearinghouses, and their business associates when applicable.

These business associates provide services that may involve handling protected health information (PHI). A website may involve PHI through appointment forms, patient messages, medical intake forms, or patient portals.

Whether HIPAA applies depends on the organization, the information collected, and how that information is used, stored, or shared. Healthcare organizations should review each website feature separately to identify applicable requirements.

Public pages vs. forms vs. patient portals

Website features present different privacy and security risks:

• Public pages: Service descriptions, provider profiles, and educational content may collect little health information. However, analytics, advertising pixels, chat tools, and session recording can introduce privacy risks if they collect sensitive data.
• Forms: Appointment requests, referrals, and patient messages may collect PHI. Forms should request only necessary information, and organizations should review the systems and vendors that process submissions.
• Patient portals: Medical records, test results, billing details, and secure messages require appropriate identity verification, authentication, access controls, session management, and account recovery.

For effective HIPAA website compliance, organizations should map what each feature collects, where the information goes, who can access it, and how it is used or disclosed. This helps identify risks and determine which safeguards are needed.

What counts as PHI and ePHI online

Protected health information (PHI) is individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate, subject to HIPAA's rules.

It can include information about a person's health condition, healthcare services, or payment for care when it is linked to identifying information such as a name, address, or other identifier.

Electronic protected health information (ePHI) refers to PHI that is created, received, maintained, or transmitted in electronic form. This can include information stored in a patient portal, submitted through a website form, sent through an electronic system, or maintained in databases and other digital systems.

PHI is not limited to obvious medical records. It can enter or move through a website in several ways, including:

• Form fields: Names, contact details, appointment information, symptoms, medical history, or other information submitted by a patient.
• URLs and query parameters: Search terms, appointment details, identifiers, or other information included in page addresses can expose sensitive information.
• User accounts: Login details and information associated with a patient account may connect website activity to an identifiable individual.
• Event logs: Website and application logs can record actions, timestamps, account identifiers, or other information that may become sensitive when linked to a patient.
• Cookies and tracking data: Cookies and other technologies can record browsing activity or interactions. Whether this information constitutes PHI depends on the context and the information involved.
• Third-party services: Analytics, chat, advertising, forms, or other embedded tools may receive information from the website. The organization should understand exactly what data is sent, where it goes, and who can access it.

Before making changes to build a HIPAA-compliant website, organizations should understand how data moves through the entire website ecosystem. Start at the browser and trace each step through forms, the CMS, analytics tools, patient systems, email services, application logs, integrations, and backups.

This helps identify where sensitive information enters the system and where it may be stored, processed, or shared. A data-flow inventory should document each system and transfer in a consistent way. For every data flow, record:

• Owner: Who operates or controls the system?
• Purpose: Why is the data collected or transferred?
• Access: Who can view, modify, or administer the data?
• Retention: How long is the information stored?
• Destination: Where does the data go, including connected vendors and systems?
• Contractual basis: Is a business associate agreement (BAA) or another contractual arrangement required?

Once the data flows are documented, the inventory can support the organization's broader risk analysis. It can show where unnecessary data is collected, where access is too broad, and where information may be exposed through third-party services or poorly configured systems.

The same inventory can also guide vendor reviews. Organizations can identify which providers receive or access sensitive information and then review their security practices, contracts, access controls, retention policies, and incident procedures. Keeping this map updated is important because new website features, integrations, or vendors can change how data moves through the system.

The HIPAA Privacy Rule governs how covered entities use and disclose protected health information (PHI). Key considerations for website UX include:

• Minimum necessary: Collect and display only the PHI needed for a specific purpose, subject to applicable exceptions.
• Privacy notices: Provide required notices explaining how health information is handled.
• Individual rights: Support applicable rights, including access to health information.
• Secure UX: Use appropriate access controls and design forms, notifications, and error messages to avoid unnecessary exposure of PHI.

These practices can support HIPAA website compliance by reducing unnecessary data collection and accidental exposure. Clear labels, focused forms, and carefully designed messages can also make privacy easier to maintain without making the website harder to use.

Privacy notices are not enough

A privacy notice does not make a website compliant on its own. Website security also depends on how information is collected, stored, accessed, transmitted, and disclosed. Privacy notices should therefore be supported by technical safeguards, access controls, vendor management, internal procedures, and secure data-handling practices.

HIPAA security rule for web design and development

The HIPAA Security Rule requires covered entities and business associates to protect electronic protected health information (ePHI) through appropriate administrative, physical, and technical safeguards.

The Rule is flexible and technology-neutral, so controls should be based on documented risks and the organization's systems and resources. For a HIPAA-compliant website, this can affect hosting, access management, development, integrations, backups, and administration.

Organizations should begin with a risk analysis and select controls that address identified risks. HHS establishes the legal requirements, while NIST SP 800-66 Rev. 2 provides practical guidance. NIST guidance is not a HIPAA regulation or certification.

Identity, access, and session security

Website systems should limit ePHI access to authorized users through appropriate identity verification, role-based access, authentication controls, and risk-based MFA. Account recovery should also verify user identity without creating new security risks.

For patient portals and administrative systems, appropriate session timeouts, logout controls, re-authentication, and protection against shared-device access can help prevent unauthorized access. These controls should reflect documented risks while keeping the user experience practical and clear.

Encryption, logging, and data integrity

Encryption can help protect ePHI during transmission and storage, while proper key management helps maintain its security. Logging and audit controls can support the detection and investigation of security events, while integrity controls help identify or prevent unauthorized changes.

Logs should capture useful security events, such as authentication attempts, permission changes, and administrative actions, without unnecessarily recording sensitive information. Logs should also have appropriate access and retention controls.

Together, these measures support broader HIPAA website compliance. A secure website depends on its architecture, development practices, access controls, administration, and ongoing risk management rather than a single security feature.

Design forms to minimize PHI exposure

Forms are a common way for healthcare websites to collect patient information. Good Healthcare website design should collect only what is needed for the specific task. An appointment request, for example, may need basic contact and scheduling details but not a full medical history.

Forms should use secure submission, input validation, and appropriate controls for attachments. Confirmation and error messages should also avoid displaying sensitive information. Each field should have a clear purpose and a secure destination. Below is an example of the ‘Before’ and ‘After’ of an appointment intake form:

The goal is not to remove information the organization legitimately needs. Instead, unnecessary PHI should be avoided or collected through a more appropriate secure system.

Organizations should also review what happens after submission. Sensitive information should not appear in URLs, analytics events, application logs, or browser messages. Third-party tracking and integrations should be checked to ensure they do not receive unnecessary form data.

This approach reduces PHI exposure while keeping forms simple and usable. As part of HIPAA website compliance, form design should be reviewed alongside the systems that receive, store, process, and monitor submitted information.

Evaluate Hosting, CMS, and Website Vendors

Hosting providers, CMS platforms, and other vendors can affect how PHI is stored, accessed, and protected. As part of healthcare website design, organizations should review the vendor's actual data practices rather than rely on advertised security features.

Before transmitting PHI, organizations should confirm contractual responsibilities and ensure the appropriate agreements are in place. Vendor claims such as “HIPAA compliant” should be treated as marketing until contracts, configurations, data flows, and security practices have been independently reviewed. A vendor may offer HIPAA-related features but still create risks if those features are not properly configured or used.

Third-party tracking, analytics, and embedded tools

Third-party tools can expose sensitive data if they collect or share information unnecessarily. Healthcare organizations should audit tools such as:

• Analytics, pixels, and tag managers
• Chat tools, maps, and video players
• Session recording and behavioral-tracking tools

For each tool, check what data it collects, where the data goes, how it is stored, and who can access it. Determine whether it receives electronic protected health information (ePHI) and assess the vendor's role using current Office for Civil Rights (OCR) guidance. Review actual configurations rather than relying on vendor claims.

HIPAA may not be the only applicable requirement. Federal Trade Commission (FTC) rules and state privacy laws may also apply when a website or activity falls outside HIPAA. Regular audits can help identify unnecessary tracking and remove tools that create avoidable privacy risks.

Secure patient portal UX

Patient portals provide access to sensitive protected health information, so security should be considered throughout the user experience. The features that should be designed to limit unauthorized access while remaining easy for patients to use include:

• Secure login
• Proxy access
• Consent
• Document viewing
• Messaging
• Logout
• Account-recovery flows

Notifications should also provide useful updates without revealing sensitive details. For example, an email or push notification can tell users that they have a new portal message without displaying a diagnosis, test result, or other health information.

Clear logout options and appropriate session controls can further reduce the risk of exposure, especially on shared devices. Strong Website security should not make account recovery unnecessarily difficult.

Patients should have clear and secure ways to verify their identity and regain access when needed. By balancing security controls with practical recovery paths and simple navigation, organizations can protect sensitive information without creating unnecessary barriers for patients.

HIPAA, accessibility, and usability address different website requirements. Good healthcare website design should protect patient information while keeping the website accessible and easy to use.

Use WCAG 2.2 as a reference for accessibility checks, including keyboard navigation, clear form labels, helpful error messages, and accessible timeouts. Security features such as session timeouts and re-authentication should also be easy to understand and use.

Accessibility obligations vary by organization, services, and location. Determine which laws and standards apply independently of HIPAA, ensuring that privacy, security, and accessibility requirements are addressed separately.

A data-flow review helps clinics identify where protected health information (PHI) enters their website and how it moves between systems. For a site with public pages, appointment booking, chat, and a patient portal, each function should be reviewed for data collection, vendor access, and security risks.

These actions are examples and not fixed recommendations. The appropriate response depends on the actual data flows, vendor roles, security controls, and business needs. Clinics may also remove unnecessary tools, such as session-recording software that creates avoidable privacy risks.

Reviewing each function helps organizations decide whether to remove tools, replace vendors, reconfigure settings, establish required contracts, restrict access, or migrate data to more appropriate systems. This process supports better risk management and stronger protection of patient information.

Before launching a healthcare website, test its security, privacy, accessibility, and failure states. Key checks should include:

• Access and forms: Test permissions, authentication, form submissions, and error handling.
• Systems and data: Review configurations, logs, backups, recovery processes, and external requests.
• Browser activity: Check what data leaves the browser through URLs, APIs, analytics, and third-party services.
• Failure states: Test incorrect logins, expired sessions, failed submissions, and unavailable services.
• Accessibility: Verify that key functions remain usable and accessible.

The OWASP Application Security Verification Standard (ASVS) can provide a structured framework for application security testing. Use the current version relevant to the testing period and select controls based on the website's risks.

ASVS is a technical verification framework, not a HIPAA certification or legal compliance standard. Document identified issues, corrective actions, and retesting results. This provides a clear record of pre-launch testing and a useful baseline for future website changes.

HIPAA website compliance is an ongoing process rather than a one-time website review. Organizations should conduct regular risk assessments and vendor reviews, review user access, maintain change-control processes, provide relevant training, and track remediation of identified issues. These activities help keep security and privacy controls aligned with current risks.

Readiness also requires documented incident-response and notification procedures. Organizations should define how incidents are identified, investigated, contained, documented, and escalated.

Notification procedures should reflect the HIPAA requirements and any other laws or contractual obligations that apply to the organization. Controls should also be reassessed whenever the website changes.

New features, vendors, integrations, or data flows can introduce new risks or change existing ones. Reviewing these changes as part of ongoing HIPAA website compliance helps organizations identify gaps early and maintain appropriate safeguards over time.

Not every healthcare-related website is subject to HIPAA. For example, a marketing website operated by a non-regulated organization may fall outside HIPAA if it does not handle PHI or meet other conditions that trigger HIPAA obligations.

However, this should be assessed based on the organization's role, data flows, and business relationships. Even if HIPAA does not apply, other requirements may still govern how the website collects and protects visitor information, including:

• State privacy laws that regulate personal data.
• Federal Trade Commission (FTC) rules covering certain privacy and security practices.
• Contractual obligations related to data handling and protection.
• General privacy requirements that apply to the website's activities.

Organizations should review these obligations before deciding whether HIPAA applies and what privacy and security measures are needed.

Building a website that supports HIPAA requirements starts with understanding whether HIPAA applies to the organization and its website activities. Key steps include:

• Determine applicability: Identify the organization's HIPAA obligations.
• Map data flows: Track where PHI is collected, stored, and shared.
• Minimize data collection: Remove unnecessary information from forms and other features.
• Review vendors: Assess vendor access, security practices, and required contracts.
• Implement safeguards: Apply appropriate security and access controls.
• Monitor changes: Reassess risks as website features, vendors, and integrations change.

HIPAA compliance depends on documented facts, website configurations, vendor contracts, data-handling practices, and ongoing governance. A single feature, certificate, or checklist cannot establish compliance.

Organizations should avoid declaring a website “HIPAA compliant” without a thorough assessment of the website, connected systems, contracts, and processes.