The Mechanism Most Practices Have Never Considered
A visitor navigates to /procedures/laminectomy/ on your practice website. Two things happen simultaneously that most practice administrators never think about:
- Their browser loads your page
- Their browser makes direct requests to every third-party server your WordPress plugins and theme reference
That second event is the one that creates HIPAA exposure.
The visitor’s IP address is transmitted in every one of those third-party requests. The full page URL (including the procedure path) is transmitted as the HTTP referrer. The third-party server receives both. If that server belongs to a vendor who has not signed a BAA with your practice, you have disclosed PHI without authorization.
This is not a hypothetical edge case. It is the default behavior of every WordPress site running third-party plugins and themes, which is every WordPress site.
Why IP Address Plus Procedure URL Is PHI
HIPAA defines PHI as individually identifiable health information: information that relates to a health condition, the provision of healthcare, or payment for healthcare, and that identifies or could identify the individual.
An IP address alone is not PHI. A procedure name alone is not PHI. The combination of a specific IP address viewing a specific procedure page is health information tied to an identifiable person, and it meets HIPAA’s definition.
The OCR has been explicit on this point. Its December 2022 bulletin on tracking technologies stated that a combination of an individual’s IP address with a visit to a webpage that addresses specific health conditions or specific healthcare providers is PHI. The bulletin was directed specifically at healthcare providers using tracking technologies on patient-facing websites.
A surgical practice website is a patient-facing website. Every page under /procedures/, /conditions/, /surgeons/, and /appointments/ is a page where a visitor’s presence reveals health-related information. Any plugin that transmits data from those pages to a third-party server is operating in PHI territory.
How WordPress Plugins Create Third-Party Requests
When a browser loads a WordPress page, it executes the HTML the server returns. That HTML includes references to external resources: scripts, stylesheets, fonts, images, tracking beacons. For each reference, the browser makes a separate outbound HTTP request.
That request includes:
- The visitor’s IP address (in the request headers)
- The full URL of the page being viewed (in the HTTP Referer header)
- Browser and device information (in the User-Agent header)
- Any cookies the third-party domain has previously set on the visitor’s browser
The plugin author’s server receives all of it. In most cases the plugin author’s privacy policy, to whatever extent it exists, was not written with HIPAA in mind and does not include a BAA provision.
Plugin Categories at Risk
The exposure is not limited to advertising trackers. It applies to any plugin that loads external resources, which covers the majority of the WordPress plugin ecosystem.
Font and Icon Plugins
Plugins that load typefaces or icon sets from remote servers (Google Fonts, Font Awesome CDN, Adobe Fonts) make a request to the font provider’s server on every page load. That request includes the visitor’s IP address and the page URL. Google Fonts does not sign HIPAA BAAs. Neither does Font Awesome’s CDN.
The fix for fonts is self-hosting: download the font files and serve them from your own domain. The request stays within your infrastructure and never reaches a third-party server.
SEO Plugins
Major SEO plugins (Yoast, Rank Math, All in One SEO) include features that phone home to their own servers: license validation, feature update checks, usage analytics. Some of these requests occur on the front end (visible to the visitor’s browser) and some on the back end (server-to-server). Front-end requests transmit visitor data. Back-end requests typically transmit site configuration data rather than visitor data, but the distinction requires verification.
Page Builder Plugins
Page builders (Elementor, Divi, WPBakery) commonly load assets from their own CDNs: icons, animations, template previews. These CDN requests originate from the visitor’s browser and include the full page URL as the referrer.
Contact Form Plugins
Contact Form 7, Gravity Forms, and WPForms include reCAPTCHA integration by default in many configurations. reCAPTCHA is a Google service. Its JavaScript loads from Google’s servers, and the visitor’s browser interacts with Google’s infrastructure during form validation. Google does not provide a HIPAA BAA for reCAPTCHA.
Beyond reCAPTCHA, some form plugins send submission notifications through third-party SMTP services or store submissions in plugin-managed databases with their own external sync features.
Security and Performance Plugins
Security plugins (Wordfence, Sucuri) often check visitor IP addresses against remote threat databases. The IP address is transmitted to the plugin vendor’s server. Some performance plugins (WP Rocket, W3 Total Cache) integrate with external CDNs for asset delivery, creating additional third-party request chains.
Chat and Support Widgets
Live chat plugins (Intercom, Drift, Zendesk, Tidio) load their interface from the vendor’s servers and establish a persistent connection to the vendor’s infrastructure while the visitor is on the page. The visitor’s IP address, the page they are viewing, and their interaction behavior are all transmitted to the chat vendor. None of these vendors provide HIPAA BAAs on standard plans.
Review and Rating Widgets
Plugins that embed third-party review widgets (Google Reviews, Healthgrades, Birdeye) load content from the review platform’s servers on every page render. The visitor’s IP address and page URL are included in those requests.
Themes Are Not Exempt
Everything above applies to WordPress themes as well. A theme that loads Google Fonts via a stylesheet, pulls icons from a remote CDN, includes a bundled analytics snippet, or uses an external licensing check creates the same third-party request vectors as a plugin.
Premium themes frequently bundle multiple third-party services as “features”: social sharing buttons, related content widgets, newsletter signup integrations, contact form integrations. Each is a potential external request chain the practice administrator did not explicitly choose.
The theme’s privacy policy, if it has one, almost certainly does not include a BAA provision.
The Risk Analysis Requirement
HIPAA does not prohibit the use of WordPress or third-party plugins. It requires that you understand your risk posture and document your decisions.
The Security Rule’s risk analysis requirement (45 CFR § 164.308(a)(1)) mandates that covered entities conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. A practice website that processes patient contact and appointment requests handles ePHI. The plugin inventory on that website is within scope for the risk analysis.
What this means in practice:
- Inventory every active plugin and your theme. For each one, identify whether it loads external resources or transmits data to third-party servers.
- For each third-party data flow, determine what data is transmitted and to whom. The IP address plus page URL combination is the minimum; some plugins transmit more.
- For each vendor receiving data, determine whether a BAA is available. If a BAA is not available and the data transmitted constitutes PHI, the transmission is a potential HIPAA violation.
- Document the risk level and your response. For risks you choose to accept, document the business justification. For risks you remediate, document the remediation. This documentation is what you present to OCR if a complaint is filed.
Your risk manager and security staff own this analysis. A web developer can help you identify what plugins are loading and what they transmit. The compliance determination of whether a given risk is acceptable for your organization requires people with authority over your compliance program.
What Remediation Looks Like
For plugins where the third-party data flow is not essential to the plugin’s function (fonts, icons, CDN assets), the path is straightforward: replace external loading with self-hosted alternatives. The feature is preserved, the third-party request is eliminated.
For plugins where the third-party connection is core to the feature (security services that check IP reputation, chat tools that connect to an external platform), the decision is binary: accept the risk with documentation, or replace the plugin with a HIPAA-eligible alternative or a self-hosted equivalent.
For plugins with no HIPAA-eligible alternative and no self-hosted option, the question becomes whether the plugin’s function is necessary at all. Many plugins installed by marketing agencies provide marginal value relative to their compliance exposure.
For tracking and analytics tags specifically, the remediation does not always require removing the tag. A consent layer that withholds Google Tag Manager firing until a visitor has actually consented, and that detects Global Privacy Control automatically, closes much of the consent gap without touching the rest of the plugin stack. DataCentury’s GPC Consent Manager is one option for practices staying on WordPress in the near term.
The most defensible position for a surgical practice website is a minimal plugin footprint: use only what is necessary, verify that each necessary plugin either avoids third-party requests or has a BAA-covered vendor relationship, and document the assessment.
The Static Site Alternative
The reason DataCentury builds surgical practice websites on a static architecture rather than WordPress is precisely this: a static site has no plugin ecosystem and no server-side application layer making third-party calls on behalf of visitors.
Every external resource on a static site is an explicit, deliberate choice. There is no plugin that quietly adds a Google Fonts reference. There is no theme that bundles a remote icon CDN. The full inventory of third-party requests is visible in the build configuration, not buried across dozens of plugin settings panels.
For practices that need to move off WordPress, the infrastructure guide covers what a modern static stack looks like and what it takes to migrate. For practices staying on WordPress, auditing your tracking pixels is the starting point for understanding what your current site is transmitting.
The plugin PHI risk is solvable. The prerequisite is knowing it exists.