Appointment Status Mapping, Push Types & Lasting Times
Why This Matters
Appointment status mapping, push types, and lasting times are foundational to how SyncApp tracks sync state and exposes write-back capabilities to other Weave teams. Understanding these mechanics is essential for debugging stale data, misconfigured status mappings, and write-back permission errors. Insurance sync follows the same core patterns and is a required Type 3 entity.
What You'll Learn
- How the appointment status map is generated from office configuration and consumed at runtime
- What lasting times are, where they are stored, and how they drive partial/incremental sync windows
- How the SetAppointmentStatus RPC works and which teams call it (Schedule and Messaging)
- What the allow_appointment_writebacks boolean flag controls and what error it produces when false
- How simplified wrapper RPCs (confirm, cancel) are being introduced on top of the existing status RPC, including AI-driven motivation
- How insurance data is synced (full sync via SQL query in this integration), how primary and secondary insurance are stored, and how the verification flow works
- Why Postman collections should be committed to the SyncApp Adhoc repo and kept up to date
Watch Video
Lesson Summary
The appointment status map is generated from office-level configuration and determines how PMS statuses map to Weave statuses; the push type mechanism triggers the GetAppointmentNewStatuses method that populates this map. Lasting times are stored per entity type in WAM settings and record the timestamp of the last successful sync; on the next partial or incremental sync run, SyncApp reads this value to determine from which point in time records need to be fetched. The SetAppointmentStatus RPC accepts an appointment ID plus status details and is called by both the Schedule team (via UI) and the Messaging team (when a patient replies to an automated confirmation text). A boolean flag called allow_appointment_writebacks gates all status changes; if false, the RPC returns an appointment writebacks not enabled error. This flag is surfaced in WAM settings under confirm-to-confirm and can be toggled from the office UI, with WAM reflecting the change immediately on refresh. Simpler wrapper RPCs for confirm and cancel are being introduced so callers — including AI agents — only need to pass an appointment ID. Insurance is a Type 3 entity synced periodically via full sync; in the OpenIntel integration this is done through a generic read-only SQL query rather than a paginated REST API, which is why no partial sync is implemented for that specific case. The transformation layer extracts both primary and secondary insurance and stores them as a single insurance object in the Weave database. Insurance verification (manual or automatic) is handled by a separate RCM/insurance team using a third-party API; the Integrations team is responsible only for pulling and storing the raw insurance data. Postman collections for all integration APIs should be committed to the SyncApp Adhoc repo so teammates can use them directly during debugging without reconstructing requests from source code.