Pharmacy Information System Integration Specifications

Integration Summary

INT-PIS-001: CPOE

Business Context

What flows

• Inbound to PIS (from CPOE)
• Medication orders: drug (RxNorm), dose, route, frequency, duration, indication, priority (STAT/routine), PRN details
• Patient context: patient_id, encounter_id, demographics, allergies, weight, renal/hepatic function summary

• Ordering provider: provider_id, specialty, DEA-equivalent authority flags for controlled substances (per MOH rules)

• Outbound from PIS (to CPOE)

• Order status updates: verified, rejected, modified, on-hold
• Pharmacist interventions: type, recommendation, prescriber response
• Dispensing status: first-dose dispensed, partial fill, backordered

When

• Inbound: immediately when a provider signs a medication order in CPOE.
• Outbound: when pharmacist verifies/rejects/modifies an order, and when dispensing events occur.

Why

• Enables pharmacist clinical verification before dispensing.
• Keeps prescribers informed of pharmacy actions and interventions.
• Supports closed-loop medication management and auditability (DOH/DHA, UAE PDPL).

How often

• High volume, real-time; every medication order and status change.

Error impact

• Inbound failure: orders not visible to pharmacy; risk of delayed therapy.
• Outbound failure: CPOE shows stale status; prescribers may duplicate orders or miss critical interventions.
• All failures must be visible in an integration dashboard and logged for ADHICS/NESA audit.

HL7 v2.5.1 Technical Detail

Message Types

• Inbound to PIS: RDE^O11 (Pharmacy/Treatment Encoded Order) – preferred for medication orders.
• Outbound to CPOE: RDE^O11 with updated ORC/RXE status, or RDE^O11 + NTE for interventions.

Sample Inbound Order Message (CPOE → PIS)

MSH|^~\&|HIS_CPOE|DUBAIHOSP|PIS|DUBAIHOSP|20260207103015+0400||RDE^O11|PIS20260207103015001|P|2.5.1|||AL|NE||UTF-8
PID|1||2026009876^^^DUBAIHOSP^MR~784-1985-1234567-1^^^AE^EID||AL-MAKTOUM^AHMED^HASSAN||19850315|M|||PO BOX 12345^^DUBAI^^00000^AE||+971501234567|||M||||||||||AE
PV1|1|I|4B^412^01^DUBAIHOSP||||KHAN^SARA^A^^^DR|||MED||||||||ENC2026020700456|||||||||||||||||||||||||20260207090000+0400
AL1|1|DA|70618^Penicillin^RXNORM|SV|Anaphylaxis|20230515
AL1|2|DA|763875^Sulfonamide^RXNORM|MO|Rash|20210110
ORC|NW|ORD-20260207-000123^HIS_CPOE|ORD-20260207-000123^PIS||SC|||^^^20260207110000+0400^^R|20260207103015+0400|||KHAN^SARA^A^^^DR^MD^^^^^PRC|+971504445555^WP^PH^^^+971^504445555|PO BOX 56789^^DUBAI^^00000^AE||PHARM^Inpatient Pharmacy^DUBAIHOSP
RXE|1|10|mg^milligram^UCUM|314076^Lisinopril 10 MG Oral Tablet^RXNORM|PO^Oral^HL70162|QD^Once daily^HL70335|||90|TAB^Tablet^UCUM|20260207103015+0400|||R|N|||I10^Essential hypertension^ICD10AM|||||||
RXR|PO^Oral^HL70162
OBX|1|NM|29463-7^Body weight^LN||78|kg^kilogram^UCUM|60-100|N|||F|||20260207080000+0400
OBX|2|NM|2160-0^Creatinine^LN||1.3|mg/dL^milligram/deciliter^UCUM|0.7-1.3|N|||F|||20260207080000+0400
NTE|1||Take once daily in the morning. Monitor blood pressure.

Key Segment Notes

• PID-3: MRN + Emirates ID (EID) – required for UAE HIE alignment.
• PV1-19: ENC2026020700456 maps to encounters.encounter_id.
• ORC-1: NW (new order); later updates use XO (change) or CA (cancel).
• ORC-2: CPOE order ID; primary key for idempotency.
• RXE: Encoded order – dose, units, route, frequency, quantity, indication.
• OBX: Optional clinical context (weight, creatinine) to support dose checking.

Sample Outbound Status/Intervention Message (PIS → CPOE)

MSH|^~\&|PIS|DUBAIHOSP|HIS_CPOE|DUBAIHOSP|20260207104030+0400||RDE^O11|PIS20260207104030002|P|2.5.1|||AL|NE||UTF-8
PID|1||2026009876^^^DUBAIHOSP^MR~784-1985-1234567-1^^^AE^EID
PV1|1|I|4B^412^01^DUBAIHOSP||||KHAN^SARA^A^^^DR|||MED||||||||ENC2026020700456
ORC|OK|ORD-20260207-000123^HIS_CPOE|ORD-20260207-000123^PIS||CM|||^^^20260207110000+0400^^R|20260207104000+0400|||ALI^FATIMA^OMAR^^^PHARM^RPh||||PHARM^Inpatient Pharmacy^DUBAIHOSP
RXE|1|10|mg^milligram^UCUM|314076^Lisinopril 10 MG Oral Tablet^RXNORM|PO^Oral^HL70162|QD^Once daily^HL70335|||90|TAB^Tablet^UCUM|20260207104000+0400|||R|N|||I10^Essential hypertension^ICD10AM
NTE|1||Pharmacist intervention: Confirmed indication and renal function. Dose appropriate. No changes required.

Field Mapping to PIS Tables (Inbound)

Field Mapping to PIS Tables (Outbound)

FHIR R4 Technical Detail

Resources

• Inbound: MedicationRequest (CPOE → PIS).
• Outbound:
• MedicationRequest (status updates)
• MedicationDispense (dispensing status)
• DetectedIssue (CDS alerts / pharmacist interventions, optional).

Sample Inbound MedicationRequest (CPOE → PIS)

{
  "resourceType": "MedicationRequest",
  "id": "ORD-20260207-000123",
  "status": "active",
  "intent": "order",
  "priority": "routine",
  "medicationCodeableConcept": {
    "coding": [
      {
        "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
        "code": "314076",
        "display": "Lisinopril 10 MG Oral Tablet"
      }
    ],
    "text": "Lisinopril 10mg Tablet"
  },
  "subject": {
    "reference": "Patient/2026009876",
    "display": "Ahmed Hassan Al-Maktoum"
  },
  "encounter": {
    "reference": "Encounter/ENC2026020700456"
  },
  "authoredOn": "2026-02-07T10:30:15+04:00",
  "requester": {
    "reference": "Practitioner/KHAN-SARA",
    "display": "Dr. Sara Khan"
  },
  "reasonCode": [
    {
      "coding": [
        {
          "system": "http://hl7.org/fhir/sid/icd-10-am",
          "code": "I10",
          "display": "Essential hypertension"
        }
      ]
    }
  ],
  "dosageInstruction": [
    {
      "text": "Take 10mg by mouth once daily in the morning",
      "timing": {
        "repeat": {
          "frequency": 1,
          "period": 1,
          "periodUnit": "d"
        },
        "code": {
          "coding": [
            {
              "system": "http://terminology.hl7.org/CodeSystem/v3-GTSAbbreviation",
              "code": "QD",
              "display": "Once daily"
            }
          ]
        }
      },
      "route": {
        "coding": [
          {
            "system": "http://snomed.info/sct",
            "code": "26643006",
            "display": "Oral route"
          }
        ]
      },
      "doseAndRate": [
        {
          "doseQuantity": {
            "value": 10,
            "unit": "mg",
            "system": "http://unitsofmeasure.org",
            "code": "mg"
          }
        }
      ]
    }
  ],
  "dispenseRequest": {
    "quantity": {
      "value": 90,
      "unit": "tablet"
    },
    "expectedSupplyDuration": {
      "value": 90,
      "unit": "days",
      "system": "http://unitsofmeasure.org",
      "code": "d"
    }
  },
  "note": [
    {
      "text": "Take once daily in the morning. Monitor blood pressure."
    }
  ]
}

Key Element Mapping

Sample Outbound MedicationDispense (PIS → CPOE)

{
  "resourceType": "MedicationDispense",
  "id": "DISP-20260207-000789",
  "status": "completed",
  "medicationCodeableConcept": {
    "coding": [
      {
        "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
        "code": "314076",
        "display": "Lisinopril 10 MG Oral Tablet"
      }
    ]
  },
  "subject": {
    "reference": "Patient/2026009876"
  },
  "context": {
    "reference": "Encounter/ENC2026020700456"
  },
  "authorizingPrescription": [
    {
      "reference": "MedicationRequest/ORD-20260207-000123"
    }
  ],
  "quantity": {
    "value": 90,
    "unit": "tablet"
  },
  "whenHandedOver": "2026-02-07T11:05:00+04:00",
  "performer": [
    {
      "actor": {
        "reference": "Practitioner/ALI-FATIMA",
        "display": "Fatima Omar Ali, RPh"
      }
    }
  ]
}

Search Parameters (PIS as FHIR server for CPOE)

• GET /MedicationRequest?patient={id}&status=active – active orders for a patient.
• GET /MedicationDispense?authorizingPrescription={order-id} – dispensing history for an order.
• GET /DetectedIssue?implicated=MedicationRequest/{id} – pharmacist interventions for an order.

Error Handling (INT-PIS-001)

Manual recovery: integration admin can requeue failed messages from integration_message_log by ID; all replays must be audit-logged (user, timestamp, reason) for ADHICS compliance.

Retry and Recovery

Retry Strategy

Dead Letter Queue

Failed messages are written to the integration_dlq table:

DLQ review cadence: every 4 hours during pharmacy operating hours; critical items (STAT orders, interventions) reviewed within 30 minutes.

Idempotency

• Inbound (CPOE to PIS): Deduplication key = ORC-2 (placer order number) + ORC-1 (order control) + MSH-10 (message control ID). If a message with the same ORC-2 and matching payload hash already exists in pharmacy_orders, the duplicate is logged and discarded.
• Outbound (PIS to CPOE): Deduplication key = [dispensing_id]_[message_type]_[event_datetime]. CPOE must ignore duplicate status updates with the same composite key.

Reconciliation

• Hourly: Automated count comparison — orders received in CPOE (ORC-1 = NW) vs. orders present in pharmacy_orders for the same hour window.
• Daily: Full reconciliation report comparing CPOE order IDs with PIS verification/dispensing status; unmatched orders flagged for investigation.
• Post-outage: PIS requests a FHIR MedicationRequest?_lastUpdated=gt[outage_start] query to CPOE to retrieve any orders missed during downtime.

INT-PIS-002: EHR (Patient Chart)

Business Context

What flows

• Active and historical medication list (orders + dispenses).
• eMAR records (actual administrations, holds, refusals, PRN responses).
• Pharmacy notes/interventions relevant to the patient chart.

When

• On each dispense, administration, reconciliation, or order status change.
• On-demand when EHR requests latest medication timeline.

Why

• Provides clinicians a consolidated view of medications in the EHR.
• Supports clinical decision-making and continuity of care.
• Required for NABIDH/Malaffi-aligned longitudinal medication history.

How often

• Real-time event push + on-demand queries.

Error impact

• If updates fail, EHR medication list may be stale; risk of duplicate therapy or missed doses.
• Must be clearly indicated in EHR UI if medication data is not current.

Technical Detail (Internal API + FHIR)

No HL7 v2 here; internal REST/FHIR.

Primary Resources

• MedicationRequest – order-level view.
• MedicationDispense – dispensing events.
• MedicationAdministration – eMAR.
• MedicationStatement – reconciled/home meds.
• Annotation – pharmacy notes (embedded).

Sample MedicationAdministration (PIS → EHR)

{
  "resourceType": "MedicationAdministration",
  "id": "ADMIN-20260207-001234",
  "status": "completed",
  "medicationCodeableConcept": {
    "coding": [
      {
        "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
        "code": "314076",
        "display": "Lisinopril 10 MG Oral Tablet"
      }
    ]
  },
  "subject": {
    "reference": "Patient/2026009876",
    "display": "Ahmed Hassan Al-Maktoum"
  },
  "context": {
    "reference": "Encounter/ENC2026020700456"
  },
  "effectiveDateTime": "2026-02-07T09:00:00+04:00",
  "performer": [
    {
      "actor": {
        "reference": "Practitioner/NURSE-001",
        "display": "Nurse Aisha Al-Nahyan"
      }
    }
  ],
  "dosage": {
    "route": {
      "coding": [
        {
          "system": "http://snomed.info/sct",
          "code": "26643006",
          "display": "Oral route"
        }
      ]
    },
    "dose": {
      "value": 10,
      "unit": "mg",
      "system": "http://unitsofmeasure.org",
      "code": "mg"
    }
  },
  "request": {
    "reference": "MedicationRequest/ORD-20260207-000123"
  },
  "note": [
    {
      "text": "Barcode verified; patient tolerated well."
    }
  ]
}

Mapping to PIS Tables

Search Parameters (EHR → PIS)

• GET /MedicationAdministration?patient={id}&date=ge2026-02-01
• GET /MedicationRequest?patient={id}&status=active
• GET /MedicationStatement?patient={id} – reconciled/home meds.

Error Handling (INT-PIS-002)

• Internal API calls are synchronous; if PIS is unavailable, EHR shows an inline error and may retry after 5–10 seconds.
• Event pushes (webhooks or message bus) use the same retry/backoff pattern as INT-PIS-001.
• Dead-letter queue for events that fail >5 times; visible in integration console.
• Manual reconciliation: EHR can request a full medication sync for a patient (/MedicationAdministration?patient=...&_since=...) after outages.

Retry and Recovery

Retry Strategy

Dead Letter Queue

Failed event pushes are written to integration_dlq:

DLQ review cadence: every 4 hours; critical medication administration events reviewed within 1 hour.

Idempotency

• Event push deduplication key = [resource_type]_[resource_id]_[lastUpdated]. EHR discards events where the resource version is older than or equal to the currently stored version.
• Synchronous queries are inherently idempotent (read-only GET requests).

Reconciliation

• Post-outage: EHR triggers a full medication sync per patient using GET /MedicationAdministration?patient={id}&_since={outage_start} and GET /MedicationDispense?patient={id}&_since={outage_start}.
• Daily: Automated comparison of pharmacy_dispensing records vs. EHR MedicationDispense resources for the past 24 hours; discrepancies flagged in integration dashboard.

INT-PIS-003: LIS (Antimicrobial Stewardship)

Business Context

What flows

• Inbound from LIS: culture and sensitivity results, organism, MIC, susceptibility (S/I/R).
• Outbound from PIS: antimicrobial orders, stewardship review linkage, recommendations.

When

• Inbound: when LIS finalizes culture/sensitivity results.
• Outbound: when antimicrobial orders are placed or stewardship reviews are recorded.

Why

• Supports antimicrobial stewardship pharmacists in optimizing therapy, reducing resistance, and meeting facility and MOH quality expectations.

How often

• Real-time; moderate volume.

Error impact

• Missing culture data → delayed de-escalation, prolonged broad-spectrum use.
• Missing outbound stewardship data → incomplete audit trail and metrics.

Technical Detail (Internal API)

Typical pattern: JSON over HTTPS between PIS and LIS/stewardship engine.

Example Inbound Culture Result (LIS → PIS)

{
  "cultureResultId": "CULT-20260207-00045",
  "patientId": "2026009876",
  "encounterId": "ENC2026020700456",
  "specimen": "Blood",
  "collectionDateTime": "2026-02-06T22:15:00+04:00",
  "organisms": [
    {
      "code": "112283007",
      "system": "http://snomed.info/sct",
      "display": "Escherichia coli",
      "susceptibilities": [
        {
          "antibioticRxNorm": "197361",
          "antibioticName": "Ceftriaxone",
          "mic": "0.5",
          "interpretation": "S"
        },
        {
          "antibioticRxNorm": "36567",
          "antibioticName": "Ciprofloxacin",
          "mic": "4",
          "interpretation": "R"
        }
      ]
    }
  ],
  "status": "final"
}

Mapping

• cultureResultId → antimicrobial_stewardship_reviews.culture_result_id
• patientId → antimicrobial_stewardship_reviews.patient_id
• Organism/susceptibility stored in a LIS-owned schema or a shared stewardship schema (not in PIS core tables).

Example Outbound Stewardship Review (PIS → LIS / Analytics)

{
  "reviewId": "AST-20260207-00012",
  "orderId": "ORD-20260207-000555",
  "patientId": "2026009876",
  "antibioticRxNorm": "197361",
  "reviewType": "de-escalation",
  "indication": "Urosepsis",
  "cultureResultId": "CULT-20260207-00045",
  "recommendation": "De-escalate from meropenem to ceftriaxone based on susceptibility.",
  "accepted": true,
  "reviewedBy": "PHARM-AST-001",
  "reviewedDateTime": "2026-02-07T11:30:00+04:00",
  "prescriberResponse": "Accepted; order changed to ceftriaxone."
}

Maps directly to antimicrobial_stewardship_reviews table.

Error Handling (INT-PIS-003)

• If LIS push fails, LIS queues and retries; PIS logs inbound failures.
• If PIS push of stewardship review fails, messages are queued with backoff; stewardship dashboard shows “pending export” status.
• No data loss allowed; all culture IDs and review IDs must be idempotent.

Retry and Recovery

Retry Strategy

Dead Letter Queue

DLQ review cadence: every 2 hours (culture results are clinically time-sensitive for antimicrobial stewardship decisions).

Idempotency

• Inbound culture results: Deduplication key = [diagnostic_report_id]_[result_status]_[last_updated]. Duplicate results with same report ID and version are discarded; updated results (amended/final) replace prior preliminary data.
• Outbound stewardship reviews: Deduplication key = [stewardship_review_id]_[review_status]. LIS ignores duplicate notifications for the same review at the same status.

Reconciliation

• Every 6 hours: PIS queries LIS for finalized culture reports for patients with active antimicrobial orders (GET /DiagnosticReport?category=microbiology&status=final&date=gt{6h_ago}); any missing reports are flagged.
• Daily: Cross-reference antimicrobial_stewardship_reviews with LIS culture result log to ensure all positive cultures with active antimicrobial orders have been reviewed.

INT-PIS-004: Billing & Claims

Business Context

What flows

• Chargeable dispensing events with: patient, encounter, payer, drug (RxNorm + NDC if available), quantity, unit cost, total cost, charge code (CPT/HCPCS or internal), and flags for controlled substances.

When

• Each time a medication is dispensed (inpatient or outpatient).

Why

• Enables accurate pharmacy revenue capture and integration with eClaimLink (DHA) / DOH eClaims via the billing module.
• Supports cost analytics and stock valuation.

How often

• Real-time; high volume.

Error impact

• Failed charges → revenue leakage, manual reconciliation.
• Duplicate charges → claim rejections, patient complaints.

HL7 v2.5.1 Technical Detail

Message Type: DFT^P03 (Detailed Financial Transaction)

Sample DFT^P03 (PIS → Billing)

MSH|^~\&|PIS|DUBAIHOSP|BILLING|DUBAIHOSP|20260207111530+0400||DFT^P03|DFT20260207111530001|P|2.5.1|||AL|NE||UTF-8
EVN|P03|20260207111530+0400
PID|1||2026009876^^^DUBAIHOSP^MR~784-1985-1234567-1^^^AE^EID||AL-MAKTOUM^AHMED^HASSAN||19850315|M
PV1|1|I|4B^412^01^DUBAIHOSP||||KHAN^SARA^A^^^DR|||MED||||||||ENC2026020700456
FT1|1|20260207111000+0400|20260207111000+0400|CG|RX^Pharmacy charge^C4|DISP-20260207-000321|314076^Lisinopril 10 MG Oral Tablet^RXNORM|2|TAB^Tablet^UCUM|5.00|10.00|AED^UAE Dirham^ISO4217|||PHARM-TECH-001^HASSAN^OMAR^^^TECH|PHARM^Inpatient Pharmacy^DUBAIHOSP|||NDC12345678
ZPH|DISP-20260207-000321|ORD-20260207-000123|10.00|5.00|unit_cost

Key Segment Notes

• FT1-6: Transaction type CG (charge).
• FT1-7: Transaction ID = pharmacy_dispensing.dispensing_id.
• FT1-8: RxNorm-coded drug.
• FT1-9: Quantity dispensed.
• FT1-11/FT1-12: Unit price and total amount.
• FT1-13: Currency (AED).
• Custom ZPH segment carries additional pharmacy-specific data (order_id, unit_cost).

Mapping

Error Handling (INT-PIS-004)

• If billing system is down, DFT messages are queued; no user-facing error in pharmacy UI.
• Duplicate detection by FT1-7 (dispensing_id) on billing side.
• Reconciliation report compares pharmacy_dispensing vs. accepted charges daily.

Retry and Recovery

Retry Strategy

Dead Letter Queue

DLQ review cadence: every 4 hours during business hours. Revenue integrity team reviews daily for completeness.

Idempotency

• Deduplication key = FT1-7 (dispensing_id). Billing system rejects duplicate charges with the same dispensing_id; returns AE with duplicate indicator.
• Credit/reversal messages use FT1-6 = CR with the original FT1-7 to reverse prior charges.

Reconciliation

• Daily: Automated reconciliation report compares pharmacy_dispensing (all records with status = DISPENSED for the day) against accepted charges in billing. Unmatched dispensing records are flagged for resubmission.
• Monthly: Revenue integrity review compares total drug cost from pharmacy_dispensing against total pharmacy charges posted in billing for the month; variance > 1% triggers investigation.
• Post-outage: PIS replays all queued DFT messages in chronological order; billing system deduplicates using FT1-7.

INT-PIS-005: NABIDH (Dubai HIE)

Business Context

What flows

• Outbound reporting of medication dispensing events and current medication list for Dubai-licensed facilities, per NABIDH pharmacy profile.

When

• Each time a medication is dispensed for a patient whose encounter is in a NABIDH-participating Dubai facility.

Why

• Supports cross-facility medication reconciliation and safety.
• Required by DHA NABIDH policies for connected providers.

How often

• Near real-time; messages buffered and sent within minutes.

Error impact

• Failed submissions reduce HIE completeness; KPI “NABIDH/Malaffi Dispensing Submission Rate” must remain ≥ 99.5%.
• Facility must be able to demonstrate retry and error management to DHA.

HL7 v2.5.1 Technical Detail (NABIDH Profile)

Message Type: Typically RDE^O11 or RDS^O13-like profile for dispenses; exact profile per NABIDH spec. Here we model as RDE^O11 with dispense context.

Sample Message (PIS → NABIDH)

MSH|^~\&|PIS|DUBAIHOSP|NABIDH|DHA|20260207113000+0400||RDE^O11|NABIDH20260207113000001|P|2.5.1|||AL|NE||UTF-8
PID|1||2026009876^^^DUBAIHOSP^MR~784-1985-1234567-1^^^AE^EID||AL-MAKTOUM^AHMED^HASSAN||19850315|M|||PO BOX 12345^^DUBAI^^00000^AE||+971501234567
PV1|1|O|OPD^PHARM^01^DUBAIHOSP||||KHAN^SARA^A^^^DR|||OPD||||||||ENC2026020700789
ORC|RE|ORD-20260207-000789^HIS_CPOE|ORD-20260207-000789^PIS||CM|||^^^20260207112500+0400^^R|20260207112500+0400|||ALI^FATIMA^OMAR^^^PHARM^RPh
RXE|1|500|mg^milligram^UCUM|202531^Amoxicillin 500 MG Oral Capsule^RXNORM|PO^Oral^HL70162|TID^Three times daily^HL70335|||21|CAP^Capsule^UCUM|20260207112500+0400|||A|N|||J02.9^Acute pharyngitis^ICD10AM
RXD|1|20260207112500+0400|202531^Amoxicillin 500 MG Oral Capsule^RXNORM|21|CAP^Capsule^UCUM||ALI^FATIMA^OMAR^^^PHARM^RPh||LOT12345|20270201|DUBAIHOSP^Main Pharmacy^DUBAIHOSP

NABIDH Requirements (Conceptual)

• Emirates ID in PID-3 or PID-18 as per NABIDH profile.
• Facility and provider identifiers aligned with DHA master codes.
• Use RxNorm for medications; ICD-10-AM for indications.
• TLS 1.2+ with DHA-issued mTLS certificates.
• HL7 ACK handling: PIS must process ACK and update integration_message_log.hie_submission_status.

Mapping

• Same as internal RDE, plus:
• RXD segment fields map to pharmacy_dispensing (lot, expiry, location).
• integration_message_log tracks message_control_id, hie_submission_status, hie_submission_datetime.

Error Handling (INT-PIS-005)

• If NABIDH connection fails, messages remain in an outbound queue with status pending_hie.
• Retry schedule: every 5 minutes for 1 hour, then hourly for 24 hours.
• After 24 hours, mark as failed_hie and alert IT + compliance.
• Negative ACKs (AE/AR) logged with reason; no auto-retry unless error is transient (e.g., AR due to temporary validation service outage).
• KPI “NABIDH/Malaffi Dispensing Submission Rate” computed from integration_message_log.

Retry and Recovery

Retry Strategy

Dead Letter Queue

DLQ review cadence: every 2 hours. Compliance team notified if any messages remain in DLQ > 24 hours (regulatory SLA risk).

Idempotency

• Deduplication key = [dispensing_id]_[message_type]_[event_datetime]. NABIDH gateway processes each unique dispensing event once; duplicate submissions return an ACK with duplicate indicator.
• Resubmissions after correction use a new MSH-10 (message control ID) but retain the original dispensing_id for NABIDH to match and update.

Reconciliation

• Daily: Compare pharmacy_dispensing records for the day against integration_message_log entries with target_system = NABIDH and status = acknowledged. Any dispensing records without a corresponding acknowledged NABIDH submission are requeued.
• Weekly: NABIDH submission rate KPI reviewed by compliance team; target > 99% within 24 hours.
• Post-outage: Bulk resubmission of all pending_hie and failed_hie messages in chronological order with rate limiting to avoid overwhelming NABIDH gateway.

INT-PIS-006: Malaffi (Abu Dhabi HIE)

Business Context

Similar to NABIDH but for DOH Abu Dhabi’s Malaffi HIE, with DOH-specific profiles and facility/provider codes.

What flows

• Medication dispensing events and medication list for Abu Dhabi encounters.

When

• On each dispense in an Abu Dhabi DOH-licensed facility.

Why

• DOH Malaffi participation requirement; supports cross-facility care.

How often

• Near real-time.

Error impact

• Same as NABIDH; monitored jointly via the shared KPI.

HL7 v2.5.1 Technical Detail (Malaffi Profile)

Message Type: RDE^O11 or Malaffi-specific pharmacy profile.

Sample Message (PIS → Malaffi)

MSH|^~\&|PIS|ABUDHABIHOSP|MALAFFI|DOH|20260207114500+0400||RDE^O11|MALAFFI20260207114500001|P|2.5.1|||AL|NE||UTF-8
PID|1||2026012345^^^ABUDHABIHOSP^MR~784-1990-7654321-3^^^AE^EID||AL-NAHYAN^FATIMA^MOHAMMED||19900320|F|||PO BOX 67890^^ABU DHABI^^00000^AE||+971502223344
PV1|1|O|OPD^PHARM^01^ABUDHABIHOSP||||OMAR^KHALID^Y^^^DR|||OPD||||||||ENC2026020700999
ORC|RE|ORD-20260207-001234^HIS_CPOE|ORD-20260207-001234^PIS||CM|||^^^20260207114000+0400^^R|20260207114000+0400|||ALI^FATIMA^OMAR^^^PHARM^RPh
RXE|1|20|mg^milligram^UCUM|617314^Omeprazole 20 MG Delayed Release Capsule^RXNORM|PO^Oral^HL70162|QD^Once daily^HL70335|||30|CAP^Capsule^UCUM|20260207114000+0400|||A|N|||K21.9^Gastro-oesophageal reflux disease^ICD10AM
RXD|1|20260207114000+0400|617314^Omeprazole 20 MG Delayed Release Capsule^RXNORM|30|CAP^Capsule^UCUM||TECH-002^YOUSEF^ALI^^^TECH||LOT67890|20280131|ABUDHABIHOSP^Main Pharmacy^ABUDHABIHOSP

Malaffi Requirements (Conceptual)

• DOH facility and provider codes in MSH-4, PV1-7.
• ADHICS-compliant logging and encryption.
• mTLS with DOH-issued certificates; IP whitelisting.

Error handling mirrors NABIDH.

Retry and Recovery

Retry Strategy

Mirrors INT-PIS-005 (NABIDH) with Malaffi-specific parameters:

Dead Letter Queue

DLQ review cadence: every 2 hours. Compliance team notified if messages remain in DLQ > 24 hours. All DLQ operations logged per ADHICS requirements.

Idempotency

• Deduplication key = [dispensing_id]_[message_type]_[event_datetime]. Malaffi gateway deduplicates on the same basis as NABIDH.
• DOH facility code and provider code in MSH-4 and PV1-7 must match registered values; mismatches cause AR rejection (not retryable without correction).

Reconciliation

• Daily: Compare pharmacy_dispensing records against integration_message_log entries with target_system = MALAFFI and status = acknowledged. Requeue any unsubmitted records.
• Weekly: Malaffi submission rate KPI reviewed by compliance team; target > 99% within 24 hours.
• Post-outage: Bulk resubmission with rate limiting; all replay operations ADHICS-logged (user, timestamp, reason, message count).

INT-PIS-007: UAE MOH (Controlled Substances)

Business Context

What flows

• Monthly batch reports of all controlled substance transactions (dispense, return, waste, adjustment) with chain-of-custody.
• Event-driven discrepancy reports (loss, suspected diversion).

When

• Monthly, on a configured schedule (e.g., 3rd of month for prior month).
• Immediately when a discrepancy is finalized in controlled_substance_log.

Why

• Compliance with UAE MOH controlled substance regulations (Federal Law No. 14 of 1995 and amendments).
• Supports audits and investigations.

How often

• Monthly batch + low-volume event-driven.

Error impact

• Failed submissions may put facility at regulatory risk; must be detected and corrected before MOH deadlines.

Technical Detail (File-Based / Portal)

Batch File Content (CSV Example)

Each row corresponds to a controlled substance transaction.

log_id,facility_code,drug_rxnorm,drug_name,controlled_schedule,transaction_type,quantity,balance_after,from_user,to_user,witness_id,patient_mrn,patient_eid,waste_amount,location,transaction_datetime,discrepancy_flag,discrepancy_reason
CS-202602-000001,DH-DUBAIHOSP,865098,Tramadol 50 MG Oral Capsule,III,DISPENSE,10,90,PHARM-VAULT,NURSE-001,NURSE-002,2026009876,784-1985-1234567-1,0,4B-412,2026-02-01T10:15:00+04:00,N,
CS-202602-000250,DH-DUBAIHOSP,865098,Tramadol 50 MG Oral Capsule,III,WASTE,2,88,NURSE-001,PHARM-VAULT,NURSE-003,2026009876,784-1985-1234567-1,2,4B-412,2026-02-05T09:00:00+04:00,N,
CS-202602-000400,DH-DUBAIHOSP,865098,Tramadol 50 MG Oral Capsule,III,ADJUSTMENT,-5,83,PHARM-VAULT,,SUP-001,,,0,VAULT-01,2026-02-10T18:30:00+04:00,Y,Stock count discrepancy

Mapping

Files are transferred via SFTP over VPN to MOH or uploaded via MOH portal; exact format will follow MOH specification.

Error Handling (INT-PIS-007)

• Batch generation failures logged and alerted to pharmacy supervisor and compliance.
• SFTP transfer failures retried every 30 minutes until success or until MOH deadline minus 24 hours, then escalated.
• Portal upload failures require manual retry; system logs export file hash and timestamp for audit.
• Discrepancy events that fail to send are queued and retried every 10 minutes; if still failing after 2 hours, on-call pharmacist notified.

Retry and Recovery

Retry Strategy

Dead Letter Queue

DLQ review cadence: immediately for discrepancy events; daily for batch reports. Compliance team notified of any unresolved items.

Idempotency

• Monthly batch reports: Each report is identified by [report_period]_[facility_id]_[generation_datetime]. Resubmission of the same report period replaces the prior submission at the MOH level.
• Discrepancy events: Deduplication key = [discrepancy_id]_[event_type]_[event_datetime]. MOH system accepts updates to existing discrepancy IDs.
• File hash (SHA-256) is computed before transmission and stored in integration_message_log; retransmitted files must match the original hash.

Reconciliation

• Monthly: After successful batch transmission, PIS compares the count of controlled substance transactions in controlled_substance_log for the reporting period against the row count in the transmitted CSV/XML file. Any mismatch triggers a re-generation and resubmission.
• Post-failure: If SFTP fails and manual portal upload is used, pharmacist uploads the system-generated file (same hash) and logs the manual submission with timestamp and confirmation number in integration_message_log.
• Annual audit: Full year reconciliation of controlled_substance_log against MOH-acknowledged submissions; discrepancies documented and resolved before regulatory review.

INT-PIS-008: Patient Portal

Business Context

What flows

• Patient-facing medication list (current and recent).
• Refill status and eligibility for outpatient prescriptions.
• Patient-friendly instructions (English/Arabic).

When

• On-demand when patient opens medication section in portal.
• Event-driven updates when a new dispense occurs or refill becomes available.

Why

• Supports patient engagement, adherence, and PDPL-compliant access to personal data.
• Reduces calls to pharmacy for routine queries.

How often

• On-demand + low-volume event push.

Error impact

• If unavailable, portal should clearly indicate that medication data is temporarily unavailable; no clinical risk but impacts patient experience.

FHIR R4 Technical Detail

Portal acts as FHIR client; PIS (or EHR) exposes FHIR server.

Resources

• MedicationRequest – prescriptions.
• MedicationDispense – fills and refills.
• MedicationStatement – reconciled/home meds.

Sample MedicationRequest for Portal

{
  "resourceType": "MedicationRequest",
  "id": "RX-20260207-000999",
  "status": "active",
  "intent": "order",
  "category": [
    {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/medicationrequest-category",
          "code": "outpatient"
        }
      ]
    }
  ],
  "medicationCodeableConcept": {
    "coding": [
      {
        "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
        "code": "617314",
        "display": "Omeprazole 20 MG Delayed Release Capsule"
      }
    ],
    "text": "Omeprazole 20mg Capsule"
  },
  "subject": {
    "reference": "Patient/2026012345",
    "display": "Fatima Mohammed Al-Nahyan"
  },
  "authoredOn": "2026-02-07",
  "dosageInstruction": [
    {
      "text": "Take one capsule by mouth once daily before breakfast",
      "patientInstruction": "تناول كبسولة واحدة عن طريق الفم مرة يومياً قبل الإفطار"
    }
  ],
  "dispenseRequest": {
    "numberOfRepeatsAllowed": 2,
    "quantity": {
      "value": 30,
      "unit": "capsule"
    },
    "expectedSupplyDuration": {
      "value": 30,
      "unit": "days",
      "system": "http://unitsofmeasure.org",
      "code": "d"
    }
  }
}

Sample MedicationDispense (Refill Status)

{
  "resourceType": "MedicationDispense",
  "id": "DISP-20260207-001000",
  "status": "completed",
  "medicationCodeableConcept": {
    "coding": [
      {
        "system": "http://www.nlm.nih.gov/research/umls/rxnorm",
        "code": "617314",
        "display": "Omeprazole 20 MG Delayed Release Capsule"
      }
    ]
  },
  "subject": {
    "reference": "Patient/2026012345"
  },
  "authorizingPrescription": [
    {
      "reference": "MedicationRequest/RX-20260207-000999"
    }
  ],
  "quantity": {
    "value": 30,
    "unit": "capsule"
  },
  "whenHandedOver": "2026-02-07T12:00:00+04:00"
}

Search Parameters (Portal → PIS/EHR)

• GET /MedicationRequest?patient={id}&status=active
• GET /MedicationDispense?patient={id}&_sort=-whenHandedOver
• GET /MedicationStatement?patient={id}

Error Handling (INT-PIS-008)

• Portal uses OAuth 2.0; if token invalid, returns 401/403; no PHI leakage.
• If FHIR server unavailable, portal shows “Medication data temporarily unavailable” and logs error.
• No retries on user-initiated GET; user can refresh manually.
• Event push failures (if used) follow the standard backoff/queue pattern.

Retry and Recovery

Retry Strategy

Circuit Breaker (FHIR Server Availability)

Dead Letter Queue (Event Push Only)

DLQ review cadence: daily. Non-critical notifications; patients retrieve full data on next portal login regardless.

Idempotency

• Patient GET requests are inherently idempotent (read-only FHIR queries).
• Event push notifications: Deduplication key = [patient_id]_[event_type]_[event_datetime]. Portal discards duplicate notifications.
• Portal caches the last-known medication list per patient; cache invalidated on new dispensing event or after 15-minute TTL.

Reconciliation

• No formal reconciliation required for on-demand pull model — patient always receives current data from PIS on each portal query.
• For event push notifications: weekly review of DLQ to clear stale notifications older than 7 days (events are informational; data is always available on-demand).

Authentication & Security

Across all PIS integrations:

• mTLS Certificates
• Used for all HL7 v2.5.1 over MLLP/TLS (CPOE, NABIDH, Malaffi, Billing).
• Certificates issued by internal CA for intra-hospital; DHA/DOH CAs for HIE endpoints.

• Certificate rotation and revocation managed per TDRA/NESA and ADHICS guidelines.

• OAuth 2.0

• Authorization Code flow for patient portal access to FHIR APIs.
• Client Credentials flow for system-to-system FHIR calls (CPOE ↔ PIS, EHR ↔ PIS).

• Scopes limited to least privilege (e.g., medications.read, medications.write).

• API Keys / Internal Tokens

• For internal REST integrations where OAuth overhead is not required; keys stored in secure vault, rotated regularly.

• Encryption

• In transit: TLS 1.2+ for all HTTP(S) and SFTP; MLLP wrapped in TLS.

• At rest: database and message logs encrypted per facility policy and UAE PDPL requirements.

• Audit & Logging

• All integration calls logged with timestamp, user/system identity, patient_id, and outcome.
• Logs retained per MOH/DOH/DHA and PDPL retention policies.

• Access to logs restricted and monitored.

• Data Minimization & PDPL

• Only necessary fields included in external integrations (NABIDH, Malaffi, MOH).
• Patient identifiers limited to MRN + Emirates ID where required by regulation.
• Cross-border transfers (if any) require explicit PDPL-compliant assessment and approvals.

This specification provides the developer-ready integration details for the Pharmacy Information System within the UAE regulatory context.