Public online appointment booking for healthcare practices running AthenaOne, Epic, Cerner, Dr Chrono, or any other closed EHR. We bridge the gap between the EHR as the system of record and a clean, branded, self-serve booking experience for your patients — with multi-location support, per-provider booking pages, and theme matching that looks native to your site.
The Problem Medical Practices Keep Running Into
So here’s the situation. You run a medical practice. You’ve invested in a good EHR — AthenaOne, Epic, Cerner, Dr Chrono, something enterprise-grade. It manages your patient records, your billing, your clinician schedules. Everything works, internally.
Then a patient lands on your website and wants to book an appointment. And you discover something that catches most practices off guard: your EHR doesn’t actually support public online booking. Not directly. Not in a way you can drop onto a marketing site.
AthenaOne’s booking APIs are built for in-portal use. Patients book from inside the athenahealth patient portal after they’ve already been registered as a patient. That’s great for existing patients. It’s useless for a new visitor who just Googled “GP near me”, clicked your site, and wants to book right now without calling.
The front desk takes the call. They book it into the EHR manually. That call takes 4 to 8 minutes. Multiply it by a hundred patients a day across seven locations and you have a staffing problem.
The Standard Workaround (And Why It’s Not Enough)
The market’s answer is third-party booking platforms like NextPatient, Zocdoc, and DocASAP. They integrate with the major EHRs and expose public-facing booking widgets. You embed the widget, patients book, the appointment syncs back into the EHR. Done, in theory.
In practice, the off-the-shelf widgets come with real limitations:
- Selection is usually location-only. Patient picks a clinic, sees whoever’s available. If your practice has 30 providers across 7 locations and patients search by provider or specialty first, this is the wrong flow.
- The widget ships with a fixed theme. Vendors rarely expose a theming API. You’re stuck with white cards, blue buttons, and a sans-serif font that doesn’t match your site. On a carefully designed practice site, this looks like a third-party bolt-on. Because it is.
- No deep-linking per provider. You can’t share a direct link to “book with Dr Ahmed” from his bio page. Patients have to go through the full selection flow every time.
- No individual provider pages that feel like yours. The vendor’s widget is one page. That’s it.
What We Build
We start with the best-available vendor integration (usually NextPatient for AthenaOne) and we extend it until the result looks and behaves like it was built native to your site. Here’s what that means in practice:
Tab-based multi-mode selection — patients can choose how they want to find care. By Location shows a clinic dropdown. By Provider gives them a keyboard-navigable typeahead filtered by name and location. By Specialty or By Zip Code handles “I just want a dermatologist near me” intent. Three distinct flows, one widget, all converging on the same underlying booking infrastructure.
Individual provider booking pages — every clinician on your team gets their own deep-linkable booking URL. A patient can click a link from a Google search, a newsletter, an email signature, or the provider’s bio page and land straight in that provider’s booking flow. No extra clicks.
Runtime theme override — since vendors like NextPatient don’t expose theming APIs, we inject the vendor’s JavaScript dynamically and then run a polling-based theme override loop. It walks the injected DOM, reads computed styles, and rewrites background colors, text colors, borders, and button states to match your brand. We also run a content-readiness detector that holds a clean loading state until the widget’s DOM is populated, so patients never see a jarring theme flash.
Multi-location deployment — every clinic, every provider roster, every opening-hours rule. We’ve wired in 7-location deployments with per-location provider rosters and location-specific booking logic.
Mobile-first responsive — the entire flow collapses cleanly to a stacked column on small screens, because more than half of healthcare searches happen on a phone.
Vendor Coverage
AthenaOne (athenahealth) — primary integration path is NextPatient. We’ve shipped production deployments on this stack.
NextPatient.co — deep customisation, theme overrides, selection flow extensions, per-provider deep-linking. Proven on multi-location practices.
Epic MyChart — patient portal deep-linking and open-booking API integration where your Epic license includes it.
Cerner — similar integration patterns via their public booking endpoints and third-party layers.
Dr Chrono — public booking via their API and Zocdoc-style third-party widgets.
Custom or legacy EHRs — if it has an API, we can usually build a custom public booking layer on top of it. If it doesn’t, we can sometimes work with a middleware booking platform that does.
Compliance and Privacy
The integration layer we build doesn’t collect, store, or transmit Protected Health Information. All patient data flows directly from the patient’s browser to the booking vendor and into the EHR. We keep our scope free of PHI handling, which means we stay out of your HIPAA compliance surface area while the vendor and your EHR provider cover their respective ends with BAAs.
We document the data flow explicitly as part of every deployment so your privacy officer has the clear answer they need.
Why Call Us Instead of the Vendor
Because the vendor will tell you what their widget does today, not what your practice actually needs. The vendor won’t build you a multi-mode selection UI, because that’s not their business. They won’t override their own theme to match your brand, because the default stylesheet is shared across all their customers. They won’t build 30 individual provider pages, because they ship one widget and that’s the product.
We do the bridge work. We take the vendor integration, extend it where it falls short, and ship the result as part of your site — not as a third-party bolt-on that clashes with everything around it.
See our All Health Medical Group public booking integration for a worked example.