HL7 XON (Extended Organization Name and ID) | Integration Soup HL7 Reference Guide

HL7 XON Extended Organization Name and ID

Carry organization names with enough identifier detail that receivers know which organization you meant.

HL7 datatype components XON 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	XON.1	Organization Name	ST		Organization Name; Type ST.
2	XON.2	Organization Name Type Code	IS	0204	Organization Name Type Code; Type IS; HL7 table 0204.
3	XON.3	ID Number	NM		ID Number; Type NM.
4	XON.4	Check Digit	NM		Check Digit; Type NM.
5	XON.5	Check Digit Scheme	ID	0061	Check Digit Scheme; Type ID; HL7 table 0061.
6	XON.6	Assigning Authority	HD	0363	Assigning Authority; Type HD; HL7 table 0363.
7	XON.7	Identifier Type Code	ID	0203	Identifier Type Code; Type ID; HL7 table 0203.
8	XON.8	Assigning Facility	HD		Assigning Facility; Type HD.
9	XON.9	Name Representation Code	ID	0465	Name Representation Code; Type ID; HL7 table 0465.
10	XON.10	Organization Identifier	ST		Organization Identifier; Type ST.

XON is the HL7 v2 datatype for an organization name with organization identification detail. It is what you use when the value is a hospital, clinic, payer, employer, school, agency, vendor, manufacturer, provider organization, or other organization rather than a person.

The name is only the start. XON can also carry a name type, an ID number with check digit, assigning authority, identifier type, assigning facility, representation code, and another organization identifier. That extra structure matters because organizations change display names, share similar names, merge, split, and show up in different workflows under different IDs.

The common trap is treating XON as a free-text organization-name field. Good Health Hospital may be clear to a human, but it may not be enough for billing, reporting, provider directory matching, payer routing, public health, or master data cleanup.

Good Health Hospital^L^716^9^M10^HOSPMASTER^XX^CENTRAL^A^GH-716

This example carries a legal organization name, an organization ID, a check digit and scheme, an assigning authority, an identifier type, an assigning facility, an alphabetic representation code, and a string organization identifier. Real interfaces often use only the first few components, but the missing authority is usually where future matching pain begins.

XON-1 to XON-2: Organization Name and Name Type

XON-1 is the organization name. It should be the name you agreed to send: legal name, display name, alias, payer name, employer name, facility name, vendor name, or whatever the field and profile require.

XON-2 is the organization name type code. In the v2.5.1 table, common values include legal name, display name, alias name, and stock exchange listing name. Use it when the distinction matters. A legal name and a display name can both be correct and still not be interchangeable.

Be careful with automated casing. A helper like Title() may be useful for ugly all-caps source text in some controlled feeds, but it can damage acronyms, brand casing, government agency names, and legal suffixes. ACME NHS TRUST, St. Luke's, 3M, and McKesson do not all want the same rule. For organization names, a lookup table or curated master data source is usually better than clever text cosmetics.

XON-3 to XON-5: ID Number, Check Digit, and Scheme

XON-3 is the organization ID number. XON-4 is the check digit, and XON-5 is the check digit scheme. These components are useful when the organization identifier has a formal numeric structure and validation rule, such as an enterprise hospital master number or a national identifier that uses a known algorithm.

Do not calculate or change the check digit unless the assigning authority has told you exactly which scheme applies. A check digit is part of the identifier governance, not a formatting flourish. If the source system gives you the ID and check digit, preserve them. If it gives you only a display name, do not make up an ID to make the XON look full.

Also remember that XON-3 is numeric in the v2.5.1 generated component data. If your organization identifier is alphanumeric, check the field profile carefully and consider whether XON-10 is the better component for that value.

XON-6 to XON-8: Assigning Authority, Identifier Type, and Assigning Facility

XON-6 is the assigning authority, using HD. It tells the receiver who minted or governs the organization ID. XON-7 is the identifier type code, using the same identifier-type table idea you see in CX. XON-8 is the assigning facility, also HD.

These components turn an organization number into a real identifier. 716 from a hospital master, 716 from an employer table, and 716 from a payer feed are not automatically the same organization. The assigning authority and identifier type tell the receiver how to interpret the number.

Assigning authority and assigning facility are not the same thing. The authority owns the identifier series. The facility may be where it was issued or where it is locally meaningful. If that difference does not matter in your interface, fine, but do not swap them casually.

XON-9 to XON-10: Name Representation and Organization Identifier

XON-9 is the name representation code. It tells the receiver whether the organization name is alphabetic, ideographic, or phonetic. Many English-only feeds leave this empty or send the default alphabetic representation, but it matters in multilingual or multi-script environments.

XON-10 is the organization identifier. Because it is an ST component in v2.5.1, it can be a better home for an alphanumeric organization key than XON-3. Use it deliberately, not as a junk drawer for notes or secondary display labels.

If the organization name contains HL7 delimiters, such as & in a company name or a caret copied from a source display, write through encoded setters or helpers such as HL7Encode(). Escaping keeps the message valid, but the cleaner fix is still to map from an organization master where names and IDs are governed.

Where XON Shows Up Most

XON appears anywhere an organization can be the meaningful party. In demographics and contact feeds, it shows up in NK1-13 Organization Name, PD1-3 Patient Primary Facility, and PD1-14 Place of Worship. In insurance and billing, it appears in payer, group, guarantor, employer, and responsible-organization style fields such as IN1-4, IN1-9, IN1-11, GT1-21, and GT1-51.

Operational feeds use XON for ordering facility name, performing organization name, software vendor organization, clinic organization name, manufacturer/distributor, location-master organization names, and other organization relationships. It is not only a billing datatype; it is an organization identity datatype.

Organization versus Person

If the value is a person, use the person-name datatype assigned by the field, such as XPN or XCN. If it is an organization, use XON. This sounds obvious until an employer, school, clinic, trust, or agency arrives in a field that older systems treated loosely.

For example, an NK1 can carry a named person and an organization around that person. Do not force the school or employer into the person-name field just because it is the first field with "name" in the label. The organization has its own home, and the human contact inside the organization has theirs.

Practical Implementation Advice

Map XON from a maintained organization source whenever you can. Payer master, employer master, provider directory, facility dictionary, vendor registry, and location master values are all better than scraped display text.

In Integration Soup transformations, Default() can be reasonable for a harmless display fallback when the guide allows it, but do not default a missing organization ID, assigning authority, or identifier type. That makes an uncertain organization look confidently identified. For messy names, prefer explicit lookup and cleanup rules; only use casing helpers where the source and organization set are narrow enough that the rule is safe.

Repeating XON values can be useful when an organization has a legal name, display name, alias, and external identifier. Keep each repeat coherent: name, name type, ID, authority, and identifier type should describe the same organization identity, not a collage of values from different masters.

HL7 Soup Web can make XON problems easier to see because the interpretation view links the readable organization detail back to the exact raw component. Table-backed values such as organization name type, identifier type, and name representation can be shown as descriptions, which helps catch a legal name sent as a display name or an organization ID sent without its authority.

Official Description and References

The HL7 v2+ XON logical model describes XON as the extended composite name and identification number for organizations. It says the datatype is used in fields such as PV2-23, NK1-13, PD1-3, and OBR-44 to specify the name and ID number of an organization, and its examples show organization IDs with assigning authorities and assigning facilities.

For formal reference, compare the generated component panel above with the HL7 v2+ XON logical model, HL7 table 0204 organization name type terminology, and HL7 table 0203 identifier type terminology.

For nearby datatype work, look at HD for assigning authorities, CX for person/patient-style identifiers, XCN for provider/person names with IDs, XPN for person names, and XAD for organization addresses. For common segment uses, start with NK1-13, PD1-3, IN1-4, GT1-21, ORC-21, and SFT-1.