Code Flow Part 4 — Entity Implementation (Patients, Appointments, Locations, Providers)
Why This Matters
For every entity you need to sync, there is an RPC that must be implemented. Knowing which RPCs exist, where they're called from, and what fields are required for each entity type is the practical foundation for writing integration code.
What You'll Learn
- How the sync patient RPC is implemented and where it's called from in the generic sync code
- What entities require separate RPC implementations: patients, appointments, client locations, providers, appointment types
- How the generic sync call is structured: a shared function calls your PMS-specific implementation
- What field requirements differ between entity types
- How to find and read an existing integration's entity implementation as a reference
Watch Video
Lesson Summary
For every entity type, there is a corresponding RPC method that must be implemented per integration. The sync patient RPC is the primary example: a generic shared function calls your PMS-specific SyncPatient implementation, which handles fetching, transforming, and sending patient data. The same pattern applies to appointments (SyncAppointment), client locations (SyncClientLocation), providers (SyncProvider), and appointment types (SyncAppointmentType). Each entity has different required fields — look at the proto definition and existing integrations as references. The generic layer handles the scheduling and looping; your implementation handles the PMS-specific data mapping.