Appointment Rule Engine - Mobile Implementation Guide
Last Updated: 2026-05-09Target Platforms: iOS (Swift), Android (Kotlin)
Purpose: Complete logic reference for implementing appointment validation rules in native mobile apps
Table of Contents
- Core Concepts
- Data Structures
- Status State Machine
- Rule Categories
- Role-Based Permissions
- Implementation Checklist
Core Concepts
The appointment rule engine validates three main operations:- Creation — Can a new appointment be scheduled?
- Update — Can an existing appointment be modified?
- Status Change — Can an appointment move to a new status?
RuleResult:
allowed: Boolean— Whether the operation is permittedseverity: String—"blocking"(HTTP 409) or"warning"(HTTP 400)code: String— Machine-readable error code (e.g.,"DOCTOR_OFF","CONFLICT")message: String— Human-readable explanationconflicts: Array— Details of detected conflicts (if any)overrideAllowedForRoles: Array<String>— Roles that can override this rule (rarely used)
Data Structures
RuleResult
AppointmentContext
DoctorSchedule
ClinicOperatingHours
Status State Machine
Valid Transitions
State Machine Functions
Rule Categories
1. APPOINTMENT CREATION VALIDATION
Applies to: POST /appointmentsRequired context: All fields in AppointmentContext
Rule 1.1: No Past Appointments
Rule 1.2: Clinic Must Be Open
Rule 1.3: Doctor Must Not Be Off
Rule 1.4: Doctor Working Hours
Rule 1.5: Patient Duplicate Detection
Rule 1.6: Doctor/Room Time Conflicts
Rule 1.7: Final Result
2. APPOINTMENT UPDATE VALIDATION
Applies to: PATCH /appointments/:idRequired context: All fields in AppointmentContext, plus
existingAppointmentId
Logic: Same as Creation Validation (Rule 1), except:
- When checking for conflicts (Rule 1.6), exclude
existingAppointmentIdfrom the conflict query - This prevents the appointment from conflicting with itself
3. APPOINTMENT CANCELLATION RULES
Applies to: Cancelling an appointment (changing status to “cancelled”)Rule 3.1: Patient Ownership
Rule 3.2: Cancellation Window (Patient Only)
Rule 3.3: Staff Can Always Cancel
4. STATUS CHANGE VALIDATION
Applies to: PATCH /appointments/:id/statusRule 4.1: Valid State Transition
Rule 4.2: Time-Based Restrictions
Rule 4.3: Past Appointment Cancellation Restriction
Rule 4.4: Role-Based Permission Matrix
Rule 4.5: Final Result
5. AVAILABLE SLOTS CALCULATION
Applies to: GET /appointments/available-slotsParameters:
clinicId, date (YYYY-MM-DD), doctorId (optional)Returns: Array of available time slots (30-minute intervals)
Algorithm
6. APPOINTMENT COMPLETION (BILLING CHECK)
Applies to: Changing status to “completed”Rule: Cannot mark completed without invoice
7. EDIT ACCESS CONTROL
Applies to: Any direct update to appointment details (doctor, time, date, etc.)Role-Based Permissions
Status Change Permissions
| Role | Can Set To |
|---|---|
| superadmin | requested, scheduled, confirmed, in_progress, completed, cancelled, no_show |
| admin | requested, scheduled, confirmed, in_progress, completed, cancelled, no_show |
| receptionist | scheduled, confirmed, cancelled, no_show, completed |
| doctor | confirmed, in_progress, completed, no_show |
| patient | cancelled (only own appointments, 48h window) |
Appointment Operations Permissions
| Role | Create | Update | Cancel | Complete |
|---|---|---|---|---|
| superadmin | ✅ | ✅ | ✅ (no restrictions) | ✅ (with invoice) |
| admin | ✅ | ✅ | ✅ (no restrictions) | ✅ (with invoice) |
| receptionist | ✅ | ✅ | ✅ (no restrictions) | ✅ (with invoice) |
| doctor | ❌ | ❌ | ✅ (no restrictions) | ✅ (with invoice) |
| patient | ❌ | ❌ | ✅ (own, 48h) | ❌ |
Implementation Checklist
Phase 1: Core Data Structures
- Define
RuleResultstruct/class - Define
ConflictDetailstruct/class - Define
AppointmentContextstruct/class - Define
DoctorSchedulestruct/class - Define
ClinicOperatingHoursstruct/class
Phase 2: State Machine
- Implement
isValidTransition(from, to)function - Implement
isFinalState(status)function - Add comprehensive unit tests for all 7 states
Phase 3: Creation Rules
- Rule 1.1: Past date blocking
- Rule 1.2: Clinic hours validation
- Rule 1.3: Doctor off detection
- Rule 1.4: Doctor working hours
- Rule 1.5: Patient duplicate detection
- Rule 1.6: Time conflict detection (with buffer)
- Combine all into
canCreateAppointment()function - Unit tests: 20+ test cases
Phase 4: Update & Cancellation
- Rule 2: Update validation (wraps creation with exclusion)
- Rule 3.1-3.3: Cancellation rules
- Implement
canCancelAppointment()function - Unit tests: 15+ test cases
Phase 5: Status Change
- Rule 4.1: State transition validation
- Rule 4.2: Time-based restrictions
- Rule 4.3: Past appointment cancellation
- Rule 4.4: Role-based permissions
- Implement
canChangeStatus()function - Unit tests: 25+ test cases
Phase 6: Supporting Features
- Rule 5: Available slots calculation
- Rule 6: Completion invoice requirement
- Rule 7: Patient edit access control
- Unit tests: 30+ test cases
Phase 7: Integration
- Wire rules into appointment creation flow
- Wire rules into appointment update flow
- Wire rules into appointment status change flow
- Wire rules into available slots endpoint
- Integration tests with sample data
Phase 8: Testing & Documentation
- Minimum 80% code coverage
- Document any platform-specific deviations (iOS/Android)
- Add inline code comments for complex logic
- Create example usage in both Swift and Kotlin
Common Implementation Pitfalls
-
Buffer Time Confusion
- Buffer is added BEFORE and AFTER appointment time
- Example: 30-min appointment at 14:00 with 15-min buffer = occupies 13:45-14:45
-
Daylight Saving Time
- Always use date-only (YYYY-MM-DD) for schedules
- Never use absolute timestamps for day-of-week checks
- Store all times in clinic’s local timezone
-
Conflict Detection with Self
- When updating, exclude the existing appointment from conflict check
- This allows moving an appointment to a different time without conflicting with itself
-
Patient Cancellation Window
- 48 hours must be calculated in the clinic’s timezone
- Check
NOW + 48 hours > appointmentDateTime(not less than)
-
Status Transition Order
- Always check transition validity BEFORE checking time restrictions
- Always check time restrictions BEFORE checking role permissions
-
Role Hierarchy
- superadmin/admin have same permissions (both unrestricted)
- Receptionist < Doctor (doctor cannot create/update)
- Patient has minimal access (cancel own, view own)
Version History
| Date | Changes |
|---|---|
| 2026-05-09 | Initial documentation for mobile implementation |
Questions or Feedback?
For clarifications on rule logic or iOS/Android implementation details, refer to:- Server source:
/server/src/lib/rules/ - Type definitions:
/server/src/lib/rules/types.ts - Full implementation:
/server/src/lib/rules/scheduling/

