Nutrition Management Master Data & Configuration

Master Data Inventory

Note: Shared entities (patients, encounters, facilities, etc.) are defined in other modules and referenced here; they are not master data of the nutrition module.

Setup Sequence (Dependency Order)

Data sets must be loaded in the following order to ensure referential and business-rule consistency.

Load Sequence Summary

1. Food Allergen Categories (MD-NUT-005) – foundational for allergen tagging.
2. Texture Modification Levels (MD-NUT-006) – required for menu item suitability and diet types.
3. Menu Items (MD-NUT-002) – reference for menu cycles, diet types, supplements.
4. Diet Type Definitions (MD-NUT-001) – map to menu categories, textures, cultural rules.
5. Menu Cycles (MD-NUT-003) – depend on menu items and diet types.
6. Enteral Formula Catalog (MD-NUT-007) – used in enteral/parenteral orders.
7. Supplement & Snack Catalog (MD-NUT-011) – may reference menu items and diet types.
8. Nutritional Reference Values (MD-NUT-004) – used by screening tools and assessments.
9. Nutrition Screening Tools (MD-NUT-008) – configured using reference values.
10. Nutrition Risk Levels (MD-NUT-012) – used by screening tools and workflows.
11. Meal Types & Service Times (MD-NUT-009) – used by menu cycles and production orders.
12. Cultural/Religious Preferences (MD-NUT-010) – used by diet orders and menu filtering.
13. Meal Satisfaction Scales (MD-NUT-013) – used by meal_service_records.

Master Data Specifications

MD-NUT-001: Diet Type Definitions

Purpose

Defines all orderable diet types (e.g., Regular, Diabetic, Renal, Low Sodium, Texture‑modified) used in diet_orders, meal_plans, tray_tickets, and menu_cycles. Ensures consistent mapping between clinical orders and kitchen production, including halal and UAE‑specific cultural requirements.

Logical Schema

Sample Data

Data Governance

• Owner: Chief Dietitian
• Approval process:
  1. Proposal raised by dietitian/physician.
  2. Review by Nutrition Governance Committee (including physician representative).
  3. Approval and documentation of clinical indications and contraindications.
  4. Update in HIS by Nutrition Informatics / IT.
  5. Communication to nursing, physicians, and kitchen staff.
• Update frequency: As needed; formal review at least annually.
• Change notification:
• Email bulletin to clinical staff and kitchen.
• Update in diet manual and e‑learning.
• Release notes in HIS change log.

Validation Rules

• code must be unique, uppercase, no spaces (use _ or - if needed).
• is_halal_only must be TRUE for all active inpatient diets in UAE facilities.
• If is_npo = TRUE, then allowed_categories and excluded_categories must be NULL.
• If is_active = FALSE, diet must not be referenced by active diet_orders.
• default_texture_level_code must exist in MD-NUT-006.
• energy_kcal_per_day_min ≤ energy_kcal_per_day_max when both populated.

MD-NUT-002: Menu Items (Food Database)

Purpose

Master list of all food and beverage items available for patient meals, snacks, and supplements. Used by menu_items table and referenced in menu_cycles, meal_plans, kitchen_production_orders, and tray_tickets. Includes nutritional values, allergen flags, and halal/vegetarian suitability.

Logical Schema

Sample Data

Data Governance

• Owner: Kitchen Manager (operational attributes) & Chief Dietitian (nutritional attributes).
• Approval process:
  1. New item proposal from kitchen or dietitian.
  2. Nutritional analysis by dietitian (calories, macros, allergens).
  3. Verification of halal certification (where applicable) per UAE food safety standards.
  4. Approval by Chief Dietitian.
  5. Entry/update in HIS by Nutrition Informatics / IT.
• Update frequency: With each menu cycle change; at least quarterly.
• Change notification:
• Updated menu item list shared with nursing and physicians (for patient counselling).
• Changes affecting allergens trigger targeted communication to clinical staff.

Validation Rules

• item_code unique and immutable once used in production.
• All meat items must have is_halal_certified = TRUE and non‑NULL halal_certification_ref.
• If is_vegan = TRUE, then is_vegetarian must also be TRUE and allergens must not include MILK, EGG, FISH, SHELLFISH.
• allergens must contain only codes defined in MD-NUT-005.
• texture_suitable_levels must contain only codes from MD-NUT-006.
• is_active = FALSE only allowed if item not present in future menu_cycles or meal_plans.

MD-NUT-003: Menu Cycles

Purpose

Defines rotating menu plans (e.g., 4‑week cycle) for each facility and diet type, specifying which menu items are available for each day and meal. Drives automated meal planning and kitchen production.

Logical Schema

Sample Data

Data Governance

• Owner: Chief Dietitian.
• Approval process:
  1. Draft cycle prepared by dietitian and kitchen manager.
  2. Nutritional adequacy review vs MD-NUT-004 reference values.
  3. Cultural and religious appropriateness review (e.g., Ramadan adjustments).
  4. Approval by Nutrition Governance Committee.
  5. Configuration in HIS and validation in test environment.
• Update frequency: Typically annually or per operational need (e.g., supplier changes).
• Change notification:
• Communicated to kitchen staff, nursing, and patient experience teams.
• Updated patient information materials (e.g., diet brochures).

Validation Rules

• cycle_code unique per facility.
• day_number must be between 1 and cycle_length_days.
• menu_item_ids must reference active menu_items.
• Only one active cycle per (facility_id, diet_type_id, meal_type_code, day_number) at a time.
• effective_date < expiry_date when expiry set.

MD-NUT-004: Nutritional Reference Values

Purpose

Stores reference nutritional requirements (e.g., kcal/kg, protein g/kg) by age group, clinical condition, and risk category. Used by nutrition_assessments, nutrition_screening, and care plan calculations.

Logical Schema

Sample Data

Data Governance

• Owner: Chief Dietitian.
• Approval process:
• Literature review (ESPEN/ASPEN, regional guidelines).
• Discussion in Clinical Nutrition Committee.
• Formal approval and documentation of references.
• Update in HIS with versioning.
• Update frequency: On guideline updates; at least every 2 years.
• Change notification:
• Communicated to dietitians and physicians.
• Training sessions for major changes.

Validation Rules

• code unique.
• For each record, min values must be ≤ max values.
• Age ranges should not overlap with identical condition_code unless intentionally configured (documented).
• is_active = FALSE only when not referenced by active screening tools.

MD-NUT-005: Food Allergen Categories

Purpose

Standardised list of allergen categories used to tag menu items and derive food_allergen_alerts from patient_allergies. Aligns with international standards and UAE food safety requirements.

Logical Schema

Sample Data

Data Governance

• Owner: Nutrition Informatics Lead.
• Approval process:
• Monitor UAE food safety regulations and international allergen standards.
• Propose additions/changes to Chief Dietitian and Food Safety Officer.
• Approval and update in HIS.
• Update frequency: On regulatory change; at least annually.
• Change notification:
• Communicated to kitchen, nursing, and physicians.
• Update in patient allergy documentation guidelines.

Validation Rules

• allergen_code unique, uppercase.
• is_major_allergen TRUE for allergens requiring prominent labelling under UAE food safety rules.
• is_active = FALSE only if no active menu items reference the allergen.

MD-NUT-006: Texture Modification Levels (IDDSI)

Purpose

Defines standard texture and fluid consistency levels per IDDSI, used in diet_orders, menu_items.texture_suitable_levels, and dysphagia management.

Logical Schema

Sample Data

Data Governance

• Owner: Speech Therapy Lead & Chief Dietitian.
• Approval process:
• Follow IDDSI official updates.
• Multidisciplinary review (speech therapy, dietetics, nursing).
• Update HIS configuration and staff training.
• Update frequency: Rare; when IDDSI changes.
• Change notification:
• Mandatory training for staff when levels or definitions change.

Validation Rules

• iddsi_number must be between 0 and 7.
• is_fluid and is_solid cannot both be FALSE.
• Codes must align with IDDSI standard naming.

MD-NUT-007: Enteral Formula Catalog

Purpose

Catalog of enteral nutrition formulas (and optionally TPN base solutions) available in the facility, used in enteral_parenteral_orders. Aligns with pharmacy formulary and PIS.

Logical Schema

Sample Data

Data Governance

• Owner: Chief Dietitian & Pharmacy Director.
• Approval process:
• New formula request via P&T Committee.
• Clinical and cost evaluation.
• Update in pharmacy formulary and HIS.
• Mapping to PIS item codes.
• Update frequency: With formulary changes; at least annually.
• Change notification:
• Communicated to physicians, dietitians, and nurses.
• Update in EN/TPN ordering guidelines.

Validation Rules

• formula_code unique.
• calories_kcal_per_ml > 0.
• allergens must use MD-NUT-005 codes.
• is_active = FALSE only if not used in active enteral_parenteral_orders.

MD-NUT-008: Nutrition Screening Tools

Purpose

Defines available nutrition screening tools (e.g., NRS‑2002, MUST, SGA) and their scoring logic, used in nutrition_screening and workflow WF-NUT-002.

Logical Schema

Sample Data

Data Governance

• Owner: Chief Dietitian.
• Approval process:
• Selection of validated tools per institutional policy.
• Configuration of scoring thresholds.
• Approval by Clinical Governance Committee.
• Update frequency: Rare; when institutional policy changes.
• Change notification:
• Training for nursing staff on new/updated tools.
• Update in admission protocols.

Validation Rules

• min_score < max_score.
• moderate_risk_min ≥ min_score and < high_risk_min.
• high_risk_min ≤ max_score.
• Only one active default tool per facility (enforced at application level).

MD-NUT-009: Meal Types & Service Times

Purpose

Defines standard meal types (breakfast, lunch, dinner, snacks) and default service times per facility. Used in meal_plans, kitchen_production_orders, and WF-NUT-003.

Logical Schema

Sample Data

Data Governance

• Owner: Kitchen Manager.
• Approval process:
• Proposed by kitchen operations.
• Reviewed with nursing and operations director.
• Approved by Operations Director.
• Update frequency: As needed (schedule changes).
• Change notification:
• Communicated to all wards and diet office.
• Updated in staff schedules and patient information.

Validation Rules

• default_start_time < default_end_time.
• At least one main meal must be active.
• is_main_meal and is_snack cannot both be TRUE.

MD-NUT-010: Cultural/Religious Dietary Preferences

Purpose

Defines standard preference codes for cultural/religious dietary needs relevant to UAE (e.g., halal, no pork, vegetarian, Ramadan fasting). Used in diet_orders.cultural_preference and meal planning.

Logical Schema

Sample Data

Data Governance

• Owner: Chief Dietitian & Patient Experience Lead.
• Approval process:
• Developed with cultural committee and religious affairs advisor (if applicable).
• Approved by hospital leadership.
• Update frequency: As needed.
• Change notification:
• Communicated to clinical and kitchen staff, especially before Ramadan.

Validation Rules

• preference_code unique.
• requires_halal must be TRUE for all active preferences in UAE context.
• If preference_code = HALAL, it must be set as default in system configuration.

MD-NUT-011: Supplement & Snack Catalog

Purpose

Defines oral nutrition supplements and standard snacks that can be ordered separately from main meals. Used in diet_orders.supplements and meal_plans.

Logical Schema

Sample Data

Data Governance

• Owner: Chief Dietitian.
• Approval process:
• Nutritional evaluation and allergen assessment.
• Halal certification verification.
• Approval by Chief Dietitian.
• Update frequency: With menu/formulary changes.
• Change notification:
• Communicated to nursing and physicians.

Validation Rules

• supplement_code unique.
• allergens must use MD-NUT-005 codes.
• is_halal_certified must be TRUE for all active supplements in UAE context.

MD-NUT-012: Nutrition Risk Levels

Purpose

Standardises risk level labels used in nutrition_screening and nutrition_assessments (e.g., Low, Moderate, High). Supports KPIs such as Nutrition Screening Compliance and Malnutrition Documentation Rate.

Logical Schema

Sample Data

Data Governance

• Owner: Chief Dietitian.
• Approval process:
• Defined in alignment with screening tools (MD-NUT-008).
• Approved by Clinical Nutrition Committee.
• Update frequency: Rare.
• Change notification:
• Communicated to dietitians and nursing.

Validation Rules

• priority_level must be unique per risk_code.
• At least one risk level must have auto_dietitian_referral = TRUE.
• reassessment_interval_days > 0 when provided.

MD-NUT-013: Meal Satisfaction Scales

Purpose

Defines scales and labels used to capture patient meal satisfaction scores in meal_service_records (e.g., 1–5 Likert scale).

Logical Schema

Sample Data

Data Governance

• Owner: Patient Experience Lead.
• Approval process:
• Defined by patient experience team.
• Approved by Quality & Patient Experience Committee.
• Update frequency: Rare.
• Change notification:
• Communicated to diet office and nursing.

Validation Rules

• min_value < max_value.
• Only one active scale with is_default = TRUE.

Configuration Parameters

Data Load Procedures

1. Initial Load

Sources

• Existing paper diet manuals and menus.
• Current kitchen production sheets.
• Pharmacy formulary (for enteral formulas).
• Institutional nutrition protocols and guidelines.

Process

1. Data Collection & Mapping - Extract current diet types, menus, and formulas into structured spreadsheets. - Map existing allergen labels to MD-NUT-005 codes. - Map existing texture descriptions to IDDSI (MD-NUT-006).

2. Template Formats - Use CSV templates per data set, e.g.:

   • diet_type_definitions.csv
   • menu_items.csv
   • menu_cycles.csv
   • enteral_formulas.csv
   • Encoding: UTF‑8 to support Arabic.

3. Import Mechanism - Preferred: Secure internal API endpoints (JSON) for bulk load.
   - Alternative: Admin UI CSV upload with server‑side validation.

4. Validation on Import - Schema validation (required fields, data types). - Referential integrity (e.g., menu_item_ids exist). - Business rules (halal, allergens, IDDSI mapping). - Duplicate detection (codes, names).

5. Testing - Load into staging environment.
   - Run end‑to‑end workflows: WF-NUT-001 to WF-NUT-006.
   - Validate sample patients across common diet types and allergies.

6. Promotion to Production - Change control approval.
   - Scheduled downtime or controlled window for initial load.
   - Post‑load verification reports (counts, spot checks).

2. Ongoing Synchronization

• Menu Items & Cycles
• Quarterly review; updates via controlled CSV/API imports.

• Versioning of menu cycles (effective/expiry dates).

• Enteral Formula Catalog

• Synchronised with pharmacy formulary via internal API (JSON) or periodic CSV from PIS.

• Allergen Categories & Reference Values

• Manual updates by Nutrition Informatics following regulatory or guideline changes.

• Audit & PDPL Compliance

• All changes logged with user, timestamp, and before/after values.
• Access restricted to authorised roles (Chief Dietitian, Nutrition Informatics, IT Admin).

3. Import/Export Formats

• CSV
• Delimiter: comma.
• Text qualifier: double quotes.
• Header row required.
• Date format: YYYY-MM-DD.

• Time format: HH:MM:SS.

• JSON (for APIs)

• Arrays of objects per data set, e.g.:

{
  "dietTypes": [
    {
      "code": "REG",
      "diet_name_en": "Regular Diet",
      "diet_name_ar": "حمية عادية",
      "is_halal_only": true,
      "is_active": true
    }
  ]
}

• Validation Responses
• On error: return list of row numbers and field errors.
• On success: return counts of created/updated records.

4. Validation on Import (Cross‑Cutting)

• Technical
• UTF‑8 encoding, no BOM.
• No control characters in text fields.

• Maximum length checks per field.

• Business

• Halal compliance for all active items and diets.
• Allergen codes must match MD-NUT-005.
• Texture levels must match MD-NUT-006.

• No overlapping active menu cycles for same facility/diet/meal/day.

• Security & Privacy (UAE PDPL)

• Master data imports must not include patient identifiers.
• Access to import/export functions restricted to authorised roles.
• Logs retained per facility data governance policy.

This specification provides the nutrition module’s master data foundation required to support diet orders, meal planning, kitchen production, tray assembly, and nutrition screening/assessment workflows in a UAE‑compliant, paperless HIS.