HL7 Table HL70279: Allow Substitution Codes

HL70279 governs whether a scheduling filler may substitute the resource (service, equipment, location, or personnel) that a placer originally requested. It is a four-value code table that rides on every appointment-information segment — AIS for services, AIG for general resources, AIL for locations, AIP for personnel — and is the field that determines how flexible the placer is willing to be when the filler must reshuffle the calendar.

Purpose

HL70279 answers a workflow question: if the originally-requested resource is unavailable at the requested time, what should the filler do. The answer ranges from "do not substitute under any circumstances" (No) through "go ahead and substitute, no notification needed" (Yes) with two intermediate states — Confirm (must contact the placer before substituting) and Notify (may substitute, but must tell the placer afterward).

Because the table is HL7-defined, every conformant v2 receiver is expected to recognize all four values without local extension. Sites that need richer substitution semantics — preferred-substitute lists, substitution-by-role rules — carry that information in companion segments rather than overloading HL70279.

Where it's used

AIS-6 Allow Substitution Code — substitution policy for the service requested on an appointment.
AIG-6 Allow Substitution Code — substitution policy for a general resource (medication, supply, generic equipment).
AIL-6 Allow Substitution Code — substitution policy for the location (room, bed, clinic).
AIP-6 Allow Substitution Code — substitution policy for personnel (provider, technician).

The same code table is reused across all four AI* segments because the placer/filler substitution semantics are identical regardless of the resource type.

Code list

Code	Display	Comment/Description
Confirm	Contact filler before substituting	The filler must contact the placer and receive explicit approval before substituting an alternate resource.
No	Substitution not allowed	The filler must use the originally-requested resource; if it is unavailable, the appointment cannot be scheduled.
Notify	Notify filler if substitution occurred	The filler may substitute freely but must notify the placer that a substitution was made (typically via an SIU^S15 update or a free-text NTE).
Yes	Substitution allowed	The filler may substitute any clinically-appropriate alternate resource without contacting or notifying the placer.

Code system OID

OID: 2.16.840.1.113883.18.125
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0279

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream v2.7+ profile demands OID-bound coded values on AIS-6, AIG-6, AIL-6, or AIP-6.

HL7-defined vs user-defined

HL70279 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and the code set is normative — receivers must accept all four values without local extension. Sites that need a richer substitution taxonomy (preferred-substitute lists, role-based substitution rules) carry the additional concept on a companion segment or extension rather than extending HL70279 locally.

Unlike most HL7 v2 code tables, HL70279 uses mixed-case word values (Confirm, No, Notify, Yes) rather than short single- or two-letter codes. This is unusual and trips up engines that assume v2 codes are always short uppercase tokens. Case is normative — YES and yes are not valid; only Yes is.

Version differences

v2.3 — Table introduced with the SIU appointment-scheduling chapter; all four codes present from the start.
v2.3.1 – v2.8.1 — Set frozen at four codes; no additions, no deprecations.

Common mistakes

Sending uppercase variants — YES, NO, CONFIRM, NOTIFY. HL70279 is case-sensitive and uses title-case word values; receivers that strictly validate will reject the uppercase forms.
Sending single-character abbreviations — Y, N, C. These are intuitive but not in HL70279.
Treating empty AIS-6/AIG-6/AIL-6/AIP-6 as No. Empty means "not asserted", and most filler systems default to Confirm rather than No when the field is empty — leading to unnecessary callbacks.
Putting the substitution flag on the wrong segment. Substitution policy for a clinician belongs on AIP-6, not AIS-6; many implementers populate only AIS-6 and lose personnel-specific substitution rules.
Confusing Notify with Confirm. Notify is after-the-fact information; Confirm blocks the substitution until the placer responds.

Examples

A scheduling request that allows free substitution of personnel:

AIP|1|A|9876^SMITH^JOHN^A^^DR^MD|||20260615090000|||30|min|Yes

A request that forbids substitution of the requested location:

AIL|1|A|OR3^Operating Room 3^MAIN||||20260615090000|||240|min|No

A service request that requires confirmation before substituting:

AIS|1|A|EKG12^Twelve-lead ECG^CPT|20260615090000|||15|min|Confirm

A general-resource request where the filler may substitute but must notify:

AIG|1|A|VENT01^Ventilator unit 1^EQUIP|EQUIP|||20260615090000|||120|min|Notify

Same Confirm value translated to a FHIR Appointment snippet (no published ConceptMap; using a sender-defined extension):

{
  "resourceType": "Appointment",
  "extension": [{
    "url": "http://example.org/fhir/StructureDefinition/allow-substitution",
    "valueCoding": {
      "system": "http://terminology.hl7.org/CodeSystem/v2-0279",
      "code": "Confirm",
      "display": "Contact filler before substituting"
    }
  }]
}

Mapping failure example — single-character abbreviation:

AIS|1|A|EKG12^Twelve-lead ECG^CPT|20260615090000|||15|min|C

C is not in HL70279 (the code is Confirm, not C). A conformant engine should route the message to a curation queue, preserve the original C in the audit log, and either remap to Confirm (the obvious intent) or pass through with a soft warning so downstream scheduling systems are not silently fed bad data.

FHIR mapping

There is no published HL7 v2-to-FHIR ConceptMap for HL70279 because the substitution-policy concept has no canonical home in the FHIR Appointment resource. Implementations that need to preserve the policy across a v2-to-FHIR-to-v2 round trip typically carry it as a sender-defined extension on Appointment.participant (when the substitution policy is per-participant) or on the Appointment root (when it applies to the whole appointment).

In all cases, the HL70279 code value (Confirm, No, Notify, Yes) is preserved verbatim in Coding.code with system set to http://terminology.hl7.org/CodeSystem/v2-0279. The mixed-case nature of the codes is preserved exactly.

Engine considerations

Mixed-case validation — Unlike most HL7 v2 code tables, HL70279 uses title-case word values. Engines must not uppercase or lowercase on ingest; YES and yes must be flagged as invalid (or remapped) rather than silently coerced.
Word-length validation — Codes are up to seven characters (Confirm). Engines that assumed v2 codes are always one or two characters and truncated AIS-6/AIG-6/AIL-6/AIP-6 will silently corrupt the value.
CWE upgrade path — In v2.7+ profiles AIS-6 (and siblings) may be transmitted as CWE rather than IS, allowing OID metadata in CWE.14 (2.16.840.1.113883.18.125). Engines must handle both shapes.
Default policy — When AIS-6 is empty, most filler systems behave as if Confirm were sent; placers that want a more permissive default should populate the field explicitly with Yes or Notify.
Cross-segment consistency — When the same appointment carries AIS, AIG, AIL, and AIP segments, each may have its own substitution policy. Receivers should not assume that AIS-6 applies to personnel; AIP-6 governs personnel separately.

How Vorro handles HL70279

Vorro validates AIS-6, AIG-6, AIL-6, and AIP-6 against the four HL70279 codes on ingest, preserving case exactly. Values that match are forwarded to all downstream channels untouched. Values that fail validation — uppercase variants, single-character abbreviations, and accidental display strings — are routed to the terminology curation queue, where they either resolve to one of the four canonical codes (and a remap rule is created) or pass through with a soft warning so downstream scheduling systems are not silently fed bad data.

On outbound, Vorro emits HL70279 as IS for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations that advertise OID-bound coded values. The original HL70279 code is always preserved when round-tripping through FHIR Appointment extensions.

Sources

← Back to HL7 v2 Guide