The request was familiar. “Can you add a patient portal to our website?” The clinic had spent two years frustrated with their existing portal, hosted by their EHR vendor. The portal was clunky. Patients complained. The clinic wanted a portal that lived on the clinic’s own site, with the clinic’s branding, that worked the way the clinic wanted it to work. A patient portal on your website sounds like a feature; it is actually a separate product with separate compliance.

The answer was no. Not because the work was technically impossible. Because the work was the wrong work. A patient portal is not a website feature. It is a regulated clinical system that touches every piece of HIPAA scaffolding the clinic has, and bolting it onto a WordPress site is a category mistake.

What a patient portal actually is

A real patient portal does at least these things:

Authenticates patients with multi-factor authentication tied to their identity, not just an email.
Displays medical records sourced from an EHR, including labs, immunizations, growth charts, visit notes.
Accepts and tracks secure messages between patient and provider, with audit trails on every read and reply.
Manages prescription refill requests and feeds them into the clinic’s prescribing workflow.
Processes appointment requests against the actual clinical calendar, not a marketing widget.
Handles payment for balances, with PCI compliance and reconciliation to the clinic’s billing system.
Retains every interaction in a compliant audit log that can be produced for an investigation.

None of these are website features. All of them are clinical systems. The portal is a thin user interface on top of an EHR or a practice management system. The hard work is not the interface. The hard work is the integration, the security posture, the audit logging, the regulatory compliance, and the operational support for when the system misbehaves at 9 PM on a Sunday.

What happens when you try a patient portal on your website

Every time a clinic has asked me to build a portal on top of their marketing site, the conversation has ended one of two ways. Either the clinic recognizes the scope and we pivot the project. Or somebody builds it anyway, and within 18 months the clinic has a partial portal that handles two of the seven jobs above, leaks PHI in ways nobody planned for, and has no path to compliance for the bits it does handle.

The leak modes are predictable:

The login system stores password hashes in a WordPress database that was never designed for PHI-adjacent access controls.
The secure messaging is implemented with a generic contact form that emails the office, sending PHI through SMTP in plaintext.
The records display pulls data via an API key that lives in a plugin’s options table, which any plugin admin can read.
The audit log is the WordPress action log, which captures “user logged in” but not “user viewed record X.”
The whole thing runs on shared hosting where the clinic does not control the operating system, the database, the backup encryption, or the access policies.

The portal looks like a portal. It functions, technically. It also creates a HIPAA exposure that the clinic did not have before, and that no plugin update will fix.

What the website should do instead

The website’s job, with respect to the portal, is three things:

Explain what the portal is. In language the parent uses. “Sign in to message your doctor, view your child’s records, request refills.” One paragraph. Maybe a short list of features.
Link to the actual portal. Hosted by your EHR, your practice management vendor, or a purpose-built portal product. The link goes to their authenticated domain, not to a page on your site.
Tell the parent who to call when the portal misbehaves. The portal will misbehave. The vendor’s support line is rarely the right first call. The clinic’s front desk needs to know how to triage portal issues.

That is the whole responsibility. Three things, one page. Maybe a footer link too. The website is the doorway. The portal is the building. You do not need to rebuild the building inside the doorway.

The branding question

The most common reason clinics ask for a portal on their own site is branding. The vendor portal looks generic. The vendor portal has the vendor’s logo in the corner. The vendor portal has stock fonts that do not match the clinic. The vendor portal feels like it belongs to somebody else, and patients sometimes get confused about whose system they are signing into.

That confusion is real, but the fix is not building your own portal. The fix is asking the vendor whether their portal supports custom branding. Most modern portal products do, and most clinics have never asked. A few hours of configuration work, swapping logos and colors, often closes 80 percent of the perceived gap. The other 20 percent is usually accepting that some clinical software does not need to look like the marketing site, because it serves a different purpose.

The honest tradeoffs

There is a legitimate version of the dissatisfaction. EHR vendor portals are often not great. They are slow, they are dated, they have bad mobile experiences. The honest options are:

Switch EHRs. Genuinely the right answer in some cases, terrible in others. A multi-year project.
Switch portal vendors while keeping the EHR. Some EHRs support third-party portals via FHIR integrations. Investigate before assuming.
Accept the portal as it is, and let the clinic website be a clean, friendly doorway into it.
Build a custom portal as a genuine clinical software project. Not a website feature. Six-figure budget, dedicated security review, ongoing maintenance team. Real clinics do this. Most clinics should not.

The wrong option is to ask the website agency to build a portal. The website agency is not the right team. The website is not the right surface. The result will be a thing that looks like a portal and is not one.

The clinic that asked me at the top of this post took option three. The website got a clean portal page that explains what the portal does, links to the EHR’s login, and tells the parent who to call when it does not work. The frustration with the portal did not disappear, but it stopped being a website problem. The website got smaller and clearer. The portal stayed regulated and audited where it belongs.

The website’s job is to make it easy to reach the clinic. The portal’s job is to be the clinic, online, for established patients. Different jobs, different tools, different teams. See the related point about PHI in notification emails, and our plans for how we scope clinic websites around this boundary.