Patient Portal & Mobile App Master Data & Configuration

Master Data Inventory

Note: Core shared entities (patients, providers, facilities, payers, etc.) are defined in their owning modules and referenced here via foreign keys; they are not redefined as master data in this file.

Setup Sequence

Data sets must be configured in the following dependency order before enabling the patient portal and mobile apps.

Load / Configuration Order (narrative):

1. Supported Languages (MD-PPT-006) – define available UI languages (EN/AR minimum) and RTL behavior.
2. Portal Content (MD-PPT-001) – help, FAQs, onboarding guides in all supported languages.
3. PDPL Consent Texts & Privacy Notices (MD-PPT-012) – bilingual consent and privacy content, including NABIDH/Malaffi references where applicable.
4. Notification Templates (MD-PPT-004) – email/SMS/push templates, localized, referencing PDPL consent where needed.
5. Telehealth Platforms & Config (MD-PPT-007) – WebRTC vendor, TURN/STUN servers, allowed browsers/apps.
6. Payment Methods & Gateways (MD-PPT-008) – payment gateway endpoints, supported methods, currencies.
7. Appointment Types & Visit Reasons (MD-PPT-009) – which appointment types are bookable via portal.
8. Proxy Relationship Types & Access Levels (MD-PPT-010) – parent/guardian, caregiver, etc., with access scopes.
9. Portal Feature Toggles & Access Policies (MD-PPT-011) – enable/disable modules (telehealth, payments, messaging) per facility.
10. Result Release Rules (MD-PPT-005) – delays and exclusions for lab/radiology/notes.
11. NABIDH/Malaffi Sharing Preferences Codes (MD-PPT-013) – patient-facing options for HIE sharing.
12. Provider Profiles (MD-PPT-002) – enriched provider data for search and booking.
13. Form Templates (MD-PPT-003) – digital forms and consents mapped to workflows.
14. Go-Live – open registration and activation workflows.

Master Data Specifications

MD-PPT-001: Portal Content (Help Pages, FAQs)

Purpose

Static and semi-static informational content displayed in the portal and mobile apps: FAQs, how-to guides, contact information, telehealth instructions, PDPL rights explanations, etc. Must be bilingual (EN/AR) and easily maintainable without code changes.

Logical Table: portal_content_pages

Schema

Sample Data

Data Governance

• Owner: Portal Administrator
• Approval:
• Clinical content: relevant Clinical Lead
• Legal/privacy content: Data Protection Officer (DPO) / Legal
• General help/FAQ: Head of Patient Experience / Marketing
• Update Frequency:
• Routine review every 6–12 months
• Immediate updates when workflows or regulations change (e.g., PDPL amendments, NABIDH/Malaffi policy changes)
• Change Process: 1. Content change request submitted via internal ticket. 2. Draft prepared by Portal Administrator / Communications. 3. Review and approval by appropriate approver. 4. Update in CMS / admin UI. 5. Notify support staff and update training materials.

Validation Rules

• content_id unique, uppercase alphanumeric with underscores.
• slug unique, lowercase, only [a-z0-9-].
• Both title_en and title_ar required for all active records.
• category must be in controlled list: {HELP, FAQ, LEGAL, TECH, BILLING, TELEHEALTH}.
• is_public = FALSE for any content referencing patient-specific data.
• last_reviewed_date must be within last 24 months for is_active = TRUE (flag for review otherwise).

MD-PPT-002: Provider Profiles

Purpose

Enriched provider metadata used for patient-facing provider search and appointment booking: specialties, languages, photos, bios, locations. Extends core providers entity from ehr-patient-mgmt.

Logical Table: provider_profiles (1:1 or 1:0..1 with providers)

Schema

Sample Data

Data Governance

• Owner: Medical Staff Office (core data) + Portal Administrator (presentation fields).
• Approval:
• Credentials, specialty: Medical Staff Office.
• Bio, photo: Provider + Marketing/Communications.
• Update Frequency:
• On provider onboarding, role change, or departure.
• Annual review of all profiles.
• Change Process: 1. Provider or department submits update request. 2. Medical Staff Office validates specialty, facility, and status. 3. Portal Administrator updates profile via admin UI. 4. For telehealth enablement, Telehealth Program Manager confirms training and licensing.

Validation Rules

• provider_id must exist and be active in providers.
• primary_facility_id must exist in facilities and be portal-enabled.
• display_name_en and display_name_ar required if is_visible_in_portal = TRUE.
• rating_average between 1.00 and 5.00 if not null; rating_count >= 0.
• telehealth_enabled = TRUE only if telehealth platform configured (MD-PPT-007) and provider licensed for telehealth per DOH/DHA/MOH rules.

MD-PPT-003: Form Templates

Purpose

Defines reusable digital form templates (pre-registration, medical history, consent forms, billing forms) rendered in the portal/app. Each template is versioned and bilingual, with JSON schema for dynamic rendering and mapping to target modules.

Logical Table: form_templates

Schema

Sample Data

Data Governance

• Owner: Portal Administrator (technical), with each form’s content owned by relevant department (e.g., HIM, Legal, Billing).
• Approval:
• Clinical forms: Clinical Governance Committee.
• Consent forms: Legal + DPO + HIM.
• Billing forms: Finance / Revenue Cycle.
• Update Frequency:
• As policies change; at least annual review for consents and PDPL-related forms.
• Change Process: 1. Department submits change request with updated wording and requirements. 2. Legal/DPO review for PDPL and DOH/DHA/MOH compliance (especially for data sharing and telehealth). 3. Form template updated and version incremented; previous version set is_active = FALSE with effective_to. 4. Regression testing in UAT to ensure mappings are correct. 5. Communication to front-line staff.

Validation Rules

• form_template_id unique, uppercase alphanumeric with underscores.
• Only one is_active = TRUE per (form_template_id logical family, category) at a time.
• requires_signature = TRUE implies signature_method in {OTP, drawn, UAE_PASS}.
• effective_from <= effective_to when both present.
• schema_json must be valid JSON and pass schema validation in admin UI.

MD-PPT-004: Notification Templates

Purpose

Templates for email, SMS, and push notifications sent by the portal (appointment reminders, result availability, message alerts, payment confirmations, PDPL notices). Must support placeholders and bilingual content.

Logical Table: notification_templates

Schema

Sample Data

Data Governance

• Owner: Portal Administrator.
• Approval:
• Content: Communications Lead.
• PDPL-related text and opt-in flags: DPO / Compliance.
• Update Frequency: Quarterly review; ad-hoc for new workflows.
• Change Process: 1. Request from business owner (e.g., Billing for payment receipts). 2. Draft prepared and validated for placeholders. 3. Legal/Compliance review for PDPL and DOH/DHA/DHCC messaging rules. 4. Update in admin UI; test with sample notifications. 5. Notify support and update SOPs.

Validation Rules

• template_id unique.
• channel in {EMAIL, SMS, PUSH}.
• If requires_opt_in = TRUE, template must be mapped to a preference flag in portal_preferences.
• Placeholders must follow standard syntax (e.g., {{patient_name}}, {{appointment_datetime}}) and be documented.
• last_reviewed_date within 12 months for is_active = TRUE (flag for review otherwise).

MD-PPT-005: Result Release Rules

Purpose

Defines when and how lab results, radiology reports, and clinical notes are released to patients via the portal, including delays for sensitive results and compliance with DOH/DHA/MOH policies and UAE PDPL transparency requirements.

Logical Table: result_release_rules

Schema

Sample Data

Data Governance

• Owner: Medical Director / HIM.
• Approval: Medical Executive Committee; Compliance for PDPL transparency.
• Update Frequency: Annual review; ad-hoc when regulations or institutional policy change.
• Change Process: 1. Policy change proposed by HIM/Clinical Governance. 2. Impact analysis on patient safety and provider workflow. 3. Approval by Medical Executive Committee. 4. Configuration update and testing in non-production. 5. Communication to clinicians and patients (via portal content).

Validation Rules

• result_type in {LAB, RADIOLOGY, NOTE, PATHOLOGY}.
• delay_hours >= 0.
• If auto_release = FALSE and require_provider_ack = FALSE, result will never appear in portal; such rules must be explicitly approved and documented.
• For sensitive categories (e.g., HIV, genetic tests), is_sensitive = TRUE and either delay_hours > 0 or auto_release = FALSE.

MD-PPT-006: Supported Languages

Purpose

Defines which languages are available in the portal and mobile apps, and which is the default. Supports bilingual EN/AR at minimum and RTL layout for Arabic.

Logical Table: supported_languages

Schema

Sample Data

Data Governance

• Owner: Portal Administrator.
• Approval: CIO + Patient Experience Lead.
• Update Frequency: Rare; when adding/removing languages.
• Change Process: 1. Business case for new language (patient demographics, DOH/DHA guidance). 2. Approval by leadership. 3. Translation of key content and UI strings. 4. Update supported_languages and deploy translations.

Validation Rules

• At least one language with is_default = TRUE.
• Only one is_default = TRUE at any time.
• is_rtl = TRUE only for languages requiring RTL (e.g., ar).
• language_code unique and valid ISO code.

MD-PPT-007: Telehealth Platforms & Config

Purpose

Defines telehealth platform configuration used by the portal for video visits (WebRTC, vendor URLs, supported platforms).

Logical Table: telehealth_platforms

Schema

Sample Data

Data Governance

• Owner: IT / Telehealth Program Manager.
• Approval: CIO; Information Security for ADHICS/NESA compliance.
• Update Frequency: As vendor or configuration changes.
• Change Process: 1. Technical evaluation and security review. 2. Pilot testing with clinicians. 3. Update configuration and mapping in scheduling/telehealth workflows.

Validation Rules

• Only one is_default = TRUE.
• base_url must be HTTPS.
• supported_clients subset of allowed values {Web, iOS, Android}.

MD-PPT-008: Payment Methods & Gateways

Purpose

Defines which payment methods are available in the portal and how they map to payment gateways and billing system codes.

Logical Table: payment_methods

Schema

Logical Table: payment_gateways

Sample Data

payment_gateways

payment_methods

Data Governance

• Owner: Revenue Cycle Manager.
• Approval: CFO; IT Security for gateway.
• Update Frequency: On contract or policy changes.
• Change Process: 1. Finance negotiates payment gateway contracts. 2. IT configures gateway and tests. 3. Portal Administrator updates payment_methods and payment_gateways. 4. Communication to patients if methods added/removed.

Validation Rules

• currency must be AED for UAE billing.
• api_base_url must be HTTPS.
• At least one active online method when Bill View & Online Payment feature is enabled.
• surcharge_percent must comply with UAE Central Bank rules (often 0).

MD-PPT-009: Appointment Types & Visit Reasons (Portal)

Purpose

Defines which appointment types and visit reasons are available for booking via the portal, and how they map to scheduling system codes.

Logical Table: portal_appointment_types

Schema

Logical Table: portal_visit_reasons

Sample Data

portal_appointment_types

portal_visit_reasons

Data Governance

• Owner: Scheduling Manager.
• Approval: Ambulatory Medical Director.
• Update Frequency: Quarterly or as new services are added.
• Change Process: 1. Service line requests new appointment type or visit reason. 2. Scheduling and Clinical leads review capacity and triage implications. 3. Update configuration and test booking flows.

Validation Rules

• scheduling_appt_type_code must exist in scheduling system.
• is_telehealth = TRUE only if telehealth platform configured and provider telehealth-enabled.
• Visit reasons flagged as potentially urgent (e.g., chest pain) must display emergency disclaimer in portal content.

MD-PPT-010: Proxy Relationship Types & Access Levels

Purpose

Defines allowed proxy relationships (e.g., parent, guardian, caregiver) and associated access levels to dependent patient records, in line with UAE legal requirements and PDPL.

Logical Table: proxy_relationship_types

Schema

Sample Data

Data Governance

• Owner: Compliance Officer.
• Approval: Legal Counsel.
• Update Frequency: Rare; when legal or policy changes.
• Change Process: 1. Legal review of UAE federal and emirate-level regulations. 2. Update relationship types and access levels. 3. Update portal content explaining proxy access.

Validation Rules

• default_access_level in {FULL, LIMITED, APPOINTMENTS_ONLY}.
• is_minor_only = TRUE only for relationships applicable to minors.
• requires_documentation = TRUE for any relationship granting FULL access.

MD-PPT-011: Portal Feature Toggles & Access Policies

Purpose

Controls which portal features are enabled per facility or globally (e.g., telehealth, online payments, messaging) and any access constraints.

Logical Table: portal_feature_toggles

Schema

Sample Data

Data Governance

• Owner: Portal Administrator.
• Approval: CIO + relevant clinical/business owners.
• Update Frequency: As services roll out or change.
• Change Process: 1. Request from service line or leadership. 2. Risk and capacity assessment. 3. Configuration update and testing. 4. Communication to patients and staff.

Validation Rules

• If facility-specific record exists, it overrides global (facility_id = NULL) for that facility.
• min_patient_age must be >= 0; if null, no age restriction.

MD-PPT-012: UAE PDPL Consent Texts & Privacy Notices

Purpose

Stores the exact texts for PDPL consent, privacy notice, and data subject rights information presented to patients during registration and in profile settings.

Logical Table: consent_texts

Schema

Sample Data

Data Governance

• Owner: Data Protection Officer.
• Approval: Legal Counsel.
• Update Frequency: On PDPL or policy changes; review at least annually.
• Change Process: 1. Legal drafts updated text. 2. DPO approves. 3. New version created; old version set valid_to. 4. Portal prompts existing users to re-consent if required.

Validation Rules

• Only one is_active = TRUE per consent_code.
• valid_from <= valid_to when valid_to not null.
• requires_explicit_opt_in = TRUE for any non-essential processing (e.g., marketing).

MD-PPT-013: NABIDH/Malaffi Sharing Preferences Codes

Purpose

Defines patient-facing options for sharing data with emirate HIEs (NABIDH in Dubai, Malaffi in Abu Dhabi), aligned with DOH/DHA policies and PDPL.

Logical Table: hie_sharing_preferences

Schema

Sample Data

Data Governance

• Owner: Integration Team + DPO.
• Approval: CIO + Legal + Compliance.
• Update Frequency: When DOH/DHA HIE policies change.
• Change Process: 1. Review updated NABIDH/Malaffi participation rules. 2. Adjust options and defaults accordingly. 3. Communicate changes to patients and update consent texts.

Validation Rules

• Exactly one is_default = TRUE.
• Options must align with regulator requirements; OPT_OUT may be disabled if not permitted for certain data types.

Configuration Parameters

Key system configuration settings for the patient portal & mobile app.

Data Load Procedures

1. Initial Load

Portal Content (MD-PPT-001)

• Import from CSV/JSON prepared by Communications team.
• Fields: content_id, slug, title_en, title_ar, body_en, body_ar, category, is_public, sort_order.
• Validation:
• Check uniqueness of content_id and slug.
• Ensure bilingual titles and bodies present.

Provider Profiles (MD-PPT-002)

• Source: export from providers table + HR/Marketing spreadsheets.
• Import format: CSV or JSON via admin API.
• Validation:
• provider_id exists in providers.
• primary_facility_id exists in facilities.
• Required bilingual fields populated.

Form Templates (MD-PPT-003)

• Source: JSON files per template (schema + mapping).
• Import via admin UI or API.
• Validation:
• JSON schema passes internal validator.
• target_module matches known module IDs.
• Signature requirements consistent with consent type.

Notification Templates (MD-PPT-004)

• Source: CSV/JSON from Communications.
• Validation:
• Placeholders match documented list.
• PDPL-related templates reviewed by DPO.

Result Release Rules (MD-PPT-005)

• Source: HIM policy document converted to CSV.
• Validation:
• No conflicting rules for same result_type/sub_type/facility_id.
• Sensitive categories flagged correctly.

Supported Languages (MD-PPT-006)

• Manually configured via admin UI.
• Ensure at least en and ar active.

Telehealth Platforms (MD-PPT-007)

• Manually configured by IT.
• Test connectivity and encryption.

Payment Methods & Gateways (MD-PPT-008)

• Source: Finance/IT configuration.
• Test transactions in sandbox environment.

Appointment Types & Visit Reasons (MD-PPT-009)

• Source: Scheduling system export.
• Map to portal-specific IDs.

Proxy Relationship Types (MD-PPT-010)

• Source: Legal/Compliance policy.
• Manual entry or CSV import.

Feature Toggles (MD-PPT-011)

• Initial configuration based on go-live scope.
• Manual via admin UI.

Consent Texts (MD-PPT-012)

• Source: Legal-approved documents.
• Import as HTML/markdown text.

HIE Sharing Preferences (MD-PPT-013)

• Source: DOH/DHA guidance.
• Manual configuration.

2. Ongoing Synchronization

• Provider Profiles:
• Daily sync from HR/credentialing system for status, specialty, facility.

• Marketing content (bio, photo) updated as needed via admin UI.

• Form Templates:

• Versioned updates; old versions retained for audit.

• Changes triggered by policy updates.

• Notification Templates:

• Rare changes; tracked via change management.

• Result Release Rules:

• Updated when clinical policies change; require governance approval.

• Payment Gateways:

• Monitor pci_dss_cert_expiry; alert before expiry.

• Consent Texts & HIE Preferences:

• Updated when PDPL or HIE policies change; may trigger re-consent flows.

3. Import/Export Formats

• CSV: For bulk administrative data (provider profiles, appointment types, visit reasons).
• JSON: For complex structures (form templates, mapping configs).
• API:
• FHIR R4 for clinical data (not master data itself but used by portal).
• Internal REST APIs for admin operations (create/update master data).

4. Validation on Import

• Schema validation (required fields, data types).
• Referential integrity checks against shared entities (providers, facilities, users).
• Business rule validation (e.g., only one default language, one default HIE preference).
• Dry-run mode for bulk imports to show errors without committing.
• Audit logging of all master data changes (who, when, before/after values) to support PDPL accountability.

This specification provides the master data and configuration foundation for the Patient Portal & Mobile App module. Application tables such as portal_accounts, portal_sessions, portal_messages, etc., are transactional and defined in the data model documentation, not as master data here.