The Website Is the Smallest Part of the Problem

Most conversations about practice websites focus on design and content. Both matter, but neither is the infrastructure. The infrastructure is what determines whether the site is fast, reliable, secure, and HIPAA-defensible. It is also what your patients interact with whether they notice it or not: how long the page takes to load on a phone in a parking lot, whether the contact form submission actually reaches your front desk, whether a site outage during a high-traffic week costs you consultations.

This article covers the infrastructure layer: what choices go into it, what each component does, and what a well-configured stack looks like for a surgical specialty practice.

Hosting: Static vs Dynamic and Why It Matters for HIPAA

The fundamental hosting decision for a practice website is static versus dynamic.

Dynamic hosting runs server-side code on every page request. WordPress is the dominant example. The server receives a request, queries a database, assembles the HTML, and returns it. Dynamic hosting requires a persistent server, a database, and application software that must all be kept updated and secured.

Static hosting serves pre-built HTML files directly from a CDN edge network. There is no server-side code to execute on a patient request, no database query, no application layer that can be compromised through SQL injection or plugin vulnerabilities. The site is built once (at deploy time) and served as files.

For surgical practices, static hosting has three specific advantages:

Performance. A file served from a CDN edge node 30 miles from the patient loads in under 100ms. A WordPress install on shared hosting making a database query can take 800ms to 2 seconds before a single byte reaches the browser. This gap is the primary driver of Core Web Vitals failures on practice sites.

Security posture. Static files have no attack surface for the categories of vulnerability that affect dynamic sites: SQL injection, PHP remote code execution, WordPress plugin exploits. The majority of healthcare website breaches involve compromised CMS installations, not static file servers.

HIPAA surface area. A static site that never executes server-side code on patient requests and never connects to a patient-data database has a significantly smaller HIPAA risk surface than a dynamic site. The forms are the only data collection point, and those can be handled through a controlled, auditable pipeline rather than through the CMS itself.

CDN: Why Edge Delivery Is Non-Negotiable for Patient-Facing Sites

A CDN (Content Delivery Network) distributes your site’s files across dozens or hundreds of geographic edge nodes. When a patient in Phoenix requests your page, they get it from the Phoenix edge node rather than a server in Virginia or Oregon. The round-trip time drops from 80–150ms to under 10ms.

For surgical practice sites, CDN is not a performance optimization. It is the baseline. Google’s Core Web Vitals measurement includes network latency. A site that performs well only for patients within 50 miles of its origin server will fail LCP for a meaningful portion of its visitors.

Modern static hosting platforms (Netlify, Vercel, Cloudflare Pages) include global CDN distribution as the default delivery layer. This is part of what makes them appropriate for practice sites: the infrastructure question is answered by the platform rather than requiring a separate CDN configuration.

What to confirm with your hosting provider:

  • Files are served from edge nodes, not solely from a single origin server
  • The CDN supports HTTP/2 or HTTP/3 for multiplexed asset delivery
  • Cache headers are configured to allow browsers to reuse static assets between visits (CSS, fonts, images)
  • Cache invalidation on deploy is automatic, so a site update goes live globally within seconds

SSL and HTTPS: Table Stakes, But Check the Details

Every patient-facing practice website must serve over HTTPS. This is not a recommendation; it is a requirement for HIPAA compliance (the Transmission Security standard under the Technical Safeguards) and a Google ranking signal. Any page served over HTTP in 2025 is incorrectly configured.

Beyond the basic certificate, a few specifics matter:

Certificate type. A wildcard certificate covering *.yourpractice.com protects all subdomains. A standard DV (domain validated) certificate covers the base domain. Either is adequate for HIPAA transmission security; the choice affects cost and management overhead.

HSTS (HTTP Strict Transport Security). HSTS tells browsers to always use HTTPS for your domain, even if a user types http:// or follows an HTTP link. Without HSTS, there is a brief window on first visit where the browser makes an unencrypted request before being redirected to HTTPS. Modern hosting platforms enable HSTS automatically; confirm it is active.

Certificate renewal. SSL certificates expire. A lapsed certificate produces a browser warning that blocks patients from reaching the site. Confirm that renewal is automatic through your hosting provider. A practice relying on a manually renewed certificate is one oversight away from a site outage.

Form Handling: The Part Most Agencies Get Wrong

Contact forms and appointment request forms are the highest-value patient interaction point on a practice website. They are also the most common source of data handling problems, including HIPAA exposure.

What not to use:

Contact Form 7, Gravity Forms, WPForms, and similar WordPress form plugins store submission data in the WordPress database. That database is on a server your marketing agency controls, likely without a BAA, and with access permissions that may include their developers, their support staff, and their hosting provider. Every form submission is potentially PHI stored in an uncontrolled location.

Third-party form services (Typeform, JotForm, Formspree) receive the form data on their servers. Most of these services do not offer HIPAA BAAs on standard plans. The data is being stored by a third party without authorization.

What to use instead:

The cleanest approach for a static practice site is a HIPAA-eligible form backend that holds a BAA and routes submissions directly to your front desk without storing them in a third-party database.

Options for HIPAA-compliant form handling:

  • A Cloudflare Workers endpoint routes form submissions server-side to your front desk without storing PHI in a third-party database
  • A first-party form endpoint on a server you control, forwarding to your practice management system or encrypted email
  • A HIPAA-compliant form service such as Formstack or JotForm HIPAA (both offer BAAs with HIPAA-eligible plans)

The form submission should reach your front desk staff through an encrypted channel, with no intermediate third-party storage that lacks a BAA.

What the form should not collect:

A web contact form should collect the minimum needed to book a consultation: name, phone number, and optionally a preferred callback time. It should not ask about the patient’s condition, symptoms, insurance, or anything that constitutes clinical PHI. The clinical intake happens inside your practice management system, not on your public website.

Transactional Email: Confirmations Without PHI Leakage

When a patient submits a form, they expect a confirmation. That confirmation email is a HIPAA consideration.

A confirmation email that says “Your appointment request for lumbar fusion surgery with Dr. Smith has been received” contains PHI: the procedure type, the physician name, and an implicit confirmation of the patient’s medical intent, all tied to the patient’s email address.

A confirmation email that says “We received your message and will contact you within one business day” contains no PHI. It confirms receipt without revealing the nature of the inquiry.

For transactional email (automated confirmations sent on form submission), use a service that:

  • Offers a HIPAA BAA (SendGrid HIPAA plan, Mailgun with BAA, AWS SES with BAA)
  • Does not store message bodies long-term in a logging system accessible to third parties
  • Routes through your domain (not a shared sending domain that could associate your patients with a specific vendor)

Keep confirmation email content minimal: receipt acknowledgment, expected response time, your phone number. No procedure names, no physician names, no specifics about the inquiry.

Uptime Monitoring: Knowing Before Your Patients Do

A practice website that goes down during business hours costs consultations. A site that is down at 7pm on Tuesday, when a patient is researching surgeons after work, costs a consultation you will never know you lost.

Uptime monitoring checks your site’s availability at regular intervals (typically every 1–5 minutes) and alerts you immediately when it becomes unreachable.

What to monitor:

  • The homepage (basic availability check)
  • The appointment request page (the most conversion-critical URL)
  • The form submission endpoint (confirm forms are accepting submissions, not just that the page loads)

Alert routing:

Uptime alerts should go to a phone number or email that is monitored outside business hours. A site outage at 9pm should not be discovered at 9am the next day.

Recommended tools:

UptimeRobot (free tier covers basic HTTP monitoring) and Better Uptime both provide adequate coverage for a practice site. The specific tool matters less than ensuring that alerts are configured and the response path is clear.

Backups and Deployment Recovery

For a static site deployed from a git repository, the git history is effectively a complete backup. Every version of the site ever deployed is stored in the repository. Rolling back to a previous version is a one-command operation.

For WordPress and dynamic sites, backups require more active management: database dumps, file system snapshots, and a tested restoration procedure. The restoration procedure is the part most agencies skip. A backup that has never been restored is a theoretical backup.

What to confirm:

  • Automated daily backups exist (most managed WordPress hosts provide this)
  • At least one backup per month is verified by actually restoring it to a staging environment
  • Recovery time objective (RTO) is defined: if the site goes down, how long until it is back up, and who is responsible for making that happen

For DataCentury-managed sites, the git-based deployment model means any version can be redeployed to a global CDN within two minutes. There is no database to restore, no CMS to reconfigure.

The Infrastructure Checklist

Before signing off on any practice website infrastructure, verify each of the following:

Hosting and delivery:

  • Static files served from a global CDN edge network
  • HTTP/2 or HTTP/3 enabled
  • Deployment pipeline automated (push to git triggers a new deploy)

Security:

  • HTTPS with automatic certificate renewal
  • HSTS enabled
  • No open admin panels accessible from the public internet

Forms and data handling:

  • BAA in place with form handling provider
  • Form submissions route to practice staff without intermediate third-party storage
  • Confirmation emails contain no PHI

Monitoring:

  • Uptime monitoring with alerts to an actively monitored channel
  • Alert tested to confirm it actually fires

Backups and recovery:

  • Automated backups or git-based version history
  • Recovery procedure documented and tested

This list is not exhaustive for a full HIPAA Technical Safeguards assessment, but it covers the web infrastructure components most commonly left unaddressed on practice sites managed by general-purpose marketing agencies.

What DataCentury Manages

Every site we build and maintain for surgical practices uses static hosting on Cloudflare’s global CDN, HTTPS with HSTS, a BAA-covered form pipeline, transactional email that contains no PHI, uptime monitoring with immediate alerting, and git-based deployment with full version history.

The BAA we provide covers our role as a business associate in the management of the practice’s web infrastructure. It is standard in our engagement terms, not an add-on.

If you are currently running a practice website and want to understand where your infrastructure gaps are, the infrastructure audit is the starting point.