Patient-specific workflows start with patient identification.
A scheduling workflow can continue only after Blackstar Systems' Orbit resolves the patient and receives real availability from the connected system, such as Open Dental. A partial identity match, ambiguous patient result, or unavailable slot stops the workflow instead of becoming a guessed booking.
Scheduling only starts once two things are true: the patient has been identified, and the connected system has returned real availability for that specific request. Orbit does not proceed on a guess in either direction. An unresolved patient, an ambiguous match, or an empty availability response is treated as a stop, not a placeholder to work around.
Key Facts
- Patient identity must resolve to a specific record before scheduling continues.
- Availability comes from the connected system for the configured provider, operatory, and duration.
- A slot is offered only when the system returns it for that request.
- Both patient and slot are checked again before the appointment is submitted.
A booking depends on both the right patient and the right slot.
A booking involves two claims agreed on at once: this patient, and this provider at this time. Orbit is careful about both before it lets a workflow continue. On the patient side, that means resolving a caller to a specific, identified record using the details a workflow collects, not proceeding on a name alone or a rough match that could belong to more than one person.
On the scheduling side, it means asking the connected system what's open, for the actual provider, operatory, and duration the workflow requires, rather than assuming an hour is available because it typically would be. Both checks have to clear before a time is offered to the caller, and both are re-checked, not assumed to still hold, at the moment the appointment is submitted.
Identity and availability clear before booking.
A booking only proceeds after the required identity and availability checks are satisfied. First, Orbit collects the identifying details a workflow requires and sends them to the connected system to resolve a specific patient record. A clean single match lets the workflow continue; more than one plausible match, or no match at all, does not.
Second, once a patient is resolved, Orbit requests availability from the system of record for the specific provider, operatory, and duration the workflow calls for. The times it can offer a caller are only ever the times that specific request returns, not a general sense of when the practice tends to be open. Third, a booking is only submitted once both the patient and the specific slot have been confirmed as valid in that same conversation, since either one can change between when it was first checked and when the caller is ready to commit.
Orbit does not book from partial identity or assumed availability.
Orbit does not create or select a patient record from a partial or ambiguous match; an unresolved identity stops the workflow rather than proceeding on a best guess.
It does not offer a time that wasn't returned by the connected system's own availability check, and it does not assume a slot is still open after checking it once.
Cancellation and rescheduling are separate Open Dental workflows where enabled for a deployment; they are not part of the new-appointment identity and availability sequence described on this page.
Integration-specific detail, such as exactly which fields identify a patient for a given practice-management system, lives on that system's own integration page, not here.
Integration-specific mapping for a live deployment lives on the Open Dental integration page, not here.
Wrong identity or wrong availability creates a false success.
Getting the patient wrong means writing information against the wrong record. Getting availability wrong means telling a caller they have an appointment that doesn't exist. Both failures are worse than simply being slow, because they look successful right up until someone discovers otherwise. Requiring a resolved identity and a system-confirmed slot before anything moves forward is what keeps a booking from becoming a confident-sounding mistake. For a practice, that mistake would otherwise surface later as a double-booked chair, a record with someone else's history attached to it, or a front desk untangling a call that sounded fine at the time.
Follow the connected controls.
See identity and availability resolved live.
Review how patient lookup and scheduling work on the Open Dental integration.