HL7 EI Entity Identifier
HL7 datatype components EI components from HL7 v2.5.1 Hide components
These are the generated components for the version selected at the top of the page. The article stays practical, and this panel follows the chosen HL7 version.
Components
EI is the HL7 v2 datatype for an entity identifier. In plain interface work, that usually means "the actual ID plus enough authority information to know whose ID it is." The value might be an order number, appointment ID, document ID, specimen/container ID, equipment ID, accession number, referral ID, or some other stable key that another system will need later.
The first component is the identifier itself. The other three components describe the assigning authority, using the same ideas as HD. That second part is what saves you when two systems both create 123456, or when the same order exists as a placer number in one system and a filler number in another.
The most expensive EI mistake is sending a naked number and hoping context will rescue it. Context works until a merger, migration, multi-facility rollout, external lab feed, document replacement, or historical query asks you to match identifiers across boundaries. Then the missing authority becomes real work.
This example says the visible order identifier is ORD-784512, the local namespace is EHR, and the universal assigning authority is an ISO object identifier. Many local feeds only populate EI-1 and EI-2. That can be acceptable inside one well-governed interface, but it is weaker once identifiers cross organizational lines.
EI-1: Entity Identifier
EI-1 is the actual identifier value. It should be the durable key from the system that created the thing, not a display label, not a row number from a report, and not a value that changes when the user edits a screen description.
In order workflows, EI-1 is the order number portion of fields such as ORC-2 Placer Order Number, ORC-3 Filler Order Number, OBR-2 Placer Order Number, and OBR-3 Filler Order Number. In document workflows, it is the durable document number in fields such as TXA-12 Unique Document Number. In container and specimen workflows, it often identifies accession, container, tray, or carrier entities.
Keep EI-1 boring. Do not pack the assigning authority, date, status, or display description into it unless that is genuinely part of the source identifier. If a legacy source hands you a free-text identifier containing HL7 delimiters, fix the source mapping if you can. If the delimiter is truly part of the preserved value, encoded writes or HL7Encode() keep the message syntactically valid, but escaping is not the same as having a clean identifier policy.
EI-2 to EI-4: Namespace ID, Universal ID, and Universal ID Type
EI-2, EI-3, and EI-4 identify the assigning authority. EI-2 is the local namespace ID. EI-3 is the universal ID, and EI-4 tells you what kind of universal ID it is, such as an OID, UUID, DNS name, or another allowed universal ID type.
Treat these as the ownership part of the identifier. ORD-784512^EHR and ORD-784512^LAB are different identifiers even though EI-1 is the same. The receiving system should not have to guess whether a value came from the EHR, LIS, RIS, document repository, scheduling system, analyzer, or external partner.
If you populate EI-4, populate EI-3 too. A universal ID type without the universal ID is just a label floating in space. If you have both a local namespace and a universal authority, send both when the profile allows it. The local value helps humans and local routing; the universal value helps cross-enterprise uniqueness.
Where EI Shows Up Most
EI is everywhere identities need to be tracked over time. Orders use it for placer and filler numbers in ORC and OBR. Scheduling uses it for appointment and group identifiers. Document workflows use it in TXA. Specimen and container workflows use it directly or through EIP in SPM and container-related segments. Equipment and imaging feeds use it for device, accession, requested procedure, study, and scheduled step identifiers.
That spread is the point: EI is less about one field and more about the habit of carrying identifiers with their authority. Once a downstream workflow needs to cancel, replace, merge, query, amend, bill, or reconcile something, weak identifiers become expensive.
Placer, Filler, and Parent Identifiers
Do not collapse placer and filler identifiers just because they look similar. The placer number belongs to the system that requested the service. The filler number belongs to the system that performed or fulfilled it. In a lab order, those are often the EHR and LIS. In radiology, they may be the ordering system and RIS/PACS ecosystem.
Parent-child relationships need the same discipline. A replacement document, addendum, reflex order, child specimen, related timing request, or scheduled follow-up may point back to another EI. Use the complete identifier, including authority, or the relationship will only work while the receiver remembers enough context to guess correctly.
Practical Implementation Advice
Before mapping an EI, write down three things: who minted the identifier, whether it is stable for the life of the entity, and what other systems may need to match it later. That answer usually tells you what belongs in EI-2 through EI-4.
For Integration Soup transformations, build EI values from explicit source fields and agreed authority constants or lookup tables. Helpers such as Default() are useful for harmless display fallbacks in some mappings, but they are dangerous for EI authority. A defaulted assigning authority can make bad data look authoritative, which is worse than letting the error surface.
If the source does not provide an authority, do not silently invent one in the message without an interface agreement. Choose a local namespace deliberately, document it, and keep it stable. Identifier authority changes are migrations, not formatting tweaks.
HL7 Soup Web is useful for checking EI values because the interpretation view can jump from the readable explanation to the exact order, document, specimen, or appointment identifier in the raw message. For universal ID type and namespace pieces, it helps show whether the assigning authority is present or whether the message is only carrying a naked number.
EI versus CX and HD
CX is for identifiers such as patient IDs that also need check digit, identifier type, assigning facility, jurisdiction, and agency detail. EI is smaller and more general: an entity identifier plus assigning authority. HD is the assigning authority structure itself, and EI spreads that HD authority across EI-2, EI-3, and EI-4 for compatibility with older field layouts.
When the field datatype is EI, resist the urge to borrow CX behavior by stuffing identifier type or facility details into EI-1. Put the ID in EI-1 and the authority in EI-2 through EI-4. If the workflow needs more metadata, look for the companion field or profile rule that carries it.
Official Description and References
The HL7 v2+ EI logical model describes EI as appropriate for machine or software generated identifiers. It places the generated identifier in the first component, while components 2 through 4 identify the assigning authority responsible for generating that identifier. It also notes that those assigning authority components are equivalent to the HD datatype, but split into separate EI components for backward compatibility.
For formal reference, compare the generated component panel above with the HL7 v2+ EI logical model and the HL7 v2+ HD logical model.
Related Datatypes and Segments
For nearby datatype work, look at HD for assigning authorities, CX for patient-style identifiers, EIP for entity identifier pairs, and PL where location identifiers use EI inside the location. For common segment uses, start with ORC-2, ORC-3, OBR-2, OBR-3, TXA-12, SCH, SPM, and SAC.