How recall recovery works across ClearDent, Tracker, and Oryx

A recall report is a list. Recall recovery is a controlled sequence of decisions:

• Who is genuinely lapsed?
• Who must not be contacted?
• What outreach is due next?
• Did the patient book—and can that booking be witnessed in the dental software?

Those questions stay the same across a practice. The database path does not.

We checked the current Xona implementation on August 4, 2026. ClearDent, Tracker, and Oryx reach the same recall workflow through three different read paths. The useful product boundary is not “one magic query for every PMS.” It is a shared contract that begins after each system has produced a trustworthy cohort.

The common contract

Xona normalizes each eligible patient into an account-scoped recall enrollment with a small set of fields: the patient handle owned by that integration, last completed visit, months-lapsed bucket, reachable phone, and limited display context for the practice.

The current cohort buckets begin at 13 months since the last completed visit: 13–18 months, 19–24, 25–36, and 37 months or more. That is a product rule, not a universal clinical definition. A practice may use different recare intervals, service definitions, or exclusions, so fit review still matters.

Once a patient enters the normalized workflow, the safety rules stop caring which PMS supplied the row:

1. Keep every record inside the clinic’s account scope.
2. Re-check patient- and phone-level suppression before contact.
3. Stop outreach when a positive PMS lookup finds an upcoming appointment.
4. Credit a recall booking only when the system can witness it—not when a row merely disappears from a report.

The last rule is the one most recall spreadsheets miss.

ClearDent: a direct query through the clinic tunnel

For ClearDent, Xona runs a read-only SQL query through the clinic’s existing secure tunnel. It finds each active patient’s most recent completed or seated appointment, calculates months since that visit, chooses the best available phone number, and drops rows that are still inside the active cycle or cannot be reached by the configured channel.

One implementation detail changed after live checks: some real visits remain marked “Seated” rather than “Completed.” Ignoring them can make a recently seen patient appear older than they are. The current query treats both states as evidence that the visit happened.

The important limitation is explicit: this v1 cohort uses the most recent completed visit, not a universal hygiene-service code that behaves identically in every ClearDent installation. That is why a clinic-specific fit check comes before activation.

Tracker: the same question, different proof of a completed visit

Tracker is also queried directly through the clinic tunnel, but its completion evidence lives in different tables and fields.

A Tracker appointment counts as a completed visit only when its status is a booked state, it was not cancelled, and the patient has a checkout timestamp. That last check matters: treating every non-cancelled appointment as a visit can admit no-shows and office cancellations into the history and move the patient’s “last visit” to a date when no visit occurred.

The output is the same normalized patient shape. The query is not.

Oryx: an API-fed mirror for the cohort scan

Oryx is cloud-hosted. Its API can answer patient-level questions, but the recall workflow needs a reliable bulk view of completed visits.

Xona builds a tenant-scoped mirror in its own database instead. The first recall scan bootstraps the history through the Oryx API. Later scans attempt to refresh a rolling recent window before rebuilding the cohort, so newly completed visits can remove a patient from the lapsed set without repeating the full history pull every time. If that incremental refresh fails, the current worker logs the failure and continues from the existing mirror; the scan must then be treated as potentially stale rather than described as fully refreshed.

The mirror is an implementation detail, not a second source of truth. Oryx remains authoritative; the mirror exists to make the bulk cohort query resumable and reviewable.

A cohort exit is not a booking

This is the most important shared rule.

A patient can leave a lapsed cohort for several reasons. Data may be corrected. A contact record may become inactive. A new completed visit may finally arrive. None of those events proves that the recall outreach created a future appointment.

Xona uses a separate booked-witness pass. It asks the PMS a narrower question: does this patient now have an upcoming, non-cancelled appointment?

• If outreach already occurred, a positive lookup stops the sequence and records a witnessed recall booking.
• If the patient had not been touched, the lookup still stops outreach, but the booking is not credited to Xona.

The same check runs immediately before a due outreach step as well as in a daily sweep. That closes the dangerous window where a patient books in the morning and an old recall queue calls them that evening.

Where the human boundary stays

Supporting three read paths is not the same as claiming universal PMS support. Database schemas vary by installation. Practice rules differ. A correct cohort can still be a poor outreach plan if the exclusions, message, cadence, escalation path, or staff ownership are wrong.

The safe rollout is therefore specific: verify the integration, preview the cohort, confirm suppressions and contact rules, then observe the first outreach and its booked-witness results. Unsupported systems get a fit review, not a promise that a generic export is equivalent.

That is the architecture in one sentence: the PMS decides how Xona reads the history; the recall contract decides what Xona is allowed to do with it.

See the recall recovery workflow or model your own cohort with the recall calculator.