Drawing the Line Between "Presentation" and "PHI" in a Healthcare Platform Rebuild
Case Study · Platform Architecture / Compliance
A healthcare communications platform serving government and public-sector customers (state/county health departments, VA facilities)
The situation
A healthcare communications platform was mid-rebuild on WordPress — the marketing site needed to support customer-facing intake: support requests, account questions, content requests. The rest of the platform (a Salesforce-based customer portal, a DAM, a digital signage system) was still being stood up.
The instinct on the table: let the marketing site collect some of that intake data directly, since the “real” system wasn’t ready yet.
Their security consultant flagged the risk before it became a launch-blocker: this platform serves healthcare organizations, which means even a simple support form could touch PHI. Government and healthcare buyers evaluate vendors on exactly this kind of data-handling discipline. Getting it wrong isn’t just a technical risk — it’s a sales risk.
The question that actually needed an answer: can WordPress ever be trusted to touch this data, even temporarily, even as a stop-gap?
What I found
Before answering, I verified the actual constraint instead of assuming one. The assumption on the table — that the hosting platform’s higher tier offered HIPAA-eligible infrastructure — turned out to be wrong on direct vendor confirmation. No tier of that host is HIPAA-eligible, and it can’t sign a BAA. That single fact changed the whole design.
Meanwhile, the platform’s CRM (Salesforce Health Cloud + Shield) does offer a BAA and is built for exactly this. So the real question wasn’t “how do we harden WordPress” — it was “how do we make sure WordPress never needs to be hardened for this in the first place.”
The rule that did the design work
WordPress is a presentation and marketing layer only. No customer data or PHI is ever collected, stored, or logged on WordPress or its hosting infrastructure — not even temporarily, not even as a quick stop-gap.
In practice:
- Support and account-request forms were built as native CRM forms (Web-to-Case / Web-to-Lead), embedded into WordPress via HTML widgets — but the submission talks directly to the CRM’s endpoint. WordPress renders the form and never touches the payload.
- No server-side logging, no database writes, no email-as-CSV workarounds — even under deadline pressure to ship before a hard migration date.
- The cookie/consent layer was scoped correctly too: consent tooling is a cookie-law control, not a HIPAA control — and the two stayed explicitly separate in every conversation with the security consultant.
- Spam/bot protection was added at the form layer without adding friction that pushes real users into abandoning the form.
The result
The platform shipped its customer-facing forms on schedule, with a data flow their security consultant actually signed off on — because the architecture was defensible by design, not by exception.
More useful than the launch itself: the team walked away with one clean, repeatable rule — nothing customer-identifiable ever touches WordPress — that now scopes every future integration decision without a fresh security review every time.
Why this matters if you're evaluating a platform partner
This is the kind of decision that’s invisible when it’s done right and expensive when it’s done wrong. “It’s just a stop-gap, we’ll clean it up later” is how healthcare and government vendors end up with data-handling debt that surfaces in a security audit six months post-launch — not during the sales cycle, when it’s cheap to fix.
The job isn’t just building the form. It’s knowing which system is allowed to touch the data before a single field gets built, and verifying vendor claims directly instead of taking them at face value.