HIPAA compliant website hosting, explained without the sales pitch

HIPAA protects individually identifiable health information. A website that publishes your address, your opening hours, the procedures you offer and the names of your clinicians is publishing information about your practice, not about your patients. There is no protected health information on that page, so there is nothing for a hosting arrangement to safeguard, and no amount of specialist hosting changes that either way.

The picture inverts the moment the site starts receiving information from patients:

• An intake or new-patient form that collects medical history
• A contact box that invites someone to describe their symptoms, which they will do whether or not you asked them to
• An appointment request naming a condition, a procedure, or a specialist
• A patient portal, or a login that identifies someone as your patient
• A chat widget that captures a conversation about a health concern and stores the transcript
• Analytics or advertising scripts on a page whose URL alone reveals a patient relationship

Every item on that list is a decision about what your website does, and every one of them is more consequential than which company owns the server. Hosting matters — but it is the fourth question, not the first. The full guide to HIPAA website requirements works through the rest of them.

Where it runs

The platform runs on Microsoft Azure — every published practice site, the dashboard and the generation pipeline. Requests arrive through a Cloudflare edge layer and are routed by hostname to the application. You do not administer a server, patch an operating system, or manage a certificate.

Encryption in transit

Every published page is served over HTTPS. Certificates are issued automatically the moment a domain resolves to us and renewed automatically thereafter, so there is nothing to buy, install, or forget to renew. This is worth stating plainly because the classic failure on practice websites is not the absence of TLS but its partial application — a secured form page reached through an unsecured home page.

What a published site is permitted to do

This is the part that distinguishes ClinicSite hosting from ordinary hosting, and it is a deliberate design choice rather than a feature we bolted on. Every published site runs under a strict content security policy that:

• Blocks form submission entirely. A published ClinicSite page cannot post data anywhere, to us or to anyone else.
• Blocks outbound network calls. No analytics, no advertising pixels, no session recording, no third-party tag manager.
• Blocks third-party scripts.Nothing executes on your visitors’ browsers except the stylesheet framework the page is built with — and the website assistant, if you enable it, which widens the policy by exactly one known origin and nothing more.
• Blocks plugins and framing manipulation through the same policy.

The consequence is unusual and worth being direct about: a published ClinicSite website does not collect patient information, because it structurally cannot. Visitors contact your practice by tapping your phone number or your email link. There is no form database to secure, no form vendor to sign a BAA with, and no stored submission to disclose in a breach.

That is a real constraint as well as a real safeguard. If your practice depends on web forms for intake, ClinicSite does not do that today and you should know it before you subscribe rather than after. We would rather lose the sale than describe this as something it is not.

When PHI does reach the platform

One feature moves patient-adjacent data onto ClinicSite: the EMR integration, which brings appointment and clinician records into your dashboard schedule view. Where that data is involved:

• EMR credentials are encrypted at rest with AES-256-GCM, and each encrypted value is cryptographically bound to the clinic it belongs to, so a stored blob cannot be transplanted from one practice to another.
• The sync runs in an isolated per-clinic worker holding its own restricted database role rather than broad access to the platform.
• Row-level security policies apply to the appointment and clinician tables, constraining what a sync worker can reach.
• Application logging is structured to keep patient information out of log lines.

If you are considering connecting an EMR, a business associate agreement is the correct thing to ask about, and asking is the right instinct. Raise it with us directly at the contact page before you connect anything.

Questions worth asking us and every alternative you are considering:

1. Does the website you build collect any patient information? If yes, where does it go, who stores it, and for how long?
2. Which of your subprocessors touch that data — form provider, chat vendor, email service, analytics — and do you hold a BAA with each of them?
3. Will you sign a BAA with me, and what does it actually cover?
4. What third-party scripts will run on my published site, and can I turn them off?
5. Is every page served over HTTPS, or only the pages with forms?
6. Who owns the website and the content if I leave, and what happens to my domain?
7. What audit reports do you publish, and what do you decline to claim?

The last one is the most revealing. A vendor with a clear, unembarrassed list of things it does not do is generally a more reliable partner than one whose marketing page has no edges at all.