The RGS (Resource Group) segment groups together the resource segments that make up a scheduled appointment. It acts as a header for a set of resource detail segments — AIG (general resource), AIL (location resource), AIP (personnel resource), and AIS (service / appointment information) — so a scheduling message can organize the many resources a single appointment may require. RGS is a small but structurally important segment in the sch-appointments group, sitting between the request/notification (ARQ or SCH) and the resource detail it introduces.
Purpose
RGS exists to bundle resources. A complex appointment may need a room, a piece of equipment, and a clinician; RGS provides a numbered group that those resource segments belong to, plus an action code describing what should happen to the group (add, update, delete) and an optional identifier for the group. By repeating RGS, a message can describe several distinct resource groups for one appointment — for example one group per occurrence in a series. The resource detail segments that follow each RGS describe the actual resources.
Used in
RGS appears in both scheduling message families and always introduces resource detail segments:
- SRM (Schedule Request Message) — RGS follows ARQ (and any APR) and groups the requested resource segments.
- SIU (Unsolicited Scheduling Information) — RGS follows SCH and groups the resources of the booked appointment. See /academy/hl7/messages/siu.
In both, RGS groups the appointment resource segments: AIG (general/equipment resource), AIL (location), AIP (personnel), and AIS (service). RGS may repeat, and each RGS is followed by the resource segments that belong to it.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (RGS javadoc) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| RGS-1 | Set ID - RGS | si | — | R | — | — | Sequence number identifying this resource group |
| RGS-2 | Segment Action Code | id | — | R | — | HL70206 | Action to take on the group (add/update/delete) |
| RGS-3 | Resource Group ID | ce | — | O | — | — | Optional identifier/name for the resource group |
Most-used fields
- RGS-1 Set ID - RGS — required; numbers the resource group within the message starting at 1. Repeating RGS segments increment this so the resource detail can be tied to the correct group.
- RGS-2 Segment Action Code — required; from HL70206, it tells the receiver whether to add, update, or delete the group. Common values include
A(add/insert),U(update),D(delete), andX(no change). - RGS-3 Resource Group ID — optional coded identifier or name for the group, useful when the receiver wants a human-readable or system label for the bundle of resources.
Version differences (2.3 to 2.8.2)
- 2.3 — RGS was introduced with the scheduling chapter as a three-field grouping segment (set ID, action code, group ID). The structure has been stable since.
- 2.4 / 2.5 / 2.5.1 — No structural change. The HL70206 Segment Action Code table governs RGS-2 throughout. This page documents the 2.5.1 form.
- 2.6 / 2.7 / 2.8 / 2.8.2 — RGS remains a three-field segment. Later versions refine the CE component definitions behind RGS-3 and the action-code wording but do not add or remove fields.
The normalized takeaway: RGS is one of the simplest and most stable scheduling segments — three fields in every modern version, with RGS-1 and RGS-2 required.
Common mistakes
- Skipping the Set ID. RGS-1 is required and must increment across repeating RGS segments. Reusing or omitting it breaks the grouping of resource detail.
- Leaving RGS-2 blank. The Segment Action Code is required and must come from HL70206. An empty or invalid action code is a common validation failure.
- Misordering resource segments. The resource detail segments (AIG, AIL, AIP, AIS) must follow their RGS, not precede it. Out-of-order resource segments orphan themselves from any group.
- Forgetting RGS can repeat. When an appointment needs multiple resource groups, emit one RGS per group with an incrementing set ID rather than cramming resources under a single group.
- Treating RGS-3 as required. Resource Group ID is optional; many implementations leave it empty and rely on RGS-1 for grouping.
Examples
Minimal
RGS|1|A
Fully populated
RGS|1|A|RG-MRI^MRI Group^L
Annotated breakdown
RGS|1|A|RG-MRI^MRI Group^L
| | |
| | └─ RGS-3 Resource Group ID (CE): RG-MRI "MRI Group" (local coding system)
| └──── RGS-2 Segment Action Code (ID), REQUIRED, HL70206: A = add/insert
└─────── RGS-1 Set ID - RGS (SI), REQUIRED: group number 1
In context — SRM^S01 schedule request
MSH|^~&|SCHEDAPP|EAST-CLINIC|FILLER|EAST-CLINIC|20260610093000||SRM^S01^SRM_S01|MSG00231|P|2.5.1
ARQ|PLAC-77821^EAST-CLINIC||1|GRP-3391^EAST-CLINIC|SCHED-RAD^Radiology^L|||MRI^MRI Brain^L|30|MIN^minutes^UCUM|20260618080000^20260618170000|R
APR|^PreferredTime^Morning|^Resource^RES-MRI-02|^Location^EAST-CLINIC|15|^AllowOverride^N
RGS|1|A|RG-MRI^MRI Group^L
AIG|1|A|RES-MRI-02^MRI Scanner 2^L|EQUIP
AIS|1|A|MRI^MRI Brain^L
In context — SIU^S12 booked notification with two resource groups
MSH|^~&|FILLER|EAST-CLINIC|EHR|EAST-CLINIC|20260610101500||SIU^S12^SIU_S12|MSG00232|P|2.5.1
SCH|PLAC-77821^EAST-CLINIC|FILL-55012^EAST-CLINIC|||SCHED-RAD^Radiology^L|MRI^MRI Brain^L||30|MIN^minutes^UCUM|^^^20260618083000^20260618090000
RGS|1|A|RG-MRI^MRI Group^L
AIG|1|A|RES-MRI-02^MRI Scanner 2^L|EQUIP
AIS|1|A|MRI^MRI Brain^L
RGS|2|A|RG-STAFF^Staffing Group^L
AIP|1|A|TECH-014^Reyes^Maria^^^^^^EAST-CLINIC|RT^Radiologic Technologist^L
FHIR mapping
| Source | Target | Notes |
|---|---|---|
| RGS | Not mapped at the segment level | No segment-level ConceptMap is published in the v2-to-FHIR IG for RGS. Scheduling data maps conceptually to the FHIR Appointment, Schedule, and Slot resources. |
RGS has no direct FHIR equivalent — it is a grouping construct. Conceptually, the resources it groups become Appointment.participant entries (and the referenced actors, locations, and devices) in FHIR, but the group header itself is not carried as a discrete FHIR element.
Engine considerations
- Enforce RGS-1 (Set ID) and RGS-2 (Segment Action Code) presence; both are required. Validate RGS-2 against HL70206.
- Preserve the order of resource detail segments after each RGS so grouping is not lost on transform.
- When RGS repeats, keep the set ID monotonic and attach each following resource segment to the nearest preceding RGS.
- RGS-3 may be empty; do not fail messages that omit it.
How Vorro parses and produces RGS
When parsing, Vorro reads RGS-1 and RGS-2 as required fields, validates the action code against HL70206, and builds a resource-group object that collects the following AIG, AIL, AIP, and AIS segments until the next RGS or the end of the appointment grouping. RGS-3 is captured as an optional label.
When producing RGS, Vorro emits one RGS per resource group with an incrementing set ID, always writes a valid Segment Action Code, and orders the resource detail segments immediately after their RGS. RGS-3 is written only when a group identifier is available. The output stays consistent with the ARQ and SCH segments produced in the same message build so the scheduling group is well-formed.
