The HIPAA-Aware Website Checklist for Telehealth Startups

Let's start with the part most vendors won't say plainly: no web developer can make you HIPAA compliant.

Compliance is organizational. It's your policies, your training, your risk assessment, your business associate agreements, and your counsel. A development team can only make sure the technical side isn't the thing that fails you.

That's a meaningful contribution — technical failures are how most breaches actually happen — but anyone selling you a "HIPAA compliant website" as a product is overselling. Ask them which of your policies they wrote.

With that said, here's what genuinely needs to be true on the technical side.

First: draw a line through your own site

Before any checklist, answer one question. Which parts of your site touch protected health information, and which don't?

Your marketing pages — the homepage, condition pages, pricing, about — usually touch none. Your intake, your portal, your scheduling, your messaging all do.

Keeping these genuinely separate is the single highest-value architectural decision you'll make. It means your marketing team can run analytics, heatmaps, and ad pixels on the marketing side without dragging your entire site into PHI scope.

Blur that line and everything downstream gets harder and more expensive.

The infrastructure checklist

Every vendor touching PHI has signed a BAA. Not "is HIPAA compliant" in their marketing copy — has actually signed a business associate agreement with you. This includes hosting, database, file storage, email, SMS, error monitoring, and backups. If your error tracker captures a stack trace containing a patient's data and that vendor hasn't signed, you have a problem.

Encrypted in transit and at rest. TLS 1.2 or better everywhere, no exceptions and no mixed content. Database and file storage encrypted at rest. This is table stakes and mostly free from modern providers.

Access controls that are real. Unique logins per person — no shared accounts, ever. Role-based permissions so a support agent can't pull the full patient database. MFA on anything administrative.

Audit logging. Who accessed what, when. You need this to detect a problem and to demonstrate what happened afterward. Logging that nobody reviews is only half useful, but logging you don't have at all is indefensible.

Automatic session timeouts. A logged-in portal on a shared or public machine is a real exposure.

A backup and recovery plan you have actually tested. Untested backups are a story you tell yourself.

The tracking scripts problem

This is where most telehealth sites quietly fail, and it deserves its own section.

Analytics, ad pixels, session recorders, and chat widgets all send data to third parties. On a page that touches PHI, that can mean transmitting protected information to a company that never signed a BAA — which is a disclosure.

It's easier to do accidentally than people expect. A URL like /intake/results?condition=hiv sends the condition to your analytics provider in the page path. A session recording tool captures the form fields as they're typed. An ad pixel fires on the confirmation page after someone books a specific consultation.

Federal regulators have been active on exactly this pattern, and there have been substantial enforcement actions and settlements over tracking technologies on health sites.

Practical rules:

• No third-party tracking on any page behind the login or inside intake
• Never put anything identifying or clinical in a URL, query string, or page title
• Audit what's actually loading on your PHI pages, not what you think is loading
• If marketing wants conversion data, pass a de-identified event server-side rather than firing a pixel in the patient's browser

Forms are the most common leak

The generic form service that's perfect for a normal business website is usually the wrong choice the moment a patient types anything into it.

Most standard form tools won't sign a BAA. If your intake form posts to one, patient data is now sitting in a system outside your compliance boundary.

The same applies to where the submission lands. A notification email containing patient details, sent through a standard email provider, is the same problem wearing a different hat.

What to ask a vendor before you hire them

Five questions. The answers tell you a lot.

1. "Which of our vendors will need to sign BAAs, and will you help us get them?" — a good answer is a specific list.
2. "How will you keep marketing pages out of PHI scope?" — if they don't understand the question, keep looking.
3. "What happens to patient data in your error monitoring and logs?" — the honest answer involves scrubbing, not "it doesn't."
4. "Who on your side will have production access, and how is it logged?"
5. "What are you explicitly not responsible for?" — the best vendors answer this one immediately and in detail.

The realistic version

A HIPAA-aware build costs more and takes longer than a standard site. BAA-covered infrastructure is more expensive, access controls are real work, and the review cycles are slower.

Budget for that honestly rather than discovering it in month three. And get your compliance counsel involved before the architecture is decided, not after it's built — retrofitting a data model is dramatically more expensive than designing it right the first time.

---

We build HIPAA-aware sites, intake flows, and scheduling for US telehealth companies, and we're clear about where our responsibility ends. See how we work.