Telehealth Scheduling: State Licensure, Time Zones, and Provider Matching
Booking looks like a solved problem until licensure rules and multi-state providers enter the picture. What the logic actually has to handle.
Booking a slot is a solved problem. Every calendar app does it.
Telehealth scheduling is a different problem wearing the same clothes, because the answer to "can this patient see this provider at this time?" depends on things a calendar knows nothing about.
Get it wrong and you get a booked consult that has to be cancelled, which is worse than never offering the slot.
The rule that shapes everything
In the US, care is generally regulated by the state the patient is located in at the time of the visit, not the state the provider sits in.
That means a provider licensed in Texas and California can see patients physically in Texas and California. A patient who lives in Texas but is visiting family in Oregon that week is, for this purpose, an Oregon patient.
Everything else in this article follows from that one fact.
Worth saying clearly: the specifics vary by state, by license type, and by what's being prescribed, and they change. Your clinical and legal team owns those rules. Your job on the engineering side is to make the system enforce whatever they tell you, and to make it easy to change when the rules move.
What the availability query really has to answer
A patient asking "what times can I book?" is really asking a question with several layers:
- Which providers hold an active license in the patient's current state?
- Of those, which are credentialed for this specific service?
- Of those, which have open calendar time?
- In the patient's time zone, not the provider's?
- With enough lead time for whatever prep the visit requires?
- And, for controlled substances or specific treatments, which providers are permitted to prescribe this, in this state?
Skip any one of those and you'll surface slots that can't actually be honored.
The mistake most teams make is treating licensure as a filter applied after fetching availability. It has to be part of the query itself, because a slot that isn't legal isn't available.
Model licensure as data, not as code
The tempting shortcut is hardcoding rules. Don't.
Licenses expire. Providers add states. A state changes what it permits. If those rules live in application code, every change is a deployment, and eventually one gets missed and you book something you shouldn't have.
Instead, keep a table of provider licenses with the state, license type, effective date, and expiry. Then:
- Availability queries read from it, so an expired license silently stops producing bookable slots
- Something warns you before expiry, at 90, 60, and 30 days, because a lapsed license discovered on the day is a scheduling emergency
- Changes are an operations task, not an engineering ticket
This is boring infrastructure that prevents a whole category of expensive problems.
Ask where the patient is, carefully
You need the patient's current location, and you cannot reliably infer it.
IP geolocation is wrong often enough to matter — VPNs, mobile carriers routing through another state, corporate networks. Their profile address is where they live, not necessarily where they are.
So ask, at booking: "Which state will you be in for this visit?" Then store the answer with the appointment, because that's the record you'll want later.
Also handle the change case. Someone books for next Tuesday from Texas and travels to Oregon on Monday. A confirmation reminder that asks them to confirm their state is a cheap safeguard.
Time zones will bite you
The classic bugs, all avoidable:
- Store everything in UTC, convert at display time. Never store a local time and hope.
- Display in the patient's time zone, clearly labeled. "2:00 PM CT" prevents more no-shows than any reminder.
- Handle daylight saving transitions. Appointments booked before a DST change and occurring after it are where naive implementations shift by an hour. Arizona and Hawaii don't observe it, which breaks assumptions that "US state implies DST."
- Reminders honor the patient's zone too. A reminder arriving at 4am is worse than no reminder.
Provider matching, beyond availability
Once you're past the legal filter, matching is a product decision.
Simplest version: first available. Fast, and fine for one-off consults.
For ongoing care, continuity usually matters more than speed. Seeing the same provider improves outcomes and retention, so weight the patient's previous provider heavily even if it means a later slot. Offer the choice: "Dr. Reyes on Thursday, or someone else today."
Other factors worth supporting: language, specialty within the service, and gender preference for sensitive care. All of these should be soft preferences layered on top of the hard licensure filter, never the other way around.
Cancellations, no-shows, and the buffer
Practical details that determine whether the schedule works in reality:
- Buffer between appointments, because notes take time and consults run long
- A cancellation window with a clear policy the patient saw before booking
- Waitlist backfill, so a cancelled slot gets offered to someone waiting rather than evaporating
- A no-show policy that's applied consistently, and that accounts for patients who couldn't connect due to a technical problem on your side
That last one matters more than it sounds. Charging a no-show fee to someone whose video call failed generates a support ticket, a chargeback, and a bad review, all from one incident.
Test the awkward cases
Before launch, run these deliberately:
- Patient in a state where no provider is licensed — do they get a clear explanation, or an empty calendar with no message?
- A license expiring between booking and appointment date
- A booking across a daylight saving transition
- A patient who changes state after booking
- Every provider fully booked — is there a waitlist, or a dead end?
The empty-calendar case is the one that gets shipped broken most often. A patient who sees no available times and no explanation assumes your product is broken and leaves.
We build scheduling, provider routing, and intake for US telehealth companies, working to the rules your clinical and legal team define. See how.