HL7 XPN Data Type: Extended Person Name

The XPN (Extended Person Name) data type was introduced in HL7 v2.3 to replace the older flat PN type. It carries a fully structured person name — family name with its own surname-prefix and own-surname components, given name, middle name(s) or initials, suffix and prefix, name type (legal, alias, maiden, display, etc.), representation code for ideographic/phonetic variants, and a validity period so historical names can travel alongside current ones. Its flagship fields are PID-5 Patient Name and NK1-2 Next of Kin Name.

Purpose

XPN exists so a person's name can be exchanged without losing structure or provenance. A single patient can have multiple names — a legal name, a maiden name from before marriage, a preferred display name, an alias used for safety reasons — and XPN encodes all of them with explicit type codes and effective/expiration dates. The structured family-name sub-type (FN) further decomposes the surname so surname prefixes ("van der"), own surname, and own-surname prefixes survive round-tripping between systems that handle surnames differently.

Component table

Source: HAPI HL7v2 v2.8.1 javadocs (XPN). Lengths are no longer published as fixed maxima in v2.8.1 (—); Required and Table # are taken from the HL7 v2 standard where well-established. XPN has 14 components in v2.7+.

Most-used components

• XPN.1 Family Name — the surname, itself an FN composite so "van der Berg" survives intact.
• XPN.2 Given Name — first name.
• XPN.3 Second And Further Given Names — middle name(s) or initials. Multiple middles are space-separated, not caret-separated.
• XPN.7 Name Type Code (HL70200) — L legal, A alias, M maiden, D display, B birth, N nickname, S coded pseudo-name. Without it, downstream consumers cannot tell which name to display vs. which to match on.
• XPN.5 Prefix and XPN.4 Suffix — "Dr." and "Jr."; render only, never used for matching.
• XPN.14 Professional Suffix — the post-v2.5 home for "MD", "PhD"; replaces the withdrawn XPN.6.

Where it's used

XPN is the canonical person-name carrier across the v2 standard. The most common occurrences:

• PID-5 Patient Name — repeating; legal name then any aliases / maiden / display variants.
• PID-9 Mother's Maiden Name — repeating XPN, often used for identity matching.
• NK1-2 Next of Kin Name — repeating.
• PV1-7 Attending Doctor — though typically XCN, XPN is embedded.
• PV1-8 Referring Doctor and PV1-9 Consulting Doctor — same pattern.
• GT1-3 Guarantor Name — repeating XPN.
• IN1-16 Name of Insured — repeating.
• DON-16 Intended Recipient Name and DON-20 Intended Recipient Ordering Provider.
• IN2-2 Insured's Employee Name and IN2-67 Insured's Family Member's Name.

Version differences

• v2.3 — XPN introduced with components .1 through .8, replacing the flat PN type.
• v2.4 — Component .9 Name Context (CWE) and .10 Name Validity Range (DR) added.
• v2.5 — Major rework. Component .6 Degree (IS) and .10 Name Validity Range (DR) withdrawn. Components .11 Name Assembly Order, .12 Effective Date, .13 Expiration Date, and .14 Professional Suffix added. Lifecycle dates now live in dedicated DTM fields instead of a DR range.
• v2.6 — XPN.1 Family Name became the structured FN composite (own surname, surname prefix, own-surname prefix, own-surname-prefix-from-partner).
• v2.7 / v2.8 / v2.8.1 — No further structural changes. The v2.8.1 javadoc confirms the 14-component layout as documented above.

Common mistakes

• Putting a comma-separated full name in XPN.1. "Smith, John Q" in the family-name component breaks every consumer that expects FN structure. Use Smith^John^Q.
• Omitting XPN.7 Name Type Code. Without L vs. A vs. M, downstream systems cannot tell the legal name from an alias or maiden name and may match on the wrong one.
• Using ^ inside the family name without escaping. A hyphenated surname like "Smith-Jones" is fine, but an embedded caret (rare but possible in transliteration) must be escaped as S.
• Populating the withdrawn XPN.6 Degree on v2.5+ messages. Some legacy bridges still emit ^^^^^MD in component 6. Move it to XPN.14.
• Using XPN.10 Name Validity Range on v2.5+ messages. The DR component is withdrawn; populate XPN.12 / XPN.13 instead.
• Cramming multiple middles into XPN.3 with carets. Middle names are space-separated within XPN.3, not component-delimited.
• Sending only XPN.1 for "Cher" / "Madonna" mononyms. Per HL7 guidance, populate XPN.1 (family) with the mononym and set XPN.7 to S (coded pseudo-name) so consumers know there is no given name to expect.

Examples

Minimal value

Smith^John

Multi-component populated

Smith^John^Quentin^Jr^Dr^^L^^^^^G

Smith family, John given, Quentin middle, Jr suffix, Dr prefix, L legal name, G given-first assembly.

Fully populated edge case with effective dates and professional suffix

van der Berg&Berg&van der^Maria^Elena Sofia^^Dr^^L^A^^^G^20100614^^MD

Structured family name with surname prefix van der, given Maria, middles Elena Sofia, prefix Dr, legal name with alphabetic representation, effective date 2010-06-14, professional suffix MD.

Maiden name carried as an XPN repetition

Berg^Maria^Elena Sofia^^^^M^^^^^^20100614

M Name Type Code marks it as the maiden name; XPN.13 carries the date the maiden name expired (the marriage date).

In-context excerpt — PID-5 with legal + maiden repetition

PID|1||MR884412^^^MERCY^MR||van der Berg&Berg&van der^Maria^Elena Sofia^^Dr^^L~Berg^Maria^Elena Sofia^^^^M||19720508|F

Common pitfall — comma-separated full name

PID|1||MR884412^^^MERCY^MR||Smith, John Q^^^^^^L||19720508|F

The receiver parses Smith, John Q as a single family name; the given name is empty. Correct form is Smith^John^Q^^^^L.

FHIR mapping

The v2-to-FHIR Implementation Guide publishes a ConceptMap from XPN to HumanName and a secondary map to plain string for fields that only need a rendered display name.

• ConceptMap: datatype-xpn-to-humanname
• ConceptMap: datatype-xpn-to-string

Engine considerations

• Repetition order matters. PID-5 carries the legal name first, then aliases / maiden / display. Engines that re-sort repetitions silently change which name is "primary" for downstream systems.
• FN sub-components. XPN.1 is itself a composite; engines that flatten XPN.1 to a single string lose the surname-prefix structure. Preserve &-delimited sub-components verbatim.
• HAPI accessor. HAPI v2.8.1 exposes XPN as ca.uhn.hl7v2.model.v281.datatype.XPN with typed getters (getFamilyName(), getGivenName(), getNameTypeCode()); repetitions on PID-5 are accessed through Pid.getPatientName() which returns XPN[].
• Escape rules. Apostrophes and hyphens in names are safe, but ^, ~, ``, &, and | inside any XPN component must be escaped using the standard HL7 escape sequences.
• Name type defaulting. If XPN.7 is missing, most engines default to L legal, but this is implementation-defined; do not rely on it.

How Vorro parses and produces XPN

Vorro's HL7 parser deserializes every XPN into a typed PersonName object that preserves the FN sub-structure of XPN.1 (own surname, surname prefix, own-surname prefix) and the full set of XPN.2–XPN.14 components. XPN.7 Name Type Code is normalized against HL70200; missing values are tagged as "unspecified" rather than silently defaulted to legal, because mis-defaulting maiden or alias names produces real downstream matching errors. PID-5 repetitions are preserved in their inbound order so the legal-name-first convention round-trips.

On outbound, Vorro emits the legal name as the first XPN repetition and any maiden / alias / display variants as subsequent repetitions, each with an explicit XPN.7 code. Professional credentials are always emitted in XPN.14, never the withdrawn XPN.6, and lifecycle dates use XPN.12 / XPN.13 rather than the withdrawn XPN.10.

Related pages

• XAD data type — Extended Address
• XTN data type — Extended Telecommunication Number
• FN data type — Family Name
• PID segment — Patient Identification
• NK1 segment — Next of Kin

Sources

• HAPI HL7v2 v2.8.1 javadoc — XPN data type
• HAPI HL7v2 v2.8.1 apidocs index
• HL7 v2 product brief
• v2-to-FHIR ConceptMap: XPN → HumanName
• v2-to-FHIR ConceptMap: XPN → string