NABIDH Guide Part 6: NABIDH Error Codes and Delivery Statuses

When a NABIDH delivery does not succeed, Pabau tells you three things: what stage it failed at, which field caused it, and what to do about it. This article is the full reference for all three — written so a practice manager can find the fix, and so a technical reader can map every code back to the DHA specification.

This article is part of the NABIDH guide series:

Part 1: What is NABIDH and how Pabau connects to it
Part 2: Connect Pabau to NABIDH
Part 3: Map your data for NABIDH
Part 4: Choose which events are sent to NABIDH
Part 5: Test, monitor and troubleshoot NABIDH deliveries
Part 6: NABIDH error codes and delivery statuses (you are here)
Part 7: NABIDH code tables reference

Where errors come from

A NABIDH message passes three checkpoints. Knowing which one stopped it tells you who can fix it.

Checkpoint	What it does	Who fixes a failure
1. Pabau pre-flight check	Before anything is sent, Pabau audits the message against its own transcription of the NABIDH specification and records every finding on the attempt.	Usually you — it is almost always missing or malformed data on a Pabau record.
2. Transport	The message is sent over HTTPS to your NABIDH endpoint.	Usually nobody — network and server errors retry automatically.
3. NABIDH’s answer	NABIDH replies with an acknowledgement (ACK) saying whether it accepted the message.	Depends on the reason — the ACK names the segment and field.

NOTE: A delivery can pass the pre-flight check and still be rejected by NABIDH, because NABIDH enforces some rules Pabau cannot see (for example whether a Sheryan provider ID is genuinely registered to your facility). Always read NABIDH’s own response on the delivery, not just the pre-flight findings.

Delivery statuses

Every row in the Logs tab carries one of six statuses.

Status	What it means	What to do
Pending	Queued and waiting for a worker to pick it up.	Nothing — it will move on its own.
Processing	A worker is building and sending the message right now.	Nothing — refresh in a moment.
Succeeded	NABIDH accepted the message.	Nothing.
Retry scheduled	The attempt failed with something worth retrying. The next attempt time is shown on the row.	Usually nothing. If the cause is bad data, fix the record so the retry succeeds.
Failed permanent	The attempt failed with something a retry cannot fix (for example invalid data).	Fix the underlying record or setting, then use Sync latest or Retry.
Dead letter	All 8 attempts were used up.	Fix the cause, then press Retry on the delivery — dead-lettered deliveries stay replayable.

Error classes

Every failed delivery is also tagged with an error class, shown as a coloured badge. The class decides whether Pabau retries on its own.

Badge	Internal code	What it means	Retries automatically?	What to do
Authentication	`auth`	The destination rejected the stored credentials. Reconnect or update them, then retry.	No	Re-enter the credentials in the connection Settings.
Configuration	`config`	The connection configuration is incomplete or invalid. Fix it in Settings, then retry.	No	Check the EMR code, Sheryan facility ID and environment in Settings.
Validation	`validation`	The record is missing or has invalid data required by the destination. Fix the record, then use Sync latest.	No	Fix the record in Pabau. The delivery drawer names the exact field — see the reference below.
Mapping	`mapping`	A field mapping is invalid. Correct the mapping, then use Sync latest.	No	Re-check the binding on the Mapping tab.
Rejected	`remote_4xx`	The destination rejected the request. Inspect the response body for the reason.	No	Open the delivery and read NABIDH’s response.
Destination error	`remote_5xx`	The destination returned a server error. Retries back off automatically.	Yes	Nothing — NABIDH is having trouble. Escalate only if it persists past the retry window.
Network	`network`	The destination could not be reached. Retries back off automatically.	Yes	Nothing, unless every delivery is failing — then check the endpoint URL.
Rate limited	`rate_limit`	The destination is throttling requests. Retries back off automatically.	Yes	Nothing — the backoff handles it.
Not implemented	`not_implemented`	This connector’s delivery engine has not shipped yet.	No	Nothing — the message family is not live yet.

The retry ladder

Retryable failures back off exponentially, starting at 30 seconds and doubling each time. A delivery gets 8 attempts in total, spread over roughly one hour.

After failed attempt #	Next attempt is scheduled in
1	30 seconds
2	1 minute
3	2 minutes
4	4 minutes
5	8 minutes
6	16 minutes
7	32 minutes
8	No further retry — the delivery is dead-lettered.

NOTE: Retries are capped at 6 hours apart, but with 8 attempts that cap is never reached in practice — the longest real gap is 32 minutes. A dead-lettered delivery is not lost: fix the cause and press Retry to replay it.

Reading a NABIDH acknowledgement

A production NABIDH endpoint answers with an HL7 acknowledgement message. The important part is the MSA segment.

Code	Name	Meaning
`AA`	Application Accept	NABIDH accepted and stored the message. This is the success case.
`AE`	Application Error	NABIDH understood the message but something in it was wrong — usually an invalid or missing field.
`AR`	Application Reject	NABIDH refused the message outright — typically a header, facility or structural problem rather than one bad field.

When the answer is AE or AR, two more fields carry the detail:

ERR-5 — the application error code. 5001 is NABIDH’s generic validation error.
ERR-7 — a human-readable diagnostic naming what went wrong.

The MSA-2 field echoes the message control ID that Pabau sent, which is how a reply is matched back to its delivery.

Reading a DHA test-utility response

The DHA HL7 test utility used during onboarding does not reply with an HL7 acknowledgement. It returns a plain sentence:

Validation : Success — the message passed.

Validation : PID:16 Marital Id Invalid against NAB002/CodeSystem should be NAB002~PID:30 Pat.DeathInd. Invalid~ — the message was rejected, and each reason is separated by a tilde (~).

Each reason follows the same shape:

Part	Example	Meaning
Segment and field	`PID:16`	The 16th field of the PID (patient identification) segment. Note the utility uses a colon where the specification uses a hyphen (`PID-16`).
Problem	`Marital Id Invalid`	What is wrong with it.
Expected code table	`against NAB002`	The list of values NABIDH will accept. Part 7 of this series lists every table in full.

TIP: Fix the required field named in the first error before chasing the rest. NABIDH often reports follow-on errors for neighbouring fields when one required field is empty, and those disappear on their own once the first is corrected.

Field-by-field reference: what you can fix

These are the findings caused by data in your Pabau account. Each one names the exact place to correct it. The Spec reference column is the section of the NABIDH Inbound HL7 v2.5.1 specification the rule comes from — useful when you are talking to DHA.

Client card — identity and demographics

Open the client, then Edit client.

Field	How to fix it	Spec reference
`PID-5.1`	Fill in the client's last name on the client card — NABIDH rejects patients without a family name.	§4.4 PID-5
`PID-5.2`	Fill in the client's first name on the client card.	§4.4 PID-5
`PID-7`	Set the client's date of birth on the client card — NABIDH allows a missing DOB only for emergency encounters.	§4.4 PID-7
`PID-8`	Set the client's gender on the client card (male/female map to M/F; anything else sends U).	§4.4 PID-8
`PID-11`	Fill in the client's address on the client card — NABIDH substitutes a Dubai default when absent, so this is a data-quality warning.	§4.4 PID-11
`PID-11.4`	Set the client's emirate/state — NABIDH expects a NAB047 emirate name (Dubai, Abu Dhabi, …).	§6 NAB047
`PID-11.6`	The country must resolve to a numeric NAB039 code — check the client's country field is a recognised country name.	§6 NAB039
`PID-13`	Add a phone number for the client — or, if one exists, this indicates the encoder failed to classify it. UAE mobiles should be +971-prefixed.	§4.4 PID-13
`PID-19`	Correct the client's Emirates ID custom field: 784 followed by 12 digits, or fifteen 1s for tourists/newborns/unknown (bind the field on the NABIDH Mapping tab if it isn't already).	§5.3 PID-19
`PID-31`	Resident/tourist must resolve to O or T — check the bound resident-flag custom field value, or the connection's "assume resident by default" setting.	§4.4 PID-31

Client card — allergies

Open the client → Allergies.

Field	How to fix it	Spec reference
`AL1-2`	Set the allergy's type on the client card (drug/food/environment map to HL7 0127 codes; unmapped types default to MA).	§4.9 AL1-2
`AL1-3`	The allergy has no allergen name — fill in the allergen on the client card allergy record.	§4.9 AL1-3
`AL1-4`	Set the allergy's severity (mild/moderate/severe map to MI/MO/SV; unknown sends U).	§4.9 AL1-4
`AL1-6`	The allergy noted-date is malformed — correct the date on the client card allergy record.	§4.9 AL1-6

Client card — problems / diagnoses

Open the client → Problems.

Field	How to fix it	Spec reference
`PRB-3`	The problem has no code or description — code the problem (ICD-10) or add a description on the client card.	§4.31 PRB-3
`PRB-7`	The problem onset date is malformed — correct the onset date on the client card problem record.	§4.31 PRB-7

Appointments and visits

Open the booking, or its service in Setup → Services.

Field	How to fix it	Spec reference
`PV1-3.1`	The booking location must map to a NAB048 point-of-care name — set the location name in Pabau to a NAB048 value or bind a PV1.3 custom field on the Mapping tab.	§4.6 PV1-3 / §6 NAB048
`PV1-3.9`	The booking has no location name — set a location on the appointment (PV1-3.9 must carry the location description).	§4.6 PV1-3
`PV1-10`	Set the service's NABIDH specialty (Setup → Services → Edit → NABIDH specialty) or bind an appointment custom field holding a NAB008 code to PV1.10.	§4.6 PV1-10 / §6 NAB008
`PV1-19`	The encounter id is the Pabau booking id (or the document number on MDM) — a missing one means the source record could not be resolved.	§3.5 encounter identifiers
`PV1-36`	Discharge disposition must be a NAB012 code — check the custom field bound to PV1.36 on the Mapping tab (unbound defaults to HOM).	§4.6 PV1-36 / §6 NAB012

Staff records — Sheryan provider IDs

Every clinician needs an 8-digit Sheryan provider ID on their team record.

Field	How to fix it	Spec reference
`PV1-7.1`	Set the practitioner's 8-digit Sheryan provider ID in the 'Sheryan provider ID' team custom field (editable on the connection Settings tab).	§5.6 clinician identifiers
`ORC-12.1`	Set the prescriber's 8-digit Sheryan provider ID in the 'Sheryan provider ID' team custom field.	§5.6 clinician identifiers
`TXA-5.1`	Set the document author's 8-digit Sheryan provider ID in the 'Sheryan provider ID' team custom field.	§5.6 clinician identifiers

Prescriptions

Open the prescription in the client record.

Field	How to fix it	Spec reference
`RXE-2.2`	The drug line has no medicine name — check the prescription form content in Pabau.	§4.13 RXE-2
`RXE-3`	The dose could not be parsed into a numeric give-amount — write the dose as "<number> <unit>" (e.g. "500 mg") on the prescription.	§4.13 RXE-3
`RXE-5`	The dose has no unit — write the dose as "<number> <unit>" (e.g. "500 mg") on the prescription.	§4.13 RXE-5
`RXR-1.1`	The route of administration must be a NAB022 ROAxxx code — check the route text on the prescription (oral/topical/IV etc.).	§4.22 RXR-1 / §6 NAB022
`RXR-2.1`	The administration site is required. Pabau does not record one, so the encoder sends OTH (Others) — an empty value here means the segment was built without it.	§4.22 RXR-2 / §6 NAB023

Documents and letters

Open the attachment or letter in the client record.

Field	How to fix it	Spec reference
`TXA-2`	Map the document's Pabau type to a NAB035 code where possible (NABIDH displays unlisted types verbatim, so this is cosmetic unless DHA onboarding says otherwise).	§4.26 TXA-2 / §6 NAB035
`TXA-4`	The document has no usable created date — check the attachment/letter date in Pabau.	§4.26 TXA-4
`TXA-16`	The document has no file name/title — set a title on the attachment (or subject on the letter) in Pabau.	§4.26 TXA-16

Lab results

Open the lab request or report in the client record.

Field	How to fix it	Spec reference
`OBR-4`	The ordered panel/test has no code or name — check the lab request in Pabau carries a test name.	§4.20 OBR-4
`OBX-2`	The result value type could not be derived — check the lab result value (numeric → NM, text → ST).	§4.27 OBX-2
`OBX-3`	The observation identifier is empty — the lab test (or document type) needs a code or name in Pabau.	§4.27 OBX-3
`OBX-5`	The result has no value — fill in the result value on the lab report in Pabau.	§4.27 OBX-5

Consent and VIP flags

Driven by client custom fields bound on the Mapping tab.

Field	How to fix it	Spec reference
`ZSC-1`	The consent flag must resolve to Y/N — check the value of the client custom field bound to ZSC.1 (checkbox fields map 1/0 → Y/N).	DHA Z-segment addendum
`ZSC-2`	The VIP flag resolves from the bound client label (present → Y) — an invalid value indicates encoder drift.	DHA Z-segment addendum

Connection settings

These come from the connection itself rather than a patient record. Fix them in Setup → Data sync → Manage → Settings.

Field	How to fix it	Spec reference
`MSH-4`	Check the NABIDH connection Settings (Setup → Data sync → Manage → Settings) — the message header is built from emrCode / sheryanFacilityId there.	§3.1 / §4.1 MSH-4
`EVN-7.2`	Check the NABIDH connection Settings (Setup → Data sync → Manage → Settings) — the message header is built from emrCode / sheryanFacilityId there.	§5.2 EVN-7
`PID-3.4`	Check the NABIDH connection Settings (Setup → Data sync → Manage → Settings) — the message header is built from emrCode / sheryanFacilityId there.	§5.1 PID-3
`PV1-3.4`	Check the NABIDH connection Settings (Setup → Data sync → Manage → Settings) — the message header is built from emrCode / sheryanFacilityId there.	§4.6 PV1-3
`PV1-19.4`	Check the NABIDH connection Settings (Setup → Data sync → Manage → Settings) — the message header is built from emrCode / sheryanFacilityId there.	§3.5
`MRG-1.4`	Check the NABIDH connection Settings (Setup → Data sync → Manage → Settings) — the message header is built from emrCode / sheryanFacilityId there.	§3.2 A40 merge

Field	How to fix it	Spec reference
`MSH-11`	The processing id comes from the connection environment (dummy→D, test→T, production→P). Check the environment selector in the connection Settings.	§4.1 MSH-11

Findings you should report rather than fix

Around half of the checks cover values that Pabau generates itself — message headers, timestamps, structural markers. If one of those is ever flagged, it means the message builder produced something unexpected, not that your data is wrong. Send the delivery ID to Pabau support; there is nothing to change in your account.

The fields in this category are:

MSH-1 MSH-2 MSH-3 MSH-5 MSH-6 MSH-7 MSH-10 MSH-12 MSH-18 EVN EVN-1 EVN-2 EVN-6 EVN-7.1 PID PID-1 PID-3.5 PID-5.7 PID-11.7 PID-15 PV1 PV1-2 PV1-7.9 PV1-44 PV1-45 ZSC AL1-1 ORC ORC-1 ORC-9 ORC-12.9 RXE/RXR RXE-2.3 RXR-1.3 RXR-2.3 PRB PRB-1 PRB-2 PRB-9 PRB-14 PRB-16 OBR OBR-1 OBR-7 OBR-25 TXA TXA-1 TXA-5.9 TXA-12 TXA-17 TXA-19 OBX OBX-1 OBX-2 OBX-3.3 OBX-11 OBX-14 MRG MRG-1.1 MRG-1.5 MSH

NOTE: A handful of checks sit in both camps — for example PID-3.1 (the patient’s Pabau record number) and PRB-4 should always be present automatically, so if they are flagged it is worth reporting rather than editing.

What to do when nothing else explains it

Open the delivery in Logs and expand the failed attempt.
Read the response body — NABIDH’s own words are the most reliable signal.
Check the pre-flight findings listed on the attempt; each carries a plain-language fix.
Correct the record in Pabau, then press Retry on the delivery (or Sync latest to resend the current state of the record).
Still stuck? Send Pabau support the delivery ID and the correlation ID from the drawer — together they identify the exact message.