HL7 XAD Extended Address
HL7 datatype components XAD 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 | XAD.1 | Street Address | SAD | Street Address; Type SAD. | |
| 2 | XAD.2 | Other Designation | ST | Other Designation; Type ST. | |
| 3 | XAD.3 | City | ST | City; Type ST. | |
| 4 | XAD.4 | State or Province | ST | State or Province; Type ST. | |
| 5 | XAD.5 | Zip or Postal Code | ST | Zip or Postal Code; Type ST. | |
| 6 | XAD.6 | Country | ID | 0399 | Country; Type ID; HL7 table 0399. |
| 7 | XAD.7 | Address Type | ID | 0190 | Address Type; Type ID; HL7 table 0190. |
| 8 | XAD.8 | Other Geographic Designation | ST | Other Geographic Designation; Type ST. | |
| 9 | XAD.9 | County/Parish Code | IS | 0289 | County/Parish Code; Type IS; HL7 table 0289. |
| 10 | XAD.10 | Census Tract | IS | 0288 | Census Tract; Type IS; HL7 table 0288. |
| 11 | XAD.11 | Address Representation Code | ID | 0465 | Address Representation Code; Type ID; HL7 table 0465. |
| 12 | XAD.12 | Address Validity Range | DR | Address Validity Range; Type DR. | |
| 13 | XAD.13 | Effective Date | TS | Effective Date; Type TS. | |
| 14 | XAD.14 | Expiration Date | TS | Expiration Date; Type TS. |
XAD is the HL7 datatype for an address. You see it in patient demographics, next-of-kin and contact details, guarantor and insurance records, employer details, organization records, and facility-related fields. The most familiar one is PID-11 Patient Address, but XAD is just as important in NK1-4, GT1-5, IN1-5, and other administrative feeds.
Addresses look simple until you have to exchange them between systems that disagree about countries, state fields, apartment lines, mailing versus physical address, county codes, and whether a street name is allowed to contain a delimiter. XAD exists because an address is not just a printable label. It can be used for patient matching, eligibility, billing, public health reporting, reminders, routing, and sometimes jurisdictional logic.
The common mistake is cramming the whole address into the first component and leaving the rest blank. That may display nicely in one receiving screen, but it gives downstream systems nothing reliable to search, validate, or geocode. If you have structured address parts, send them as structured parts.
This example carries two address repeats: a home/physical address and a mailing address. The repeat separator is doing the "two addresses" job, while XAD-7 says what each address is for. That is much cleaner than one field containing Home: ...; Mail: ....
XAD-1 and XAD-2: Address Lines
XAD-1 is the street address, and XAD-2 is the other designation. In ordinary patient feeds, XAD-1 is the main street line and XAD-2 is the apartment, unit, suite, building detail, PO box qualifier, or other secondary line. In HL7 v2.5.1, XAD-1 uses the SAD datatype, which means a profile can break the street address into subcomponents when it needs to.
Do not throw every address line into XAD-1 just because the source has one free-text address box. If the source gives you separate street and unit lines, keep them separate. If the source really only gives you one printable address, be honest about that limitation rather than inventing city or postal code values from fragile string parsing.
Address text also needs proper HL7 escaping. A value such as Unit 2 & 3 should not accidentally create a subcomponent. Integration Soup helpers such as HL7Encode(), or message APIs that write encoded text, are useful when raw source text may contain |, ^, ~, &, or backslash. The goal is not to prettify the address; it is to stop punctuation from changing the message structure.
XAD-3 to XAD-6: City, State, Postal Code, and Country
XAD-3 is city, XAD-4 is state or province, XAD-5 is zip or postal code, and XAD-6 is country. These are the parts that make addresses useful for matching, mail, reporting, and regional rules. They are also where local assumptions leak into interfaces. Some countries require state or province, some do not. Some postal codes contain spaces or letters. Some systems store country as a display name while the receiver wants a code.
If you have the country, send it. An address without country may feel harmless inside one hospital, but it becomes ambiguous in shared services, national reporting, cross-border care, and cloud-hosted systems. Use the code set your implementation guide expects, and do not strip meaningful postal-code formatting unless both systems have agreed on the normalized form.
XAD-7: Address Type
XAD-7 tells the receiver what the address is for: home, mailing, business, temporary, birth, legal, billing, or whatever the local profile allows. This is the component that keeps repeats from becoming a guessing game.
If you have a physical address and a mailing address, send two XAD repeats and type them. Do not put both into one repeat. Also avoid using the first repeat as "primary" without a type code unless the receiver explicitly works that way. Order is a weak substitute for meaning.
XAD-8 to XAD-10: Geographic and Public Health Details
XAD-8 is other geographic designation, XAD-9 is county or parish code, and XAD-10 is census tract. These are often empty in everyday ADT interfaces, but they can become important in public health reporting, immunization registries, regional eligibility, disease surveillance, emergency planning, and population reporting.
When a guide asks for county, parish, or census tract, use the coding system that guide expects. Do not send a county display name where a code is required, and do not duplicate the same idea in PID-12 and XAD-9 unless the profile specifically tells you to. A clean address is better than the same geography repeated inconsistently.
XAD-11: Address Representation Code
This component says how the address is represented, such as alphabetic, ideographic, or phonetic representation. In single-script feeds it is usually empty. In multilingual environments, it can explain why the same address appears in more than one repeat.
If you do send multiple representations, use XAD-11 deliberately. Do not rely on repeat order to tell the receiver which address is romanized and which is local script. That sort of knowledge tends to get lost during migrations.
XAD-12 to XAD-14: Validity and Dates
XAD-12 carries an address validity range, while XAD-13 and XAD-14 carry effective and expiration dates. These components are useful for temporary addresses, seasonal addresses, student addresses, historic addresses, and insurance or billing addresses that only apply for a defined period.
Most simple patient feeds send current addresses only and leave these dates blank. That is fine if both systems agree the feed is current-state only. If the receiver uses address history, be explicit about whether the dates describe when the patient lived there, when the source recorded it, or when the receiver should use it.
Where XAD Shows Up Most
In ADT and registration, PID-11 is the address everyone thinks of first. It is often consumed by portals, reminder systems, billing systems, population health tools, and downstream patient matching. That makes it tempting to "clean" addresses aggressively, but be careful. Removing apartment details, changing casing, or dropping country can create more harm than it fixes.
Contact and guarantor workflows use XAD in NK1-4, GT1-5, and insurance segments such as IN1-5 Insurance Company Address. In those fields, remember whose address it is. The guarantor address is not automatically the patient address, and an insurance company address is not a patient mailing address.
Practical Implementation Advice
When mapping XAD, first decide whether the source has one address or several. If it has several, repeat the field and populate XAD-7. Then decide how much structure you can honestly supply. Good structured values beat heroic parsing. If the source gives you a single multiline block, it may be safer to send the printable line as received than to invent a state or postal code from a brittle split.
Be especially careful with country and address type. They look optional in many feeds, but they often decide whether a receiver can mail, report, match, or validate the address. If you use Default() during a transformation, use it for genuinely optional display pieces, not to mask missing country or address type values that your profile requires.
When reviewing a message in HL7 Soup Web, the interpretation view can help you see whether PID-11 or NK1-4 is really split into street, city, postal code, country, and address type. Table-backed pieces such as address type and country are easier to check when the code description is shown beside the raw value.
Official Description and References
The HL7 v2+ logical model describes XAD as the extended address datatype and notes that it replaced the older AD datatype as of HL7 v2.3. The examples show structured address components for different countries, which is a good reminder that XAD is meant to carry address meaning, not just a local print format.
For formal reference, compare the generated component panel above with the HL7 v2+ XAD logical model and the HL7 v2-to-FHIR XAD to Address concept map.
Related Datatypes and Segments
For nearby datatype work, look at XTN for phone and email contact details, CWE for coded geography or profile-specific address values, and HD when an address is tied to a facility or assigning authority. For common segment uses, start with PID-11, NK1-4, GT1-5, IN1-5, and IN2.