Scheduling & Bed/OR Management Workflows

This document defines eight core workflows for the Scheduling & Bed/OR Management module. Each workflow includes process steps, actors, decision points, integration hooks, exception handling, and the paperless transformation achieved by the HIS.

Regulatory context (UAE): Patient scheduling and encounter management must comply with UAE PDPL (Federal Decree-Law No. 45/2021) for consent, purpose limitation, and data minimisation; MOH, DOH, and DHA regulations for admission/discharge processes; and NABIDH (Dubai) / Malaffi (Abu Dhabi) requirements for timely ADT (Admission/Discharge/Transfer) messaging. See 05-integrations.md for technical detail of HL7 and FHIR interfaces.

WF-SCH-001: Outpatient Appointment Booking

Process Flow

Actor: Scheduling Clerk, Patient (via Portal)
Trigger: Patient requests appointment or provider orders follow-up
Pre-conditions:

• Patient exists in patients (or will be created via EHR Patient Management before booking).
• Provider schedule templates and rules configured (provider_schedules, scheduling_rules, appointment_types).
• Facility calendar and closure days configured.
• For portal booking: patient authenticated in Patient Portal and consent to digital communication recorded (PDPL).

1. Actor opens Appointment Search & Booking screen (SCR-SCH-001).
2. Actor searches for patient by MRN, Emirates ID (e.g., 784-1990-1234567-1), name, or phone; system queries patients and patient_identifiers.
3. If patient not found: - a. For staff: system redirects to EHR Patient Management to create/merge patient. - b. For portal: system offers “complete registration” flow; booking is blocked until demographics are complete.
4. Actor selects appointment type (e.g., New Visit, Follow-up, Procedure) from appointment_types; system loads default duration, prep/post time, and flags (requires_referral, requires_pre_auth).
5. Actor selects facility, department, and optionally specific provider; system reads provider_schedules, scheduling_templates, appointment_slots, and scheduling_rules to compute available slots.
6. System applies scheduling constraints: - Max patients per slot / overbooking limits. - Lead time rules (e.g., routine ≥ 2 days, urgent ≤ 48 hours). - Provider-specific restrictions (e.g., “new patients only in morning”).
7. System displays available slots in calendar/grid view; actor chooses desired date/time.
8. System performs eligibility & authorization pre-check (if configured): - Queries insurance details from EHR Patient Management / Policy-Contract module. - If appointment_types.requires_referral = true, system checks for valid referral in EHR. - If appointment_types.requires_pre_auth = true, system checks for pre-authorization record.
9. Decision: Is insurance/referral/pre-auth valid? - If no, system:
   • Displays warning and options: proceed as self-pay, hold as “pending authorization”, or cancel.
   • For portal, may restrict booking depending on facility policy.
   • If yes, proceed.
10. Actor confirms booking; system:
    • Creates/updates encounters row as “planned” or “pre-registered” (encounter_class = outpatient).
    • Inserts row into appointments with status = booked, linking patient_id, provider_id, facility_id, department_id, appointment_type_id, slot_id.
    • Updates appointment_slots.current_bookings and overbooking counters.
11. System triggers downstream actions:
    • For portal bookings: sends confirmation via SMS/email/push (EN/AR) using contact data from patient_demographics.
    • For internal bookings: prints or displays appointment summary if needed.
12. If no suitable slot is available:
    • Actor or portal user adds patient to waitlist_entries with priority, preferred dates, and acceptable providers.
13. System logs booking event in audit trail (user, timestamp, IP/device) for PDPL accountability.

Data Modified:

• encounters — INSERT (planned encounter shell) or UPDATE (linking to new appointment)
• appointments — INSERT
• appointment_slots — UPDATE (current_bookings, is_blocked if slot filled)
• waitlist_entries — INSERT (if added to waitlist)
• scheduling_rules_audit (if implemented) — INSERT for rule overrides
• integration_message_log — INSERT (if external notifications/eligibility checks performed)

Mermaid Flowchart

Decision Points

1. Patient found? - If not found, booking cannot proceed until registration is completed or a merge is done.
2. Slots available? - If no slots, system offers waitlist; booking is not created.
3. Authorization valid? - If invalid, facility-configurable options:
   • Block booking.
   • Allow as self-pay.
   • Allow as “pending authorization” with flag for billing.
4. Proceed anyway after warning? - If user proceeds, system records override reason and flags encounter for financial review.

Integration Points

• EHR & Patient Management (ehr-patient-mgmt)
• Read: patients, patient_demographics, patient_identifiers, providers, facilities, departments.
• Write: encounters (planned).
• Policy & Contract Management (policy-contract-mgmt)
• Eligibility and pre-authorization checks (internal API).
• Billing & Claims (billing-claims)
• Notification of new planned encounter and appointment for pre-authorization workflows.
• Patient Portal
• FHIR R4 Appointment and Slot resources (INT-SCH-006) for online booking and confirmation.
• Notification Service
• SMS/email push (EN/AR) using UAE phone formats and PDPL-compliant consent flags.

Exception Handling

• Duplicate booking for same patient/provider/time:
• System checks appointments for overlapping bookings; prompts user to confirm or cancel.
• Provider schedule changed after slot display:
• On booking attempt, system re-validates slot; if no longer available, shows error and reloads availability.
• Eligibility service timeout:
• System logs timeout, allows configurable behaviour:
  • Soft-fail: allow booking with “eligibility pending” flag.
  • Hard-fail: block booking and prompt to retry.
• Portal booking outside allowed rules:
• System enforces stricter scheduling_rules for portal (e.g., no same-day booking); returns clear error messages.

Paperless Transformation

Remaining Paper Touchpoints: Optional printed appointment reminder if patient requests; otherwise fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Appointment exists in appointments with status booked and linked to patient, provider, facility, and encounter
• Encounter shell created or linked for downstream clinical and billing workflows
• Slot availability updated; overbooking counters maintained
• Patient notified of appointment details with pre-visit instructions
• Full audit trail of booking action, including any rule overrides

SLA and Timing

State Transition Diagram

WF-SCH-002: Appointment Check-In

Process Flow

Actor: Registration Clerk, Patient (via Self-Service Kiosk)
Trigger: Patient arrives for scheduled appointment
Pre-conditions:

• Appointment exists in appointments with status booked.
• Encounter shell exists in encounters (planned) or will be created at check-in.
• Kiosk devices integrated with Emirates ID reader and QR scanner where applicable.
• PDPL-compliant notice of processing displayed at kiosk/registration desk.

1. Patient approaches registration desk or kiosk and selects “Check-In”.
2. Patient identifies themselves via: - Emirates ID scan (kiosk or clerk). - MRN entry. - QR code from portal confirmation.
3. System searches appointments for upcoming bookings (e.g., ±2 hours) for this patient.
4. Decision: Matching appointment found? - If no, system offers:
   • Walk-in registration (if allowed).
   • Assistance request to clerk.
   • If yes, displays appointment details (provider, time, department).
5. Clerk/patient verifies identity and confirms appointment; system displays demographics and insurance from EHR Patient Management.
6. Actor reviews and updates demographics/insurance if needed; changes are written back to EHR Patient Management.
7. System performs real-time insurance eligibility check (if configured).
8. Decision: Eligibility valid? - If no, system:
   • Flags encounter as “eligibility issue”.
   • Prompts for self-pay acceptance or rescheduling.
   • If yes, proceed.
9. If co-payment required, clerk collects payment (cash/POS); payment status stored in Billing module.
10. System updates:
    • appointments.status → checked_in.
    • appointments.check_in_time with current timestamp.
    • encounters.encounter_status → in_progress (or creates encounter if not existing).
11. System assigns queue number and estimated wait time based on provider schedule and current load; updates clinic_queue (if implemented).
12. Clinic Queue Board (SCR-SCH-009) is updated to show patient as waiting.
13. System prints or displays queue ticket and wait time; for kiosk, may also show directions to clinic location.

Data Modified:

• appointments — UPDATE (status, check_in_time)
• encounters — INSERT (if new) or UPDATE (encounter_status, admission_datetime for outpatient)
• clinic_queue — INSERT/UPDATE (implementation-specific)
• integration_message_log — INSERT (eligibility check, payment events)

Mermaid Flowchart

Decision Points

1. Appointment found? - If not, branch to walk-in or manual assistance; no check-in to scheduled encounter.
2. Eligibility valid? - If invalid, facility policy determines whether to allow self-pay, require rescheduling, or escalate.
3. Proceed as self-pay? - If patient declines, appointment remains booked or is cancelled; no encounter activation.
4. Encounter exists? - If not, create new encounters row; if yes, update status and timestamps.

Integration Points

• EHR & Patient Management
• Read/update demographics and insurance.
• Billing & Claims
• Eligibility checks, co-pay collection, and encounter activation for billing.
• Patient Access / Kiosk
• Device integration for Emirates ID, QR scanning, and queue ticket printing.
• Clinic Queue Board
• Internal API or shared DB to update real-time queue.

Exception Handling

• Emirates ID reader failure:
• Fallback to manual MRN/name search; log device error.
• Eligibility service unavailable:
• Soft-fail: allow check-in with “eligibility pending” flag; notify billing.
• Duplicate check-in:
• If appointments.status already checked_in or completed, system warns and blocks duplicate.
• Kiosk abandonment:
• If patient does not complete flow within timeout, session is cleared without data changes.

Paperless Transformation

Remaining Paper Touchpoints: Printed queue ticket if facility chooses to provide; can be replaced by on-screen token or SMS.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Appointment status is checked_in with accurate check-in timestamp
• Encounter is active (in_progress) and linked to appointment
• Patient visible in clinic queue with estimated wait time
• Co-payment collected and recorded in billing (if applicable)
• Demographics and insurance verified or flagged for update

SLA and Timing

Note: Check-in transitions the appointment from Booked to CheckedIn within the appointment lifecycle defined in WF-SCH-001. No separate state diagram is required.

WF-SCH-003: Appointment Cancellation / Rescheduling

Process Flow

Actor: Scheduling Clerk, Patient (via Portal/Call)
Trigger: Patient or provider requests cancellation or date change
Pre-conditions:

• Appointment exists in appointments with status booked or checked_in (rescheduling may be restricted after check-in).
• Cancellation/rescheduling policies configured in scheduling_rules (e.g., cut-off times, penalties).
• Waitlist configured for relevant appointment types.

1. Actor opens Appointment Search and locates appointment by patient, provider, date, or appointment ID.
2. System displays appointment details, including status, type, and any linked encounters.
3. Actor selects action: Cancel or Reschedule.
4. System checks scheduling_rules for cancellation/reschedule eligibility (e.g., cannot cancel within 2 hours of start without override).
5. Decision: Within allowed cancellation window? - If no, system:
   • Displays warning and may require supervisor override.
   • For portal, may block cancellation and instruct patient to call.
   • If yes, proceed.
6. Actor records cancellation reason from Cancellation Reason Codes master data; system stores in appointments.cancellation_reason.
7. If Reschedule selected: - System invokes WF-SCH-001 sub-flow to find new slot. - Upon successful new booking, sets original appointment status to rescheduled and rescheduled_from in new appointment.
8. If Cancel selected: - System sets appointments.status to cancelled. - If encounter exists and no clinical documentation/charges, sets encounters.encounter_status to cancelled.
9. System releases original slot: - Decrements appointment_slots.current_bookings. - If slot was blocked due to full capacity, re-opens it.
10. System checks waitlist_entries for matching criteria (appointment type, provider, priority).
11. Decision: Waitlisted patient available?
    • If no, workflow ends.
    • If yes, system:
    • For auto-offer: sends offer to highest-priority waitlisted patient with expiry time.
    • For manual: flags slot in Waitlist Management screen.
12. System sends notifications:
    • To patient: cancellation/reschedule confirmation via SMS/email/app.
    • To provider/clinic: updated schedule view.
13. System updates cancellation metrics and flags repeat no-shows based on history.

Data Modified:

• appointments — UPDATE (status, cancellation_reason, rescheduled_from)
• encounters — UPDATE (status to cancelled when appropriate)
• appointment_slots — UPDATE (current_bookings)
• waitlist_entries — UPDATE (offer status, resolution_type when booked)
• integration_message_log — INSERT (notifications)

Mermaid Flowchart

Decision Points

1. Within allowed window? - Based on scheduling_rules (e.g., late cancellation vs on-time).
2. Override granted? - Senior Scheduling Clerk may override rules; system logs override.
3. Action = Reschedule? - Determines whether WF-SCH-001 is invoked or appointment is simply cancelled.
4. Encounter exists & unused? - If encounter has no clinical notes or charges, it can be safely cancelled; otherwise, may require HIM review.
5. Waitlist match found? - If yes, triggers waitlist offer logic.

Integration Points

• Patient Portal
• Allow patient-initiated cancellation/rescheduling within rules; update FHIR Appointment status.
• EHR & Patient Management
• Encounter status updates for cancelled visits.
• Billing & Claims
• Late cancellation/no-show flags for potential fees.
• Notification Service
• SMS/email/app updates to patient and provider.

Exception Handling

• Attempt to cancel completed appointment:
• System blocks and suggests creating an administrative correction instead.
• Reschedule to conflicting time:
• System checks for overlapping appointments for patient and provider; blocks if conflict.
• Notification delivery failure:
• System logs failure and displays alert to clerk; may trigger manual phone call.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Original appointment status reflects cancellation or rescheduling with reason
• Freed slot available for rebooking or waitlist offer
• Encounter cancelled if no clinical documentation exists
• Patient and provider notified of change
• Cancellation metrics updated for KPI tracking

SLA and Timing

Note: Cancellation and rescheduling represent transitions within the appointment lifecycle defined in WF-SCH-001 (Booked → Cancelled or Booked → Rescheduled). No separate state diagram is required.

WF-SCH-004: Inpatient Admission (Bed Assignment)

Process Flow

Actor: Bed Management Coordinator, Admitting Physician
Trigger: Physician orders admission (elective or emergency)
Pre-conditions:

• Admission order placed in CPOE and available to Scheduling module.
• Patient exists in patients; demographics and identifiers complete.
• Bed inventory configured in beds with status and attributes.
• Admission criteria and gender/isolation rules configured in scheduling_rules.
• NABIDH/Malaffi connectivity configured for ADT A01 messages.

1. Bed Management Coordinator opens Bed Board (SCR-SCH-004) or Admission screen (SCR-SCH-005) and selects pending admission from queue (from CPOE or ED).
2. System retrieves admission request details: requested ward type, specialty, isolation needs, gender, and expected LOS from CPOE.
3. Coordinator searches available beds using filters (ward type, isolation, gender, floor, facility).
4. System displays real-time bed status from beds and bed_assignments (occupied, vacant, pending discharge, cleaning).
5. System runs compatibility checks: - Gender mixing rules (e.g., no mixed-gender rooms unless private). - Isolation requirements (e.g., single room for airborne precautions). - Age/specialty constraints (e.g., paediatric vs adult wards).
6. Decision: Suitable bed available? - If no, system:
   • Offers to add patient to waitlist_entries for bed.
   • Flags admission as “bed pending” and notifies ED/ordering physician.
   • If yes, proceed.
7. Coordinator selects bed; system prompts confirmation and displays any conflicts (e.g., bed reserved for incoming transfer).
8. System creates/updates encounters: - Inserts new encounter with encounter_class = inpatient, encounter_status = admitted, admission_datetime. - Links to admission order and attending/admitting providers.
9. System inserts bed_assignments row with is_current = true, assigned_datetime, bed_id, encounter_id, patient_id.
10. System updates beds.bed_status to occupied and cleaning_status to not_applicable or clean.
11. System generates ADT A01 (Admit) message and sends to:
    • EHR Patient Management.
    • Billing & Claims.
    • NABIDH (if Dubai facility) or Malaffi (if Abu Dhabi facility).
    • Nutrition Management (for dietary census).
12. System notifies nursing station, housekeeping (for preparation if needed), and other relevant services via internal alerts.
13. System records expected LOS in encounter_details for discharge planning and bed forecasting.

Data Modified:

• encounters — INSERT (new inpatient encounter)
• encounter_details — INSERT/UPDATE (admission diagnosis, expected LOS, bed_id)
• bed_assignments — INSERT
• beds — UPDATE (bed_status, cleaning_status)
• waitlist_entries — INSERT (if bed not available)
• integration_message_log — INSERT (ADT A01, notifications)

Mermaid Flowchart

Decision Points

1. Suitable bed available? - If not, admission remains pending; patient may stay in ED/holding area.
2. Compatibility checks pass? - If gender/isolation/specialty rules fail, bed is not selectable.
3. Bed reserved or conflicting? - If bed reserved for higher-priority case, system warns and may block assignment.

Integration Points

• CPOE
• Admission order details (reason, requested ward, isolation).
• EHR & Patient Management
• Encounter creation and ADT A01 updates.
• Billing & Claims
• Admission notification, start of inpatient billing.
• Nutrition Management
• Admission notification for dietary census.
• Cleaning Management
• Bed preparation tasks if bed requires setup.
• NABIDH / Malaffi
• Outbound ADT A01 messages (INT-SCH-007 / INT-SCH-008).

Exception Handling

• Bed assigned in parallel by another user:
• On save, system re-checks beds.bed_status; if not vacant, shows error and reloads bed board.
• ADT A01 transmission failure:
• Message stored in retry queue; after repeated failures, alert IT/integration team; admission remains valid locally.
• Incorrect bed attributes:
• If bed master data inconsistent (e.g., missing gender restriction), system logs data quality issue and may require admin correction.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital; patient may still receive printed admission information leaflet if requested.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Inpatient encounter created with admission timestamp and attending provider
• Bed assigned to patient; bed board reflects occupied status
• ADT A01 sent to HIE and all downstream modules
• Nursing station, dietary, and housekeeping notified
• Expected LOS recorded for discharge planning and bed forecasting

SLA and Timing

State Transition Diagram

WF-SCH-005: Patient Transfer (Bed-to-Bed)

Process Flow

Actor: Bed Management Coordinator, Charge Nurse
Trigger: Clinical need for patient transfer (step-down, isolation, specialty change)
Pre-conditions:

• Active inpatient encounter in encounters with current bed_assignments.is_current = true.
• Transfer reasons master data configured.
• Bed inventory and compatibility rules up to date.
• NABIDH/Malaffi ADT A02 integration active.

1. Charge Nurse or physician initiates transfer request in EHR (reason, target ward type, urgency).
2. Bed Management Coordinator opens transfer queue and selects patient/encounter.
3. System displays current bed, ward, and clinical flags (isolation, fall risk, etc.).
4. Coordinator searches for target bed using criteria (ward type, isolation, gender, specialty).
5. System runs compatibility checks similar to admission workflow.
6. Decision: Suitable target bed available? - If no, system:
   • Allows marking transfer as “pending bed”.
   • Optionally adds to bed waitlist.
   • If yes, proceed.
7. Coordinator selects target bed; system prompts for clinical reason and requires Charge Nurse approval.
8. Charge Nurse reviews and approves transfer electronically (e-signature).
9. System updates bed_assignments: - Sets current assignment is_current = false and released_datetime = now. - Inserts new assignment with bed_id = target, is_current = true, assigned_datetime = now.
10. System updates beds:
    • Old bed: bed_status = vacant, cleaning_status = pending.
    • New bed: bed_status = occupied.
11. System generates ADT A02 (Transfer) message and sends to:
    • EHR Patient Management.
    • Billing & Claims (for location-based charges).
    • NABIDH/Malaffi.
    • Nutrition (update dietary location).
    • PIS (update medication administration location).
12. System triggers cleaning workflow for vacated bed (INT-SCH-004).
13. Nursing dashboards and bed board are updated to reflect new location.

Data Modified:

• bed_assignments — UPDATE (old row), INSERT (new row)
• beds — UPDATE (old and new bed status/cleaning_status)
• bed_transfers — INSERT (transfer history, reason, approvals, adt_message_id)
• integration_message_log — INSERT (ADT A02, cleaning, nutrition, PIS notifications)

Mermaid Flowchart

Decision Points

1. Suitable target bed available? - If no, transfer remains pending; patient stays in current bed.
2. Approval granted? - Charge Nurse may reject transfer if clinically inappropriate.
3. Compatibility checks pass? - If not, bed cannot be selected; system suggests alternative wards.

Integration Points

• EHR & Patient Management
• Location updates for patient chart.
• Billing & Claims
• Ward/bed-level charge updates.
• Nutrition Management
• Update ward/bed for meal delivery.
• PIS (Pharmacy Information System)
• Update medication administration location.
• Cleaning Management
• Trigger cleaning tasks for vacated bed.
• NABIDH / Malaffi
• ADT A02 messages for transfers.

Exception Handling

• Transfer initiated while discharge in progress:
• System detects pending discharge order and warns; requires explicit confirmation or cancellation of discharge.
• Concurrent transfer requests:
• If multiple transfers target same bed, system locks bed on first confirmed assignment; others must reselect.
• ADT A02 failure:
• Retry mechanism; if persistent, local data remains authoritative and integration team alerted.

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Patient assigned to new bed; old bed released for cleaning
• Bed board reflects updated occupancy for both source and target wards
• ADT A02 sent to HIE and all downstream modules
• Cleaning workflow triggered for vacated bed
• Full audit trail of transfer with clinical reason and approval

SLA and Timing

Note: Patient transfer represents transitions within the bed assignment lifecycle defined in WF-SCH-004 (Occupied → PendingTransferOut → PendingCleaning). No separate state diagram is required.

WF-SCH-006: Patient Discharge

Process Flow

Actor: Physician, Discharge Coordinator, Nurse
Trigger: Physician enters discharge order in CPOE
Pre-conditions:

• Active inpatient encounter in encounters with encounter_status = admitted or in_progress.
• Discharge disposition master data configured.
• Discharge checklist templates configured per specialty.
• NABIDH/Malaffi ADT A03 integration active.
• Patient portal enabled for discharge summary where applicable.

1. Physician enters discharge order in CPOE, specifying discharge disposition (home, transfer, AMA, deceased).
2. Scheduling module receives discharge order event and flags encounter as “discharge in progress”.
3. System runs discharge readiness checks: - Pending orders (labs, imaging). - Outstanding consults. - Unverified results.
4. Decision: Any blocking items? - If yes, system displays list; discharge coordinator/nurse works with physician to resolve or override. - If no, proceed.
5. Nurse opens Admission/Transfer/Discharge screen (SCR-SCH-005) for the patient and completes discharge checklist (medication reconciliation, patient education, follow-up appointments).
6. System prompts to schedule follow-up appointment(s) via WF-SCH-001 (outpatient booking).
7. Physician or authorised clinician reviews and signs discharge summary (generated from EHR, not owned by this module but linked).
8. System updates encounters: - discharge_datetime = now. - encounter_status = discharged. - discharge_disposition set.
9. System updates bed_assignments: - Current assignment is_current = false, released_datetime = now.
10. System updates beds:
    • bed_status = vacant.
    • cleaning_status = pending.
11. System generates ADT A03 (Discharge) message and sends to:
    • EHR Patient Management.
    • Billing & Claims (for final billing and LOS calculation).
    • NABIDH/Malaffi.
    • Nutrition (remove from census).
12. System triggers cleaning workflow for vacated bed (INT-SCH-004).
13. System sends discharge summary to Patient Portal (if patient enrolled and consented).
14. Discharge KPIs (e.g., discharge before noon) are updated for analytics.

Data Modified:

• encounters — UPDATE (discharge_datetime, encounter_status, discharge_disposition)
• bed_assignments — UPDATE (current row is_current = false, released_datetime)
• beds — UPDATE (bed_status, cleaning_status)
• appointments — INSERT (follow-up) via WF-SCH-001
• integration_message_log — INSERT (ADT A03, cleaning, portal notification)

Mermaid Flowchart

Decision Points

1. Blocking items? - Pending critical results or consults may block discharge unless overridden.
2. Override or resolve? - Physician may override certain pending items with justification.
3. Patient portal delivery? - If patient not enrolled or declines, summary not sent to portal.

Integration Points

• CPOE
• Discharge order and readiness checks.
• EHR & Patient Management
• Encounter status and discharge summary linkage.
• Billing & Claims
• Final billing, DRG/LOS calculation.
• Cleaning Management
• Bed cleaning tasks.
• Nutrition Management
• Removal from dietary census.
• Patient Portal
• Delivery of discharge summary and follow-up appointment details.
• NABIDH / Malaffi
• ADT A03 discharge messages.

Exception Handling

• Discharge order cancelled:
• If physician cancels discharge, system reverts encounter status and bed status; ADT A03 cancellation (or A13) may be sent depending on integration profile.
• ADT A03 failure:
• Retry queue; local discharge remains valid; integration team alerted.
• Bed already reassigned:
• System prevents reassignment until discharge is fully processed; if conflict occurs, manual correction by Bed Management.

Paperless Transformation

Remaining Paper Touchpoints: Printed discharge instructions if patient prefers physical copy; otherwise digital via portal.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Encounter closed with discharge timestamp, disposition, and summary
• Bed released and cleaning workflow triggered
• ADT A03 sent to HIE and all downstream modules
• Follow-up appointment(s) scheduled
• Patient portal updated with discharge summary (if enrolled)
• Discharge KPIs updated (e.g., discharge before noon metric)

SLA and Timing

Note: Patient discharge represents transitions within the bed assignment lifecycle defined in WF-SCH-004 (Occupied → PendingDischarge → PendingCleaning → Cleaning → Vacant). No separate state diagram is required.

WF-SCH-007: Operating Room Scheduling

Process Flow

Actor: OR Scheduler, Surgeon, Anesthesiologist
Trigger: Surgeon requests OR time for surgical procedure
Pre-conditions:

• Patient and encounter exist (pre-admission or same-day surgery encounter).
• OR rooms configured in or_rooms with capabilities and availability.
• OR block schedules configured in or_schedules.
• Surgical procedure codes (CPT) master data loaded.
• Pre-op clearance and consent workflows available in EHR.

1. Surgeon submits OR booking request via CPOE or OR Case Booking screen (SCR-SCH-007), specifying patient, procedure (CPT), estimated duration, preferred date/time, and equipment/implant needs.
2. System validates request: - Patient and encounter linkage. - Procedure code validity. - Required pre-op labs/imaging ordered.
3. OR Scheduler opens OR booking queue and reviews pending requests.
4. Scheduler selects a request and views: - Patient details. - Procedure details. - Surgeon and anesthesiologist preferences. - Pre-op clearance status (from EHR).
5. Scheduler checks OR availability: - Reads or_schedules and or_rooms for selected date. - Considers existing or_cases and turnover times.
6. System checks surgeon and anesthesiologist availability against provider_schedules.
7. Decision: Are OR room and team available in requested window? - If no, system suggests alternative slots (different time/room/day). - If yes, proceed.
8. Scheduler selects OR room, date, and time block; system calculates expected end time including turnover.
9. System creates or_cases record: - Links to schedule_id, patient_id, encounter_id, surgeon_id, anesthesiologist_id. - Stores procedure_code_cpt, estimated_duration, case_status = scheduled.
10. System updates or_schedules for the room/date with block usage and utilisation metrics.
11. System assigns supporting staff (scrub nurse, circulator) via integration with staffing/HR module or manual entry.
12. System sends confirmations:
    • To surgeon and anesthesiologist (schedule updates).
    • To patient (SMS/email/app with pre-op instructions).
13. System verifies consent and pre-authorization status:
    • If missing, flags case as “pending consent” or “pending pre-auth”.
14. OR Schedule Board (SCR-SCH-006) displays updated Gantt-style view for all rooms.

Data Modified:

• or_cases — INSERT
• or_schedules — UPDATE (block usage, status)
• encounters — UPDATE (may set encounter_type/class for surgical episode)
• scheduling_rules_audit — INSERT (if rules overridden, e.g., after-hours case)
• integration_message_log — INSERT (notifications)

Mermaid Flowchart

Decision Points

1. Room & team available? - If not, scheduler must negotiate alternative time or room.
2. Alternative accepted? - Surgeon may accept or request different slot; request may remain pending.
3. Consent/pre-auth complete? - If not, case is scheduled but flagged; pre-op team must resolve before day of surgery.

Integration Points

• CPOE
• OR booking request and pre-op orders.
• EHR & Patient Management
• Encounter linkage and pre-op clearance status.
• Billing & Claims
• Surgical case data for OR charges and professional fees.
• PIS (Anesthesia drugs)
• Anesthesia plan and drug requirements.
• Staffing/HR
• Staff assignment and availability (if integrated).
• Patient Portal
• Procedure schedule and pre-op instructions.

Exception Handling

• Overlapping cases for same surgeon:
• System detects conflict and blocks scheduling until resolved.
• OR room closed (maintenance/emergency):
• Admin updates or_rooms.is_active = false; system prevents new bookings and prompts rescheduling of existing cases.
• Last-minute cancellation:
• Case status updated to cancelled; slot may be offered to urgent cases; billing and utilisation metrics updated accordingly.

Paperless Transformation

Remaining Paper Touchpoints: Printed daily OR list for theatre staff if desired; can be replaced by digital displays.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• OR case created with procedure, team, room, and time block
• OR schedule board reflects new case; utilisation metrics updated
• Surgeon, anesthesiologist, and patient notified of schedule
• Pre-op consent and pre-authorization status tracked; case flagged if pending
• Supporting staff assigned (or flagged for manual assignment)

SLA and Timing

State Transition Diagram

WF-SCH-008: Waitlist Management

Process Flow

Actor: Scheduling Clerk, System (automated)
Trigger: No available slot for requested appointment or bed; slot becomes available
Pre-conditions:

• Waitlist functionality enabled for relevant services.
• waitlist_entries table configured with priority rules.
• Notification channels (SMS/app) configured and PDPL-compliant consent obtained.

1. When booking attempt fails due to no available slots (WF-SCH-001), clerk or portal user is offered option to join waitlist.
2. If accepted, system creates waitlist_entries row: - patient_id, waitlist_type (appointment/bed), requested_service, preferred_provider_id, priority, added_datetime, target_date_from/to, status = active.
3. Scheduling Clerk can view and manage waitlist via Waitlist Management screen (SCR-SCH-008), with sorting by priority and days waiting.
4. System continuously monitors appointment_slots and beds for newly available capacity (e.g., cancellations, discharges).
5. When a slot becomes available, system identifies matching waitlist entries based on: - Service/department. - Provider (if required). - Priority and target date range.
6. Decision: Matching waitlist entry found? - If no, slot remains available for normal booking. - If yes, proceed.
7. For auto-offer mode: - System sends offer notification to highest-priority matching patient with expiry time (e.g., 2 hours). - waitlist_entries.offer_status updated (if such field exists) and offered_count incremented.
8. Patient responds via portal/SMS link: - Accept → system invokes WF-SCH-001 to book appointment into freed slot. - Decline or no response before expiry → system moves to next patient in queue.
9. For manual mode: - Clerk contacts patient and manually books appointment; system updates waitlist_entries accordingly.
10. Once appointment/bed is booked from waitlist:
    • waitlist_entries.status = resolved.
    • waitlist_entries.resolution_type = booked.
    • resolved_datetime set.
11. If patient declines or cannot be reached after multiple offers:
    • resolution_type may be set to declined or lost_to_follow_up.

Data Modified:

• waitlist_entries — INSERT, UPDATE (status, offered_count, resolution_type, resolved_datetime)
• appointments — INSERT (when booking from waitlist)
• appointment_slots — UPDATE (current_bookings)
• integration_message_log — INSERT (notifications)

Mermaid Flowchart

Decision Points

1. Patient/Clerk accepts waitlist? - If not, no waitlist entry is created.
2. Slot becomes available? - Triggered by cancellation or schedule change.
3. Match found? - Based on service, provider, priority, and date range.
4. Accepted? - If patient declines or times out, next patient is offered.

Integration Points

• Patient Portal
• Waitlist enrolment and offer acceptance/decline.
• Notification Service
• SMS/app notifications with time-limited offers.
• EHR & Patient Management
• Appointment creation from waitlist.
• Scheduling Analytics
• Waitlist conversion metrics for KPIs.

Exception Handling

• Multiple offers accepted simultaneously:
• System uses transactional booking; first confirmed booking gets slot; others receive “slot no longer available” message and remain on waitlist.
• Notification failure:
• System logs failure and may fall back to manual contact by clerk.
• Waitlist entry stale (e.g., patient already booked elsewhere):
• On offer generation, system checks if patient already has suitable appointment; if yes, marks entry as resolved (duplicate).

Paperless Transformation

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Outputs:

Post-conditions:

• Waitlist entry created with structured priority, preferences, and timestamps
• When slot becomes available, highest-priority matching patient offered the slot
• Successful conversion results in booked appointment and resolved waitlist entry
• Declined or expired offers cycle to next patient in queue
• Full audit trail of waitlist additions, offers, and resolutions

SLA and Timing

Note: Waitlist management is a process-coordination workflow that matches available capacity to queued patients. It does not manage a distinct entity lifecycle beyond the waitlist_entries status field (Active → Offered → Resolved/Declined/Expired). No separate state diagram is required.

These workflows, combined with the underlying data model and integrations, enable a fully paperless scheduling and bed/OR management process aligned with UAE regulatory requirements, including UAE PDPL, MOH/DOH/DHA policies, and NABIDH/Malaffi HIE connectivity.