HL7 XCN Extended ID and Name for Persons
HL7 datatype components XCN 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 | XCN.1 | ID Number | ST | ID Number; Type ST. | |
| 2 | XCN.2 | Family Name | FN | Family Name; Type FN. | |
| 3 | XCN.3 | Given Name | ST | Given Name; Type ST. | |
| 4 | XCN.4 | Second and Further Given Names or Initials Thereof | ST | Second and Further Given Names or Initials Thereof; Type ST. | |
| 5 | XCN.5 | Suffix (e.g., JR or III) | ST | Suffix (e.g., JR or III); Type ST. | |
| 6 | XCN.6 | Prefix (e.g., DR) | ST | Prefix (e.g., DR); Type ST. | |
| 7 | XCN.7 | Degree (e.g., MD) | IS | 0360 | Degree (e.g., MD); Type IS; HL7 table 0360. |
| 8 | XCN.8 | Source Table | IS | 0297 | Source Table; Type IS; HL7 table 0297. |
| 9 | XCN.9 | Assigning Authority | HD | 0363 | Assigning Authority; Type HD; HL7 table 0363. |
| 10 | XCN.10 | Name Type Code | ID | 0200 | Name Type Code; Type ID; HL7 table 0200. |
| 11 | XCN.11 | Identifier Check Digit | ST | Identifier Check Digit; Type ST. | |
| 12 | XCN.12 | Check Digit Scheme | ID | 0061 | Check Digit Scheme; Type ID; HL7 table 0061. |
| 13 | XCN.13 | Identifier Type Code | ID | 0203 | Identifier Type Code; Type ID; HL7 table 0203. |
| 14 | XCN.14 | Assigning Facility | HD | Assigning Facility; Type HD. | |
| 15 | XCN.15 | Name Representation Code | ID | 0465 | Name Representation Code; Type ID; HL7 table 0465. |
| 16 | XCN.16 | Name Context | CE | 0448 | Name Context; Type CE; HL7 table 0448. |
| 17 | XCN.17 | Name Validity Range | DR | Name Validity Range; Type DR. | |
| 18 | XCN.18 | Name Assembly Order | ID | 0444 | Name Assembly Order; Type ID; HL7 table 0444. |
| 19 | XCN.19 | Effective Date | TS | Effective Date; Type TS. | |
| 20 | XCN.20 | Expiration Date | TS | Expiration Date; Type TS. | |
| 21 | XCN.21 | Professional Suffix | ST | Professional Suffix; Type ST. | |
| 22 | XCN.22 | Assigning Jurisdiction | CWE | Assigning Jurisdiction; Type CWE. | |
| 23 | XCN.23 | Assigning Agency or Department | CWE | Assigning Agency or Department; Type CWE. |
XCN is one of those HL7 datatypes that looks like a name field until it starts doing a lot more than a name field. It is the datatype you see when a segment needs to identify a person involved in the workflow: an ordering provider, attending doctor, responsible observer, transcriptionist, pharmacist, scheduler, contact person, or someone who entered, verified, performed, or signed something.
So the first rule is a nice simple one: XCN is not usually where you identify the patient. Patient identifiers normally live in CX fields such as PID-3, and patient names normally use XPN. XCN is for a person as an actor in the message. In real interfaces that usually means provider or staff identity, with enough name detail for humans and enough identifier detail for systems.
The most common mistake is sending only the name, or only a local ID, and hoping the receiver can work it out. Sometimes that is enough inside one hospital. It is rarely enough once the message crosses organizations, feeds a registry, drives billing, or lands in a system that has its own provider master. If you can send the ID number, assigning authority, name type, and identifier type, do it. A naked provider number is like a street address without the city: it may be correct, but you have made the receiver guess the map.
That little XCN example says: this is Bob Smith, the ID is probably an NPI, the assigning authority is named and carried as an OID-style HD value, and the name being sent is the legal name. In a live message you might see it inside ORC-12, OBR-16, PV1-7, OBX-16, TXA-5, or plenty of other person/provider fields.
XCN-1: ID Number
This is usually the component that matters most to machines. It may be an NPI, DEA number, medical license number, employee number, internal provider master ID, scheduler user ID, or some other locally agreed identifier. In lab and order interfaces, implementation guides often prefer a real provider identifier such as an NPI when the sender has it. CMS describes the NPI as a unique 10 digit identifier for covered health care providers, and that is why it turns up so often in U.S. provider-facing XCN values.
Do not treat XCN-1 as self-explaining. If the value is an NPI, say that in XCN-13. If it came from a local provider table, say who assigned it in XCN-9. If you have no trustworthy identifier, sending only the name may be the honest answer, but then you should not expect reliable provider matching on the receiving side. An integration engine such as Integration Soup is often where these local provider IDs get mapped into the identifier style the receiver expects.
XCN-2 to XCN-6: The Person Name
The name components are there for people, matching, and display. XCN-2 is the family name, XCN-3 is the given name, XCN-4 is second and further given names or initials, XCN-5 is the suffix, and XCN-6 is the prefix. In day-to-day interfaces you will often see only the first three populated, for example 5551001234^Smith^Bob. That is common in lab result feeds and order messages, and it is better than free-texting "Dr Bob Smith" into one blob.
The family name component is actually the FN datatype, so it can carry surname pieces when a profile uses that level of detail. Most interfaces do not go that deep, but it explains why people sometimes get confused by XCN having components that themselves have subcomponents. If you parse by HL7 delimiters rather than string splitting by hand, the hierarchy is not scary. HL7 Soup Web is handy for this sort of thing because you can click through a provider field and see exactly which component and subcomponent you are looking at.
If your source system only gives you plain text names, the Integration Soup coding helpers can take some of the boring cleanup out of the job. The string extensions such as Title() and McName() are useful when you are turning text like bob smith or o'connor into sensible XCN name components. They do not magically decide which provider identifier or assigning authority to use, but they are a neat little assist when the raw text is messy and you are building a proper XCN value in a transformation.
XCN-7: Degree
This is where degrees such as MD can be carried. It is tempting to put every professional decoration here, but in modern interfaces it is often either empty or used only when the receiving system displays provider names exactly as supplied. If the provider credential affects workflow, eligibility, billing, or clinical authorization, do not rely on this cosmetic component alone. That sort of meaning usually belongs in a provider master, a credentialing system, or a profile-specific coded field.
XCN-8: Source Table
This component points at the source table for the identifier. In older HL7 patterns it helped say which local table the ID came from. In many modern interfaces it is left blank because XCN-9 Assigning Authority and XCN-13 Identifier Type Code carry the more useful meaning. If your trading partner asks for it, populate it exactly as they specify. Otherwise, do not invent a source table code just to fill the slot.
XCN-9: Assigning Authority
This is the component that turns "123456" from a number into an identifier. XCN-9 uses the HD datatype, so it can carry a namespace ID, a universal ID, and a universal ID type. The universal ID is often an OID when organizations want a globally meaningful assigning authority. For example, an implementation guide may say that an NPI should come with a specific assigning authority and ID type, while a local staff ID might be assigned by the hospital's provider master.
In practice, this is where many provider-matching problems are born. Two systems can both send provider ID 1234, and both can be correct in their own world. Without XCN-9, the receiver has to decide whether those are the same person, different people, or a collision. If you are doing any cross-organization work, external reporting, or long-lived provider matching, this component deserves more respect than it usually gets.
XCN-10: Name Type Code
This tells the receiver what sort of name is being sent. Legal name is commonly represented with L, and many profiles either expect that value or assume it when the component is blank. This matters more when the same person can be sent with a legal name, display name, alias, or a different representation for a different writing system.
For provider fields, most integrations keep this simple: one repeat with the legal or official provider name. Where names are used for matching, be careful with nicknames and display-only formatting. A message that says Smith^Bob may look friendlier than Smith^Robert, but the provider registry may disagree.
XCN-11 and XCN-12: Check Digit Details
XCN-11 is the identifier check digit, and XCN-12 says which check digit scheme was used. These are not commonly populated for provider identifiers in the interfaces most people build today, especially when the identifier is alphanumeric or when the identifier type already has its own validation rules. If a profile requires a check digit, follow the profile exactly. Otherwise these components are usually left empty.
The important thing is not to calculate a check digit just because the field exists. Check digits are only useful when both systems agree on the algorithm and on which identifier they apply to. An unexpected value here can be worse than no value because it suggests a validation rule the receiver may not actually use.
XCN-13: Identifier Type Code
This is one of the small components that does a lot of work. XCN-13 tells the receiver what kind of identifier is sitting in XCN-1. HL7 table 0203 includes provider-friendly codes such as NPI, DEA, physician number, license-style identifiers, and many other identifier types. If XCN-1 contains an NPI, XCN-13 should say NPI. If it is a DEA number in a pharmacy interface, say DEA. If it is only a local provider number, use the agreed local or standard identifier type.
In orders and results this component helps stop a surprisingly common support conversation: "Which provider number did you send us?" The answer should be readable from the XCN itself. XCN-9 says who assigned the identifier, and XCN-13 says what kind of identifier it is. You usually want both.
XCN-14: Assigning Facility
This is another HD value, but it is about the facility where the identifier was first assigned rather than the authority that owns the identifier namespace. In simple provider flows it is often empty. It becomes more useful in large hospital groups, shared MPI/provider-master arrangements, and historic data migrations where the same organization has multiple facilities feeding one enterprise system.
If the identifier is nationally assigned, like an NPI, the assigning facility may not add much. If the identifier is local, the facility can be helpful, but it should not replace XCN-9. Think of XCN-9 as "who controls this identifier namespace" and XCN-14 as "which facility issued or first used this particular identifier" when that distinction matters.
XCN-15 to XCN-18: Representation, Context, Validity, and Assembly
These are the name-detail components that show up more in careful profiles than in everyday feeds. XCN-15 is the name representation code, useful when names can be represented alphabetically, ideographically, or phonetically. XCN-16 is the name context, which can explain the setting or purpose of the name. XCN-17 gives the name validity range, and XCN-18 can say the name assembly order.
If you work in a single-language, single-script environment, these often stay blank and nobody misses them. If you work with multilingual names, legal name changes, transliterated names, or systems that display names differently by culture, these components stop being decorative. The main advice is to use them only when the sending system actually knows the distinction. Guessing a representation or assembly order is not much better than flattening the whole name into free text.
XCN-19 and XCN-20: Effective and Expiration Dates
These components tell you when the identifier or name information became valid and when it stopped being valid. They are much more useful in master data and credentialing style feeds than in ordinary ORU or ORM traffic. For example, a provider may have an internal ID that is active only during an employment period, or a credential that should no longer be used after a certain date.
Most receivers do not use these dates unless an implementation guide calls them out. If you do populate them, make sure the date meaning is agreed. Is it the date the provider became active, the date this name became valid, the date the identifier was issued, or the date the sender started using it? Those sound similar until you have to reconcile two provider records.
XCN-21: Professional Suffix
This is for professional suffix text, separate from the general suffix in XCN-5 and the degree in XCN-7. In real interfaces it is not heavily used, partly because professional credentials are often managed outside HL7 messages and partly because display names vary by receiving application. If your receiver wants provider display text, agree on whether it expects degree, professional suffix, prefix, or some combination. Otherwise it is easy to get names that look odd even though the identifier is perfectly fine.
XCN-22 and XCN-23: Assigning Jurisdiction and Assigning Agency or Department
These are later, more specific components that help describe who assigned the identifier in a more structured way. XCN-22 can carry the jurisdiction, and XCN-23 can carry the assigning agency or department. They are useful when the difference between a state board, national registry, internal department, or other issuing body matters. You may see this around licenses, public health reporting, credentialing, or profiles that are trying to remove ambiguity from provider identifiers.
For many ordinary feeds they are empty, and that is fine. But they are worth knowing about because they are exactly the sort of components you wish existed when a receiver says, "We need to know which authority issued this provider ID, not just the value." If you already have that information and the receiver can use it, these components are a cleaner place for it than a note field.
Where XCN Shows Up Most
In ADT and registration, XCN appears in places like PV1-7 Attending Doctor, PV1-8 Referring Doctor, and PD1-4 Patient Primary Care Provider. These fields are often consumed by downstream systems for display, routing, provider attribution, and sometimes billing or reporting. If you only send the provider's name here, the feed may look fine on a screen but still fail the moment someone needs reliable attribution.
In orders and lab results, the big ones are ORC-12 Ordering Provider, OBR-16 Ordering Provider, OBR-28 Result Copies To, and OBX-16 Responsible Observer. Lab implementation guides often push hard on NPI, assigning authority, and name because the ordering provider may drive reporting, routing, and follow-up. One practical trap is assuming ORC and OBR always carry the same provider. Some profiles require them to match within an order group; other workflows, especially reflex or amended workflows, can make the segment context matter. Read the profile before flattening them into one internal field.
Pharmacy and immunization interfaces use XCN around administering, ordering, dispensing, and verifying people. That is where DEA, NPI, local pharmacist IDs, and treatment supplier details can all appear depending on the message family. Scheduling uses XCN in SCH and AIP style personnel fields. Documents use it in TXA for people who originated, authenticated, transcribed, or distributed a document. Billing and charge feeds can use it in FT1 for performed-by, ordered-by, and entered-by people.
Practical Implementation Advice
If you are building a new interface, decide what the primary provider identifier is before you start mapping. In many U.S. healthcare interfaces that will be NPI for external provider identity, with local IDs retained for internal routing or user lookup. In other countries or local networks it may be a national provider number, license number, or an enterprise provider master ID. The key is to be explicit. XCN-1, XCN-9, and XCN-13 should tell the story together.
Also decide whether repeats are allowed and what each repeat means. A receiver may want one provider value only, or it may accept multiple identifiers for the same person. If you send an NPI repeat and a local-provider-ID repeat, make sure the receiver knows which one to match on and which one to display. This is a place where a little agreement in the interface spec saves a lot of "why did it pick that provider?" support work later.
Official Description and References
The HL7 v2+ logical model describes XCN as the extended composite ID number and name for persons, notes that it replaced the older CN datatype as of HL7 v2.3, and points out its use in segments such as PV1, ORC, RXO, RXE, OBR, and SCH where a message needs both the ID number and name of a person. The HL7 v2.5.1 component table lists the 23 components used by this guide's default reference panel.
For formal reference, compare the generated component panel above with the HL7 v2+ XCN logical model, the HL7 v2.5.1 Chapter 2.A datatype tables, and HL7 terminology table 0203 for identifier type codes. Public lab implementation guides are also useful because they show ordering provider XCN values populated with NPI, name, assigning authority, and identifier type.
Related Datatypes and Segments
For nearby datatype work, look at CX for patient and visit identifiers, XPN for person names without the identifier part, HD for assigning authorities, and CWE for coded values. For common segment uses, start with ORC-12, OBR-16, PV1-7, OBX-16, RXA, and TXA-5.