ERR-3 is the field that turns a rejection into a category a routing rule can act on, and most test suites only ever generate one or two of its possible values, leaving entire branches of downstream error handling unverified.
Quick answer
ERR-3 is the HL7 Error Code field. It carries a coded value, drawn from a table of standard error categories, describing the general type of problem the receiving system found - things like a required field that was missing, a value that did not match its expected data type, or a message type the receiving system does not support.
What this field contains
Component 1
Identifier — the numeric or alphanumeric code representing the error category, e.g. a code meaning required field missing
Component 2
Text — a short human-readable label describing that category, meant to travel alongside the code
Component 3
Coding system — identifies which table the code was pulled from, distinguishing standard tables from locally defined ones
Common case
Structural problems — codes covering missing required data or fields that do not match their expected format
Divergent case
Unsupported content — codes covering message types, event types, or processing IDs the receiving system was not built to handle
Example
Synthetic example Generated by Synthibase
ERR||MSH^1^9^1|200^Unsupported message type^HL70357|E|||Receiving application does not support trigger event Z99
A synthetic ERR segment reporting an unsupported message type found in MSH-9, with a fabricated trigger event code.
Where this trips people up
It is common for a test generator to only ever produce the "required field missing" category because it is the easiest defect to fake, so error-routing logic that branches differently for data type errors versus unsupported message types versus table-value errors never gets a real workout. Another frequent miss: teams hardcode a single coding system in ERR-3 component three and forget that some interfaces mix standard categories with locally defined ones, which breaks lookups when a test message uses a local code the parser was not expecting.
Cover every HL7 error category before go-live
Synthibase can generate synthetic messages that deliberately trip a full spread of error categories - missing fields, data type mismatches, unsupported message types, and more - so your routing logic is tested against more than just the easy case.
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.