HL7 EI Data Type: Entity Identifier

The EI (Entity Identifier) data type was introduced in HL7 v2.3 to carry an identifier that is namespace-scoped — the value is unique only within the issuing system, and the namespace tells the receiver which system that is. EI appears wherever HL7 needs to identify a specific business object: order numbers (ORC-2 Placer Order Number, ORC-3 Filler Order Number, OBR-2, OBR-3), the donation identification number in BUI-2 / DON-1, the message control ID in some profiles of MSH-10, and many cross-reference identifiers.

Purpose

EI is the simpler sibling of CX. Where CX adds patient-identifier metadata (check digit, identifier type code, assigning facility, effective dates), EI carries just enough metadata to make an identifier globally resolvable: the local ID, the namespace that issued it, and (optionally) a universally unique OID/GUID/UUID with a type code so the receiver can reason about it across organizational boundaries.

Component table

Source: HAPI HL7v2 v2.8.1 javadocs (EI). Length is shown as — because v2.7+ deprecated fixed maximum lengths in favour of conformance-profile constraints.

Most-used components

• EI.1 Entity Identifier — the actual ID value; this is what humans read and what local systems index.
• EI.2 Namespace ID — names the issuing application or service; the most common cross-system disambiguator in practice.
• EI.3 / EI.4 Universal ID + Type — the rigorous, globally resolvable identification of the issuing authority; required for cross-organization exchange where namespace strings may collide.

Where it's used

• ORC-2 Placer Order Number — the order ID assigned by the placer (EHR/CPOE).
• ORC-3 Filler Order Number — the order ID assigned by the filler (LIS/RIS/Pharmacy).
• ORC-4 Placer Group Number — groups related orders under a single placer-assigned ID.
• OBR-2 Placer Order Number — mirrors ORC-2 at the observation-request level.
• OBR-3 Filler Order Number — mirrors ORC-3 at the observation-request level.
• PV1-19 Visit Number — encounter identifier (CX in modern profiles, EI in some legacy ones).
• BUI-2 Blood Unit Identifier — the DIN-derived unit identifier.
• DON-1 Donation Identification Number (DIN) — the donation event identifier.
• SPM-2 Specimen ID — laboratory specimen identifier.
• TXA-12 Unique Document Number — transcription document identifier.

Version differences

• HL7 v2.3 — EI introduced with the four-component structure shown above.
• HL7 v2.4 / v2.5 / v2.5.1 — no structural changes; vocabulary refinement on [HL70301] Universal ID Type added codes such as GUID and UUID.
• HL7 v2.6 / v2.7 — no structural changes; conformance guidance strengthened the requirement that EI.3 and EI.4 be co-populated.
• HL7 v2.7.1 / v2.8 / v2.8.1 / v2.8.2 — structure stable; fixed maximum lengths deprecated. HAPI v2.8.1 javadoc shows the same four components.

Common mistakes

• Confusing EI with CX. EI is namespace-scoped (HL70363 in EI.2 / HL70301 in EI.4); CX is type-and-authority-scoped (HL70203 Identifier Type Code in CX.5). They have different metadata vocabularies and cannot be substituted for one another, even though both carry an identifier value.
• Populating only EI.1 and EI.2 for an order that crosses organizational boundaries — the receiving organization cannot guarantee namespace uniqueness across vendors, so EI.3/EI.4 are required for federated workflows.
• Sending EI.3 (an OID) without EI.4 — the receiver cannot validate the format without knowing the type, and strict profiles will reject the message.
• Putting an OID into EI.1 (the local identifier slot) and leaving EI.3 empty — defeats the round-trip purpose of EI and makes the local ID unrecognizable in the source system.
• Reusing the same EI.2 namespace string across acquired hospital systems after a merger — collisions silently corrupt cross-reference lookups.

Examples

Minimal value (local identifier only):

ORD-1234

Three-component value with namespace:

ORD-1234^MERCY

Four-component value (fully populated EI with universal ID):

ORD-1234^MERCY^2.16.840.1.113883.19.5^ISO

Variant with UUID rather than OID:

ORD-1234^MERCY^9c4e1f88-7a3d-4c1f-9c2a-9a3d7d3f1a2b^UUID

In context — ORC-2 / ORC-3 placer and filler order numbers in an order message:

MSH|^~&|CPOE|MERCY^2.16.840.1.113883.19.5^ISO|LIS|MERCY|20260610100500||ORM^O01^ORM_O01|MSG00121|P|2.8.1
PID|1||MR884412^^^MERCY^MR||TESTPATIENT^ALEX^Q||19720508|F
ORC|NW|ORD-1234^MERCY^2.16.840.1.113883.19.5^ISO|FIL-9988^MERCY-LIS^2.16.840.1.113883.19.5.1^ISO|GRP-77^MERCY|||||20260610100500
OBR|1|ORD-1234^MERCY^2.16.840.1.113883.19.5^ISO|FIL-9988^MERCY-LIS^2.16.840.1.113883.19.5.1^ISO|24323-8^Comprehensive Metabolic Panel^LN

Common pitfall — EI.3 without EI.4:

ORC|NW|ORD-1234^MERCY^2.16.840.1.113883.19.5

The receiver sees an unlabeled string in EI.3 and cannot tell whether it is an ISO OID, a GUID, or a vendor-private identifier scheme — strict profiles will reject this message.

FHIR mapping

The v2-to-FHIR IG publishes several EI ConceptMaps depending on the receiving context:

• ConceptMap-datatype-ei-system-to-identifier — default mapping to Identifier.
• ConceptMap-datatype-ei-to-coding — used where EI carries a code rather than an identifier.
• ConceptMap-datatype-ei-to-condition — used where EI surfaces in a problem-list slot.
• ConceptMap-datatype-ei-to-procedure — used where EI references a procedure.
• ConceptMap-datatype-ei-udicarrier-to-device — used where EI references device-assigned identifiers.

The default Identifier mapping is:

Because EI is reused across many semantic contexts, the surrounding field's profile determines which ConceptMap applies — EI does not have a single "correct" FHIR target outside of context.

Engine considerations

• Universal ID Type validation: EI.4 must come from HL70301; engines that allow free text here let OID slip in when the standard requires ISO. Validate at parse time.
• EI vs CX disambiguation: many fields historically transitioned from EI to CX (e.g. PV1-19 Visit Number). Engines that auto-detect by component count will mis-parse a CX with only its first four components populated as an EI. Use the schema, not the value, to decide.
• OID format checking: when EI.4 is ISO, EI.3 should match the dotted-decimal OID syntax. Soft-validate this and reject obvious nonsense at the boundary.
• Empty EI.2 with populated EI.3 is permitted (universal-ID-only EI) but rare; do not treat it as a parse error.

How Vorro parses and produces EI

Vorro indexes EI by both (EI.1, EI.2) and (EI.1, EI.3, EI.4) so that cross-references resolve whether the upstream system populated the namespace, the universal ID, or both. On inbound, EI.4 is validated against HL70301 and unknown values are tagged for curation rather than silently accepted. EI.3 is normalized to a canonical URN form (urn:oid:..., urn:uuid:...) in the internal model so downstream FHIR mappers do not have to repeat the prefixing logic.

On outbound, Vorro emits EI with all four components whenever the destination is cross-organizational, and prunes EI.3/EI.4 only for intra-application messages where the namespace alone is sufficient. We never emit EI.3 without EI.4.

Related pages

• CX data type — Extended Composite ID with Check Digit
• HD data type — Hierarchic Designator
• ORC segment — Common Order

Sources

• HAPI HL7v2 v2.8.1 javadoc — EI data type
• HAPI HL7v2 v2.8.1 apidocs index
• HL7 v2 product brief
• v2-to-FHIR ConceptMap — EI to Identifier