Physician Portal & Mobile App Master Data & Configuration

Master Data Inventory

Note: Core entities (patients, providers, facilities, encounters, payers) are governed in their owning modules and only referenced here. See ../ehr-patient-mgmt/06-master-data.md and ../scheduling/06-master-data.md.

Setup Sequence

Data sets must be configured in the following dependency order before physician portal go‑live.

Load / Configuration Order

1. MD-PHY-011: UAE Facility & Department Mobile Mappings
2. MD-PHY-006: Provider Specialty Groups
3. MD-PHY-012: Mobile Role-to-Permission Profiles
4. MD-PHY-010: Telehealth Configuration (visit types & platforms)
5. MD-PHY-005: Handoff Templates (I-PASS variants)
6. MD-PHY-009: Mobile Inbox Item Types & Statuses
7. MD-PHY-008: Mobile Task Types & Priorities
8. MD-PHY-007: Mobile Patient List Definitions
9. MD-PHY-004: Notification Rule Types & Channels
10. MD-PHY-003: Mobile Note Templates
11. MD-PHY-002: Mobile Order Set Library
12. MD-PHY-001: Order Favorites / Quick Orders (per provider personalization)

Master Data Specifications

MD-PHY-001: Order Favorites / Quick Orders

a. Purpose

Provider- and department-specific shortcuts for frequently used orders (medications, labs, imaging, consults, nursing). Used heavily in:

• WF-PHY-002 Mobile Order Entry
• SCR-PHY-003 Mobile Order Entry screen

Favorites reduce taps and support safe, standardized ordering on mobile.

b. Schema

Table: physician_favorites (owned by this module; core structure extended with master-data attributes)

c. Sample Data

d. Data Governance

• Owner:
• Personal favorites: Individual provider
• Department defaults: Clinical Informatics + Department Chair
• Approval process:
• Personal: No formal approval; subject to audit for safety.
• Department defaults: Request → Clinical Informatics build → Department Chair approval → Portal Admin deploy.
• Update frequency:
• Personal: On demand.
• Department defaults: At least annually; after major guideline changes.
• Change notification:
• Department default changes communicated via email + in-app banner; change log maintained for 2 years.

e. Validation Rules

• provider_id must exist in providers.
• (is_department_default = TRUE) implies specialty_group_code NOT NULL.
• favorite_type in (ORDER, ORDER_SET, PATIENT, NOTE_TEMPLATE, LINK).
• display_order must be unique per (provider_id, favorite_type) for active favorites.
• item_id must map to a valid orderable / entity in its source module (validated via internal API).

MD-PHY-002: Mobile Order Set Library

a. Purpose

Subset of enterprise order sets optimized for mobile entry (shorter, grouped, minimal scrolling). Used in WF-PHY-002 and SCR-PHY-003.

b. Schema

Table: mobile_order_sets

Child Table: mobile_order_set_items

c. Sample Data

mobile_order_sets

mobile_order_set_items (excerpt)

d. Data Governance

• Owner: Clinical Informatics Team
• Approval process:
• Draft by Clinical Informatics → Review by relevant Department Chair → P&T Committee approval for medication content → CMO sign-off for high-risk conditions.
• Update frequency: Annual review; ad-hoc when guidelines change (e.g., MOH circulars, DOH/DHA clinical guidance).
• Change notification:
• Release notes to affected specialties; in-app notification for changed sets; archived versions retained for 5 years for medico-legal traceability.

e. Validation Rules

• code unique across mobile_order_sets.
• base_order_set_id must exist and be active in CPOE order set master.
• All orderable_id values must be valid and active in CPOE orderable catalog.
• review_status = APPROVED required before mobile_enabled = TRUE.
• At least one mobile_order_set_item with default_selected = TRUE per set.

MD-PHY-003: Mobile Note Templates

a. Purpose

Mobile-optimized clinical note templates (shorter, structured, voice-friendly) used in WF-PHY-006 and SCR-PHY-009.

b. Schema

Table: mobile_note_templates

c. Sample Data

Example mobile_sections_json (for 301):

[
  {"code": "SUBJ", "label_en": "Subjective", "label_ar": "الشكوى", "required": false},
  {"code": "OBJ", "label_en": "Objective", "label_ar": "الفحص", "required": false},
  {"code": "ASSESS", "label_en": "Assessment", "label_ar": "التقييم", "required": true},
  {"code": "PLAN", "label_en": "Plan", "label_ar": "الخطة", "required": true},
  {"code": "FOLLOWUP", "label_en": "Follow-up", "label_ar": "المتابعة", "required": false}
]

d. Data Governance

• Owner: Clinical Informatics; oversight by Documentation Committee.
• Approval process:
• Draft by Clinical Informatics → Department clinical lead review → Documentation Committee approval → CMO sign-off for global templates.
• Update frequency: Semi-annual review; ad-hoc for regulatory/documentation changes (e.g., DOH/DHA documentation standards).
• Change notification:
• Email + in-app message to affected specialties; old templates retired but not deleted.

e. Validation Rules

• code unique across mobile_note_templates.
• base_template_id must exist and be active in EHR note template master.
• mobile_sections_json must be valid JSON and include at least one required section.
• Only one template per (specialty_group_code, note_type) can have is_default_for_specialty = TRUE and is_active = TRUE.

MD-PHY-004: Notification Rule Types & Channels

a. Purpose

Defines system-level notification types and allowed channels (in-app, push, email, SMS) used by physician_preferences and WF-PHY-003 / WF-PHY-004 / WF-PHY-005 / WF-PHY-008.

b. Schema

Table: notification_rule_types

c. Sample Data

d. Data Governance

• Owner: Portal Administrator + Clinical Informatics.
• Approval process:
• New rule type or change to is_mandatory/severity requires CMO + IT Director approval and PDPL impact assessment (for SMS/email).
• Update frequency: Quarterly review; ad-hoc for new clinical workflows or regulatory requirements (e.g., DOH/DHA alerting policies).
• Change notification:
• In-app banner + email to all portal users; updated notification preference UI.

e. Validation Rules

• rule_type_code unique.
• At least one channel must be TRUE for each active rule.
• For is_mandatory = TRUE, default_channel_in_app must be TRUE.
• SMS channel (default_channel_sms) only allowed for categories RESULT, SYSTEM, TASK and must comply with UAE PDPL consent and opt-out tracking (enforced at application layer).

MD-PHY-005: Handoff Templates (I-PASS Variants)

a. Purpose

Defines structured handoff templates used in WF-PHY-007 and SCR-PHY-007, based on I-PASS (Illness severity, Patient summary, Action list, Situation awareness, Synthesis by receiver).

b. Schema

Table: handoff_templates

c. Sample Data

d. Data Governance

• Owner: Patient Safety Officer.
• Approval process:
• Developed by Patient Safety team → Reviewed by relevant Department Heads → Approved by Patient Safety Committee and CMO.
• Update frequency: Annual review; after any serious incident related to handoff quality.
• Change notification:
• Communicated via clinical governance channels; training updates; in-app help updated.

e. Validation Rules

• code unique.
• At least includes_patient_summary and includes_action_list must be TRUE.
• Only one active template per specialty can have is_default_for_specialty = TRUE.

MD-PHY-006: Provider Specialty Groups

a. Purpose

Logical grouping of providers for portal configuration (favorites, order sets, note templates, handoff templates, patient lists). Derived from credentialing and DOH/DHA/MOH specialty codes.

b. Schema

Table: provider_specialty_groups

c. Sample Data

d. Data Governance

• Owner: Medical Staff Office.
• Approval process:
• New specialty group or mapping change requires Medical Staff Director approval and alignment with DOH/DHA/MOH licensing.
• Update frequency: On credentialing changes; annual review.
• Change notification:
• IT and Clinical Informatics notified; may trigger updates to defaults (favorites, templates).

e. Validation Rules

• specialty_group_code unique.
• At least one of doh_specialty_code, dha_specialty_code, moh_specialty_code must be populated.
• default_role_name must map to an existing role in roles master.

MD-PHY-007: Mobile Patient List Definitions

a. Purpose

Defines standard patient lists available on SCR-PHY-006 (Schedule & Patient List) and WF-PHY-001 / WF-PHY-005 (e.g., "My Inpatients", "On-call List", "Clinic Today").

b. Schema

Table: mobile_patient_list_definitions

c. Sample Data

Example filter_definition_json (for MY_INPATIENTS):

{
  "encounter_type": "INPATIENT",
  "assigned_provider": "CURRENT_USER",
  "status": ["ADMITTED", "OBSERVATION"]
}

d. Data Governance

• Owner: Clinical Informatics.
• Approval process:
• New standard list or filter change requires Clinical Informatics Lead + CMO approval.
• Update frequency: Annual review; ad-hoc for workflow changes.
• Change notification:
• In-app tooltip updates; short communication to affected roles.

e. Validation Rules

• code unique.
• list_type in (INPATIENT, OUTPATIENT, ONCALL, CUSTOM).
• filter_definition_json must be valid JSON and use only supported filter keys.
• For is_editable_by_user = FALSE, filters cannot reference user-modifiable fields.

MD-PHY-008: Mobile Task Types & Priorities

a. Purpose

Defines task categories and priority levels used in SCR-PHY-008 and WF-PHY-008 (Clinical Task Management).

b. Schema

Table: task_types

Table: task_priorities

c. Sample Data

task_priorities

task_types

d. Data Governance

• Owner: Clinical Informatics.
• Approval process:
• New task type or SLA change requires CMO approval; may involve Patient Safety for critical tasks.
• Update frequency: Annual review; after incident reviews or workflow changes.
• Change notification:
• Communicated via clinical governance; updated in training materials.

e. Validation Rules

• task_type_code and priority_code unique.
• default_priority_code must exist in task_priorities.
• sla_hours must be positive for clinical tasks; can be NULL for non-clinical.
• CRITICAL priority must have the highest sort_order.

MD-PHY-009: Mobile Inbox Item Types & Statuses

a. Purpose

Standardizes inbox item classification and lifecycle for SCR-PHY-005 (Unified Inbox) and WF-PHY-003 / WF-PHY-004.

b. Schema

Table: inbox_item_types

Table: inbox_status_codes

c. Sample Data

inbox_item_types

inbox_status_codes

d. Data Governance

• Owner: Portal Administrator.
• Approval process:
• New item type or status requires Clinical Informatics + IT Director approval.
• Update frequency: Rare; reviewed annually.
• Change notification:
• UI labels and help updated; minimal user impact.

e. Validation Rules

• item_type_code and status_code unique.
• At least one non-terminal status must exist.
• Status transitions enforced at application layer (e.g., cannot move from ARCHIVED back to UNREAD).

MD-PHY-010: Telehealth Configuration (Visit Types & Platforms)

a. Purpose

Defines telehealth visit types and technical platforms for SCR-PHY-010 (Telehealth Consultation) and related workflows.

b. Schema

Table: telehealth_visit_types

Table: telehealth_platforms

c. Sample Data

telehealth_visit_types

telehealth_platforms

d. Data Governance

• Owner: Telehealth Program Manager.
• Approval process:
• New visit type: CMO + Finance approval (billing); ensure payer coverage (e.g., Daman, THIQA).
• New platform: CIO + CISO approval; ADHICS/NESA compliance; PDPL DPIA.
• Update frequency: Quarterly review; ad-hoc for payer/regulatory changes.
• Change notification:
• Communicated to clinicians and scheduling; training updates.

e. Validation Rules

• visit_type_code and platform_code unique.
• is_billable = TRUE requires valid cpt_code.
• is_end_to_end_encrypted = TRUE required for all active platforms (per ADHICS/NESA).

MD-PHY-011: UAE Facility & Department Mobile Mappings

a. Purpose

Maps facilities/departments to mobile portal context, including NABIDH/Malaffi IDs for correct routing of results and schedules.

b. Schema

Table: mobile_facility_mappings

Table: mobile_department_mappings

c. Sample Data

mobile_facility_mappings

mobile_department_mappings

d. Data Governance

• Owner: IT / Integration Team.
• Approval process:
• New facility/department mapping requires CIO approval and coordination with NABIDH/Malaffi registration.
• Update frequency: On facility/department changes; rare.
• Change notification:
• Communicated to all clinicians at affected facility; may affect patient list behavior.

e. Validation Rules

• facility_id and department_id must exist and be active in master tables.
• At least one of nabidh_facility_code, malaffi_facility_code must be populated for facilities participating in HIE.
• default_patient_list_code must exist in mobile_patient_list_definitions.

MD-PHY-012: Mobile Role-to-Permission Profiles

a. Purpose

Defines default permission bundles per role for the portal/mobile context, aligning with roles defined in the module brief (Physician, NP/PA, Nurse, Specialist Consultant, CMO, Portal Administrator).

b. Schema

Table: mobile_role_permission_profiles

c. Sample Data

d. Data Governance

• Owner: Portal Administrator; oversight by CMO + CIO.
• Approval process:
• Any change to default permissions requires joint approval by CMO and CIO; security review for PDPL compliance.
• Update frequency: On role model changes; rare.
• Change notification:
• Communicated to affected users; audit trail maintained.

e. Validation Rules

• (role_name, permission_code) must be unique.
• role_name must exist in roles master.
• Non-configurable permissions (is_configurable = FALSE) cannot be changed at user level.

Configuration Parameters

Data Load Procedures

1. Initial Load

• Provider Specialty Groups (MD-PHY-006)
• Source: Credentialing system / HR.
• Format: CSV or API export with provider ID, specialty codes.

• Process: Map DOH/DHA/MOH specialty codes to internal specialty_group_code; load into provider_specialty_groups.

• Facility & Department Mappings (MD-PHY-011)

• Source: Facilities master, NABIDH/Malaffi registration documents.
• Format: CSV or JSON.

• Process:

  1. Extract active facilities/departments.
  2. Add NABIDH/Malaffi IDs.
  3. Load into mobile_facility_mappings and mobile_department_mappings.

• Role-to-Permission Profiles (MD-PHY-012)

• Source: Security design document.
• Format: CSV.

• Process: Pre-load standard profiles for all roles.

• Telehealth Configuration (MD-PHY-010)

• Source: Telehealth program office.
• Format: Configuration JSON.

• Process: Load visit types and platforms; validate encryption flags.

• Handoff Templates, Patient Lists, Task Types, Inbox Types (MD-PHY-005, 007, 008, 009)

• Source: Clinical workflow design.
• Format: CSV/JSON.

• Process: Load after sign-off from CMO/Patient Safety/Clinical Informatics.

• Mobile Note Templates & Order Sets (MD-PHY-003, 002)

• Source: Existing EHR templates/order sets.
• Format: API-based mapping (preferred) or CSV export.

• Process:

  • Map base IDs → mobile variants.
  • Optimize sections/items for mobile.
  • Load only APPROVED templates/sets.

• Order Favorites (MD-PHY-001)

• Initial: Department defaults only.
• Source: Department leads.
• Format: CSV with provider_id NULL for department defaults.
• Process: Load; providers then personalize in-app.

2. Ongoing Synchronization

• Specialty Groups & Role Profiles
• Trigger: Credentialing changes, new roles.

• Mechanism: Nightly batch or event-driven integration from credentialing system.

• Facility/Department Mappings

• Trigger: New facility/department, NABIDH/Malaffi updates.

• Mechanism: Manual update by Integration team with change control.

• Telehealth Visit Types & Platforms

• Trigger: New services, payer coverage changes.

• Mechanism: Change request via Telehealth Program; manual configuration.

• Order Sets & Note Templates

• Trigger: Clinical guideline updates, P&T decisions.

• Mechanism: Governance process; changes propagated from EHR/CPOE master via internal APIs.

• Favorites

• Trigger: Provider actions in app.
• Mechanism: Real-time updates via internal API; no batch sync.

3. Import/Export Formats

• CSV
• Used for bulk initial load (specialty groups, patient lists, task types, inbox types).

• UTF-8 encoding; bilingual fields (*_en, *_ar) supported.

• JSON

• Used for complex fields (e.g., mobile_sections_json, filter_definition_json).

• Exchanged via internal configuration APIs.

• API

• FHIR R4 / internal REST APIs for mapping to EHR templates, order sets, and orderables.

4. Validation on Import

• Referential integrity checks against shared entities (providers, facilities, departments, roles).
• Uniqueness checks on all code and *_code fields.
• JSON schema validation for mobile_sections_json and filter_definition_json.
• Business rules (e.g., mandatory templates must include required I-PASS components; critical notifications must be mandatory).
• Audit logging of all configuration imports with user, timestamp, and change summary (PDPL accountability).

All configuration changes must follow UAE PDPL principles (data minimization, purpose limitation, auditability) and DOH/DHA cybersecurity guidelines (ADHICS, NABIDH/Malaffi integration policies).