HL7 v2 QPD-3 Field Guide: User Parameters Values and Common Mistakes
QPD-3 is where the actual search value lives, but its shape is not fixed by the segment itself — it is defined entirely by whichever query QPD-1 names, which is exactly the assumption that trips up generic parsers.
QPD-3 is the first of the User Parameters fields, and in a common patient demographic query it typically carries the primary identifier being searched for, such as a patient identifier with its assigning authority and identifier type. Later repetitions and additional QPD fields can carry further search criteria — a name, a date of birth, or other demographic values — with the exact list and order defined by the specific query named in QPD-1, not by QPD itself.
What this field contains
Example
QPD-3 (9284471^^^SYNTHIBMRN^MR) is a fabricated patient identifier standing in as the search parameter for this synthetic demographic query.
Where this trips people up
Because QPD-3's structure is defined by the query in QPD-1 rather than by QPD itself, test generators that hardcode a patient-identifier shape for every query silently produce malformed parameters the moment a different query type expects, say, a name or a date range in that same position. Parsing code on the receiving end that was only ever validated against one parameter layout tends to fail quietly too, extracting garbage into the wrong component instead of raising an obvious error, which makes the underlying mismatch hard to catch until search results start coming back wrong.