HL7 v2 QPD Segment Guide: Fields, Format, and Testing Gotchas
QPD is where a query message actually says what it wants — everything else in a QBP is routing and formatting, but QPD is the segment carrying the patient identifier or search criteria the requester is trying to find, and it is the segment most test suites populate with exactly one hardcoded example.
QPD (Query Parameter Definition) is the segment in HL7 v2 query messages, most often QBP, that specifies which predefined query is being invoked and supplies the actual parameter values being searched on. It names the query by ID in QPD-1, carries a requester-assigned tag in QPD-2 so the eventual response can be matched back to this specific request, and holds the search parameters themselves — such as a patient identifier — starting in QPD-3. The exact shape of QPD-3 and beyond depends entirely on which query is named in QPD-1, since each defined query specifies its own parameter list.
The fields that actually matter in practice
Example
A synthetic QPD segment for a patient demographic query, with a fabricated query tag and a made-up medical record number used as the search parameter.
Where this trips people up
A lot of generated test messages hardcode a single query type and never vary QPD-1, so parsing logic that is supposed to branch on which query is running only ever gets exercised against one code path — the moment a second query type shows up in production, the field-mapping assumptions baked in for the first one quietly misapply to the second. The other frequent miss is treating QPD-2 as disposable: if a test generator invents a fresh query tag on the response side instead of echoing the value the requester sent, correlation between the outbound query and the inbound QAK/response pair breaks in a way that looks fine until something tries to match them programmatically.