HL7 XTN Extended Telecommunication Number
HL7 datatype components XTN 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 | XTN.1 | Telephone Number | ST | Telephone Number; Type ST. | |
| 2 | XTN.2 | Telecommunication Use Code | ID | 0201 | Telecommunication Use Code; Type ID; HL7 table 0201. |
| 3 | XTN.3 | Telecommunication Equipment Type | ID | 0202 | Telecommunication Equipment Type; Type ID; HL7 table 0202. |
| 4 | XTN.4 | Email Address | ST | Email Address; Type ST. | |
| 5 | XTN.5 | Country Code | NM | Country Code; Type NM. | |
| 6 | XTN.6 | Area/City Code | NM | Area/City Code; Type NM. | |
| 7 | XTN.7 | Local Number | NM | Local Number; Type NM. | |
| 8 | XTN.8 | Extension | NM | Extension; Type NM. | |
| 9 | XTN.9 | Any Text | ST | Any Text; Type ST. | |
| 10 | XTN.10 | Extension Prefix | ST | Extension Prefix; Type ST. | |
| 11 | XTN.11 | Speed Dial Code | ST | Speed Dial Code; Type ST. | |
| 12 | XTN.12 | Unformatted Telephone number | ST | Unformatted Telephone number; Type ST. |
XTN is the HL7 datatype for contact details: phone numbers, mobile numbers, fax numbers, email addresses, extensions, and the occasional unparsed contact value. It shows up anywhere a message needs to tell another system how to reach a patient, contact person, provider, organization, guarantor, insurer, or facility.
The everyday patient fields are PID-13 Phone Number - Home and PID-14 Phone Number - Business, but XTN also appears in NK1-5, NK1-6, guarantor and insurance fields, provider/contact segments, scheduling messages, and public health feeds. It matters for reminders, portals, care coordination, billing follow-up, emergency contacts, and operational support.
The biggest trap is treating XTN as a single phone-number string. It can carry a formatted number, a structured phone number, an email address, a fax, a mobile, or a free-text fallback. Those are not all the same thing. If you have both a mobile number and an email address, send two repeats. Do not stuff them into one component with a comma and hope the receiver is feeling generous.
This example carries a personal mobile number and an email address as separate repeats. The use code and equipment type tell the receiver what each repeat means. That is far easier to map than 021 555 1234 / jane.smith@example.org in one field.
XTN-1: Telephone Number
XTN-1 is the older formatted telephone number component. You still see it in legacy feeds because it is easy to populate from a screen field. The downside is that the receiver may not know which part is country code, area code, local number, or extension.
If both systems agree on XTN-1, it can be perfectly serviceable for display. If the receiver needs dialing, matching, SMS routing, or country-specific validation, structured components are usually better. Do not populate both the formatted number and the parsed components inconsistently. That just creates two versions of the truth in one value.
XTN-2 and XTN-3: Use Code and Equipment Type
XTN-2 says how the contact detail is used: primary residence, work, network/email, emergency, answering service, and so on depending on the table and profile. XTN-3 says what kind of equipment or channel it is: phone, fax, mobile/cellular phone, Internet, pager, and similar values.
These two components are the heart of XTN. A phone number with no use code may still dial, but it does not tell the receiver whether it is home, work, mobile, or temporary. An email address without an equipment type may display, but it is harder to route into portal or notification logic. Use the values your implementation guide expects, and keep repeats separate by purpose.
XTN-4: Email Address
XTN-4 is the email or communication address component. In practice, an email repeat often looks like ^NET^Internet^someone@example.org. The address sits in XTN-4, while XTN-2 and XTN-3 tell the receiver that this repeat is a network or Internet contact value.
Do not put email in the phone-number component just because the source screen says "Contact". If the receiver is going to trigger reminders, portal invites, notifications, or identity verification, it needs to know whether the value is a phone number or an email address. Mixed contact fields are convenient for data entry and painful for interfaces.
XTN-5 to XTN-7: Country, Area, and Local Number
XTN-5 is country code, XTN-6 is area or city code, and XTN-7 is the local number. These are the structured phone-number components most people care about when they need dialing or normalization. They are especially useful when messages cross regions, when SMS reminders are involved, or when a receiver applies validation rules.
Phone normalization is local and policy-heavy. Some receivers want international-style country and area pieces. Some want a national-format local number. Some accept punctuation and some do not. Validate and format the number according to the receiving profile, and keep the rule visible in the interface spec so the next mapping change does not quietly change dialing behavior.
XTN-8, XTN-10, and XTN-11: Extension, Prefix, and Speed Dial
XTN-8 carries the extension. XTN-10 carries an extension prefix, and XTN-11 carries a speed dial code. These show up more in organization, work-phone, and internal directory scenarios than in ordinary patient mobile numbers.
If a receiver needs an extension, send it separately instead of appending x1234 to the local number. If the phone system uses a facility prefix or speed dial code, document it carefully. Those values are often meaningful only inside one organization.
XTN-9: Any Text
XTN-9 is a free-text note about the telecommunication value. It can be useful for things like "after 5pm", "reception desk", or other display-only details when a profile allows it. It is not where the actual phone number or email should go.
Because this is text, escape it properly if it can contain HL7 delimiters. Helpers such as HL7Encode() or encoded field APIs are more appropriate here than hand-replacing characters, especially when contact notes come from user-entered text.
XTN-12: Unformatted Telephone Number
XTN-12 is for a telephone number that the sending system cannot parse into country, area, and local components. It is a useful honest fallback. If the source really has 1-800-DENTIST or a messy free-text phone value, XTN-12 can be better than pretending the pieces are known.
Use it deliberately. If you can parse the number reliably, send the structured components. If you cannot, do not invent structure. The receiver may still display or manually review the unformatted value, which is better than receiving a confidently wrong phone number.
Where XTN Shows Up Most
In patient demographics, PID-13 and PID-14 are the usual home and business contact fields. Older profiles may still treat those field names literally, while newer implementations use XTN repeats for phones, mobiles, and email addresses with use/equipment codes. Read the profile before assuming email is allowed in PID-13.
In contacts and guarantors, XTN appears in NK1-5, NK1-6, GT1, and insurance segments. In scheduling and operational workflows, it may drive reminder calls, staff contact, or resource coordination. Bad XTN values often look harmless until the reminder service tries to call an email address.
Practical Implementation Advice
Start by separating channels. Phone, mobile, fax, pager, and email should normally be separate repeats, with XTN-2 and XTN-3 telling the receiver what each repeat is. Then decide whether the phone number can be safely parsed into country, area, and local components. If it cannot, use XTN-12 or agree on a legacy formatted XTN-1 pattern.
Do not use Default() to turn a missing mobile number into a fake value just to satisfy a required-looking field. If the receiver requires at least one contact method, that is a validation and workflow issue, not a string helper issue. Missing contact details should be visible in testing rather than quietly converted into bad data.
HL7 Soup Web helps during testing because the interpretation view can show each XTN repeat and jump back to the exact phone, email, use-code, or equipment-type component in the raw message. For coded components such as XTN-2 and XTN-3, the table description makes it easier to catch a mobile number sent as a work phone or an email repeat sent as plain telephone text.
Official Description and References
The HL7 v2+ logical model describes XTN as the extended telecommunication number datatype and gives examples for work fax, phone with extension, internal dialing details, speed dial, and home/work email addresses. The HL7 v2.5.1 component panel in this guide lists the twelve XTN components used by the default reference version.
For formal reference, compare the generated component panel above with the HL7 v2+ XTN logical model, HL7 table 0201 telecommunication use codes, and HL7 table 0202 telecommunication equipment types.
Related Datatypes and Segments
For nearby datatype work, look at XAD for addresses, XPN for person names, and CWE for coded values. For common segment uses, start with PID-13, PID-14, NK1-5, NK1-6, GT1, and IN1.