HIPAA compliance is one of the most misunderstood topics in dental practice web development. Practice owners get told their website “must be HIPAA compliant,” vendors sell “HIPAA-compliant websites” as a premium tier, and nobody quite explains what any of it means. This post is the clear-eyed version.
The short version: a marketing website for a dental practice usually doesn’t need to be HIPAA-compliant in any meaningful technical sense, because it doesn’t handle Protected Health Information. What it does need is a vendor who understands where the line is, so that when patient data starts flowing, it flows through the right infrastructure.
What HIPAA actually says about websites
HIPAA is a federal law that governs how covered entities (healthcare providers, health plans, and healthcare clearinghouses) and their business associates (vendors that handle Protected Health Information on their behalf) protect PHI.
Your dental practice is a covered entity. Your web developer becomes a business associate if and only if they handle PHI on your behalf. That’s the whole test.
Your website itself is just software. Software isn’t a covered entity or a business associate — the company operating it is. So the question isn’t “is my website HIPAA compliant” but “does my website’s data flow put my vendor into a HIPAA business associate relationship, and if so, have we signed a Business Associate Agreement?”
What counts as Protected Health Information (PHI)
PHI is any information that:
- Relates to an individual’s past, present, or future health, healthcare, or payment for healthcare, AND
- Identifies the individual (or could reasonably be used to identify them).
Things that are PHI:
- A patient’s name attached to their appointment history, treatment records, or insurance information.
- A completed intake form asking about medical conditions, medications, or dental history.
- File uploads of insurance cards, X-rays, or medical records.
- Any communication from an identified patient about their care.
Things that are usually not PHI:
- A generic “contact us” form asking for name, email, and reason for visit (“I’d like to schedule a cleaning”).
- Site analytics tracking anonymous traffic patterns.
- A public “meet our doctors” page.
- Marketing content, service descriptions, blog posts.
The line gets drawn at “identifiable + health-related.” A form that asks “what’s your name and phone number, and what’s this about?” and gets a reply of “I need to schedule a routine cleaning” — that’s arguably borderline. A form that asks “what medications are you taking?” or “please describe your dental history” — that’s clearly PHI.
When you need a Business Associate Agreement (BAA)
You need a BAA with your web development vendor if:
- Your website has a patient portal that authenticates against your PMS.
- Your website hosts intake forms that collect health information.
- Your website accepts file uploads of medical or insurance records.
- Your vendor has direct access to your PMS or patient scheduler for integration purposes.
- Your vendor is involved in transmitting, storing, or processing PHI in any capacity.
You do not need a BAA if:
- Your vendor built a marketing site with a basic contact form that just asks for name, email, and a message.
- Your vendor set up your Google Business Profile.
- Your vendor is doing SEO work on public marketing pages.
The safest position: if you’re uncertain whether the work involves PHI, sign a BAA anyway. It’s a standard document, it doesn’t cost anything to have in place, and it protects both sides.
Common myths
Myth: “HIPAA-compliant hosting” is a real product.
There’s no such thing as HIPAA-compliant hosting in isolation. There’s hosting that can be part of a HIPAA-compliant operational stack when properly configured and covered by a BAA with the hosting provider. Cloudflare, AWS, Google Cloud, and DigitalOcean all offer BAAs for accounts operated under specific tiers and configurations. But the hosting alone isn’t the compliance — it’s the whole chain of policies, agreements, technical controls, and workflows.
Myth: You need “SSL for HIPAA.”
Every website needs HTTPS in 2026 regardless of HIPAA. Not having HTTPS is a browser warning, an SEO negative, and a security failure. But HTTPS alone is not the same as HIPAA compliance — a HIPAA-covered data flow needs HTTPS and proper access controls, audit logging, backup, disaster recovery, and everything else.
Myth: “We use a HIPAA-compliant patient portal, so our website is HIPAA compliant.”
Your patient portal being HIPAA-compliant means the patient portal handles PHI correctly. If your marketing website links to the portal, and the portal is on your PMS vendor’s infrastructure with its own BAA, that’s fine — the PHI never touches your marketing site. That’s actually the right architecture. But it doesn’t make your marketing site “HIPAA compliant” (which is a meaningless statement anyway).
What we do at Militech
Our default approach for dental marketing websites:
Keep PHI out of the marketing site’s data flow. Patient portals live on your PMS vendor’s infrastructure, which is covered by the PMS vendor’s BAA with you. Online booking uses your patient scheduler’s hosted form (Zocdoc, NexHealth, etc.), which has its own compliance posture. Insurance verification flows go through the vendor’s infrastructure. The marketing site collects marketing-level information (name, phone, “I’d like to schedule an appointment”) and hands actual PHI-touching workflows off to properly-covered systems.
Sign a BAA when the scope requires it. When we’re building a patient portal that authenticates against your PMS, or integrating deeply with your practice’s data flows, we sign a Business Associate Agreement as standard practice. If the scope is a marketing site with a contact form, we won’t insist on a BAA you don’t need.
Architect the data flow explicitly. Every dental engagement we do includes an explicit conversation about what data touches what infrastructure. You should know exactly where patient data lives, who has access to it, and where the boundaries are.
Use compliance-aware infrastructure. Even when we’re not handling PHI, we host on infrastructure that’s used for compliance-sensitive workloads industry-wide (Cloudflare and similar). If your practice ever expands its patient-facing digital footprint, the foundation is compatible.
Practical guidance for practice owners
If you’re evaluating web developers for your dental practice:
- Ask them to explain the data flow. “Walk me through what happens when a patient fills out a form on my site.” If they can’t do this clearly, they haven’t thought about it.
- Ask about BAA policy. “Under what circumstances do you sign a BAA, and what’s your standard document?” If they don’t have one or don’t know what a BAA is, you have your answer.
- Ask about PMS integrations specifically. “How do you integrate with Dentrix / Eaglesoft / Open Dental / etc., and how do you handle credentials?” You want vendor-supported integrations, not scrape-based workarounds that break when the PMS updates.
- Ignore vendors who claim “HIPAA-compliant websites” as a feature. They’re either uninformed or marketing to the uninformed.
Have specific questions about HIPAA and your dental practice website? Contact us — happy to talk through your specific data flow. Or see our dental practice services page for the full offer and FAQ.