Nutrition Management Integration Specifications

Integration Summary

INT-NUT-001: CPOE → Nutrition (Diet & EN/TPN Orders)

Business Context

What flows

• New and updated:
• Oral diet orders (diet type, texture, fluid restriction, supplements)
• Enteral nutrition (EN) orders
• Total parenteral nutrition (TPN) orders (clinical intent; detailed compounding goes to PIS)
• Patient demographics (MRN, Emirates ID, name, sex, DOB)
• Encounter context (inpatient location, attending physician)
• Special instructions (cultural/religious preferences, e.g., halal, vegetarian, diabetic)

When

• Immediately when a physician signs or modifies a diet/EN/TPN order in CPOE.

Why

• To:
• Generate accurate meal plans and kitchen production orders
• Ensure therapeutic diet compliance and allergy safety
• Initiate EN/TPN workflows and calorie tracking

How often

• Real-time, per order event.

Error impact

• If inbound order fails:
• Patient may not appear correctly on dietary census
• Wrong diet may be served or EN/TPN may not be initiated
• Requires urgent manual communication between ward and kitchen/dietitian

HL7 v2.5.1 Technical Detail

Message Type: ORM^O01 (Order message) from CPOE to Nutrition

Sample HL7 Message (Diet + EN order)

MSH|^~\&|HIS_CPOE|DUBAIHOSP|HIS_NUTRITION|DUBAIHOSP|20260207101530||ORM^O01|NUT-20260207101530-001|P|2.5.1|||AL|NE||UTF-8
PID|1||2026009876^^^DUBAIHOSP^MR~784-1980-1234567-3^^^UAE^EID||AL-NAHYAN^FATIMA^SAEED||19800612|F|||PO BOX 56789^^DUBAI^^00000^AE||+971501112233|||M||||||||||AE
PV1|1|I|5W^512^02^DUBAIHOSP||||ALI^OMAR^H^^^DR|||MED||||||||ENC-20260207-00045|||||||||||||||||||||||||20260207093000
AL1|1|FA|227493005^Peanut allergy^SCT|SV|Anaphylaxis|20190115
AL1|2|FA|91935009^Cow's milk protein allergy^SCT|MO|Rash|20200310
ORC|NW|DORD-20260207-0001||NUT-PLN-20260207-0001|CM||||20260207101530|||ALI^OMAR^H^^^DR^MBBS|||||DUBAIHOSP^Dubai General Hospital
OBR|1|DORD-20260207-0001||D001^Diet Order^L||20260207101530|||||||||ALI^OMAR^H^^^DR
ZDI|REG^Regular Diet^L|IDDSI-5^Minced & moist^IDDSI|1500|ml/24h|HALAL^Halal only^L|NO_PORK^No pork^L|NO_NUTS^No nuts^L|DIAB^Diabetic-friendly^L
ORC|NW|EN-20260207-0002||NUT-EN-20260207-0002|CM||||20260207102000|||ALI^OMAR^H^^^DR^MBBS
OBR|2|EN-20260207-0002||E001^Enteral Nutrition^L||20260207102000
ZTP|EN|FORM-ARAB-01^Isocaloric EN Formula^L|50|ml/h|1200|ml|24|h|NG^Nasogastric tube^L|CONT^Continuous^L|CAL1800^1800 kcal/day^L|PRO80^80 g protein/day^L
NTE|1||Please avoid spicy foods; patient prefers mild Emirati dishes.

Key segments

• PID: Patient identifiers (MRN + Emirates ID), demographics.
• PV1: Inpatient encounter and bed location used for tray routing.
• AL1: Food-related allergies (type FA).
• First ORC/OBR + ZDI:
• Diet order:
  • ZDI-1: Diet type (maps to diet_type_definitions.diet_type_id)
  • ZDI-2: Texture (maps to diet_orders.texture_modification)
  • ZDI-3: Fluid restriction (maps to diet_orders.fluid_restriction_ml)
  • ZDI-4..7: Cultural/religious and preference flags
• Second ORC/OBR + ZTP:
• EN order:
  • ZTP-1: Nutrition type (EN vs TPN)
  • ZTP-2: Formula (maps to enteral_parenteral_orders.formula_name)
  • ZTP-3..7: Rate and total volume
  • ZTP-8..12: Route, schedule, calorie/protein targets

Field mapping to Nutrition tables

FHIR R4 Technical Detail

For internal API, Nutrition exposes a FHIR-style endpoint; CPOE may alternatively call it directly instead of HL7.

Resource Types

• NutritionOrder for oral diet and enteral orders
• ServiceRequest or NutritionOrder extension for TPN clinical order (compounding details go to PIS)

Sample FHIR NutritionOrder (Diet + EN)

{
  "resourceType": "NutritionOrder",
  "id": "DORD-20260207-0001",
  "status": "active",
  "intent": "order",
  "patient": {
    "reference": "Patient/2026009876",
    "display": "Fatima Saeed Al-Nahyan"
  },
  "encounter": {
    "reference": "Encounter/ENC-20260207-00045"
  },
  "dateTime": "2026-02-07T10:15:30+04:00",
  "orderer": {
    "reference": "Practitioner/ALI-OMAR",
    "display": "Dr. Omar H. Ali"
  },
  "oralDiet": {
    "type": [
      {
        "coding": [
          {
            "system": "http://gates-his.ae/codes/diet-type",
            "code": "REG",
            "display": "Regular Diet"
          }
        ]
      }
    ],
    "texture": [
      {
        "modifier": {
          "coding": [
            {
              "system": "http://www.iddsi.org",
              "code": "5",
              "display": "Minced & moist"
            }
          ]
        }
      }
    ],
    "fluidConsistencyType": [
      {
        "coding": [
          {
            "system": "http://gates-his.ae/codes/fluid-restriction",
            "code": "FR1500",
            "display": "1500 ml/24h"
          }
        ]
      }
    ],
    "instruction": "Halal only, no pork, no nuts, diabetic-friendly. Avoid spicy food."
  },
  "enteralFormula": {
    "baseFormulaProductName": "Isocaloric EN Formula",
    "baseFormulaType": {
      "coding": [
        {
          "system": "http://gates-his.ae/codes/enteral-formula",
          "code": "FORM-ARAB-01",
          "display": "Isocaloric EN Formula"
        }
      ]
    },
    "administration": [
      {
        "schedule": {
          "repeat": {
            "boundsPeriod": {
              "start": "2026-02-07T10:20:00+04:00"
            }
          }
        },
        "quantity": {
          "value": 1200,
          "unit": "mL",
          "system": "http://unitsofmeasure.org",
          "code": "mL"
        },
        "rateQuantity": {
          "value": 50,
          "unit": "mL/h",
          "system": "http://unitsofmeasure.org",
          "code": "mL/h"
        }
      }
    ]
  },
  "extension": [
    {
      "url": "http://gates-his.ae/fhir/StructureDefinition/calorie-target",
      "valueQuantity": {
        "value": 1800,
        "unit": "kcal/d",
        "system": "http://unitsofmeasure.org",
        "code": "kcal/d"
      }
    },
    {
      "url": "http://gates-his.ae/fhir/StructureDefinition/protein-target",
      "valueQuantity": {
        "value": 80,
        "unit": "g/d",
        "system": "http://unitsofmeasure.org",
        "code": "g/d"
      }
    }
  ]
}

Key element mappings

Search parameters (Nutrition API)

• GET /NutritionOrder?patient={patientId}
• GET /NutritionOrder?encounter={encounterId}
• GET /NutritionOrder?status=active&patient={patientId}
• GET /NutritionOrder?date=ge2026-02-07&date=le2026-02-08

Error Handling

Manual recovery:

1. Interface dashboard lists failed orders with patient, encounter, and error.
2. Dietitian or IT can: - Reprocess message after correction, or - Manually create diet/EN/TPN order in Nutrition module and link to encounter.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Messages exhausting all retries → integration_dlq table
• Admin dashboard for manual review, correction, and requeue
• Retention: 30 days active, then archive to cold storage
• Alert: dietitian supervisor + integration team notified on DLQ insertion

Idempotency:

• Deduplication key: [order_id]_[ORM^O01]_[message_datetime]
• Nutrition module checks for duplicate order_id before processing; treats duplicates as updates (idempotent upsert)
• Duplicate messages return AA ACK without reprocessing

Reconciliation:

• Daily batch comparison: CPOE medication_orders (diet/EN/TPN subset) vs Nutrition diet_orders + enteral_parenteral_orders
• Unmatched records flagged for dietitian / interface analyst review
• Reconciliation report available in integration admin module
• Monthly trend reporting on message success rates

INT-NUT-002: Scheduling (ADT) → Nutrition (Census Management)

Business Context

What flows

• Admission (A01), transfer (A02), discharge (A03) events with:
• Patient identifiers
• Encounter/visit number
• Bed/ward/facility
• Admission/discharge timestamps

When

• Every time an inpatient is admitted, transferred, or discharged.

Why

• To maintain an accurate dietary census:
• Add new inpatients with default diet
• Update bed/ward for tray routing
• Remove discharged patients and cancel pending meals

How often

• Real-time, per ADT event.

Error impact

• If ADT messages fail:
• Kitchen may miss new patients or continue sending meals to discharged patients
• Tray routing may be wrong after transfers
• Requires manual phone calls and paper lists

HL7 v2.5.1 Technical Detail

Message Types: ADT^A01, ADT^A02, ADT^A03

Sample ADT^A01 (Admission)

MSH|^~\&|HIS_ADT|ABUDHABIHOSP|HIS_NUTRITION|ABUDHABIHOSP|20260207100000||ADT^A01|ADT-20260207-0001|P|2.5.1|||AL|NE||UTF-8
EVN|A01|20260207095500|||USER1^ADMIN^AHMED
PID|1||2026005432^^^ABUDHABIHOSP^MR~784-1975-7654321-8^^^UAE^EID||AL-MAKTOUM^AHMED^KHALID||19750620|M|||PO BOX 112233^^ABU DHABI^^00000^AE||+971502223344|||M||||||||||AE
PV1|1|I|7E^702^01^ABUDHABIHOSP||||HASSAN^LAILA^M^^^DR|||MED||||||||ENC-20260207-01001|||||||||||||||||||||||||20260207095000

Sample ADT^A02 (Transfer)

MSH|^~\&|HIS_ADT|ABUDHABIHOSP|HIS_NUTRITION|ABUDHABIHOSP|20260207140000||ADT^A02|ADT-20260207-0002|P|2.5.1
EVN|A02|20260207135500|||USER1^ADMIN^AHMED
PID|1||2026005432^^^ABUDHABIHOSP^MR
PV1|1|I|7E^702^01^ABUDHABIHOSP||||HASSAN^LAILA^M^^^DR|||MED||||||||ENC-20260207-01001|||||||||||||||||||||||||20260207095000
PV2|||^^^8ICU^803^02^ABUDHABIHOSP

Sample ADT^A03 (Discharge)

MSH|^~\&|HIS_ADT|ABUDHABIHOSP|HIS_NUTRITION|ABUDHABIHOSP|20260208110000||ADT^A03|ADT-20260208-0003|P|2.5.1
EVN|A03|20260208104500|||USER1^ADMIN^AHMED
PID|1||2026005432^^^ABUDHABIHOSP^MR
PV1|1|I|8ICU^803^02^ABUDHABIHOSP||||HASSAN^LAILA^M^^^DR|||MED||||||||ENC-20260207-01001||||||||||||||||||||01|||||20260208104500

Key segment usage

• PID-3: MRN and Emirates ID for patient resolution.
• PV1-2: Patient class; Nutrition processes only I (inpatient) and optionally E (ED obs).
• PV1-3: Current location (ward/room/bed).
• PV1-19: Visit/encounter number (maps to encounters.encounter_id).
• PV1-36 & PV1-45 (A03): Discharge disposition and time.

Field mapping

On A01:

1. Create census entry and default diet_orders row (e.g., “NPO” or facility default).
2. Generate initial meal_plans for upcoming meals if diet is known.

On A02:

1. Update tray_tickets.bed_location and meal_plans routing.

On A03:

1. Cancel future meal_plans and tray_tickets.
2. Mark diet_orders.status as completed or discontinued.

FHIR R4 Technical Detail

If Scheduling exposes FHIR:

• Encounter and Patient resources drive census.

Sample Encounter

{
  "resourceType": "Encounter",
  "id": "ENC-20260207-01001",
  "status": "in-progress",
  "class": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "IMP",
    "display": "inpatient encounter"
  },
  "subject": {
    "reference": "Patient/2026005432",
    "display": "Ahmed Khalid Al-Maktoum"
  },
  "period": {
    "start": "2026-02-07T09:50:00+04:00"
  },
  "location": [
    {
      "location": {
        "reference": "Location/7E-702-01",
        "display": "Ward 7E, Room 702, Bed 01"
      },
      "status": "active"
    }
  ],
  "serviceProvider": {
    "reference": "Organization/ABUDHABIHOSP",
    "display": "Abu Dhabi General Hospital"
  }
}

Search parameters

• GET /Encounter?status=in-progress&class=IMP
• GET /Encounter?patient={patientId}&status=in-progress

Nutrition periodically (or via subscription) updates census from these.

Error Handling

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• ADT messages exhausting all retries → integration_dlq table
• Kitchen manager alerted to maintain temporary manual census until resolved
• Retention: 30 days active, then archive
• Alert: kitchen manager + IT notified on DLQ insertion

Idempotency:

• Deduplication key: [PV1-19 (encounter_id)]_[EVN-1 (event_type)]_[MSH-10 (message_control_id)]
• Duplicate events ignored if no state change detected
• ADT events processed in order; out-of-order events (e.g., A03 before A01) held in pending queue

Reconciliation:

• Hourly comparison: Scheduling active encounters vs Nutrition dietary census
• Patients in Scheduling but missing from census → auto-add with default diet and flag for review
• Patients in census but discharged in Scheduling → auto-cancel future meals and flag
• Daily reconciliation report for kitchen manager and dietitian lead

INT-NUT-003: Nutrition ↔ EHR (Patient Chart)

Business Context

What flows

• Inbound to Nutrition:
• Patient allergies (food and non-food)
• Anthropometrics: weight, height, BMI if calculated in EHR
• Outbound to EHR:
• Nutrition screening results
• Nutrition assessments and care plans
• Meal intake/consumption percentages
• Patient meal satisfaction scores (optional in chart)

When

• Inbound:
• On opening Nutrition screens (on-demand)
• When allergies/weight/height updated in EHR (event-driven)
• Outbound:
• When screening or assessment is saved
• When intake is recorded

Why

• To maintain a unified clinical record and avoid duplicate documentation.
• To support malnutrition coding and quality metrics.

How often

• Real-time, per event.

Error impact

• If inbound fails: dietitians may work with outdated allergy or weight data.
• If outbound fails: nutrition documentation may be missing from the main chart, affecting care and coding.

FHIR R4 Technical Detail (Internal API)

Inbound resources

• AllergyIntolerance (food allergies)
• Observation (weight, height, BMI)

Outbound resources

• Observation (screening scores, intake)
• CarePlan (nutrition care plan)
• Composition or DocumentReference (full assessment note)

Sample inbound AllergyIntolerance (Peanut)

{
  "resourceType": "AllergyIntolerance",
  "id": "ALG-PEANUT-001",
  "clinicalStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical",
        "code": "active"
      }
    ]
  },
  "verificationStatus": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/allergyintolerance-verification",
        "code": "confirmed"
      }
    ]
  },
  "type": "allergy",
  "category": ["food"],
  "criticality": "high",
  "code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "227493005",
        "display": "Allergy to peanut"
      }
    ],
    "text": "Peanut allergy"
  },
  "patient": {
    "reference": "Patient/2026009876",
    "display": "Fatima Saeed Al-Nahyan"
  },
  "onsetDateTime": "2019-01-15",
  "reaction": [
    {
      "manifestation": [
        {
          "coding": [
            {
              "system": "http://snomed.info/sct",
              "code": "39579001",
              "display": "Anaphylaxis"
            }
          ]
        }
      ],
      "severity": "severe"
    }
  ]
}

Mapping to food_allergen_alerts

Sample outbound Observation (Nutrition Screening)

{
  "resourceType": "Observation",
  "id": "NSCR-20260207-0001",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "survey",
          "display": "Survey"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "76458-9",
        "display": "Nutritional risk screening tool"
      }
    ],
    "text": "NRS-2002 score"
  },
  "subject": {
    "reference": "Patient/2026009876"
  },
  "encounter": {
    "reference": "Encounter/ENC-20260207-00045"
  },
  "effectiveDateTime": "2026-02-07T11:00:00+04:00",
  "valueQuantity": {
    "value": 4,
    "unit": "score"
  },
  "interpretation": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation",
          "code": "H",
          "display": "High"
        }
      ]
    }
  ],
  "note": [
    {
      "text": "High risk; auto-referral to dietitian."
    }
  ]
}

Mapping to nutrition_screening

Search parameters

• GET /AllergyIntolerance?patient={patientId}&category=food
• GET /Observation?patient={patientId}&code=76458-9 (screening)
• GET /Observation?patient={patientId}&code=29463-7 (weight)
• GET /CarePlan?patient={patientId}&category=nutrition

Error Handling

Manual recovery:

• Dietitian can re-push a specific assessment or screening from Nutrition UI (“Resend to EHR”).
• IT can export failed payload from dead-letter queue and replay via admin tool.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Outbound FHIR resources exhausting all retries → integration_dlq table
• Dietitian lead alerted; documentation may be missing from patient chart
• Retention: 30 days active, then archive
• Alert: dietitian lead + integration team notified on DLQ insertion

Idempotency:

• Deduplication key: [resource_type]_[resource_id]_[effectiveDateTime]
• EHR performs idempotent upsert on matching resource ID
• Duplicate submissions return HTTP 200 without reprocessing

Reconciliation:

• Daily comparison: Nutrition nutrition_screening + nutrition_assessments vs EHR clinical documentation
• Missing outbound documents flagged for re-push
• Stale inbound allergy/weight data flagged if not refreshed within 24 h
• Weekly reconciliation report for dietitian lead and IT

INT-NUT-004: Nutrition → PIS (TPN Compounding)

Business Context

What flows

• For TPN orders:
• Patient demographics and encounter
• Clinical targets (kcal/day, protein/day, fluid volume)
• High-level formulation parameters (e.g., “standard adult TPN”, glucose tolerance)
• Reference to ordering physician and dietitian

When

• When a TPN order is created or modified in Nutrition (or CPOE, depending on design) and marked “Ready for Pharmacy”.

Why

• Pharmacy needs structured TPN requirements to compound safely and efficiently.
• Supports TPN Order Accuracy KPI.

How often

• Real-time, per TPN order event.

Error impact

• If integration fails:
• Pharmacy may not see TPN orders; patient may miss critical nutrition.
• Requires manual phone/fax communication.

Technical Detail (Internal JSON API)

Endpoint

• POST /api/pis/tpn-orders
• PUT /api/pis/tpn-orders/{orderId}

Sample JSON payload

{
  "tpnOrderId": "TPN-20260207-0005",
  "patient": {
    "mrn": "2026009876",
    "emiratesId": "784-1980-1234567-3",
    "name": "Fatima Saeed Al-Nahyan",
    "dateOfBirth": "1980-06-12",
    "sex": "F"
  },
  "encounterId": "ENC-20260207-00045",
  "orderingPhysician": {
    "id": "ALI-OMAR",
    "name": "Dr. Omar H. Ali"
  },
  "dietitian": {
    "id": "DIET-001",
    "name": "Ms. Huda Al-Mansouri"
  },
  "clinicalTargets": {
    "caloriesKcalPerDay": 1800,
    "proteinGramsPerDay": 80,
    "totalVolumeMlPerDay": 2000
  },
  "administration": {
    "startDateTime": "2026-02-07T20:00:00+04:00",
    "durationDays": 3,
    "route": "central-line",
    "infusionType": "continuous"
  },
  "formulationPreferences": {
    "glucoseTolerance": "normal",
    "lipidEmulsion": "soybean-oil-based",
    "electrolyteRestrictions": "renal-adjusted",
    "comments": "Monitor triglycerides and daily electrolytes."
  },
  "status": "active"
}

Mapping from enteral_parenteral_orders

Error Handling

Manual recovery:

• Dietitian can print or export TPN summary and send to pharmacy if integration is down (temporary paper fallback).
• Once integration restored, orders can be re-sent with original timestamps for audit.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• TPN orders exhausting all retries → integration_dlq table
• Pharmacy supervisor + dietitian alerted immediately (patient safety concern)
• Nutrition UI shows banner: "TPN not yet sent to Pharmacy — manual communication required"
• Retention: 30 days active, then archive
• Alert: pharmacy supervisor + dietitian + IT notified on DLQ insertion

Idempotency:

• Deduplication key: [tpnOrderId]
• PIS performs idempotent upsert based on tpnOrderId; duplicate submissions update rather than create

Reconciliation:

• Every 4 hours: Nutrition enteral_parenteral_orders (TPN, status = ACTIVE) vs PIS TPN compounding queue
• Unmatched orders flagged for pharmacy and dietitian review
• Daily reconciliation report for pharmacy supervisor

INT-NUT-005: LIS → Nutrition (Nutritional Lab Markers)

Business Context

What flows

• Lab results relevant to nutrition:
• Serum albumin, prealbumin
• Electrolytes (Na, K, Mg, Phosphate)
• Glucose (fasting, random)
• Triglycerides (for TPN monitoring)

When

• When LIS finalizes relevant results.

Why

• Dietitians need up-to-date labs for assessment and EN/TPN monitoring.
• Supports malnutrition risk assessment and TPN safety.

How often

• Real-time, per result.

Error impact

• If results don’t reach Nutrition:
• Dietitians may work with outdated labs.
• TPN adjustments may be delayed.

HL7 v2.5.1 Technical Detail

Message Type: ORU^R01 (Observation Result)

Sample HL7 Message

MSH|^~\&|LIS|DUBAIHOSP|HIS_NUTRITION|DUBAIHOSP|20260207120000||ORU^R01|LAB-20260207-0001|P|2.5.1|||AL|NE||UTF-8
PID|1||2026009876^^^DUBAIHOSP^MR~784-1980-1234567-3^^^UAE^EID||AL-NAHYAN^FATIMA^SAEED||19800612|F
PV1|1|I|5W^512^02^DUBAIHOSP||||ALI^OMAR^H^^^DR|||MED||||||||ENC-20260207-00045
OBR|1|LAB-ORD-20260207-001||LABPANEL^Nutrition Panel^L||20260207113000|||||||20260207114500|||LABDOC^HASSAN^KHALID^^^DR
OBX|1|NM|1751-7^Albumin [Mass/volume] in Serum or Plasma^LN||32|g/L|35-50|L|||F|||20260207115900
OBX|2|NM|14338-8^Prealbumin [Mass/volume] in Serum or Plasma^LN||0.12|g/L|0.20-0.40|L|||F|||20260207115900
OBX|3|NM|2345-7^Glucose [Mass/volume] in Serum or Plasma^LN||9.8|mmol/L|3.9-7.8|H|||F|||20260207115900

Key segments

• OBR: Nutrition-related panel.
• OBX:
• OBX-3: LOINC-coded test.
• OBX-5: Result value.
• OBX-7: Reference range.
• OBX-8: Abnormal flag (L, H).

Mapping

Nutrition may not persist all lab values but will:

• Cache latest relevant labs per patient/encounter for display in nutrition_assessments.
• Optionally store in a small nutrition_lab_cache table keyed by patient + test code.

FHIR R4 Technical Detail

If LIS exposes FHIR:

Resource: Observation

Sample Observation (Albumin)

{
  "resourceType": "Observation",
  "id": "LAB-ALB-20260207-0001",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "laboratory"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "1751-7",
        "display": "Albumin [Mass/volume] in Serum or Plasma"
      }
    ],
    "text": "Serum albumin"
  },
  "subject": {
    "reference": "Patient/2026009876"
  },
  "encounter": {
    "reference": "Encounter/ENC-20260207-00045"
  },
  "effectiveDateTime": "2026-02-07T11:59:00+04:00",
  "valueQuantity": {
    "value": 32,
    "unit": "g/L",
    "system": "http://unitsofmeasure.org",
    "code": "g/L"
  },
  "referenceRange": [
    {
      "low": { "value": 35, "unit": "g/L" },
      "high": { "value": 50, "unit": "g/L" }
    }
  ],
  "interpretation": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation",
          "code": "L",
          "display": "Low"
        }
      ]
    }
  ]
}

Search parameters

• GET /Observation?patient={patientId}&code=1751-7 (albumin)
• GET /Observation?patient={patientId}&category=laboratory&date=ge2026-02-01

Error Handling

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Lab messages exhausting all retries → integration_dlq table
• If unmatched for > 24 h, alert integration team
• Nutrition UI shows banner: “Latest labs may be delayed” when recent fetch fails
• Retention: 30 days active, then archive

Idempotency:

• Deduplication key: [patient_id]_[LOINC_code]_[effectiveDateTime]
• Nutrition lab cache performs upsert; duplicate results overwrite previous value for same test and timestamp

Reconciliation:

• Daily comparison: LIS finalized results (nutrition-relevant LOINC codes) vs Nutrition lab cache
• Missing results flagged for interface analyst review
• Stale cache entries (> 72 h without refresh for active patients) flagged for dietitian awareness

INT-NUT-006: Nutrition → Billing & Claims

Business Context

What flows

• Charge events for:
• Dietitian consultations (initial, follow-up)
• EN/TPN daily management
• Special supplements (e.g., oral nutritional supplements)

When

• Charges are accumulated during the day and sent in a nightly batch.

Why

• To ensure all nutrition-related services are billed correctly to payers (e.g., Daman, THIQA, Oman Insurance).
• Supports revenue capture and Malnutrition Documentation Rate KPI.

How often

• Daily batch (e.g., 23:30 UAE time).

Error impact

• If batch fails:
• Revenue loss or delayed billing.
• Requires manual reconciliation.

HL7 v2.5.1 Technical Detail

Message Type: DFT^P03 (Detailed Financial Transaction) – optional; some sites may use internal JSON only.

Sample HL7 DFT^P03

MSH|^~\&|HIS_NUTRITION|DUBAIHOSP|BILLING|DUBAIHOSP|20260207233000||DFT^P03|DFT-20260207-0001|P|2.5.1|||AL|NE||UTF-8
EVN|P03|20260207232900
PID|1||2026009876^^^DUBAIHOSP^MR~784-1980-1234567-3^^^UAE^EID||AL-NAHYAN^FATIMA^SAEED||19800612|F
PV1|1|I|5W^512^02^DUBAIHOSP||||ALI^OMAR^H^^^DR|||MED||||||||ENC-20260207-00045
FT1|1|20260207110000|20260207113000||99205^Initial nutrition assessment^CPT|1|EA|||DIET-001^AL-MANSOURI^HUDA|||20260207113000|||NUT-CHG-0001
FT1|2|20260207190000|20260207193000||97802^Medical nutrition therapy, follow-up^CPT|1|EA|||DIET-001^AL-MANSOURI^HUDA|||20260207193000|||NUT-CHG-0002
FT1|3|20260207120000|20260207120000||B4185^Parenteral nutrition; 10-50 liters^HCPCS|1|EA|||ALI^OMAR^H^^^DR|||20260207120000|||NUT-CHG-0003

Key segments

• FT1-6: Procedure code (CPT/HCPCS or local code).
• FT1-7: Quantity.
• FT1-13: Performing provider (dietitian or physician).
• FT1-19: Internal charge ID.

Mapping from Nutrition

• Source tables: nutrition_assessments, enteral_parenteral_orders, meal_service_records.
• A charge engine in Nutrition aggregates these into nutrition_charges (internal) before DFT generation.

Internal API (JSON)

If Billing prefers REST:

{
  "batchId": "NUT-BILL-20260207",
  "facilityId": "DUBAIHOSP",
  "serviceDate": "2026-02-07",
  "charges": [
    {
      "chargeId": "NUT-CHG-0001",
      "patientMrn": "2026009876",
      "encounterId": "ENC-20260207-00045",
      "code": "99205",
      "codeSystem": "CPT",
      "description": "Initial nutrition assessment",
      "quantity": 1,
      "unit": "EA",
      "performingProviderId": "DIET-001",
      "serviceStart": "2026-02-07T11:00:00+04:00",
      "serviceEnd": "2026-02-07T11:30:00+04:00"
    }
  ]
}

Error Handling

Manual recovery:

• Finance can request re-send of a specific batch.
• Nutrition can export charges as CSV for manual upload if integration is down.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed batches → integration_dlq table
• Finance team alerted; batch marked as FAILED in Nutrition
• Retention: 90 days active (financial data retention requirement), then archive
• Alert: finance team + IT notified on DLQ insertion

Idempotency:

• Deduplication key: [batchId]_[chargeId]
• Billing performs idempotent processing; duplicate charges ignored
• Re-sent batches with same batchId are treated as retries, not new submissions

Reconciliation:

• Daily (morning after batch): Nutrition nutrition_charges vs Billing accepted charges
• Rejected charges reviewed and corrected by finance; re-submitted in next batch
• Monthly revenue reconciliation: total nutrition charges vs billed amounts
• Quarterly audit of charge capture completeness

INT-NUT-007: Nutrition → NABIDH / Malaffi (HIE)

Business Context

What flows

• Outbound summary data to regional HIEs:
• Nutrition assessments (malnutrition risk, BMI, care plan summary)
• EN/TPN therapy summary (start/stop, type)
• Key observations (e.g., BMI, weight trends) – usually already sent by EHR, but Nutrition may contribute structured malnutrition assessments.

When

• When a nutrition assessment is signed or EN/TPN is started/ended.
• Sent in near real-time batches (e.g., every 15 minutes) to reduce overhead.

Why

• To support continuity of care across facilities in Dubai (NABIDH) and Abu Dhabi (Malaffi).
• To support public health and quality analytics.

How often

• Near real-time, small batches.

Error impact

• If HIE submission fails:
• External providers may not see latest nutrition data.
• No direct impact on internal care, but regulatory reporting may be incomplete.

NABIDH / Malaffi Technical Detail

Profiles are based on HL7 v2.5.1 and FHIR R4 with local constraints. Nutrition will typically piggyback on:

• FHIR Observation for BMI and malnutrition risk.
• FHIR CarePlan for nutrition care plan.
• HL7 ORU^R01 for non-FHIR endpoints if required.

Sample FHIR Observation (Malnutrition risk for HIE)

{
  "resourceType": "Observation",
  "id": "HIE-MALNUTRISK-20260207-0001",
  "meta": {
    "profile": [
      "http://nabidh.dha.gov.ae/fhir/StructureDefinition/nutrition-risk-observation"
    ]
  },
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "survey"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "76458-9",
        "display": "Nutritional risk screening tool"
      }
    ],
    "text": "NRS-2002 score"
  },
  "subject": {
    "identifier": {
      "system": "http://identity.ica.gov.ae/emirates-id",
      "value": "784-1980-1234567-3"
    }
  },
  "effectiveDateTime": "2026-02-07T11:00:00+04:00",
  "valueQuantity": {
    "value": 4,
    "unit": "score"
  }
}

Required fields (typical NABIDH/Malaffi expectations)

• Patient identifier (Emirates ID preferred).
• Encounter or episode reference.
• Observation code (LOINC).
• Status, effective date/time, value.

Acknowledgement handling

• For HL7: Expect ACK with MSA-1 = AA/AE/AR.
• For FHIR: Use Bundle transactions; check HTTP 200/201 and OperationOutcome for errors.

Error Handling

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Outbound HIE bundles exhausting all retries → integration_dlq table
• Queued bundles retained for up to 7 days for re-submission when HIE recovers
• Compliance officer alerted; regulatory reporting may be incomplete
• Retention: 90 days active (regulatory data), then archive
• Alert: compliance officer + integration team notified on DLQ insertion

Idempotency:

• Deduplication key: [Emirates_ID]_[resource_type]_[resource_id]_[effectiveDateTime]
• HIE performs duplicate detection on submission; duplicate bundles acknowledged without reprocessing

Reconciliation:

• Daily comparison: Nutrition outbound HIE queue (submitted) vs HIE acknowledgements (accepted)
• Rejected resources flagged for compliance officer review and correction
• Weekly HIE submission success rate report
• Monthly audit of regulatory reporting completeness for DOH/DHA compliance

Authentication & Security

All integrations must comply with UAE PDPL, DOH ADHICS, and DHA/NABIDH security requirements, as well as TDRA/NESA cybersecurity standards.

Transport Security

• All external and cross-module traffic over HTTPS (TLS 1.2+).
• HL7 v2 over MLLP must be wrapped in TLS (mTLS where possible).
• Certificates:
• Issued by trusted CA or internal PKI.
• Separate certificates per environment (DEV/UAT/PROD).

Authentication

• Internal REST APIs (EHR, PIS, Billing):
• OAuth 2.0 client credentials flow.
• Nutrition module acts as confidential client with client_id/client_secret.
• Access tokens scoped (e.g., scope: nutrition.read nutrition.write).
• HL7 interfaces:
• Mutual TLS at transport layer.
• Optional IP whitelisting between interface engines.
• HIE (NABIDH/Malaffi):
• mTLS with facility-specific certificates.
• OAuth 2.0 or JWT-based tokens as per HIE specification.

Authorization & Data Minimisation

• Nutrition module only requests and sends data necessary for its function (e.g., only nutrition-related labs).
• Role-based access control enforced within Nutrition (dietitian, nurse, kitchen staff).
• Outbound HIE payloads exclude unnecessary identifiers in line with PDPL minimisation principles.

Message Encryption & Integrity

• TLS provides encryption in transit.
• For batch files (if ever used), use AES-256 encryption at rest and during transfer (e.g., SFTP with SSH keys).
• Digital signatures or MACs may be used for high-sensitivity payloads (e.g., TPN orders) as per facility policy.

Logging & Audit

• All integration calls logged with:
• Timestamp, source, destination, patient identifier (pseudonymised where possible), operation type, outcome.
• Access to logs restricted to authorised IT and compliance staff.
• Audit trails retained according to MOH/DOH/DHA retention policies.

Error Monitoring & Alerting

• Central integration engine monitors:
• Queue lengths
• Error rates per interface
• ACK/NAK patterns
• Alerts:
• Email/SMS/ITSM ticket when:
  • Consecutive failures > configurable threshold (e.g., 5).
  • Queue delay > 10 minutes for real-time interfaces.
  • HIE submissions fail for > 1 hour.

This specification covers all Nutrition Management integrations required for the UAE deployment and is intended to be directly consumable by development and integration teams.