HL7 RCP Segment: Response Control Parameter

The RCP (Response Control Parameter) segment governs how a query response should be returned. It does not say what to search for, that is the job of QPD; instead it controls the response shape: the priority of the query, the maximum quantity of records to return, the modality of delivery, when execution should occur, sort order, and which segment groups to include. RCP travels alongside QPD inside a QBP (query by parameter) message and lets the requester tune the response without changing the query criteria.

Purpose

The purpose of RCP is to let the requester express delivery and result-set preferences for a query. Query Priority indicates whether the responder should answer immediately or defer. Quantity Limited Request caps how many records come back and in what units, which is the foundation of paging. Response Modality selects how the result is delivered, for example in real time or as a batch. The remaining fields cover scheduled execution time, a modify indicator for changes to a prior request, repeating sort-by instructions, and repeating segment-group inclusion controls. RCP keeps these response-shaping concerns out of QPD, giving a clean separation between what is queried and how the answer is returned.

Used in

RCP is part of the modern query group built on the Query by Parameter framework. It is used in:

QBP (query by parameter) request messages, where RCP shapes the response alongside QPD. See QBP and the query framework.

A client builds a QBP message in which QPD defines the query and RCP controls the response. The responder returns an RSP message led by QID and QAK; the hit counts QAK reports reflect the quantity limit RCP requested.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (RCP.html) 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
RCP-1	Query Priority	id	—	O	—	HL70091	Immediate or deferred response priority
RCP-2	Quantity Limited Request	cq	—	O	—	HL70126	Max records to return and their units
RCP-3	Response Modality	ce	—	O	—	HL70394	How the response is delivered
RCP-4	Execution and Delivery Time	ts	—	O	—	—	When the query should run or be delivered
RCP-5	Modify Indicator	id	—	O	—	—	Whether this modifies a prior request
RCP-6	Sort-by Field	srt	—	O	Y	—	Field and direction to sort results by
RCP-7	Segment group inclusion	id	—	O	Y	—	Segment groups to include in the response

Most-used fields

RCP-1 Query Priority: drawn from HL70091, it tells the responder whether to answer immediately (I) or defer (D). It is the field most responders branch on first.
RCP-2 Quantity Limited Request: a CQ pairing a count with a units code from HL70126 (for example RD for records). This is the backbone of paging and the most common reason to send RCP at all.
RCP-3 Response Modality: from HL70394, selects real-time versus batch delivery.
RCP-6 Sort-by Field: a repeating field that lets the requester order results by one or more fields, each with a sort direction.

Version differences (2.3 to 2.8.2)

RCP is the response-control half of the Query by Parameter framework introduced in 2.4 and 2.5. It does not exist in 2.3, where response control was handled by fields within the older QRD/QRF query group. From 2.4 through 2.8.2 the RCP layout is stable: Query Priority, Quantity Limited Request, Response Modality, Execution and Delivery Time, Modify Indicator, and the repeating Sort-by Field and Segment-group-inclusion fields keep their positions. The Response Modality field uses the CE data type in 2.5.1; later versions favor CWE for coded elements, but the position and meaning are unchanged. The associated tables, HL70091 (priority), HL70126 (quantity-limited-request units), and HL70394 (modality), were refined across versions, so confirm permitted values against your trading partner's version.

Common mistakes

Putting search criteria in RCP. Criteria belong in QPD; RCP only controls response shape.
Sending a bare number in RCP-2. Quantity Limited Request is a CQ: it needs both a quantity and a units code from HL70126, for example 25^RD&Records&HL70126.
Using unlisted priority or modality codes. RCP-1 (HL70091) and RCP-3 (HL70394) draw from coded tables; off-table values break responder logic.
Treating Sort-by as single-valued. RCP-6 repeats; multi-key sorting requires multiple repetitions, not a packed single value.
Assuming the responder honors every control. Quantity limits, modality, and sort are requests; a conformant responder may apply its own caps, so always read the QAK hit counts to learn what actually came back.

Examples

Minimal valid segment (priority only, the common immediate-response case):

RCP|I

Fully-populated segment, an immediate query limited to 25 records, real-time modality, sorted by name ascending:

RCP|I|25^RD&Records&HL70126|R^Real-Time^HL70394|20260610101459|N|PatientName^A|PID

Annotated breakdown:

RCP|I|25^RD&Records&HL70126|R^Real-Time^HL70394|20260610101459|N|PatientName^A|PID
    | |                     |                    |              | |             |
    | |                     |                    |              | |             +-> RCP-7 Segment group inclusion = PID
    | |                     |                    |              | +---------------> RCP-6 Sort-by Field = PatientName, Ascending
    | |                     |                    |              +-----------------> RCP-5 Modify Indicator = N (new request)
    | |                     |                    +--------------------------------> RCP-4 Execution/Delivery Time = 20260610101459
    | |                     +-----------------------------------------------------> RCP-3 Response Modality = R (real-time)
    | +---------------------------------------------------------------------------> RCP-2 Quantity Limited Request = 25 records
    +-----------------------------------------------------------------------------> RCP-1 Query Priority = I (immediate)

In-context excerpt 1, a patient demographics request inside a QBP^Q11 message, with QPD and RCP:

MSH|^~&|EHR|CLINIC_A|MPI|CENTRAL|20260610101459||QBP^Q11^QBP_Q11|MSG00042|P|2.5.1
QPD|Z44^Demographics Query^HL70471|Q4815162342|DOE^JANE|19850214|F
RCP|I|25^RD&Records&HL70126|R

In-context excerpt 2, a visit-history request that pages a larger result set and sorts by date:

MSH|^~&|EHR|CLINIC_A|MPI|CENTRAL|20260610101600||QBP^Q11^QBP_Q11|MSG00044|P|2.5.1
QPD|Z45^Visit History Query^HL70471|Q9001234567|MR67890^^^CLINIC_A^MR|20250101|20260101
RCP|I|50^RD&Records&HL70126|R^Real-Time^HL70394||N|VisitDate^D

FHIR mapping

RCP is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR Implementation Guide for RCP because query/response infrastructure has no direct FHIR resource equivalent. In FHIR, the controls RCP expresses are handled by RESTful search mechanics: the quantity limit maps to the _count parameter, sort order to _sort, segment-group inclusion to _include and _elements, and paging to Bundle links. There is no segment-level field translation, so engines bridging v2 query traffic to FHIR project RCP's controls onto the corresponding search parameters rather than transforming RCP directly.

Engine considerations

Interface engines read RCP to configure how they execute and return a query. The Quantity Limited Request in RCP-2 drives paging, so engines parse its CQ structure into a count and a units code and apply the appropriate page size. Query Priority in RCP-1 routes immediate versus deferred handling. Because RCP-6 (Sort-by Field) and RCP-7 (Segment group inclusion) repeat, engines must iterate their repetitions rather than reading a single value. A robust engine also treats RCP controls as advisory: it enforces its own maximum quantity and reflects the actual count back through the response QAK, so clients learn what was really returned.

How Vorro parses and produces RCP

When parsing an inbound QBP, Vorro reads RCP to set response controls: it decodes RCP-2 into a normalized page size and units, maps RCP-1 priority and RCP-3 modality against their tables, and iterates the repeating RCP-6 sort instructions and RCP-7 inclusion entries into ordered lists. When producing an RCP, Vorro emits the priority, builds a well-formed CQ for the quantity limit, and writes each sort key and segment-group inclusion as a separate repetition. It keeps query criteria in the companion QPD and ensures the requested limits are reflected consistently against the hit counts the responder reports in QAK.

Sources

← Back to HL7 v2 Guide