Log in Sign up
Back to blog
Best Practices

What Actually Makes Your DPC Website HIPAA-Compliant

May 8, 2026 7 min read
Doctor typing on computer in office
Photo by Vitaly Gariev on Unsplash

Ask a room full of DPC physicians what makes a website HIPAA-compliant and you'll get a dozen different answers. Most of them wrong. Some will say you need special "HIPAA-compliant hosting." Others will say you can't have a contact form at all. A few will tell you the whole website needs to be encrypted end-to-end, whatever that means for a marketing page.

The reality is simpler and more specific than any of that. Your practice website is mostly a marketing site. It describes your services, shows your pricing, and gives people a way to reach you. HIPAA doesn't regulate marketing sites. It regulates the handling of protected health information, or PHI.

The question isn't "Is my website HIPAA-compliant?" It's "Does my website collect, transmit, or display PHI, and if so, am I handling it correctly?" Once you frame it that way, the answer gets a lot clearer.

What HIPAA actually covers on your website

HIPAA's Privacy Rule and Security Rule apply to protected health information. PHI is any individually identifiable health information, things like a patient's name paired with a diagnosis, treatment details, billing records, or even the fact that someone is your patient.

Your website's homepage, services page, pricing page, blog, and about page almost certainly contain zero PHI. They're public marketing content. HIPAA has nothing to say about them. You don't need a Business Associate Agreement with your web host just because your site exists.

Where HIPAA does come into play is anywhere your website touches actual patient data:

  • A contact form where someone might describe symptoms or mention they're a current patient
  • An embedded patient portal or scheduling tool that handles names, dates, and health details
  • Testimonials that identify real patients (with their consent)
  • Analytics tools that could inadvertently capture PHI from URL parameters or form fields

If your website doesn't do any of those things, your HIPAA exposure from the site itself is essentially zero. But most DPC practice sites do at least one or two of them, so let's walk through each one.

Contact forms: the most common risk

This is where most DPC websites stumble without realizing it. You add a simple contact form with a name field, email, and a free-text message box. Seems harmless. But the moment a prospective patient types "I have diabetes and I'm looking for a new doctor," that form submission now contains PHI.

The form itself isn't the problem. The problem is what happens to the data after they hit send. Where does that submission go? Is it emailed to you in plain text? Stored in a third-party database? Sitting in some form builder's admin panel that three employees of that company can access?

Here's how to handle it:

  • Keep the message field generic. Label it "How can we help?" or "Questions about membership" rather than "Describe your health concerns." You can't stop someone from typing medical details, but you can avoid inviting it.
  • Use a form service that encrypts submissions in transit. This means HTTPS on your site (which you should have anyway) and a form backend that uses TLS. Most modern form services do this by default.
  • Don't store submissions longer than needed. Respond to the inquiry, then delete the submission from the form service. Don't let years of form data pile up in a tool you forgot about.
  • If your form regularly receives PHI, get a BAA. If you're using a third-party form service and patients routinely share health details through it, that service is acting as a business associate. You need a Business Associate Agreement with them.

The practical fix for most DPC practices: use a simple contact form that collects a name, email, phone number, and a short message. Make sure your site runs on HTTPS. Don't overthink it beyond that unless you're building an intake form that asks for medical history.

Patient portals and embedded tools

Many DPC practices link to a patient portal, membership signup, or scheduling tool from their website. This is where HIPAA compliance actually matters, and the good news is that it's usually someone else's job.

If you use Hint Health for membership and billing, Hint handles the HIPAA compliance for the data flowing through their platform. Same for Atlas. Same for most established EHR and practice management tools. They sign BAAs, they encrypt data, they go through audits. That's what you're paying them for.

Your responsibility is simpler:

  • Link out, don't embed recklessly. A "Sign Up" button that takes the patient to Hint's hosted page is clean. You're handing off to a compliant platform. Embedding a third-party portal in an iframe on your site can work too, but make sure the embedded service is HIPAA-compliant on its end.
  • Don't build your own patient portal. Unless you have the resources to handle encryption, access controls, audit logs, and a BAA with your hosting provider, don't try to roll your own. Use the tools built for this.
  • Check that the link goes to HTTPS. Every link from your site to a patient-facing tool should point to an HTTPS URL. If it doesn't, find a different tool.

The pattern is simple: your marketing site handles the "convince them" part, then hands off to a compliant platform for the "collect their data" part. Keep those two things separate and you're in good shape.

Testimonials and patient photos

We covered this in depth in our testimonials guide, but it's worth repeating in the HIPAA context: patient testimonials are not a HIPAA violation as long as the patient consents.

HIPAA prevents you from disclosing patient information. It doesn't prevent a patient from voluntarily sharing their own experience. The critical piece is documentation. Get written consent that specifies where the testimonial will appear (website, print, social media) and keep that consent form on file.

A few guardrails to remember:

  • Never post a patient's words without their explicit written permission
  • Let patients choose whether to use their full name, first name only, or stay anonymous
  • If a patient asks you to remove their testimonial, do it immediately
  • Don't add health details that the patient didn't include themselves

Patient photos follow the same rule. A photo of a patient on your website requires their written consent. A photo of your office, your staff, or a stock photo requires nothing from a HIPAA perspective. When in doubt, skip the patient photo and use something else.

Analytics and tracking scripts

This one sneaks up on people. You install Google Analytics or a Facebook tracking pixel on your practice website because you want to know how many people visit your site. Reasonable. But those tools can capture data you didn't intend to share.

The risk comes from URL parameters and form data. If a patient clicks a link that includes their name or a medical term in the URL, and your analytics tool logs that URL, you've just sent PHI to a third party. Google Analytics in particular has been flagged by HHS as a potential HIPAA concern for healthcare websites when it captures identifiable information.

What to do about it:

  • Don't put PHI in URLs. If your site generates URLs with patient names or health information in the query string, fix that. URLs should be clean and generic.
  • Use privacy-focused analytics. Tools that don't use cookies and don't track individual users are a simpler path. They give you visitor counts and page views without the compliance headache.
  • If you use Google Analytics, disable data sharing features. Turn off the settings that share data with Google's advertising products. And don't use Google Analytics on any page that collects patient information.
  • Skip the Facebook pixel entirely. Unless you're running Facebook ads for your practice (most DPC docs aren't), there's no upside and real compliance risk.

The safest approach for a DPC practice site: use a lightweight, privacy-first analytics tool, or skip analytics altogether. You need to know if your site gets traffic. You don't need to know which individual people visited your pricing page at 2 AM.

The "HIPAA-compliant hosting" myth

This is the biggest misconception in DPC website land. Someone told you that you need "HIPAA-compliant hosting" for your practice website. That person was probably trying to sell you HIPAA-compliant hosting.

Here's the truth: if your website is a marketing site that doesn't store, process, or transmit PHI on the server, you don't need a BAA with your hosting provider. A static website with your services, pricing, blog, and a contact form that emails you doesn't require HIPAA-compliant infrastructure.

You need HIPAA-compliant hosting when your website itself stores patient data. If you're running a custom patient portal on your own server, storing medical records in a database you manage, or processing insurance claims through your website's backend, then yes, you need compliant hosting with a signed BAA.

But that's not what most DPC practices are doing. Most are running a marketing site and linking out to Hint, Atlas, or another compliant platform for the patient-facing data stuff. In that model, your hosting provider never touches PHI.

Don't pay three times the going rate for "HIPAA hosting" when your site is just HTML, CSS, and a few images. Put that money toward something that actually helps your practice.

A simple compliance checklist

Run through this list once. If you can check everything off, your website is in good shape.

  • HTTPS is active on every page. No exceptions. If your site still loads over plain HTTP, fix that today. Most hosting providers offer free SSL certificates.
  • Contact form submissions are encrypted in transit. Your form backend should use TLS. Submissions shouldn't be emailed in plain text to a personal Gmail account.
  • No PHI in URLs. Check your site's links, confirmation pages, and any booking tool URLs. Patient names and health details should never appear in the address bar.
  • Third-party tools that handle PHI have BAAs. If you use a scheduling tool, EHR portal, or form service that collects patient health information, confirm that provider will sign a BAA with you.
  • Analytics don't capture identifiable data. Review your analytics setup. If you're using Google Analytics, make sure it's configured to not collect personal information. Better yet, switch to a privacy-first alternative.
  • Patient testimonials have documented consent. Written permission for every quote on your site. Filed and accessible.
  • No patient data stored on your web server. If your marketing site links out to compliant platforms for data collection, confirm that no PHI is being cached or logged on your side.

That's seven items. Most DPC practices can get through this list in an afternoon. If you find a gap, fix it. If everything checks out, stop worrying about HIPAA and your website.

The takeaway

HIPAA compliance for your DPC website is not the minefield people make it out to be. Your marketing site, the part with your services, pricing, and blog, is almost certainly fine as-is. The places to pay attention are contact forms, embedded tools that handle patient data, testimonials, and analytics scripts.

Get HTTPS on your site, keep PHI out of URLs and analytics, use compliant platforms for anything that touches patient data, and document consent for testimonials. That covers 99% of DPC practices. Save the expensive compliance consultants for when you're actually building a patient portal, not when you're putting up a five-page marketing site.

Ready to check website off your list?

DPC Spot gives you a professional, mobile-friendly practice site built for direct primary care. HTTPS out of the box, clean contact forms, and seamless links to Hint and Atlas for the patient data stuff. No compliance headaches, no template wrestling. Get started for free and have your site live by the end of the day.