HL7 CE Data Type: Coded Element

The CE (Coded Element) data type was introduced in HL7 v2.1 as the first composite for transmitting a coded value together with its display text and coding system. It carries a primary identifier triplet (code, text, system) and an optional alternate triplet, allowing a sender to transmit both the local code and a standard equivalent. CE was widely used through v2.4 in fields like PID-10 Race, OBX-3 Observation Identifier, DG1-3 Diagnosis Code, and OBR-4 Universal Service Identifier before it was deprecated in v2.5 and replaced by CWE and CNE.

Purpose

CE was designed for the simple case: "here is a code, and optionally an equivalent code from a different vocabulary." It is unconstrained — there is no formal contract about whether the code must come from a stated value set, and no version, OID, or Original Text components. Because of those limitations CE was split in v2.5 into two stricter successors:

• CWE — Coded With Exceptions permits local extensions and unmapped codes (the common real-world case).
• CNE — Coded No Exceptions requires that values come from a stated HL7 or external vocabulary.

CE is retained in many production interfaces because legacy ADT, ORM, and ORU profiles still reference it, and because re-profiling thousands of downstream consumers to CWE is rarely worth the disruption. HAPI HL7v2 v2.8.1 no longer publishes a CE Java class under ca.uhn.hl7v2.model.v281.datatype — CE was removed from the v2.7+ structure libraries — but messages declaring 2.4 or earlier in MSH-12 continue to parse CE through the version-specific structure packages (...model.v24.datatype.CE).

Component reference

CE carries six components, separated by the component delimiter ^. The structure has been stable since v2.3.

The primary triplet is CE.1 / CE.2 / CE.3. The alternate triplet is CE.4 / CE.5 / CE.6 and is typically used to carry a local code alongside a standard one (or vice versa).

Most-used components

• CE.1 Identifier — the code itself; the only component every consumer reads.
• CE.3 Name of Coding System — without it, CE.1 is ambiguous. 2376 means very different things in ICD-9 vs SNOMED CT vs an internal table.
• CE.2 Text — display text for logging and human-readable views; never authoritative.
• CE.4 / CE.5 / CE.6 — the alternate triplet, used when both a standard and a local code travel together.

Where it's used

In v2.3 / v2.4 (the high-water mark for CE) and in legacy v2.5+ interfaces that retained CE for backward compatibility:

• PID-10 Race
• PID-22 Ethnic Group
• PID-26 Citizenship
• PID-28 Nationality
• OBX-3 Observation Identifier
• OBR-4 Universal Service Identifier
• DG1-3 Diagnosis Code
• PR1-4 Procedure Code
• AL1-3 Allergen Code / Mnemonic / Description
• IN1-35 Company Plan Code
• ORC-16 Order Control Code Reason
• RXA-9 Administration Notes

From v2.5 onward HL7 re-typed many of these fields to CWE; the ones that retained a strict vocabulary contract (e.g. units of measure) became CNE.

Version differences

• v2.1 — CE introduced with components CE.1–CE.6.
• v2.2 / v2.3 / v2.3.1 / v2.4 — CE stable. Treated as the default coded composite across the standard.
• v2.5 — CE deprecated. Most fields re-typed to CWE; strict-vocabulary fields re-typed to CNE. CE retained for backward compatibility in older message structures.
• v2.6 / v2.7 / v2.7.1 / v2.8 / v2.8.1 — CE remains in the HL7 standard as a deprecated type but is not present in the HAPI v2.7+ structure packages. Messages declaring v2.5 or later that still send CE must do so via a custom profile or via the CWE composite instead.

Common mistakes

• Sending CE in a v2.5+ message where the receiving profile now requires CWE — receiving engines either reject the message or silently coerce it, losing the alternate triplet.
• Leaving CE.3 (Name of Coding System) empty. A bare identifier like M or 2376 has no meaning without its system; downstream lookup is impossible.
• Putting display text in CE.1 — e.g. Male^^HL70001 instead of M^Male^HL70001. Subsequent equality checks against the code table fail.
• Using a local code in CE.1 but populating CE.3 with the name of a standard system. The code-to-system pair is then internally inconsistent.
• Reversing the primary and alternate triplets — putting the standard code in CE.4–CE.6 and the local code in CE.1–CE.3 — when the receiving profile expects the standard code first.
• Treating CE as repeating. CE is a composite, not a repeating field; multiple coded values require the field to be marked repeating (~ delimiter), not multiple component sets.
• Continuing to emit CE from new interfaces in 2026 rather than upgrading the profile to CWE — every modern HAPI, Mirth, Cloverleaf, and Rhapsody schema for v2.7+ assumes CWE.

Examples

Minimal — just the code (legal but ambiguous):

M

Three-component value — code + display + coding system (the recommended minimum):

M^Male^HL70001

Six-component value with an alternate triplet:

M^Male^HL70001^MALE^Male^MERCYLOCAL

Diagnosis code with ICD-10 in the primary triplet and a local mapping in the alternate:

J45.909^Unspecified asthma, uncomplicated^I10^ASTH^Asthma^MERCYDX

In context — PID-10 Race in a v2.4 ADT^A04 message:

MSH|^~&|ADT|MERCY|EHR|MERCY|20260610091500||ADT^A04|MSG00051|P|2.4
EVN|A04|20260610091500
PID|1||MR884412^^^MERCY^MR||TESTPATIENT^ALEX^Q||19720508|F|||123 MAIN ST^^TAMPA^FL^33602||(813)555-0142|||S||AC993321|||2106-3^White^HL70005

In context — OBX-3 Observation Identifier carrying a LOINC code under CE:

OBX|1|NM|2345-7^Glucose [Mass/volume] in Serum or Plasma^LN||118|mg/dL|70-99|H|||F

Common pitfall — CE.1 populated but CE.3 omitted (ambiguous, do not send):

2106-3^White

Common pitfall — display text smuggled into CE.1:

White^^HL70005

FHIR mapping

The HL7 v2-to-FHIR Implementation Guide publishes a ConceptMap for CE:

• ConceptMap-datatype-ce-to-codeableconcept

Component-level mapping into CodeableConcept:

CE has no Original Text component, so CodeableConcept.text is typically derived from CE.2 when no alternate triplet is present. This is one of the practical reasons HL7 introduced CWE.9 Original Text in v2.5.

Engine considerations

• HAPI HL7v2 v2.7+ structure packages do not contain a CE class. Engines that need to parse CE inside a v2.5+ envelope either downgrade the structure version, register a custom datatype, or coerce CE into CWE at the message-parsing layer.
• Routing engines (Mirth Connect, Cloverleaf, Rhapsody, Iguana) typically expose CE as positional components regardless of version. The interface engineer's job is to validate that CE.3 / CE.6 are present whenever CE.1 / CE.4 are populated.
• When an inbound CE arrives without CE.3, vocabulary normalization has nothing to anchor against. Engines should refuse silent "best guess" lookups and instead route the value to a curation queue.
• Translating CE → FHIR CodeableConcept loses no fidelity; translating CWE → CE drops Original Text, OIDs, and the second alternate triplet, so engines should never silently down-cast.
• Engines that retain raw segment text (Vorro does this) can round-trip CE losslessly even when the canonical internal representation is CWE.

How Vorro parses and produces CE

Vorro treats CE as an inbound legacy form and a deliberate outbound choice. On inbound:

• The version declared in MSH-12 controls whether the parser instantiates CE or CWE. Mixed-version traffic into a single channel is parsed against the message-declared version, not the channel's preferred version.
• CE.3 is required for the value to enter Vorro's normalized terminology layer. Bare CE.1 values without a system land in a curation queue with the original raw segment preserved.
• The alternate triplet is preserved as a second Coding entry inside our internal CodeableConcept, not collapsed.

On outbound, Vorro emits CE only when the destination profile explicitly demands a v2.4-or-earlier message. New interfaces are negotiated with CWE; CE outbound is a configurable downgrade with a warning logged on every send so operators can chase the upgrade path.

Related pages

• CWE data type — Coded With Exceptions
• CNE data type — Coded No Exceptions
• CF data type — Coded Element with Formatted Values

Sources

• HAPI HL7v2 v2.8.1 javadoc — CWE datatype (CE successor)
• HAPI HL7v2 v2.8.1 apidocs index
• HL7 v2 product brief
• HL7 v2-to-FHIR IG — ConceptMap CE to CodeableConcept