HL7 XCN Data Type: Extended Composite ID Number and Name for Persons

The XCN (Extended Composite ID Number and Name for Persons) data type was introduced in HL7 v2.3 as the successor to the older CN type. It pairs a person's identifier (NPI, DEA, internal provider ID, license number) with a structured name — family, given, middle, suffix, prefix, professional suffix — plus the assigning authority and identifier type that disambiguate the ID across networks. It is the type of every provider-bearing field in HL7 v2: PV1-7 Attending Doctor, OBR-16 Ordering Provider, ORC-12 Ordering Provider, and dozens of others.

Purpose

XCN exists so that a person reference — almost always a practitioner — can be exchanged with both a stable identifier and a human-readable name in a single field. The identifier (XCN.1) plus assigning authority (XCN.9) and type code (XCN.13) gives a receiving system enough to look the practitioner up in its directory; the name components (XCN.2 through XCN.6, plus XCN.21 professional suffix) give clinicians something readable when the directory lookup fails or the receiver has no directory. XCN differs from XPN (which carries only a name) by bundling the identifier with the name.

Components

Source: HAPI HL7v2 v2.8.1 javadoc (XCN). Length is not published in v2.8.1 javadocs (—).

Most-used components

• XCN.1 Person Identifier — the practitioner's directory key (NPI, internal staff ID); the one component that drives downstream resolution.
• XCN.2 Family Name (FN) — structured surname; sub-typed as FN so compound surnames stay parseable.
• XCN.3 Given Name — first name.
• XCN.4 Second and Further Given Names — middle name or initial.
• XCN.9 Assigning Authority — namespace + OID for XCN.1; mandatory in cross-network messages.
• XCN.13 Identifier Type Code — categorizes XCN.1 (NPI vs DEA vs internal), so the receiver knows which registry to query.

Where it's used

• PV1-7 Attending Doctor, PV1-8 Referring Doctor, PV1-9 Consulting Doctor, PV1-17 Admitting Doctor — the primary patient-visit roles.
• ORC-12 Ordering Provider — the ordering clinician on every order.
• OBR-16 Ordering Provider — the ordering clinician on every diagnostic request.
• OBR-28 Result Copies To and OBR-32 Principal Result Interpreter.
• DON-32 Donation Accept Staff and DON-33 Donation Material Review Staff.
• DON-23 Bleed Start Phlebotomist and DON-24 Bleed End Phlebotomist (also seen as XCN in some profiles, XPN in others).
• NK1-30 Contact Person Identifier — the next-of-kin's identifier.
• IN1-50 Insured's Administrative Sex's-provider references and PRT-5 Participation Person.
• OBX-16 Responsible Observer.

XCN repeats in most of these fields (one patient can have several attending physicians over a stay), so receivers must handle multiple XCN occurrences separated by ~.

Version differences

• v2.3 — XCN introduced, replacing CN. Initial 14 components.
• v2.5 — XCN.7 Degree withdrawn in favor of new XCN.21 Professional Suffix. XCN.18 Name Assembly Order, XCN.19 Effective Date, XCN.20 Expiration Date added. XCN.2 retyped to use FN (Family Name) instead of ST so compound surnames can be structured.
• v2.6 — XCN.16 Name Context and XCN.17 Name Validity Range refined.
• v2.7 — Major expansion: XCN.22 Assigning Jurisdiction, XCN.23 Assigning Agency or Department, XCN.24 Security Check, XCN.25 Security Check Scheme added. XCN.17 Name Validity Range withdrawn (use XCN.19/XCN.20). XCN.8 widened from IS to CWE.
• v2.8 / v2.8.1 — no structural changes; HAPI v2.8.1 javadoc shows the same 25 components.

Common mistakes

• Packing the full name into XCN.1. XCN.1 is the identifier, not a name. Senders new to HL7 sometimes emit 99812^Dr. Jane Smith MD with the name in XCN.1; the correct form puts the ID in XCN.1 and the name parts in XCN.2 through XCN.6 + XCN.21.
• Using XPN where XCN is required. XPN carries only a name; XCN carries name and identifier. Substituting XPN drops the identifier silently — receivers can no longer resolve the practitioner.
• Omitting XCN.9 Assigning Authority on cross-network messages. Without the namespace and OID, the same 99812 can refer to two different clinicians at two different facilities.
• Misordering XCN.2 and XCN.3. XCN.2 is the family name, XCN.3 is the given name. Senders that flip them produce records where Dr. Smith is filed as "Jane" and Jane as "Smith".
• Sending degree text in XCN.7 instead of XCN.21. XCN.7 has been withdrawn since v2.5; v2.7+ receivers ignore it. Put "MD" in XCN.21 Professional Suffix.

Examples

Minimal value

99812^SMITH^JANE

Multi-component value

99812^SMITH^JANE^L^^DR^^^MERCY&2.16.840.1.113883.19.5&ISO^L^^^^^^^^^^^^MD

Fully populated value

99812^SMITH^JANE^L^JR^DR^^NPI^MERCY&2.16.840.1.113883.19.5&ISO^L^3^M10^NPI^MERCYFAC&2.16.840.1.113883.19.5.1&ISO^A^^^G^20180601000000-0500^20300531235959-0500^MD^US-MO^MO-BHA^^

Annotated breakdown

99812                                          XCN.1   Person Identifier
^SMITH                                         XCN.2   Family Name (FN; surname only)
^JANE                                          XCN.3   Given Name
^L                                             XCN.4   Second Given (initial)
^JR                                            XCN.5   Suffix
^DR                                            XCN.6   Prefix
^                                              XCN.7   Degree (WITHDRAWN — leave empty)
^NPI                                           XCN.8   Source Table (CWE)
^MERCY&2.16.840.1.113883.19.5&ISO              XCN.9   Assigning Authority (HD)
^L                                             XCN.10  Name Type Code (legal)
^3                                             XCN.11  Identifier Check Digit
^M10                                           XCN.12  Check Digit Scheme
^NPI                                           XCN.13  Identifier Type Code
^MERCYFAC&2.16.840.1.113883.19.5.1&ISO         XCN.14  Assigning Facility (HD)
^A                                             XCN.15  Name Representation Code
^                                              XCN.16  Name Context (CWE)
^                                              XCN.17  Name Validity Range (WITHDRAWN)
^G                                             XCN.18  Name Assembly Order (G=given-first)
^20180601000000-0500                           XCN.19  Effective Date (DTM)
^20300531235959-0500                           XCN.20  Expiration Date (DTM)
^MD                                            XCN.21  Professional Suffix
^US-MO                                         XCN.22  Assigning Jurisdiction (CWE)
^MO-BHA                                        XCN.23  Assigning Agency or Department (CWE)
^                                              XCN.24  Security Check
^                                              XCN.25  Security Check Scheme

In-context excerpt — ORC-12 Ordering Provider on an ORM order

ORC|NW|ORD-7741||GRP-3315|||||||99812^SMITH^JANE^L^^DR^^^MERCY&2.16.840.1.113883.19.5&ISO^L^^^NPI^^^^^^^^MD

In-context excerpt — multiple attending physicians in PV1-7

PV1|1|I|3W^301^A^MERCY||||99812^SMITH^JANE^L^^DR^^^MERCY&2.16.840.1.113883.19.5&ISO^L^^^NPI^^^^^^^^MD~99820^OKONKWO^ADAEZE^N^^DR^^^MERCY&2.16.840.1.113883.19.5&ISO^L^^^NPI^^^^^^^^MD

Two XCN repetitions separated by ~, one per attending physician.

In-context excerpt — OBR-16 with a compound family name

OBR|1|ORD-7742|ACC-9921|11218-5^Microbiology studies^LN||20260610090000|||||||||99834^de la Cruz^Maria^Elena^^DR^^^MERCY&2.16.840.1.113883.19.5&ISO^L^^^NPI^^^^^^^^MD

Note that de la Cruz is placed in XCN.2 as the FN surname; FN structure inside XCN.2 may further split it into FN.2 (de la) and FN.3 (Cruz) where the receiver wants the prefix separated.

Common pitfall snippet

^Dr. Jane Smith MD

The sender left XCN.1 empty and packed the entire display name into XCN.2. Receivers cannot resolve the practitioner because there is no identifier, and the family name is corrupted by the prefix and the professional suffix.

FHIR mapping

The v2-to-FHIR IG publishes five ConceptMaps for XCN:

• XCN → Practitioner — primary mapping for clinician fields.
• XCN → PractitionerRole — used when the field implies a role (attending vs consulting).
• XCN → Patient — degenerate case for some donor/next-of-kin references.
• XCN → RelatedPerson — for NK1 and similar.
• XCN → Annotation — for free-text-only references where structured mapping is impossible.

Engine considerations

• Sub-component & delimiter inside XCN.9 and XCN.14: Both fields are HD, whose three sub-components (namespace, universal ID, universal ID type) use &. Engines that re-tokenize XCN.9 with ^ corrupt the OID.
• FN inside XCN.2: XCN.2 is not a plain string — it is sub-typed as FN. A compound surname like "de la Cruz" can populate FN.1 alone (most common) or FN.2 + FN.3 for structured exchange. Engines that strongly type XCN.2 as ST drop the FN sub-components.
• Repetition: XCN repeats in most provider fields (PV1-7, OBR-28, OBX-16). Engines that flatten a repeating XCN to a single string lose multiple attending doctors.
• Withdrawn components: XCN.7 (since v2.5) and XCN.17 (since v2.7) are still wire-present. v2.7+ producers leave them empty; v2.7+ consumers prefer XCN.21 over XCN.7 and XCN.19/20 over XCN.17, emitting a warning when only the withdrawn slot is populated.
• Identifier-type table conflicts: XCN.8 (HL70297 source table) and XCN.13 (HL70203 identifier type) are commonly conflated by hand-coded senders. Schema validation that constrains each table separately catches this.
• Security Check (XCN.24): v2.7+ — when present, the receiver must validate the check value before trusting XCN.1 in security-sensitive workflows (e.g. e-prescribing).

How Vorro parses and produces XCN

On inbound, Vorro materializes XCN as a Practitioner (or RelatedPerson / Patient per the v2-to-FHIR IG, depending on the field). XCN.1 + XCN.9 + XCN.13 form the canonical identifier triple; we resolve it against an internal directory keyed on (namespace, OID, identifier-type, value). XCN.2 is parsed as FN so compound surnames are preserved in structured form. XCN.7 is read but treated as advisory only — if XCN.21 is empty, Vorro promotes XCN.7's value to XCN.21 internally and logs an upgrade warning.

On outbound, Vorro always emits XCN.1 with a populated identifier (we refuse to send an XCN without one) and always pairs it with XCN.9 + XCN.13. Repeating XCNs are preserved as ordered repetitions. Professional suffix is always emitted in XCN.21, never XCN.7, for v2.5+ destinations.

Related pages

• XPN data type — Extended Person Name
• FN data type — Family Name
• PV1 segment — Patient Visit

Sources

• HAPI HL7v2 v2.8.1 javadoc — XCN
• HAPI HL7v2 v2.8.1 apidocs index
• HL7 v2 product brief
• v2-to-FHIR ConceptMap — XCN to Practitioner
• v2-to-FHIR ConceptMap — XCN to PractitionerRole
• v2-to-FHIR ConceptMap — XCN to Patient
• v2-to-FHIR ConceptMap — XCN to RelatedPerson
• v2-to-FHIR ConceptMap — XCN to Annotation