Skip to content
Get Support
  • There are no suggestions because the search field is empty.

NABIDH Guide Part 4: Choose Which Events Are Sent to NABIDH

Every message family in the NABIDH integration has its own switch. This guide explains each trigger on the connection's Triggers tab, what turns into which HL7 message, which are on by default — and the validation rules that decide whether a message can be sent at all.

This article is part of the NABIDH guide series:

The Triggers tab

Open your NABIDH connection and go to 2. Triggers. Triggers are grouped into Clients, EMR and Appointments; each row maps one Pabau event to one NABIDH message, with a switch. Disabled rows are ignored entirely — events that happen while a trigger is off are not queued for later.

Step 1: Client Triggers

  • Add patient (ADT^A28) — sent when a client is created. On by default.
  • Update patient (ADT^A31) — sent when a client's details change. On by default.
  • Delete patient (ADT^A29) — off by default, and deliberately so: an A29 deletes the patient's demographic record at NABIDH.
  • Client merge (ADT^A40) — off by default. Tells NABIDH that two records were merged so it can combine them too.

WARNING: Only enable Delete patient and Client merge once you are confident in your data hygiene — both change or remove records on the health information exchange, not just in Pabau.

Step 2: Appointment (Visit) Triggers

  • Visit pre-admit (ADT^A05) — announces a booking to NABIDH when it is created, before the patient arrives.
  • Visit updates (A04 / A08 / A03) — the core visit flow. Pabau picks the right message from the appointment's journey: check-in sends the visit registration (ADT^A04), subsequent detail changes send updates (ADT^A08), and marking the appointment Complete sends the discharge (ADT^A03).
  • Visit cancelled after check-in (ADT^A11) — tells NABIDH to void a visit that had already been registered.

NOTE: Nothing is sent for future bookings unless you enable pre-admit — the first visit message NABIDH sees is the check-in. Pabau also keeps the visit sequence valid on your behalf: for example, completing an appointment that was never checked in sends the registration and the discharge in order, duplicate status changes are not re-sent, and cancelling a visit NABIDH never heard about sends nothing.

Step 3: EMR Triggers

  • Client problems (PPR^PC1) — when a problem/diagnosis is added or updated, the patient's whole problem list is re-sent, so NABIDH always holds the complete current list.
  • Client allergies (ADT^A31 + AL1) — likewise sends the patient's full active allergy list on every change.
  • Prescriptions (RDE^O11) — sent when a prescription is issued, one order group per drug line. Medications are matched against the Dubai Drug Code (DDC) registry. Prescriptions awaiting medical approval are held until approved.
  • Lab results (ORU^R01) — new results go out flagged as final; a re-imported/amended result is re-sent in full, flagged as corrected.
  • Documents & letters (MDM^T02) — EMR letters and PDFs, base64-encoded, up to 3 MB per document.
  • Vaccinations (VXU^V04) — visible on the tab but marked coming soon.

Step 4: Save Your Changes

Trigger switches are staged like mapping edits. Go to 4. Review — it summarises what is enabled and what will change — and press Save to publish. The Review tab is also a good sanity check that data flows one way, from Pabau to NABIDH.

What blocks a message: validation

Before anything is sent, Pabau validates the record against NABIDH's requirements. A record that fails validation is not sent at all — the delivery is marked failed in the log with a message telling you exactly what to fix (see Part 5). The rules that matter day to day:

  • Every patient message needs a first name, last name, date of birth, and at least one contact detail (mobile, phone or email).
  • Dubai residents need a valid Emirates ID (784-prefixed, 15 digits) in the bound custom field. Tourists are exempt.
  • Every visit message needs a NABIDH specialty on the booked service and an 8-digit Sheryan licence for the practitioner (own or fallback) — both set up in Part 3.
  • Documents need PDF content; lab results need at least one analyte with a value; prescriptions need at least one named drug line and must not be pending approval.

TIP: Before going live, run one test event per enabled trigger and watch it succeed in the log — Part 5: Test, monitor and troubleshoot NABIDH deliveries shows how.