The EIP (Entity Identifier Pair) data type was introduced in HL7 v2.3 to solve one specific problem: a child order or result needs to reference its parent, and the parent's identity is known to two different systems — the placer (the ordering system) and the filler (the performing system) — each using its own identifier. EIP pairs those two identifiers in a single composite so the receiver always has both halves of the link, regardless of which system it can join against.
Purpose
In an Order Entry / Lab workflow, a reflex test (a child order) needs to point back to the test that triggered it (the parent). The placer knows the parent by its Placer Order Number; the filler knows it by its Filler Order Number. A receiver that joins on Placer Order Number alone fails when the inbound message originated from the filler side — and vice versa. EIP fixes that by always carrying both identifiers together. The same shape is reused for parent observation references in OBR-50 and for parent service identifiers in some profiles.
EIP is structurally simple: two EI values, side by side, separated by ^. The complexity lives inside each EI (which has its own four sub-components for entity ID, namespace, universal ID, and universal ID type).
Component reference
Source: HAPI HL7v2 v2.8.1 javadocs — EIP. EIP has 2 components separated by ^. Length is not published in the javadocs (—).
| Seq | Name | Data Type | Length | Req | Description |
|---|---|---|---|---|---|
| EIP.1 | Placer Assigned Identifier | ei | — | C | The parent's identifier as known to the placer system. At least one of EIP.1 / EIP.2 must be present. |
| EIP.2 | Filler Assigned Identifier | ei | — | C | The parent's identifier as known to the filler system. |
Because each component is itself an EI with four sub-components, an EIP serialized in the wire format uses the sub-component separator & within each component and the component separator ^ between them. A fully populated EIP can look quite dense; it's still just two EIs.
Most-used components
- EIP.1 Placer Assigned Identifier — the parent's placer order number with its assigning authority. The most common single component populated, and what placer-anchored systems will join on.
- EIP.2 Filler Assigned Identifier — the parent's filler order number with its assigning authority. Required for filler-anchored joins; populated in result and reflex flows where the filler is the source of truth.
In practice senders should populate both whenever they have both. The whole point of EIP is to free the receiver from caring which side the message came from.
Where it's used
- OBR-29 Parent — references the parent observation that triggered this OBR (reflex tests, additional ordered tests).
- OBR-50 Parent Universal Service Identifier — in some profiles, the parent's universal service identifier.
- ORC-8 Parent — the parent order for a child order in an order group (split orders, follow-ups).
- OBX-25 Observation Sub-ID — in profiles that retyped for parent linkage.
- Various Z-segments in vendor specifications that elected EIP for explicit parent linkage.
EIP is overwhelmingly an Orders / Observations data type; it has no role outside the order-result message family.
Version differences
- v2.3 — EIP introduced with 2 components, each an EI.
- v2.3.1 / v2.4 / v2.5 / v2.5.1 / v2.6 / v2.7 — structurally stable. The internal EI shape evolved (universal ID and universal ID type became mandatory companions in v2.5+) but EIP itself did not change.
- v2.7.1 / v2.8 / v2.8.1 / v2.8.2 — structurally stable per the HAPI v2.8.1 javadoc. Same two components.
EIP has not been deprecated and is still the canonical parent-linkage composite in v2.8.1.
Common mistakes
- Populating only EIP.1 because the sending system happens to be the placer. The receiver may be filler-anchored; a one-sided pair forces it to do a lookup it shouldn't need.
- Reusing the child's Placer / Filler Order Numbers in EIP. EIP references the parent, not the current message's own order.
- Stuffing both identifiers into EIP.1 as a single string separated by spaces or slashes. The placer and filler identifiers must occupy distinct components.
- Omitting the assigning authority sub-components (EI.2 / EI.3 / EI.4) inside each EIP component. A bare entity ID with no namespace can collide across facilities — the assigning authority is what makes the identifier globally unique.
- Confusing EIP's sub-component delimiter (
&) with its component delimiter (^).123^MERCY^ISOis a malformed EIP whose EIP.1 looks like123rather than123^MERCY^ISO; the correct form is123&MERCY&&ISOfor EIP.1.
Examples
Minimal — placer side only:
ORD-1234&MERCY&2.16.840.1.113883.19.5&ISO
(Single EI in EIP.1; EIP.2 absent. Legal but defeats the point.)
Fully populated EIP — placer and filler:
ORD-1234&MERCY&2.16.840.1.113883.19.5&ISO^FILL-5678&LIS&2.16.840.1.113883.19.7&ISO
EIP.1 is ORD-1234 from MERCY (OID 2.16.840.1.113883.19.5); EIP.2 is FILL-5678 from LIS (OID 2.16.840.1.113883.19.7).
In context — OBR-29 Parent on a reflex test:
OBR|2|RX-9012^MERCY|FILL-9012^LIS|301^Reflex panel^L|||20260610120000||||||||300^DR Smith|||||||||||F|||||||ORD-1234&MERCY&2.16.840.1.113883.19.5&ISO^FILL-5678&LIS&2.16.840.1.113883.19.7&ISO
The reflex panel OBR carries OBR-29 pointing back to the parent order that triggered it, identified in both placer and filler namespaces.
In context — ORC-8 Parent on a child order:
ORC|NW|RX-9012^MERCY|FILL-9012^LIS|||||ORD-1234&MERCY&2.16.840.1.113883.19.5&ISO^FILL-5678&LIS&2.16.840.1.113883.19.7&ISO
Common pitfall — using ^ between the two EI elements' sub-components:
ORD-1234^MERCY^2.16.840.1.113883.19.5^ISO^FILL-5678^LIS^2.16.840.1.113883.19.7^ISO
This serializes eight components, not two; EIP.1 ends up as ORD-1234 with no assigning authority. The fix is to use & for EI's sub-components and reserve ^ for the boundary between EIP.1 and EIP.2.
FHIR mapping
The HL7 v2-to-FHIR Implementation Guide does not publish a dedicated ConceptMap for EIP. The two EI components individually map per the EI ConceptMap; together they form a pair of Identifier instances that reference the parent resource.
| HL7 v2 | FHIR target | Notes |
|---|---|---|
| EIP.1 Placer Assigned Identifier | Identifier with type.coding.code = PLAC | Populated on the parent reference (e.g. ServiceRequest.basedOn). |
| EIP.2 Filler Assigned Identifier | Identifier with type.coding.code = FILL | Populated alongside EIP.1 as a second Identifier slice. |
In an Orders flow, the EIP becomes two ServiceRequest.identifier entries on the parent reference. In a Results flow (OBR-29), the EIP populates Observation.partOf or DiagnosticReport.basedOn with the parent reference resolved through either identifier.
Engine considerations
- Delimiter discipline — the sub-component / component split is the single biggest source of EIP bugs in the wild. Engines must split EIP on
^first, then split each EI on&. A flat split on either delimiter alone corrupts the data. - Assigning authority preservation — EI.2 (namespace ID), EI.3 (universal ID), and EI.4 (universal ID type) must round-trip intact. Dropping them collapses the identifier's uniqueness scope.
- One-sided pairs — engines should warn but not reject when only one of EIP.1 / EIP.2 is populated; receivers that can't join on the populated side will silently drop the parent link otherwise.
- OID-vs-namespace — when EI.3 is an OID and EI.2 is a short namespace name, both should be retained; FHIR consumers prefer the OID, HL7 v2 consumers prefer the namespace name.
- HAPI typing —
ca.uhn.hl7v2.model.v281.datatype.EIPexposesgetEip1_PlacerAssignedIdentifier()andgetEip2_FillerAssignedIdentifier(), both returningEIinstances with the four sub-component accessors.
How Vorro parses and produces EIP
On inbound, Vorro parses EIP composites strictly: split on ^ for the pair, split each EI on & for the four sub-components, and validate EI.4 against the HL70301 universal-ID-type table (ISO, GUID, UUID, etc.). When only one side of the pair is populated, Vorro keeps the message but emits a structured warning so downstream joins can choose whether to attempt a lookup.
On outbound, Vorro emits EIP only when both sides are known. If a source carries only a placer identifier, Vorro resolves the filler identifier from the order's lifecycle history before emitting; if the filler cannot be resolved, we emit EIP with EIP.2 empty rather than fabricating a filler number. We never collapse EIP's sub-components into the component delimiter — the & / ^ distinction is preserved byte-for-byte.
