HL7 Table 0190 (Address Type) is the HL7-defined value set that tags a postal address with the role it plays for the person or entity it describes — home, business, mailing, permanent, temporary, birth, registry, or a "bad" address that should no longer be used. It lives in XAD.7 Address Type and therefore appears on every field that carries an XAD: PID-11 Patient Address, NK1-4 NK Address, OBX-23 Performing Organization Address, and dozens more.
Purpose
A single person can have many addresses simultaneously — they live at one, get mail at another, work at a third, and may have a vacation address that matters only seasonally. Without an explicit type, receivers cannot tell which one to mail a billing statement to versus which to dispatch an ambulance to. Table 0190 supplies that metadata so the same XAD.1–XAD.6 street/city/state payload can repeat with different roles in the same field.
It also encodes one piece of quality metadata: BA (Bad address) marks an address known to be undeliverable. Engines should suppress mail-merge and outreach for BA-flagged rows rather than retry.
Where it's used
- XAD.7 — the canonical location for Table 0190; every XAD-bearing field inherits it.
- PID-11 Patient Address (repeating) — home, mailing, vacation in one field.
- NK1-4 Next of Kin Address.
- IN1-19 Insured's Address.
- PV1-43 Pending Location / PV2 Prior Pending Location address subcomponents where institutional addresses appear.
- ORC-23, OBR-44 ordering/performing facility addresses.
Code list
| Code | Display | Comment |
|---|---|---|
| B | Firm/Business | Business address of a person or organization |
| BA | Bad address | Known-undeliverable; suppress outreach |
| BDL | Birth delivery location | Address where the person was born |
| BR | Residence at birth | Residential address at time of birth |
| C | Current Or Temporary | Short-term current location |
| F | Country Of Origin | Address in country of origin |
| H | Home | Primary residential address |
| L | Legal Address | Legally-recognized address (often differs from home) |
| M | Mailing | Where to send mail (may differ from home) |
| N | Birth (nee) | Address used at birth — historical |
| O | Office | Office address |
| P | Permanent | Permanent address (military, students often have separate Current) |
| RH | Registry home | Address registered with a registry (e.g., immunization) |
| S | Service Location | Where service is delivered (institutional) |
| TM | Tube Address | Pneumatic tube address (intra-facility) |
| V | Vacation | Vacation home / seasonal address |
Code system OID and canonical URI
- OID —
2.16.840.1.113883.18.103 - Canonical URI —
http://terminology.hl7.org/CodeSystem/v2-0190
When sending XAD.7 as a coded value, use the HL70190 short name. The OID appears in CWE.14 style fields and in FHIR Coding.system URIs.
HL7-defined vs user-defined
Table 0190 is HL7-defined. The 16 codes above are the normative set. Implementations should not invent new mnemonics — when a needed role is missing, the closest existing code (often O Office or C Current) should be used and the discrepancy raised through HL7 ballot rather than a local extension. Unlike some "user-defined" tables (0001 Sex, for example), HL7 does not invite extension here.
Version differences
- v2.3 — Original publication with the core set: H, B, C, M, P, O, F, N, V, BA.
- v2.5 —
L(Legal Address) added. - v2.6 —
BDL,BR,RH,Sadded to support birth registry and service-location use cases. - v2.7 —
TM(Tube Address) added for intra-facility routing. - v2.7.1 / v2.8 / v2.8.1 — Stable. 16 codes total.
Common mistakes
- Treating
HandMas interchangeable. A patient who has moved but kept a PO box for mail has different XAD repetitions for each — collapsing them loses the mailing address. - Sending
P(Permanent) when the address is actually current. Military and student populations often have a Permanent address that is not where they presently live; misuse breaks dispatch and visit-tracking. - Omitting
BAon a known-bad address. Without the flag, the engine has no signal to stop retrying. - Mapping every XAD to FHIR
Address.use = homeregardless of XAD.7. This drops the type axis entirely and frequently mis-routes correspondence. - Confusing
BDL(Birth delivery location — where born) withBR(Residence at birth — home at birth). They are different facts and different addresses.
Examples
Sample HL7 PID-11 with two address repetitions — home and mailing:
PID|1||123456^^^MRN||DOE^JANE||19800101|F|||123 MAIN ST^^BOSTON^MA^02101^USA^H~PO BOX 99^^BOSTON^MA^02110^USA^M
Sample XAD with bad-address flag:
500 OLD ROAD^^WORCESTER^MA^01609^USA^BA
FHIR Coding JSON — Address with use + type:
{
"address": [
{
"use": "home",
"type": "physical",
"line": ["123 MAIN ST"],
"city": "BOSTON",
"state": "MA",
"postalCode": "02101",
"country": "USA"
},
{
"use": "billing",
"type": "postal",
"line": ["PO BOX 99"],
"city": "BOSTON",
"state": "MA",
"postalCode": "02110"
}
]
}
Mapping failure — XAD.7 omitted:
123 MAIN ST^^BOSTON^MA^02101
The receiver has no idea whether this is home, business, mailing, or a legal address. FHIR generation defaults Address.use to absent, which downstream consumers often treat as home incorrectly. Fix: always populate XAD.7.
FHIR mapping
The HL7 v2-to-FHIR IG splits Table 0190 across two FHIR ValueSets because FHIR factored address metadata into two independent axes:
Address.use—home,work,temp,old,billing. Bound tohttp://hl7.org/fhir/ValueSet/address-use.Address.type—postal,physical,both. Bound tohttp://hl7.org/fhir/ValueSet/address-type.
| HL7 v2 (Table 0190) | FHIR target |
|---|---|
| H | Address.use = home |
| O, B | Address.use = work |
| C | Address.use = temp |
| BA | Address.use = old |
| M | Address.use = billing |
| L, P | Address.use = home (with extension); Address.type = postal |
| BDL, BR, N | Address.type + extension (historical context) |
| S, TM, RH | Address.type = physical; extension records exact role |
| V, F | Address.use = temp (with extension for vacation/origin) |
IG references: ConceptMap-table-hl70190-to-address-use and ConceptMap-table-hl70190-to-address-type.
Engine considerations
- Two-axis split — translating to FHIR requires emitting both
useandtypefrom a single Table 0190 code; some codes (L,P,BDL) require an extension to round-trip without loss. - Repetition preservation — XAD is a repeating field; engines must preserve order and pair each XAD.7 with its address. Reordering repetitions silently is a bug.
BAsuppression — outreach, mail-merge, and direct-mail integrations should consult XAD.7 and skipBArows; logging the suppression aids audit.- Default avoidance — when XAD.7 is empty, the engine should mark
Address.useas absent rather than guesshome; the consumer then knows the type is unknown.
How Vorro handles HL70190
Vorro caches Table 0190 at startup and normalizes XAD.7 on inbound. Each XAD repetition is preserved with its type intact; BA-flagged rows are passed through but tagged with a delivery-suppression flag in the canonical model. On FHIR output, Vorro emits both Address.use and Address.type per the IG's dual ConceptMap, attaches the original HL70190 code as an extension when the FHIR mapping is lossy (e.g., BDL, TM), and never invents home for an empty XAD.7.
Related pages
- XAD data type — Extended Address
- PID segment — Patient Identification
- HL7 Table 0201 — Telecommunication Use Code
