Recalls, Insurance & Appointment Confirmations — RPC Implementation
Why This Matters
Recalls, recall types, and appointment statuses are core Type 3 features that directly drive patient reminders and schedule visibility in the Weave UI. Without correctly syncing and pushing these entities into settings, messaging teams cannot send recall reminders and offices cannot map PMS-specific statuses to Weave schedule states. Understanding the RPC and push mechanics here is essential before tackling write-backs in Type 4.
What You'll Learn
- What recalls are, how they differ from recall types, and why only two years of historical data is synced by default
- How partial vs full sync applies to recalls, including the two-year lookback window logic
- How recall types are pushed into settings via info push and consumed by the messaging team to drive reminder configuration
- How appointment statuses are fetched from the PMS and pushed into settings as a key-value map
- How the appointment status map is configured per office, including the one-to-many mapping constraint between PMS statuses and Weave statuses
- Where recall types and appointment status maps are visible in WAM and the Weave UI, and how manual settings overrides can be used for debugging
Watch Video
Lesson Summary
Recalls represent events stored in the PMS that are synced into Data Service to power Weave's recall reminder feature. Sync uses a two-year lookback window: on first run it performs a full sync from two years back, and on subsequent runs it performs a partial sync from the last sync timestamp. Recall types are a distinct entity — a key-value listing of all possible recall categories — which is pushed into settings via the info push RPC alongside appointment statuses, medical conditions, and appointment types. The messaging team reads recall types from settings to present a toggle UI to office users, who then select which recall type categories should trigger reminders. Appointment statuses follow the same push pattern: the integration fetches all possible PMS appointment statuses, pushes them into a settings key called appointment statuses, and separately maintains an appointment status map that stores the office-configured mapping from PMS status IDs to Weave schedule statuses. This mapping is one-to-many from Weave status to PMS status, but each PMS status ID must map to exactly one Weave status to avoid UI ambiguity. If no mapping is configured, appointments display as unknown in the Weave schedule UI. The current architecture pushes recall types and appointment statuses into settings rather than exposing a dedicated API, which is acknowledged as a suboptimal pattern; these values are refreshed only on SyncApp restart or when the info push RPC is manually triggered.