Book a practice review

Insights / Practice websites, privacy and tracking

Website contact and appointment forms under HIPAA: what a practice needs to know

When a form message becomes protected health information, where it travels, what HHS expects of vendors and BAAs, and the simpler option of not collecting it.

Creahive Health team

Every practice website has at least one form: a contact form, an appointment request, a new patient intake page. Patients do not read the small print. Some will type their symptoms, their medication, or the reason they want to be seen into whatever box is in front of them.

Search for “HIPAA compliant contact form” and you will find a long list of products that use the phrase. A label on a product does not settle the question for your practice. Under HIPAA, the obligations sit with covered entities and their business associates, and they depend on what the form collects, where the message goes, who can see it and what agreements are in place. This guide walks through what the HHS guidance says, using HHS’s own documents, which are linked at the end. For what to do when a request is started or sent but never booked, see following up on abandoned appointment requests. If the form is a booking widget run by a scheduling company, see our guide to online booking widgets. Our guide to Google Analytics on medical practice websites covers analytics tags on form and thank-you pages. For forms that open inside an ad instead of on your site, see our guide to lead form ads in healthcare.

This is general information for practice owners, not legal advice. Whether a form on your site handles protected health information, and what your practice must do about it, depends on the facts. Talk to your privacy officer or a healthcare attorney before you decide.

When a form message is protected health information

HHS’s summary of the Privacy Rule defines individually identifiable health information as information, including demographic data, that relates to a person’s past, present or future physical or mental health or condition, the care they receive, or payment for that care, and that identifies the person or could reasonably be used to identify them. It notes that this includes common identifiers such as name, address and birth date. When a covered entity or its business associate holds that information, it is protected health information (PHI).

A name and email address on their own, sent to a dental office, already say something about the sender. Add a line such as “I have had tooth pain for a week” or “I would like to book a follow-up for my knee” and the message clearly relates to that person’s health. HHS gives a close example in its bulletin on online tracking: a public appointment page where someone enters their email address and the reason they are seeking care. HHS says that information meets the definition of individually identifiable health information.

HIPAA applies to your practice only if you are a covered entity. For a health care provider, that generally means one that transmits health information electronically in connection with standard transactions such as insurance claims. If you are not sure whether that describes you, the CMS “Are you a covered entity?” tool and your adviser are the place to start. Practices outside HIPAA can still face FTC and state privacy rules, which our guide to tracking pixels touches on.

Where a form submission actually goes

Most practice owners picture a form as a box on the page and an email in the inbox. In between, the message usually passes through several systems run by different companies:

  • The visitor’s browser, and any scripts on the page that can read what they type, such as analytics, session recording, chat or ad tags
  • Your web host’s server, and often the website’s own database, where many form plugins keep a copy of every entry
  • A third-party form service, if the form is embedded from one
  • The email service that sends the notification, and the mailbox provider that stores it
  • Anything the form is connected to afterwards: a CRM, a spreadsheet, a marketing tool, a backup

Each of those points matters, because HHS looks at who creates, receives, maintains or transmits the information on your behalf, not at what the product is called.

What the Security Rule expects of a system that holds ePHI

The Security Rule covers PHI in electronic form (ePHI). HHS’s summary says covered entities and business associates must protect the confidentiality, integrity and availability of all ePHI they create, receive, maintain or transmit, and must carry out a risk analysis as part of that. Its technical safeguards include:

  • Access control: only authorized people can get to the information. For a form, that means who can log in to the website dashboard, the form service and the inbox.
  • Audit controls: a way to record and examine activity in systems that hold ePHI.
  • Integrity: measures so the information is not improperly altered or destroyed.
  • Authentication: checking that a person seeking access is who they say they are.
  • Transmission security: protection against unauthorized access while the information travels over a network.

An HTTPS padlock on the page helps with the last item, for the trip from the browser to your server. It does nothing for the copy sitting in the plugin’s database, the notification email, or a staff member’s shared password. HHS also explains that “addressable” items in the Security Rule are not optional: a regulated entity either adopts them where reasonable and appropriate, or documents an alternative that meets the same purpose.

Business associate agreements with form and email vendors

HHS describes a business associate as a person or organization outside your workforce that performs functions or services for you involving the use or disclosure of individually identifiable health information. When you use one, the Privacy Rule requires a business associate agreement (BAA) that sets written safeguards for the information.

HHS’s guidance on cloud services is the most useful document for website forms. It says a cloud service provider that creates, receives, maintains or transmits ePHI for a covered entity is a business associate, even if it only stores encrypted data and has no key to read it. A hosted form service or an email provider that stores your form submissions fits that description closely. The OCR tracking bulletin says the same about tracking vendors that receive PHI: a BAA is needed, and the disclosure must be permitted by the Privacy Rule.

There is a narrow exception for “conduits.” HHS gives the US Postal Service and certain couriers, and their electronic equivalents, as examples of organizations that only transport information and do not access it beyond what the transport requires. A service that keeps copies of messages for you is doing more than transporting them, so do not assume your form or email provider is a conduit without advice.

Practical points when you talk to a vendor:

  • Ask in writing whether they will sign a BAA, and for which product and plan the agreement applies.
  • Read the BAA itself. HHS publishes sample provisions that show what one covers, such as safeguards, reporting, subcontractors and what happens to the data when the contract ends.
  • Check every link in the chain, not just the form. A form service with a BAA that emails full submissions to a mailbox without one has moved the problem, not solved it.
  • Keep the signed agreements with your HIPAA records, next to your risk analysis.

What about email with patients?

HHS answers this directly in an FAQ. The Privacy Rule allows providers to communicate with patients by email if they apply reasonable safeguards, such as checking the address before sending and limiting the amount or type of information in unencrypted messages. If a patient starts an email conversation, HHS says the provider can generally assume email is acceptable to them, and can alert the patient to the risks of unencrypted email and let them decide. That FAQ is about communication with a patient. It does not replace the Security Rule and BAA questions above for the systems that store your form entries.

The simpler option: do not collect it

Many practices do not need clinical details on a public website form at all. A general contact form only has to let someone ask a question or request a call back. If the form does not ask for health information, says clearly not to send it, and routes clinical questions to the phone or to a patient portal that is already set up for PHI, far less of the chain above is in play.

A notice does not guarantee that nobody will type their symptoms anyway, so the inbox and the plugin’s stored entries still deserve care. What it does is keep the form’s purpose narrow and make the practice’s intent clear. Our own contact form on this site carries the line “Do not send patient information” for the same reason.

Ways to keep a general form narrow:

  • Ask only for name, a phone number or email, and a short reason picked from a neutral list such as “New patient question”, “Billing” or “Other”
  • Leave out free-text fields labelled “Symptoms” or “Reason for visit”
  • Put a short notice next to the submit button, not only in the privacy policy
  • Keep analytics, session recording and ad tags off the form page, as the tracking guide explains
  • Send online booking and intake through your practice management or scheduling system rather than a generic website form

A short review for your current forms

  1. List every form on the siteContact, appointment request, new patient, careers, newsletter, chat. Note what each one asks for and which page it sits on.
  2. Follow one test submissionSend a test entry and find every place it lands: the website dashboard, the form service, each inbox, any CRM or spreadsheet.
  3. Decide what each form is forIf a form does not need health information, remove the fields that invite it and add the notice. If it does, it belongs in a system your practice has assessed for ePHI.
  4. Check the vendors that remainFor each system that may hold ePHI, confirm whether a BAA is in place and what it covers.
  5. Review who has accessRemove old staff and agency logins from the website, the form service and shared inboxes, and stop sharing passwords.
  6. Write it downAdd the forms and the decisions to your risk analysis, and repeat the review when the site or a vendor changes.

Forms are one item in a wider website review. Our practice website checklist covers the rest, and if you are planning a new site, our medical website design page explains how we build contact pages that keep forms narrow. Calls are the other half of the front desk; the AI front desk page covers how those are handled.

Questions practice owners ask

Is there a “HIPAA compliant” form plugin I can just install?

A product cannot make a practice compliant on its own. HIPAA obligations attach to covered entities and business associates and depend on how a tool is configured, who can access it, where the data goes and whether a BAA is in place. A vendor willing to sign a BAA for the product you use is one piece; your own safeguards and the rest of the chain are the others.

Our site has HTTPS. Is the form secure enough?

HTTPS protects the submission on its way from the browser to your server, which relates to the Security Rule’s transmission security safeguard. It does not cover stored copies, notification emails, access control or vendor agreements, which HHS lists as separate requirements.

A patient emailed us their symptoms. Have we broken the rules?

HHS says that when a patient starts an email exchange, a provider can generally assume email is acceptable to that patient, while still applying reasonable safeguards. You can also tell the patient about the risks of unencrypted email and offer the phone or a portal instead. Ask your privacy officer how your practice handles such messages.

Do we need a BAA with our web designer or host?

It depends on whether they create, receive, maintain or transmit PHI for you. A host whose servers store form entries containing PHI, or an agency that logs in to read them, may be a business associate under HHS’s definition. If your forms do not collect PHI and staff are told not to send it to the agency, the question may not arise. Your adviser should look at the actual setup.

Is a privacy policy on the website enough?

No. A privacy policy explains your practices to visitors. It does not replace the safeguards in the Security Rule or the agreements HHS requires with business associates, and OCR’s tracking bulletin says a privacy policy statement alone does not permit disclosing PHI to a vendor.

For the notice text that goes on a form, including what the form is for, when messages are read and the 911 and 988 instructions, see our guide to medical website disclaimers, terms of use and emergency notices.

Sources

More in Practice websites, privacy and tracking

Want a second pair of eyes on your patient path?

Book a practice review. We look at how patients find you, what they see on your site, what happens when they call, and what you can measure today. You get a plain list of what we would fix first.

Book a practice review