Blood Bank Management Integration Specifications

Integration Summary

INT-BB-001: CPOE (Orders & Results)

Business Context

What flows

• Inbound to Blood Bank
• Transfusion orders: component type, units, priority, indication, special requirements (irradiated, CMV-negative, etc.).
• Type & screen orders: ABO/Rh typing, antibody screen requests.

• Patient, encounter, and ordering provider context.

• Outbound to CPOE

• Type & screen results (ABO/Rh, antibody screen, antibody specificity).
• Crossmatch results and validity period.
• Component availability and allocation status (e.g., “2 RBC units crossmatched and reserved”).

When

• Inbound: when an ordering physician signs a transfusion or type & screen order in CPOE.
• Outbound: when blood bank completes type & screen or crossmatch, or when inventory allocation changes for an active order.

Why

• Ensures clinicians can order blood products electronically and see status/results in CPOE.
• Supports safe transfusion practice by surfacing compatibility information and preventing duplicate or inappropriate orders.

How often

• Real-time, per order/result event.

Error impact

• Inbound failure: transfusion orders may not appear in blood bank worklists; delays in blood availability.
• Outbound failure: clinicians may not see results or availability; risk of duplicate orders or unsafe transfusion decisions.
• All failures must be visible on a blood bank integration dashboard and logged for audit (UAE MOH blood safety & UAE PDPL accountability).

HL7 v2.5.1 Technical Detail

Message Types

• Inbound Orders: ORM^O01 from CPOE to Blood Bank.
• Outbound Results/Status: ORU^R01 from Blood Bank to CPOE.

Sample Inbound Transfusion Order (ORM^O01)

MSH|^~\&|CPOE|DUBAI_HOSP|BLOODBANK|DUBAI_HOSP|20260207103015||ORM^O01|BB-ORD-20260207103015|P|2.5.1|||AL|NE||UTF-8
PID|1||2026009876^^^DUBAI_HOSP^MR~784-1990-1234567-3^^^UAE^EID||AL-NAHYAN^FATIMA^ALI||19900312|F|||PO BOX 12345^^DUBAI^^00000^AE||+971501112233|||M||||||||||AE
PV1|1|I|4A^412^01^DUBAI_HOSP||||HASSAN^OMAR^K^^^DR|||MED||||||||ENC2026020710001|||||||||||||||||||||||||20260207094500
ORC|NW|TS-20260207-0001^CPOE|TS-20260207-0001^BLOODBANK||SC||^^^20260207103015^^R||20260207103015|||HASSAN^OMAR^K^^^DR^MD|||||DUBAI_HOSP^Dubai General Hospital
OBR|1|TS-20260207-0001^CPOE|TS-20260207-0001^BLOODBANK|BBTS^Type and Screen^L|||20260207103000|||||||HASSAN^OMAR^K^^^DR^MD|||||||20260207103015|||F
NTE|1||Pre-op type & screen for elective surgery tomorrow.

Key segment mapping (Type & Screen order)

Sample Inbound Transfusion Product Order (ORM^O01)

MSH|^~\&|CPOE|DUBAI_HOSP|BLOODBANK|DUBAI_HOSP|20260207103520||ORM^O01|BB-ORD-20260207103520|P|2.5.1|||AL|NE||UTF-8
PID|1||2026009876^^^DUBAI_HOSP^MR~784-1990-1234567-3^^^UAE^EID||AL-NAHYAN^FATIMA^ALI||19900312|F
PV1|1|I|4A^412^01^DUBAI_HOSP||||HASSAN^OMAR^K^^^DR|||MED||||||||ENC2026020710001
ORC|NW|TX-20260207-0005^CPOE|TX-20260207-0005^BLOODBANK||SC||^^^20260207103520^^R||20260207103520|||HASSAN^OMAR^K^^^DR^MD
OBR|1|TX-20260207-0005^CPOE|TX-20260207-0005^BLOODBANK|BBTX^Transfusion Request^L|||20260207103500|||||||HASSAN^OMAR^K^^^DR^MD
OBX|1|NM|BB-COMP^Component Type^L||RBC^Red Blood Cells^ISBT|||N|||F
OBX|2|NM|BB-UNITS^Units Requested^L||2|units|||N|||F
OBX|3|TX|BB-PRIO^Priority^L||URGENT|||N|||F
OBX|4|TX|BB-IND^Indication^L||Symptomatic anemia, Hb 6.5 g/dL|||N|||F
OBX|5|TX|BB-SREQ^Special Requirements^L||Irradiated; CMV-negative|||N|||F

Transfusion order mapping

Sample Outbound Type & Screen Result (ORU^R01)

MSH|^~\&|BLOODBANK|DUBAI_HOSP|CPOE|DUBAI_HOSP|20260207114530||ORU^R01|BB-RES-20260207114530|P|2.5.1|||AL|NE||UTF-8
PID|1||2026009876^^^DUBAI_HOSP^MR~784-1990-1234567-3^^^UAE^EID||AL-NAHYAN^FATIMA^ALI||19900312|F
PV1|1|I|4A^412^01^DUBAI_HOSP||||HASSAN^OMAR^K^^^DR|||MED||||||||ENC2026020710001
ORC|RE|TS-20260207-0001^CPOE|TS-20260207-0001^BLOODBANK||CM||||20260207114500|||BBTECH^SALEH^MOHAMMED^^^TECH
OBR|1|TS-20260207-0001^CPOE|TS-20260207-0001^BLOODBANK|BBTS^Type and Screen^L|||20260207110000|||||||BBTECH^SALEH^MOHAMMED^^^TECH|||||||20260207114500|||F
OBX|1|ST|BB-ABO^ABO Group^L||A|||N|||F
OBX|2|ST|BB-RH^Rh Type^L||POS|||N|||F
OBX|3|ST|BB-FWD^Forward Group^L||A POS|||N|||F
OBX|4|ST|BB-REV^Reverse Group^L||A POS|||N|||F
OBX|5|ST|BB-ABSCR^Antibody Screen^L||NEGATIVE|||N|||F
OBX|6|TS|BB-VALID^Result Valid Until^L||20260210000000+0400|||||F
NTE|1||Type & screen valid for 72 hours from specimen collection.

Mapping to blood_type_screen

Sample Outbound Crossmatch Result (ORU^R01)

MSH|^~\&|BLOODBANK|DUBAI_HOSP|CPOE|DUBAI_HOSP|20260207121045||ORU^R01|BB-RES-20260207121045|P|2.5.1
PID|1||2026009876^^^DUBAI_HOSP^MR~784-1990-1234567-3^^^UAE^EID||AL-NAHYAN^FATIMA^ALI||19900312|F
PV1|1|I|4A^412^01^DUBAI_HOSP||||HASSAN^OMAR^K^^^DR|||MED||||||||ENC2026020710001
ORC|RE|TX-20260207-0005^CPOE|TX-20260207-0005^BLOODBANK||CM||||20260207121000|||BBTECH^SALEH^MOHAMMED^^^TECH
OBR|1|TX-20260207-0005^CPOE|TX-20260207-0005^BLOODBANK|BBCM^Crossmatch^L|||20260207114500
OBX|1|ST|BB-CMRES^Crossmatch Result^L||COMPATIBLE|||N|||F
OBX|2|ST|BB-CMTYPE^Crossmatch Type^L||ELECTRONIC|||N|||F
OBX|3|TS|BB-CMVALID^Crossmatch Valid Until^L||20260210000000+0400|||||F
OBX|4|ST|BB-CMUNIT^Component ID^L||RBC-20260207-00123|||N|||F
OBX|5|ST|BB-CMLOC^Component Location^L||MAIN_FRIDGE_01|||N|||F

Mapping to crossmatch_records and blood_component_inventory

FHIR R4 Technical Detail

For internal APIs between Blood Bank and CPOE/EHR, FHIR may be used in addition to HL7 v2.

Resource Types

• ServiceRequest for transfusion and type & screen orders.
• Observation for type & screen and crossmatch results.
• Procedure for completed transfusions (see INT-BB-003).

Example: Transfusion ServiceRequest (CPOE → Blood Bank)

{
  "resourceType": "ServiceRequest",
  "id": "TX-20260207-0005",
  "status": "active",
  "intent": "order",
  "category": [
    {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "386216000",
          "display": "Transfusion"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "44465007",
        "display": "Transfusion of red blood cells"
      }
    ],
    "text": "RBC transfusion"
  },
  "subject": {
    "reference": "Patient/2026009876",
    "display": "Fatima Ali Al-Nahyan"
  },
  "encounter": {
    "reference": "Encounter/ENC2026020710001"
  },
  "authoredOn": "2026-02-07T10:35:20+04:00",
  "requester": {
    "reference": "Practitioner/HASSAN-OMAR",
    "display": "Dr. Omar Hassan"
  },
  "priority": "urgent",
  "reasonCode": [
    {
      "text": "Symptomatic anemia, Hb 6.5 g/dL"
    }
  ],
  "quantityQuantity": {
    "value": 2,
    "unit": "units"
  },
  "extension": [
    {
      "url": "http://gateshealth.ae/fhir/StructureDefinition/blood-component-type",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://isbt128.org/product-codes",
            "code": "E0184",
            "display": "Red Blood Cells"
          }
        ]
      }
    },
    {
      "url": "http://gateshealth.ae/fhir/StructureDefinition/blood-special-requirements",
      "valueString": "Irradiated; CMV-negative"
    }
  ]
}

Key element mappings

Search parameters (Blood Bank API)

• GET /ServiceRequest?category=transfusion&status=active
• GET /ServiceRequest?subject=Patient/2026009876&status=active
• GET /Observation?code=BB-ABO,BB-RH&subject=Patient/2026009876&_sort=-effective

Error Handling

Manual recovery

• Blood bank technologist can manually create/adjust orders in Blood Bank UI when integration fails.
• Once corrected, system can re-trigger outbound results via “Resend to CPOE” action.
• All manual interventions logged with users.user_id for UAE PDPL and MOH audit.

Retry and Recovery

Retry Strategy

• Trigger: Network timeout, HL7 ACK timeout, or FHIR 5xx error.
• Non-retryable: HL7 AE/AR, FHIR 4xx, or parsing/validation errors — route directly to DLQ for manual correction.

Circuit Breaker (for FHIR REST API calls)

Dead Letter Queue

• Storage: integration_message_log entries with status IN ('failed', 'rejected') and endpoint = 'CPOE'.
• Visibility: Blood bank integration dashboard with filter by message type (order vs result) and status.
• Retention: 30 days.
• Resolution workflow: Interface analyst or Blood Bank Supervisor reviews → corrects data or resolves connectivity → triggers "Resend to CPOE" action → status updated.
• Alerting: Immediate alert to Blood Bank Supervisor for failed inbound orders (patient safety: transfusion delays). Email + dashboard alert for failed outbound results.

Idempotency

• Inbound orders: Deduplication via placer order number (ORC-2 / ServiceRequest.id). Duplicate orders detected and acknowledged without creating new transfusion_orders records.
• Outbound results: Deduplication via filler order number (ORC-3) + result type. CPOE should treat duplicate results as updates (upsert).

Reconciliation

• Frequency: Twice daily (08:00 and 20:00).
• Process: Compare active transfusion_orders in Blood Bank against CPOE active orders for the same patients. Flag orders present in one system but not the other. Compare outbound results (type & screen, crossmatch) against CPOE received results.
• Report: Discrepancies on Blood Bank integration dashboard and in daily quality report.
• KPI: Order-to-result integration success rate target >= 99.9% (patient safety critical).

INT-BB-002: Laboratory Information System (LIS) – Donor Infectious Disease Testing

Business Context

What flows

• Outbound (Blood Bank → LIS)
• Donor specimens and test requests for mandatory infectious disease panel (HBV, HCV, HIV, syphilis, malaria, and any MOH-required tests).

• Donor demographics and donation identifiers.

• Inbound (LIS → Blood Bank)

• Infectious disease test results per donation.
• Flags for reactive/non-reactive, confirmatory results.

When

• Outbound: immediately after donation collection and component processing (WF-BB-002).
• Inbound: when LIS finalizes infectious disease results.

Why

• UAE MOH blood safety regulations require mandatory screening of all donations.
• Blood components must remain in quarantine until all tests are non-reactive.

How often

• Real-time per donation.

Error impact

• Outbound failure: LIS may not receive tests; donations remain in quarantine, causing inventory shortages.
• Inbound failure: contaminated units may not be quarantined/discarded promptly; patient safety risk and MOH non-compliance.

HL7 v2.5.1 Technical Detail

Message Type

• Inbound from LIS: ORU^R01 (lab results).
• Outbound orders to LIS may be via internal API or ORM^O01 depending on LIS capability; here we focus on inbound ORU^R01.

Sample Infectious Disease Result (ORU^R01)

MSH|^~\&|LIS|DUBAI_HOSP|BLOODBANK|DUBAI_HOSP|20260207140030||ORU^R01|BB-LAB-20260207140030|P|2.5.1|||AL|NE||UTF-8
PID|1||DNR-2025001234^^^BLOODBANK^DN||AL-MAKTOUM^AHMED^SAEED||19851210|M|||PO BOX 54321^^DUBAI^^00000^AE||+971502223344
OBR|1|LIS-ORD-78901^LIS|DON-20260207-0008^BLOODBANK|BBIDP^Donor Infectious Disease Panel^L|||20260207110000|||||||PATH^KHALID^YOUSEF^^^DR
OBX|1|CWE|HBsAg^Hepatitis B surface antigen^LN||NEGATIVE^Non-reactive^L|||N|||F|||20260207133000
OBX|2|CWE|Anti-HCV^Hepatitis C antibody^LN||NEGATIVE^Non-reactive^L|||N|||F|||20260207133200
OBX|3|CWE|HIV-AgAb^HIV Ag/Ab combo^LN||NEGATIVE^Non-reactive^L|||N|||F|||20260207133400
OBX|4|CWE|VDRL^Syphilis screening^LN||NEGATIVE^Non-reactive^L|||N|||F|||20260207133600
OBX|5|CWE|MALARIA^Malaria screening^L||NEGATIVE^Non-reactive^L|||N|||F|||20260207133800
NTE|1||All mandatory UAE MOH infectious disease markers non-reactive.

Mapping

Implementation detail:

• A child table donation_infectious_results (owned by blood-bank) will store per-test results, linked to blood_donations.donation_id.
• blood_donations.infectious_disease_status is derived:
• CLEAR if all tests non-reactive.
• REACTIVE if any test reactive.
• If REACTIVE, all related blood_components are moved to quarantine and then discarded; donor is deferred per MOH rules.

Internal API (Blood Bank → LIS)

Where LIS exposes REST APIs, Blood Bank may send orders as JSON.

Example payload (simplified)

{
  "orderId": "DON-20260207-0008",
  "donorId": "DNR-2025001234",
  "panelCode": "BBIDP",
  "tests": [
    "HBsAg",
    "Anti-HCV",
    "HIV-AgAb",
    "VDRL",
    "MALARIA"
  ],
  "collectionDateTime": "2026-02-07T11:00:00+04:00"
}

Error Handling

Manual recovery includes:

• Manual entry of results from paper/portal if LIS integration fails.
• Ability to re-ingest HL7 messages from dead-letter queue after fix.

Retry and Recovery

Retry Strategy

• Trigger: Network timeout or HL7 transport failure (outbound orders to LIS or inbound results from LIS).
• Non-retryable: HL7 AR (message reject) or parsing errors — route to DLQ for manual investigation.
• Critical safety note: Reactive results from LIS must be processed immediately. If inbound reactive result fails to process, system must alert Blood Bank Supervisor within 5 minutes for manual quarantine action.

Dead Letter Queue

• Storage: integration_message_log entries with status IN ('failed', 'rejected') and endpoint = 'LIS'. Separate sub-queues for outbound orders (dlq-bb-lis-orders) and inbound results (dlq-bb-lis-results).
• Visibility: Blood bank integration dashboard with priority highlighting for inbound result failures.
• Retention: 30 days.
• Resolution workflow: Interface analyst reviews → corrects mapping (e.g., missing donation ID in OBR-3) → triggers re-ingest from DLQ → system processes and updates donation/component status.
• Alerting: Immediate alert for inbound result failures (patient safety: components may remain in quarantine unnecessarily, or worse, reactive results not processed). Standard alert for outbound order failures.

Idempotency

• Outbound orders: Deduplication via donation_id + panel code. LIS should treat duplicate order messages as no-ops.
• Inbound results: Deduplication via OBR-3 (donation ID) + OBX-3 (test code). Duplicate results update existing donation_infectious_results records with latest values and audit trail.

Reconciliation

• Frequency: Every 4 hours (critical integration).
• Process: Compare donations with infectious_disease_status = 'PENDING' older than the expected SLA (24 hours) against LIS order status. Flag donations where LIS has not returned results. Compare LIS completed results against Blood Bank processed results to find unmatched entries.
• Report: "Donations Awaiting ID Results" dashboard with aging analysis. Escalation to LIS team for overdue results.
• KPI: Infectious disease result turnaround time target < 24 hours. Result integration success rate >= 99.9%.

INT-BB-003: EHR (Patient Chart) – Transfusion & Reaction History

Business Context

What flows

• Outbound from Blood Bank to EHR:

• Latest confirmed blood type and antibody status.

• Transfusion events (what component, when, how much, who administered).
• Transfusion reactions (type, severity, classification, MOH reporting status).

When

• After type & screen completion.
• After transfusion administration record is finalized.
• After reaction investigation is completed.

Why

• Clinicians need consolidated transfusion history and reaction alerts in the patient chart.
• Supports decision-making for future transfusions and pre-medication.

How often

• Near real-time; typically within seconds of event completion.

Error impact

• EHR may show outdated blood type or miss reaction history; risk of unsafe transfusion.
• Must be recoverable and auditable.

FHIR R4 Technical Detail

Resource Types

• Observation for blood type and antibody status.
• Procedure for transfusion events.
• Observation or Condition for transfusion reactions (depending on EHR design).

Example 1: Blood Type Observation

{
  "resourceType": "Observation",
  "id": "BB-TS-TS-20260207-0001-ABO",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "laboratory",
          "display": "Laboratory"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "883-9",
        "display": "ABO and Rh group"
      }
    ],
    "text": "ABO/Rh typing"
  },
  "subject": {
    "reference": "Patient/2026009876",
    "display": "Fatima Ali Al-Nahyan"
  },
  "effectiveDateTime": "2026-02-07T11:45:00+04:00",
  "issued": "2026-02-07T11:45:30+04:00",
  "performer": [
    {
      "reference": "Organization/DUBAI_HOSP_BB",
      "display": "Dubai General Hospital Blood Bank"
    }
  ],
  "valueString": "A positive",
  "component": [
    {
      "code": {
        "coding": [
          {
            "system": "http://loinc.org",
            "code": "11289-6",
            "display": "ABO group"
          }
        ]
      },
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://gateshealth.ae/fhir/CodeSystem/abo-group",
            "code": "A",
            "display": "Group A"
          }
        ]
      }
    },
    {
      "code": {
        "coding": [
          {
            "system": "http://loinc.org",
            "code": "11290-4",
            "display": "Rh type"
          }
        ]
      },
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://gateshealth.ae/fhir/CodeSystem/rh-type",
            "code": "POS",
            "display": "Rh positive"
          }
        ]
      }
    }
  ]
}

Mapping

Search

• GET /Observation?subject=Patient/2026009876&code=883-9&_sort=-date&_count=1 (latest blood type).

Example 2: Transfusion Procedure

{
  "resourceType": "Procedure",
  "id": "BB-ADMIN-20260207-0010",
  "status": "completed",
  "category": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "387713003",
        "display": "Surgical procedure"
      }
    ],
    "text": "Transfusion"
  },
  "code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "44465007",
        "display": "Transfusion of red blood cells"
      }
    ],
    "text": "RBC transfusion"
  },
  "subject": {
    "reference": "Patient/2026009876"
  },
  "encounter": {
    "reference": "Encounter/ENC2026020710001"
  },
  "performedPeriod": {
    "start": "2026-02-07T12:00:00+04:00",
    "end": "2026-02-07T13:15:00+04:00"
  },
  "performer": [
    {
      "actor": {
        "reference": "Practitioner/NURSE-123",
        "display": "Nurse Aisha Mohammed"
      }
    }
  ],
  "reasonCode": [
    {
      "text": "Symptomatic anemia, Hb 6.5 g/dL"
    }
  ],
  "bodySite": [
    {
      "text": "Peripheral IV"
    }
  ],
  "outcome": {
    "text": "Completed without immediate reaction"
  ],
  "extension": [
    {
      "url": "http://gateshealth.ae/fhir/StructureDefinition/blood-component-id",
      "valueString": "RBC-20260207-00123"
    },
    {
      "url": "http://gateshealth.ae/fhir/StructureDefinition/blood-volume-infused",
      "valueQuantity": {
        "value": 280,
        "unit": "mL",
        "system": "http://unitsofmeasure.org",
        "code": "mL"
      }
    }
  ]
}

Mapping

Search

• GET /Procedure?subject=Patient/2026009876&code=44465007
• GET /Procedure?encounter=Encounter/ENC2026020710001&status=completed

Example 3: Transfusion Reaction Observation

{
  "resourceType": "Observation",
  "id": "BB-REA-20260207-0003",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "procedure",
          "display": "Procedure"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://gateshealth.ae/fhir/CodeSystem/transfusion-reaction-type",
        "code": "FNHTR",
        "display": "Febrile non-hemolytic transfusion reaction"
      }
    ],
    "text": "Transfusion reaction"
  },
  "subject": {
    "reference": "Patient/2026009876"
  },
  "effectiveDateTime": "2026-02-07T12:20:00+04:00",
  "valueCodeableConcept": {
    "coding": [
      {
        "system": "http://gateshealth.ae/fhir/CodeSystem/reaction-severity",
        "code": "MOD",
        "display": "Moderate"
      }
    ]
  },
  "derivedFrom": [
    {
      "reference": "Procedure/BB-ADMIN-20260207-0010"
    }
  ],
  "note": [
    {
      "text": "Fever and chills 20 minutes after transfusion start; DAT negative; classified as FNHTR."
    }
  ]
}

Mapping

Error Handling

Manual recovery: EHR integration admin can trigger “Resend all unsynced transfusion data for patient X” via admin UI.

Retry and Recovery

Retry Strategy

• Trigger: EHR FHIR endpoint unreachable or 5xx error.
• Non-retryable: 4xx validation errors — route to DLQ for data correction (e.g., invalid FHIR resource structure).
• Per-resource tracking: Each resource type (Observation for blood type, Procedure for transfusion, Observation for reaction) is tracked independently. Failure of one does not block others.

Dead Letter Queue

• Storage: integration_message_log entries with status = 'failed' and endpoint = 'EHR_CHART', tagged by FHIR resource type.
• Visibility: Blood bank integration dashboard.
• Retention: 30 days.
• Resolution workflow: EHR integration admin reviews → fixes mapping or data → triggers “Resend all unsynced transfusion data for patient X” via admin UI → system re-pushes all pending resources for the patient.
• Alerting: Dashboard alert for reaction sync failures (patient safety: EHR must show reaction history for future transfusion decisions). Standard alert for blood type and transfusion history sync failures.

Idempotency

• Deduplication key: FHIR resource ID (admin_id for Procedure, ts_id for blood type Observation, reaction_id for reaction Observation).
• EHR-side: PUT semantics — duplicate resources with the same ID perform update rather than creating duplicates.

Reconciliation

• Frequency: Nightly at 03:00.
• Process: Compare Blood Bank's transfusion_administration (completed in last 24h), blood_type_screen (resulted in last 24h), and transfusion_reactions (classified in last 24h) against EHR FHIR server records via search queries. Flag records present in Blood Bank but missing or outdated in EHR.
• Report: Discrepancies on integration dashboard and in daily quality report.
• Bulk re-sync: Admin can trigger full re-sync for a date range or specific patient if systematic issues are detected.

INT-BB-004: Billing & Claims – Transfusion Charges

Business Context

What flows

• Outbound charge events for:

• Blood components issued/administered.

• Processing fees (leukoreduction, irradiation, washing).
• Crossmatch and type & screen fees.

When

• When a component is issued to a patient (for some sites).
• Or when transfusion administration is completed (preferred to ensure actual use).

Why

• Ensure accurate billing and eClaims submissions (eClaimLink in Dubai, DOH eClaims in Abu Dhabi).
• Support cost tracking and KPI reporting (e.g., wastage vs billed units).

How often

• Real-time per transfusion event.

Error impact

• Missed or duplicate charges; revenue leakage or patient complaints.
• Must be reconciled with transfusion records.

HL7 v2.5.1 Technical Detail

Message Type: DFT^P03 (Detailed Financial Transaction).

Sample DFT^P03 Message

MSH|^~\&|BLOODBANK|DUBAI_HOSP|BILLING|DUBAI_HOSP|20260207133045||DFT^P03|BB-DFT-20260207133045|P|2.5.1|||AL|NE||UTF-8
EVN|P03|20260207133030
PID|1||2026009876^^^DUBAI_HOSP^MR~784-1990-1234567-3^^^UAE^EID||AL-NAHYAN^FATIMA^ALI||19900312|F
PV1|1|I|4A^412^01^DUBAI_HOSP||||HASSAN^OMAR^K^^^DR|||MED||||||||ENC2026020710001
FT1|1|20260207120000|20260207131500||CG|BB-RBC-ISSUE^RBC transfusion unit^CPT|1|UNIT|450.00|AED|||BB-ADMIN-20260207-0010||HASSAN^OMAR^K^^^DR^MD|||20260207133030
FT1|2|20260207114500|20260207114500||CG|BB-CROSSMATCH^Crossmatch testing^CPT|1|EA|150.00|AED|||CM-20260207-0009||SALEH^MOHAMMED^^^TECH|||20260207133030

Mapping

Billing system will map BB-RBC-ISSUE and BB-CROSSMATCH to CPT/price based on facility configuration.

Error Handling

Manual reconciliation: periodic report comparing transfusion_administration vs billed FT1 entries.

Retry and Recovery

Retry Strategy

• Trigger: Billing system unreachable or 5xx transport error.
• Non-retryable: HL7 AR (billing rejects DFT, e.g., price mismatch, missing charge code) or patient/encounter not found — route to DLQ for correction.

Dead Letter Queue

• Storage: integration_message_log entries with status IN ('failed', 'rejected') and endpoint = 'BILLING'.
• Visibility: Blood bank integration dashboard with finance-specific filter; also visible in Billing module's integration exceptions view.
• Retention: 60 days (billing audit requirements).
• Resolution workflow: Billing Analyst reviews rejected DFT → coordinates with Blood Bank to correct charge codes, encounter linkage, or patient data → triggers manual resend → Billing processes corrected DFT.
• Alerting: Email + dashboard alert to Finance if DLQ depth > 5 or any DFT aged > 24 hours.

Idempotency

• Deduplication key: FT1-13 (transaction reference, mapped from admin_id or crossmatch_id).
• Billing-side: Enforces idempotency using transaction reference; duplicate DFTs update existing charge rather than creating new.

Reconciliation

• Frequency: Daily at 01:00.
• Process: Compare transfusion_administration records (completed in last 24h) and crossmatch_records against billed DFT entries in Billing module. Flag transfusions without corresponding charges (revenue leakage) and charges without corresponding transfusions (potential errors).
• Report: Reconciliation results in daily RCM operations report and Blood Bank financial dashboard.
• KPI: Charge capture rate for transfusions >= 99.5%.

INT-BB-005: UAE MOH Hemovigilance Reporting

Business Context

What flows

• Outbound:

• Serious transfusion reaction reports (e.g., acute hemolytic, TRALI, TACO, anaphylaxis).

• Quarterly summary statistics (reaction rates, near-miss events) as required by MOH.

When

• Immediately after a reaction is classified as serious by Blood Bank Medical Director.
• Quarterly for summary reports.

Why

• Compliance with UAE MOH hemovigilance and blood safety regulations.
• National surveillance of transfusion safety.

How often

• Event-driven for serious reactions.
• Quarterly batch for summary.

Error impact

• Non-compliance with MOH reporting timelines; potential regulatory penalties.
• Loss of surveillance data.

Technical Detail (MOH Portal / API)

Current MOH implementations are typically via secure web portal; future REST API is anticipated.

Event Report Payload (REST JSON – conceptual)

{
  "reportId": "MOH-REA-20260207-0003",
  "facilityId": "DUBAI_HOSP",
  "patientEid": "784-1990-1234567-3",
  "patientAge": 36,
  "patientSex": "F",
  "reactionDateTime": "2026-02-07T12:20:00+04:00",
  "reactionType": "FNHTR",
  "severity": "MODERATE",
  "imputability": "PROBABLE",
  "componentType": "RBC",
  "componentId": "RBC-20260207-00123",
  "indication": "Symptomatic anemia, Hb 6.5 g/dL",
  "outcome": "Recovered",
  "reportedBy": "PATH-001",
  "reportDateTime": "2026-02-07T14:00:00+04:00"
}

Mapping

Error Handling

Quarterly summary can be regenerated from transfusion_reactions and re-uploaded if needed.

Retry and Recovery

Retry Strategy

• Trigger: MOH portal/API unavailable or transport error.
• Non-retryable: Authentication failure (credential issue) — stop retries immediately; alert Security/IT for credential fix.
• Regulatory urgency: Serious reaction reports have MOH-mandated timelines. Retry strategy is aggressive (up to 24 hours) before escalation.

Dead Letter Queue

• Storage: integration_message_log entries with status = 'failed' and endpoint = 'MOH_HEMOVIGILANCE'.
• Visibility: Blood Bank compliance dashboard.
• Retention: 180 days (regulatory audit requirement).
• Resolution workflow: Compliance Officer coordinates with IT → resolves portal/API issue or credential problem → triggers re-submission → updates reported_to_moh flag on reaction record.
• Alerting: Immediate alert to Blood Bank Medical Director and Compliance Officer for any failed serious reaction report. Dashboard flag for overdue reports approaching MOH deadline.

Idempotency

• Deduplication key: reportId (e.g., MOH-REA-20260207-0003).
• MOH-side: Expected to treat duplicate report submissions with same reportId as updates rather than new reports.
• HIS-side: Track MOH acknowledgment/reference number; duplicate submissions only sent if no acknowledgment received.

Reconciliation

• Frequency: Weekly and quarterly.
• Weekly process: Compare transfusion_reactions with severity meeting MOH reporting criteria against reported_to_moh = true records. Flag any unreported serious reactions.
• Quarterly process: Generate summary statistics from transfusion_reactions and compare against quarterly MOH submission. Regenerate and re-upload if discrepancies found.
• Report: Compliance dashboard showing reporting status, pending reports, and overdue items.
• KPI: MOH serious reaction report submission rate: 100% within mandated timeline.

INT-BB-006: External Blood Bank Suppliers

Business Context

What flows

• Outbound: Blood product requests (by component type, ABO/Rh, quantity, required-by date).
• Inbound: Shipment manifests and product details (ISBT 128 codes, expiry, storage requirements).

When

• When inventory falls below configured par levels.
• On scheduled order cycles (e.g., daily for platelets).

Why

• Maintain adequate inventory (≥ 3 days on hand for all ABO/Rh groups).
• Support inter-facility transfers and supplier coordination.

How often

• Daily or on-demand.

Error impact

• Stock-outs or overstock; increased wastage; inability to meet clinical demand.

Technical Detail

Outbound – Secure File (CSV over SFTP)

Example BB_ORDER_20260207.csv:

order_id,facility_id,order_date,component_type,abo_group,rh_type,quantity,required_by,priority
ORD-EXT-20260207-001,DUBAI_HOSP,2026-02-07,RBC,A,POS,4,2026-02-08,ROUTINE
ORD-EXT-20260207-002,DUBAI_HOSP,2026-02-07,PLT,ANY,ANY,6,2026-02-07,URGENT

Inbound – Shipment Manifest (CSV)

shipment_id,facility_id,component_id,component_type,abo_group,rh_type,volume_ml,expiry_datetime,storage_location,status
SHIP-20260207-010,DUBAI_HOSP,RBC-20260207-90001,RBC,A,POS,280,2026-03-05T23:59:00+04:00,MAIN_FRIDGE_01,RECEIVED
SHIP-20260207-010,DUBAI_HOSP,PLT-20260207-90002,PLT,ANY,ANY,250,2026-02-10T23:59:00+04:00,PLT_ROOM_01,RECEIVED

Mapping

• Inbound rows create/update:

• blood_components (component_id, type, ABO/Rh, volume, expiry).

• blood_component_inventory (inventory_id, facility_id, storage_location, status = AVAILABLE, received_datetime).

Error Handling

Retry and Recovery

Retry Strategy

• Trigger: SFTP connection failure.
• Non-retryable: Malformed CSV (quarantine file for manual correction), authentication failure (alert IT for SSH key issue).

Dead Letter Queue

• Outbound (orders): Failed order files stored in local outbound/failed/ directory with timestamp and error reason. Blood Bank Supervisor alerted.
• Inbound (shipment manifests): Malformed or partially failed CSV files moved to inbound/quarantine/ directory. Error report generated listing rejected rows and reasons.
• Retention: 90 days.
• Resolution workflow: For outbound failures — IT resolves SFTP connectivity → system retransmits queued order files. For inbound failures — Blood Bank Supervisor coordinates with supplier to correct data → corrected file re-imported via admin UI.
• Alerting: Alert Blood Bank Supervisor if outbound order not confirmed within 4 hours. Alert for any inbound file with > 10% rejected rows.

Idempotency

• Outbound orders: order_id serves as natural key; supplier systems should treat duplicate order files as updates.
• Inbound shipments: component_id serves as natural key; duplicate component_id rows in manifest are ignored (logged as warning).

Reconciliation

• Frequency: Daily at 06:00 (after overnight supplier processing).
• Process: Compare outbound order requests (sent in last 48 hours) against inbound shipment manifests. Flag orders without corresponding shipments. Compare received blood_component_inventory entries against shipment manifest totals.
• Report: Supplier fulfillment report on Blood Bank dashboard. Discrepancies communicated to supplier liaison.
• KPI: Supplier order fulfillment rate and delivery timeliness.

INT-BB-HIE-1 & INT-BB-HIE-2: NABIDH / Malaffi (HIE Connectivity)

Business Context

What flows

• Outbound to HIEs:

• Key transfusion-related data to support longitudinal patient safety across facilities:

  • Confirmed ABO/Rh type.
  • Clinically significant antibodies.
  • Serious transfusion reactions.
  • Possibly transfusion events (depending on HIE profile).

When

• When type & screen is finalized.
• When a serious reaction is finalized.
• Optionally when a transfusion is completed.

Why

• Ensure that any facility connected to NABIDH (Dubai) or Malaffi (Abu Dhabi) can see critical transfusion-related safety data.
• Supports cross-facility transfusion decisions.

How often

• Real-time or near real-time.

Error impact

• Other facilities may not see updated blood type or reaction history; risk of unsafe transfusion elsewhere.

HL7 v2.5.1 Technical Detail

Message Type: ORU^R01 with NABIDH/Malaffi-specific profiles.

Sample NABIDH-style ORU^R01 for ABO/Rh

MSH|^~\&|BLOODBANK|DUBAI_HOSP|NABIDH|DHA|20260207120000||ORU^R01|BB-HIE-20260207120000|P|2.5.1|||AL|NE||UTF-8
PID|1||2026009876^^^DUBAI_HOSP^MR~784-1990-1234567-3^^^UAE^EID||AL-NAHYAN^FATIMA^ALI||19900312|F|||PO BOX 12345^^DUBAI^^00000^AE||+971501112233
PV1|1|I|4A^412^01^DUBAI_HOSP||||HASSAN^OMAR^K^^^DR|||MED||||||||ENC2026020710001
ORC|RE|TS-20260207-0001^DUBAI_HOSP|TS-20260207-0001^BLOODBANK||CM||||20260207114500|||BBTECH^SALEH^MOHAMMED^^^TECH
OBR|1|TS-20260207-0001^DUBAI_HOSP|TS-20260207-0001^BLOODBANK|883-9^ABO and Rh group^LN|||20260207110000|||||||BBTECH^SALEH^MOHAMMED^^^TECH|||||||20260207114500|||F
OBX|1|ST|11289-6^ABO group^LN||A|||N|||F|||20260207114500
OBX|2|ST|11290-4^Rh type^LN||POS|||N|||F|||20260207114500

Required fields (typical HIE profiles)

• PID-3 with Emirates ID and MRN.
• PID-5, PID-7, PID-8.
• PV1-2, PV1-3, PV1-19.
• OBR-4 with LOINC code.
• OBX-3 with LOINC; OBX-5 with result.

Malaffi uses similar structure with DOH-specific facility codes and ADHICS security requirements.

Acknowledgement handling

• Expect ACK from HIE; if AE/AR, log and route to integration team.
• Messages must be re-queued for retry if HIE is temporarily unavailable.

Error Handling

Retry and Recovery

Retry Strategy (applies to both NABIDH and Malaffi)

• Trigger: MLLP/TLS transport failure or no ACK within 30 seconds.
• Non-retryable: ACK with AE or AR (validation/mapping error) — route to DLQ for manual correction. Security errors (expired certificate) — stop all retries immediately; alert Security/IT.

Dead Letter Queue

• NABIDH: integration_message_log entries with status IN ('failed', 'rejected') and endpoint = 'NABIDH_BB'.
• Malaffi: integration_message_log entries with status IN ('failed', 'rejected') and endpoint = 'MALAFFI_BB'.
• Visibility: Integration Exceptions dashboard with separate filters for NABIDH and Malaffi blood bank messages.
• Retention: 90 days (regulatory compliance).
• Resolution workflow: Integration Admin reviews → corrects identifiers, LOINC codes, or facility mapping → triggers resend from DLQ → HIE processes corrected message.
• Alerting: Email + dashboard alert if DLQ depth > 5 or any message aged > 24 hours. Priority alert for failed reaction reports (patient safety across facilities).

Idempotency

• Deduplication key: MSH-10 (Message Control ID).
• HIE-side: NABIDH and Malaffi expected to deduplicate by MSH-10.
• HIS-side: ACK matching via MSA-2 to integration_message_log.message_control_id.

Reconciliation

• Frequency: Daily at 04:00.
• NABIDH process: Compare blood bank events (type & screen results, transfusions, reactions) for Dubai-facility patients in the last 24 hours against integration_message_log entries with endpoint = 'NABIDH_BB' and status = 'acked'. Flag unsubmitted events.
• Malaffi process: Same comparison for Abu Dhabi–facility patients against endpoint = 'MALAFFI_BB'.
• Report: HIE submission rate on Integration dashboard. Separate KPIs for NABIDH and Malaffi blood bank data submission.
• KPI: HIE transfusion data submission rate target >= 99.5%.

Authentication & Security

All integrations must comply with:

• UAE PDPL (Federal Decree-Law No. 45/2021) for personal data protection.
• DHA NABIDH and DOH Malaffi security and privacy policies.
• ADHICS (for Abu Dhabi) and TDRA/NESA cybersecurity standards.

Transport Security

• All external and cross-module communications over TLS 1.2+.
• mTLS (mutual TLS) for:
• HL7 v2 over MLLP/TLS (CPOE, LIS, Billing, HIEs).
• REST APIs where supported (EHR, MOH future APIs).

Authentication

• OAuth 2.0 (client credentials or JWT bearer) for:
• Internal REST APIs (EHR, CPOE, LIS where applicable).
• HIE connections (NABIDH, Malaffi) as per their specs.
• API Keys (rotated regularly) for some internal services (Billing).
• SFTP SSH keys for supplier file transfers.
• Portal credentials + optional client certificates for MOH hemovigilance portal.

Message Encryption & Data Protection

• No PHI in logs beyond what is necessary for troubleshooting; Emirates ID and names must be masked in production logs where possible.
• At-rest encryption for integration queues and message stores.
• Strict role-based access control:
• Only integration services and authorized admins can view raw HL7/FHIR payloads.
• All access and message flows auditable with timestamps and users.user_id where applicable.

Retry & Dead Letter Queues (General Pattern)

• Standard exponential backoff for transient errors.
• Maximum retry window configurable per integration (e.g., 30 minutes for internal, 24 hours for HIE/MOH).
• Dead-letter queues per integration (e.g., dlq-bb-cpoe, dlq-bb-lis) with:
• Reason for failure.
• Original payload.
• Manual reprocess capability.