HL7 ERR Error
HL7 field reference ERR fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| ERR.1 | Error Code and Location | No | Yes | ELD | 0060 |
| ERR.2 | Error Location | No | Yes | ERL | |
| ERR.3 | HL7 Error Code | Yes | No | CWE | 0357 |
| ERR.4 | Severity | Yes | No | ID | 0516 |
| ERR.5 | Application Error Code | No | No | CWE | 0533 |
| ERR.6 | Application Error Parameter | No | Yes | ST | |
| ERR.7 | Diagnostic Information | No | No | TX | |
| ERR.8 | User Message | No | No | TX | |
| ERR.9 | Inform Person Indicator | No | Yes | IS | 0517 |
| ERR.10 | Override Type | No | No | CWE | 0518 |
| ERR.11 | Override Reason Code | No | Yes | CWE | 0519 |
| ERR.12 | Help Desk Contact Point | No | Yes | XTN |
ERR describes an error or warning in a structured way so the sender can identify what failed and where.
ERR is the structured explanation that tells the sender what went wrong and where. In an ACK it is often the difference between a useful rejection and a mystery retry loop.
Populate the location, severity, error code, and diagnostic text in a way that points to the field or component the sender can fix. A vague error is just a support ticket with extra steps.
The v2.5.1 structures show ERR in ACK - General acknowledgment message, ADR_A19 - Patient query, BRP_O30 - BRP - Blood product dispense status acknowledgment, and BRT_O32 - BRT - Blood product transfusion/disposition acknowledgment, and 56 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
ERR-1 points back to the part of the incoming message that caused the problem. Use it to identify the segment, field, component, repetition, or subcomponent that the sender can actually fix.
When several locations failed, repeat the field rather than compressing several message paths into one vague note.
ERR-2 points back to the part of the incoming message that caused the problem. Use it to identify the segment, field, component, repetition, or subcomponent that the sender can actually fix.
When several locations failed, repeat the field rather than compressing several message paths into one vague note.
ERR-3 is the standard HL7 error code. It gives the sender a machine-readable reason for the failure, so choose the closest agreed value rather than dropping everything into a generic application error.
ERR-4 separates fatal errors, errors, warnings, and informational messages. That distinction matters for retry logic and operator alerting.
ERR-5 is the receiver's local or application-specific error code. It is useful when ERR-3 is too broad, but the sender still needs the code set and documentation to understand it.
ERR-6 carries parameters that explain the application error, such as the offending local code, limit, or expected value. Keep each repeat small and meaningful.
ERR-7 is the technical explanation for support staff. Include enough detail to reproduce or correct the issue, but avoid leaking sensitive payload data into logs where it does not belong.
ERR-8 is the human-facing message. It should be clearer and less technical than the diagnostic text, especially if the receiving application may show it to an operator.
ERR-9 says whether someone needs to be informed about the error. Treat it as an operational signal, not as a substitute for monitoring and alert rules.
ERR-10 describes what kind of override may apply. Only populate it when the workflow really supports override handling and the sender knows what to do with it.
ERR-11 gives the reason an override was used or requested. Keep the code aligned with the local policy because override reason values are often audited.
ERR-12 gives the sender a support contact point. It is useful for onboarding and production incidents, but it should be kept current or it quickly becomes noise.