HL7 XPN Extended Person Name
HL7 datatype components XPN 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
| Pos | Component | Name | Type | Table | Description |
|---|---|---|---|---|---|
| 1 | XPN.1 | Family Name | FN | Family Name; Type FN. | |
| 2 | XPN.2 | Given Name | ST | Given Name; Type ST. | |
| 3 | XPN.3 | Second and Further Given Names or Initials Thereof | ST | Second and Further Given Names or Initials Thereof; Type ST. | |
| 4 | XPN.4 | Suffix (e.g., JR or III) | ST | Suffix (e.g., JR or III); Type ST. | |
| 5 | XPN.5 | Prefix (e.g., DR) | ST | Prefix (e.g., DR); Type ST. | |
| 6 | XPN.6 | Degree (e.g., MD) | IS | 0360 | Degree (e.g., MD); Type IS; HL7 table 0360. |
| 7 | XPN.7 | Name Type Code | ID | 0200 | Name Type Code; Type ID; HL7 table 0200. |
| 8 | XPN.8 | Name Representation Code | ID | 0465 | Name Representation Code; Type ID; HL7 table 0465. |
| 9 | XPN.9 | Name Context | CE | 0448 | Name Context; Type CE; HL7 table 0448. |
| 10 | XPN.10 | Name Validity Range | DR | Name Validity Range; Type DR. | |
| 11 | XPN.11 | Name Assembly Order | ID | 0444 | Name Assembly Order; Type ID; HL7 table 0444. |
| 12 | XPN.12 | Effective Date | TS | Effective Date; Type TS. | |
| 13 | XPN.13 | Expiration Date | TS | Expiration Date; Type TS. | |
| 14 | XPN.14 | Professional Suffix | ST | Professional Suffix; Type ST. |
XPN is the HL7 datatype for a person's name. You see it in the obvious places, such as PID-5 Patient Name, PID-6 Mother's Maiden Name, NK1-2 Name, and GT1-3 Guarantor Name. It also turns up in insurance, contact, staff, provider, and administrative fields where the message needs the name of a person but not necessarily that person's identifier.
The practical point of XPN is simple: names are not one field. A name has family and given parts, optional prefixes and suffixes, a type that says whether it is legal, alias, maiden, display, or something else, and sometimes details about script, validity dates, and display order. If you flatten all of that into Jane Anne Smith, the receiver can display it, but it may not be able to match, search, sort, or safely update it.
The most common trap is treating the first repeat as "the name" and ignoring the name type code. That works until a patient has a legal name and a preferred name, or an old alias, or a local script version and a romanized version. Repetition is useful, but repetition without meaning is just a pile of names.
That example carries two XPN repetitions. The first is Jane Anne Smith, marked as a legal name. The second is Jane Jones, marked as a maiden name. The names are not separated by commas, and the repeat order is not doing the real work. The components and the name type code are.
XPN-1 to XPN-3: The Name Itself
XPN-1 is the family name, XPN-2 is the given name, and XPN-3 is the second and further given names or initials. These three components are where most day-to-day XPN values live. Smith^Jane^Anne is boring in exactly the right way: the receiver knows what to sort on, what to display as the given name, and what extra given-name text belongs in the middle.
Family name is technically the FN datatype, so it can carry more structure than a plain string when a profile needs that. Most interfaces use it like a string, but knowing it is FN helps explain why surname prefixes, compound surnames, and family-name subcomponents sometimes appear. Do not split a family name just because it has a space or punctuation. Van Der Meer, O'Connor, and hyphenated names are not broken data.
If you are mapping from messy source text, Integration Soup string extensions such as Title() and McName() can tidy values like jane, SMITH, or o'connor while you build the XPN components. They help with casing; they do not decide which component a name belongs in, and they should not be used to overwrite carefully entered cultural or legal name formatting.
XPN-4 to XPN-6: Suffix, Prefix, and Degree
XPN-4 is the name suffix, XPN-5 is the prefix, and XPN-6 is the degree. These are useful when the receiving system displays names as supplied, but they are not a substitute for putting the family and given names in the right place. A common mistake is sending Dr Jane Smith in the given name or family name component because the source screen showed it that way. Use the prefix component if the prefix needs to travel.
Degrees and professional decorations are often better handled by a provider or staff master than by patient-name style fields. For patient names, these components are often empty. For staff or provider names carried as XPN, send them only when the receiver expects them and knows how to display them.
XPN-7: Name Type Code
This is the small component that prevents a lot of confusion. XPN-7 explains what kind of name the repeat represents. Legal, alias, maiden, display, preferred, and other local/profile-specific meanings all need this kind of hint. In patient demographics, a legal name and a preferred name are not interchangeable just because they belong to the same person.
If the field repeats, populate XPN-7 wherever you can. If you send two names and leave both type codes blank, the receiver may choose the first one, the longest one, the most recent one, or the one that happened to survive an import rule written years ago. That is not a great matching strategy.
XPN-8 and XPN-11: Representation and Assembly
XPN-8 is the name representation code. It is mainly useful when the same name can be sent alphabetically, ideographically, or phonetically. In single-script interfaces it is often blank, but in multilingual environments it can be the difference between a useful repeat and a duplicate-looking mystery value.
XPN-11 is the name assembly order. It tells a receiver how the name should be assembled for display when the usual family-name-first or given-name-first assumption is not enough. Do not guess this from country alone. Use it when the source system really knows the intended assembly order or the implementation guide asks for it.
XPN-9: Name Context
Name context can describe the setting or purpose of a name. It is not heavily populated in everyday ADT feeds, but it exists for interfaces that need more nuance than the name type code alone can provide. If your source only has "legal" and "preferred", XPN-7 is usually the better place to carry that. XPN-9 is for profiles that have agreed on a more specific context.
XPN-10, XPN-12, and XPN-13: Validity Dates
XPN-10 gives a name validity range, while XPN-12 and XPN-13 carry effective and expiration dates. These components matter around name changes, historical names, staff credentials, insurance subscriber names, and identity workflows where an old name should remain visible but should no longer be treated as current.
Most simple patient feeds leave these empty and send the current names only. That is fine, as long as the receiving system does not need history. If you do send dates, be clear about what they mean. Is the effective date when the patient legally changed the name, when the source system recorded it, or when the receiver should start using it? Those are different business events.
XPN-14: Professional Suffix
Professional suffix is separate from the general suffix and degree components. It is rarely important in ordinary patient-name fields, but it can matter when XPN is used for staff, contacts, or provider-like people in administrative messages. If the receiver only displays a name, agree which of prefix, suffix, degree, and professional suffix it uses. Otherwise you end up with names that are technically populated and visually odd.
Where XPN Shows Up Most
In ADT and registration, XPN is central to PID-5, and repeats are the right way to carry legal, alias, maiden, and preferred names when the receiving profile supports them. PID-6 uses XPN for mother's maiden name, but that does not mean you should send the mother's entire current identity there. It is a demographic matching clue, not a mother-record link.
For next-of-kin and contact workflows, XPN appears in NK1-2 and related contact fields. Insurance and guarantor messages use it for subscriber, guarantor, employer contact, and approval names. Staff-oriented segments such as STF-3 can also use XPN, although person identifiers are more commonly handled with XCN when an ID and a name need to travel together.
Practical Implementation Advice
When you build XPN values, map the structure deliberately. Do not take a display name from a screen and hope the receiver can reverse-engineer it. Put family name in XPN-1, given name in XPN-2, further given names in XPN-3, and the type in XPN-7 when you know it. If you have both a legal name and a preferred name, send repeats rather than inventing a local delimiter inside one component.
Also watch HL7 escaping. Apostrophes and hyphens are fine as ordinary text, but HL7 delimiters such as ^, |, ~, &, and backslash need proper escaping if they appear in source text. Integration Soup helpers such as HL7Encode() and APIs such as SetTextEncoded are useful when you are inserting source text into an HL7 message and do not want a name to accidentally become extra components.
When you are checking a live message, HL7 Soup Web can make the split visible: the interpretation view shows the field and component you are looking at, links back to the exact place in the raw message, and translates table-backed values such as name type or representation code into readable descriptions.
Official Description and References
The HL7 v2+ logical model describes XPN as an extended person name and lists the family name, given name, further given names, suffix, prefix, degree, name type code, representation, context, validity, assembly order, dates, and professional suffix components. HL7 terminology also notes XPN as the extended person name datatype that replaced PN as of HL7 v2.3.
For formal reference, compare the generated component panel above with the HL7 v2+ XPN logical model and the HL7 terminology dataTypes code system.
Related Datatypes and Segments
For nearby datatype work, look at XCN when a person identifier and name travel together, CX for patient identifiers, FN for family-name structure, and CWE for coded values such as context. For common segment uses, start with PID-5, PID-6, NK1-2, GT1-3, IN1-16, and STF-3.