HL7 ARQ Appointment Request
HL7 field reference ARQ fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| ARQ.1 | Placer Appointment ID | Yes | No | EI | |
| ARQ.2 | Filler Appointment ID | No | No | EI | |
| ARQ.3 | Occurrence Number | No | No | NM | |
| ARQ.4 | Placer Group Number | No | No | EI | |
| ARQ.5 | Schedule ID | No | No | CE | |
| ARQ.6 | Request Event Reason | No | No | CE | |
| ARQ.7 | Appointment Reason | No | No | CE | 0276 |
| ARQ.8 | Appointment Type | No | No | CE | 0277 |
| ARQ.9 | Appointment Duration | No | No | NM | |
| ARQ.10 | Appointment Duration Units | No | No | CE | |
| ARQ.11 | Requested Start Date/Time Range | No | Yes | DR | |
| ARQ.12 | Priority-ARQ | No | No | ST | |
| ARQ.13 | Repeating Interval | No | No | RI | |
| ARQ.14 | Repeating Interval Duration | No | No | ST | |
| ARQ.15 | Placer Contact Person | Yes | Yes | XCN | |
| ARQ.16 | Placer Contact Phone Number | No | Yes | XTN | |
| ARQ.17 | Placer Contact Address | No | Yes | XAD | |
| ARQ.18 | Placer Contact Location | No | No | PL | |
| ARQ.19 | Entered By Person | Yes | Yes | XCN | |
| ARQ.20 | Entered By Phone Number | No | Yes | XTN | |
| ARQ.21 | Entered By Location | No | No | PL | |
| ARQ.22 | Parent Placer Appointment ID | No | No | EI | |
| ARQ.23 | Parent Filler Appointment ID | No | No | EI | |
| ARQ.24 | Placer Order Number | No | Yes | EI | |
| ARQ.25 | Filler Order Number | No | Yes | EI |
ARQ is the HL7 Appointment Request segment. The ARQ segment defines a request for the booking of an appointment. It is used in transactions sent from an application acting in the role of a placer.
Scheduling segments carry the appointment story in pieces: request, service, resource group, location, personnel, preferences, and timing.
The v2.5.1 structures show ARQ in SQM_S25 (Schedule query message and response), SRM_S01 (Request new appointment booking). That tells you where it can appear, but the local implementation guide still decides which optional fields are meaningful.
Scheduling flows are easier to reason about when the request, resource, and appointment fields are visible together. HL7 Soup Web is helpful for inspection, and Integration Soup can keep resource mapping and routing rules explicit.
So this page stays intentionally practical: what each field is for, what shape the generated v2.5.1 data gives it, and where I would be careful before mapping it.
ARQ-1 is the placer application's appointment request identifier. It should survive from the first request through later responses and updates, so the placer can match the filler answer back to the original request.
ARQ-2 is the filler application's identifier once the scheduler has created or recognized the appointment. It is often empty on the initial request because the filler has not assigned it yet. Once the filler returns one, keep it. Losing the filler ID is how reschedules and cancellations drift away from the booking they were supposed to change.
Both fields use EI, so the assigning authority matters. A pretty number with no namespace is fine on a screen and risky between systems.
ARQ-3 identifies one child occurrence of a repeating appointment when that occurrence does not have its own unique placer or filler appointment ID. Use it only when the parent appointment pattern and occurrence numbering are agreed. Otherwise "occurrence 3" can mean the third planned visit to one system and the third successfully booked visit to another.
ARQ-4 groups related appointment requests from the placer side. It is useful when one business request results in several appointment requests that should be kept together, such as a package of services or a referral with related bookings. Do not use it as a substitute for the individual appointment IDs in ARQ-1 and ARQ-2.
ARQ-5 points at the schedule the placer is trying to book against, such as a clinic, service, resource calendar, or local schedule code. Once the filler has assigned a unique appointment ID, that filler ID should normally carry the identity of the booked appointment. If the filler ID is only unique inside a schedule, make that schedule namespace part of the identifier design.
ARQ-6 is about why this scheduling event is happening: patient request, caregiver request, no-show handling, reschedule reason, and similar event-level context. ARQ-7 is the reason for the appointment itself, such as follow-up, routine, urgent, or consult. Those are related, but not interchangeable.
ARQ-8 classifies the appointment type. In many interfaces this is one of the fields that drives downstream rules, letters, slot templates, or clinic workflow. Use agreed codes and text; do not collapse reason, type, and service code into one local value because the receiving scheduler may need all three concepts separately.
ARQ-9 and ARQ-10 describe the requested overall appointment duration. The duration should be positive and paired with units. If the receiver defaults empty units to seconds but the sender assumed minutes, the appointment book will not be amused.
Keep this separate from the service and resource durations in AIS, AIG, AIL, and AIP. A 60-minute appointment might include a 15-minute personnel resource and a 90-minute room block.
ARQ-11 is the requested time window, not necessarily the booked time. It can repeat when the placer offers several acceptable ranges. A request like "next Tuesday morning or Thursday afternoon" belongs here more naturally than in a comment.
Send the precision you really mean. A date-only range, a morning range, and an exact timestamp are different scheduling requests. Time zones should be agreed before this field is trusted across sites.
ARQ-12 carries scheduling priority. It is not a clinical urgency field unless the implementation guide defines it that way. If priority affects slot selection, escalation, or patient communication, keep the code set small and explicit.
ARQ-13 describes the interval between repeating appointments. ARQ-14 describes how long the repeating pattern continues. Together they are the schedule pattern, not the duration of one visit.
Recurring scheduling is where ambiguity gets expensive. Agree whether skipped holidays, patient cancellations, and rescheduled occurrences keep the same occurrence numbers or create new appointment IDs.
These fields identify the person or team the filler should contact about the request. ARQ-15 is required and should carry a usable identifier or name. ARQ-16, ARQ-17, and ARQ-18 add contact phone, address, and location when the filler needs to resolve a scheduling question.
This is not necessarily the same person who entered the request. It is the operational contact from the placing side. Put a contact here who can actually answer scheduling questions, not just the clinician whose name appears elsewhere.
ARQ-19 identifies the person who entered the appointment request, with optional phone and location in ARQ-20 and ARQ-21. This is audit and follow-up context. It may be a clerk, referral coordinator, clinician, system user, or service account depending on how the placer works.
Do not confuse "entered by" with "responsible provider". If clinical responsibility matters, carry it in the appropriate provider or order/referral segments.
These fields tie this request back to a parent appointment on the placer or filler side. They are useful for repeating appointments and appointment sets where one parent request produces several child bookings.
Use parent IDs only when both systems understand the parent-child model. If every occurrence already has its own independent appointment ID, parent fields may add confusion rather than clarity.
These link the scheduling request to an order. That is a different relationship from the appointment IDs above. The appointment identifies the booking; the order identifies the requested clinical service or procedure that may need to be scheduled.
A scheduling system should not quietly create or fill an order just because a slot is available. If ARQ-24 is present, the filler order number relationship in ARQ-25 needs to be handled according to the order workflow the receiver actually supports.
Related links
- SCH - Scheduling Activity Information
- RGS - Resource Group
- AIS - Appointment Information
- AIG - Appointment Information - General Resource
- AIL - Appointment Information - Location Resource
- AIP - Appointment Information - Personnel Resource
- APR - Appointment Preferences
- TQ1 - Timing/Quantity
- SQM_S25 - Schedule query message and response
- SRM_S01 - Request new appointment booking