Case Management Master Data & Configuration

Master Data Inventory

Note: Core shared entities (patients, providers, encounters, facilities, departments, payers, insurance plans, prior authorizations) are defined in their owning modules and referenced here via foreign keys only (see module brief).

Setup Sequence

Data sets must be configured in the following dependency order.

Load Sequence (narrative):

1. Level-of-Care Definitions (MD-CSM-002) — foundational for UM criteria, review types, and payer schedules.
2. UM Review Types & Outcomes (MD-CSM-010) — standardises review events and decisions.
3. UM Clinical Criteria (MD-CSM-001) — mapped to level-of-care and review types.
4. Payer Review Schedules (MD-CSM-007) — references level-of-care and review types.
5. Discharge Disposition Codes (MD-CSM-003) — required for discharge planning and billing mapping.
6. Post-Acute Service Types (MD-CSM-004) — used in discharge plans.
7. UAE Discharge Destination Facilities (MD-CSM-009) — linked to service types and dispositions.
8. Case Assignment Rules (MD-CSM-006) — depends on departments/service lines (from shared entities).
9. Care Coordination Program Types (MD-CSM-008) — used in care coordination workflows and dashboards.
10. Readmission Risk Score Weights (MD-CSM-005) — required for automated risk scoring.
11. Readmission Root Cause Categories (MD-CSM-011) — used in readmission review documentation.
12. Go-Live — after validation of all above and integration with scheduling, EHR, and billing.

Master Data Specifications

MD-CSM-001: UM Clinical Criteria

Purpose

Structured representation of utilisation management clinical criteria (e.g., InterQual-equivalent or facility-developed) used to determine medical necessity and appropriate level-of-care for admission, continued stay, and discharge. Supports consistent, auditable UM decisions and payer compliance.

Schema

Table: um_clinical_criteria

Sample Data

Data Governance

• Owner: Medical Director (Utilization Management)
• Approval process: 1. Draft/updated criteria prepared by UM team or clinical specialty lead. 2. Reviewed by UM Committee (including Physician Advisor, Case Management Director). 3. Legal/compliance review for payer and MOH/DOH/DHA alignment if needed. 4. Approved version recorded; IT updates master data in test then production.
• Update frequency: Annual formal review; ad-hoc updates when major guidelines or payer requirements change.
• Change notification:
• Release notes to case managers, UM nurses, physician advisors.
• In-system banner for changed criteria for 2–4 weeks.
• Training sessions for high-impact changes.

Validation Rules

• code must be unique and non-null.
• display_name_en and display_name_ar required and <= 255 chars.
• review_phase limited to controlled list: Admission, Continued Stay, Discharge, Observation, Retrospective.
• level_of_care_code must exist in level_of_care (MD-CSM-002).
• effective_to must be NULL or > effective_from.
• Only one active criteria record per (code) at any time.
• is_active = TRUE only if current date between effective_from and effective_to (or effective_to NULL).

MD-CSM-002: Level-of-Care Definitions

Purpose

Defines standard levels of care used across UM, billing, and reporting (e.g., inpatient acute, observation, day surgery, home health). Ensures consistent classification aligned with UAE regulatory and payer expectations.

Schema

Table: level_of_care

Sample Data

Data Governance

• Owner: UM Committee Chair
• Approval process:
• Proposed changes initiated by UM Committee or Revenue Cycle.
• Reviewed by Compliance Officer for DOH/DHA/MOH alignment.
• Approved by UM Committee and Revenue Cycle Director.
• Update frequency: Rare; only when regulatory or operational model changes.
• Change notification:
• Communicated to UM, billing, coding, and bed management teams.
• Mapping updates coordinated with billing and claims (eClaimLink, DOH eClaims).

Validation Rules

• code unique and immutable once used in production.
• display_name_en and display_name_ar required.
• At least one level with inpatient_flag = TRUE.
• default_length_of_stay_days ≥ 0.
• Cannot deactivate (is_active = FALSE) if referenced by active UM criteria or payer review schedules without migration plan.

MD-CSM-003: Discharge Disposition Codes

Purpose

Standardised discharge disposition codes used for clinical documentation, billing, and regulatory reporting. Based on HL7 Table 0112 with UAE-specific extensions (e.g., discharge to home in UAE, transfer to facility in specific emirate).

Schema

Table: discharge_disposition_codes

Sample Data

Data Governance

• Owner: HIM Manager
• Approval process:
• New codes or changes proposed by HIM or Case Management.
• Reviewed for impact on coding, billing, and DOH/DHA/MOH reporting.
• Approved by HIM Director and Revenue Cycle Director.
• Update frequency: Infrequent; when HL7 or UAE reporting requirements change.
• Change notification:
• Communicated to physicians, case managers, coders.
• Updated mapping for billing and analytics.

Validation Rules

• code unique and non-null.
• Only one of is_home, is_transfer, is_death should be TRUE per code.
• If requires_destination_facility = TRUE, system must enforce selection of destination facility (MD-CSM-009) in discharge workflow.
• EXPIRED must have is_death = TRUE.
• Cannot deactivate codes used in last 12 months without mapping to replacement.

MD-CSM-004: Post-Acute Service Types

Purpose

Defines categories of post-acute services used in discharge planning and care coordination (e.g., home health, rehab, DME). Drives discharge plan structure, referrals, and reporting.

Schema

Table: post_acute_service_types

Sample Data

Data Governance

• Owner: Case Management Director
• Approval process:
• New service types proposed by Discharge Planning or Care Coordination.
• Reviewed for contractual arrangements and payer coverage implications.
• Approved by Case Management Director and Revenue Cycle Director if billing impact.
• Update frequency: Quarterly review; ad-hoc when new programs/services added.
• Change notification:
• Communicated to discharge planners, social workers, and care coordinators.
• Updated in discharge planning templates.

Validation Rules

• code unique and non-null.
• requires_external_provider TRUE for services requiring a specific provider/facility.
• typical_duration_days ≥ 0 if provided.
• Cannot deactivate if referenced by active discharge plans without migration.

MD-CSM-005: Readmission Risk Score Weights

Purpose

Stores configuration for readmission risk scoring algorithms (e.g., LACE index or facility-specific model). Used in WF-CSM-005 to calculate risk scores and levels.

Schema

Table: readmission_risk_weights

Sample Data

Example for a simplified LACE-like model:

Data Governance

• Owner: Medical Informatics Lead
• Approval process:
• Model design/recalibration by analytics team.
• Validation on historical UAE facility data (e.g., readmission outcomes).
• Approval by Quality & Patient Safety Committee and Medical Director.
• Update frequency: Annual or when performance review indicates need.
• Change notification:
• Communicated to case managers, care coordinators, and physicians.
• Updated documentation on how scores should influence interventions.

Validation Rules

• Combination (model_code, factor_code, effective_from) must be unique.
• effective_to > effective_from when not NULL.
• Risk thresholds (risk_level_threshold not NULL) must cover full score range without overlap for each model.
• Only one active version of a model at a time.

MD-CSM-006: Case Assignment Rules

Purpose

Defines rules for automatic assignment of cases to case managers/UM nurses based on department, service line, payer, and workload. Used in WF-CSM-001 for automated case assignment.

Schema

Table: case_assignment_rules

Sample Data

(IDs are illustrative; actual IDs come from shared entity tables.)

Data Governance

• Owner: Case Management Director
• Approval process:
• Proposed changes from Case Management leadership or Nursing Administration.
• Reviewed for workload balance and coverage.
• Approved by Case Management Director.
• Update frequency: On staffing or organisational changes; at least annually.
• Change notification:
• Communicated to case management team and bed management.
• Changes scheduled outside peak hours to avoid assignment instability.

Validation Rules

• code unique.
• max_caseload > 0.
• For active rules, case_manager_id must reference an active user with appropriate role.
• Rule evaluation engine must apply highest priority (lowest numeric value) first; ties broken by more specific criteria (payer > department > service_line).
• System must prevent configuration that would leave a department/emirate with no active rule.

MD-CSM-007: Payer Review Schedules

Purpose

Defines payer-specific UM requirements: review frequency, initial authorization windows, and communication channels. Used in WF-CSM-001, WF-CSM-002, and WF-CSM-006.

Schema

Table: payer_review_schedules

Sample Data

Assume payer IDs: Daman=302, Thiqa=303, Oman=304.

Data Governance

• Owner: UM Team Lead
• Approval process:
• Data sourced from signed payer contracts and UM manuals.
• Reviewed by Contract Management and Revenue Cycle.
• Approved by Revenue Cycle Director.
• Update frequency: On contract renewal or payer policy change.
• Change notification:
• Communicated to UM team and Patient Access (Prior Auth).
• System alerts for changed schedules for active cases.

Validation Rules

• For each active combination (payer_id, level_of_care_code, review_type), only one schedule may be active at a time.
• effective_to > effective_from when not NULL.
• initial_review_hours, subsequent_review_days, max_days_without_auth must be ≥ 0 if provided.
• communication_channel limited to controlled list.

MD-CSM-008: Care Coordination Program Types

Purpose

Defines types of care coordination programs (e.g., heart failure clinic, diabetes management, high-risk readmission program) used in WF-CSM-004 and readmission prevention workflows.

Schema

Table: care_coordination_program_types

Sample Data

Data Governance

• Owner: Case Management Director
• Approval process:
• New programs proposed by Population Health or Quality.
• Reviewed for resource availability and KPIs.
• Approved by Population Health Committee.
• Update frequency: As programs evolve; at least annual review.
• Change notification:
• Communicated to care coordinators and relevant clinical teams.
• Patient portal content updated for patient-facing programs.

Validation Rules

• code unique.
• min_risk_level limited to Low, Medium, High or NULL.
• If auto_enroll_flag = TRUE, program must have clear inclusion rules configured in care coordination engine (outside this table).

MD-CSM-009: UAE Discharge Destination Facilities

Purpose

Directory of external facilities and providers used as discharge destinations (rehab centres, long-term care, home care agencies, etc.) within UAE and abroad. Supports WF-CSM-003 and mapping to discharge dispositions.

Schema

Table: discharge_destination_facilities

Sample Data

Data Governance

• Owner: Discharge Planning Lead
• Approval process:
• New facilities added upon credentialing/contracting.
• Verified against DOH/DHA/MOH licensing where applicable.
• Approved by Case Management Director and Contracting team.
• Update frequency: Quarterly review; ad-hoc for contract changes.
• Change notification:
• Communicated to discharge planners and social workers.
• Inactive facilities flagged in UI and removed from selection lists.

Validation Rules

• code unique.
• service_type_code must exist in post_acute_service_types.
• If country = 'United Arab Emirates', emirate should be one of configured emirates.
• Cannot deactivate if referenced by future-dated discharge plans without reassignment.

MD-CSM-010: UM Review Types & Outcomes

Purpose

Standardises UM review types and possible outcomes for documentation and analytics (e.g., admission review, continued stay review, outcomes like approved, denied, downgraded).

Schema

Table: um_review_types

Table: um_review_outcomes

Sample Data

Review Types

Outcomes

Data Governance

• Owner: UM Team Lead
• Approval process:
• Changes proposed by UM Committee.
• Reviewed for alignment with payer terminology and reporting.
• Approved by UM Committee Chair.
• Update frequency: Rare; annual review.
• Change notification:
• Communicated to UM staff.
• Mapping updates in reports and dashboards.

Validation Rules

• code unique.
• At least one final outcome (is_final = TRUE) must exist.
• Outcomes used in continued stay authorizations must remain stable; deprecation requires mapping.

MD-CSM-011: Readmission Root Cause Categories

Purpose

Taxonomy for documenting root causes of 30-day readmissions, used in WF-CSM-005 and quality improvement analytics.

Schema

Table: readmission_root_cause_categories

Sample Data

Data Governance

• Owner: Quality & Patient Safety Lead
• Approval process:
• Categories proposed by Quality team based on RCA findings.
• Reviewed by multidisciplinary quality committee.
• Approved by Quality & Patient Safety Committee.
• Update frequency: Annual; ad-hoc when new patterns identified.
• Change notification:
• Communicated to case managers and quality reviewers.
• Historical data mapping considered before deactivating codes.

Validation Rules

• code unique.
• is_preventable must be explicitly set.
• Cannot deactivate categories used in active quality improvement projects without replacement mapping.

Configuration Parameters

Data Load Procedures

1. Initial Load

Sources

• UM criteria and level-of-care: Excel/CSV from UM vendor or internal guidelines.
• Discharge dispositions: HL7 0112 reference + UAE-specific mapping from HIM.
• Post-acute service types and destination facilities: Contracting and Case Management spreadsheets.
• Payer review schedules: Contract abstracts from Policy & Contract Management.
• Readmission risk weights: Analytics model specification.
• Case assignment rules: Case Management staffing plan.
• Care coordination program types: Population Health documentation.
• Root cause categories: Quality & Patient Safety taxonomy.

Process

1. Data extraction & standardisation - Convert all sources to UTF-8 CSV with bilingual columns (display_name_en, display_name_ar). - Ensure codes follow agreed naming conventions (no spaces, uppercase, underscore-separated).

2. Staging import - Load into staging tables (e.g., stg_um_clinical_criteria) via ETL or bulk import. - Validate mandatory fields and referential integrity (e.g., level_of_care_code exists).

3. Data validation - Run validation scripts:

   • Uniqueness of codes.
   • Date ranges (effective_from/effective_to).
   • Cross-reference checks (e.g., payer IDs, department IDs).
   • Generate exception reports for records failing validation.

4. Business review - UM Committee, HIM, Case Management, and Quality teams review sample records and summary counts. - Sign-off captured for audit (per UAE PDPL accountability).

5. Promotion to production - Move validated records from staging to production tables. - Enable configuration flags (e.g., is_active) only after sign-off.

2. Ongoing Synchronisation

• UM Clinical Criteria:
• When using an external UM vendor, schedule periodic JSON/CSV imports via internal API.
• Versioning handled via effective_from/effective_to.
• Payer Review Schedules:
• Triggered by contract updates in Policy & Contract Management (INT-CSM-005).
• API-based updates with change logs.
• Destination Facilities:
• Quarterly reconciliation with Contract Management and facility licensing data (DOH/DHA/MOH).
• Readmission Risk Weights:
• Updated after model recalibration; changes deployed via controlled release process.

3. Import/Export Formats

• Import:
• Preferred: CSV over secure SFTP or internal API (JSON).
• Required columns documented per table schema.
• Date format: YYYY-MM-DD.

• Boolean: TRUE/FALSE.

• Export:

• CSV and JSON exports for:
  • Analytics (e.g., readmission programs).
  • External audits (payer, regulator).
• Exports must respect UAE PDPL:
  • Use pseudonymised identifiers where possible.
  • Exclude direct patient identifiers from master data exports.

4. Validation on Import

For each import job:

1. Syntactic validation - Check file encoding (UTF-8). - Validate headers and required columns. - Validate data types (numeric, dates, booleans).

2. Semantic validation - Referential integrity (e.g., payer_id exists). - Code uniqueness and immutability rules. - Business rules (e.g., review schedules not overlapping).

3. Regulatory & privacy checks - Ensure no patient-level data is present in master data imports. - Log all imports with user, timestamp, and record counts for audit (PDPL accountability).

4. Error handling - Reject file if > X% of rows invalid (configurable, default 5%). - Provide detailed error report (row number, field, error message). - Support partial load with clear logging when appropriate (for non-critical datasets).

This specification provides the master data and configuration foundation for the Case Management module, enabling developers to implement database schemas, admin UIs, and integration points consistent with UAE regulatory and operational requirements.