EHR & Patient Management Master Data & Configuration

Master Data Inventory

Note: Large terminologies (ICD-10-AM, SNOMED CT, Allergen list) are usually loaded via dedicated terminology services; here we define their role and key fields, not the full code sets.

Setup Sequence

Dependency Diagram

Load Sequence (Narrative)

1. Core demographic reference: Nationality, Emirates & Cities, Languages, Religion, Marital Status, Occupation.
2. Organizational structure: Facilities → Departments → Locations; then NABIDH/Malaffi IDs.
3. Security model: User Roles → Permission Catalogue → assign to users (operational, not master data).
4. Clinical coding: Provider Specialty Codes; ICD-10-AM; SNOMED CT subset; Allergen reference list.
5. Financial/registration: Insurance Payer Codes; Patient Category/Type.
6. Documentation & consent: Document Types; Consent Types & Scopes → Consent Form Templates.
7. Audit & privacy: Audit Action Types; Break-the-Glass Reasons.
8. Validation & go-live: After all above are loaded and tested, enable registration, charting, and portal access.

Master Data Specifications

Below are detailed specs for the most critical data sets used directly in this module. Others follow the same pattern.

MD-EHR-001: Nationality Codes

a. Purpose

Standardised list of patient nationalities used in registration, reporting, and regulatory submissions (e.g., MOH, DOH, DHA). Supports bilingual display and mapping to ISO 3166-1 codes.

b. Schema

Table: ref_nationalities

c. Sample Data

d. Data Governance

• Owner: System Administrator
• Approval: HIM Supervisor + Compliance for any non-ISO additions
• Update frequency: Annually or when ISO list changes
• Change process: 1. Admin reviews ISO updates. 2. Propose additions/retirements. 3. HIM Supervisor approves. 4. Changes applied in test, then production. 5. Notify registration staff via release notes.

e. Validation Rules

• nationality_code must be unique, 3 uppercase letters.
• iso_alpha2 must be unique, 2 uppercase letters.
• display_name_en and display_name_ar must be non-empty when is_active = TRUE.
• Cannot deactivate a nationality if referenced by active patients without HIM approval (soft check with warning).

MD-EHR-002: Emirates & Cities

a. Purpose

Standard list of UAE emirates and commonly used cities/areas for address capture and reporting.

b. Schema

Table: ref_emirates_cities

Composite primary key: (emirate_code, city_code).

c. Sample Data

d. Data Governance

• Owner: System Administrator
• Approval: Operations Director for new areas; HIM for naming conventions
• Update frequency: Rare; as new developments/areas are added
• Change process:
• Request from registration/operations.
• Verify against municipal naming.
• Add in test; validate with sample addresses.
• Deploy to production; notify registration team.

e. Validation Rules

• emirate_code must be one of a predefined set (DXB, AUH, SHJ, AJM, RAK, UAQ, FUJ).
• city_code must be unique within emirate.
• At least one is_default_city = TRUE per emirate.
• Cannot delete cities referenced in patient_demographics; only inactivate.

MD-EHR-003: Document Types

a. Purpose

Defines the types of documents that can be scanned or uploaded (e.g., Emirates ID, insurance card, external reports) for consistent indexing and retention policies.

b. Schema

Table: ref_document_types

c. Sample Data

d. Data Governance

• Owner: HIM Supervisor
• Approval: HIM Committee + Legal for legal/consent types
• Update frequency: As needed; formal review annually
• Change process: 1. Request from clinical/registration department. 2. HIM analyses impact on workflows and retention. 3. Legal reviews if legal/consent category. 4. New type configured and tested. 5. Communicate to scanning staff with examples.

e. Validation Rules

• document_type_code must be unique, uppercase, alphanumeric + underscore.
• default_retention_years must meet or exceed UAE legal minimums for medical records (per MOH/DOH/DHA).
• Clinical documents (is_clinical = TRUE) must have requires_patient_link = TRUE.
• Consent-related types must be mapped to a consent type (MD-EHR-020) in configuration.

MD-EHR-004: Note Templates

a. Purpose

Structured templates for clinical notes (H&P, progress notes, discharge summaries, nursing assessments) to standardise documentation and support bilingual headings.

b. Schema

Table: ref_note_templates

c. Sample Data

content_structure_json example (simplified):

{
  "sections": [
    {"id": "chief_complaint", "label_en": "Chief Complaint", "label_ar": "الشكوى الرئيسية", "type": "text"},
    {"id": "history_present_illness", "label_en": "History of Present Illness", "label_ar": "التاريخ المرضي الحالي", "type": "textarea"}
  ]
}

d. Data Governance

• Owner: Clinical Informatics Lead
• Approval: Relevant Department Chair + HIM Supervisor
• Update frequency: As needed; formal review at least every 2 years
• Change process:
• Clinician submits request with clinical rationale.
• Clinical Informatics drafts template.
• Department Chair and HIM review for completeness and medico-legal requirements.
• Pilot in test environment.
• Approve and deploy; version previous template (set effective_to).

e. Validation Rules

• note_type must be from a controlled list (H&P, PROGRESS, DISCHARGE, CONSULT, NURSING_ASSESSMENT, etc.).
• Only one active template per (note_type, specialty_code, version) combination.
• effective_from must be <= current date for active templates.
• effective_to must be NULL for active templates.

MD-EHR-005: Consent Form Templates

a. Purpose

Defines the content and metadata of consent forms used for treatment, procedures, data processing (UAE PDPL), and HIE data sharing (NABIDH/Malaffi).

b. Schema

Table: ref_consent_templates

c. Sample Data

d. Data Governance

• Owner: Legal Counsel / Privacy Officer
• Approval: Executive Medical Committee + Compliance
• Update frequency: On regulatory change (e.g., UAE PDPL updates) or policy change; annual review
• Change process:
• Legal drafts or updates text.
• Privacy Officer reviews for PDPL compliance (consent, rights, withdrawal).
• Clinical leadership reviews for clinical clarity.
• New version created; old version retired (but preserved for historical records).
• Training and communication to registration and clinical staff.

e. Validation Rules

• consent_type_code must exist in MD-EHR-020.
• Only one active template per (consent_type_code, version) combination.
• Mandatory consents must be presented before certain workflows (e.g., PDPL consent before portal activation).
• HTML must be well-formed and free of external scripts.

MD-EHR-006: Insurance Payer Codes

a. Purpose

Standardised list of insurance payers used for registration, eligibility checks (eClaimLink / DOH eClaims), and billing.

b. Schema

Table: ref_payers

Note: Canonical payer entities are owned by policy-contract-mgmt; this reference table defines the subset and local codes used by EHR registration. It should map 1:1 to payers.payer_id.

c. Sample Data

d. Data Governance

• Owner: RCM Manager
• Approval: Finance Director
• Update frequency: Quarterly or when new payers/contracts are added
• Change process:
• RCM receives payer registry updates from DHA/DOH.
• Validate mapping to payers master in policy-contract-mgmt.
• Update codes and endpoints in test; run eligibility tests.
• Deploy to production; inform registration and billing teams.

e. Validation Rules

• payer_code must be unique and non-null for active payers.
• dha_payer_code and doh_payer_code must match official registries when provided.
• Cannot deactivate payer if active insurance policies exist without RCM override.

MD-EHR-007: Provider Specialty Codes

a. Purpose

Standard list of provider specialties aligned with DOH/DHA classifications, used in provider profiles, note templates, and access control.

b. Schema

Table: ref_provider_specialties

c. Sample Data

d. Data Governance

• Owner: Credentialing Office
• Approval: Medical Director
• Update frequency: As DOH/DHA update specialty lists
• Change process:
• Monitor DOH/DHA circulars.
• Map new/changed specialties.
• Update reference table; adjust provider records as needed.
• Communicate changes to HR and department heads.

e. Validation Rules

• specialty_code must be unique and stable (avoid renaming; create new code instead).
• doh_code/dha_code must match regulator lists when present.
• Cannot deactivate specialty if active providers are mapped without migration plan.

MD-EHR-008: Facility Master

a. Purpose

Defines all facilities (hospitals, clinics) within Gates Group, including licensing and emirate, used across all modules.

b. Schema

Table: facilities (owned by this module)

c. Sample Data

d. Data Governance

• Owner: System Administrator
• Approval: COO + Compliance
• Update frequency: On facility opening/closing or licensing change
• Change process:
• Facility management submits request with license documents.
• IT updates facility master; integration team updates NABIDH/Malaffi IDs (MD-EHR-026).
• Validate routing rules for HIE and billing.

e. Validation Rules

• facility_code must be unique.
• licensing_authority must be one of (DOH, DHA, MOH).
• emirate_code must exist in MD-EHR-002.
• Cannot deactivate facility if active encounters exist; requires migration plan.

MD-EHR-011: User Role Definitions

a. Purpose

Defines RBAC roles used for access control (Registration Clerk, Physician, Nurse, etc.), as listed in the module brief.

b. Schema

Table: roles (owned by this module)

c. Sample Data

d. Data Governance

• Owner: IT Security Officer
• Approval: Information Security Committee
• Update frequency: Rare; when new job functions are introduced
• Change process:
• Security analysis of new role requirements.
• Map to permissions (MD-EHR-012).
• Test in non-production environment.
• Document role capabilities and train admins.

e. Validation Rules

• role_code must be unique and immutable once assigned.
• System roles (is_system_role = TRUE) cannot be deleted; only disabled via configuration.
• At least one active System Administrator and Privacy Officer role must exist.

MD-EHR-012: Permission Catalogue

a. Purpose

Granular permissions used to build roles (e.g., register_patient, merge_records, view_full_record).

b. Schema

Table: permissions (owned by this module)

c. Sample Data

d. Data Governance

• Owner: IT Security Officer
• Approval: Information Security Committee
• Update frequency: As new features are added
• Change process:
• New feature triggers permission design.
• Security review to ensure least-privilege.
• Map permissions to roles; update documentation.
• Deploy with feature release.

e. Validation Rules

• permission_code must be unique and stable.
• Combination (module, resource, action) should be unique.
• Permissions used in code must exist in this table (enforced via deployment checks).

MD-EHR-013: Allergen Reference List

a. Purpose

Master list of allergens (drug and non-drug) used in Allergy Management (WF-EHR-004), sourced from RxNorm and SNOMED CT.

b. Schema

Table: ref_allergens

c. Sample Data

d. Data Governance

• Owner: Pharmacy Informatics (drug allergens) + Clinical Informatics (non-drug)
• Approval: Pharmacy & Therapeutics Committee for drug list; Allergy Committee (if exists) for non-drug
• Update frequency: With RxNorm/SNOMED releases (typically quarterly/biannually)
• Change process:
• Import updated subsets from terminology services.
• Maintain local list of “common” allergens for UI.
• Validate mappings to CDS rules in CPOE.

e. Validation Rules

• allergen_code + allergen_system must be unique.
• Only codes from approved RxNorm/SNOMED releases.
• Cannot delete allergens referenced in patient_allergies; only inactivate.

MD-EHR-014: ICD-10-AM Diagnosis Codes

a. Purpose

Standard diagnosis codes used in problem list, encounters, and billing, aligned with ICD-10-AM (Australian Modification) adopted in UAE.

b. Schema

Table: ref_icd10am_codes

c. Sample Data

d. Data Governance

• Owner: HIM Manager
• Approval: Coding Committee
• Update frequency: With ACCD ICD-10-AM releases
• Change process:
• Import new version into terminology service.
• Run regression tests on coding tools.
• Train coders on changes.

e. Validation Rules

• icd10am_code must conform to ICD-10-AM format.
• Only is_billable = TRUE codes can be used for final billing diagnoses.
• Historical codes remain for legacy data; not reused.

MD-EHR-015: SNOMED CT Clinical Terms Subset

a. Purpose

SNOMED CT subset used for problem list descriptions, allergy manifestations, and other coded clinical concepts.

b. Schema

Table: ref_snomed_terms

c. Sample Data

d. Data Governance

• Owner: Clinical Informatics
• Approval: Clinical Coding Committee
• Update frequency: Biannually
• Change process:
• Import updated SNOMED release.
• Maintain local subsets for each use case.
• Validate mappings to ICD-10-AM and CDS rules.

e. Validation Rules

• snomed_code must exist in licensed SNOMED CT release.
• Category must be from controlled list.
• Inactivation must follow SNOMED historical association rules (map to replacement concepts where possible).

MD-EHR-020: Consent Types & Scopes

a. Purpose

Defines high-level consent types and scopes used to classify consent records and templates, aligned with UAE PDPL and HIE policies.

b. Schema

Table: ref_consent_types

c. Sample Data

d. Data Governance

• Owner: Privacy Officer
• Approval: Legal Counsel + Executive Committee
• Update frequency: On PDPL or HIE policy changes
• Change process:
• Legal/Privacy review regulatory updates.
• Adjust consent types and scopes accordingly.
• Update mapping to consent templates and workflows.

e. Validation Rules

• consent_type_code must be unique.
• PDPL-related consents must be presented before processing personal health data beyond legal bases.
• HIE-related consents must be checked before sending data to NABIDH/Malaffi.

MD-EHR-021: Audit Action Types

a. Purpose

Standardised action codes used in audit_log to classify user activities (view, update, BTG, export, etc.).

b. Schema

Table: ref_audit_actions

c. Sample Data

d. Data Governance

• Owner: Privacy Officer
• Approval: Information Security Committee
• Update frequency: As new audited actions are introduced
• Change process:
• Security identifies new action types.
• Add to reference table and map in application logging.
• Update privacy monitoring dashboards.

e. Validation Rules

• action_code must be unique.
• High-risk actions must have severity_level = 'HighRisk'.
• BTG-related actions must set is_btg_related = TRUE.

MD-EHR-022: Break-the-Glass Reasons

a. Purpose

Controlled list of reasons that clinicians must select when invoking Break-the-Glass (BTG) access, supporting PDPL accountability.

b. Schema

Table: ref_btg_reasons

c. Sample Data

d. Data Governance

• Owner: Privacy Officer
• Approval: Information Security Committee
• Update frequency: Rare; on privacy policy change
• Change process:
• Privacy Officer proposes changes.
• Committee approves.
• Update reference table; adjust BTG training materials.

e. Validation Rules

• btg_reason_code must be unique.
• At least one active reason must exist for BTG to be enabled.
• BTG events must store both btg_reason_code and free-text explanation when requires_free_text = TRUE.

Configuration Parameters

Core Configuration Matrix

Data Load Procedures

1. Initial Load

Sources:

• National/international standards:
• ISO 3166-1 (nationalities)
• ISO 639-1 (languages)
• ICD-10-AM (ACCD)
• SNOMED CT (SNOMED International)
• RxNorm (for allergens)
• UAE-specific:
• DOH/DHA specialty lists
• DHA eClaimLink / DOH eClaims payer registries
• DOH/DHA/MOH facility licenses
• Internal:
• Organizational charts (facilities, departments, locations)
• Security design (roles, permissions)
• Legal-approved consent texts
• HIM-defined document types, marital status, religion, occupation

Process:

1. Extract standard code sets from official sources (CSV/XML/JSON).
2. Transform to HIS schema (field mapping, bilingual names).
3. Load into staging tables.
4. Run validation scripts (see below).
5. Promote to production reference tables after sign-off.

2. Ongoing Synchronization

• Terminologies (ICD-10-AM, SNOMED CT, RxNorm):
• Use terminology service or scheduled imports.
• Maintain version metadata.

• Allow coexistence of old and new codes for historical data.

• Payers & Specialties:

• Quarterly sync from DOH/DHA registries.
• Compare with current data; generate change report.

• Apply adds/updates/inactivations with RCM/Credentialing approval.

• Facilities & HIE IDs:

• On any facility licensing change, update facility master and NABIDH/Malaffi IDs (MD-EHR-026).

• Coordinate with integration team to update routing rules.

• Roles & Permissions:

• Managed via change control process tied to software releases.

3. Import/Export Formats

• Supported formats:
• CSV: For bulk master data imports (nationalities, emirates, document types, etc.).
• JSON: For terminology subsets and configuration bundles.
• API: For real-time sync with external registries (e.g., payer eligibility endpoints).

Example CSV layout – Nationality Codes:

nationality_code,iso_alpha2,display_name_en,display_name_ar,is_active
ARE,AE,United Arab Emirates,الإمارات العربية المتحدة,1
IND,IN,India,الهند,1
PAK,PK,Pakistan,باكستان,1

Example JSON layout – Consent Types:

[
  {
    "consent_type_code": "PDPL_DATA_PROCESSING",
    "display_name_en": "Personal Health Data Processing Consent",
    "display_name_ar": "موافقة على معالجة البيانات الصحية الشخصية",
    "scope_description_en": "Consent to process personal health data in accordance with UAE PDPL.",
    "scope_description_ar": "موافقة على معالجة البيانات الصحية الشخصية وفقًا لقانون حماية البيانات الشخصية في الإمارات.",
    "is_pdpl_required": true,
    "is_hie_related": false
  }
]

4. Validation on Import

For each import job:

1. Schema validation: - Check required columns present. - Validate data types and lengths.

2. Referential integrity: - Emirates codes must exist when loading facilities. - Consent types must exist before consent templates.

3. Business rules: - No duplicate codes. - Bilingual fields must not be empty for active records. - Retention periods must meet UAE regulatory minimums.

4. Audit & Logging: - Log import file name, user, timestamp, record counts, errors. - Store import files securely for traceability.

5. Approval & Rollback: - Changes to high-impact data (consent types, roles, permissions, payer codes) require dual approval (business owner + IT). - Support rollback to previous snapshot if validation fails post-deployment.

This master data and configuration specification provides the foundation for implementing the EHR & Patient Management module in a UAE-compliant, paperless manner, ensuring consistent demographics, coding, consent, and access control across all integrated systems.