Suggested Scheduling

---

Use the Suggested Scheduling component to propose up to three alternative appointment times.
The Doctor App presents this component when the doctor selects Suggest Another Alternative in one of these parent workflows:

• Review and Approve
• Offer Appointment
• Alternative Offer

The component supports authenticated users only and loads dynamically inside the active screen.

---

Component Behavior

• Up to three editable scheduling cards.
• Fields for doctor, location, date, and time.
• Dynamic fee preview and doctor fee calculation.
• Inline validation and real-time conflict detection.
• Delete icons for optional cards.
• Button enablement logic that depends on valid and complete cards.
• Automatic acceptance when one alternative matches the original request.

---

Workflow

1. Select Suggest Another Alternative in a parent workflow.
2. The app presents the first card with prepopulated doctor and location.
3. Enter date and time for the first alternative.
4. Add up to two additional cards if needed.
5. The app validates:
   • Required values exist.
   • No conflicts or duplicates appear.
   • The number of cards does not exceed the limit.
6. Approve becomes active when all alternatives are valid.

---

Validations

These scenarios describe how the app validates the Suggested Scheduling component and what the integrator can expect.

Scenario	App Behavior	SDK Output	Example
A card does not include a valid date or time.	The app marks fields with validation indicators and disables Approve.	Validation error for incomplete card data.	—
Two or more cards contain identical doctor, location, date, and time.	The app rejects the duplicates and highlights conflicting values.	Validation error identifying conflicting cards.	—
More than three alternatives exist.	The app blocks creation of a fourth card.	Error identifying the card limit.	—
The app recalculates visit fee after a valid date–time entry.	The app displays updated fee values in each card.	Update set reflecting recalculated fee.	—
One alternative matches the original appointment request.	The app activates auto-approval logic and enables immediate confirmation.	Update set identifying auto-match.	—

Actions

These scenarios describe how the app responds when the doctor interacts with Suggested Scheduling.

Scenario	App Behavior	SDK Output	Example
The doctor selects Approve and all cards are valid.	The app sends the alternatives and transitions to the next status in the parent workflow.	Update set that includes all valid alternatives.	—
The doctor selects Delete on a secondary or tertiary card.	The app removes the selected card and reindexes remaining cards.	Update set that removes the card fragment.	—
The doctor selects Cancel.	The app closes the component and restores the parent view.	No-op or navigation update set.	—
The doctor edits date or time.	The app updates inline validation and fee preview.	Update set that refreshes the modified card.	—
The app detects a prescription requirement for the patient.	The app displays a conditional prescription information link.	Update set that adds a warning element.	—

---

SDK Reference

Each Suggested Scheduling card uses positional identifiers: {x} starts at 0 and increments for each card.
All repeated fields share this pattern.

Card #	Reference ID	Type	Value	Notes
x=0	doctor~0	Combo	Doctor selector	Prepopulated in first card. Editable in all cards.
x=0	location~0	Combo	Location selector	Required. Forms part of uniqueness rule.
x=0	prescription-info~0	Link	Prescription warning	Conditional.
x=0	date~0	Date	Date selector	Required. Triggers validation and fee calculation.
x=0	time~0	Time	Time selector	Required. Triggers validation and fee calculation.
x=0	fee-text~0	Section	Visit fee label	Static.
x=0	doctor-fee-text~0	Regular	Doctor fee label	Static.
x=0	doctor-fee~0	Highlight	Doctor fee amount	Dynamic.
x=0	delete~0	Link	Delete icon	Hidden in first card; appears on cards 1 and 2.