Academy / Week 3 / Type 3 Integration Implementation / Recalls, Insurance & Appointment Confirmations — RPC Implementation

Recalls, Insurance & Appointment Confirmations — RPC Implementation

Lesson 14.1⏱ ~10 minWeek 3

💡 Why This Matters

These three entity types are what separates a Type 2 from a Type 3 integration. Knowing exactly which RPCs to implement and what the data structures look like for each is the hands-on starting point for any Type 3 implementation ticket.

🎯 What You'll Learn

  • What recalls are: recurring care reminders synced from PMS (dental cleanings, vet vaccinations, optometry)
  • What recall types are: the categories of recalls (annual, semi-annual, etc.) — a separate entity to sync
  • How insurance is structured: primary vs secondary, coverage details, policy holder info
  • What appointment confirmation status means and how it maps to auto-confirmation in Weave
  • The three code areas per entity: API (fetch), entity (transform), RPC method (sync)
  • Using OpenDental as the reference integration for implementation patterns

Watch Video

Open in Google Drive 💡 Open in Drive for AI-powered transcript search

📋 Lesson Summary

Three entities define Type 3 functionality. Recalls: synced as records pointing to a patient and a recall type (cleaning due, vaccination due). Recall types: a separate entity listing the types of recurring care (e.g., prophy, annual exam). Insurance: primary and secondary coverage per patient, including carrier, policy number, and policy holder. Appointment confirmations: the confirmation status of appointments (attempted, confirmed, unconfirmed) mapped from PMS-specific status values. Each requires three code areas: API to call the PMS, entity to transform to Weave schema, and an RPC sync method. OpenDental is the reference implementation to study.

🏷 Key Concepts

RecallsRecall TypesPrimary InsuranceSecondary InsuranceAppointment Confirmation StatusThree Code Areas PatternOpenDental ReferenceEntity → RPC Pattern

Key Takeaways

01Recalls and recall types are two separate entities — don't conflate them
02Insurance has primary and secondary records per patient — implement both separately
03Appointment confirmation status comes from PMS status values mapped via upon_new_status configuration
04Always read the OpenDental implementation before starting a new Type 3 integration
05Recall types are usually static (change rarely) — consider using push types instead of time-based partial sync