HL7 Table HL70482: Order Type

HL70482 is a minimal two-value HL7-defined code table introduced in v2.5 to capture whether an order was placed in an inpatient or outpatient context. It sits behind ORC-29 Order Type on every order (ORM, OMG, OMP, OML, OMD, OMS) and order-status (ORR, ORL) message. Despite its simplicity, the field is load-bearing for downstream billing and routing: pharmacy systems use it to choose between inpatient unit-dose dispensing and outpatient retail dispensing; lab systems use it to choose between in-house and reference processing; revenue cycle uses it to apply the correct fee schedule.

Purpose

ORC-29 tells the receiver which encounter context owns the order. The answer is not always the same as the patient's current PV1-2 patient class: a patient may be physically inpatient when a discharge medication is ordered for outpatient pickup, or physically outpatient when an admission order kicks off an inpatient stay. HL70482 lets the placer state the intended order context explicitly rather than forcing the receiver to infer it.

The table is intentionally narrow — two values — because that is the only distinction that matters for most downstream routing. Sites that need richer context (observation, ambulatory surgery, home health) carry that on PV1-2 (HL70004) or on the order's billing fields, not on ORC-29.

Where it's used

ORC-29 Order Type — the canonical and only home of HL70482, carried on every ORC segment in v2.5+ profiles.

Code list

Code	Display	Comment/Description
I	Inpatient Order	Order was placed in or intended for an inpatient encounter context.
O	Outpatient Order	Order was placed in or intended for an outpatient encounter context.

Code system OID

OID: 2.16.840.1.113883.18.314
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0482

The OID resolves on the HL7 Terminology server and is emitted in CWE.14 when ORC-29 is transmitted as CWE (its native data type from v2.5 onward).

HL7-defined vs user-defined

HL70482 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and the code set is normative — receivers must accept both values without local extension, and senders must not invent additional codes inside this table. Sites occasionally try to add OBS (observation) or ED (emergency department) to HL70482; the conformant answer is to carry observation status on a separate field, not to extend HL70482.

Version differences

v2.1 – v2.4 — ORC-29 and HL70482 did not exist. Order context was inferred from the linked PV1-2.
v2.5 — HL70482 introduced with I and O. ORC-29 added to the ORC segment as a CWE field bound to this table.
v2.6 – v2.8.1 — Set frozen at two codes; no further additions.
v2.9 — HL70482 itself unchanged; the v2-to-FHIR Implementation Guide formalizes the mapping to FHIR Encounter.class.

Common mistakes

Sending PV1-2 (Patient Class) values like E, P, or B in ORC-29. PV1-2 is HL70004, not HL70482; the codes are case-similar but the tables are different and ORC-29 will fail conformance validation.
Leaving ORC-29 blank because "PV1 already says inpatient." ORC-29 is the order's stated context, which can legitimately differ from the patient's current encounter class (a discharge-pickup script is an O order placed during an I encounter).
Using lowercase i or o. HL70482 codes are case-sensitive uppercase; normalize on ingest.
Treating ORC-29 as a free-text field. It is CWE bound to HL70482; downstream pharmacy and lab systems will reject anything outside the two codes.
Extending HL70482 locally with OBS, ED, SDS, or vendor-specific values. HL70482 is HL7-defined; locally extended codes break conformance and FHIR mapping.

Examples

A minimal ORC for an inpatient medication order:

ORC|NW|ORD12345^EHR|FILL98765^PHARM||CM||||20260612083000|NUR123^JONES^ANNE||PHYS456^WELBY^MARCUS||||||||||I^Inpatient Order^HL70482

An outpatient lab order placed during an ambulatory clinic visit:

ORC|NW|ORD22222^EHR|FILL55555^LAB||CM||||20260612110000|NUR789^SMITH^JOHN||PHYS456^WELBY^MARCUS||||||||||O^Outpatient Order^HL70482

FHIR ServiceRequest + Encounter snippet conveying the same I context. The order type drives the linked Encounter's class:

{
  "resourceType": "ServiceRequest",
  "id": "ord-12345",
  "status": "active",
  "intent": "order",
  "encounter": { "reference": "Encounter/enc-77" },
  "extension": [{
    "url": "http://terminology.hl7.org/CodeSystem/v2-0482",
    "valueCoding": {
      "system": "http://terminology.hl7.org/CodeSystem/v2-0482",
      "code": "I",
      "display": "Inpatient Order"
    }
  }]
}

And the linked Encounter:

{
  "resourceType": "Encounter",
  "id": "enc-77",
  "status": "in-progress",
  "class": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "IMP",
    "display": "inpatient encounter"
  }
}

Mapping failure example — vendor code in ORC-29:

ORC|NW|ORD99999^EHR|FILL11111^PHARM||CM||||20260612||||||||||||||OBS^Observation^LOCAL

OBS is not in HL70482. A conformant engine should route the message to the curation queue, preserve the original OBS in the audit log, and either remap to O (the closest HL7-defined value for an outpatient observation order) or pass through with a soft warning so downstream pharmacy or lab systems are not silently fed an unrecognized value.

FHIR mapping

The v2-to-FHIR Implementation Guide maps ORC-29 onto the linked Encounter.class rather than onto a coded element of ServiceRequest itself:

HL7 v2 (HL70482)	FHIR (v3 ActCode on Encounter.class)
I	IMP (inpatient encounter)
O	AMB (ambulatory)

Encounter.class is bound to http://terminology.hl7.org/CodeSystem/v3-ActCode. Because the FHIR mapping replaces the v2 code with a different code system, the original HL70482 code should be preserved as an extension on the ServiceRequest if the receiver needs to round-trip back to HL7 v2.

Engine considerations

Single-character validation — ORC-29's code component is one character; engines should reject multi-character payloads in the code subfield rather than truncate.
Case sensitivity — HL70482 codes are case-sensitive uppercase; normalize on ingest.
CWE structure — ORC-29 is CWE-typed even in v2.5 profiles; engines must populate CWE.1 (code), CWE.2 (display), and CWE.3 (system) and may populate CWE.14 (OID) for v2.7+ destinations.
Round-trip preservation — When mapping to FHIR Encounter.class, store the original HL70482 code as an extension on the ServiceRequest so the v2 outbound channel can restore ORC-29.

How Vorro handles HL70482

Vorro validates ORC-29's code subfield against the two HL70482 values on ingest. Values that match are forwarded to downstream channels untouched. Values that fail validation — including lowercase variants, vendor extensions like OBS or ED, and accidental display strings in CWE.1 — are routed to the terminology curation queue, where a remap rule resolves them to I or O while preserving the original in the audit log.

On outbound, Vorro emits HL70482 as CWE with CWE.3 set to HL70482 for v2.5–v2.6 destinations and with CWE.14 set to 2.16.840.1.113883.18.314 for v2.7+ destinations that advertise OID-bound coded values. When translating to FHIR, the original HL70482 code is preserved as an extension on the target ServiceRequest so the v2 outbound channel can restore ORC-29 byte-for-byte.

Sources

← Back to HL7 v2 Guide