Laboratory Information System Integration Specifications

Integration Summary

INT-LIS-001: CPOE (Computerized Physician Order Entry)

Business Context

What flows

• Inbound to LIS
• Lab orders: patient, encounter, ordering provider, priority, clinical indication, fasting status, requested tests (LOINC), specimen requirements, collection location.
• Order updates: cancellations, add-on tests, priority changes.
• Outbound to CPOE
• Order status: received, in progress, specimen collected, resulted, cancelled, rejected (with reason).
• Results: header + components, units, reference ranges, abnormal/critical flags, comments, performing lab.

When

• Inbound: immediately when a provider signs a lab order in CPOE.
• Outbound: when LIS changes order status or verifies results (preliminary or final).

Why

• Drive specimen collection and lab workflow from CPOE.
• Ensure ordering clinicians see real-time status and results in their ordering context.
• Support UAE regulatory expectations for traceability and timely result availability.

How often

• High-volume, real-time; each order and result event generates at least one message.

Error impact

• Inbound failure: orders may not appear in LIS; specimens cannot be processed; potential delays in diagnosis.
• Outbound failure: clinicians may not see results or status updates; risk of missed critical results (mitigated by internal alerting and critical value workflow).
• All failures must be logged and monitored; interface downtime > 5 minutes triggers incident escalation.

HL7 v2.5.1 Technical Detail

Message Types

• Inbound Orders: ORM^O01
• Outbound Results: ORU^R01
• Acknowledgements: ACK with MSA-1 = AA/AE/AR.

Sample Inbound Order (ORM^O01 – CPOE → LIS)

MSH|^~\&|CPOE|DUBAIHOSP|LIS|DUBAIHOSP|20260207101530+0400||ORM^O01|LIS20260207101530001|P|2.5.1|||AL|NE||UTF-8
PID|1||MRN123456^^^DUBAIHOSP^MR~784-1985-1234567-1^^^AE^EID||AL-MAKTOUM^AHMED^MOHAMMED||19850315|M|||PO BOX 12345^^DUBAI^^00000^AE||+971501234567|||M||||||||||AE
PV1|1|O|OPD^LABCOLL^01^DUBAIHOSP||||AL-NAHYAN^FATIMA^ALI^^^DR|||MED||||||||ENC20260207100001|||||||||||||||||||||||||20260207100000+0400
ORC|NW|ORD-LAB-20260207-0001||ACC-20260207-0001|SC||^^^20260207103000+0400^^R|STAT|20260207101530+0400|||AL-NAHYAN^FATIMA^ALI^^^DR^MD|||||DUBAIHOSP^Dubai General Hospital
OBR|1|ORD-LAB-20260207-0001|ACC-20260207-0001|24323-8^Glucose [Moles/volume] in Serum or Plasma^LN|R|20260207103000+0400|||||||20260207101530+0400|||AL-NAHYAN^FATIMA^ALI^^^DR^MD|||||||F||^^^SER^Serum|||F
NTE|1||Fasting 8 hours. Rule out diabetes mellitus.
OBR|2|ORD-LAB-20260207-0001|ACC-20260207-0002|718-7^Hemoglobin [Mass/volume] in Blood^LN|R|20260207103000+0400|||||||20260207101530+0400|||AL-NAHYAN^FATIMA^ALI^^^DR^MD|||||||F||^^^WB^Whole blood|||F

Key Segment Notes

• PID-3: MRN + Emirates ID (EID) as per UAE practice.
• PV1-3: Ordering location (e.g., OPD LAB collection room).
• ORC-1: NW new order; ORC-5 SC = in process; ORC-7 timing; ORC-9 order date/time.
• ORC-12: Ordering provider (linked to providers.provider_id).
• OBR-4: LOINC-coded test.
• OBR-18: Placer field 1 – can carry LIS section or routing info.
• OBR-27: Specimen source (e.g., SER serum, WB whole blood).

Field Mapping to LIS Tables

Sample Outbound Result (ORU^R01 – LIS → CPOE)

MSH|^~\&|LIS|DUBAIHOSP|CPOE|DUBAIHOSP|20260207113045+0400||ORU^R01|LIS20260207113045001|P|2.5.1|||AL|NE||UTF-8
PID|1||MRN123456^^^DUBAIHOSP^MR~784-1985-1234567-1^^^AE^EID||AL-MAKTOUM^AHMED^MOHAMMED||19850315|M
PV1|1|O|OPD^LABCOLL^01^DUBAIHOSP||||AL-NAHYAN^FATIMA^ALI^^^DR|||MED||||||||ENC20260207100001
ORC|CM|ORD-LAB-20260207-0001||ACC-20260207-0001|CM||^^^20260207112000+0400^^R||20260207112000+0400|||AL-NAHYAN^FATIMA^ALI^^^DR^MD
OBR|1|ORD-LAB-20260207-0001|ACC-20260207-0001|24323-8^Glucose [Moles/volume] in Serum or Plasma^LN|R|20260207103000+0400|20260207111000+0400|||||||20260207111500+0400|||LABTECH^OMAR^HASSAN^^^^^LIS|||||||F||^^^SER^Serum|||F|||20260207112000+0400
OBX|1|NM|24323-8^Glucose [Moles/volume] in Serum or Plasma^LN||8.5|mmol/L|3.9-6.1|H^High^HL70078|||F|||20260207111500+0400|LABTECH^OMAR^HASSAN
NTE|1||Patient fasting. Consider repeat test if clinically indicated.
OBR|2|ORD-LAB-20260207-0001|ACC-20260207-0002|718-7^Hemoglobin [Mass/volume] in Blood^LN|R|20260207103000+0400|20260207111200+0400|||||||20260207111800+0400|||LABTECH^OMAR^HASSAN^^^^^LIS
OBX|2|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN||13.8|g/dL|13.0-17.0|N^Normal^HL70078|||F|||20260207111800+0400|LABTECH^OMAR^HASSAN

Key Segment Notes

• ORC-1 = CM (completed).
• OBR-22 / OBR-25 / OBX-11 used to derive lab_results.result_status.
• OBX-3 LOINC code; OBX-2 data type; OBX-5 value; OBX-6 units; OBX-7 reference range; OBX-8 abnormal flag.
• Critical results will have OBX-8 with HH/LL and will link to critical notification workflow.

Field Mapping to LIS Tables

FHIR R4 Technical Detail

Resources

• Orders: ServiceRequest
• Results: DiagnosticReport + Observation (panel + components).

Sample ServiceRequest (CPOE → LIS)

{
  "resourceType": "ServiceRequest",
  "id": "ORD-LAB-20260207-0001",
  "status": "active",
  "intent": "order",
  "priority": "stat",
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "24323-8",
        "display": "Glucose [Moles/volume] in Serum or Plasma"
      }
    ],
    "text": "Serum Glucose"
  },
  "subject": {
    "reference": "Patient/MRN123456",
    "display": "Ahmed Al-Maktoum"
  },
  "encounter": {
    "reference": "Encounter/ENC20260207100001"
  },
  "authoredOn": "2026-02-07T10:15:30+04:00",
  "requester": {
    "reference": "Practitioner/AL-NAHYAN-FATIMA",
    "display": "Dr. Fatima Al-Nahyan"
  },
  "reasonCode": [
    {
      "coding": [
        {
          "system": "http://hl7.org/fhir/sid/icd-10-am",
          "code": "E11.9",
          "display": "Type 2 diabetes mellitus without complications"
        }
      ]
    }
  ],
  "specimen": [
    {
      "reference": "Specimen/ACC-20260207-0001"
    }
  ],
  "note": [
    {
      "text": "Fasting 8 hours. Rule out diabetes mellitus."
    }
  ]
}

Key Element Mapping

Sample DiagnosticReport + Observations (LIS → CPOE/EHR)

{
  "resourceType": "DiagnosticReport",
  "id": "DR-ACC-20260207-0001",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/v2-0074",
          "code": "CH",
          "display": "Chemistry"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "24323-8",
        "display": "Glucose [Moles/volume] in Serum or Plasma"
      }
    ],
    "text": "Serum Glucose"
  },
  "subject": {
    "reference": "Patient/MRN123456",
    "display": "Ahmed Al-Maktoum"
  },
  "encounter": {
    "reference": "Encounter/ENC20260207100001"
  },
  "effectiveDateTime": "2026-02-07T11:10:00+04:00",
  "issued": "2026-02-07T11:20:00+04:00",
  "performer": [
    {
      "reference": "Organization/DUBAIHOSP-LAB",
      "display": "Dubai General Hospital Laboratory"
    }
  ],
  "result": [
    {
      "reference": "Observation/OBS-GLU-ACC-20260207-0001"
    }
  ],
  "conclusion": "Fasting glucose is elevated. Consider further evaluation for diabetes mellitus."
}

{
  "resourceType": "Observation",
  "id": "OBS-GLU-ACC-20260207-0001",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "laboratory",
          "display": "Laboratory"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "24323-8",
        "display": "Glucose [Moles/volume] in Serum or Plasma"
      }
    ],
    "text": "Serum Glucose"
  },
  "subject": {
    "reference": "Patient/MRN123456"
  },
  "encounter": {
    "reference": "Encounter/ENC20260207100001"
  },
  "effectiveDateTime": "2026-02-07T11:10:00+04:00",
  "issued": "2026-02-07T11:20:00+04:00",
  "performer": [
    {
      "reference": "Organization/DUBAIHOSP-LAB"
    }
  ],
  "valueQuantity": {
    "value": 8.5,
    "unit": "mmol/L",
    "system": "http://unitsofmeasure.org",
    "code": "mmol/L"
  },
  "interpretation": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation",
          "code": "H",
          "display": "High"
        }
      ]
    }
  ],
  "referenceRange": [
    {
      "low": {
        "value": 3.9,
        "unit": "mmol/L"
      },
      "high": {
        "value": 6.1,
        "unit": "mmol/L"
      }
    }
  ],
  "specimen": {
    "reference": "Specimen/ACC-20260207-0001"
  },
  "note": [
    {
      "text": "Patient fasting. Consider repeat test if clinically indicated."
    }
  ]
}

Search Parameters (for CPOE/EHR)

• GET /DiagnosticReport?patient=Patient/MRN123456&category=laboratory
• GET /Observation?patient=Patient/MRN123456&code=24323-8&date=ge2026-02-01
• GET /DiagnosticReport?encounter=ENC20260207100001

Error Handling

• Transport/network failure
• Retry with exponential backoff: 30s, 1m, 2m, 5m, 10m (max 5 attempts).
• Queue messages in integration_message_log with status pending.

• If > 15 minutes backlog, alert integration support and Lab Supervisor.

• HL7 ACK = AE/AR

• Log full message and ACK in error store.
• No automatic retry unless error is transient (e.g., “duplicate” where idempotency is safe).

• Interface analyst corrects data and resubmits via admin UI.

• FHIR 4xx

• Parse OperationOutcome and store against message.

• Mark order/result as “interface error”; show banner in LIS worklist for manual intervention.

• FHIR 5xx

• Treat as transient; retry as per backoff; escalate if > 30 minutes.

• Manual recovery

• Admin UI to requeue failed messages by order_id / accession_number.
• Audit trail retained to satisfy UAE PDPL and DOH/DHA audit requirements.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Messages exhausting all retries written to integration_dlq table with full payload, error details, and original timestamps
• Admin dashboard for manual review, correction, and requeue by order_id or accession_number
• Retention: 30 days active, then archive per UAE PDPL and facility retention policies
• Alert: integration team notified on DLQ insertion; Lab Supervisor alerted if > 15 minutes backlog

Idempotency:

• Deduplication key: [order_id]_[message_type]_[message_control_id]
• CPOE checks MSH-10 (Message Control ID) for inbound results; duplicates return AA ACK without reprocessing
• LIS checks ServiceRequest.id for duplicate inbound orders

Reconciliation:

• Daily batch comparison: LIS lab_orders vs CPOE acknowledged orders
• Daily: LIS lab_results with result_status = 'FINAL' vs CPOE/EHR received results
• Unmatched records flagged for interface analyst / Lab Supervisor review
• Monthly trend reporting on message success rates and DLQ volumes

INT-LIS-002: Lab Analyzers / Instruments

Business Context

What flows

• Outbound: analyzer worklists (sample ID, tests, priority, rack/position).
• Inbound: test results (raw and/or processed), QC results, instrument flags (hemolysis, clot, insufficient volume).

When

• Worklist: when specimens are accessioned and assigned to an analyzer.
• Results: immediately when analyzer completes analysis.

Why

• Eliminate manual entry, reduce transcription errors, support high-throughput automation and QC.

How often

• Real-time; per specimen and per QC run.

Error impact

• Outbound failure: technologists may need to manually program analyzers.
• Inbound failure: results may not post to LIS; risk of delayed reporting.

HL7 / ASTM Technical Detail

Analyzer interfaces vary; LIS must support:

• ASTM E1381/E1394 host-query and upload.
• HL7 v2.x ORU^R01-like messages over serial/TCP.

Example HL7-like Result from Analyzer → LIS

MSH|^~\&|CHEM_ANALYZER|DUBAIHOSP_LAB|LIS|DUBAIHOSP|20260207110500+0400||ORU^R01|ANALYZER20260207110500001|P|2.5.1
PID|1||MRN123456^^^DUBAIHOSP^MR
OBR|1|ORD-LAB-20260207-0001|ACC-20260207-0001|24323-8^Glucose [Moles/volume] in Serum or Plasma^LN|||20260207105500+0400
OBX|1|NM|24323-8^Glucose [Moles/volume] in Serum or Plasma^LN||8.5|mmol/L|3.9-6.1|H|||P|||20260207110500+0400

Mapping

• OBR-3 (sample ID) → lab_specimens.accession_number.
• OBX fields map to lab_result_components as in INT-LIS-001.

Error Handling

• Instrument connection loss: LIS marks analyzer as “offline”; route tests to alternate analyzer; alert Lab Supervisor.
• Parsing errors: message stored raw; flagged for interface engineer; technologist may manually enter results.
• Retry: for TCP/serial transient failures, retry connection every 60s; no message-level retry from analyzer (typically analyzer resends or LIS polls).

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Unparseable analyzer messages stored raw in analyzer_error_queue for interface engineer review
• Technologist can manually enter results as fallback during interface downtime
• Once interface restored, duplicate detection prevents double entry

Idempotency:

• Results keyed by [accession_number]_[test_code]_[analyzer_id]_[result_datetime]
• Duplicate result transmissions from analyzer (e.g., after reconnection) are detected and merged — latest value retained
• Manual entries flagged with manual_entry = true for audit purposes

Reconciliation:

• Hourly: LIS checks for specimens loaded on analyzers (from worklist) without corresponding results after expected analysis time
• Daily: cross-reference analyzer result counts with LIS captured results to detect missed transmissions
• Interface uptime and error rates reported in integration dashboard

INT-LIS-003: EHR (Patient Chart)

Business Context

What flows

• Outbound from LIS to core EHR:
• Final and preliminary results, cumulative history, critical flags, QC status indicators.
• EHR uses this to render lab sections in patient chart and provider inbox.

When

• On result verification (preliminary or final).
• On result amendment.

Why

• Provide clinicians with a unified view of patient data.
• Support clinical decision-making and follow-up.

How often

• Real-time for each result event.

Error impact

• Results may be visible in LIS but not in EHR; clinicians may miss important findings. Critical values are mitigated by internal LIS alerting (WF-LIS-005).

FHIR R4 Technical Detail

Same DiagnosticReport + Observation pattern as in INT-LIS-001, but this integration is internal to the HIS.

Additional Elements

• DiagnosticReport.basedOn → reference to ServiceRequest (order).
• DiagnosticReport.media for attached PDFs or images (e.g., pathology).

Search Examples (EHR UI)

• GET /DiagnosticReport?patient=Patient/{id}&status=final
• GET /Observation?patient=Patient/{id}&category=laboratory&_sort=-date

Error Handling

• Internal API failures: retry 3 times (5s, 15s, 60s); if still failing, queue and alert HIS operations.
• Dead letter queue: integration_message_log with target_system = 'EHR' and status = 'failed'.
• Manual recovery: operations can replay messages by result_id or accession_number.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed messages written to integration_message_log with target_system = 'EHR' and status = 'failed'
• Operations dashboard for manual review, correction, and replay by result_id or accession_number
• Critical results (with is_critical = true) receive priority alerting — integration team notified immediately
• Retention: 30 days active

Idempotency:

• Deduplication key: DiagnosticReport.id (linked to result_id)
• EHR checks for existing DiagnosticReport with same id — updates in place rather than creating duplicates
• Corrected results use same report ID with updated status

Reconciliation:

• Daily: compare LIS lab_results with result_status = 'FINAL' against EHR received DiagnosticReport records
• Critical results verified within 1 hour of verification — any undelivered critical result triggers immediate escalation
• Monthly: reconciliation report available for Lab Supervisor and HIS operations review

INT-LIS-004: NABIDH (Dubai HIE)

Business Context

What flows

• Outbound ORU^R01 messages for finalized lab results performed in Dubai-licensed facilities, conforming to NABIDH profiles.
• LOINC-coded observations, patient identifiers (MRN + Emirates ID), facility and provider identifiers as per DHA requirements.

When

• Immediately when lab_results.result_status transitions to Final for patients whose encounter facility is under DHA jurisdiction.

Why

• Comply with DHA NABIDH mandates for data sharing.
• Enable cross-facility access to lab results in Dubai.

How often

• Real-time; high volume.

Error impact

• Non-compliance with NABIDH submission SLAs; incomplete patient record in HIE. KPI “NABIDH/Malaffi Result Submission Rate” monitors this.

HL7 v2.5.1 Technical Detail (NABIDH Profile)

Message Type: ORU^R01 (NABIDH-constrained)

MSH|^~\&|LIS|DUBAIHOSP|NABIDH|DHA|20260207114500+0400||ORU^R01|NABIDH20260207114500001|P|2.5.1|||AL|NE||UTF-8
PID|1||MRN123456^^^DUBAIHOSP^MR~784-1985-1234567-1^^^AE^EID||AL-MAKTOUM^AHMED^MOHAMMED||19850315|M|||PO BOX 12345^^DUBAI^^00000^AE||+971501234567
PV1|1|O|OPD^LAB^01^DUBAIHOSP||||AL-NAHYAN^FATIMA^ALI^^^DR|||MED||||||||ENC20260207100001
ORC|RE|ORD-LAB-20260207-0001||ACC-20260207-0001|CM||^^^20260207112000+0400^^R||20260207112000+0400|||AL-NAHYAN^FATIMA^ALI^^^DR^MD
OBR|1|ORD-LAB-20260207-0001|ACC-20260207-0001|24323-8^Glucose [Moles/volume] in Serum or Plasma^LN|R|20260207103000+0400|20260207111000+0400|||||||20260207111500+0400|||DUBAIHOSP^Dubai General Hospital Laboratory||||||F||^^^SER^Serum|||F|||20260207112000+0400
OBX|1|NM|24323-8^Glucose [Moles/volume] in Serum or Plasma^LN||8.5|mmol/L|3.9-6.1|H^High^HL70078|||F|||20260207111500+0400|DUBAIHOSP^Dubai General Hospital Laboratory

NABIDH-specific Requirements (high level)

• PID must include Emirates ID where available.
• Use LOINC for OBX-3; local codes may be sent as additional components.
• Facility and provider identifiers must match DHA-registered codes.
• MSH-3/4 and MSH-5/6 values as per NABIDH registration.
• TLS + mTLS over MLLP; message-level ACKs required.

Field Mapping

Same as LIS internal mapping, plus:

• PID-3 EID → HIE patient matching.
• PV1-3 → facility/department codes aligned with NABIDH master data.

Acknowledgement Handling

• Expect ACK from NABIDH with MSA-1 = AA/AE/AR.
• Store hie_submission_status and hie_ack_code in integration_message_log.
• If AE/AR, capture ERR segment and expose in monitoring dashboard.

Error Handling

• Transport failure: retry with exponential backoff (1m, 5m, 15m, 30m, 60m).
• If > 24 hours unsent, escalate to HIS and compliance teams.
• Messages are never dropped; they remain in queue until successfully acknowledged or manually cancelled with justification (for PDPL compliance).

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Messages exhausting all retries written to integration_dlq with target_system = 'NABIDH'
• Messages are never dropped — remain in queue until acknowledged or manually cancelled with justification (for PDPL compliance)
• Admin dashboard for manual review, payload correction, and requeue
• Alert: integration team notified on DLQ insertion; compliance team alerted if > 24 hours unsent

Idempotency:

• Deduplication key: [result_id]_[ORU^R01]_[message_control_id]
• NABIDH checks MSH-10 (Message Control ID); duplicate submissions return AA without reprocessing
• Corrected results use new MSH-10 with updated OBR-25 status

Reconciliation:

• Daily: compare lab_results with result_status = 'FINAL' (Dubai facilities) against integration_message_log where target_system = 'NABIDH' and status = 'accepted'
• Unmatched records flagged for integration team; shown on NABIDH submission compliance dashboard
• Monthly: trend reporting on NABIDH submission success rate for KPI "NABIDH/Malaffi Result Submission Rate"

INT-LIS-005: Malaffi (Abu Dhabi HIE)

Business Context

Similar to NABIDH but for Abu Dhabi (DOH) facilities and Malaffi HIE.

What flows

• Final lab results (ORU^R01) with DOH-compliant coding and identifiers.

When

• On final result for encounters at Abu Dhabi facilities.

Why

• DOH mandates participation in Malaffi; ADHICS requires secure, auditable data exchange.

HL7 v2.5.1 Technical Detail (Malaffi Profile)

MSH|^~\&|LIS|ABUDHABIHOSP|MALAFFI|DOH|20260207120000+0400||ORU^R01|MALAFFI20260207120000001|P|2.5.1|||AL|NE||UTF-8
PID|1||MRN987654^^^ABUDHABIHOSP^MR~784-1990-7654321-3^^^AE^EID||AL-NAHAYAN^KHALID^SAEED||19900310|M|||PO BOX 54321^^ABU DHABI^^00000^AE||+971509876543
PV1|1|I|WARD3^301^02^ABUDHABIHOSP||||HASSAN^OMAR^ALI^^^DR|||MED||||||||ENC20260206140001
ORC|RE|ORD-LAB-20260206-0100||ACC-20260206-0500|CM||^^^20260206170000+0400^^R||20260206170000+0400|||HASSAN^OMAR^ALI^^^DR^MD
OBR|1|ORD-LAB-20260206-0100|ACC-20260206-0500|718-7^Hemoglobin [Mass/volume] in Blood^LN|R|20260206160000+0400|20260206164500+0400|||||||20260206165000+0400|||ABUDHABIHOSP^Abu Dhabi General Hospital Laboratory
OBX|1|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN||11.0|g/dL|13.0-17.0|L^Low^HL70078|||F|||20260206165000+0400|ABUDHABIHOSP^Abu Dhabi General Hospital Laboratory

Malaffi-specific Notes

• DOH facility and provider codes must be used.
• ADHICS requires detailed audit logging of all outbound messages.
• Similar ACK/error handling as NABIDH.

Error Handling

• Same retry/backoff as NABIDH.
• Additional ADHICS requirement: log all failures with timestamp, user (system account), and remediation steps.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Messages exhausting all retries written to integration_dlq with target_system = 'MALAFFI'
• Same never-drop policy as NABIDH — messages remain in queue until acknowledged or cancelled with justification
• ADHICS-compliant audit trail: all failures logged with timestamp, system account, and remediation steps
• Alert: integration team notified on DLQ insertion; compliance team alerted if > 24 hours unsent

Idempotency:

• Deduplication key: [result_id]_[ORU^R01]_[message_control_id]
• Malaffi checks MSH-10 (Message Control ID); duplicate submissions return AA without reprocessing
• Corrected results use new MSH-10 with updated OBR-25 status

Reconciliation:

• Daily: compare lab_results with result_status = 'FINAL' (Abu Dhabi facilities) against integration_message_log where target_system = 'MALAFFI' and status = 'accepted'
• ADHICS audit trail maintained for all reconciliation activities
• Monthly: trend reporting on Malaffi submission success rate for KPI "NABIDH/Malaffi Result Submission Rate"

INT-LIS-006: Billing & Claims

Business Context

What flows

• Outbound charge events for completed and verified tests:
• Test code (LOINC), billing code (CPT), specimen type, performing facility, priority (for possible differential tariffs), send-out vs in-house.

When

• When lab_results.result_status becomes Final and test is billable.

Why

• Ensure accurate and timely charge capture for RCM.
• Support eClaimLink (DHA) and DOH eClaims via downstream billing module.

How often

• Real-time per test; may be aggregated downstream.

Error impact

• Underbilling or delayed billing; revenue leakage.

HL7 v2.5.1 Technical Detail – DFT^P03

MSH|^~\&|LIS|DUBAIHOSP|BILLING|DUBAIHOSP|20260207120500+0400||DFT^P03|BILL20260207120500001|P|2.5.1|||AL|NE||UTF-8
EVN|P03|20260207120500+0400
PID|1||MRN123456^^^DUBAIHOSP^MR~784-1985-1234567-1^^^AE^EID||AL-MAKTOUM^AHMED^MOHAMMED||19850315|M
PV1|1|O|OPD^LAB^01^DUBAIHOSP||||AL-NAHYAN^FATIMA^ALI^^^DR|||MED||||||||ENC20260207100001
FT1|1|20260207112000+0400|20260207112000+0400||CG|80048^Basic metabolic panel^CPT||1|EA|||ACC-20260207-0001|DUBAIHOSP^Dubai General Hospital Laboratory|||24323-8^Glucose [Moles/volume] in Serum or Plasma^LN~718-7^Hemoglobin [Mass/volume] in Blood^LN

Field Mapping

Error Handling

• If billing system unavailable:
• Queue DFT messages; retry 1m, 5m, 15m, 60m.
• If > 24 hours, alert RCM team.
• Duplicate detection: billing system uses FT1-13 (accession) + FT1-7 (CPT) for idempotency.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed DFT messages written to integration_dlq with target_system = 'BILLING'
• "Pending Billing" flag shown on test in LIS worklist until resolved
• Admin dashboard for billing analyst review, correction, and requeue
• Alert: RCM team notified if > 24 hours unsent or DLQ count exceeds threshold

Idempotency:

• Deduplication key: [accession_number]_[CPT_code]_[FT1_transaction_id]
• Billing system uses FT1-13 (accession) + FT1-7 (CPT) combination — duplicates are rejected without double-charging
• Re-sent messages after correction use new MSH-10 with same accession reference

Reconciliation:

• Daily: compare lab_results with result_status = 'FINAL' and billable flag against billing system charge records
• Unmatched records (unbilled tests) flagged for revenue integrity review
• Monthly: charge capture rate reported as KPI; trend analysis on billing DLQ volumes

INT-LIS-007: PIS (Pharmacy – Antimicrobial Stewardship)

Business Context

What flows

• Outbound from LIS:
• Microbiology culture and sensitivity results (organism, MIC, S/I/R).
• Aggregated antibiogram data (periodic).
• Inbound from PIS:
• Active antimicrobial orders for the patient (drug, dose, start date).

When

• Culture result finalized; interim results may also be sent.
• Antibiogram updates (e.g., monthly/quarterly).
• PIS updates antimicrobial orders (new/changed/stopped).

Why

• Support antimicrobial stewardship: correlate microbiology results with current therapy; suggest de-escalation/escalation.

How often

• Real-time for patient-level data; scheduled for antibiogram.

Error impact

• Stewardship rules may not see latest culture or therapy; potential inappropriate antibiotic use.

Internal API / FHIR R4 Technical Detail

Outbound Microbiology Observation (LIS → PIS)

{
  "resourceType": "Observation",
  "id": "MIC-ACC-20260205-0100-AMC",
  "status": "final",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/observation-category",
          "code": "laboratory"
        }
      ]
    }
  ],
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "18906-8",
        "display": "Antibiotic susceptibility"
      }
    ],
    "text": "Antibiotic susceptibility"
  },
  "subject": {
    "reference": "Patient/MRN555555",
    "display": "Fatima Al-Nahyan"
  },
  "encounter": {
    "reference": "Encounter/ENC20260205103001"
  },
  "specimen": {
    "reference": "Specimen/ACC-20260205-0100"
  },
  "effectiveDateTime": "2026-02-06T09:30:00+04:00",
  "valueCodeableConcept": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "112283007",
        "display": "Escherichia coli"
      }
    ],
    "text": "Escherichia coli"
  },
  "component": [
    {
      "code": {
        "coding": [
          {
            "system": "http://hl7.org/fhir/sid/atc",
            "code": "J01CA04",
            "display": "Amoxicillin and enzyme inhibitor"
          }
        ],
        "text": "Amoxicillin-clavulanate"
      },
      "valueQuantity": {
        "value": 8,
        "unit": "µg/mL"
      },
      "interpretation": [
        {
          "coding": [
            {
              "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation",
              "code": "R",
              "display": "Resistant"
            }
          ]
        }
      ]
    }
  ]
}

Inbound Active Antimicrobial Orders (PIS → LIS)

Simple internal JSON structure:

{
  "patientId": "MRN555555",
  "encounterId": "ENC20260205103001",
  "antimicrobialOrders": [
    {
      "orderId": "RX-20260205-0100",
      "drugCode": "J01DD04",
      "drugName": "Ceftriaxone",
      "startDateTime": "2026-02-05T11:00:00+04:00",
      "dose": "2 g",
      "route": "IV",
      "frequency": "q24h",
      "status": "active"
    }
  ]
}

Mapping to LIS

• Micro data → lab_micro_cultures and lab_micro_sensitivities.
• Antimicrobial orders stored in stewardship cache for correlation; not persisted as LIS master data.

Error Handling

• If PIS unavailable: LIS continues to send; PIS retries consumption; stewardship UI may show “current antimicrobial data unavailable”.
• If LIS → PIS fails: retry 1m, 5m, 15m; alert stewardship pharmacist if > 1 hour delay.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed culture/sensitivity messages written to integration_dlq with target_system = 'PIS_STEWARDSHIP'
• Stewardship UI displays “current antimicrobial data unavailable” banner when PIS data is stale
• Alert: stewardship pharmacist notified if > 1 hour delay in culture data delivery

Idempotency:

• Culture results keyed by [culture_id]_[organism_code]_[result_datetime]
• PIS checks for existing culture results before processing; updates in place for revised sensitivity data
• Antibiogram aggregates are full-replacement (not incremental) — each update replaces prior dataset

Reconciliation:

• Daily: verify that all finalized microbiology results with active antimicrobial orders have been delivered to PIS
• Weekly: compare LIS antibiogram generation dates against PIS received dates
• Monthly: stewardship pharmacist reviews integration health metrics

INT-LIS-008: Reference Laboratories

Business Context

What flows

• Outbound:
• Send-out orders, electronic requisitions, specimen manifests (patient, tests, specimen details, payer).
• Inbound:
• Results from reference labs (HL7, PDF, or proprietary formats).

When

• Outbound: when a test is marked as send-out and specimen is shipped.
• Inbound: when reference lab publishes results (batch or real-time).

Why

• Support esoteric tests not performed in-house.
• Track send-out TAT and compliance.

How often

• Batch daily for manifests; real-time where supported.

Error impact

• Lost or delayed send-outs; missing results; billing discrepancies.

HL7 v2.x / File Transfer Technical Detail

Outbound ORM^O01 (LIS → Reference Lab)

MSH|^~\&|LIS|DUBAIHOSP|REFLAB1|REFLAB1|20260207123000+0400||ORM^O01|REFLAB20260207123000001|P|2.5.1
PID|1||MRN123456^^^DUBAIHOSP^MR~784-1985-1234567-1^^^AE^EID||AL-MAKTOUM^AHMED^MOHAMMED||19850315|M|||PO BOX 12345^^DUBAI^^00000^AE||+971501234567
PV1|1|O|OPD^LAB^01^DUBAIHOSP||||AL-NAHYAN^FATIMA^ALI^^^DR
ORC|NW|ORD-SO-20260207-0005||SO-ACC-20260207-0005|SC||^^^20260207130000+0400^^R||20260207123000+0400|||AL-NAHYAN^FATIMA^ALI^^^DR
OBR|1|ORD-SO-20260207-0005|SO-ACC-20260207-0005|50015-7^Vitamin D [Mass/volume] in Serum or Plasma^LN|R|20260207123000+0400|||||||20260207123000+0400|||DUBAIHOSP^Dubai General Hospital Laboratory|||||||P||^^^SER^Serum

Inbound ORU^R01 (Reference Lab → LIS)

Similar to INT-LIS-001 ORU mapping; results mapped into lab_results and lab_result_components, with lab_sendout_orders.status updated to result_received.

Error Handling

• SFTP failures: retry 5m, 15m, 60m; if > 24 hours, alert Lab Supervisor and reference lab contact.
• HL7 parsing errors: quarantine file; manual review; results may be entered manually if needed.
• KPI “Send-Out TAT Compliance” uses lab_sendout_orders timestamps.

Retry and Recovery

Retry Strategy:

Dead Letter Queue:

• Failed outbound manifests/orders stored in integration_dlq with target_system = 'REFLAB_[lab_name]'
• Unparseable inbound result files quarantined in secure directory for interface engineer review
• Lab Supervisor alerted if outbound failures > 24 hours
• Manual result entry available as fallback for urgent tests

Idempotency:

• Outbound orders keyed by [sendout_id]_[order_test_id] — duplicate manifest submissions detected by reference lab
• Inbound results keyed by [accession_number]_[test_code]_[reference_lab_id] — duplicate result imports are detected and merged
• Manual entries flagged with source = MANUAL_REFLAB for audit trail

Reconciliation:

• Daily: compare lab_sendout_orders with status = 'IN_TRANSIT' against expected TAT; flag overdue send-outs
• Weekly: cross-reference shipped specimens against received results; follow up on missing results with reference lab
• Monthly: send-out TAT compliance reported as KPI; reconciliation of billing charges for send-out tests

Authentication & Security

Across all LIS integrations, the following security controls apply, aligned with UAE PDPL, DOH/DHA, and TDRA/NESA expectations:

Transport Security

• All external integrations (NABIDH, Malaffi, reference labs over internet) use TLS 1.2+.
• Internal HIS services use mTLS between services (CPOE, EHR, Billing, PIS, LIS).
• HL7 over MLLP is tunneled through TLS where supported by HIEs and partners.

Authentication & Authorization

• mTLS certificates
• Facility-level certificates issued by approved UAE CAs for NABIDH/Malaffi.
• Service certificates for internal APIs (LIS, CPOE, EHR, Billing, PIS).
• OAuth 2.0
• Client credentials flow for server-to-server FHIR APIs (CPOE ↔ LIS, LIS ↔ EHR, LIS ↔ PIS).
• Scopes such as lab.order.write, lab.result.read, hie.submit.
• API keys
• Only for legacy or third-party reference labs where OAuth/mTLS not available; stored encrypted and rotated regularly.

Message Encryption & Data Protection

• Data in transit: TLS; no plaintext PHI on unencrypted channels.
• Data at rest: integration logs and message payloads stored in encrypted databases or file systems.
• Emirates ID and other identifiers masked in non-production logs.

Audit & Logging

• All integration calls logged with:
• Timestamp, source, target, message type, patient/encounter identifiers (hashed where required), status, error codes.
• Logs retained per UAE regulatory and facility policy; accessible for DOH/DHA/MOH audits.

Error Monitoring & Alerts

• Central integration engine dashboard:
• Monitors queue depth, error rates, ACK failures, and HIE submission KPIs.
• Alert thresholds:
• Any HIE outage > 30 minutes.
• NABIDH/Malaffi submission success rate < 99.5% over 24h.
• LIS–CPOE or LIS–EHR outage > 5 minutes.

This specification provides the developer-ready integration details for the LIS module, consistent with UAE regulatory and interoperability requirements.