HL7 ELT Data Type: Element Location Type (Error Location)

ELT (Element Location Type) is the v2.5+ composite that points at the exact location inside a message where an error was detected. It has six components — Segment ID, Segment Sequence, Field Position, Field Repetition, Component Number, Sub-Component Number — and walks the receiver from the outer segment all the way down to a sub-component within a single field.

A small naming wrinkle: HL7's published prose calls the underlying composite Element Location Type (ELT), but HAPI's v2.8.1 model package ships the class as ca.uhn.hl7v2.model.v281.datatype.ERL — Error Location. Both names refer to the same six-component composite. This page uses ELT for the type and notes ERL wherever the HAPI class name matters in code.

ELT was introduced in v2.5 as the location half of the v2.4 ERCD/ELD split — the legacy composite's location components (Segment ID, Sequence, Field Position) survive as ELT.1–ELT.3, with three new components (Field Repetition, Component Number, Sub-Component Number) added underneath.

Purpose

ELT exists to answer one question precisely: where in the offending message did the error occur? The six-component drill-down lets the receiver pinpoint a sub-component inside a repetition inside a field inside an instance of a segment, which is enough resolution to underline the exact offending byte range on a screen or in an automated retry.

Separating location from the coded error (which lives in ERR-3 as a CWE) means a single ERR segment can carry both — and it means the location can be richly populated even when the diagnosis is a free-text human description. That separation is the whole reason ERCD was retired.

Component reference

Source: HAPI HL7v2 v2.8.1 javadocs — ERL. ELT/ERL has six components separated by ^.

Seq	Name	Data Type	Length	Req	Description
ELT.1	Segment ID	st	3	R	Three-letter segment identifier — `PID`, `OBX`, `MSH`, `IN1`.
ELT.2	Segment Sequence	nm	—	O	1-based occurrence of the segment within the message, counting across all segments sharing the same Segment ID.
ELT.3	Field Position	nm	—	O	1-based field position within the segment.
ELT.4	Field Repetition	nm	—	O	1-based repetition number within a repeating field (e.g. PID-3 patient identifier list).
ELT.5	Component Number	nm	—	O	1-based component within the field.
ELT.6	Sub-Component Number	nm	—	O	1-based sub-component within the component.

All components after ELT.1 are optional; populate from the outside in and stop at the level of detail the receiver actually needs.

Most-used components

ELT.1 Segment ID — the only required component; populate every time.
ELT.3 Field Position — the second most useful piece; identifies the field that failed validation.
ELT.2 Segment Sequence — only relevant when the offending segment type repeats (multiple OBX rows, multiple NK1 rows). Default to 1 for unique segments (MSH, PID).
ELT.5 Component Number — used when only one component of a composite field is bad (e.g. PID-5.1 Family Name missing but PID-5.2 Given Name fine).
ELT.4 Field Repetition — used when the bad value is in a specific repetition (e.g. the third PID-3 patient identifier).
ELT.6 Sub-Component Number — rarely populated; sub-components are uncommon outside extension types.

Where it's used

ERR-2 Error Location — the canonical home. Each ERR segment carries one or more ELT instances in ERR-2, pointing at every location implicated in the error described by ERR-3 (CWE) and ERR-4 (severity).

ELT is structurally a generic location pointer and could be reused anywhere a message needs to reference a position inside another message, but in published v2.8.1 segments ERR-2 is its only home.

Version differences

v2.1–v2.4 — No ELT. Location pointer was fused with the error code into the four-component ERCD/ELD composite in ERR-2. Repetition, component, and sub-component had no representation at all.
v2.5 — ELT introduced. ERR-2 retyped from ERCD to ELT. ERR-3 added as CWE error code. ERR-4 added as severity. Bridge engines must split incoming v2.4 ERCD into ELT (components 1–3, with 4–6 left empty) and CWE on the way up.
v2.5.1 / v2.6 / v2.7 / v2.7.1 / v2.8 / v2.8.1 / v2.8.2 — Six-component ELT remains stable. HAPI ships the class as ERL across all v2.5+ packages.

Common mistakes

Confusing ELT with ERL in code reviews. HAPI's class name is ERL; the v2 spec calls the type ELT. They are the same thing. Reviewers who insist on renaming all ERL references to ELT (or vice versa) end up rewriting working code for no semantic gain.
Populating ELT.2 with a Set ID. ELT.2 Segment Sequence is the occurrence count of the segment type within the message, not the value of any Set ID field. Segments without an explicit set ID (MSH, EVN) still have a sequence.
0-based field positions. HL7 v2 field positions are 1-based; MSH-1 is the field separator, OBX-1 is the Set ID. 0-based emitters off-by-one every error report.
Empty ELT.1. A location pointer with no segment ID is unactionable — the receiver cannot resolve "field 5 of nothing" against the original message.
Encoding multiple locations into one ELT. ERR-2 is repeating; if an error implicates three fields, emit three ELT repetitions in ERR-2, not one ELT with three field positions jammed together.

Examples

Minimal — segment only:

PID

Field-level — PID-5 (Patient Name):

PID^1^5

Component-level — PID-5 component 1 (Family Name) of repetition 1:

PID^1^5^1^1

Sub-component — IN1-7.1.2 of the second IN1 segment:

IN1^2^7^1^1^2

Repeating identifier — the third PID-3 patient identifier:

PID^1^3^3

In context — ERR segment with two ELT repetitions in ERR-2:

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^5^1^1|PID^1^3|101^Required field missing^HL70357|E^Error^HL70516

Common pitfall — 0-based field position:

ERR||PID^1^4|101^Required field missing^HL70357|E

The emitter meant "PID-5 (Patient Name) is missing" but encoded the field as 4 because their internal model is 0-indexed. The receiver dutifully reports back "field 4 missing" — which is PID-4 (Alternate Patient ID), a deprecated field — and the operator wastes 20 minutes chasing the wrong field.

FHIR mapping

The v2-to-FHIR Implementation Guide does not publish a per-datatype ConceptMap for ELT. The HL7 v2 location pointer (segment, field, repetition, component, sub-component) maps to an OperationOutcome.issue.location FHIRPath expression or to an issue.expression entry.

HL7 v2 (ELT)	FHIR `OperationOutcome.issue.location`
ELT.1 Segment ID	segment portion of the expression (e.g. `PID`)
ELT.2 Segment Sequence	occurrence index in the expression
ELT.3 Field Position	field portion (e.g. `PID-5`)
ELT.4 Field Repetition	repetition portion (e.g. `PID-5[2]`)
ELT.5 Component Number	component portion (e.g. `PID-5.1`)
ELT.6 Sub-Component Number	sub-component portion (e.g. `PID-5.1.2`)

FHIR issue.location is typed as string and is free-form by spec; modern guidance prefers issue.expression as a FHIRPath string, but for v2-derived issues a synthetic dotted path (PID-5.1.2) is the convention.

Engine considerations

Bridge translation. Up-converting v2.4 ERCD → v2.5+ ELT: ELT.1 ← ERCD.1, ELT.2 ← ERCD.2, ELT.3 ← ERCD.3; ELT.4–ELT.6 stay empty. Down-converting v2.5+ ELT → v2.4 ERCD: take ELT.1–ELT.3 and drop ELT.4–ELT.6 with a logged warning.
HAPI accessors. ca.uhn.hl7v2.model.v281.datatype.ERL exposes getSegmentID(), getSegmentSequence(), getFieldPosition(), getFieldRepetition(), getComponentNumber(), getSubComponentNumber(). The class is named ERL despite the spec's ELT prose; engines that programmatically generate documentation should map both names.
Repetition encoding. ERR-2 repeats; emit one ELT per implicated location rather than overloading a single ELT.
Validation. Receivers should reject ELT with an empty ELT.1 — a location pointer with no segment is structurally meaningless.
Round-trip across v2.4. ELT.4–ELT.6 cannot survive a v2.4 hop because ERCD has no slots for them. Engines that need to preserve sub-component-level locations across a v2.4 bridge must carry them on a side channel.

How Vorro parses and produces ELT

Vorro parses ELT into an internal Location record with six explicit slots (segmentId, segmentSequence, fieldPosition, fieldRepetition, componentNumber, subComponentNumber), all optional except segmentId. The record is shape-compatible with the FHIR OperationOutcome.issue.location convention, so issues that arrive over the v2 channel and issues that arrive over a FHIR OperationOutcome channel share a single internal representation.

When producing ELT outbound, Vorro emits exactly the components the destination's version supports. For v2.4-and-earlier destinations, the location is fused with the error code into ERCD and ELT.4–ELT.6 are dropped with a structured warning. For v2.5+ destinations, the full six-component ELT is emitted with empty trailing components when not populated — Vorro never inserts placeholder zeroes, which would be misread as "component 0."

Sources

← Back to HL7 v2 Guide