HL7 RPI_I04 Return Patient Demographic Data

The demographic and billing answer to an RQP_I04 request.
HL7 message structure RPI_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

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
MSA
 Message Acknowledgment Yes No
RPI_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
RPI_I04.GUARANTOR_INSURANCE
 Guarantor Insurance group No No
GT1
 Guarantor No Yes
RPI_I04.INSURANCE
 Insurance group Yes Yes
IN1
 Insurance Yes No
IN2
 Insurance Additional Information No No
IN3
 Insurance Additional Information, Certification No No
NTE
 Notes and Comments No Yes

RPI_I04 returns patient information after an RQP_I04 request. It has the same general flavor as the request, but adds MSA and can include richer guarantor and insurance groups.

In practical terms, this is the message a receiving system sends when it says, "I found the patient; here is the demographic, next-of-kin, guarantor, and coverage data I can return."

A small RPI I04 example

MSH|^~\&|MPI|CITYHOSP|REFERRAL|CITYCLINIC|20260718101503||RPI^I04^RPI_I04|RPI040001|P|2.5.1 MSA|AA|RQP040001 PRD|RT|City Hospital^Patient Registry|1 Hospital Way^^Auckland^^1010^NZ|^^^MPI|CITYHOSP CTD|PR|Registry^Team|1 Hospital Way^^Auckland^^1010^NZ|^WPN^PH^^64^9^5553000 PID|1||123456^^^CITYHOSP^MR~NHI1234^^^NATIONAL^NI||Smith^Jane^Anne^^Ms^^L||19800314|F|||12 High Street^^Auckland^^1010^NZ^H||^PRN^CP^^64^21^5551234 NK1|1|Smith^Alex|SPO^Spouse^HL70063|12 High Street^^Auckland^^1010^NZ|^PRN^CP^^64^21^5557777 GT1|1|G123|Smith^Jane^Anne||12 High Street^^Auckland^^1010^NZ|^PRN^CP^^64^21^5551234 IN1|1|PLAN77|CITYCARE|CityCare Health Plan|PO Box 77^^Auckland^^1140^NZ|||||Smith^Jane^Anne|SEL NTE|1||Demographics returned from patient registry on 20260718.

What systems do with it

The requester may use RPI_I04 to fill a referral packet, update a worklist, or show a user the receiver's demographics for confirmation. An integration engine may map selected fields onward, but it should usually keep an audit trail of where those values came from.

MSA links the response to the original request. If the receiver found multiple possible patients or no patient at all, the profile should define how that status is returned. Do not let a blank PID or ambiguous response look like a clean answer.

How to read the structure

MSH and MSA frame the response. The provider group identifies the responding provider or organization using PRD and CTD.

PID carries the returned patient identity and demographics. NK1 can repeat for associated parties. The optional guarantor/insurance group contains GT1 and insurance segments such as IN1, IN2, and IN3.

Implementation traps

Do not treat returned demographics as a blind overwrite. Demographic data needs source-of-truth rules, field-level trust, timestamps, and sometimes human confirmation.

Also watch for identifier collisions. If PID-3 repeats with local and national identifiers, preserve each assigning authority. Flattening them into one patient number is how a useful response becomes dangerous.

Reference notes

The HL7 v2+ I04 material describes RQP/RPI as the request and return pair for patient demographic information, including billing and insurance information. The RPI response adds MSA and can return provider, patient, guarantor, insurance, and note content.