ERCD (Error Code and Location) is the legacy composite that lived in ERR-2 through HL7 v2.4. The standard prose calls it "ERCD" in some publications and "CM" in others (HL7 v2.1–v2.3 used the generic CM prefix for composite types); HAPI's v2.4 model package names the corresponding class ELD — Error Location and Description — and that is the spelling most developers see in code. From v2.5 onwards the composite was retired: ERR-2 was retyped as ERL (Error Location), the coded-error portion moved to ERR-3 as a CWE, and severity was elevated to a dedicated ERR-4 field.
This page documents ERCD/ELD because v2.4-and-earlier interfaces are still actively bridged into v2.7+ networks, and the migration semantics are exactly where new engineers get stuck.
Purpose
ERCD existed to answer two questions at once on a non-acknowledgment error: what went wrong (the coded error) and where in the offending message did it go wrong (segment ID, sequence within the message, field position). Packing both into a single composite kept ERR small in early versions of the standard but coupled location and diagnosis in ways that made it hard to express common cases — e.g. "this entire segment is wrong" (no field position) or "this value is wrong but I cannot describe it as a code" (free text only).
The v2.5 split fixed all of these: ERR-2 became a pure ERL location with explicit slots for repetition, component, and sub-component; ERR-3 became a pure CWE error code; ERR-4 became a dedicated severity. The cost of the cleanup is that v2.4 ↔ v2.5 bridges must split or fuse ERCD whenever a message crosses the boundary.
Component reference
Source: HAPI HL7v2 v2.4 javadocs — ELD. ELD/ERCD has four components separated by ^. Length is not published in the javadocs (—).
| Seq | Name | Data Type | Length | Req | Description |
|---|---|---|---|---|---|
| ERCD.1 | Segment ID | st | — | O | Three-letter ID of the segment in which the error occurred — PID, OBX, OBR, MSH. |
| ERCD.2 | Sequence | nm | — | O | 1-based occurrence of the segment within the message, counted across all segments sharing the same Segment ID. |
| ERCD.3 | Field Position | nm | — | O | 1-based field position within the segment. |
| ERCD.4 | Code Identifying Error | ce | — | R | The error itself, drawn from HL7 table [HL70357] — e.g. 100^Segment sequence error, 101^Required field missing, 102^Data type error, 103^Table value not found, 200^Unsupported message type. v2.4 typed this as CE; v2.5+ would type it as CWE. |
Note that HAPI's ELD class uses the underlying CE composite for component 4; conforming v2.5+ migrations should re-emit it as CWE.
Most-used components
- ERCD.1 Segment ID — read first to triage which segment the receiver objected to.
- ERCD.3 Field Position — points at the specific field; the most useful piece for an automated correction tool.
- ERCD.4 Code Identifying Error — the diagnosis. HL70357 has a small, stable code list; the most common values are
101(required field missing),102(data type error), and103(table value not found). - ERCD.2 Sequence — only relevant when the offending segment type repeats (multiple OBX rows, multiple NK1 rows); often left empty when the segment is unique in the message (MSH, PID).
Where it's used
ERCD lived in exactly one field, in v2.4-and-earlier messages:
- ERR-2 Error Code and Location — the canonical (and only) home of ERCD. One ERR segment carried one repeating ERR-2, with each repetition describing one structural problem with the message being acknowledged.
In v2.5+ the field was replaced: ERR-2 retyped as ERL, ERR-3 added as CWE error code, ERR-4 added as severity. v2.5+ messages do not contain ERCD instances.
Version differences
- v2.1 / v2.2 / v2.3 / v2.3.1 — Error-reporting composite present as a CM-prefixed type with the four components above; some documentation calls it ERCD, some calls it CM_ELD.
- v2.4 — Composite formalized; HAPI's v2.4 model package names it
ELD. Still four components, still typed CE for the error code. - v2.5 — Composite retired. ERR-2 retyped as ERL with six components (Segment ID, Segment Sequence, Field Position, Field Repetition, Component Number, Sub-Component Number). ERR-3 added as CWE Error Code. ERR-4 added as Severity (HL70516).
- v2.5.1 / v2.6 / v2.7 / v2.7.1 — No reintroduction of ERCD. ERL and CWE remain the structural anchors of an error report.
- v2.8 / v2.8.1 / v2.8.2 — HAPI v2.8.1 does not ship an
ERCDclass. The closest analog isERL, which is the v2.5+ replacement.
Common mistakes
- Re-emitting v2.4 ERCD into a v2.5+ ERR segment. The field positions and types are wrong — ERR-2 expects ERL, not ERCD; ERR-3 expects CWE, not absent. Bridges must split ERCD into ERL (taking components 1–3) and CWE (taking component 4) on the way up, and fuse them on the way down.
- Losing the error code on a v2.5+ → v2.4 down-conversion. When down-converting, the CWE in ERR-3 must be placed into ERCD.4. Down-converters that emit a v2.4 ERR with only ERR-2 populated and no error code are non-conformant and useless to the receiver.
- Treating ERCD.2 Sequence as a Set ID. It is the occurrence count of the segment type within the message, not a per-segment identifier. Segments without an explicit set ID (MSH, EVN, MSA, ERR itself) still have a sequence — typically 1.
- Free text in ERCD.4. ERCD.4 is CE; the identifier (CE.1) must be a code from HL70357. Free-text-only error descriptions break automated processing on the receiver. Use the original-text component (CE.6 / CWE.9 in v2.5+) for prose.
- Populating ERCD.3 Field Position with a 0-based index. HL7 v2 field positions are 1-based; field 1 of OBX is the Set ID, not the value type. 0-based emitters off-by-one every error report.
- Omitting ERCD.1 Segment ID. A field position without a segment ID is unactionable; the receiver cannot tell which segment the field belongs to.
Examples
Minimal value — just the error code, location unknown:
^^^101^Required field missing^HL70357
Three-component value — segment and field position, no error code:
PID^1^5
Field-level error report:
PID^1^5^101^Required field missing^HL70357
Segment-sequence error (segment in the wrong order):
OBX^3^^100^Segment sequence error^HL70357
Data-type error in OBX-5:
OBX^2^5^102^Data type error^HL70357
Table-value error in PID-8 (Administrative Sex):
PID^1^8^103^Table value not found^HL70357
In context — full v2.4 NACK rejecting a malformed ADT:
MSH|^~&|EHR|MERCY|EMR|MERCY|20260624102000-0500||ACK^A01^ACK|ACK-77321|P|2.4
MSA|AE|MSG-ADT-77321|Patient identifier missing
ERR|PID^1^3^101^Required field missing^HL70357~PID^1^5^101^Required field missing^HL70357
In context — the same NACK migrated to v2.8.1 (note the split into ERR-2 ERL and ERR-3 CWE, and the added severity in ERR-4):
MSH|^~&|EHR|MERCY|EMR|MERCY|20260624102000-0500||ACK^A01^ACK|ACK-77321|P|2.8.1
MSA|AE|MSG-ADT-77321
ERR|PID^1^3|PID^1^3|101^Required field missing^HL70357|E^Error^HL70516
ERR|PID^1^5|PID^1^5|101^Required field missing^HL70357|E^Error^HL70516
Common pitfall — v2.4 emitter against a v2.7+ receiver:
MSH|^~&|EMR|MERCY|EHR|MERCY|20260624102000-0500||ACK^A01^ACK|ACK-77321|P|2.7.1
ERR|PID^1^5^101^Required field missing^HL70357
VID.1 claims 2.7.1, but ERR-2 carries a four-component ERCD instead of the v2.5+ ERL/CWE split. The v2.7.1 parser cannot bind the trailing components and the error report is silently truncated.
FHIR mapping
The v2-to-FHIR Implementation Guide does not publish a per-datatype ConceptMap for ERCD, because the IG targets modern (v2.5+) HL7 and ERCD does not exist there. Conceptually, the four-component composite collapses onto a single OperationOutcome.issue entry:
| HL7 v2 (ERCD) | FHIR OperationOutcome.issue |
|---|---|
| ERCD.1 Segment ID | embedded in issue.location / issue.expression (e.g. PID-5) |
| ERCD.2 Sequence | embedded in issue.location as the occurrence index |
| ERCD.3 Field Position | embedded in issue.location as the field portion |
| ERCD.4 Code Identifying Error | issue.details (CodeableConcept) — code from a value set derived from HL70357 |
| (no source — defaults to error in v2.4-and-earlier) | issue.severity |
(no source — defaults to processing) | issue.code |
For v2.5+ ERR segments, the v2-to-FHIR IG maps each ERR repetition to one issue — drawing location from ERR-2 (ERL), details from ERR-3 (CWE), and severity from ERR-4. Down-converting a FHIR OperationOutcome into a v2.4 ERCD requires fusing the location and details fields back into one composite.
Engine considerations
- Bridge translation. Any engine that bridges v2.4 ↔ v2.5+ must split and fuse ERCD on every crossing. Splitting v2.4 → v2.5+ takes ERCD.1–ERCD.3 → ERL, ERCD.4 → CWE, and synthesizes a default severity (typically
EError from HL70516). Fusing v2.5+ → v2.4 takes ERL.1–ERL.3 → ERCD.1–ERCD.3 and CWE → ERCD.4; ERL.4–ERL.6 (Repetition, Component, Sub-Component) and ERR-4 Severity have nowhere to land in v2.4 and are lost. - Severity defaulting. v2.4-and-earlier messages have no explicit severity field; receivers must default to
errorwhen up-converting. Bridges that default toinformationorwarningmute critical errors and let bad data continue downstream. - Code-system curation. HL70357 (HL7 Message Error Status Codes) is small but stable:
100segment sequence error,101required field missing,102data type error,103table value not found,200unsupported message type,201unsupported event code,202unsupported processing ID,203unsupported version ID,204unknown key identifier,205duplicate key identifier,206application record locked,207application internal error. Engines should treat any value outside this list as a profile extension and log it. - HAPI typing. HAPI's v2.4 model exposes the composite as
ca.uhn.hl7v2.model.v24.datatype.ELDwith accessorsgetSegmentID(),getSequence(),getFieldPosition(),getCodeIdentifyingError(). v2.8.1 has no ERCD/ELD class; the closest analog isca.uhn.hl7v2.model.v281.datatype.ERLfor the location portion only. - Round-trip lossiness. v2.5+ → v2.4 → v2.5+ round-trips lose ERL.4–ERL.6 and ERR-4. Engines that must preserve those values across the bridge should carry a side-channel (a non-conformant Z-segment or external trace) rather than relying on the v2.4 ERR to round-trip them.
How Vorro parses and produces ERCD
Vorro parses ERCD only when an inbound message declares VID.1 ≤ 2.4. The composite is decomposed into (segmentId, sequence, fieldPosition, errorCode) and immediately mapped to Vorro's internal Issue model, which is shape-compatible with FHIR OperationOutcome.issue. Severity is defaulted to error because v2.4 ERR carries no severity field; the default is tagged so the receiver can distinguish "sender asserted error" from "Vorro inferred error."
When Vorro produces an outbound message to a v2.4-and-earlier destination, the internal Issue is fused back into ERCD: ERL.1–ERL.3 collapse into ERCD.1–ERCD.3, the CWE error code collapses into ERCD.4 (down-cast to CE), and ERL.4–ERL.6 plus the FHIR-side severity are dropped with a logged warning. Vorro never silently drops them — every down-cast emits a structured warning so operators can see exactly which information the destination is incapable of receiving.
Related pages
- CWE data type — Coded With Exceptions (the v2.5+ replacement for the error-code portion)
- ERR segment — Error
- MSA segment — Message Acknowledgment
