The QPD segment defines the parameters of the query.
| Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
|---|---|---|---|---|---|---|---|---|---|
QPD
|
|||||||||
1
|
Message Query Name | CWE | R | [1..1] | 01375 | ||||
|
2
|
Query Tag | ST | C | [0..1] | 00696 | 32 | # | ||
3
|
User Parameters | Varies | O | [0..1] | 01435 | 256 | # | ||
Definition: This field contains the name of the query. These names are assigned by the function-specific chapters of this specification. It is one to one with the Query Profile for this query name, and it is in fact an identifier for that Query Profile. Site-specific query names begin with the letter "Z." Refer to User defined table 0471 – Query name in Chapter 2C, Code Tables, for suggested values.
Definition: This field may be valued by the initiating system to identify the query, and may be used to match response messages to the originating query. If this field is valued, the responding system is required to echo it back as the first field in the query acknowledgement segment (QAK).
This field differs from MSA-2-Message control ID in that its value remains constant for each message (i.e., all continuation messages) associated with the query, whereas MSA-2-Message control ID may vary with each continuation message, since it is associated with each individual message, not the query as a whole.
Implementation considerations: It is not necessary to value this field in implementations where the only return message on the socket will be the response to the query that was just sent. Conversely, in an "asynchronous" implementation where many queries, responses, and other messages may be communicated bidirectionally over the same socket, it is essential that this field be valued so that the Client knows to which query the Server is responding.
Definition: These successive parameter fields hold the values that the Client passes to the Server.
The client data is presented as a sequence of HL7 fields. Beginning at QPD-3-User parameters, the remaining fields of the QPD segment carry user parameter data. Each QPD user parameter field corresponds to one parameter defined in the Query Profile, where each name, type, optionality, and repetition of each parameter has been specified. While these parameters are understood to be usually "anded" together, the user SHALL inspect the required Query Profile to properly understand each. Except in the QSC variant, the parameter names do not need to be stated in the query; they are understood to be positional based on the Query Profile.
Each parameter field may be specified in the Query Profile to be of any single data type, including the complex QIP and QSC types. Parameter fields may also contain the sort control (SRT) field or the segment group (ID) field defined in Sections 5.5.6.6, "RCP-6 Sort-by Field (SRT) 01624," and 5.5.6.7, "RCP-7 Segment Group Inclusion (ID) 01594," below.
Parameter fields in the QPD segment appear in the same order as in the Query Profile.
Note: Query By Example: The Query by Example is an extension of Query by Parameter (QBP) in which search parameters are passed by sending them in the segment which naturally carries them. Thus if one wanted to perform a "find_candidates" query using query by example, one would send the demographics information on which to search in the PID and/or PD1 segments leaving blank those fields in the segment sent which are not query parameters. If, for example, religion were not one of the query parameters, PID-17 would be left blank when the PID was sent in the query. Parameters which do not occur naturally in an HL7 message, such as search algorithm, confidence level, etc, would continue to be carried in the QPD segment as they are in the Query by Parameter. The segments and fields available for use as query parameters would be specified in the Query Profile for the query.
®© HL7.org 2019+. HL7 v2+ generated on March 23, 2022
Links:
Version History
|
Propose a change
|
License
The Demo site for our new HL7 Version 2+ (plus) Standard
