Does a healthcare website's contact form need to be HIPAA compliant?

A contact form needs to be a HIPAA compliant contact form when two things are true: your practice is a HIPAA covered entity, and the form collects health information tied to an identifiable person. HHS explains that a health care provider is a covered entity only if it transmits health information electronically in connection with a transaction for which HHS has adopted a standard, such as billing insurance electronically. Most dental, chiropractic and physical therapy practices that bill insurance meet that test. Some cash-only practices, including some med spas, may not, though state privacy laws and the FTC can still apply.

If you are covered, the question is what the form collects. HHS guidance on online tracking technologies states that individually identifiable health information collected on a regulated entity's website generally is PHI, even if the person has no existing relationship with you and even without treatment or billing details. A form that asks for a name, phone number and "describe your symptoms" is collecting PHI.

Protected health information on a form is any health-related detail combined with something that identifies the person. Common examples on practice websites:

• A name or email address plus a reason for visit, symptom, condition or treatment requested.
• Appointment requests that name a specific service tied to a condition, such as a root canal or a post-surgical rehab evaluation.
• New-patient forms with medical history, medications or insurance details.
• Uploads such as photos for a cosmetic consultation, X-rays or referral letters.
• Information typed into a symptom checker or booking tool, which HHS guidance treats as PHI when it is captured along with identifying details.

A business associate agreement (BAA) is the contract that lets a vendor handle PHI on your behalf. HHS defines a business associate as a person or entity, other than your workforce, that performs functions for a covered entity involving access to PHI. That can include your form builder, website host if it stores submissions, email provider, CRM, scheduling tool and any automation platform that passes form data between them.

According to HHS's sample business associate agreement provisions, the contract must set the permitted uses and disclosures of PHI, require appropriate safeguards (including the HIPAA Security Rule for electronic PHI), require the vendor to report unauthorized uses and breaches, and require it to return or destroy PHI at the end of the relationship where feasible. It must also flow those terms down to subcontractors.

Encryption alone does not remove the need for a BAA. HHS guidance on cloud computing says a cloud service provider that stores ePHI is a business associate even if it stores only encrypted data and lacks the encryption key.

Tracking tools are where many practices get caught out. HHS's bulletin on online tracking technologies explains that tracking code on pages where patients book appointments or enter health details can disclose PHI to the tracking vendor, and that a cookie banner does not count as a HIPAA authorization.

There is an important update. On June 20, 2024, a federal court in the Northern District of Texas (American Hospital Association v. Becerra) vacated the part of that guidance dealing with tracking on unauthenticated public pages, such as a general page about a condition, when only an IP address was connected to the visit. HHS notes the decision at the top of the bulletin. The rest of the bulletin, including the treatment of booking pages, patient portals and forms that capture health details, still stands. The practical takeaway: keep advertising pixels and session recording tools off pages where people submit health information unless the vendor signs a BAA.

These defaults reduce risk without making it harder for patients to reach you. Review them with your compliance advisor.

• Ask less on public forms: name, phone, email, preferred time and a general category such as "new patient" or "existing patient". Add a note asking people not to include medical details.
• Use a secure intake system for clinical details: a patient portal or HIPAA-ready form tool with a signed BAA, sent after first contact.
• Map the data path: list every system a submission touches, from form to email notification to CRM, and confirm each has a BAA or receives no PHI.
• Turn off email copies of full submissions: send a notification that a new form arrived, and keep the details inside the secure system.
• Remove ad pixels and session recording from form, booking and portal pages unless covered by a BAA.
• Use HTTPS everywhere and restrict who on your team can view submissions.
• Write it down: document your form inventory, vendors, BAAs and review date as part of your HIPAA risk analysis.

A dental office keeps a short "request an appointment" form with contact details and a dropdown for general visit type, then sends new patients a secure intake link for medical history. A physical therapy clinic accepts referral uploads only through its HIPAA-ready intake tool, not the general contact form. A chiropractic clinic removes its ad pixel from the booking confirmation page and tracks conversions through a method that does not send health details to the ad platform.

Monvell's Development and Platform teams build practice websites and intake flows with this separation designed in, using vendors that sign BAAs for any system that handles patient information.