Patient Access Master Data & Configuration

Master Data Inventory

Note: MD-PAC-007 and MD-PAC-008 are views/snapshots of master data owned by policy-contract-mgmt, configured here for Patient Access use (no independent coding systems defined).

Setup Sequence

Data sets must be loaded/configured in the following dependency order.

Load Sequence Explanation

1. UAE Payer Master (MD-PAC-007) – foundational payer list (Daman, THIQA, Oman Insurance, etc.), synced from Policy & Contract Mgmt.
2. Payer Eligibility Endpoints (MD-PAC-001) – depends on payer list; defines technical connectivity per payer.
3. Referral Type Codes (MD-PAC-006) – uses payer codes; defines which referral types are valid per payer.
4. Authorization Service Categories (MD-PAC-002) – maps services to auth categories per payer.
5. Coverage Rule Snapshots (MD-PAC-008) – derived from coverage_rules; used by Patient Access workflows.
6. Pre-Registration Question Sets (MD-PAC-005) – uses coverage rules and visit types to determine required questions.
7. Financial Assistance Programs (MD-PAC-003) – base catalogue of assistance options.
8. Payment Plan Templates (MD-PAC-004) – depends on financial assistance policies and finance rules.
9. Work Queue Definitions (MD-PAC-009) – uses endpoints, referral types, auth categories, and pre-reg rules to define routing.
10. Communication Templates (MD-PAC-010) – uses all above to generate accurate EN/AR messages (eligibility, auth, financial counseling).

Master Data Specifications

MD-PAC-001: Payer Eligibility Endpoints

Purpose

Defines technical connectivity details for real-time eligibility checks and prior authorization with UAE payers (via DHA eClaimLink, DOH eClaims/Shafafiya, and direct payer APIs). Used by:

• WF-PAC-001 Insurance Eligibility Verification
• WF-PAC-002 Prior Authorization Management
• WF-PAC-006 Pre-Registration

Logical Table: pac_payer_eligibility_endpoints

Schema

Sample Data

Data Governance

• Owner: IT / RCM Team
• Approval Process: 1. Request from RCM or IT (new payer or endpoint change). 2. Technical validation in non-production environment. 3. Security review (ADHICS / UAE PDPL compliance for data in transit). 4. Approval by Patient Access Manager + IT Director. 5. Scheduled deployment to production with connectivity test.
• Update Frequency: As payer connectivity changes; minimum quarterly review of status and last_verified_datetime.
• Change Notification:
• Email notification to Patient Access, Billing, and Integration teams.
• System banner for Registration Clerks if an endpoint is degraded or inactive.
• Audit log entry for each change (who, when, what).

Validation Rules

• endpoint_id must be unique (UUID format).
• payer_id must reference an existing payers.payer_id or be 0 for SELF-PAY.
• endpoint_code unique per payer; uppercase letters, digits, hyphen only (^[A-Z0-9\-]+$).
• status ∈ {ACTIVE, INACTIVE, DEPRECATED}.
• channel_type ∈ {DHA_ECLAIMLINK, DOH_ECLAIMS, DIRECT_API, PORTAL_ONLY}.
• If channel_type ≠ PORTAL_ONLY, then api_base_url and auth_method must be populated.
• effective_to must be NULL or ≥ effective_from.
• last_verified_datetime must be ≤ current datetime.
• For UAE PDPL compliance, notes must not contain any patient-identifiable information.

MD-PAC-002: Authorization Service Categories

Purpose

Defines standardized service categories used to determine when prior authorization is required, how requests are grouped, and routing rules per payer. Used in:

• WF-PAC-002 Prior Authorization Management
• WF-PAC-004 Patient Cost Estimation
• WF-PAC-006 Pre-Registration

Logical Table: pac_auth_service_categories

Schema

Payer-specific overrides are stored in a separate mapping table (not detailed here) linking payer_id + category_code to override flags.

Sample Data

Data Governance

• Owner: Authorization Team Lead
• Approval Process: 1. Payer policy change detected (circular, eClaimLink notice, DOH circular). 2. Authorization team analyses impact and proposes category updates. 3. Review by Revenue Cycle Director and Medical Director (for clinical impact). 4. Approved changes implemented in test, validated with sample cases. 5. Deployment to production with communication to Authorization Specialists and Registration Clerks.
• Update Frequency: Monthly review; immediate update on critical payer changes.
• Change Notification:
• Release notes in RCM change log.
• In-app notification for Authorization Specialists.
• Training update if change significantly alters workflow.

Validation Rules

• category_code unique, uppercase letters, digits, underscore only.
• priority_level ∈ {ROUTINE, URGENT, EMERGENT}.
• If default_auth_required = TRUE, then at least one of doh_auth_required, dha_auth_required, moh_auth_required, selfpay_auth_required must be TRUE.
• effective_to NULL or ≥ effective_from.
• typical_turnaround_days must be NULL or > 0.
• example_cpt_codes and example_icd10am_codes must be comma-separated lists without spaces (UI can format).

MD-PAC-003: Financial Assistance Programs

Purpose

Defines available financial assistance and charity programs for patients, including eligibility criteria and discount structures, aligned with facility policy and UAE regulations (e.g., Emirate-level social support schemes). Used in:

• WF-PAC-004 Patient Cost Estimation
• WF-PAC-005 Financial Counseling

Logical Table: pac_financial_assistance_programs

Schema

Sample Data

Data Governance

• Owner: Financial Counseling Manager
• Approval Process: 1. Proposal from Finance or Counseling (new program or change). 2. Financial impact analysis by Finance Director. 3. Compliance review (to ensure alignment with UAE PDPL for data used in means tests and any Emirate-level regulations). 4. Approval by CFO / Finance Committee. 5. Configuration update and communication to Financial Counselors and Patient Access.
• Update Frequency: Annual formal review; ad-hoc for new programs.
• Change Notification:
• Email to Financial Counselors and Registration Supervisors.
• Update to counseling SOPs.
• System notification if a program is deactivated.

Validation Rules

• program_code unique, uppercase letters, digits, underscore only.
• max_discount_percentage between 0 and 100.
• If program_type = 'CHARITY', then requires_means_test must be TRUE.
• If requires_government_approval = TRUE, documentation_required_en and documentation_required_ar must not be NULL.
• effective_to NULL or ≥ effective_from.
• For UAE PDPL, eligibility_criteria_* and documentation_required_* must not include examples with real patient identifiers.

MD-PAC-004: Payment Plan Templates

Purpose

Defines standard payment plan structures used by Financial Counselors to set up instalment arrangements for patient balances. Used in:

• WF-PAC-004 Patient Cost Estimation
• WF-PAC-005 Financial Counseling

Logical Table: pac_payment_plan_templates

Schema

Sample Data

Data Governance

• Owner: Finance Director
• Approval Process: 1. Proposal from Finance or RCM. 2. Financial modelling and risk assessment. 3. Approval by CFO / Finance Committee. 4. Legal review to ensure compliance with UAE financial regulations and PDPL (for auto-debit consents). 5. Configuration in HIS and training for Financial Counselors.
• Update Frequency: As needed (typically annual).
• Change Notification:
• Email to Financial Counselors and Billing.
• Update to patient-facing materials (brochures, portal content).
• System-level change log.

Validation Rules

• template_code unique, uppercase letters, digits, underscore.
• min_balance_amount ≤ max_balance_amount.
• max_term_months > 0.
• min_initial_payment_percentage between 0 and 100.
• interest_rate_annual ≥ 0.
• If interest_rate_annual > 0, ensure facility policy allows interest charging and patient consent capture is configured.
• effective_to NULL or ≥ effective_from.

MD-PAC-005: Pre-Registration Question Sets

Purpose

Defines configurable sets of questions used for pre-registration, tailored by visit type, department, and payer requirements. Supports bilingual EN/AR and PDPL-compliant consent capture. Used in:

• WF-PAC-006 Pre-Registration
• WF-PAC-001 Insurance Eligibility Verification (to ensure required insurance data is collected)

Logical Tables (conceptual):

• pac_prereg_question_sets – header per visit type.
• pac_prereg_questions – individual questions within a set.

Schema – pac_prereg_question_sets

Schema – pac_prereg_questions

Sample Data – pac_prereg_question_sets

Sample Data – pac_prereg_questions

Data Governance

• Owner: Patient Access Manager
• Approval Process: 1. Request from Registration, Legal, or Compliance (e.g., new PDPL consent wording). 2. Review by Patient Access Governance Committee and Legal (for PDPL and DOH/DHA requirements). 3. User acceptance testing with Registration Clerks and Patient Portal. 4. Scheduled deployment with training.
• Update Frequency: Semi-annual review; immediate updates for regulatory changes (e.g., PDPL amendments, DOH/DHA circulars).
• Change Notification:
• In-app notification for Registration Clerks.
• Portal release notes for patients if question sets change significantly.
• Updated training materials.

Validation Rules

• set_code unique.
• sequence_no must be positive and unique within a set_code.
• field_type ∈ {TEXT, NUMBER, DATE, DROPDOWN, CHECKBOX, SIGNATURE}.
• If field_type = 'DROPDOWN', options_json must be valid JSON with options array.
• If field_code relates to Emirates ID, validation_regex should enforce 784-YYYY-NNNNNNN-C format.
• If requires_consent_pdpl = TRUE, at least one question in the set must have field_code like PDPL_CONSENT and required = TRUE.

MD-PAC-006: Referral Type Codes

Purpose

Defines standardized referral types used in Referral Management (WF-PAC-003), including payer-specific requirements and visit limits.

Logical Table: pac_referral_type_codes

Schema

Sample Data

Data Governance

• Owner: Patient Access Manager
• Approval Process: 1. Payer policy change or new network arrangement identified. 2. Proposal drafted by Patient Access with input from Policy & Contract Mgmt. 3. Review by Medical Director and RCM Lead. 4. Approved changes configured and tested.
• Update Frequency: Quarterly or as payer/network changes occur.
• Change Notification:
• Email to Registration, Scheduling, and Authorization teams.
• Update to referral SOPs.

Validation Rules

• referral_type_code unique, uppercase letters, digits, underscore.
• default_authorized_visits > 0.
• default_validity_days > 0.
• If requires_payer_approval = TRUE, then requires_referral_number must be TRUE.
• effective_to NULL or ≥ effective_from.

MD-PAC-007: UAE Payer Master (Local View)

Purpose

Local read-only view of payer master data for Patient Access, sourced from policy-contract-mgmt. Used for dropdowns and routing in all Patient Access workflows.

Logical View: vw_pac_payers

Schema (View Fields)

Sample Data

Governance & Validation

• Owner: Policy & Contract Mgmt module.
• Patient Access: Read-only; no direct edits.
• Sync: Real-time or nightly refresh.
• Validation: Enforced in owning module; Patient Access validates that active = TRUE when assigning payer.

MD-PAC-008: Coverage Rule Snapshots for Patient Access

Purpose

Denormalized snapshot of coverage rules relevant to Patient Access (eligibility, auth, referrals), derived from coverage_rules in Policy & Contract Mgmt. Used by:

• WF-PAC-001 Eligibility Verification
• WF-PAC-002 Prior Authorization Management
• WF-PAC-003 Referral Management
• WF-PAC-004 Cost Estimation

Logical Table: pac_coverage_rule_snapshots

Schema (Core Fields)

Sample Data

Data Governance

• Owner: Policy & Contract Mgmt (source); Patient Access Manager (consumer).
• Sync Process:
• Nightly ETL job to refresh snapshot from coverage_rules.
• On-demand sync for urgent payer changes.
• Approval: Changes approved in Policy & Contract Mgmt; Patient Access does not alter rules.
• Change Notification:
• RCM-wide communication for major benefit changes.
• In-app hints (e.g., “New auth requirement for MRI with Daman effective 01-Mar-2026”).

Validation Rules

• rule_id must exist in coverage_rules.
• service_category_code must exist in pac_auth_service_categories if not NULL.
• referral_type_code must exist in pac_referral_type_codes if not NULL.
• effective_to NULL or ≥ effective_from.
• last_synced_datetime must be updated on each sync.

MD-PAC-009: Patient Access Work Queue Definitions

Purpose

Defines work queues for Patient Access staff (eligibility, auth, referrals, pre-reg, counseling), including filters and routing rules. Supports dashboards and workload distribution.

Logical Table: pac_work_queue_definitions

Schema

Sample Data

Example filter_definition_json for ELIG_PENDING (conceptual):

{
  "table": "eligibility_checks",
  "conditions": [
    {"field": "status", "operator": "IN", "value": ["PENDING", "ERROR"]},
    {"field": "check_datetime", "operator": ">=", "value": "NOW-24H"}
  ]
}

Data Governance

• Owner: Patient Access Manager
• Approval Process: 1. Request from supervisors to add/modify queue. 2. Review by Patient Access Manager and IT. 3. Test in non-production environment.
• Update Frequency: Quarterly or as operational needs change.
• Change Notification:
• Email to affected staff.
• Dashboard update notes.

Validation Rules

• queue_code unique.
• module_area ∈ {ELIGIBILITY, AUTH, REFERRAL, PREREG, COUNSELING}.
• filter_definition_json must be valid JSON and reference existing tables/fields.
• sla_hours > 0 if not NULL.

MD-PAC-010: Communication Templates (EN/AR)

Purpose

Defines reusable EN/AR communication templates for SMS, email, and portal messages related to Patient Access (pre-reg invitations, eligibility results, auth updates, financial counseling). Must comply with UAE PDPL for consent and data minimisation.

Logical Table: pac_communication_templates

Schema

Sample Data

Example body_en / body_ar for PREREG_INVITE_SMS:

• body_en:
  Dear {patient_first_name}, please complete your pre-registration for your appointment on {appointment_date} at {facility_name}. Click: {prereg_link}

• body_ar:
  عزيزي/عزيزتي {patient_first_name}، يرجى إكمال التسجيل المسبق لموعدك بتاريخ {appointment_date} في {facility_name}. اضغط هنا: {prereg_link}

allowed_placeholders: {patient_first_name},{appointment_date},{facility_name},{prereg_link}

Data Governance

• Owner: Patient Access Manager
• Approval Process: 1. Draft by Patient Access / Communications team. 2. Legal and Compliance review for UAE PDPL and DOH/DHA messaging guidelines. 3. Translation review for Arabic accuracy. 4. Final approval by Communications Lead.
• Update Frequency: Quarterly review; ad-hoc for regulatory or branding changes.
• Change Notification:
• Email to Patient Access staff.
• Update in communication SOPs.

Validation Rules

• template_code unique.
• channel ∈ {SMS, EMAIL, PORTAL}.
• pdpl_compliant must be TRUE before active can be set to TRUE.
• body_en and body_ar must only use placeholders listed in allowed_placeholders.
• No hard-coded patient identifiers in template bodies.

Configuration Parameters

Data Load Procedures

1. Initial Load

Payer Eligibility Endpoints (MD-PAC-001)

• Source: DHA eClaimLink documentation, DOH eClaims/Shafafiya specs, payer integration guides.
• Format: Initial CSV or JSON file with endpoint definitions.
• Process: 1. Compile list of contracted payers from Policy & Contract Mgmt. 2. For each payer, obtain technical endpoint details. 3. Populate template CSV/JSON and import via admin UI or ETL. 4. Validate connectivity in test environment.
• Validation:
• Ensure all active payers have at least one endpoint or are explicitly marked as PORTAL_ONLY or SELF-PAY.
• Test sample eligibility and auth calls.

Authorization Service Categories (MD-PAC-002)

• Source: Payer manuals, eClaimLink/DOH guidelines, internal policies.
• Format: CSV with category definitions.
• Process: 1. Define initial category list with Authorization Team. 2. Map to typical CPT/ICD-10-AM codes. 3. Import via configuration UI.
• Validation:
• Cross-check with coverage rules in Policy & Contract Mgmt.
• Run test orders through WF-PAC-002 to confirm correct auth prompts.

Financial Assistance Programs (MD-PAC-003) & Payment Plan Templates (MD-PAC-004)

• Source: Facility finance policies.
• Format: Manual entry or CSV import.
• Validation:
• Confirm discount percentages and terms match approved policies.
• Test sample patient balances to ensure correct plan options appear.

Pre-Registration Question Sets (MD-PAC-005)

• Source: Registration requirements, PDPL consent text, DOH/DHA/MOH requirements.
• Format: Admin UI configuration or JSON import.
• Validation:
• Ensure mapping to patient tables is correct.
• Test portal and clerk-driven pre-registration flows.

Referral Type Codes (MD-PAC-006)

• Source: Payer referral policies, internal referral workflows.
• Format: CSV or UI entry.
• Validation:
• Confirm referral prompts appear correctly at scheduling and check-in.

Work Queue Definitions (MD-PAC-009) & Communication Templates (MD-PAC-010)

• Source: Operational design workshops, Communications team.
• Format: Admin UI configuration.
• Validation:
• Verify queues show correct items.
• Send test SMS/email via sandbox gateway.

2. Ongoing Synchronization

• Payer Master & Coverage Rules (MD-PAC-007, MD-PAC-008):
• Nightly ETL from Policy & Contract Mgmt.
• On-demand sync endpoint for urgent payer changes.

• Logging of sync status and row counts.

• Eligibility Endpoints (MD-PAC-001):

• Manual updates when payer connectivity changes.

• Quarterly review of last_verified_datetime with automated ping tests.

• Communication Templates (MD-PAC-010):

• Versioning of templates; keep history for audit.
• Legal review date tracked in last_reviewed_date.

3. Import/Export Formats

• CSV:
• Used for bulk initial load of MD-PAC-001, 002, 003, 004, 006.
• UTF-8 encoding to support Arabic text.

• Header row must match field names.

• JSON:

• Used for complex structures (MD-PAC-005 question sets, MD-PAC-009 filters, MD-PAC-010 templates).

• REST admin API endpoints to import/export configuration.

• API:

• Internal APIs to sync payer and coverage data from Policy & Contract Mgmt.
• Secure endpoints with mutual TLS and role-based access.

4. Validation on Import

For all imports:

1. Schema Validation: - Check required fields present. - Data types and length constraints.
2. Referential Integrity: - Validate FK references (payer_id, plan_id, department_id, etc.).
3. Business Rules: - Apply validation rules defined per data set (e.g., percentages, date ranges).
4. UAE-Specific Checks: - Emirates ID patterns in any relevant question validations. - PDPL consent presence for portal pre-registration.
5. Dry Run Mode: - Provide preview of changes and errors before committing.
6. Audit Logging: - Record import file name, user, timestamp, and summary (rows inserted/updated, errors).

This master data and configuration specification provides the foundation for implementing the Patient Access module in a UAE-compliant, configurable, and maintainable way.