HL7 V2.4 Contents

HL7 V2.4 Chapter 5

• 5 .
  Query
  • 5.1 CHAPTER 5 CONTENTS
  • 5.2 INTRODUCTION
    • 5.2.1 Query/response model
    • 5.2.2 Evolution of the query standard
    • 5.2.3 Query development methodology
    • 5.2.4 Response format
      • 5.2.4.1 Segment pattern response
      • 5.2.4.2 Tabular response
      • 5.2.4.3 Display response
      • 5.2.4.4 Choosing among available response formats
    • 5.2.5 Query specification formats
      • 5.2.5.1 Expressing the same data using the variants
        • 5.2.5.1.1 Expression as simple parameters
        • 5.2.5.1.2 Expression as query by example
        • 5.2.5.1.3 Expression as a complex expression
    • 5.2.6 Summary chart of query/response pairs
  • 5.3 QUERY/RESPONSE CONFORMANCE STATEMENT
    • 5.3.1 Using the Conformance Statement
      • 5.3.1.1 Query with tabular response example
      • 5.3.1.2 Example of Conformance Statement with tabular response
    • 5.3.2 Formal specification of the conformance statement
      • 5.3.2.1 Steps for developing a conformance statement
      • 5.3.2.2 Conformance Statement introduction
      • 5.3.2.3 Query grammar
      • 5.3.2.4 Response grammar
      • 5.3.2.5 Response grammar for display response
      • 5.3.2.6 QPD input parameter specification
      • 5.3.2.7 QPD input parameter field description and commentary
      • 5.3.2.8 QBE input parameter specification
      • 5.3.2.9 QBE input parameter field description and commentary
      • 5.3.2.10 RCP input parameter field description and commentary
      • 5.3.2.11 Input specification: virtual table
      • 5.3.2.12 Virtual table field description and commentary
      • 5.3.2.13 Output specification for tabular response
    • 5.3.3 Conformance statement templates
      • 5.3.3.1 Conformance statement template for query with tabular response
      • 5.3.3.2 Conformance statement template for query with segment pattern response
      • 5.3.3.3 Conformance statement for query with display response
      • 5.3.3.4 Conformance statement table summaries
  • 5.4 QUERY/RESPONSE MESSAGE PAIRS
    • 5.4.1 QBP/RSP - query by parameter/segment pattern response (events vary )
    • 5.4.2 QBP/RTB - query by parameter/tabular response (events vary)
    • 5.4.3 QBP/RDY - query by parameter/display response (events vary)
    • 5.4.4 QSB - Create subscription (event Q16)
    • 5.4.5 QVR - query for previous events (event Q17)
    • 5.4.6 QCN/ACK - cancel query/acknowledge message (event J01)
    • 5.4.7 QSX /ACK - cancel subscription/acknowledge message (event J02)
  • 5.5 QUERY/RESPONSE MESSAGE SEGMENTS
    • 5.5.1 DSP - display data segment
      • 5.5.1.0 DSP field definitions
      • 5.5.1.1 DSP-1 Set ID - DSP (SI) 00061
      • 5.5.1.2 DSP-2 Display level (SI) 00062
      • 5.5.1.3 DSP-3 Data line (TX) 00063
      • 5.5.1.4 DSP-4 Logical break point (ST) 00064
      • 5.5.1.5 DSP-5 Result ID (TX) 00065
    • 5.5.2 QAK- query acknowledgment segment
      • 5.5.2.0 QAK field definitions
      • 5.5.2.1 QAK-1 Query tag (ST) 00696
      • 5.5.2.2 QAK-2 Query response status (ID) 00708
      • 5.5.2.3 QAK-3 Message query name (CE) 01375
      • 5.5.2.4 QAK-4 Hit count total (NM) 01434
      • 5.5.2.5 QAK-5 This payload (NM) 01622
      • 5.5.2.6 QAK-6 Hits remaining (NM) 01623
    • 5.5.3 QID- query identification segment
      • 5.5.3.0 QID field definitions
      • 5.5.3.1 QID-1 Query tag (ST) 00696
      • 5.5.3.2 QID-2 Message query name (CE) 01375
      • 5.5.3.0 QPD field definitions
      • 5.5.3.1 QPD-1 Message query name (CE) 01375
      • 5.5.3.2 QPD-2 Query tag (ST) 00696
      • 5.5.3.3 QPD-3 User parameters (Varies) 01435
        • 5.5.3.3.1 Note on QPD usage for query by example variant.
    • 5.5.4 QRI - query response instance segment
      • 5.5.4.0 QRI field definitions
      • 5.5.4.1 QRI-1 Candidate confidence (NM) 01436
      • 5.5.4.2 QRI-2 Match reason code (IS) 01437
      • 5.5.4.3 QRI-3 Algorithm descriptor (CE) 01438
    • 5.5.5 RCP - response control parameter segment
      • 5.5.5.0 RCP field definitions
      • 5.5.5.1 RCP-1 Query priority (ID) 00027
      • 5.5.5.2 RCP-2 Quantity limited request (CQ) 00031
      • 5.5.5.3 RCP-3 Response modality (CE) 01440
      • 5.5.5.4 RCP-4 Execution and delivery time (TS) 01441
      • 5.5.5.5 RCP-5 Modify indicator (ID) 01443
      • 5.5.5.6 RCP-6 Sort-by field (SRT) 01624
      • 5.5.5.7 RCP-7 Segment group inclusion (ID) 01594
    • 5.5.6 RDF - table row definition segment
      • 5.5.6.0 RDF field definitions
      • 5.5.6.1 RDF-1 Number of columns per row (NM) 00701
      • 5.5.6.2 RDF-2 Column description (RCD) 00702
    • 5.5.7 RDT - table row data segment
      • 5.5.7.0 RDT field definitions
      • 5.5.7.1 RDT-1 Column value (Variable) 00703
  • 5.6 AUXILIARY QUERY PROTOCOLS
    • 5.6.1 Immediate vs. deferred response
      • 5.6.1.1 Immediate response
      • 5.6.1.2 Deferred response example
    • 5.6.2 Query cancellation
    • 5.6.3 Interactive continuation of response messages
      • 5.6.3.1 Interactive continuation algorithm and rules
      • 5.6.3.2 Use case
      • 5.6.3.3 Example of interactive continuation protocol
      • 5.6.3.4 Message fragmentation example
    • 5.6.4 Batch message as a query response
    • 5.6.5 Query error response
  • 5.7 PUBLISH AND SUBSCRIBE
    • 5.7.1 Introduction
    • 5.7.2 Details
    • 5.7.3 Examples
      • 5.7.3.1 Example of a publish and subscribe Conformance Statement
    • 5.7.4 Establishing a subscription
    • 5.7.5 Canceling a subscription
  • 5.8 QUERY IMPLEMENTATION CONSIDERATIONS
  • 5.9 QUERY/RESPONSE MESSAGE EXAMPLES
    • 5.9.1 Query by parameter (QBP) / segment pattern response (RSP)
      • 5.9.1.1 Proposed dispense history example and Conformance Statement
        • 5.9.1.1.1 Associated dispense history Conformance Statement
      • 5.9.1.2 Comprehensive pharmacy information examples and Conformance Statement
        • 5.9.1.2.1 Comprehensive pharmacy information Conformance Statement
    • 5.9.2 Query using QSC variant / segment pattern response examples
      • 5.9.2.1 Dispense information example and Conformance Statement
        • 5.9.2.1.1 Associated dispense information Conformance Statement
      • 5.9.2.2 Dispense information query showing different instantiation
      • 5.9.2.3 Lab results history example
        • 5.9.2.3.1 Lab results history Conformance Statement
      • 5.9.2.4 Lab example different instantiation
    • 5.9.3 Query by parameter (QBP) / tabular response (RTB)
      • 5.9.3.1 MPI example
        • 5.9.3.1.1 MPI Conformance Statement
      • 5.9.3.2 Pharmacy example:
        • 5.9.3.2.1 QBP/RTB dispense history Conformance Statement
    • 5.9.4 Query using QSC variant / tabular response (RTB)
      • 5.9.4.1 Pharmacy example
        • 5.9.4.1.1 QBP/RTB dispense history Conformance Statement using QSC variant
    • 5.9.5 Query by parameter (QBP) / display response (RDY)
      • 5.9.5.1 Dispense history display Conformance Statement
    • 5.9.6 Query using QSC variant (QBP) / display response (RDY)
      • 5.9.6.1 Dispense history display Conformance Statement using QSC variant
    • 5.9.7 Query by example (QBP) / tabular response (RTB)
      • 5.9.7.1 MPI Conformance Statement using QBE variant
      • 5.9.7.2 MPI Conformance Statement - Non query by example version
  • 5.10 SUPERCEDED QUERY/RESPONSE TRIGGER EVENTS AND MESSAGE PAIRS
    • 5.10.1 Display message
      • 5.10.1.1 Display vs. record-oriented messages
      • 5.10.1.2 UDM/ACK - unsolicited display update message (event Q05)
      • 5.10.1.3 Continuation of unsolicited display update message
    • 5.10.2 Original mode queries
      • 5.10.2.1 QRY/DSR - original mode display query - immediate response (event Q01)
        • 5.10.2.1.1 Original mode display query variants
    • 5.10.3 Original mode deferred access
      • 5.10.3.1 QRY/QCK - deferred query (event Q02)
      • 5.10.3.2 DSR/ACK - deferred response to a query (event Q03)
    • 5.10.4 Enhanced mode queries
      • 5.10.4.1 EQQ - embedded query language query (event Q04)
      • 5.10.4.2 RQQ - event replay query (event Q09)
      • 5.10.4.3 SPQ - stored procedure request (event Q08)
      • 5.10.4.4 VQQ - Virtual Table query (event Q07)
    • 5.10.5 Other query/response message segments
      • 5.10.5.1 EQL - embedded query language segment
        • 5.10.5.1.0 EQL field definitions
        • 5.10.5.1.1 EQL-1 Query tag (ST) 00696
        • 5.10.5.1.2 EQL-2 Query/response format code (ID) 00697
        • 5.10.5.1.3 EQL-3 EQL query name (CE) 00709
        • 5.10.5.1.4 EQL-4 EQL query statement (ST) 00710
      • 5.10.5.2 ERQ - event replay query segment
        • 5.10.5.2.0 ERQ field definitions
        • 5.10.5.2.1 ERQ-1 Query tag (ST) 00696
        • 5.10.5.2.2 ERQ-2 Event identifier (CE) 00706
        • 5.10.5.2.3 ERQ-3 Input parameter list (QIP) 00705
      • 5.10.5.3 QRD - original-style query definition segment
        • 5.10.5.3.0 QRD field definitions
        • 5.10.5.3.1 QRD-1 Query date/time (TS) 00025
        • 5.10.5.3.2 QRD-2 Query format code (ID) 00026
        • 5.10.5.3.3 QRD-3 Query priority (ID) 00027
        • 5.10.5.3.4 QRD-4 Query ID (ST) 00028
        • 5.10.5.3.5 QRD-5 Deferred response type (ID) 00029
        • 5.10.5.3.6 QRD-6 Deferred response date/time (TS) 00030
        • 5.10.5.3.7 QRD-7 Quantity limited request (CQ) 00031
        • 5.10.5.3.8 QRD-8 Who subject filter (XCN) 00032
        • 5.10.5.3.9 QRD-9 What subject filter (CE) 00033
        • 5.10.5.3.10 QRD-10 What department data code (CE) 00034
        • 5.10.5.3.11 QRD-11 What data code value qual (CM) 00035
        • 5.10.5.3.12 QRD-12 Query results level (ID) 00036
      • 5.10.5.4 QRF - original style query filter segment
        • 5.10.5.4.0 QRF field definitions
        • 5.10.5.4.1 QRF-1 Where subject filter (ST) 00037
        • 5.10.5.4.2 QRF-2 When data start date/time (TS) 00038
        • 5.10.5.4.3 QRF-3 When data end date/time (TS) 00039
        • 5.10.5.4.4 QRF-4 What user qualifier (ST) 00040
        • 5.10.5.4.5 QRF-5 Other QRY subject filter (ST) 00041
        • 5.10.5.4.6 QRF-6 Which date/time qualifier (ID) 00042
        • 5.10.5.4.7 QRF-7 Which date/time status qualifier (ID) 00043
        • 5.10.5.4.8 QRF-8 Date/time selection qualifier (ID) 00044
        • 5.10.5.4.9 QRF-9 When quantity/timing qualifier (TQ) 00694
        • 5.10.5.4.10 QRF-10 Search confidence threshold (NM) 01442
      • 5.10.5.5 SPR - stored procedure request definition segment
        • 5.10.5.5.0 SPR field definitions
        • 5.10.5.5.1 SPR-1 Query tag (ST) 00696
        • 5.10.5.5.2 SPR-2 Query/response format code (ID) 00697
        • 5.10.5.5.3 SPR-3 Stored procedure name (CE) 00704
        • 5.10.5.5.4 SPR-4 Input parameter list (QIP) 00705
      • 5.10.5.6 URD - results/update definition segment
        • 5.10.5.6.0 URD field definitions
        • 5.10.5.6.1 URD-1 R/U date/time (TS) 00045
        • 5.10.5.6.2 URD-2 Report priority (ID) 00046
        • 5.10.5.6.3 URD-3 R/U who subject definition (XCN) 00047
        • 5.10.5.6.4 URD-4 R/U what subject definition (CE) 00048
        • 5.10.5.6.5 URD-5 R/U what department code (CE) 00049
        • 5.10.5.6.6 URD-6 R/U display/print locations (ST) 00050
        • 5.10.5.6.7 URD-7 R/U results level (ID) 00051
      • 5.10.5.7 URS - unsolicited selection segment
        • 5.10.5.7.0 URS field definitions
        • 5.10.5.7.1 URS-1 R/U where subject definition (ST) 00052
        • 5.10.5.7.2 URS-2 R/U when data start date/time (TS) 00053
        • 5.10.5.7.3 URS-3 R/U when data end date/time (TS) 00054
        • 5.10.5.7.4 URS-4 R/U what user qualifier (ST) 00055
        • 5.10.5.7.5 URS-5 R/U other results subject definition (ST) 00056
        • 5.10.5.7.6 URS-6 R/U which date/time qualifier (ID) 00057
        • 5.10.5.7.7 URS-7 R/U which date/time status qualifier (ID) 00058
        • 5.10.5.7.8 URS-8 R/U date/time selection qualifier (ID) 00059
        • 5.10.5.7.9 URS-9 R/U quantity/timing qualifier (TQ) 00695
      • 5.10.5.8 VTQ - Virtual table query request segment
        • 5.10.5.8.0 VTQ field definitions
        • 5.10.5.8.1 VTQ-1 Query tag (ST) 00696
        • 5.10.5.8.2 VTQ-2 Query/response format code (ID) 00697
        • 5.10.5.8.3 VTQ-3 VT query name (CE) 00698
        • 5.10.5.8.4 VTQ-4 Virtual table name (CE) 00699
        • 5.10.5.8.5 VTQ-5 Selection criteria (QSC) 00700
    • 5.10.6 Other Query examples
      • 5.10.6.1 Original mode query with display-oriented response
      • 5.10.6.2 Enhanced mode query examples
        • 5.10.6.2.1 Embedded query language query
        • 5.10.6.2.2 Virtual Table query
        • 5.10.6.2.3 Stored procedure request
        • 5.10.6.2.4 The response to the above queries might look like the following:
        • 5.10.6.2.5 Embedded query language continuation query
        • 5.10.6.2.6 Virtual Table query continuation query
        • 5.10.6.2.7 Stored procedure request query continuation query
        • 5.10.6.2.8 Tabular response showing no further data
        • 5.10.6.2.9 Event replay query example
        • 5.10.6.2.10 Event replay response example
        • 5.10.6.2.11 Embedded query language (EQL) , Virtual Table, and stored procedure error response
        • 5.10.6.2.12 Event replay error response
  • 5.11 OUTSTANDING ISSUES

5 .
Query

5.1 CHAPTER 5 CONTENTS

5.2 INTRODUCTION

This chapter defines the rules that apply to queries and to their responses. It also defines the unsolicited display messages because their message syntax is query-like in nature.
Version 2.4 of the standard introduces new models for query and response messages. The layout of this chapter is structured such that all information pertaining to those newly defined query/response message pairs, including auxiliary protocols, appears in sections 5.1-5.9 and the previously defined queries appear in section 5.10. Outstanding issues appear in the final section, 5.11

The Standard embraces the most common queries that are likely to occur. These are defined by the functional chapters. The following represents typical examples of queries supported by the Standard:
a) data regarding a single patient, e.g., send all lab results for patient #123456
b) data regarding multiple patients, e.g., send the list of patients whose attending physician is Dr. #123
c) data that is not patient related, e.g., send the age specific normal values for serum protein.
d) data within a specified time range, e.g., send all serum glucose results, reported between January 1, 1998 through December 31, 1999, for patient #123456.
The variety of potential queries is almost unlimited. There was no attempt here to define a Standard that would cover every possible query. Chapter 5 discusses general ways query/response pairs are structured. Functional chapters discuss specific query/response pairs required for their needs. The technical committees responsible for functionally-specific chapters define detailed content of the query/response segment patterns within those chapters.

In particular, there is no implication that a specific system must support generalized queries or Conformance Statements to comply with the Standard. Rather, these transactions provide a format, or a set of tools to support queries to the extent desired by the institution. The resources available and local policies will influence the type of queries that are implemented.

5.2.1 Query/response model

A query with its response should be thought of as a message pair. The following illustration shows the three generic models of message pairs: the declarative, interrogative, and imperative. Within each model, one system assumes the role of initiator and the other system assumes the role of responder. HL7 queries follow the "interrogative" style of messaging as described below.
Click here for Picture
Note: All messaging in HL7 assumes a single basic paradigm using a point-to-point transmission of an initial message from a sender to a receiver, followed by a response or acknowledgement message from the receiver back to the sender. The response/acknowledgment message may be optional depending on several use cases that will be discussed below. The point-to-point transmission is defined independent of any particular technology or architecture.
The declarative model is employed for distribution or broadcast of unsolicited events such as the ORU and RDS. Clients (interested parties) that desire information that resides on a Server or data owner may "subscribe" to be updated when new information is available on the Server. The Server initiates a transmission of event information. This transmission may be to a single Client, or may be a broadcast to multiple Clients. Each Client responds with an acknowledgement of receipt.
The interrogative model is employed for queries. A Client initiates a query (a request for data) to the Server. The Server processes the query, responds with a report of success or failure of the query to the Client, and further responds by delivering information requested by the query.
The imperative model is employed for remote interoperation. A Client initiates a request for action (such as an order) to the Server. The Server processes the request and responds with a report of success or failure to the Client.
Note: In HL7 v2.4, there is no formal assumption of client-server architecture, or of a particular "publish and subscribe" architecture. Thus the roles of the intercommunicating applications may change according to the messaging needs. I.e. an application may be a data owner or Server for one set of messages (e.g., an order entry system creating orders), and an interested party or Client for another set of messages (e.g., an order entry system receiving order status messages from an ancillary departmental system). Furthermore, the "data owning" system may be a middleware component such as an "application server" or a "messaging gateway" or "router" that distributes information from a server application. In the discussions below, "Client" and "Server" are used as shorthand synonyms for "requesting system/application" and "responding system/application" without implying the assumption of a client/server architecture. Likewise, the support for "publish and subscribe" does not assume a particular operating system or architecture, but is defined at the application level (level 7), in a technology-neutral form. The phrase "data owner" is used to refer to the human institution that operates the Server program. One would say that "the data owner defines the data to be made available by the Server program."

5.2.2 Evolution of the query standard

The Query Standard, like the HL7 Standard in general, has been evolving since its inception in Version 2.1. Version 2.4 introduces a new methodology intended to supercede the previous generation of queries.
Original Mode Queries
Originally, the parameters of an HL7 query were carried by the QRD and QRF segments. Because these segments were intended to be used by all queries, the content of these segments could only be loosely defined. Such "original mode queries" actually represent just a starting point for defining queries.
In these original mode queries, separate trigger events were used to differentiate between an immediate response and a deferred response. In addition, some of the functional chapters defined queries and responses with separate trigger events.
Enhanced Mode Queries
In HL7 V2.3, "enhanced mode queries" were introduced that attempted to provide for a much higher level of precision in queries. Four new ways of specifying a query were introduced in Version 2.3.
* An Embedded Query Language query, which supports free-form select statements, based on the query language of choice (e.g., SQL)
* a Virtual Table request query which supports queries against server database tables (virtual or actual) based on specific selection criteria
* a stored procedure request, which enables an application on one system to execute a stored procedure on another system, which is coded to extract specific data
* an event replay request message, which is used to request data formatted as an event replay response
"Enhanced Mode" introduced three new ways to pass data to the responding system (e.g., a Server).
1) Passing values to specific parameters of a query. (Used by the stored procedure and event replay queries.) This is the most common and straightforward technique for creating queries. The drawback is that the client is tightly limited in the range of queries it can formulate.
2) Passing the query as a single complex query "expression". (Used by the Virtual Table query.) The query is defined by an expression-tree made up of the usual AND OR,' <' , `>',... Operators can refer to column_names or variables defined by the Server. These Queries give the Client significant flexibility in specifying their query over the columns that the Server has permitted. The cost of this Client flexibility is that the Server must evaluate the query expression, rather than simply plug parameter values into an existing stored procedure.
3) Passing the query as a single string in an existing database query language such as SQL. (Used by the EQL External Query Language query.) An EQL query is represented as a string formatted in the particular syntax of an existing query language. The Server will probably pass this string expression directly to an existing database engine to evaluate the query, which will have to parse this expression to recover the query. The drawback of this technique is that different database engines use different query languages, and so the exact query string which the Client constructs will depend on the Server's query language.
Also in Version 2.3, the use of the trigger event was moving closer to the definition set forth in chapter 2. Each offered query had its own trigger event. In Version 2.3.1 each response had its own trigger event.
Version 2.4 Queries
Users of 2.3 queries encountered some somewhat arbitrary limitations suggested by the 2.3 standard. A close reading of the 2.3 virtual table query wording made it appear that the only way a query could be specified by a QSC selection expression was if it returned tabular (RDT) results, and it seemed that query-by-parameter queries could not return tabular results.
Version 2.4 of the HL7 standard now more cleanly separates how a query is specified from how the data is returned, and it emphasizes the existence of a "Conformance Statement." HL7 continues to support the semantics of the Stored Procedure/Event Replay queries and the Virtual Table queries, but formulates the syntax more clearly using a single new query, the Query By Parameter (QBP).
The QBP query is intended to unify the semantics of the stored-procedure, event-replay and virtual-table queries within the framework of a precise conformance statement.
The standard recognizes the continued use of the Original Mode queries (QRD/QRF), but uses a new query formalism to explain their semantics more clearly.
The bulk of the new material of Version 2.4 consists of defining a format for Conformance Statements, and giving examples of query design and use.
Compatibility with past versions
For backward compatibility, both the "original" and "enhanced" queries remain in the standard, but their description has been relegated to a "for backward compatibility only" section. The main part of this chapter is a complete and consistent explanation of the recommended approach to HL7 queries in Version 2.4.
As in past versions of HL7, the detailed domain content of the query and response messages is defined by the technical committees responsible for the functionally-specific chapters; the basic forms and methodology for queries and responses are defined in this chapter.
Sections 5.2.4 and 5.2.5 discuss Response Formats and Query Specification Formats.

5.2.3 Query development methodology

Typically, an individual HL7 conformant query would evolve as follows:
An institution, or data owner, decides that it would like to make information available via a query. It decides precisely what data will be made available and how it will be offered. Knowing its own data, the data owner will define its query to return one of three representations of the data:
1. As traditional HL7 segments. (See section 5.2.4.0 for "segment pattern response".)
2. As rows and columns of data from a precisely defined Virtual Table. (See section 5.2.4.2 for "tabular response.")
3. As rows of human readable text ready to output to a screen or printer. (See section 5.2.4.3 for "display response".)
Next, the data owner specifies exactly which input variables the Client can use to control the data that the Server agrees to return.
The complete specification of what data are available, how the data will be returned, and what variables can be valued or constrained in a Query is called the Conformance Statement.
The Conformance Statement concept is critical to the proper usage of the query/response pair. In the absence of a Conformance Statement, the Client would be unaware of the existence of the query, let alone how to use it or what to expect from it. The data owner advertises the existence of, and support for, a query by publishing a Conformance Statement.
The Conformance Statement has the following broad structure:

Conformance statement: A declaration which sets forth the name of the query supported by the Server, the logical structure of the information that can be queried, and the logical structure of what can be returned.
Section 5.3 will explain the conformance statement in detail.
The next section elaborates on the three styles of response data (segment pattern, tabular, and display) that a data owner may use to represent its data.
The introduction of the Conformance Statement concept is not intended to imply system certification. It is intended to promote well-specified queries. As in previous versions, support for queries is not required for HL7 conformance.

5.2.4 Response format

The first decision a data owner must make in formulating a query is to decide which style of representing data is most appropriate for their needs.

These structures support all original mode and enhanced mode responses, as well as the 2.4 queries.

5.2.4.1 Segment pattern response

Segment Pattern data responses reflect the traditional way of offering data within HL7. The Server responds to queries by returning a pattern of HL7 segments. For example, the core of a response to a query for Lab data might be defined by the following segment grammar:
{PID
OBR
[{OBX}]
}
For example, patient information will be returned in the PID segment and laboratory results in OBR and OBX segments. In this style, the message returned by a Server is often a close approximation to an existing unsolicited update HL7 message.
In creating a Conformance Statement for a segment pattern response, the data owner must decide on the exact segment grammar it will return. The output specification of the Conformance Statement for a segment pattern response will have a structure very similar to the message definition of a standard HL7 transaction. It must define a grammar of segments that will be returned, and, for each segment, it should clarify, where necessary, the meaning of each field, the cardinality of the data, and whether the data is optional or required.

5.2.4.2 Tabular response

A data owner may decide that the best model for the data it wishes to offer is that of a fairly conventional table of rows and columns. In this case, a data owner advertises support for a straightforward ("virtual") table of data, with specific columns of specific data types. It further indicates which of the columns the Client can constrain in its query. The response to a query will be in the form of a set of rows from the advertised table.
The Virtual Table is an abstraction around a traditional database table. However, there are important differences between a traditional database table and the Virtual Table. The Virtual Table need not be based on a single table or collection of data. It may represent a "join" or combination of data among database tables (although the "join" or combination is not explicitly exposed to the Client).
The concept of table, borrowed from the relational database world, is used merely as a representational aid. The actual internal data structure of the Server need not be relational. Virtual Tables may be used to present data elements from internal structures that are hierarchical, object-oriented, or otherwise non-relational in nature.
Virtual Tables therefore insulate the user from the exact data layout or representation in the data source. That is to say, the requestor need not understand the structure of the tables, rows and columns of the database being queried but only the structure of the Virtual Table representation. Likewise, the responder (database owner) does not have to expose the structure of the real database. Neither the owner nor the requestor needs to worry if the structure of the database changes.
The rows and columns of the Virtual Table for a query are fully described in the Conformance Statement for that query.
A virtual table data representation is appropriate when the information being offered is relatively simple. It would not be the appropriate representation for lab reports that typically involve a complex nesting of results into sections. Data carried by the typical HL7 segment or segment group could be modeled as a virtual table. For example, the ADT system might offer a table consisting of the fields of PID, NK1 and a single PV1 segment. On the other hand, it would be difficult to represent the visit history of a patient in a single virtual table.

5.2.4.3 Display response

A display message can be generated where the update information does not need to be captured by the receiving system's database, but only displayed, either on a visual medium (such as a PC, workstation or a CRT) or on printed medium.
The display response does not actually represent a formal style of data organization. It represents a decision to return data formatted for human, rather than for computer, consumption. The Server offers a pretty-printed version of the data in a format that is meaningful for human readers. Logically, the content of the pretty printed message might be the complex data carried by an HL7 segment pattern, or could be a simple record normally carried by a tabular response.

5.2.4.4 Choosing among available response formats

In practice, it is easy to decide which style of data to offer. In general, segment pattern responses are able to carry complex data structures (e.g., an entire laboratory report), while tabular responses are typically simple data structures. Therefore, tabular response is intended as a simpler tool to accomplish a simpler task. There is no need for the Client to understand, parse and process the deep structure and relationships implied by the segment pattern response.. The Client does not need a complex state machine to do segment level parsing. The rows all have the same structure so only a simple state machine is needed.
If the query is defined by an HL7 technical committee, then the decision is already made. If, on the other hand, no query is yet defined but the domain of the data is well covered by HL7, then it is probable that there are existing HL7 segments that could carry the data. A Z query may be constructed out of the existing HL7 segments. If the data is site specific, the site can either create its own Z segments and offer a segment pattern response (which makes particular sense if the overall data is complex) or it can define its own Virtual Table, offer a tabular response and let the Client process each record.
Once it is known what data a Server is making available, then the data can be ordered or requested. This is analogous to needing to refer to a catalog before ordering an item by mail.

5.2.5 Query specification formats

The previous section explained the three representations for data that are returned to a query client. This section discusses how the client may represent a query for information.
HL7 now recommends one primary way with 3 basic variants for specifying a query.
This query model with its variants is intended to assist implementers in translating specific query needs from the ordinary prose of the business model into an appropriate HL7 query paradigm. The paradigm selected will depend upon the philosophy of the institution: whether to allow relative freedom to client systems in composing query expressions, or to control rigidly the fields and operations to be offered. The following paragraphs compare and contrast the features of each of the HL7 query variant models. The differences between them lie mainly in the processing they require on the Server side.
Query By Simple Parameter
The first variant is called the Simple Parameter query. In the simple parameter query, the input parameters are passed in order as successive fields of an HL7 segment. The Server need only read them from the corresponding HL7 fields, and plug them into an internal function to evaluate the query.
This is the most basic form of the query in which the Server specifies a fixed list of parameters in its Conformance Statement. (For example, the Server may direct the querying system to specify a medical record number, a beginning date, and an ending date.) When invoking the query, the Client passes a specific value for each parameter. This is analogous to invoking a stored procedure against a database.
The parameter definition segment (i.e., the QPD) can be seen as a generalization of the QRD and QRF segments of the original mode query. Each field in the QRD and QRF corresponds to 1 parameter of the QPD instance. HL7 recommends that queries defined by QRD and QRF segments be recast as a version 2.4 Query By Parameter.
The obvious implementation gain is that the Server can simply map the input values to the parameters specified in the Conformance Statement. An already known function or procedure is called to evaluate the query and select data to be returned. The bulk of the work effort has already been invested in the development of this predefined function or procedure.
Query By Example Variant:
The Query By Example (QBE) is an extension of Query By Parameter (QBP) in which search parameters are passed by sending them in the segment which naturally carries them, instead of as fields of the QPD segment. For example, if one wanted to perform a "find_candidates" query using QBE, 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 that 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 exact segments and fields available for use as query parameters would be specified in the Conformance Statement for the query.
Query using the QSC variant:
The third variant is known as the QSC variant because of its use of the QSC data type, which was used in the Virtual Table query. The conformance statement for the query will define all the variables that the Client may use in an expression. At runtime, the Client is able to define the exact search criteria by constructing a "tree" of operator/operand nodes that constrain the available input parameters. To evaluate the query, the Server must be willing to analyze and interpret the query expression at runtime. The Server may translate the input expression into its local data access language, or perhaps it will interpret the request itself, and evaluate the expression for each item of the virtual table. The client's Complex Expression is analogous to an SQL selection statement against a relational database.
This variant is most like the Virtual Table Query (VQQ).
There are a number of factors to consider in determining which variant to offer. In the Complex Expression (QSC) variant, the Client may select any or all of the variables offered and may specify any permissible operators and values for each variable. By contrast, in the Simple Parameter variant or the Query By Example variant, the Client must provide values for exactly the set of variables offered.
The Simple Parameter variant is easy to parse and process because it has positional fields; i.e., the parameters are in a predefined and fixed order. Likewise, the Query By Example variant lends itself to simple processing, since parameters will occur in known positions in defined segments. The Complex Expression variant, on the other hand, requires more involved parsing and processing because of its flexibility and the optionality of its elements. Thus, while the Complex Expression variant offers more functionality to the Client, it is more burdensome for the Server to process. Conversely, the Simple Parameter and Query By Example variants offer less functionality to the Client but are generally easier for the Server to implement; they are often based on existing stored procedures on the Server's system.

5.2.5.1 Expressing the same data using the variants

The following is an example of a query stated in all three variant forms. This example is presented to illustrate the utility of each format for the purpose of offering a query. Which format to use depends upon the level of processing complexity to be implemented on the Server and the degree of specification flexibility required by the Client.
The purpose of the query is to allow a simple inquiry upon an administrative database. Suppose a patient information request is submitted by the Client. The Server is to respond with demographic information: patient's date of birth, sex, and ZIP code.

5.2.5.1.1 Expression as simple parameters

As we have seen, this variant requires an exact parameter specification.
The client system transmits a QBP query message in the following format:
MSH|^~|FEH.IVR|HUHA.CSC|HUHA.DEMO||199902031135-0600||QBP^Z58^QBP_Q13|1|D|2.4
QPD|Z58^Pat Parm Qry 2|Q502|111069999
RCP||I
The names of the input and output fields are not specified in the query message, but by the Conformance Statement, identified by QPD-1-message query name. The MSH-9.2-trigger event and the QPD-1-message query name are this query's only distinguishing elements. The requesting system must refer to this query's Conformance Statement to learn more about the input and output fields.

5.2.5.1.2 Expression as query by example

Just as in the Simple Parameter variant, the Query By Example requires an exact parameter specification. The distinction in a Query By Example is that segments other than QPD are used to transmit the parameters. The segments offered should be already-existing segments that the Server can parse easily.
The client system transmits a Query By Example in the following format.
MSH|^~|FEH.IVR|HUHA.CSC|HUHA.DEMO||199902031135-0600||QBP^Z58^QBP_Q13|1|D|2.4
QPD|Z58^Pat Parm Qry 2|Q502
PID|||111069999
RCP||I
Parameters used in this query are specified in the Conformance Statement.

5.2.5.1.3 Expression as a complex expression

In contrast, the Complex Expression variant allows flexible input specifications. This allows more choices for the Client system, but can require more complex processing capability on the part of the Server System.
If the above Simple Parameter variant were to be stated as a Complex Expression, it might look like this.
MSH|^~|FEH.IVR|HUHA.CSC|HUHA.DEMO||199902031135-0600||QBP^Q12^QBP_Q12|1|D|2.4
QPD|Z999^Pat Sel Qry 1|Q501|@MedicalRecordNo^EQ^111069999
RCP||I
Note the explicit statement of the input field name in QPD-3-user parameters. Also, note that this query might be used to specify and request other fields, depending upon the specification of what is permitted by the server system's Conformance Statement.

Using the new modalities shown in the table, the variety and number of queries is almost unlimited. There is no implication that a specific Server must support all of these potential generalized queries to comply with the Standard. Rather, these transactions provide a format, or a set of tools, to support queries to the extent desired by the institution. The resources available and local policies will influence the types of queries that are implemented.

5.2.6 Summary chart of query/response pairs

The following chart delineates the query/response messages defined in chapter 5:

The following chart delineates the query/response messages defined in the functional chapters:

5.3 QUERY/RESPONSE CONFORMANCE STATEMENT

The introduction of the Query/Response Conformance Statement concept is not intended to imply system certification. It is intended to promote the definition and implementation of well-specified queries. As in previous versions, support for queries is not required for HL7 conformance.
In the introduction, the data owner describes the data being made available and the purpose of the query. He specifies the exact coded value Query Name which the Client must used to invoke this query.
The Query Grammar defines the exact segments the Client may send. For each field of those segments, the conformance statement will define how the Server will interpret client values. (For example, the patient name field is interpreted as a regular expression match.)
The Response Grammar defines the exact pattern of segments that the Server will return. Each Segment Pattern Response will specify its own pattern of segments. (For example, lab data queries will return patterns of OBR and OBX, while demographic queries might respond with patterns of PID, PV1... segments.) When a data owner defines a tabular response query, the response grammar might simply be a list of RDT segments that carry rows of data. The user selects columns from a Virtual Table to define the output for the Query By Parameter/Tabular Response (QBP/RTB).
Note that in the case of an HL7-defined query, a specific section of the HL7 Standard will define a Conformance Statement. By contrast, in the case of a site defined query, the Conformance Statement is written by analysts and programmers of the Server application/system, and is available to the analysts and programmers of the Client application/system.
Although the Conformance Statement is a new construct with Version 2.4, it may also be used with the previous generation queries.

5.3.1 Using the Conformance Statement

Critical to the proper usage of the new query/response pairs is the Conformance Statement concept. In the absence of a Conformance Statement, the Client might not be aware of the existence of a query, or might not know how to use it or what to expect from it.
The Server advertises the existence of, and support for, a query by publishing a Conformance Statement. The Conformance Statement identifies the query, specifies what items can be queried and describes what the response will look like.
Conformance Statement: A declaration which sets forth the name of the query supported by the Server, the logical structure of the information that can be queried, and the logical structure of what can be returned.
A number of examples of Conformance Statements can be found in section 5.9

5.3.1.1 Query with tabular response example

The user wishes to know the identity of the patient whose medical record number is "555444222111".
MSH|^&~\|PCR|GenHosp|MPI||199811201400-0800||QBP^Q40^QBP_Q13|8699|P|2.4||||||||
QPD|Q40^WhoAmI^HL7nnnn|Q0001|555444222111^^^MPI^MR|||19980531|19990531|
RCP|I|
RDF|PatientList^CX^20~PatientName^XPN^48~Mother'sMaidenName^XPN^48~DOB^TS^26~Sex^IS^1~Race^CE^80|
The MPI system returns the following RTB message
MSH|^&~\|MPI|GenHosp|PCR||199811201400-0800||RTB^R40^RTB_R40|ACK9901|P|2.4||||||||
MSA|AA|8699|
QAK|Q0001|OK|Q40^WhoAmI^HL7nnnn|1|
QPD|Q28^WhoAmI^HL7nnnn|Q0001|555444222111^^^MPI^MR|||19980531|19990531|
RDF|PatientList^CX^20~PatientName^XPN^48~Mother'sMaidenName^XPN^48~DOB^TS^26~Sex^IS^1~Race^CE^80|
RDT|555444222111^^^MPI^MR|Everyman^Adam||19600614|M||

5.3.1.2 Example of Conformance Statement with tabular response

QPD Input Parameter Specification

QPD Input Parameter Field Description and Commentary

RCP Response Control Parameter Field Description and Commentary

Output Specification and Commentary: Virtual Table

5.3.2 Formal specification of the conformance statement

The Conformance Statement contains the following information:
* Conformance Statement ID: The unique identifier applying to this query's Conformance Statement. This value is transmitted as the first component of QPD-1-Message query name. For sites implementing the Conformance SIG's Implementation Guide, this value shall also be transmitted in MSH-21-Conformance statement ID.
* Formal Query Name: identifies a unique query or publication, e.g., PharmacyDispenseHistory.
* Query Trigger: identifies the trigger event for the query. Note that more than one conformance statement may map to the same generic trigger event (Q10 through Q15). If a non-generic trigger event is used, it should correspond to exactly one Conformance Statement.
The use of Q for HL7-standard query trigger events is conventional; another letter may be used if the supply of Q triggers is exhausted.
The assignment of a trigger event, while mandatory, is intended to facilitate processing rather than to identify a query uniquely. A query is uniquely identified by the value transmitted in QPD-1-Message query name. This value must be the same in both the query and response messages, even though the trigger event for the query differs from the trigger event for the response.
* Response Trigger: identifies the unique trigger event for the response. Note that more than one conformance statement may map to the same generic trigger event (K10 through K15). If a non-generic trigger event is used, it should correspond to exactly one Conformance Statement.
The use of K for HL7-standard response trigger events is conventional; another letter may be used if the supply of K triggers is exhausted.
* Query Priority: Specifies if the query is immediate, deferred or selectable
* Query Characteristics: Narrative describing general feature of the query
* Purpose: Describes intent of query
* Query Grammar: defines the logical structure of what can be sent by the Client. The structure of this part of the Conformance Statement is very similar in appearance to a message syntax.
* Response Grammar: defines the logical structure of what can be returned by the Server. The structure of this part of the Conformance Statement is very similar in appearance to a message syntax with 2 additional columns: Comment and Support Indicator
* Data Model: the logical structure of the information that can be queried. It can be thought of as a set of rows or a list of items having the same format as the Virtual Table structure described in the next section. This works for both tabular and segment pattern queries. A display query can be considered as orthogonal to the tabular and segment pattern queries and follows the same input structure. This is not always included in the Conformance Statement.
* Input Parameter Field Specification and Commentary: Cites the allowable parameters that can be passed to the recipient. The structure of this part of the Conformance Statement is very similar in appearance to an HL7 Segment Attribute Table with several additional columns: ColName, Key/Search, Sort, MatchOp, SegmentFieldName, and Service Identifier Code.
A QPD Input Parameters table and corresponding explanation table is always provided. These tables discuss all the fields of the QPD segment, including QPD-1-Message query name and QPD-2-Query tag. If the query is a Query By Example, additional input parameters and explanation tables are provided for all the fields that may be populated in the example segments.
* Response Control: Specifies execution date and time, restrictions on amount of data, and query modality. This is not always included in the Conformance Statement.
* Output Specification and Commentary: Used for tabular and display response. For the tabular response, it specifies the column names that will be returned. The structure of this part of the Conformance Statement is very similar in appearance to an Attribute Table with several additional columns: ColName, Key/Search, Sort, MatchOp, SegmentFieldName, and Service Identifier Code. For the display response, it describes the format of the data that will be returned.
Note that in the case of an HL7-defined query, a specific section of the HL7 standard will define a Conformance Statement. The existence of a standard Conformance Statement for any given query does not mean that a system must implement this particular query to be conformant to the HL7 Standard. However, systems that do implement the query must follow the specifications as given in the Conformance Statement.
Sites that wish to offer queries not specified by the Standard may create their own Conformance Statements. By contrast to an HL7-standard query, in the case of a site defined query, the Conformance Statement is written by the Server, and is available to the analysts and programmers of the Client system to enable them to know the exact behavior of the Server.
Although the Conformance statement is a new construct with version 2.4, it may also be used with the previous generation queries.
Input Parameter Specification and Input Field Description and Commentary are always included for the QPD segment. When the Query By Example variant is used, they are provided for the QBE as well. An Output Specification and Commentary showing a Virtual Table is provided for queries that accommodate a tabular response.
For Conformance Statements published in the HL7 Standard, each table includes the Conformance Statement ID in parentheses in the upper left-hand cell. This allows the table to be imported automatically into the HL7 database.

5.3.2.1 Steps for developing a conformance statement

1) Before composing the Conformance Statement, express the query in ordinary English sentences.
2) Transform the query into a mathematical or pseudo-language statement. A syntax such as SQL provides a useful mechanism.
3) From the pseudo-statement, extract the parameters and the operations upon the parameters.
4) Advertise the parameters in the Conformance Statement.
5) Within the Conformance Statement, explain the operations that will be performed upon the parameters: relational conjunctions, equality/inequality, etc. Use examples to aid the user in understanding how the query might be invoked in specific instances.

5.3.2.2 Conformance Statement introduction

The Conformance Statement begins with a table that summarizes the characteristics and identifying information about the query to which the Conformance Statement applies.

Query Statement ID: The unique identifier applying to this Conformance Statement. This value is transmitted as the first component of QPD-1-Message query name.
Type: Usually Query, except for publish-and subscribe Conformance Statements (see Section 5.7.3.1) for which the value should be Publish.
Query Name: The name corresponding to the identifier in Query Statement ID. This value is transmitted as the second component of QPD-1-Message query name.
Query Trigger (= MSH-9): The exact value that the Client will transmit in the MSH-9-Message type field of the query message.
Query Mode: Whether the query may be sent in Real time (including Bolus) or in Batch; see Section 5.5.5.3. The value Both indicates that both real-time/bolus and batch modes are acceptable.
Response Trigger (= MSH-9): The exact value that the Server will transmit in the MSH-9-Message type field of the response message.
Query Characteristics: Particular features of this query. This is free text intended to help the query implementor in selecting among queries.
Purpose: The end result that this query is intended to accomplish. Free text.
Response Characteristics: Particular features of this response. This is free text intended to help the query implementor in selecting among queries.
Based on Segment Pattern: For queries that return a segment pattern response, this is the (non-query response) message type upon which the segment pattern is based.

5.3.2.3 Query grammar

The Conformance Statement shows a query grammar. This is a brief model of the segments used in the query message.

Query Grammar: This and the following column specify the HL7 code name and full name of each segment sent in the query. Braces specify that the segment or segment group is repeatable; brackets specify the optionality of the segment or segment group.
Section Reference: Specifies where in the standard further information about the segment can be found.
When the Query By Example variant is used, the Query Grammar shows the segments that may be used to transmit parameters and the order in which they appear. Segments used to transmit parameters are always sent immediately following the QPD segment.

5.3.2.4 Response grammar

The Conformance Statement always shows a response grammar. If the query response is segment pattern, the response grammar should specify the segments, order, optionality, and repetition as do message specifications within the HL7 Standard.

Response Grammar: This and the following column specify the HL7 code name and full name of each segment returned in the response. Braces specify that the segment or segment group is repeatable; brackets specify the optionality of the segment or segment group.
For Conformance Statements published in the HL7 Standard,, the Response Grammar table includes the Conformance Statement ID in parentheses in the upper left-hand cell. This allows the table to be imported automatically into the HL7 database.
Message Description: The full text name of the segment.
Group Control: The name of a segment group.
Comment: Specifies in English (1) the opening or closing of a segment group and (2) the relevance of the segment in a Hit Count. (Only positive value is noted)
Support Indicator: Allows the Server to indicate (1) whether an optional segment or segment group will be supported or (2) that the segment or segment group is dependent on an input parameter. The default understanding is that if the Server knows the information, it will be sent.
Sec Ref: Specifies where in the standard further information about the segment can be found.

5.3.2.5 Response grammar for display response

The response grammar for a display response lists the segment names, descriptions, and section references for the segments to be returned by the Server, as described in the previous section. In addition, the print text is displayed, as in the following example.

5.3.2.6 QPD input parameter specification

The Input Parameter Specification section of the Conformance Statement looks very much like an attribute table and is followed by a commentary on the fields. Each row of the QPD Input Parameter Specification specifies one user parameter within the QPD segment. Values for user parameters are transmitted in successive fields of the QPD segment, beginning at QPD-3.
When the QSC variant is employed (see Section 5.2.5.1.3), a complex query expression may be used as the only input parameter, or may be combined with other (simple) input parameters.
QPD Input Parameter Specification

The following is a description of the attributes of the above table.
Field Seq: The ordinal number of the element being discussed. Sequence 1 is always Message Query Name, and sequence 2 is always Query Tag. Sequence 3 and above are reserved for user parameters.
Name: the user-defined name for the element as will be used in the query. Example: MedicationDispensed. When Name is derived from an actual HL7 element (segment and field), the segment field name and element name appear in the columns headed by those names. When Name is not derived from an actual HL7 element (segment and field), the source system defines the values they expect in this field.
For Conformance Statements published in the HL7 Standard, the Input Parameter Specification table includes the Conformance Statement ID in parentheses in the upper left-hand cell. This allows the table to be imported automatically into the HL7 database.
Key/Search: This field identifies which element is the key and which elements are searchable. The key field is designated by a value of `K'. A value of `S' designates fields upon which an indexed search can be performed by the source. `L' designates non-indexed fields. (Note that searching on a non-indexed field requires the Server to perform a linear scan of the data base.) If this column is left blank, the field may not be searched.
Sort: valued as "Y" if the output of the query can be sorted on this field. This column should only be valued in Virtual Tables that are used as output specifications.
Len: the maximum field length that will be transmitted by the source.
Type: the data type of this user parameter. The values available for this field are described in Section 2.8 of the Health Level Seven Standard. Data types QIP and QSC are available for transmitting complex user parameters.
Opt: defines whether the field is required (`R'), optional (`O'), conditionally required (`C'), or required for backward compatibility (`B').
Rep: valued as `Y' if the field may repeat (i.e., be multiply valued).
Match Op: the relational operator that will be applied against the value that the querying system specifies for this field.
Note: These are defined by HL7 Table 0209 - Relatio nal operator, a component of the QSC data type
TBL: identifies the HL7 table from which the values are derived.
Segment Field Name: identifies the HL7 segment and field from which the new definition is derived. This field will be blank if the Name is NOT derived from an actual HL7 segment and field.
Service Identifier Code: a value of data type CE that contains the applicable LOINC code, if it exists, or the applicable HL7 code, if it exists, if no Segment Field Name has been identified. If a Segment Field Name has been identified, this field is not populated.
Element Name: the name of the element identified by Segment Field Name. This may also be a user-defined `Z'-element.

5.3.2.7 QPD input parameter field description and commentary

The QPD Input Parameter Field Description and Commentary provides a more detailed description of each of the fields transmitted in the QPD segment.

Input Parameter: The name of the field whose value is being transmitted.
Comp. Name: When the Input Parameter is of a composite data type (e.g., XPN), this is the name of an individual component of the composite input parameter. Only those components that may be valued should be listed in this column.
DT: The data type of the parameter or component.
Description: A narrative description of the parameter or component and how it is to be used.

5.3.2.8 QBE input parameter specification

In the Query By Example variant, discussed below in Section 5.9.7, "Query by example (QBP) / tabular response (RTB)," the Conformance Statement may specify that the client may use fields within actual message segments, such as the PID segment, to transmit parameter information. Where this is permitted, the Conformance Statement includes a "QBE Input Parameter Specification" table to specify which fields may be used to transmit the parameters.
QBE Input Parameter Specification

Fields are indicated by their actual Segment Field Name, which specifies both segment and position. Except for this distinguishing feature, the remaining columns in this table are identical in meaning to their counterparts in the "QPD input parameter specification" in Section 5.3.2.6 above.
Each row of the QBE Input Parameter Specification specifies one field that may be used to transmit user parameters within the example segment(s).

5.3.2.9 QBE input parameter field description and commentary

The QPD Input Parameter Field Description and Commentary provides a more detailed description of each of the fields transmitted in the example segments sent in a Query By Example.
QBE Input Parameter Field Description and Commentary

Fields are indicated by their actual Segment Field Name, which specifies both segment and position. Except for this distinguishing feature, the remaining columns in this table are identical in meaning to their counterparts in the "QPD input parameter field description and commentary" in Section 5.3.2.7 above.

5.3.2.10 RCP input parameter field description and commentary

The RCP Input Parameter Field Description and Commentary provides a more detailed description of each of the fields transmitted in the RCP (Response Control Parameters) segment.
RCP Response Control Parameter Field Description and Commentary

Field Seq: The position within the RCP segment that the field occupies.
Name: The name of the field whose value is being transmitted.
Component Name: When the field referenced by Name is of a composite data type (e.g., XPN), this is the name of an individual component of the composite input parameter. Only those components that may be valued should be listed in this column.
LEN: The maximum length of the field.
DT: The data type of the parameter or component.
Description: A narrative description of the parameter or component and how it is to be used.

5.3.2.11 Input specification: virtual table

When the QSC variant is in use, the Conformance Statement includes a Virtual Table specification listing the fields that the Client may include in the complex expression parameter.
Input Specification: Virtual Table

The ColName column identifies each field name that the Client may include in the complex query expression. Other columns in this table are defined as in Section 5.3.2.6 above.
When both the QSC variant and a tabular response are specified, this table is labeled "Input/Output Specification: Virtual Table" and no separate output specification is provided.

5.3.2.12 Virtual table field description and commentary

The Virtual Table Field Description and Commentary provides a more detailed description of each of the fields listed in the Virtual Table.
Virtual Table Field Description and Commentary

ColName: The name used to identify the column, or field, in the complex expression.
Comp. Name: When the ColName is of a composite data type (e.g., XPN), this is the name of an individual component of the column. Only those components that may be valued should be listed.
When specifying a field in the complex expression, both the ColName and Comp. Name attributes should be sent if only a single component is being identified. For instance, PatientList.ID would specify the ID component of the PatientList field.
DT: The data type of the field or component.
Description: A narrative description of the field or component and how it is to be used.

5.3.2.13 Output specification for tabular response

The output specification for the tabular response consists of the Virtual Table description, i.e., the columns and rows. It has the same columns as the input specification, but the rows reflect all of the available rows in the table, not just those that can be filtered upon input.
Output Specification and Commentary: Virtual Table

The usage of the columns in this table is as described in Section 5.2.2.2, "Input Parameter Specification." Note that the Key/Search and Match Op fields are only meaningful when a virtual table is used in the input specification (QSC variant).
When the QSC variant is in use, the "Input/Output Specification and Commentary" virtual table is used for selection of output fields. No separate table is specified for output.

5.3.3 Conformance statement templates

5.3.3.1 Conformance statement template for query with tabular response

QPD Input Parameter Specification

QPD Input Parameter Field Description and Commentary

[The following table is used only for the Complex Expression (QSC) variant.]
Input Specification: Virtual Table

[The following table is used only for the Complex Expression (QSC) variant.]
Virtual Table Field Description and Commentary

[The following table is used only for the Query By Example variant.]
QBE Input Parameter Specification

[The following table is used only for the Query By Example (QBE) variant.]
QBE Input Parameter Field Description and Commentary

RCP Response Control Parameter Field Description and Commentary

Output Specification and Commentary: Virtual Table

5.3.3.2 Conformance statement template for query with segment pattern response

QPD Input Parameter Specification

QPD Input Parameter Field Description and Commentary

[The following table is used only for the Complex Expression (QSC) variant.]
Input Specification: Virtual Table

[The following table is used only for the Complex Expression (QSC) variant.]
Virtual Table Field Description and Commentary

[The following table is used only for the Query By Example (QBE) variant.]
QBE Input Parameter Specification

[The following table is used only for the Query By Example variant.]
QBE Input Parameter Field Description and Commentary

RCP Response Control Parameter Field Description and Commentary

5.3.3.3 Conformance statement for query with display response

QPD Input Parameter Specification

QPD Input Parameter Field Description and Commentary

[The following table is used only for the Complex Expression (QSC) variant.]
Input Specification: Virtual Table

[The following table is used only for the Complex Expression (QSC) variant.]

[The following table is used only for the Query By Example (QBE) variant.]
QBE Input Parameter Specification

[The following table is used only for the Query By Example variant.]
QBE Input Parameter Field Description and Commentary

RCP Response Control Parameter Field Description and Commentary

5.3.3.4 Conformance statement table summaries

The following table lists the tables that are to be included in each Conformance Statement. The differences arise both from the query variant used and the response type provided.

5.4 QUERY/RESPONSE MESSAGE PAIRS

The query recommended for use in v 2.4 is the Query By Parameter (QBP). The query/response message pairs that follow in this section supercede the previous generation of original mode and enhanced queries that are described in sections 5.10.2, 5.10.3, 5.10.4.
All queries must have a Query Name. The Query Name field, which is a CE data type, uniquely identifies a Conformance Statement
The QBP allows for several variants in defining the selection criteria.
The first variant, the Query By (Simple) Parameter, is to declare a sequence of one to many HL7 fields. Each of these fields will retain its data type as defined in the original HL7 usage. Each field corresponds to a parameter in the Conformance Statement.
Note: It is the responsibility of the Server to declare explicitly the purpose of the query, the meaning of each of the query parameters, and the relationships among the parameters. These declarations are made in the Conformance Statement.
A second variant, the Query By Example, allows the specification of parameters within actual HL7 segments other than the QPD. For example, the Conformance Statement might permit the use of the PID segment to transmit specific patient identification parameters. Each such parameter is specified in the QBE Input Parameter Specification and QBE Input Parameter Field Description and Commentary tables.
The third variant uses a single QPD parameter in the form of a complex query selection expression. This field with its QSC data type allows the defining segment to be broader in scope and allows any field in the target data to be selected and filtered unless constrained through the Conformance Statement. It explicitly states any relational operators such as AND and OR. It is intended to support a wide range of combinations of parameters.
The difference in how parameters are passed in each of these three variants is as follows:
* Query by Simple Parameter passes each client value to the Server positionally using only the third and successive fields of the QPD segment.
* Query By Example passes parameters using HL7 segments, such as PID, that are defined in the endpoint application chapters. The third and successive fields of the QPD segment also may be used in this variant.
* In the QSC Selection Criteria variant, the parameter values are all contained within a single complex query selection expression that is passed in QPD-3.
Each generic query has a specific message syntax, a unique trigger event, and a unique message structure. Each generic response also has a specific message syntax, a unique trigger event, and a unique message structure.
There are three generic message structures, each of which accommodates the specific detail needed in each of the three response types.
* The QBP_Q11 structure supports a Segment Pattern Response and contains the MSH, QPD, RCP, and DSC segments. Its default trigger event is Q11. A standard or site-defined query may use this trigger event or may specify a unique trigger event value in its Conformance Statement. If a unique trigger event value is chosen for a site-defined query, that value must begin with Z.
* The QBP_Q13 structure supports a Tabular Response and contains the MSH, RCP, RDF, and DSC segments. Its default trigger event is Q13. A standard or site-defined query may use this trigger event or may specify a unique trigger event value in its Conformance Statement. If a unique trigger event value is chosen for a site-defined query, that value must begin with Z.
* The QBP_Q15 structure supports a Display Response and contains the MSH, QPD, RCP, and DSC segments. Its default trigger event is Q15. A standard or site-defined query may use this trigger event or may specify a unique trigger event value in its Conformance Statement. If a unique trigger event value is chosen for a site-defined query, that value must begin with Z.
The new queries support both immediate and deferred response. This information is carried in the RCP segment along with the execution date and time.
The query definition segment is echoed back in the response. This is particularly important in a continuation situation. Otherwise, the sender might be conceivably having to manage a queue of queries.

5.4.1 QBP/RSP - query by parameter/segment pattern response (events vary )

The QBP_Q11 structure supports a Segment Pattern Response and contains the MSH, QPD, RCP, and DSC segments. Its default trigger event is Q11. A standard or site-defined query may use this trigger event or may specify a unique trigger event value in its Conformance Statement. If a unique trigger event value is chosen for a site-defined query, that value must begin with Z.

The RSP_K11 supports a Segment Pattern Response to the QBP and contains the MSH, MSA, ERR, QAK, QPD, variable content segments, and the DSC. Its default trigger event is K11. A standard or site-defined response may use this trigger event or may specify a unique trigger event value in its Conformance Statement. If a unique trigger event value is chosen for a site-defined response, that value must begin with Z.
Note on QBP: Query By Example variant: 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. A Conformance Statement which uses this variant must replace the ellipses in the input QBP_Q11 grammar above, with the specific segments that it accepts.
Note: The indicated trigger events are the default values for MSH-9-2-Trigger event. Standard and site-defined queries may use these trigger events or may specify unique trigger event values in their Conformance Statements. Unique trigger event values for site-defined queries must begin with Z.
Note on RSP: The conformance statement for each QBP/RSP pair shall specify an explicit segment pattern grammar in place of the ellipses shown above in the RSP_K11 grammar.

5.4.2 QBP/RTB - query by parameter/tabular response (events vary)

The QBP_Q13 structure supports a Tabular Response and contains the MSH, RDF, RCP, and DSC segments. Its default trigger event is Q13. A standard or site-defined query may use this trigger event or may specify a unique trigger event value in its Conformance Statement. If a unique trigger event value is chosen for a site-defined query, that value must begin with Z.
Unless otherwise specified in the query's Conformance Statement, the default value for the RDF segment shall be understood to contain all available fields from the Virtual Table. The Client may override the default RDF by specifying explicitly the columns to be returned.

The RTB_K13 supports a Tabular Response to the QBP and contains the MSH, MSA, ERR, QAK, QPD, RDF, RDT and the DSC. Its default trigger event is K13. A standard or site-defined response may use this trigger event or may specify a unique trigger event value in its Conformance Statement. If a unique trigger event value is chosen for a site-defined response, that value must begin with Z.
The RTB_K13 structure requires that, if any RDT segments are returned, they be preceded by an RDF segment containing the row definition specification for the RDT segments. If no RDF was sent in the query, the default RDF is returned in the RTB_K13.
Note: The indicated trigger events are the default values for MSH-9-2-Trigger event. Standard and site-defined queries may use these trigger events or may specify unique trigger event values in their Conformance Statements. Unique trigger event values for site-defined queries must begin with Z.

5.4.3 QBP/RDY - query by parameter/display response (events vary)

The QBP_Q15 structure supports a Display Response and contains the MSH, QPD, RCP, and DSC segments. Its default trigger event is Q15. A standard or site-defined query may use this trigger event or may specify a unique trigger event value in its Conformance Statement. If a unique trigger event value is chosen for a site-defined query, that value must begin with Z.

The RDY_K15 supports a Display Response to the QBP and contains the MSH, MSA, ERR, QAK, DSP, and the DSC. Its default trigger event is K15. A standard or site-defined response may use this trigger event or may specify a unique trigger event value in its Conformance Statement. If a unique trigger event value is chosen for a site-defined response, that value must begin with Z.
Note: The indicated trigger events are the default values for MSH-9-2-Trigger event. Standard and site-defined queries may use these trigger events or may specify unique trigger event values in their Conformance Statements. Unique trigger event values for site-defined queries must begin with Z.

5.4.4 QSB - Create subscription (event Q16)

See section 5.7 for more information about this event.

5.4.5 QVR - query for previous events (event Q17)

The Query for Previous Events is like a Query by Parameter with a Segment Pattern Response except that the response consists of zero to many messages of the type defined in the Conformance Statement rather than a single response message containing multiple iterations of the segment pattern. While the messages sent in response to a QVR will reflect events which occurred in the past, the time stamp in the message header will reflect the time the message is actually constructed (current time). It is also similar to the previous generation VQQ/RQQ Event Replay.
While the response is similar to subscription messages, it differs from subscription in that the response messages are the result of "interrogating" the database rather than events being triggered in the current timeframe.
In a Query for Previous Events, the Server still has to parse the query, but avoids the handshaking protocols required in normal query/response situations. The Server acknowledges the query with the general acknowledgement message ACK. The Server then transmits a sequence of messages as if they were simulated unsolicited messages. This is useful for low end systems that cannot/do not want to deal with the overhead of the query response message syntax, i.e., systems that can only process unsolicited update messages.
Systems that choose to offer the QVR should offer guidance in the Conformance Statement, where appropriate, concerning the scope and size of the data requested by the Client. Moreover, the Conformance Statement should contain language cautioning Clients of the potential for harm from getting messages out of the original sequence and/or context.
Use cases for this query are as follows: 1) to populate a database initially, 2) to recover from an extended down time on the part of the recipient, 3) to enable systems which normally receive unsolicited data to be extended to act as a query client with minimal modification.
Note: If there is a concern that it will be difficult to distinguish these messages from any current realtime messages, e.g., if they are going down the same pipe, the data offerer might choose to designate a unique MSH-3 Sending application for the messages it sends in response to a QVR. This would allow downstream systems to recognize which messages were the result of the QVR, versus which are the result of current realtime activity on the sending system. For example, there may be 2 systems receiving pharmacy dispense messages. If system A wishes to issue a QVR to receive a historical load, system B might misinterpret the QVR results coming over the pipe as actual live data. A separate Sending Application name would allow for easy differentiation.

The QVR message segments are identical to those of the QBP. A QVR conformance statement may use either the QSC or query by example syntactic variants as well as the query by simple parameter.

5.4.6 QCN/ACK - cancel query/acknowledge message (event J01)

5.4.7 QSX /ACK - cancel subscription/acknowledge message (event J02)

See Section 5.6 for more information about this event.

5.5 QUERY/RESPONSE MESSAGE SEGMENTS

This section includes all message segments, except for the general message segments, used for the query/response pairs recommended for use in v 2.4.

5.5.1 DSP - display data segment

The DSP segment is used to contain data that has been preformatted by the sender for display. The semantic content of the data is lost; the data is simply treated as lines of text.

5.5.1.0 DSP field definitions

5.5.1.1 DSP-1 Set ID - DSP (SI) 00061

Definition: This field is used optionally to number multiple display segments.

5.5.1.2 DSP-2 Display level (SI) 00062

Definition: This field contains numbering to define groups of fields as assigned by the individual sites or applications.

5.5.1.3 DSP-3 Data line (TX) 00063

Definition: This field contains an actual line as it should be displayed. As described for the TX data type, highlighting and other special display characteristics may be included.

5.5.1.4 DSP-4 Logical break point (ST) 00064

Definition: This field is non-null if this line is the last line of a logical break point in the response as defined by the responding system.
Often the lines of display text will fall into logical groups that differ from the physical size of a screen or printer page. For example, a complete battery or an entire radiology report might be thought of as comprising a logical group, though it might have as few as six or as many as 120 lines. Knowledge of the logical break points in the display data can be useful to the application system that is displaying or printing data. For this reason, DSP-4-Logical break point is used. The sending application (the one that formats the data) places the logical break points where appropriate. If there is a particular ancillary result ID associated with the data delineated by DSP-4-Logical break point, the value of this ID also can be returned in DSP-5-Result ID. Then if the user selects the area of the display delineated by DSP-4-Logical break point, the displaying system can query for the associated DSP-5-Result ID.

5.5.1.5 DSP-5 Result ID (TX) 00065

Definition: When the user selects a result ID (defined by DSP-4-Logical break point) from the screen display corresponding to a record in which DSP-5-Result ID is non-null, the application can initiate a second query (a separate session) to the ancillary with the QRD-10-What department data code filled in with this non-null value (e.g., the ancillary accession number or its equivalent). The ancillary response will contain the report referenced by this result ID (e.g., accession number). The ancillary should correlate the result ID with DSP-4-Logical break point as follows: If more than one line of text is sent per result, DSP-5-Result ID should be only non-null for a DSP segment that contains a non-null DSP-4-Logical break point. This field may be broken into components by local agreement. A common example might be to include placer order number, filler order number, and universal service identifier. Whenever such fields are used as components of the result ID, their components will be sent as subcomponents.

5.5.2 QAK- query acknowledgment segment

The QAK segment contains information sent with responses to a query. Although the QAK segment is required in the responses to the enhanced queries (see section 5.10.4), it may appear as an optional segment placed after the (optional) ERR segment in any query response (message) to any original mode query.

5.5.2.0 QAK field definitions

5.5.2.1 QAK-1 Query tag (ST) 00696

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 it is valued, the responding system is required to echo it back as the first field in the query acknowledgment 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. QAK-1-Query tag is not conditional on the presence of the QRD-1-Query ID field in the original mode queries: in the original mode queries QAK-1-Query tag is not used.

5.5.2.2 QAK-2 Query response status (ID) 00708

Definition: This field allows the responding system to return a precise response status. It is especially useful in the case where no data is found that matches the query parameters, but where there is also no error. It is defined with HL7 Table 0208 - Query response status.

5.5.2.3 QAK-3 Message query name (CE) 01375

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: This field contains the name of the query. These names are assigned by the function-specific chapters of this specification. Site-specific event replay query names begin with the letter "Z." Refer to User defined table 0471 - Query name for suggested values.

5.5.2.4 QAK-4 Hit count total (NM) 01434

Definition: This field, when used, contains the total number of records found by the Server that matched the query. For tabular responses, this is the number of rows found. For other response types, the Conformance Statement defines the meaning of a "hit."

5.5.2.5 QAK-5 This payload (NM) 01622

Definition: This field, when used, contains the total number of matching records that the Server sent in the current response. Where the continuation protocol is used to transmit the response in partial installments, this number will differ from the value sent in QAK-4-Hit count total.

5.5.2.6 QAK-6 Hits remaining (NM) 01623

Definition: This field, when used, contains the number of matching records found by the Server that have yet to be sent. It is only meaningful when the Server uses the continuation protocol to transmit partial responses.

5.5.3 QID- query identification segment

The QID segment contains the information necessary to uniquely identify a query. Its primary use is in query cancellation or subscription cancellation.

5.5.3.0 QID field definitions

5.5.3.1 QID-1 Query tag (ST) 00696

Definition: This field identifies the instance of a query.

5.5.3.2 QID-2 Message query name (CE) 01375

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: This field contains the name of the query. These names are assigned by the function-specific chapters of this specification. Site-specific query names begin with the letter "Z." Refer to User defi ned table 0471 - Query name for suggested values.
QPD - query parameter definition
The QPD segment defines the parameters of the query.

5.5.3.0 QPD field definitions

5.5.3.1 QPD-1 Message query name (CE) 01375

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
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 conformance statement for this query name, and it is in fact an identifier for that conformance statement. Site-specific query names begin with the letter "Z." Refer to User defined table 0471 - Q uery name for suggested values.

5.5.3.2 QPD-2 Query tag (ST) 00696

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.]

5.5.3.3 QPD-3 User parameters (Varies) 01435

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 Conformance Statement, 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 must inspect the required Conformance Statement 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 Conformance Statement.
Each parameter field may be specified in the Conformance Statement 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.4.5.3.1 and 5.4.5.3.2 below.
Parameter fields in the QPD segment appear in the same order as in the Conformance Statement.

5.5.3.3.1 Note on QPD usage for query by example variant.

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 Conformance Statement for the query.

5.5.4 QRI - query response instance segment

The QRI segment is used to indicate the weight match for a returned record (where the responding system employs a numeric algorithm) and/or the match reason code (where the responding system uses rules or other match options).
Examples of the use of this segment appear in Section 3.6, "MPI Queries."

5.5.4.0 QRI field definitions

5.5.4.1 QRI-1 Candidate confidence (NM) 01436

Definition: This field contains a numeric value indicating the match weight or confidence level associated with the record.
Example: |0.88| or |12.32|
One use of this optional field is in Patient Look-up transactions where the searching system employs a numeric algorithm for determining potential matches to patient/person look-ups.

5.5.4.2 QRI-2 Match reason code (IS) 01437

Definition: This field contains a coded value indicating what search components (e.g., name, birth date, social security number) of the record returned matched the original query where the responding system does not assign numeric match weights or confidence levels. In short, it provides a method for passing a descriptive indication of why a particular record was found.
.Refer to User-defined Table 0392 - Match reason for suggested values.

5.5.4.3 QRI-3 Algorithm descriptor (CE) 01438

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
Definition: This field contains a text value indicating the name or identity of the specific search algorithm to which the RCP-5 Search confidence threshold and the QRI-1 Candidate confidence refer. Note that there are sometimes significant differences among the algorithms in their numeric scales (e.g., one is 0-100, another might be 10 - 20) as well as their meanings of the same value (two algorithms with an 80% match might not return the same records). Refer to User-defined Table 0393 - Match algorithms for suggested values.

Example: |MATCHWARE_1.2^^HL7nnnn| or |LINKSOFT_2.01^HL7nnnn|
One use of this optional field is in Patient Look-up transactions where the searching system employs a numeric algorithm for determining potential matches to patient/person look-ups.

5.5.5 RCP - response control parameter segment

The RCP segment is used to restrict the amount of data that should be returned in response to query.