Search "patient portal software" and you'll find two categories of results: enterprise EHR suites priced for hospital systems, and generic booking widgets (Zenoti, Podium, Prospyr, Vagaro) that were built for salons and gyms and happen to also work for a med spa. Neither is built for the businesses actually caught in the middle: independent clinics, IV and hormone-therapy practices, telehealth-adjacent operators, and multi-location wellness brands that need something more than a calendar, but don't need (or can't afford) a full hospital-grade EHR.
We build the thing in the middle. This is what we've learned it actually needs to include — and what most "patient portal" software on the market quietly skips.
The pattern we keep finding
Across a run of Utah longevity, IV-therapy, and hormone-optimization clinics we looked at recently, the same gap showed up over and over: real clinical businesses, real patient volume, real providers — running on booking software built for a completely different kind of business. A hormone-therapy practice offering testosterone optimization and IV infusions was routing every booking through Zenoti, a spa and salon platform, with no separation between a Botox touch-up and a clinical intake that should legally involve health history and lab review. A five-location IV clinic had each location running its own separate Vagaro profile with zero shared patient record between them. A practice with a genuine EHR (Elation) still bounced patients to a generic, off-brand booking page with no online intake at all.
None of this is a design problem. It's an infrastructure problem: the tools these practices are running on were never built for HIPAA-aware clinical intake, multi-location patient records, or telehealth delivery — they were built to book a haircut.
What an actual patient portal needs to do
1. Real, HIPAA-aware intake — not a Google Form
Health-history intake needs encryption at rest and in transit, access logging, and a real distinction between what a receptionist can see and what a provider can see. A form builder that happens to be "technically" behind a login isn't the same thing as a system designed around who's allowed to see what. We built this into Topp Health's primary-care/telehealth platform: real HIPAA intake forms tied to provider access, not a generic form embed.
2. Scheduling that understands your actual business, not a generic calendar
A booking widget built for a spa treats every appointment the same: pick a service, pick a time, done. A real clinical business usually has constraints a generic calendar can't express — which provider can perform which service, how long a first-visit intake actually takes versus a follow-up, whether a service needs a specific room or piece of equipment, and how that changes across multiple locations. For Elyxion, an IV therapy and functional-medicine practice, that meant building scheduling and client health records that work across multiple locations as one system, not five separate calendars that happen to share a brand name.
3. Telehealth that's actually built in, not marketed and missing
More than one practice we looked at markets "telehealth available" on their homepage with no actual delivery mechanism anywhere on the site — no video integration, no virtual intake, nothing beyond a phone number. If you're going to offer it, the portal needs to actually deliver it: video visits, virtual intake forms, and a record that ties a telehealth visit to the same patient history as an in-person one. We built full telehealth integration into Topp Health's platform for exactly this reason — not as an add-on, but as a first-class part of how the practice runs.
4. A provider-facing system that's actually usable, not an afterthought
Most of the gap we see isn't visible to patients at all — it's what happens after a booking. Does the provider have a real dashboard, or is a scheduling change three phone calls and a sticky note? For Renew You, a wellness and aesthetics practice, that meant a full patient portal paired with real provider and scheduling management on the backend — not just a pretty booking page with nothing behind it.
5. Compliance infrastructure that goes beyond "HIPAA-compliant" as a marketing phrase
For businesses where compliance isn't optional — clinical labs, testing services, anything involving chain of custody — the bar is higher than a patient portal. We built Precision Mass Spec a custom LIMS (laboratory information management system) with real chain-of-custody tracking, because "HIPAA-compliant" wasn't a strong enough claim for what the business actually needed to prove.
What this actually costs, and why the range is so wide
Scope varies enormously depending on what's actually being replaced. A small clinic portal — real intake, provider-aware scheduling, one location — is a meaningfully different build than a full platform with telehealth, EHR integration, and multi-location support for a practice running five clinics on five disconnected systems. We scope every build around what's actually needed, not a fixed package, because the honest answer is that a single-provider clinic replacing a booking widget and a five-location practice replacing an entire disconnected back office are not the same project.
The real question to ask before building (or replacing) a patient portal
Not "does this have a HIPAA badge on the pricing page." Ask instead: if a patient calls asking where they are in a 12-month treatment protocol, can any staff member answer that from one system — or does it take checking two or three? If the answer is more than one system, the software isn't actually doing its job, no matter how compliant its marketing copy claims to be.
FAQ
Do we need a full custom EHR, or does a patient portal cover it?
Most independent clinics don't need to build or replace a full EHR — the real gap is almost always the patient-facing and scheduling layer sitting on top of (or instead of) one, plus the intake and communication pieces that a generic booking tool was never built to handle.
Can this integrate with an EHR we already use, like Elation or Tebra?
Yes — the goal is almost never to rip out a working clinical EHR, it's to stop bouncing patients off-brand to a generic booking page that isn't connected to it.
What about multi-location practices?
This is usually where the gap is worst — most booking tools treat each location as its own separate account with no shared patient record, which is exactly the problem Elyxion's build was designed to solve.
Is telehealth actually feasible for a small practice to build in?
Yes, and it doesn't need to be a separate product — it should be one part of the same patient record and scheduling system a patient already uses for in-person visits.
How is pricing structured?
Scope-quoted, based on what's actually being replaced — not a fixed tier. A single-location portal and a five-location platform with telehealth and EHR integration are genuinely different projects.
What if we're not sure what we actually need yet?
That's normal — most practices know something isn't working before they know exactly what the fix looks like. That's what a real scoping conversation is for.
If your practice is running clinical intake through the same system you'd use to book a haircut, that's worth a conversation. See what a real Clinic OS build looks like, or get in touch to talk through what your practice actually needs.