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 HL70276: Appointment Reason Codes

HL70276 is the small HL7-defined vocabulary that classifies why an appointment is being requested or booked. It first appeared in HL7 v2.3 alongside the SIU scheduling message family and has remained stable through v2.8.1. The table is carried in ARQ-7 Appointment Reason on appointment-request transactions and in AIS-4 Appointment Reason on the scheduling information segments inside SIU notifications.

Purpose

HL70276 answers the categorical question "what kind of visit is this" — not the clinical indication, not the chief complaint, but the workflow bucket the scheduler should drop the appointment into. A ROUTINE reason tells the scheduling system to treat the appointment as a standard pre-booked slot; WALKIN tells the same system that the patient is already on site; EMERGENCY flags the appointment for priority handling.

The table is intentionally coarse. Sites that need a richer set of reasons — for example, "annual physical" vs "diabetes follow-up" — typically pair the HL70276 code with a CWE-bound user-defined value set, or carry the richer concept in a separate AIS field or a downstream Appointment.serviceType.

Where it's used

  • ARQ-7 Appointment Reason — the canonical home, populated on SRM appointment-request transactions (S01, S03, S05, S07).
  • AIS-4 Appointment Reason — carried on the AIS (Appointment Information — Service) segment inside SIU notifications (S12, S13, S14, S15, S17, S26).
  • SCH-7 Appointment Reason — present on the SCH master scheduling segment in older v2.3/v2.3.1 profiles.

Code list

CodeDisplayComment/Description
CHECKUPRoutine check-upA scheduled non-urgent visit for general health assessment.
EMERGENCYEmergency appointmentThe appointment is urgent and should be prioritized.
FOLLOWUPA follow up visit from previous appointmentContinuation of care related to a prior encounter.
ROUTINERoutine appointment — default if not valuedThe default workflow bucket; assumed when ARQ-7 / AIS-4 is empty.
WALKINA previously unscheduled walk-in visitThe patient arrived without an appointment and was booked on the spot.

Code system OID

  • OID: 2.16.840.1.113883.18.122
  • Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0276

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile demands OID-bound coded values for ARQ-7 or AIS-4.

HL7-defined vs user-defined

HL70276 is HL7-defined, but the field that carries it (ARQ-7) is bound as CWE/CE in modern profiles, which means receivers are expected to accept additional coded values from local or user-defined extensions alongside the five HL7 codes. In practice this is the most common cause of mapping problems: senders ship PHYSICAL, ANNUAL, NEWPT, and other vendor codes in ARQ-7 because the field looks user-defined, while strict downstream profiles reject anything outside the HL7-defined five.

Version differences

  • v2.3 — Table introduced with the SIU/SRM scheduling chapter; all five codes present from day one.
  • v2.3.1 – v2.6 — Set frozen at five codes; field binding moves from CE to CWE in some profiles.
  • v2.7 – v2.8.1 — No additions to the code list. CWE.14 OID binding becomes standard so receivers can disambiguate HL7-defined codes from local extensions.
  • v2.9 — HL70276 itself is unchanged; FHIR alignment work shifts the recommended downstream binding toward Appointment.reasonCode.

Common mistakes

  • Sending free text in ARQ-7.2 ("annual physical") instead of a code in ARQ-7.1. The first component is the code; the second is the human-readable display.
  • Treating HL70276 as a clinical reason code and trying to populate it with ICD-10 or SNOMED CT values. Those belong in a separate diagnosis or serviceType field.
  • Defaulting to ROUTINE for emergency walk-ins because the EHR's default reason is ROUTINE. Downstream prioritization breaks when EMERGENCY is suppressed.
  • Inventing local codes like PHYSICAL or SICK inside HL70276 without populating CWE.3 (L) to flag them as local. Strict receivers reject these as conformance failures.
  • Using WALKIN for any unscheduled appointment, including phone-booked same-day appointments. WALKIN specifically means the patient is physically present.

Examples

A minimal ARQ requesting a routine follow-up:

ARQ|0001^Vorro|||||||FOLLOWUP^A follow up visit from previous appointment^HL70276|||||||||||

An emergency walk-in:

ARQ|0002^Vorro|||||||WALKIN^A previously unscheduled walk-in visit^HL70276|||||||||||
AIS|1||99213^Office Visit^CPT|20260625103000|||||EMERGENCY^Emergency appointment^HL70276

Same FOLLOWUP reason mapped to a FHIR Appointment.reasonCode:

{
  "resourceType": "Appointment",
  "status": "booked",
  "reasonCode": [{
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v2-0276",
      "code": "FOLLOWUP",
      "display": "A follow up visit from previous appointment"
    }]
  }]
}

Mapping failure example — unknown vendor code:

ARQ|0003^Vorro|||||||PHYSICAL^Annual Physical^HL70276

PHYSICAL is not in HL70276. A conformant engine should either remap it to CHECKUP (and log the remap), or preserve PHYSICAL with CWE.3 set to L and route the message to a curation queue so the receiver sees an explicit local code rather than a silently malformed HL7-defined one.

FHIR mapping

The HL7 v2-to-FHIR Implementation Guide publishes ConceptMap-table-hl70276-to-sct, which projects the five HL7 codes onto Appointment.reasonCode:

Appointment.reasonCode is a CodeableConcept bound with example strength to http://hl7.org/fhir/ValueSet/encounter-reason, so the v2 codes can be carried verbatim using the v2-0276 system URI without needing to be translated into SNOMED CT.

Engine considerations

  • Default handling — Treat an empty ARQ-7 as ROUTINE per the table comment, but emit a soft warning so senders can be coached toward explicit values.
  • CWE coding system — Always populate CWE.3 with HL70276 when emitting HL7-defined codes, so downstream receivers can distinguish them from local extensions.
  • Local extension protocol — When a sender insists on PHYSICAL, ANNUAL, or other vendor codes, place them in a separate user-defined table (commonly mirrored in CWE.4/.5/.6) rather than overloading HL70276.
  • FHIR round-trip — Preserve the original HL70276 code in Appointment.reasonCode.coding so a future v2 outbound channel can restore the exact code.

How Vorro handles HL70276

Vorro validates ARQ-7 and AIS-4 against the five HL70276 codes on ingest. Recognized values are passed through to downstream channels unchanged. Unknown vendor codes — PHYSICAL, ANNUAL, NEWPT, and the long tail — are routed to the terminology curation queue, where an integration engineer either maps them to one of the five canonical codes (and a permanent remap rule is created) or marks them as local extensions and the original code rides through with CWE.3 set to L.

On outbound, Vorro emits HL70276 as a CWE triplet (code^display^HL70276) for v2.5+ profiles. For FHIR-bound destinations the original v2 code is preserved as a Coding entry inside Appointment.reasonCode so SIU round-trips do not lose fidelity.

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 HL70276: Appointment Reason Codes | Vorro Academy | Vorro