HIPAA website requirements: what actually applies to a clinic site

HIPAA governs protected health information: individually identifiable health information held or transmitted by a covered entity or its business associates. Two parts of that definition do the work. The information has to relate to a person’s health, care, or payment for care, and it has to be identifiable — tied to a name, a phone number, an email address, an account, a device identifier, or enough surrounding detail to point at one person.

A brochure website usually contains none of that. If your site publishes what your practice does, which clinicians work there, which insurance you accept, where you are, when you are open and what number to call, then it holds information about your business, not about your patients. That site is not a HIPAA problem. It may still have accessibility obligations, state law obligations, advertising rules from your licensing board, and ordinary security responsibilities — but the Privacy Rule and the Security Rule have nothing to attach to.

HIPAA obligations attach the moment the website does any of these:

• Collects a patient intake form. Name plus date of birth plus reason for visit is protected health information the instant it is submitted.
• Offers a “describe your symptoms” contact box. The field name is doing the damage. Anything that invites clinical detail will receive it.
• Hosts a patient portal login. The existence of an account is itself a statement that a treatment relationship exists.
• Takes an appointment request that names a condition or a service.“Request an appointment” with a service dropdown reveals more than a phone number does.
• Runs a chat widget that accepts health details, or stores transcripts of conversations with identifiable people.
• Processes payments tied to care, or displays balances, statements or claim status.

The practical consequence is that the question “is my website HIPAA compliant?” is usually the wrong question. The better one is: what patient information, if any, does my website touch, and where does it go afterwards? If the honest answer is “none, everything goes through the phone and the EMR,” you have removed most of the risk surface rather than trying to secure it. That is a legitimate design decision and often a better one than building a form and then defending it.

A business associate agreement (BAA) is the written contract that has to be in place before a vendor handles protected health information on your behalf. It is not a formality and it is not a marketing asset. It is the mechanism by which your obligations follow your data.

What a BAA has to do

• Define the permitted and required uses and disclosures of the information.
• Prohibit uses or disclosures beyond what the contract and the law allow.
• Require appropriate safeguards to prevent impermissible use or disclosure.
• Require the business associate to report security incidents and breaches to you.
• Bind subcontractors to equivalent terms, so the chain does not leak at the second link.
• Provide for access, amendment and accounting so you can meet patient rights requests that depend on data the vendor holds.
• Address return or destruction of the information when the relationship ends.

“Our servers are HIPAA compliant” is not a BAA

This sentence appears on a great many hosting websites and it means less than it sounds like. Servers can be encrypted, access-controlled, monitored and physically secure — all genuinely useful — and none of that creates a contractual obligation to you, a duty to notify you of a breach, or any limit on what the vendor may do with your data. Infrastructure is a capability. A BAA is a commitment. You need the commitment, and a vendor that has built the capability should have no difficulty signing for it.

Nothing is HIPAA certified

There is no HIPAA certification. No government body certifies products, no official seal exists, and no audit firm can confer HIPAA compliance on a piece of software. HIPAA is enforced after the fact: regulators examine whether a covered entity and its business associates actually did what the rules require. Third-party attestations like SOC 2 or HITRUST are real and can be useful evidence about a vendor’s controls, but they are not HIPAA certification and no vendor should present them as such.

When a vendor advertises a “HIPAA certified” product, you have learned something useful — just not what they intended. Ask instead: will you sign a BAA, what does it cover, who are your subcontractors, and what independent assessment of your controls can you show me?

If a clinic website causes a HIPAA problem, a form is usually how. Forms feel harmless because they look like part of the page, but a form is a pipe, and the interesting question is always where the other end of it is.

Plain-text email delivery is the classic failure

The default behaviour of most website form tools is to email you the submission. That single design choice can send a patient’s name, contact details and description of their symptoms across the internet through a mail relay you have no agreement with, into an inbox that may be a personal account, where it sits indefinitely and gets forwarded. It happens because it is the path of least resistance during setup, and it is rarely revisited afterwards.

The vendor chain behind a form is longer than it looks

A form embedded on a clinic site may involve the website platform, a separate form-builder service, a spam-filtering service, an email delivery provider, a notification integration, and a spreadsheet or CRM where responses accumulate. Each is a business associate if PHI passes through it, each needs a BAA, and each has its own subcontractors. Map the chain before you publish the form, not after someone asks.

The honest alternative: do not collect clinical detail on the website

Many practices route intake through their EMR’s patient portal, which is already covered by an agreement and already built for this, and keep the public website to published information plus a phone number, an address and a link into that portal. This is not a compromise. It concentrates PHI in the one system designed to hold it, and it means the marketing site — the part most likely to be redesigned by an agency, migrated between hosts or plugged into new tools — never becomes a place where patient data lives.

If you do decide to collect, collect the minimum. A form that asks for a name and a callback number is a far smaller problem than one that asks what is wrong. Necessary information can be gathered on the phone or in the portal.

Email and patient communication

A mailto: link and a form post carry different risks. A mailto:link hands the message to the patient’s own email client; nothing passes through your website, your host or a form vendor, and the chain of intermediaries where most website breaches occur simply does not exist. What it does not do is make the resulting email disappear. Once a patient sends you clinical detail, that message is protected health information in your mailbox, and your email provider is handling it.

Patients are permitted to email you, and to receive replies by unencrypted email if they have been warned of the risk and still prefer it. What is not acceptable is for the practice to treat ordinary email as a default channel for clinical information without that conversation, or to leave years of patient email accumulating in an unprotected personal account.

Breach notification in outline

When unsecured protected health information is acquired, accessed, used or disclosed impermissibly, the Breach Notification Rule requires notification unless a risk assessment shows a low probability that the information was compromised. Notice goes to the affected individuals, to the Secretary of Health and Human Services, and — above a size threshold — to prominent media in the affected area. Business associates must notify the covered entity, which is one reason the reporting clause in a BAA matters so much: without it you may not learn that anything happened.

Specific deadlines and thresholds are set by regulation and are worth confirming with your compliance officer rather than from an article. What every practice should have in advance is a written procedure naming who is called, who assesses, who notifies and in what order — decided before an incident, not during one.

Documentation and risk analysis

The Security Rule expects an accurate and thorough assessment of risks to electronic protected health information, and expects it to be maintained rather than performed once. Website-relevant documentation includes: an inventory of what the site collects, a list of vendors that touch it and the status of each BAA, an inventory of third-party scripts and what they transmit, the reasoning behind decisions you made, and the date each item was last reviewed. Undated documentation is worth very little. A short, current, honest record beats a long, stale one.

This section is about our product rather than about the regulation, and it is short on purpose. What is above stands on its own regardless of what you build with.

• Generated ClinicSite websites do not collect patient information. Published sites run under a content security policy that blocks form submission outright and blocks outbound network calls. Contact runs through tel: and mailto: links rather than form posts.
• Every published site is served over HTTPS with certificates issued and renewed automatically.
• The platform runs on Microsoft Azure.
• Connected SimplePractice EMR credentials are encrypted at rest with AES-256-GCM, each ciphertext bound to its tenant.