SyncApp's Internal Flowchart
Why This Matters
The SyncApp flowchart is the algorithm you're working with every day. Understanding full vs. partial sync, why hashes are stored, and how per-entity loops work will make you a significantly better debugger and developer.
What You'll Learn
- The full SyncApp flowchart: fetch → serialize → transform → store hash → send to Data Service
- What full sync vs. partial (delta) sync means and when each is used
- Why SyncApp stores a hash of the transformed data indexed by entity ID
- How the hash comparison enables change detection to avoid sending unchanged data
- Why hash-based deduplication is especially important for on-prem PMSs that must always do full fetches
- The per-entity loop: each entity type (patients, appointments, providers) goes through this flow independently
Watch Video
Lesson Summary
SyncApp's flowchart: Start → for each entity → decide full or partial fetch → fetch data from PMS → serialize into Weave format → store hash of transformed data (keyed by entity ID) → compare hash to previously stored hash → if changed, send to Data Service; if unchanged, skip. On first onboarding, full sync fetches all data. Thereafter, partial sync fetches only recently modified records. However, some PMSs (especially on-prem) can't support partial queries, so SyncApp always fetches everything — but uses the hash comparison to only send what actually changed to Data Service, keeping network traffic lean.