HL7 CX Data Type: Extended Composite ID with Check Digit

The CX (Extended Composite ID with Check Digit) data type was introduced in HL7 v2.3, replacing the older CK data type, and is the flagship identifier carrier in HL7 v2. It is the data type of PID-3 Patient Identifier List — the field that carries every MRN, SSN, driver's license, and external person-identifier known about a patient — and it appears wherever a person-level or account-level identifier needs to be transmitted with its full provenance: check digit, assigning authority, identifier type, assigning facility, and lifecycle dates.

Purpose

CX exists to make identifiers reconcilable across organizations. A bare "884412" is meaningless; "884412^^^MERCY^MR" tells a receiver this is a Medical Record Number issued by Mercy Health, which can be matched against Mercy's namespace and routed differently from a Social Security Number or a driver's license. The data type evolved substantially between v2.3 (five components) and v2.7+ (ten or more components) to accommodate cross-jurisdiction patient matching, assigning-agency provenance, and identifier reliability metadata required by modern enterprise master person index (EMPI) workflows.

Component table

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

Comp	Name	Sub-type	Length	Required	Description
CX.1	ID Number	st	—	R	The identifier value itself, e.g. an MRN or SSN.
CX.2	Identifier Check Digit	st	—	O	Check digit computed against CX.1 using the algorithm named in CX.3.
CX.3	Check Digit Scheme	id	—	C	Algorithm used to compute CX.2. Drawn from HL7 table [HL70061] (e.g. `M10`, `M11`, `ISO`, `NPI`). Conditional with CX.2.
CX.4	Assigning Authority	hd	—	O	Hierarchic Designator naming the system that issued CX.1. Itself a composite (namespace + universal ID + type).
CX.5	Identifier Type Code	id	—	R	Coded identifier type from HL7 table [HL70203] — `MR` (MRN), `SS` (SSN), `DL` (driver's license), `PI` (patient internal), `NI` (national identifier), etc.
CX.6	Assigning Facility	hd	—	O	Facility-level scope for CX.1; complements CX.4 when the issuing system spans multiple facilities.
CX.7	Effective Date	dt	—	O	Date the identifier became valid for this person.
CX.8	Expiration Date	dt	—	O	Date the identifier ceased to be valid (e.g. after a merge or reassignment).
CX.9	Assigning Jurisdiction	cwe	—	O	Governmental jurisdiction issuing the identifier (driver's license state, passport country).
CX.10	Assigning Agency or Department	cwe	—	O	Agency or department within the jurisdiction (DMV, immigration).
CX.11	Security Check	st	—	O	Security-grade check value (v2.8+) for tamper detection.
CX.12	Security Check Scheme	id	—	C	Algorithm naming the scheme used for CX.11 (v2.8+).

Most-used components

CX.1 ID Number — the value users read and downstream systems index.
CX.4 Assigning Authority — the HD-composite that names the issuing system; the most important cross-organization disambiguator.
CX.5 Identifier Type Code — names the kind of identifier (MRN vs SSN vs DL); without it the receiver cannot route or match correctly.
CX.6 Assigning Facility — narrows scope below the assigning authority for multi-facility systems.

Where it's used

PID-3 Patient Identifier List — the canonical CX field; repeats once per identifier known about the patient.
PID-4 Alternate Patient ID — legacy alternate identifier slot (deprecated in modern profiles in favour of additional PID-3 repetitions).
PID-19 SSN Number — Social Security Number expressed as CX.
PID-20 Driver's License Number — DL with assigning jurisdiction in CX.9.
GT1-2 Guarantor Number — guarantor identifier.
NK1-33 Next of Kin Identifiers — identifiers for next-of-kin persons.
IN1-49 Insured's ID Number — insurance-card identifier.
PV1-19 Visit Number — encounter identifier in modern v2.7+ profiles (legacy profiles used CX or NM here).
MRG-1 Prior Patient Identifier List — prior identifiers in a patient-merge event.
PRT-10 Participation Person Identifier — participating person's ID in v2.7+.

Version differences

HL7 v2.3 — CX introduced with five components: ID Number, Check Digit, Check Digit Scheme, Assigning Authority (HD), Identifier Type Code. Replaced the legacy CK data type.
HL7 v2.4 — added Assigning Facility (CX.6).
HL7 v2.5 / v2.5.1 — added Effective Date (CX.7) and Expiration Date (CX.8) to record identifier lifecycle.
HL7 v2.6 — added Assigning Jurisdiction (CX.9) and Assigning Agency or Department (CX.10).
HL7 v2.7 — strengthened semantics of CX.5 Identifier Type Code and clarified Assigning Authority as the primary cross-organizational anchor.
HL7 v2.8 / v2.8.1 — added Security Check (CX.11) and Security Check Scheme (CX.12) to support tamper-evident identifier transmission. HAPI v2.8.1 javadoc reflects the twelve-component layout.

Common mistakes

Omitting CX.4 Assigning Authority — without it, cross-domain identifier reconciliation is impossible because MRN "884412" at Mercy is unrelated to MRN "884412" at St. Jude.
Putting MR (the type) into CX.1 instead of CX.5 — CX.1 carries the value, CX.5 carries the kind. Receivers will index MR884412 as the identifier and fail to match.
Populating CX.2 (check digit) without CX.3 (check-digit scheme) — the check digit cannot be validated and most engines reject the message.
Conflating CX.4 Assigning Authority with CX.6 Assigning Facility — Assigning Authority names the system (e.g. "MERCY EHR"), Assigning Facility names the physical site (e.g. "MERCY-DOWNTOWN"). They may differ for multi-site deployments.
Sending a free-text string in CX.5 instead of a code from HL70203 — values like "MedicalRecordNumber" are not valid where MR is required.

Examples

Minimal value (ID + type code, the absolute minimum for a usable identifier):

MR884412

Four-component value (assigning authority + identifier type code):

MR884412^^^MERCY^MR

Fully populated CX (assigning authority HD, identifier type code, effective and expiration dates):

MR884412^4^M10^MERCY&2.16.840.1.113883.19.5&ISO^MR^MERCY-DOWNTOWN&2.16.840.1.113883.19.5.10&ISO^20180312^99991231

Note the embedded HD inside CX.4 — MERCY&2.16.840.1.113883.19.5&ISO — separated by & because HD lives one delimiter level deeper than CX.

In context — PID-3 Patient Identifier List carrying multiple identifiers (~ repetition separator):

MSH|^~&|ADT|MERCY^2.16.840.1.113883.19.5^ISO|EHR|MERCY|20260610105500||ADT^A08^ADT_A01|MSG00171|P|2.8.1
EVN|A08|20260610105500
PID|1||MR884412^^^MERCY&2.16.840.1.113883.19.5&ISO^MR~123-45-6789^^^USA&2.16.840.1.113883.4.1&ISO^SS~D-9911223^^^OH-DMV^DL^^20210101^20290101|TESTPATIENT^ALEX^Q||19720508|F

Common pitfall — type code stuffed into the value:

PID|1||MR884412

The identifier appears to be the string MR884412 in an unknown namespace with no type — downstream EMPI matching cannot resolve it because the actual MRN is 884412 and the MR belongs in CX.5.

FHIR mapping

The v2-to-FHIR IG publishes a CX ConceptMap at ConceptMap-datatype-cx-to-identifier, plus context-specific variants:

ConceptMap-datatype-cx-mother-to-relatedperson — when CX surfaces in NK1 / GT1 contexts.
ConceptMap-datatype-cx-to-string — flattened form for profiles that require a single display string.

Default Identifier mapping:

CX component	FHIR element	Notes
CX.1	`Identifier.value`	The raw ID value.
CX.4 (HD)	`Identifier.system`	Universal ID from HD typically wrapped as `urn:oid:` / `urn:uuid:`.
CX.4.1 Namespace	`Identifier.assigner.identifier.value`	Local namespace name.
CX.5	`Identifier.type` (CodeableConcept)	Mapped from HL70203 to FHIR `v2-0203` ValueSet.
CX.6	`Identifier.assigner` (Reference to Organization)	Assigning facility resolves to an `Organization` resource.
CX.7	`Identifier.period.start`	Effective date.
CX.8	`Identifier.period.end`	Expiration date.
CX.9	extension `identifier-jurisdiction`	Jurisdictional issuer.

HD-inside-CX.4 is the same building block used inside EI.4 — its FHIR target depends entirely on context.

Engine considerations

CX.4 is an HD — a composite inside a composite, separated by & (the sub-component delimiter). Many engines mishandle this and flatten the HD into a single string, losing universal-ID and type metadata. Always parse CX.4 as HD before reading.
Repetition vs. component confusion: PID-3 repeats CXs with ~; within each CX, components use ^ and sub-components use &. Engines must respect all three delimiters.
Check-digit validation: engines that re-validate CX.2 against CX.1+CX.3 must implement the scheme named in CX.3 (M10, M11, etc.) — silently accepting invalid check digits hides upstream corruption.
Identifier Type Code is the routing key: many EMPI and HIE engines route on CX.5 to decide whether to treat an identifier as an MRN, SSN, or external ID. Missing CX.5 forces fallback behavior that is rarely correct.
HAPI HL7v2 v2.8.1 generates ca.uhn.hl7v2.model.v281.datatype.CX with strongly-typed accessors; CX.4 returns an HD instance, not a String.

How Vorro parses and produces CX

Vorro treats CX as a typed Identifier object with an embedded HD assigner. On inbound, every CX is decomposed into (value, type-code, assigning-authority, assigning-facility, period), with CX.4 fully parsed into its HD components. CX.5 is validated against HL70203 and the type code drives routing decisions downstream (MRN → EMPI; SSN → de-identification pipeline; DL → identity-proofing flow).

On outbound, Vorro always emits CX.4 as a fully populated HD (namespace + universal ID + type) for cross-organization messages, always populates CX.5 from the curated identifier-type registry, and never emits CX.2 without CX.3. For acquired-facility integrations where the source could not supply an OID, Vorro auto-assigns a transient pseudo-OID under a configured root and tags the message with provenance so receivers can distinguish curated from imputed authority data.

Sources

← Back to HL7 v2 Guide