HL7 v2 ERR-4 Field Guide: Severity Values and Common Mistakes
ERR-4 is a single coded value, but it decides whether a message gets rejected outright or just logged with a shrug, and a lot of receiving systems treat every populated ERR segment as fatal because their test data never included anything but the error-level severity.
ERR-4 is the Severity field. It carries one of three coded values: E for a genuine error that should block or reject the message, W for a warning about something questionable that did not stop processing, and I for an informational note that has no bearing on whether the message was accepted.
What this field contains
Example
A synthetic ERR segment flagging a suspicious but non-blocking value in PID-13 with a warning-level severity.
Where this trips people up
A surprising number of downstream systems key their entire message-rejection logic off whether ERR-4 is simply present rather than checking its actual value, so a message that only carried a warning or an informational ERR gets discarded exactly like a hard failure. Test suites that only ever generate error-level ERR segments never catch this, because the bug only shows up once a warning-level message shows up expecting to be accepted. Building synthetic test cases across all three severity values is the only reliable way to confirm the receiving system is actually reading ERR-4 instead of just noticing the segment exists.