HL7 RQC_I05 (Request for Patient Clinical Information) | Integration Soup HL7 Reference Guide

HL7 RQC_I05 Request for Patient Clinical Information

An older clinical-information query built on QRD and QRF.

HL7 message structure RQC_I05 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
QRD	Original-Style Query Definition	Yes	No
QRF	Original style query filter	No	No
RQC_I05.PROVIDER	Provider group	Yes	Yes
PRD	Provider Data	Yes	No
CTD	Contact Data	No	Yes
PID	Patient Identification	Yes	No
NK1	Next of Kin / Associated Parties	No	Yes
GT1	Guarantor	No	Yes
NTE	Notes and Comments	No	Yes

RQC_I05 requests patient clinical information. It belongs to the older patient referral query family and uses the original-mode query segments QRD and QRF. HL7 later retained this event for backward compatibility, and newer systems usually prefer query/response profiles such as QBP_Q11 and RSP_K11.

If you see RQC_I05 in the wild, it is often because an older system still asks for clinical history, laboratory data, or summary information this way. The response side is RCI_I05.

A small RQC I05 example

MSH|^~\&|REFERRAL|CITYCLINIC|LAB|CITYHOSP|20260718103000||RQC^I05^RQC_I05|RQC050001|P|2.5.1 QRD|20260718103000|R|I|RQC050001|||10^RD|123456^^^CITYHOSP^MR|RES|LAB QRF|LAB|20260701000000|20260718235959|CBC^Complete blood count^L PRD|RP|Nguyen^Mara^^^Dr^MD|88 Clinic Road^^Auckland^^1010^NZ|^^^CITYCLINIC|555555 CTD|PR|Care^Cara|88 Clinic Road^^Auckland^^1010^NZ|^WPN^PH^^64^9^5551000 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F NTE|1||Please return recent CBC results for referral review.

What workflow it represents

The sender is asking a clinical data holder for information about a patient. The receiver might be a lab, hospital system, clinical repository, or older referral hub. The requester needs the answer to make a clinical or administrative decision without waiting for a manual extract.

Because this message is backward-compatible older style, both sides need a very explicit local profile. QRD and QRF can identify the query, desired format, patient, department, date range, and filters, but the meaning of each field is often more local than implementers expect.

How to read the structure

MSH identifies the message. QRD is the main query definition, while QRF narrows the request with filters such as where to search or what time period matters. The provider group uses PRD and CTD to identify who is asking.

PID identifies the patient. Optional NK1, GT1, and NTE can add context, but the real query logic should be in QRD/QRF and the agreed profile.

Implementation traps

The main trap is modernizing only half the workflow. If the receiver expects QBP/QPD/RCP and the sender sends QRD/QRF, both messages may parse and still mean nothing to each other.

Another trap is assuming the response is a full chart. RQC_I05 asks for the clinical data described by the query. If the filter says lab results for a date range, missing diagnoses or procedures do not necessarily mean the patient has none.

Reference notes

HL7 v2+ patient referral material marks RQC/RCI I05 as retained for backward compatibility and notes that original-mode query and QRD/QRF were replaced by later query response message pairs. HL7 terminology also marks I05 as deprecated.