Integrations

One system owns the booking. The other follows.

Most integration problems in healthcare are ownership problems. Two systems both believe they hold the calendar, they drift, and somebody's afternoon is spent reconciling them by hand. QLess Health starts somewhere else: we decide which system is the system of record for a given service line, and the other one keeps in step.

QLess Health integration architecture: Epic as system of record for appointment-led sites, QLess Health as system of record for walk-in-led sites, and an independent downstream event stream to BI, CRM, and survey systems.

Two modes

Which system holds the calendar?

The answer depends on how the service line actually runs. Both modes are in production. What changes between them is the direction the appointments travel — and what the patient is allowed to do from their phone.

Appointment-led sites

Epic is the system of record

Central scheduling books everything. Creations, reschedules, cancellations and check-ins flow from Epic into QLess Health, which builds and runs the visit that follows — including multi-step visits, where one appointment becomes a chain of linked services that moves as a unit.

Appointment management stays where it belongs. Patients reschedule and cancel through your schedulers, in Epic, the way they do today. QLess Health doesn't write appointments back, and doesn't offer the patient a second place to change one.

Walk-in-led sites

QLess Health is the system of record

Epic has no concept of a walk-in — everything it holds is an appointment. So when a patient arrives, QLess Health finds the capacity, takes them into the queue, and writes a matching appointment record into Epic so the visit exists where the clinical record lives.

Here the patient's status page is live: they can leave the line, add a service, or cancel — and the cancellation is pushed to Epic with them.

One system of record per service line. It sounds like a limitation. It's the thing that stops the two calendars from disagreeing. The following system is configured with enough concurrency that it never becomes the blocker, so a booking that's valid in the system of record is never refused by the other one.

What we track

Four states, not four hundred fields.

We don't replicate the chart. We're not a second copy of your EHR and we don't want to be. Four appointment states carry everything patient flow needs — which is why the integration is small enough to reason about, and small enough to fix when something upstream changes.

Created

A new appointment appears. QLess Health builds the visit — including every step, when the visit has more than one.

Rescheduled

The time moves. The visit moves with it, as a unit, with all of its steps intact.

Cancelled

The appointment goes away. So does the visit, and any step that depended on it.

Checked in

The patient arrives and registration begins. The visit becomes live and the queue starts moving.

Service completion is next on the list — the signal that lets one step close itself and release the next without a staff member clicking twice.

How the data moves

Two paths in. One of them always works.

Polling

It's the universal path. QLess Health asks Epic what has changed since it last asked, on a cadence tuned to how far ahead the site books. A clinic scheduling weeks out doesn't need the same frequency as one booking same-day, and paying for frequency you don't need is just load on your interface.

Epic's event channel

It's the faster path, where you have it licensed and configured. It's filtered to the departments and event types that matter, so we're not drinking from your whole firehose to find the twelve appointments we care about.

We don't promise a millisecond. What we'll tell you in discovery is the cadence your booking horizon actually needs, and then hold to it.

The EHR adapter

Why the second implementation costs less than the first.

Most vendors integrate by writing custom code per customer, or by asking you to stand up middleware and maintain it forever. We built the variation into the platform instead. Three layers of mapping, configured rather than coded:

API mapping

Which call does this action use in this system, and what does that system need back before it will accept it.

Field mapping

Your field name, our field name. Set once during implementation, not rediscovered every time something changes.

Value mapping

Your department codes and visit types, translated into our locations and services. The layer most integrations skip and then hard-code.

No interface engine to buy. No integration consultancy on retainer. No per-transaction fee sitting between you and your own appointment data.

Downstream

Everything downstream is yours, EHR or not.

The EHR integration is one half of the picture. The other half doesn't depend on it at all: QLess Health publishes its own events — a patient checked in, a wait time moved materially, a visit completed, a survey came back — and anything you run can subscribe.

Our Salesforce integration is built on exactly this, and has been in production since 2025. Your warehouse, your BI tool, your survey platform and your CRM all consume the same stream. Publish once, subscribe as many times as you like.

This is also the part that runs on day one, before the EHR work is finished — which makes it a useful place to start.

Staff experience

Stop copying phone numbers between systems.

At most healthcare front desks, staff spend a measurable fraction of the day moving the same data between two screens by hand.

When a patient is summoned for service, QLess Health opens the right record automatically — picture-in-picture, on the staff member's screen. No copy-paste, no manual lookup, no alt-tabbing to find the appointment that's already been found.

It's the least glamorous thing on this page and one of the most defended. Every lookup you remove is time back at the desk, and a keystroke that can't be got wrong.

The most boring competitive advantage in healthcare access: not making your staff copy phone numbers between systems.

What we'll need from you

The honest version of the effort estimate.

Integration timelines slip for one reason far more often than any other, and it isn't the vendor's code. It's waiting on access. We'd rather tell you now than discover it in week six.

A test environment

Somewhere we can exercise the integration against your real configuration before it touches a patient.

Your field and value mappings

We can't guess what your department codes mean. Somebody who knows your build needs to sit with us for a few sessions — this is the single biggest determinant of how fast you get to value.

Event channel configuration, if you're using it

Licensed, enabled, and filtered to the right departments. If that's not available, polling covers you and nothing about the project stops.

Scope, plainly

Epic today. The adapter is built for what comes next.

We're doing Epic properly before we do anything else. Every EHR exposes a different set of capabilities, and claiming seven integrations when six are theoretical is how implementations turn into disputes.

The adapter exists precisely so the next vendor is a configuration exercise rather than a rebuild — and we're mapping what each of the majors can and can't support before we commit to a date on any of them.

If you're on something else and you want to be next, that's a conversation worth having early.

Talk to us about your stack

Every connection, without exception: HIPAA-aligned with a BAA in place, TLS 1.3 in transit, encrypted at rest, and audit-logged end to end. SOC 2 Type II attested annually since 2024 with no gap in coverage.