HL7 QBP_Q21 (Get Person Demographics) | Integration Soup HL7 Reference Guide

HL7 QBP_Q21 Get Person Demographics

Ask the identity source for the person behind a known identifier.

HL7 message structure QBP_Q21 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
QPD	Query Parameter Definition	Yes	No
RCP	Response Control Parameter	Yes	No
DSC	Continuation Pointer	No	No

QBP_Q21 is a person-demographics query. A system has an identifier or a small set of search criteria and asks an identity source, MPI, EHR, or registry for the matching person details. It is common in patient lookup, registration assistance, portal enrollment, and identity confirmation workflows.

The message itself stays small: QPD carries the query name, query tag, and person lookup parameters; RCP controls response behavior; DSC supports continuation if the receiver needs paging.

A small QBP Q21 example

MSH|^~\&|EHR|CITYHOSP|MPI|CITYHOSP|20260717100500||QBP^Q21^QBP_Q21|QBP210001|P|2.5.1 QPD|Q21^Get Person Demographics^HL7nnn|Q210001|123456^^^CITYHOSP^MR RCP|I|1^RD

What workflow it represents

The sender wants demographics before committing to a downstream action. That might be a kiosk checking a hospital number, an integration engine enriching an inbound order, or an application confirming that a patient exists in the enterprise index. The usual response is an RSP_K21 carrying PID, optional PD1, NK1, and match quality in QRI.

The profile matters more than the message name. One site may allow lookup only by enterprise ID. Another may allow name, date of birth, sex, phone, and address. Both can be QBP_Q21, but the QPD parameter contract is different.

How to read the structure

MSH says who is asking and gives the query message a control ID. QPD names the demographics query and provides the query tag that the response will echo. RCP should be explicit when the sender wants exactly one result, a limited candidate list, or deferred behavior.

When identifiers are used, assigning authorities are not decoration. A naked 123456 is rarely enough in an MPI conversation. Use a properly qualified CX value so the receiver knows which identifier domain you mean.

Implementation traps

Person queries invite false confidence. A response can contain the right-looking name and still be the wrong person if assigning authorities, birth dates, or matching rules are loose. Treat the response status and QRI match confidence as workflow inputs, not as pretty metadata.

Also agree whether the query is allowed to return multiple candidates. Some user-facing workflows should stop and ask a person to choose; automated interfaces often need a single confident match or a controlled failure.

Reference notes

HL7's refactored QBP_Q21 material describes this message as a get-person-demographics query and shows the compact MSH, QPD, RCP, DSC structure. See HL7 Europe QBP_Q21. IHE Patient Demographics Query profiles use the same QBP/RSP style for demographics lookup workflows; see IHE ITI-21.