Scheduling & Bed/OR Management Master Data & Configuration

Master Data Inventory

Note: Patients, providers, facilities, departments, locations, payers are shared entities and not redefined here (see ../01-ehr-patient-mgmt/06-master-data.md and ../11-policy-contract-mgmt/06-master-data.md).

Setup Sequence

Dependency Diagram

Load Sequence Notes

1. Core shared master (from other modules) must exist before any scheduling configuration.
2. Encounter Types/Classes drive how appointments, admissions, OR cases map to encounters and ADT messages.
3. Financial Classes & Admission Sources support encounter creation and billing integration.
4. Discharge Dispositions required for discharge workflow and ADT A03.
5. Bed & Ward Taxonomy must be in place before bed registry and bed board configuration.
6. OR Taxonomy must precede OR schedules and OR cases.
7. Appointment & Queue Taxonomy required before appointment booking and queue board.
8. Holiday Calendar influences provider schedule templates and scheduling rules.
9. CPT Surgical Codes required before OR case booking and billing mapping.
10. Scheduling Rules use all previous master data to enforce constraints.
11. Provider Schedule Templates depend on appointment types, holidays, and rules.
12. Discharge Checklists depend on encounter types and discharge dispositions.
13. Waitlist Codes used by appointment and bed waitlist workflows.

Master Data Specifications

MD-SCHED-001: Appointment Types

Purpose

Defines standardized categories of outpatient and procedural appointments (e.g., new visit, follow-up, teleconsultation). Used for:

• Slot duration and buffer defaults
• Scheduling rules (lead time, overbooking, pre-auth)
• Reporting (no-show rate by type)
• Mapping to encounter types/classes

Logical Schema

Typically stored in appointment_types table (owned by this module).

Sample Data

Data Governance

• Owner: Scheduling Administrator
• Approver: Operations Director + relevant Department Head
• Update Frequency: On service line changes; formal review at least annually.
• Change Process: 1. Request raised by department head (with justification and proposed duration). 2. Impact analysis (scheduling, billing, NABIDH/Malaffi mapping). 3. Approval by Operations Director. 4. Configuration in test, validation with pilot clinic. 5. Promotion to production with communication to affected clinics.

Validation Rules

• code must be unique, uppercase, 3–20 characters, [A-Z0-9_-]+.
• default_duration_min > 0 and ≤ 240.
• If is_telehealth = TRUE, encounter_class_code must be O and must comply with DOH/DHA telehealth policies.
• If requires_pre_auth = TRUE, mapping to payers and CPT codes must exist in billing module.
• Cannot deactivate (is_active = FALSE) if future appointments exist for this type (soft deactivation only after migration).

MD-SCHED-002: Ward / Bed Types

Purpose

Defines standardized ward/bed categories used for bed assignment, billing, and reporting (e.g., General, ICU, VIP). Used by:

• Bed registry (beds.ward_type)
• Admission bed search filters
• Revenue mapping (room & board charges)
• UAE regulatory reporting (e.g., ICU occupancy)

Logical Schema

Sample Data

Data Governance

• Owner: Facilities Management
• Approver: COO / Hospital Director
• Update Frequency: On renovations, new ward opening/closure.
• Change Process: 1. Facilities project triggers review of ward types. 2. Coordination with Bed Management and Billing to ensure charge mapping. 3. Update in test, validate bed board and ADT flows. 4. Schedule cutover (often aligned with physical move).

Validation Rules

• ward_type_code unique, stable over time (no reuse).
• acuity_level between 1 and 5.
• If is_critical_care = TRUE, must map to ICU-related reporting categories for DOH/DHA.
• Cannot deactivate if any active beds reference this ward type; require migration.

MD-SCHED-003: OR Room Inventory

Purpose

Defines each operating room’s capabilities and attributes. Used for:

• OR scheduling (room selection)
• Equipment-based constraints (e.g., laminar flow, imaging)
• Utilization reporting

Logical Schema

(Complementary to or_rooms table; this master data defines controlled attributes.)

Sample Data

Data Governance

• Owner: OR Manager
• Approver: Surgical Services Director + Facilities
• Update Frequency: On room commissioning/decommissioning or major equipment changes.
• Change Process: 1. Facilities/biomed notify OR Manager of changes. 2. OR Manager updates capabilities and validates scheduling rules. 3. Communicate to surgeons and anesthesia teams.

Validation Rules

• or_room_code unique per facility.
• max_daily_hours between 1 and 24.
• If room_type = Hybrid, has_c_arm must be TRUE.
• Cannot deactivate if future OR cases scheduled; require rescheduling.

MD-SCHED-004: Provider Schedule Templates

Purpose

Reusable weekly patterns for provider availability (clinic sessions, telehealth blocks). Used to generate provider_schedules and appointment_slots.

Logical Schema

Sample Data

Data Governance

• Owner: Scheduling Administrator
• Approver: Department Head
• Update Frequency: Quarterly or when rosters change.
• Change Process: 1. Department submits roster changes. 2. Scheduling team updates templates and regenerates future slots (respecting existing bookings). 3. Communicate changes to affected patients if slots are impacted.

Validation Rules

• session_end_time > session_start_time.
• max_patients > 0.
• If is_telehealth = TRUE, facility_id must map to telehealth reporting location per DOH/DHA.
• No overlapping active templates for same provider, facility, department, day, and time range unless explicitly allowed by policy.

MD-SCHED-005: Scheduling Rules

Purpose

Configurable rules controlling how appointments, beds, and OR slots can be booked. Examples:

• Minimum/maximum lead time
• Overbooking limits
• Cancellation cut-off times
• Gender/isolation constraints for beds

Logical Schema

Sample Data

Data Governance

• Owner: Scheduling Administrator
• Approver: Operations Director + relevant clinical leads.
• Update Frequency: As policies change; at least annual review.
• Change Process: 1. Policy change documented by Operations/Quality. 2. Rule change drafted and tested in non-production. 3. Stakeholder sign-off (including Revenue Cycle if financial impact). 4. Controlled deployment with communication to users.

Validation Rules

• rule_code unique.
• parameters_json must be valid JSON and conform to schema per rule_type.
• Only one active rule per rule_type + scope_level + scope identifiers combination (no conflicting rules).
• Changes logged with audit trail (per UAE PDPL accountability).

MD-SCHED-006: Encounter Types / Classes

Purpose

Defines encounter classes and subtypes used across the HIS, aligned with HL7 and UAE reporting (e.g., inpatient, outpatient, emergency, day surgery).

Logical Schema

Sample Data

Data Governance

• Owner: Health Information Management (HIM) Manager
• Approver: Medical Director + Revenue Cycle Manager.
• Update Frequency: Rare; on regulatory or service model changes.
• Change Process: 1. Review HL7, DOH/DHA, MOH reporting requirements. 2. Impact analysis on ADT, billing, analytics. 3. Controlled implementation with mapping updates.

Validation Rules

• hl7_class_code must be one of standard HL7 values (I, O, E, P, etc.).
• Each encounter must map to exactly one active encounter type.
• Cannot delete; only deactivate with historical mapping preserved.

MD-SCHED-007: Discharge Dispositions

Purpose

Standardizes discharge outcomes for encounters, aligned with HL7 Table 0112 and UAE-specific needs (e.g., transfer to another facility, home, deceased). Used for:

• ADT A03 messages
• Regulatory reporting (mortality, transfers)
• Analytics (readmission risk, discharge before noon KPI)

Logical Schema

Sample Data

Data Governance

• Owner: HIM Manager
• Approver: Medical Director + Quality & Patient Safety.
• Update Frequency: Rare; on regulatory changes.
• Change Process: 1. Monitor DOH/DHA/MOH circulars. 2. Update mapping to HL7 and national reporting. 3. Communicate to clinicians and discharge planners.

Validation Rules

• hl7_code must be valid HL7 0112 value.
• Exactly one disposition must be marked is_deceased = TRUE for standard death reporting (additional subcodes may exist but must map).
• Cannot deactivate if used in last 12 months without migration plan.

MD-SCHED-008: Cancellation Reason Codes

Purpose

Captures standardized reasons for appointment cancellation or no-show, used for:

• No-show and cancellation KPIs
• Operational improvements (e.g., provider-driven vs patient-driven cancellations)
• Potential patient flagging (repeat no-shows)

Logical Schema

Sample Data

Data Governance

• Owner: Scheduling Administrator
• Approver: Outpatient Operations Manager.
• Update Frequency: As needed; semi-annual review.
• Change Process: 1. Review cancellation reports to identify new patterns. 2. Add or refine codes to improve analytics. 3. Train front-desk staff on correct usage.

Validation Rules

• cancel_reason_code unique.
• At least one active code per category PATIENT and PROVIDER.
• counts_as_no_show = TRUE only for patient-driven non-attendance without prior notice.

MD-SCHED-009: Holiday / Closure Calendar

Purpose

Defines facility-level non-working days (UAE public holidays and facility-specific closures) used to:

• Prevent scheduling on closed days
• Adjust provider schedule generation
• Inform patient portal availability

Logical Schema

Sample Data

Data Governance

• Owner: HR / Facility Administration
• Approver: Hospital Director.
• Update Frequency: Annually (public holidays) + ad-hoc closures.
• Change Process: 1. Load UAE public holidays as per government announcements. 2. Facilities propose additional closure dates. 3. Communicate to scheduling teams and update system.

Validation Rules

• No duplicate active holiday for same facility_id and date.
• If is_partial_day = TRUE, both partial_start_time and partial_end_time required and end > start.
• Appointment slot generation must respect this calendar.

MD-SCHED-010: Surgical Procedure Codes (CPT – Surgery)

Purpose

Catalogue of CPT surgical procedure codes (10000–69999) used for OR case booking, anesthesia planning, and billing mapping.

Logical Schema

Sample Data

Data Governance

• Owner: Surgical Services Administrator
• Approver: Coding/HIM + Revenue Cycle.
• Update Frequency: Annually with CPT updates; ad-hoc for local exclusions.
• Change Process: 1. Import new CPT release. 2. Map to specialties and typical durations. 3. Validate with surgeons and billing.

Validation Rules

• cpt_code must be valid CPT surgery code (10000–69999).
• typical_duration_min > 0 for codes used in OR scheduling.
• Cannot deactivate if referenced by future OR cases.

MD-SCHED-011: Bed Status Codes

Purpose

Standardizes bed occupancy states for the bed board and ADT triggers.

Logical Schema

Sample Data

Data Governance

• Owner: Bed Management Coordinator
• Approver: Nursing Director + Facilities.
• Update Frequency: Rare.
• Change Process: Controlled; must be aligned with Cleaning module workflows.

Validation Rules

• Exactly one status with is_assignable = TRUE and triggers_cleaning = FALSE representing “ready” state (VACANT).
• Status transitions must be defined in workflow engine (e.g., OCCUPIED → PENDING-CLEAN → VACANT).

MD-SCHED-012: Bed Cleaning Status Codes

Purpose

Represents cleaning workflow states for beds, used to coordinate with Cleaning Management module.

Logical Schema

Sample Data

Data Governance

• Owner: Facilities / Cleaning Manager
• Approver: Bed Management Coordinator.
• Update Frequency: Rare.

Validation Rules

• At least one status with is_terminal_clean = TRUE.
• Mapping between bed_status_code and cleaning_status_code transitions must be defined.

MD-SCHED-013: OR Case Status Codes

Purpose

Defines lifecycle states for OR cases (requested, scheduled, in progress, completed, cancelled).

Logical Schema

Sample Data

Data Governance

• Owner: OR Manager
• Approver: Surgical Services Director.
• Update Frequency: Rare.

Validation Rules

• Only one status per case can be is_final_state = TRUE at a time.
• counts_as_performed = TRUE only for statuses representing completed surgery.

MD-SCHED-014: Waitlist Status & Resolution Codes

Purpose

Standardizes waitlist entry states and resolution outcomes for appointments and beds.

Logical Schema

Separate resolution codes:

Sample Data – Status

Sample Data – Resolution

Data Governance

• Owner: Scheduling Administrator
• Approver: Outpatient Operations Manager.
• Update Frequency: Rare.

Validation Rules

• Exactly one terminal status used when resolution_code is set.
• is_success = TRUE only for resolutions that count towards Waitlist Conversion Rate KPI.

MD-SCHED-015: Admission Sources

Purpose

Defines where patients are admitted from (e.g., ER, clinic, transfer from other facility). Used for:

• Encounter creation (admission_source)
• Reporting and analytics
• ADT mapping

Logical Schema

Sample Data

Data Governance

• Owner: HIM Manager
• Approver: Medical Director.
• Update Frequency: Rare.

Validation Rules

• admission_source_code unique.
• Must cover all sources used in DOH/DHA reporting templates.

MD-SCHED-016: Financial Classes

Purpose

High-level financial categories for encounters (e.g., government, private insurance, self-pay). Used for:

• Encounter financial_class
• Revenue cycle reporting
• Eligibility workflows

Logical Schema

Sample Data

Data Governance

• Owner: Revenue Cycle Manager
• Approver: CFO.
• Update Frequency: On payer/product changes.

Validation Rules

• Must align with payer master in Policy & Contract Management module.
• Each encounter must have exactly one financial class.

MD-SCHED-017: Discharge Checklist Templates

Purpose

Defines discharge checklist templates per service line/encounter type (e.g., surgical, medical, maternity) used in WF-SCH-006.

Logical Schema

Sample Data (conceptual)

Example items_json for SURG-POSTOP (simplified):

[
  {"id": "meds_reconciled", "text_en": "Medications reconciled and prescriptions provided", "text_ar": "مراجعة الأدوية وتقديم الوصفات", "required": true},
  {"id": "wound_care", "text_en": "Wound care instructions explained", "text_ar": "شرح تعليمات العناية بالجرح", "required": true},
  {"id": "followup_booked", "text_en": "Follow-up appointment booked", "text_ar": "حجز موعد المتابعة", "required": true}
]

Data Governance

• Owner: Nursing Director / Quality Department
• Approver: Medical Director.
• Update Frequency: Annual review or after incident investigations.

Validation Rules

• items_json must be valid JSON with at least one required item.
• At least one active template per major encounter type.

MD-SCHED-018: OR Block Types

Purpose

Defines types of OR time blocks (e.g., dedicated list, emergency block, training) used in or_schedules.block_type.

Logical Schema

Sample Data

Data Governance

• Owner: OR Manager
• Approver: Surgical Services Director.

Validation Rules

• is_emergency and is_training cannot both be TRUE.

MD-SCHED-019: Scheduling Priority Codes

Purpose

Defines priority levels for appointments and waitlist entries (e.g., urgent, routine, elective).

Logical Schema

Sample Data

Data Governance

• Owner: Scheduling Administrator
• Approver: Medical Director / Operations.

Validation Rules

• sort_order unique.
• max_wait_days must align with clinical policies and DOH/DHA access standards.

MD-SCHED-020: Queue Status Codes (Clinic)

Purpose

Defines statuses for patients in the clinic queue (used in Clinic Queue Board WF-SCH-002, WF-SCH-009).

Logical Schema

Sample Data

Data Governance

• Owner: Outpatient Operations Manager
• Approver: Medical Director.

Validation Rules

• Exactly one terminal status must be set when encounter is closed from queue.

Configuration Parameters

Data Load Procedures

Initial Load

1. Source Identification - Appointment types, scheduling rules, queue statuses: from existing scheduling system or policy documents. - Ward/bed types, OR room inventory: from facilities CAD/layout and current bed/OR lists. - Discharge dispositions, encounter types, admission sources: from HIM coding manuals and HL7 mapping. - Holiday calendar: from UAE government announcements and facility HR. - CPT surgical codes: from official AMA CPT data (licensed).

2. Import Formats - Preferred: CSV or UTF-8 encoded Excel for bulk master data. - For CPT and other large sets: JSON or direct DB import. - All bilingual fields must support UTF-8 for Arabic.

3. Sample CSV Layout (Appointment Types)

code,display_name_en,display_name_ar,default_duration_min,prep_time_min,post_time_min,encounter_class_code,requires_referral,requires_pre_auth,is_telehealth,color_code,is_active
NEW,New Consultation,استشارة جديدة,30,10,5,O,TRUE,FALSE,FALSE,#1E90FF,TRUE
FUP,Follow-up Visit,زيارة متابعة,15,5,5,O,FALSE,FALSE,FALSE,#32CD32,TRUE

4. Validation on Import - Schema validation (required fields, data types). - Referential integrity (e.g., encounter_type_code exists). - Code uniqueness checks. - Business rules (e.g., duration ranges, HL7 code validity). - Arabic text encoding validation.

5. Approval & Sign-off - Each dataset reviewed by its governance owner. - Parallel test of key workflows (WF-SCH-001 to WF-SCH-008) using imported master data.

Ongoing Synchronization

• CPT Surgical Codes
• Annual import from AMA source.
• Compare with existing codes; mark obsolete as inactive rather than deleting.

• Validate mappings to OR templates and billing.

• Holiday Calendar

• Annual update when UAE public holidays announced.

• Facility-specific closures added as needed.

• Scheduling Rules & Templates

• Managed within application UI by authorized roles.
• Changes logged with audit trail (per UAE PDPL accountability and ADHICS/NABIDH security expectations).

Import/Export Interfaces

• Admin UI
• CSV upload for appointment types, cancellation reasons, scheduling rules, templates.

• Download current configuration as CSV for review.

• API

• Internal REST endpoints for IT to automate updates (e.g., holiday calendar).
• Access controlled via roles/permissions and logged.

Data Quality & PDPL Considerations

• Master data sets do not contain direct patient identifiers, but:
• Changes can affect patient care and billing; all changes must be auditable.
• Access to configuration screens restricted to appropriate roles.
• For any imports that include mappings to providers/facilities, ensure:
• Provider/facility IDs are validated against canonical masters.
• No free-text storage of personal data beyond what is necessary for configuration.

This specification provides the master data and configuration foundation required for the Scheduling & Bed/OR Management module to support all defined workflows and KPIs in the UAE regulatory context.