ERR is the segment that turns a rejected message from a mystery into a diagnosis, and it is the segment most test suites under-exercise because nobody bothers to generate the bad inbound data that would actually trigger it.
Quick answer
ERR (Error) is the segment carried in acknowledgment messages, typically ACK and NAK, that reports what went wrong with an inbound HL7 v2 message. It points to the exact segment, field, and component involved, classifies the problem into a coded error category, and flags how serious the issue is - a hard rejection, a warning, or just an informational note. If your interface engine or downstream system generates any kind of validation feedback, it is almost certainly building that feedback out of ERR.
The fields that actually matter in practice
ERR-1
Error Code and Location — an older, pre-component style location pointer kept for backward compatibility; most modern interfaces read ERR-2 instead
ERR-2 →
Error Location — identifies exactly which segment occurrence, field position, and component of the offending message triggered the error
ERR-3 →
HL7 Error Code — a coded category describing the type of problem found, such as a missing required field, a data type mismatch, or an unsupported message type
ERR-4 →
Severity — marks whether the problem is a hard error, a warning, or purely informational, which drives whether the sending system should stop or just take note
ERR-5
Application Error Code — a locally defined error code layered on top of the standard HL7 category, used when a receiving application wants more specific detail than the coded table provides
ERR-8
User Message — a free-text description meant for a human reading the acknowledgment, often the only field anyone actually looks at when triaging a rejected message
Example
Synthetic example Generated by Synthibase
ERR||PID^1^8^1|101^Required field missing^HL70357|E|||Patient administrative sex is required and was not populated
A synthetic ERR segment reporting a missing required field in PID-8, flagged as an error-level severity. All identifiers and text are fabricated for this example.
Where this trips people up
Test suites almost always validate the happy path - a clean message that produces a clean ACK - and never bother constructing the malformed inbound messages that would actually populate ERR. That means the code responsible for parsing ERR-2 location pointers, branching on ERR-3 error categories, or routing on ERR-4 severity often goes live having only ever seen an empty ERR segment or none at all. Another common miss: teams treat every NAK the same way instead of checking severity, so a message that only carried a warning-level ERR gets dropped exactly like one that carried a hard error, silently discarding data that should have gone through.
Generate realistic ERR test scenarios without hand-crafting broken messages
Synthibase can produce synthetic HL7 v2 messages with deliberate, controlled defects - missing fields, bad data types, unsupported message types - so your ACK/NAK handling and ERR parsing logic get real coverage before go-live.
Start free trial →
This page is written independently by Synthibase for testing and informational purposes. It is not an official publication of HL7 International or X12/Washington Publishing Company, and is not a substitute for reviewing the official standard or your trading partner's companion guide. See our
Terms of Service for full legal terms.