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
| Code | Display | Comment/Description |
|---|---|---|
| CHECKUP | Routine check-up | A scheduled non-urgent visit for general health assessment. |
| EMERGENCY | Emergency appointment | The appointment is urgent and should be prioritized. |
| FOLLOWUP | A follow up visit from previous appointment | Continuation of care related to a prior encounter. |
| ROUTINE | Routine appointment — default if not valued | The default workflow bucket; assumed when ARQ-7 / AIS-4 is empty. |
| WALKIN | A previously unscheduled walk-in visit | The 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
serviceTypefield. - Defaulting to
ROUTINEfor emergency walk-ins because the EHR's default reason isROUTINE. Downstream prioritization breaks whenEMERGENCYis suppressed. - Inventing local codes like
PHYSICALorSICKinside HL70276 without populating CWE.3 (L) to flag them as local. Strict receivers reject these as conformance failures. - Using
WALKINfor any unscheduled appointment, including phone-booked same-day appointments.WALKINspecifically 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:
| HL7 v2 (HL70276) | FHIR (Appointment.reasonCode) |
|---|---|
| CHECKUP | http://terminology.hl7.org/CodeSystem/v2-0276#CHECKUP |
| EMERGENCY | http://terminology.hl7.org/CodeSystem/v2-0276#EMERGENCY |
| FOLLOWUP | http://terminology.hl7.org/CodeSystem/v2-0276#FOLLOWUP |
| ROUTINE | http://terminology.hl7.org/CodeSystem/v2-0276#ROUTINE |
| WALKIN | http://terminology.hl7.org/CodeSystem/v2-0276#WALKIN |
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
ROUTINEper the table comment, but emit a soft warning so senders can be coached toward explicit values. - CWE coding system — Always populate CWE.3 with
HL70276when 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.codingso 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.
Related pages
- ARQ segment — Appointment Request
- HL70277 code table — Appointment Type Codes
- HL70278 code table — Filler Status Codes
