FHIR Appointment Integration: Scheduling Data Across Systems

A Schedule represents a provider or resource's bookable calendar; Slot represents a specific bookable (or already-booked) time period within that schedule, with a status (free, busy, busy-unavailable); and Appointment represents an actual booked visit, referencing the participants (patient, provider) and, often, the Slot it consumes. Reading availability generally means querying Slot resources with status=free for a given Schedule; booking means creating an Appointment that references the chosen Slot.

Read-only integration (pulling appointment data to keep an external system, like a patient engagement platform, in sync with the EHR's actual schedule) is meaningfully lower-risk than write-back integration (creating, modifying, or canceling appointments from outside the EHR) - and it's worth building and validating the read path first, since it already unlocks significant value (accurate, current scheduling data) with much less operational risk than write-back.

Write-back needs careful handling of race conditions specifically: two systems attempting to book the same Slot near-simultaneously is a real scenario at any meaningful volume, and the integration needs to handle a booking conflict response gracefully (re-check availability and offer alternatives) rather than assuming a successful create request always means a successful booking.

Not every EHR's FHIR API exposes Slot/Schedule resources with the same completeness - some populate them richly, others require falling back to a proprietary scheduling API or HL7 v2 SIU messages for the same data. Confirm what's actually available and well-populated for your specific target EHR before designing around the FHIR-native resources as if they're universally reliable.