NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Code Table6 min read

HL7 Table HL70190: Address Type

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

CodeDisplayComment
BFirm/BusinessBusiness address of a person or organization
BABad addressKnown-undeliverable; suppress outreach
BDLBirth delivery locationAddress where the person was born
BRResidence at birthResidential address at time of birth
CCurrent Or TemporaryShort-term current location
FCountry Of OriginAddress in country of origin
HHomePrimary residential address
LLegal AddressLegally-recognized address (often differs from home)
MMailingWhere to send mail (may differ from home)
NBirth (nee)Address used at birth — historical
OOfficeOffice address
PPermanentPermanent address (military, students often have separate Current)
RHRegistry homeAddress registered with a registry (e.g., immunization)
SService LocationWhere service is delivered (institutional)
TMTube AddressPneumatic tube address (intra-facility)
VVacationVacation home / seasonal address

Code system OID and canonical URI

  • OID2.16.840.1.113883.18.103
  • Canonical URIhttp://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.5L (Legal Address) added.
  • v2.6BDL, BR, RH, S added to support birth registry and service-location use cases.
  • v2.7TM (Tube Address) added for intra-facility routing.
  • v2.7.1 / v2.8 / v2.8.1 — Stable. 16 codes total.

Common mistakes

  • Treating H and M as 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 BA on a known-bad address. Without the flag, the engine has no signal to stop retrying.
  • Mapping every XAD to FHIR Address.use = home regardless of XAD.7. This drops the type axis entirely and frequently mis-routes correspondence.
  • Confusing BDL (Birth delivery location — where born) with BR (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.usehome, work, temp, old, billing. Bound to http://hl7.org/fhir/ValueSet/address-use.
  • Address.typepostal, physical, both. Bound to http://hl7.org/fhir/ValueSet/address-type.
HL7 v2 (Table 0190)FHIR target
HAddress.use = home
O, BAddress.use = work
CAddress.use = temp
BAAddress.use = old
MAddress.use = billing
L, PAddress.use = home (with extension); Address.type = postal
BDL, BR, NAddress.type + extension (historical context)
S, TM, RHAddress.type = physical; extension records exact role
V, FAddress.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 use and type from 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.
  • BA suppression — outreach, mail-merge, and direct-mail integrations should consult XAD.7 and skip BA rows; logging the suppression aids audit.
  • Default avoidance — when XAD.7 is empty, the engine should mark Address.use as absent rather than guess home; 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.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides
HL7 Table HL70190: Address Type | Vorro Academy | Vorro