Nutrition Management Workflows
Home / Clinical Modules / Nutrition Management / Workflows

Nutrition Management Workflows

This document defines six core workflows for the Nutrition Management module in the Gates Group HIS. Each workflow describes process steps, decision logic, integration hooks, exception handling, and the paperless transformation achieved.

Regulatory context (UAE): All workflows must comply with UAE Federal Decree-Law No. 45/2021 on Personal Data Protection (UAE PDPL) for handling patient-identifiable information, and with MOH, DOH (ADHICS), and DHA (NABIDH) requirements for clinical documentation, auditability, and secure data exchange. Nutrition data that forms part of the clinical record is shared with NABIDH/Malaffi where applicable, following local consent and data minimisation rules.

WF-NUT-001: Diet Order Entry & Processing

Process Flow

Actor: Physician (ordering), Dietitian (review), System
Trigger: Patient admitted, diet change ordered, or post‑procedure diet progression
Pre-conditions:

  • Patient exists in patients and has an active encounter in encounters
  • ADT event has added patient to dietary census (see WF-NUT-006)
  • Patient allergies loaded from patient_allergies and mapped to food_allergen_alerts
  • Diet types and menu items configured in diet_type_definitions and menu_items
  1. Physician opens Diet Order Entry (SCR-NUT-001) from the patient chart (CPOE context).
  2. System loads: - Patient demographics (from patients) - Active encounter details (from encounters) - Current diet order (if any) from diet_orders - Food allergen alerts from food_allergen_alerts.
  3. Physician selects diet parameters: - Diet type (FK to diet_type_definitions) - Texture modification (IDDSI level) - Fluid restriction (mL/day) - Supplements (free text + structured list) - Cultural/religious preferences (e.g., halal, vegetarian, no pork).
  4. System validates the order: - Checks that diet type is active in diet_type_definitions - Ensures start date/time ≥ current time - Confirms halal compliance (all menu items mapped to this diet type must have is_halal = TRUE).
  5. System performs food allergen check: - Cross-references selected diet type and supplements with food_allergen_alerts and menu_items.allergens. - If potential conflict, displays severity-graded warning to physician.
  6. Decision: If severe allergen conflict detected: - If physician cancels → workflow ends, no new order created. - If physician overrides → justification captured and stored in order_audit_log (owned by CPOE; referenced here conceptually).
  7. Physician confirms order details and signs electronically (within CPOE, but diet order data is persisted in Nutrition module).
  8. System: - Sets any previous active diet order for the encounter to status = 'REPLACED' in diet_orders (UPDATE). - Inserts new row into diet_orders with status = 'ACTIVE'.
  9. System triggers automatic meal plan generation: - For each remaining meal of the current day and upcoming days in the active menu cycle, creates entries in meal_plans based on menu_cycles and menu_items, filtered by diet type, texture, allergens, and cultural preferences.
  10. System updates kitchen production planning:
    • Aggregates new/changed meal plans into kitchen_production_orders for upcoming meal services (INSERT/UPDATE).
    • Generates or updates tray_tickets per patient/meal (INSERT/UPDATE).
  11. System sends internal notification to:
    • Nursing station (via EHR messaging) that diet order has changed.
    • Dietitian work queue for review if diet is therapeutic (e.g., renal, diabetic, tube feeding).
  12. Dietitian reviews diet order and associated meal plans:
    • May adjust supplements or special instructions → updates diet_orders and meal_plans (UPDATE).
  13. System logs all changes for audit and UAE PDPL accountability (who changed what, when).

Data Modified:

  • diet_orders — INSERT (new order), UPDATE (previous order status, later modifications)
  • meal_plans — INSERT (generated plans), UPDATE (if dietitian adjusts), DELETE (if plans invalidated)
  • kitchen_production_orders — INSERT/UPDATE (recalculated production quantities)
  • tray_tickets — INSERT/UPDATE (per-patient tray specs)
  • food_allergen_alerts — READ only (no modification in this workflow)
  • Shared (in other modules, conceptually): notification/audit tables

Mermaid Flowchart

flowchart TD A["Physician opens Diet Order Entry"] --> B["Load patient, encounter, current diet, allergen alerts"] B --> C["Physician selects diet type, texture, fluid restriction, supplements"] C --> D["Validate diet type, dates, halal compliance"] D -->|"Invalid"| D1["Show validation errors"] --> C D -->|"Valid"| E["Run food allergen check"] E --> F{"Severe allergen conflict?"} F -->|"Yes"| G["Display warning & require decision"] G --> H{"Physician overrides?"} H -->|"No"| Z["Cancel diet order entry"] H -->|"Yes"| I["Capture override reason"] F -->|"No"| J["Physician reviews & e-signs order"] I --> J J --> K["Set previous active diet order to REPLACED"] K --> L["Insert new ACTIVE diet order"] L --> M["Generate meal plans from menu cycles"] M --> N["Update kitchen production orders"] N --> O["Generate/Update tray tickets"] O --> P["Notify nursing & dietitian"] P --> Q["Dietitian reviews order & plans"] Q --> R{"Dietitian modifications?"} R -->|"Yes"| S["Update diet_orders & meal_plans"] R -->|"No"| T["Diet order & meal plans final"] S --> T T --> Y["End"]

Decision Points

  1. Validation of diet order
    - If diet type inactive or start time invalid → system blocks order until corrected.
    - If halal requirement not met (e.g., mapped menu items not halal) → system prevents saving unless dietitian explicitly flags exception (e.g., non-Muslim patient, documented).

  2. Food allergen conflict
    - If conflict with severe food allergy (e.g., nuts, shellfish, egg) → hard warning; physician must either cancel or override with justification.
    - If mild/moderate conflict (e.g., intolerance) → soft warning; physician can proceed but justification recommended.

  3. Dietitian review
    - If diet is standard (e.g., regular, soft) and screening risk is low → dietitian review optional.
    - If diet is therapeutic or patient high-risk → dietitian review mandatory; system flags if not completed within defined SLA (e.g., 24h).

Integration Points

  • CPOE module
  • Inbound: diet order entry UI and e-signature context.
  • Data: diet order details (diet type, texture, fluid restriction, supplements).

  • Mechanism: Internal API / HL7 ORM^O01 (INT-NUT-001).

  • EHR Patient Management (ehr-patient-mgmt)

  • Read: patients, patient_allergies, facilities, locations.

  • Purpose: demographics, allergy mapping, location for tray delivery.

  • Scheduling / ADT

  • Read: encounters and ADT events (for active encounter and bed/ward).

  • Purpose: ensure order tied to correct encounter and location.

  • EHR Clinical Notes

  • Outbound: dietitian comments may be referenced in clinical notes (via INT-NUT-003).

Exception Handling

  • Allergy data missing or incomplete:
  • System displays banner: “Food allergy list incomplete — verify with patient / nursing.”

  • Allows order but logs warning; dietitian review is auto-flagged as high priority.

  • Menu mapping failure (no suitable menu items for selected diet + allergens + preferences):

  • System alerts: “No menu items available for this combination. Please adjust diet type or preferences.”

  • Meal plan generation is blocked until resolved; dietitian is notified.

  • Integration failure with CPOE or ADT:

  • Diet order saved locally with status = 'PENDING_INTEGRATION'.

  • Background job retries; if >3 failures, alerts IT support and dietitian.

  • Database conflict (concurrent diet order changes):

  • System uses optimistic locking; if conflict detected, prompts user to reload latest data and re-apply changes.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Handwritten diet order slips sent to kitchen Structured diet orders in diet_orders with real-time propagation to kitchen Eliminates transcription errors and delays
Manual kitchen communication boards for diet changes Automatic update of kitchen_production_orders and tray_tickets Ensures latest diet is reflected in every meal
Handwritten labels for dietary restrictions on trays System-generated tray tickets with allergens and preferences Improves patient safety and compliance
Phone calls from nursing to kitchen for diet changes Event-driven notifications and dashboards Reduces interruptions and miscommunication

Remaining Paper Touchpoints: Optional printed diet summary for patient education on discharge, if patient declines portal access.

Inputs and Outputs

Inputs:

Source Data Element Format
EHR / Patient Chart Patient demographics (MRN, Emirates ID, age, sex) patients table
EHR / Patient Chart Active allergies (food and drug) patient_allergies table (SNOMED CT coded)
Scheduling / ADT Active encounter details (ward, bed, admission date) encounters table
Nutrition Master Data Diet type definitions and menu cycles diet_type_definitions, menu_cycles tables
Nutrition Master Data Menu items with allergen and halal mappings menu_items table
Nutrition Module Food allergen alerts derived from patient allergies food_allergen_alerts table
Provider Diet type, texture (IDDSI), fluid restriction, supplements, cultural preferences Diet Order Entry form (SCR-NUT-001)

Outputs:

Destination Data Element Format
diet_orders New active diet order record SQL INSERT
diet_orders Previous diet order set to REPLACED SQL UPDATE
meal_plans Generated meal plans for upcoming meals SQL INSERT (multiple rows)
kitchen_production_orders Updated production quantities for kitchen SQL INSERT/UPDATE
tray_tickets Per-patient tray specifications with barcodes SQL INSERT/UPDATE
Nursing Station Diet order change notification Internal notification
Dietitian Work Queue Review task (if therapeutic diet) Internal notification

Post-conditions:

  • New diet order exists with status = 'ACTIVE' and valid e-signature
  • Any previous active diet order for the encounter has status = 'REPLACED'
  • Meal plans generated for all remaining meals in current and upcoming menu cycle days
  • Kitchen production orders reflect updated tray counts and item quantities
  • Tray tickets updated with current diet, allergens, and preferences
  • Dietitian notified if diet is therapeutic or patient is high-risk

SLA and Timing

Step Target Time Escalation Measurement Source
Diet order signing to meal plan generation < 30 seconds Alert IT if > 2 min meal_plans.created_datetime minus diet_orders.order_datetime
Kitchen production order update < 5 minutes after meal plan generation Alert Kitchen Manager if > 10 min kitchen_production_orders.updated_datetime
Tray ticket generation < 5 minutes after meal plan generation Alert Diet Technician if > 10 min tray_tickets.created_datetime
Dietitian review (therapeutic diet) < 24 hours from order entry Alert Dietitian Supervisor at 24h diet_orders.dietitian_reviewed_datetime
Nursing notification delivery < 1 minute from order signing Alert IT if > 5 min notification_log.sent_datetime
Late diet order change (after production cut-off) Kitchen Manager review within 15 min Escalate to Food Services Director diet_orders.order_datetime vs kitchen_production_orders.cutoff_datetime

State Transition Diagram

stateDiagram-v2 [*] --> Draft : Physician begins diet order entry Draft --> PendingValidation : Physician submits order PendingValidation --> AllergenReview : Allergen conflict detected PendingValidation --> Signed : Validation passes, no conflicts AllergenReview --> Signed : Physician overrides with justification AllergenReview --> Cancelled : Physician cancels order Signed --> Active : System activates and generates meal plans Active --> UnderReview : Dietitian reviews therapeutic diet UnderReview --> Active : Dietitian approves or modifies Active --> Replaced : New diet order entered for same encounter Active --> Completed : Patient discharged (ADT A03) Active --> Cancelled : Provider cancels diet order Replaced --> [*] Completed --> [*] Cancelled --> [*]

WF-NUT-002: Nutrition Screening & Assessment

Process Flow

Actor: Nurse (screening), Dietitian (assessment), System
Trigger: Patient admission (screening within 24h), high-risk screen triggers full assessment
Pre-conditions:

  • Active inpatient encounter in encounters
  • Nutrition screening tools configured in master data (Nutrition Screening Tools)
  • Patient anthropometrics (weight, height) available or scheduled to be measured
  • Lab integration with LIS configured for nutrition-related markers (INT-NUT-005)
  1. Nurse opens Nutrition Screening Form (SCR-NUT-003) from admission workflow.
  2. System loads: - Patient demographics and encounter details. - Latest weight/height from EHR (if available). - Selected screening tool (e.g., NRS-2002, MUST) per facility configuration.
  3. Nurse completes screening questions: - Recent weight loss, reduced intake, disease severity, BMI, etc.
  4. System auto-calculates screening score and assigns risk level (low / moderate / high) based on tool-specific rules.
  5. System saves screening record: - Inserts row into nutrition_screening with score, risk level, and screened_by.
  6. Decision: If risk level is moderate or high: - System auto-creates dietitian referral and flags patient in dietitian worklist. - Sets referred_to_dietitian = TRUE in nutrition_screening.
  7. Dietitian opens Nutrition Assessment (SCR-NUT-004) from worklist.
  8. System pre-populates assessment form with: - Screening results from nutrition_screening. - Anthropometrics (weight, height, BMI) from EHR or last assessment. - Relevant lab values (albumin, prealbumin, electrolytes, glucose) from LIS via INT-NUT-005.
  9. Dietitian conducts comprehensive assessment: - Reviews weight history, dietary intake, functional status, physical exam findings. - Documents findings and malnutrition risk classification (e.g., per GLIM or local policy).
  10. Dietitian defines nutrition goals:
    • Calorie and protein targets, fluid goals, route of nutrition (oral/EN/TPN), supplements.
  11. System saves assessment:
    • Inserts row into nutrition_assessments with targets, findings, and care plan text.
  12. System updates care plan:
    • Links assessment to active diet order and meal plans (via diet_orders and meal_plans references).
    • Schedules reassessment date/time (stored in nutrition_assessments or related scheduling table).
  13. System writes summary note to EHR clinical notes (via INT-NUT-003) for inclusion in NABIDH/Malaffi shared record.
  14. Decision: If malnutrition indicators present but not coded:
    • System prompts dietitian/physician to consider adding ICD-10-AM malnutrition diagnosis to problem list (for Malnutrition Documentation Rate KPI).

Data Modified:

  • nutrition_screening — INSERT (new screening), UPDATE (if corrections)
  • nutrition_assessments — INSERT (new assessment), UPDATE (if amended)
  • diet_orders — READ only (for context)
  • meal_plans — READ only (for context; may be indirectly adjusted in other workflows)

Mermaid Flowchart

flowchart TD A["Nurse opens Nutrition Screening Form"] --> B["Load patient, encounter, tool config"] B --> C["Nurse completes screening questions"] C --> D["Auto-calculate score & risk level"] D --> E["Insert record into nutrition_screening"] E --> F{"Risk level moderate/high?"} F -->|"Yes"| G["Auto-refer to dietitian & flag worklist"] F -->|"No"| H["Mark as low risk; schedule routine rescreen"] G --> I["Dietitian opens Nutrition Assessment"] H --> I I --> J["Load screening, anthropometrics, labs"] J --> K["Dietitian documents assessment & malnutrition risk"] K --> L["Define calorie/protein/fluid targets & care plan"] L --> M["Insert record into nutrition_assessments"] M --> N["Link to diet orders & meal plans; schedule reassessment"] N --> O{"Malnutrition indicators present but not coded?"} O -->|"Yes"| P["Prompt to add ICD-10-AM malnutrition diagnosis"] O -->|"No"| Q["No coding prompt"] P --> R["Write summary note to EHR"] Q --> R R --> S["End"]

Decision Points

  1. Risk level threshold
    - If risk_level = low → no immediate dietitian referral; rescreen per policy (e.g., weekly).
    - If risk_level = moderate/high → automatic dietitian referral and SLA tracking.

  2. Availability of anthropometrics and labs
    - If recent weight/height or labs missing → system prompts nurse/dietitian to order measurements or labs; assessment can be saved with missing data flagged.

  3. Malnutrition coding prompt
    - If assessment indicates malnutrition (per tool) and no corresponding ICD-10-AM code in problem list → system prompts for coding; if user declines, requires reason (e.g., not clinically confirmed).

Integration Points

  • EHR Patient Chart (INT-NUT-003)
  • Inbound: anthropometrics, problem list.

  • Outbound: nutrition screening and assessment summaries as clinical notes.

  • LIS (INT-NUT-005)

  • Inbound: lab results (albumin, prealbumin, electrolytes, glucose).

  • Used to support assessment and monitoring.

  • Scheduling

  • Used to schedule reassessment tasks (may be via task/appointment subsystem).

Exception Handling

  • Screening not completed within 24h of admission:

  • System generates alert to nursing manager and flags patient on Nutrition Analytics Dashboard (SCR-NUT-008).

  • LIS connectivity issues:

  • Assessment can proceed with last available labs; system marks lab section as “data unavailable” and logs integration error.

  • Partial assessment (patient off ward, non-cooperative):

  • Dietitian can save incomplete assessment with status INCOMPLETE; system requires follow-up date.

  • PDPL considerations:

  • Access to screening/assessment limited by role; all access logged for audit.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Paper nutrition screening forms on admission Electronic screening in nutrition_screening with auto-scoring Ensures 100% legibility and automatic KPI tracking
Manual dietitian referral slips Auto-referral and worklist generation based on risk level Reduces missed referrals and delays
Handwritten nutrition care plans in paper charts Structured nutrition_assessments linked to diet orders and meal plans Enables analytics on targets vs. delivery
Manual tally of malnutrition cases for audits Systematic prompts and coded data Supports quality reporting to MOH/DOH/DHA

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Source Data Element Format
EHR / Patient Chart Patient demographics, weight, height, BMI patients table, vital_signs
Scheduling / ADT Active inpatient encounter encounters table
Nutrition Master Data Screening tool configuration (NRS-2002, MUST) Master data tables
Nurse Screening responses (weight loss, intake, disease severity) Nutrition Screening Form (SCR-NUT-003)
LIS (INT-NUT-005) Albumin, prealbumin, electrolytes, glucose HL7 ORU^R01 / FHIR Observation
Dietitian Assessment findings, malnutrition classification, calorie/protein targets Nutrition Assessment Form (SCR-NUT-004)

Outputs:

Destination Data Element Format
nutrition_screening Screening record with score, risk level, screened_by SQL INSERT
nutrition_assessments Assessment record with targets, findings, care plan SQL INSERT
Dietitian Work Queue Auto-referral for moderate/high risk patients Internal notification
EHR Clinical Notes (INT-NUT-003) Screening and assessment summaries FHIR Observation, CarePlan
Problem List ICD-10-AM malnutrition diagnosis prompt (if applicable) FHIR Condition (via EHR)
Scheduling Reassessment date/time Task/appointment record

Post-conditions:

  • Screening record exists in nutrition_screening with calculated score and risk level
  • If moderate/high risk: dietitian referral created and patient flagged in worklist
  • If assessment completed: targets and care plan linked to diet orders and meal plans
  • Summary note written to EHR clinical record for NABIDH/Malaffi sharing
  • Reassessment scheduled per facility policy

SLA and Timing

Step Target Time Escalation Measurement Source
Screening completion from admission < 24 hours Alert Nursing Manager at 24h nutrition_screening.screening_date minus encounters.admission_datetime
Auto-referral to dietitian (moderate/high risk) < 1 minute from screening completion Alert IT if > 5 min nutrition_screening.referred_datetime
Dietitian assessment (high risk) < 24 hours from referral Alert Dietitian Supervisor at 24h nutrition_assessments.assessment_date minus referral time
Dietitian assessment (moderate risk) < 48 hours from referral Alert Dietitian Supervisor at 48h nutrition_assessments.assessment_date minus referral time
Lab result availability for assessment < 4 hours from specimen collection Per LIS SLA lab_results.resulted_datetime
Reassessment (high risk inpatient) Every 3–5 days Alert at overdue date nutrition_assessments.next_reassessment_date
EHR note posting < 5 minutes from assessment save Alert if > 15 min Integration log timestamp

WF-NUT-003: Meal Production & Tray Assembly

Process Flow

Actor: Kitchen Manager, Kitchen Staff, Diet Technician, System
Trigger: Meal service time approaching (breakfast, lunch, dinner)
Pre-conditions:

  • Active diet orders in diet_orders and meal plans in meal_plans for the meal date/time
  • ADT census up to date (WF-NUT-006)
  • Menu cycles configured in menu_cycles and items in menu_items
  • Tray tickets generation logic configured
  1. At defined cut-off time before each meal (e.g., 2 hours), system runs production planning job.
  2. System queries meal_plans for the target meal date and meal type (e.g., breakfast) with status = 'PLANNED'.
  3. System aggregates required quantities per menu item: - Counts number of portions per menu_items.item_id considering diet type, texture, and supplements.
  4. System inserts or updates a kitchen_production_orders record for the meal: - production_items_json contains item IDs and quantities.
  5. System generates or updates tray_tickets for each patient: - Includes patient name, MRN, bed location, diet type, allergen alerts, menu items, special instructions, and barcode.
  6. Kitchen Manager views Kitchen Production Dashboard (SCR-NUT-006): - Reviews total tray count and item quantities. - Adjusts production if last-minute ADT changes occurred (system auto-refreshes).
  7. Kitchen Staff begin meal preparation: - Mark preparation status per item or batch in kitchen_production_orders (UPDATE).
  8. Diet Technician manages tray assembly using Tray Assembly & Delivery screen (SCR-NUT-007): - Scans tray ticket barcode to display patient-specific tray requirements.
  9. Staff assemble tray according to ticket: - System may require confirmation of key items (e.g., main dish, dessert, beverage).
  10. Decision: If an item is unavailable (stock-out or quality issue):
    • Staff select a system-suggested substitute from menu_items filtered by diet type, allergens, and halal status.
    • System updates tray_tickets.menu_items and kitchen_production_orders.production_items_json accordingly.
  11. Staff perform temperature logging:
    • Record hot/cold food temperatures in associated QC table (not owned here, but referenced) or within kitchen_production_orders extension.
  12. When all trays for a ward are assembled:
    • Diet Technician sets status = 'READY_FOR_DELIVERY' for relevant tray_tickets and updates kitchen_production_orders.status as appropriate.
  13. System timestamps production completion in kitchen_production_orders.completed_datetime.

Data Modified:

  • kitchen_production_orders — INSERT (new production order), UPDATE (status, completion time, item adjustments)
  • tray_tickets — INSERT (new tickets), UPDATE (substitutions, status, barcode scans)
  • meal_plans — READ only (source of planned meals)

Mermaid Flowchart

flowchart TD A["Scheduled production job runs"] --> B["Query meal_plans for meal date/type"] B --> C["Aggregate quantities per menu item"] C --> D["Insert/Update kitchen_production_orders"] D --> E["Generate/Update tray_tickets per patient"] E --> F["Kitchen Manager reviews Production Dashboard"] F --> G["Kitchen Staff prepare meals"] G --> H["Tray assembly using Tray Assembly screen"] H --> I["Scan tray ticket barcode"] I --> J{"All required items available?"} J -->|"Yes"| K["Confirm tray contents"] J -->|"No"| L["Suggest suitable substitutes"] L --> M["Staff select substitute item"] M --> N["Update tray_tickets & production order"] K --> O["Record temperature logs"] O --> P["Mark tray_tickets as READY_FOR_DELIVERY"] P --> Q["Update kitchen_production_orders status & completion time"] Q --> R["End"]

Decision Points

  1. Item availability
    - If item available → proceed with planned menu.
    - If unavailable → system suggests substitutes that match diet type, allergens, and halal requirements; staff must choose one or escalate to dietitian.

  2. Temperature compliance
    - If recorded temperature outside thresholds (hot ≥ 63°C, cold ≤ 5°C) → system flags QC alert and may require supervisor sign-off before release.

  3. Late ADT or diet order changes
    - If changes occur after cut-off → system can generate delta updates to kitchen_production_orders and tray_tickets; Kitchen Manager decides whether to accommodate or defer to next meal.

Integration Points

  • Scheduling / ADT (INT-NUT-002)

  • Inbound: updated census and bed locations for tray routing.

  • EHR Patient Management

  • Read: patient identifiers and bed locations.

  • Inventory / Materials Management (if present)

  • Optional integration to check stock levels for menu items.

Exception Handling

  • Production job failure:

  • System logs error and alerts Kitchen Manager; allows manual triggering of production run.

  • Barcode scanner failure:

  • Staff can manually select patient from list with dual verification (name + MRN + bed); system logs that barcode verification was bypassed.

  • Data inconsistency (tray ticket references non-existent menu item):

  • System prevents assembly, prompts for regeneration of tray ticket.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Paper production tallies for each meal kitchen_production_orders with aggregated quantities Reduces counting errors and improves forecasting
Handwritten tray tickets Electronic tray_tickets with barcodes and allergen alerts Enhances safety and traceability
Manual meal counts by ward Automated tray counts based on meal_plans and ADT census Aligns production with real-time census
Paper temperature logs Digital temperature entries linked to production orders Facilitates audits and quality reporting

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Source Data Element Format
meal_plans Planned meals for target meal date/type with patient, diet, and menu items SQL query
menu_items Menu item details, allergens, halal status, nutritional info Master data table
menu_cycles Active menu cycle for the facility Master data table
Scheduling / ADT (INT-NUT-002) Updated patient census and bed locations HL7 ADT / internal API
diet_orders Active diet orders with diet type, texture, restrictions SQL query
Kitchen Staff Item availability, substitutions, temperature readings Tray Assembly screen (SCR-NUT-007)

Outputs:

Destination Data Element Format
kitchen_production_orders Production order with aggregated item quantities SQL INSERT/UPDATE
tray_tickets Per-patient tray specifications with barcodes and allergen alerts SQL INSERT/UPDATE
Kitchen Production Dashboard (SCR-NUT-006) Total tray counts, item quantities, preparation status Real-time UI
cleaning_supplies_usage (conceptual) Temperature logs for QC compliance SQL INSERT

Post-conditions:

  • Kitchen production order exists with correct item quantities for the meal service
  • Tray tickets generated for every patient with active diet orders
  • All mandatory checklist items confirmed by kitchen staff
  • Temperature logs recorded for hot and cold food items
  • Tray status set to READY_FOR_DELIVERY for completed trays

SLA and Timing

Step Target Time Escalation Measurement Source
Production planning job completion < 2 minutes Alert IT if > 5 min kitchen_production_orders.generated_datetime
Tray ticket generation < 5 minutes after production planning Alert Kitchen Manager if > 10 min tray_tickets.created_datetime
Meal preparation (breakfast) Complete by 06:30 Alert Kitchen Manager at 06:15 if behind kitchen_production_orders.status
Meal preparation (lunch) Complete by 11:30 Alert Kitchen Manager at 11:15 if behind kitchen_production_orders.status
Meal preparation (dinner) Complete by 17:30 Alert Kitchen Manager at 17:15 if behind kitchen_production_orders.status
Tray assembly per ward < 20 minutes per ward Alert Supervisor if > 30 min tray_tickets start/end timestamps
Temperature compliance check At point of assembly QC alert if out of range (hot < 63°C, cold > 5°C) Temperature log entries

State Transition Diagram

stateDiagram-v2 [*] --> Planned : Meal plans exist for target meal Planned --> ProductionOrdered : Production planning job runs ProductionOrdered --> InPreparation : Kitchen staff begin cooking InPreparation --> PrepComplete : All items prepared PrepComplete --> TrayAssembly : Diet technician begins assembly TrayAssembly --> ReadyForDelivery : All trays assembled and verified TrayAssembly --> SubstitutionRequired : Item unavailable SubstitutionRequired --> TrayAssembly : Substitute selected ReadyForDelivery --> [*] Planned --> Cancelled : ADT discharge cancels meal Cancelled --> [*]

WF-NUT-004: Meal Delivery & Patient Satisfaction

Process Flow

Actor: Diet Technician, Nursing Assistant, System
Trigger: Trays assembled and marked as ready for delivery
Pre-conditions:

  • tray_tickets.status = 'READY_FOR_DELIVERY'
  • Patient location up to date via ADT (WF-NUT-006)
  • Mobile/tablet devices available with barcode scanning capability
  1. Diet Technician opens Tray Assembly & Delivery screen (SCR-NUT-007) in delivery mode.
  2. System displays list of trays ready for delivery, grouped by ward/room/bed.
  3. Staff select a tray and scan the tray ticket barcode.
  4. At patient bedside, staff scan patient wristband barcode (MRN/Emirates ID).
  5. System matches tray ticket patient ID with scanned patient ID.
  6. Decision: If IDs do not match: - System displays red alert and blocks delivery. - Staff must re-check tray and patient; may re-scan or return tray to kitchen.
  7. If IDs match: - System displays diet order summary (diet type, allergens, special instructions) for final verification.
  8. Staff deliver tray and mark tray_tickets.status = 'DELIVERED', recording delivered_datetime and delivered_by.
  9. System writes a corresponding meal_service_records entry: - Links to meal_plans and includes meal type, delivered time, and staff.
  10. After meal period, staff collect trays:
    • For patients requiring intake monitoring, staff open the meal record and enter consumption percentage and any comments.
  11. System updates meal_service_records.consumption_percentage and optionally patient_satisfaction_score (if survey completed).
  12. Decision: If consumption < threshold (e.g., <50%) or patient reports poor appetite:
    • System flags record and notifies dietitian for possible intervention.
  13. System aggregates satisfaction and intake data for Nutrition Analytics Dashboard (SCR-NUT-008).

Data Modified:

  • tray_tickets — UPDATE (status, delivery details)
  • meal_service_records — INSERT (on delivery), UPDATE (consumption, satisfaction)
  • meal_plans — READ only

Mermaid Flowchart

flowchart TD A["Open Tray Delivery mode"] --> B["View trays READY_FOR_DELIVERY by ward"] B --> C["Select tray & scan tray ticket barcode"] C --> D["Scan patient wristband"] D --> E{"Tray patient ID matches wristband ID?"} E -->|"No"| F["Show mismatch alert; block delivery"] F --> B E -->|"Yes"| G["Display diet summary & allergen alerts"] G --> H["Deliver tray; mark ticket DELIVERED"] H --> I["Insert meal_service_records entry"] I --> J["After meal, record consumption & satisfaction"] J --> K{"Poor intake or low satisfaction?"} K -->|"Yes"| L["Flag record & notify dietitian"] K -->|"No"| M["No action required"] L --> N["Data available for analytics"] M --> N N --> O["End"]

Decision Points

  1. Patient-tray identity match
    - If mismatch → hard stop; no delivery allowed until resolved.
    - If match → proceed with delivery.

  2. Intake adequacy
    - If consumption below configured threshold → system flags for dietitian review.
    - If adequate → no alert.

  3. Satisfaction score
    - If low score (e.g., <3/5) → optional workflow to log complaint or improvement suggestion.

Integration Points

  • EHR Patient Management

  • Wristband barcode data (MRN/Emirates ID) used for identity verification.

  • EHR Intake/Output (INT-NUT-003)

  • Outbound: food intake data may be summarised into overall intake/output records.

Exception Handling

  • Barcode unreadable:

  • Staff can manually select patient from list with dual verification (name + MRN + date of birth); system logs manual override.

  • Patient off ward or NPO (nil per os):

  • Staff can mark tray as “Not delivered – patient unavailable/NPO”; system updates meal_service_records with reason.

  • Device offline:

  • App caches delivery events locally and syncs when connectivity restored; timestamps preserved.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Paper delivery logs for trays tray_tickets status and meal_service_records timestamps Real-time visibility and traceability
Manual intake/output sheets for food Structured meal_service_records.consumption_percentage Enables calorie delivery vs. target KPI
Paper satisfaction surveys In-app satisfaction capture per meal Supports continuous quality improvement
Manual incident reporting for wrong-tray events Automated mismatch alerts and audit logs Reduces risk of wrong diet delivery

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Source Data Element Format / Notes
WF-NUT-003 (Meal Production) Assembled tray with ticket Physical tray + barcode ticket from tray_tickets
tray_tickets Tray details: patient ID, diet type, bed location, meal type Status = READY_FOR_DELIVERY
EHR Patient Management Patient wristband barcode (MRN / Emirates ID) Scanned at bedside for identity verification
diet_orders Active diet order summary (diet type, allergens, special instructions) Displayed for final verification before delivery
meal_plans Expected meal for this patient, meal type, and timing Links tray to planned meal service

Outputs:

Destination Data Element Format / Notes
tray_tickets Status = DELIVERED, delivered_datetime, delivered_by Updated on successful bedside verification and delivery
meal_service_records Delivery record: meal type, delivered time, staff ID, patient link INSERT on delivery
meal_service_records consumption_percentage, patient_satisfaction_score UPDATE after meal collection
Dietitian notification Low-intake or low-satisfaction alert Triggered if consumption < threshold or satisfaction score < 3/5
Nutrition Analytics Dashboard (SCR-NUT-008) Aggregated intake and satisfaction data Real-time feed for KPI reporting

Post-conditions:

  • Tray delivery recorded digitally with timestamp and staff identification
  • Patient identity verified via barcode match before every delivery
  • Consumption and satisfaction data captured for ongoing nutritional monitoring
  • Low-intake cases flagged for dietitian intervention

SLA and Timing

Step Target Time Escalation Measurement Source
Tray dispatch from kitchen to ward ≤ 20 min from production completion Alert kitchen manager if tray not dispatched within 25 min tray_tickets.status change from READY_FOR_DELIVERY to in-transit
Patient identity verification (barcode scan) ≤ 30 sec per tray N/A (real-time at bedside) Scan timestamp in tray_tickets
Tray delivery and status update ≤ 30 min from dispatch Alert if tray still not delivered 35 min after dispatch tray_tickets.delivered_datetime − dispatch time
Consumption and satisfaction recording ≤ 60 min after meal collection Alert if not recorded by end of meal service period meal_service_records.updated_at
Low-intake dietitian notification ≤ 5 min from recording Auto-escalate to dietitian supervisor if not acknowledged within 30 min Notification audit log

State Transition Diagram

stateDiagram-v2 [*] --> ReadyForDelivery : Tray assembled and ticketed (WF-NUT-003) ReadyForDelivery --> Dispatched : Staff picks tray for ward delivery Dispatched --> IdentityVerified : Patient wristband scanned, IDs match Dispatched --> MismatchBlocked : Patient wristband scanned, IDs do NOT match MismatchBlocked --> Dispatched : Re-check tray or return to kitchen IdentityVerified --> Delivered : Tray handed to patient, status updated Delivered --> IntakeRecorded : Staff records consumption % and satisfaction IntakeRecorded --> [*] : Meal service complete ReadyForDelivery --> Cancelled : Patient discharged, NPO, or off-ward Dispatched --> NotDelivered : Patient unavailable or refused NotDelivered --> [*] : Reason logged, dietitian notified Cancelled --> [*] : Tray returned to kitchen

WF-NUT-005: Enteral & Parenteral Nutrition Management

Process Flow

Actor: Physician, Dietitian, Pharmacist (for TPN), Nurse, System
Trigger: Patient unable to meet nutritional needs orally
Pre-conditions:

  • Active encounter in encounters
  • Nutrition assessment completed or in progress (nutrition_assessments)
  • CPOE integration for EN/TPN orders (INT-NUT-001, INT-NUT-004)
  • LIS integration for metabolic monitoring (INT-NUT-005)
  1. Physician opens CPOE and selects Enteral/Parenteral Nutrition order set.
  2. System loads: - Patient anthropometrics and latest nutrition assessment (if available). - Relevant labs (electrolytes, glucose, liver/renal function).
  3. Physician specifies: - Nutrition type (EN or TPN), route (NG, PEG, central line, etc.), and indication.
  4. Dietitian is notified (or co-authors order) to calculate requirements: - Reviews nutrition_assessments or performs quick assessment if none exists. - Determines calorie, protein, and fluid targets.
  5. For Enteral Nutrition (EN): - Dietitian selects formula from enteral_parenteral_orders.formula_name referencing facility formulary. - Sets rate (mL/hr), total volume, and schedule (continuous/bolus).
  6. For TPN: - Physician enters high-level prescription (e.g., kcal, grams of amino acids, dextrose, lipids). - Pharmacist uses PIS/TPN compounding system to derive detailed formulation.
  7. System validates order: - Checks against calorie/protein targets from nutrition_assessments. - Verifies fluid limits and electrolyte constraints based on labs.
  8. Physician signs order in CPOE.
  9. System inserts record into enteral_parenteral_orders with status = 'ACTIVE' and links to patient and encounter.
  10. For TPN, system sends order details to PIS/TPN compounding system (INT-NUT-004).
  11. Nurse administers EN/TPN:
    • Records start/stop times and any intolerance (e.g., residuals, GI symptoms) in EHR.
  12. System periodically calculates delivered calories vs. target:
    • Uses enteral_parenteral_orders and administration records to estimate delivered volume and energy.
  13. Decision: If delivered calories < threshold (e.g., <80% of target over 48h):
    • System flags case for dietitian review and potential order adjustment.
  14. When patient transitions to oral diet:
    • Physician/dietitian updates enteral_parenteral_orders.status = 'DISCONTINUED' and adjusts diet_orders accordingly.

Data Modified:

  • enteral_parenteral_orders — INSERT (new EN/TPN order), UPDATE (status, adjustments)
  • nutrition_assessments — READ (for targets), UPDATE (if reassessment)
  • diet_orders — UPDATE (when transitioning to oral diet)

Mermaid Flowchart

flowchart TD A["Physician selects EN/TPN order set in CPOE"] --> B["Load nutrition assessment & labs"] B --> C["Specify EN/TPN type, route, indication"] C --> D["Dietitian calculates calorie/protein/fluid requirements"] D --> E{"EN or TPN?"} E -->|"EN"| F["Select enteral formula, rate, volume, schedule"] E -->|"TPN"| G["Physician enters high-level TPN prescription"] G --> H["Pharmacist compounds detailed TPN in PIS"] F --> I["Validate against targets, fluid limits, labs"] H --> I I --> J{"Validation passed?"} J -->|"No"| K["Show errors; adjust order"] K --> C J -->|"Yes"| L["Physician e-signs order"] L --> M["Insert enteral_parenteral_orders with status ACTIVE"] M --> N["Send TPN details to PIS (if TPN)"] N --> O["Nurse administers & documents"] O --> P["System calculates delivered vs. target"] P --> Q{"Delivered < threshold?"} Q -->|"Yes"| R["Flag for dietitian review"] Q -->|"No"| S["Continue current regimen"] R --> T["Dietitian adjusts order or targets"] S --> T T --> U["Transition to oral diet when appropriate; discontinue EN/TPN"] U --> V["End"]

Decision Points

  1. EN vs. TPN selection
    - EN preferred when GI tract functional; TPN reserved for contraindications to EN.

  2. Validation against targets and labs
    - If order exceeds fluid limits or conflicts with electrolyte status → system blocks or requires override with justification.

  3. Calorie delivery adequacy
    - If delivered <80% of target over defined window → triggers review; may prompt change in rate, formula, or route.

Integration Points

  • CPOE (INT-NUT-001)

  • Inbound: order entry and e-signature context.

  • PIS / TPN Compounding (INT-NUT-004)

  • Outbound: TPN order details for compounding and label generation.

  • LIS (INT-NUT-005)

  • Inbound: metabolic labs for monitoring and dose adjustment.

  • EHR Nursing Documentation

  • Inbound: administration records used to calculate delivered calories.

Exception Handling

  • Missing nutrition assessment:

  • System prompts dietitian to complete assessment; order can be placed with provisional targets but flagged.

  • PIS integration failure:

  • TPN order remains in enteral_parenteral_orders with status = 'PENDING_PIS'; system retries and alerts pharmacy.

  • Lab data outdated:

  • System warns if key labs older than configured threshold (e.g., 72h); suggests ordering new labs.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Paper TPN calculation worksheets Structured EN/TPN orders in enteral_parenteral_orders with electronic calculations Reduces calculation errors and improves traceability
Manual enteral feeding records Electronic administration records linked to orders Enables accurate calorie delivery calculations
Handwritten calorie count sheets Automated estimation of delivered vs. target calories Supports TPN Order Accuracy KPI
Faxed TPN orders to pharmacy Real-time digital transmission to PIS Shortens turnaround time and reduces miscommunication

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Source Data Element Format / Notes
CPOE (INT-NUT-001) EN or TPN order: nutrition type, route, indication, clinical targets ORM^O01 or FHIR NutritionOrder / ServiceRequest
nutrition_assessments Calorie, protein, and fluid targets from dietitian assessment Referenced during order creation and validation
LIS (INT-NUT-005) Relevant lab results: albumin, electrolytes, glucose, triglycerides ORU^R01 or FHIR Observation; used for monitoring and dose adjustment
EHR Nursing Documentation EN/TPN administration records: start/stop times, volumes infused, intolerance events Inbound from nursing flow sheets
Facility formulary EN formula options and TPN compounding templates Master data from enteral_parenteral_orders.formula_name references

Outputs:

Destination Data Element Format / Notes
enteral_parenteral_orders New EN/TPN order record with status ACTIVE INSERT on physician signature
PIS / TPN Compounding (INT-NUT-004) TPN order details for compounding and labelling Outbound JSON API; sent for TPN orders only
nutrition_assessments Updated assessment if reassessment triggered UPDATE if dietitian revises targets
diet_orders Status change when transitioning patient from EN/TPN to oral diet UPDATE to discontinue EN/TPN and activate oral diet order
Dietitian notification Calorie delivery shortfall alert Triggered if delivered < 80% of target over 48 h

Post-conditions:

  • EN/TPN order active and linked to patient encounter
  • For TPN, compounding request transmitted to Pharmacy
  • Calorie delivery monitoring initiated with automated shortfall alerts
  • Transition to oral diet documented when clinically appropriate

SLA and Timing

Step Target Time Escalation Measurement Source
EN/TPN order entry and signing in CPOE ≤ 30 min from clinical decision Alert dietitian supervisor if order not signed within 1 h enteral_parenteral_orders.created_at − clinical decision timestamp
Dietitian target calculation ≤ 2 h from order placement (non-urgent) Escalate to lead dietitian if not completed within 4 h nutrition_assessments.updated_at
TPN order transmission to PIS ≤ 1 min from physician signature Alert if PIS acknowledgement not received within 5 min Integration engine message log
TPN compounding and delivery by Pharmacy ≤ 4 h from order receipt (per PIS SLA) Escalate to pharmacy supervisor if not compounded within 6 h PIS compounding status
Calorie delivery adequacy check Automated; evaluated every 24 h Dietitian notified if < 80% target over 48 h System calculation from administration records
Transition to oral diet documentation ≤ 30 min from clinical decision Alert if EN/TPN not discontinued within 2 h of oral diet order enteral_parenteral_orders.status change timestamp

State Transition Diagram

stateDiagram-v2 [*] --> Ordered : Physician selects EN/TPN in CPOE Ordered --> DietitianReview : Dietitian notified for target calculation DietitianReview --> Validated : Targets confirmed, order validated against labs Validated --> Signed : Physician e-signs order Signed --> Active : System activates order, records in enteral_parenteral_orders Active --> PendingPIS : TPN order sent to PIS for compounding (TPN only) PendingPIS --> Active : PIS acknowledges, compounding in progress Active --> Monitoring : Nurse administers, system tracks delivery vs. target Monitoring --> UnderTarget : Delivered calories < 80% of target over 48 h UnderTarget --> Adjusted : Dietitian adjusts rate, formula, or route Adjusted --> Monitoring : Revised order active, monitoring continues Monitoring --> Transitioning : Patient ready for oral diet Transitioning --> Discontinued : EN/TPN discontinued, oral diet order activated Discontinued --> [*] : EN/TPN lifecycle complete Active --> OnHold : Temporarily held (procedure, intolerance) OnHold --> Active : Hold removed, administration resumes Active --> Cancelled : Order cancelled before administration Cancelled --> [*]

WF-NUT-006: ADT-Triggered Census Update

Process Flow

Actor: System (automated), Dietitian (review), Kitchen Manager (review)
Trigger: ADT event (A01 admit, A02 transfer, A03 discharge) or diet order change
Pre-conditions:

  • HL7 ADT feed from Scheduling/ADT module configured (INT-NUT-002)
  • Mapping between ADT locations and nutrition service areas established
  • Default diet policy defined (e.g., “NPO until diet ordered” or “Regular” per facility)
  1. System receives ADT message (A01/A02/A03) from Scheduling module.
  2. System parses message and identifies: - Patient ID, encounter ID, facility, ward, room, bed. - Event type (admission, transfer, discharge).
  3. Admission (A01): - System adds patient to internal dietary census list. - Applies default diet policy:
    • Either creates a provisional diet_orders record (e.g., “NPO until evaluated”) or marks patient as “Awaiting diet order”.
  4. Transfer (A02): - System updates patient location in census and in tray_tickets for future meals. - Recalculates routing for meal delivery carts.
  5. Discharge (A03): - System removes patient from dietary census. - Sets any future meal_plans to status = 'CANCELLED'. - Updates tray_tickets for future meals to status = 'CANCELLED'.
  6. For any diet order change (from WF-NUT-001): - System triggers immediate refresh of meal plans and tray tickets for upcoming meals.
  7. System generates updated census reports per meal service: - Ward-wise tray counts and special diet counts available in Patient Dietary Census screen (SCR-NUT-002).
  8. Decision: If ADT message conflicts with existing encounter data (e.g., unknown encounter ID): - System logs error and places event in exception queue for manual reconciliation.
  9. Dietitian and Kitchen Manager can view real-time census and verify that admissions/transfers/discharges are reflected correctly.
  10. System retains ADT event history for audit and PDPL accountability.

Data Modified:

  • diet_orders — INSERT (default diet or NPO on admission, depending on policy), UPDATE (if status changes on discharge)
  • meal_plans — UPDATE (status changes), DELETE (if invalidated), INSERT (if new plans generated)
  • tray_tickets — UPDATE (location, status), INSERT (for new patients), DELETE (if invalidated)
  • Internal census structures (not necessarily a dedicated table; may be derived from encounters + diet_orders)

Mermaid Flowchart

flowchart TD A["Receive ADT event from Scheduling"] --> B["Parse patient, encounter, location, event type"] B --> C{"Event type?"} C -->|"A01 Admit"| D["Add patient to dietary census"] C -->|"A02 Transfer"| E["Update patient location & tray routing"] C -->|"A03 Discharge"| F["Remove from census; cancel future meals"] D --> G{"Default diet policy?"} G -->|"Create default diet order"| H["Insert provisional diet_orders record"] G -->|"Await explicit diet order"| I["Flag patient as Awaiting diet order"] E --> J["Update tray_tickets for future meals"] F --> K["Set future meal_plans & tray_tickets to CANCELLED"] H --> L["Generate meal_plans & tray_tickets as needed"] I --> L J --> L K --> L L --> M["Generate updated census reports"] M --> N{"Data consistency check passed?"} N -->|"No"| O["Log error & send to exception queue"] N -->|"Yes"| P["End"]

Decision Points

  1. Default diet policy on admission
    - If facility uses default NPO → create NPO diet order until physician orders specific diet.
    - If facility uses default regular diet → create regular diet order unless contraindicated.

  2. Handling of transfers
    - If transfer within same facility → update location only.
    - If transfer between facilities → may require re-generation of menu plans based on facility-specific menu cycles.

  3. Data consistency checks
    - If encounter ID not found or patient not known → event sent to exception queue for manual review.

Integration Points

  • Scheduling / ADT (INT-NUT-002)
  • Inbound: HL7 ADT messages (A01/A02/A03).

  • Data: patient, encounter, location, event type.

  • EHR Patient Management

  • Shared use of facilities, departments, locations for routing.

Exception Handling

  • Missing or malformed ADT messages:

  • System logs error with raw message; no census update performed; alerts IT.

  • Duplicate ADT events:

  • System detects duplicates based on message control ID; ignores duplicates while logging.

  • Network interruptions:

  • ADT interface engine queues messages; Nutrition module processes when connection restored.

Paperless Transformation

Previously Paper-Based Now Digital In-System Notes
Manual census boards in kitchen Real-time census derived from ADT and diet_orders Reflects admissions, transfers, discharges instantly
Phone calls from wards to kitchen for ADT updates Automated HL7 ADT-driven updates Reduces communication burden and errors
Paper diet change notices Event-driven updates to meal_plans and tray_tickets Ensures correct diet at next meal

Remaining Paper Touchpoints: None — fully digital.

Inputs and Outputs

Inputs:

Source Data Element Format / Notes
Scheduling / ADT (INT-NUT-002) ADT event: A01 (admit), A02 (transfer), A03 (discharge) HL7 ADT^A01/A02/A03 or FHIR Encounter
ADT message segments Patient ID, encounter ID, ward, room, bed, event timestamp Parsed from PID, PV1, EVN segments
Facility configuration Default diet policy (NPO vs. Regular), location-to-kitchen mapping Master data; determines behaviour on A01
WF-NUT-001 (Diet Order Entry) Diet order changes Internal event; triggers census refresh

Outputs:

Destination Data Element Format / Notes
diet_orders Provisional diet order on admission (e.g., NPO or default) INSERT on A01 (per facility policy)
diet_orders Status = COMPLETED or DISCONTINUED on discharge UPDATE on A03
meal_plans New plans for admitted patients; cancelled plans for discharged patients INSERT/UPDATE/DELETE based on event type
tray_tickets Updated bed location on transfer; cancelled tickets on discharge UPDATE (A02) or UPDATE status = CANCELLED (A03)
Patient Dietary Census (SCR-NUT-002) Real-time census with ward-wise tray counts and special diet counts Derived view from encounters + diet_orders
Exception queue Unmatched or conflicting ADT events Logged for manual reconciliation

Post-conditions:

  • Dietary census accurately reflects current inpatient population
  • Tray routing updated immediately after patient transfers
  • Discharged patients removed from future meal plans
  • Newly admitted patients appear on census with appropriate default diet status

SLA and Timing

Step Target Time Escalation Measurement Source
ADT message receipt and parsing ≤ 5 sec from ADT event Alert integration team if queue delay > 1 min Integration engine message receipt timestamp
Census update (A01/A02/A03 processing) ≤ 30 sec from message receipt Alert if processing > 2 min Census update log timestamp
Meal plan regeneration after census change ≤ 2 min from census update Alert kitchen manager if plans not ready 5 min before next meal cut-off meal_plans.created_at
Exception queue resolution ≤ 30 min for manual reconciliation Escalate to IT if unresolved within 1 h Exception queue age
Census report availability for next meal service Ready at least 30 min before meal service cut-off Alert dietitian and kitchen manager if census stale Census report generation timestamp
Next → Nutrition Management User Roles & Permissions
content/clinical/nutrition/01-workflows.md Generated 2026-02-20 22:54