HL7 Table HL70277: Appointment Type Codes

HL70277 is the three-value HL7-defined vocabulary that classifies what kind of appointment record is being transmitted — a normal booking, a tentative "penciled-in" hold, or a backfilled record of a completed visit. It first appeared in HL7 v2.3 with the SIU scheduling chapter and has remained at three codes through v2.8.1. The table is carried in ARQ-8 Appointment Type on appointment-request transactions and in AIS-5 Appointment Type on the scheduling information segments inside SIU notifications.

Purpose

HL70277 tells the receiver whether the appointment payload is a real scheduled slot, a tentative placeholder, or a retrospective record. Each value implies a different downstream workflow:

• Normal — the appointment is a real, confirmed slot and should be displayed on the schedule.
• Tentative — the appointment is being held but not yet confirmed; the slot may still be released.
• Complete — the appointment already occurred and is being recorded for historical or billing purposes.

Without HL70277, a receiver cannot distinguish between an active booking and a backfilled historical record, which leads to double-booking, missing-arrival alerts firing on already-completed appointments, and tentative holds being treated as firm commitments.

Where it's used

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

Code list

Code system OID

• OID: 2.16.840.1.113883.18.123
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0277

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-8 or AIS-5.

HL7-defined vs user-defined

HL70277 is HL7-defined. Unlike HL70276 (Appointment Reason), the three values here are meant to be exhaustive, and there is no common pattern of vendors extending the table with local codes. The most common conformance failure is not local extension but rather case-sensitivity: senders ship NORMAL, normal, or N instead of Normal, and strict receivers reject the message.

Version differences

• v2.3 — Table introduced with the SIU/SRM scheduling chapter; all three codes present from day one.
• v2.3.1 – v2.6 — Set frozen at three codes; field binding moves from CE to CWE in profiles that adopt the modern coded element.
• v2.7 – v2.8.1 — No additions. CWE.14 OID binding becomes standard so receivers can disambiguate HL7-defined codes from any local extensions sites might attempt.
• v2.9 — HL70277 itself is unchanged. The FHIR alignment work splits the semantics across Appointment.status and Appointment.appointmentType, but the v2 codes remain mixed-case in HL70277.

Common mistakes

• Case-folding the codes to uppercase or lowercase. The table is literally mixed case — Normal, Tentative, Complete — and strict receivers compare exactly.
• Confusing HL70277 (Tentative) with HL70278 (Pending). HL70277 describes the requested type before the filler responds; HL70278 describes the filler's status after processing.
• Using Complete to mean "the booking is complete" (i.e., finished being entered) instead of "the visit has already occurred". Complete means the appointment itself happened.
• Omitting ARQ-8 and assuming the receiver will default to Normal. The spec allows this default but many strict EHRs reject empty appointment-type fields.
• Sending Normal with the SCH segment when the actual workflow is a backfilled historical record. Use Complete so the receiver does not generate arrival alerts.

Examples

A standard appointment request:

ARQ|0001^Vorro|||||||FOLLOWUP^A follow up visit from previous appointment^HL70276|Normal^Routine schedule request^HL70277|||||||||

A tentative hold while the patient considers options:

ARQ|0002^Vorro|||||||CHECKUP^Routine check-up^HL70276|Tentative^A request for a tentative appointment^HL70277

A historical record being backfilled after a walk-in:

ARQ|0003^Vorro|||||||WALKIN^A previously unscheduled walk-in visit^HL70276|Complete^Request to add a completed appointment^HL70277

Same Tentative value rendered onto FHIR (HL7 v2 Tentative collapses to Appointment.status = proposed plus a coded appointmentType):

{
  "resourceType": "Appointment",
  "status": "proposed",
  "appointmentType": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v2-0277",
      "code": "Tentative",
      "display": "A request for a tentative appointment"
    }]
  }
}

Mapping failure example — wrong case:

ARQ|0004^Vorro|||||||CHECKUP^Routine check-up^HL70276|NORMAL^Routine schedule request^HL70277

NORMAL is not a valid HL70277 code; only Normal is. A conformant engine should case-normalize to Normal, log the remap for the sender, and pass the message through rather than reject it outright.

FHIR mapping

The v2-to-FHIR IG does not publish a ConceptMap for this table; the mapping below follows the obvious correspondence: the mapping is partly to Appointment.status and partly to Appointment.appointmentType:

Because the semantics straddle two FHIR fields, round-tripping requires preserving the original HL70277 code in the appointmentType.coding array. Engines that only populate Appointment.status lose the v2 fidelity.

Engine considerations

• Case normalization — Accept lowercase and uppercase variants on ingest, normalize to the mixed-case HL70277 form on outbound. Log every normalization so senders can be coached.
• Default handling — Treat empty ARQ-8 / AIS-5 as Normal per the table comment, but emit a soft warning.
• Status separation — On FHIR outbound, populate both Appointment.status and Appointment.appointmentType rather than just one — receivers that follow strict FHIR conformance need both.
• Backfill detection — Complete records should suppress arrival reminder and missing-arrival alerts in downstream systems; flag this case in the routing layer.

How Vorro handles HL70277

Vorro validates ARQ-8 and AIS-5 against the three HL70277 codes on ingest, case-normalizing on the way in so senders who ship NORMAL or tentative do not block message flow. The original sender-supplied casing is preserved in the audit log, and the canonical mixed-case form rides on through to downstream channels.

On outbound, Vorro emits HL70277 as a CWE triplet (code^display^HL70277) for v2.5+ profiles. For FHIR-bound destinations the original v2 code is preserved as a Coding entry inside Appointment.appointmentType and the parallel Appointment.status value is computed per the v2-to-FHIR ConceptMap.

Related pages

• ARQ segment — Appointment Request
• HL70276 code table — Appointment Reason Codes
• HL70278 code table — Filler Status Codes

Sources

• HL7 Terminology — CodeSystem v2-0277 Appointment Type Codes
• HL7 v2 product brief