HL7 RQP_I04 (Request for Patient Demographic Data) | Integration Soup HL7 Reference Guide

HL7 RQP_I04 Request for Patient Demographic Data

A request for the current patient, billing, and contact picture.

HL7 message structure RQP_I04 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
RQP_I04.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

RQP_I04 asks another system or organization for patient demographic information. HL7 describes the event as a provider-to-provider request that may also be directed to a payor, and it can include insurance and billing context.

Think of it as an older, message-based way to ask "what do you know about this patient?" The response is RPI_I04, usually carrying the richer demographics and insurance detail.

A small RQP I04 example

MSH|^~\&|REFERRAL|CITYCLINIC|MPI|CITYHOSP|20260718101500||RQP^I04^RQP_I04|RQP040001|P|2.5.1 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 current demographics, next of kin, guarantor, and billing contacts.

What workflow it represents

The sender may be trying to populate a referral, registration, billing, or care coordination workflow without re-keying the patient. The receiver is the system that has the better demographic record or the payer-adjacent data the requester needs.

This kind of request should be treated carefully because demographics look simple until identity matching goes wrong. The safest requests include a trusted identifier, enough demographics to support matching, and a clear note or local profile that says which data elements are expected back.

How to read the structure

MSH identifies the request and its control ID. The provider group uses PRD and optional CTD to say who is asking and how to contact them.

PID identifies the patient being queried. NK1 and GT1 can add next-of-kin or guarantor clues when they are part of the known context. NTE should explain the request, not replace structured demographics.

Implementation traps

The main trap is sending too little identity. A name and date of birth can still match more than one person. If the requester has an MRN, enterprise ID, payer member number, or assigning authority, send it properly in PID-3.

The second trap is overwriting local demographics with the response without trust rules. The answer may be current in the receiver's world, but that does not automatically make it more authoritative than the requester for every field.

Reference notes

The HL7 v2+ I04 material describes RQP/RPI as a request for patient demographic information, including insurance and billing information. The structure uses MSH, a provider group, PID, optional NK1 and GT1, and notes.