5. Query |
|
Chapter Chairs/Editors:
Mike Henderson Eastern Informatics
|
|
|
|
|
|
|
|
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.2_5.9 and the previously defined queries appear in section 5.10. Outstanding issues appear in the final section, 5.11
5.1 CHAPTER 5 CONTENTS
5.2 INTRODUCTION
Topic | Section Reference |
---|---|
Introduction | 5.2 |
Query/Response Model | 5.2.1 |
Evolution of the Query Standard | 5.2.2 |
Query Development Methodology | 5.2.3 |
Response Formats | 5.2.4 |
Query Specification Formats | 5.2.5 |
Summary Chart of Query/Response Pairs | 5.2.6 |
Query/Response Conformance Statement | 5.3 |
Query/Response Message Pairs | 5.3.3.4 |
Query/Response Message Segments | 5.5 |
Auxiliary Query Protocols | 5.6 |
Publish and Subscribe | 5.7 |
Query Implementation Considerations | 5.8 |
Query/Response Message Examples | 5.9 |
Superceded Query/Response Trigger Events and Message Pairs | 5.10 |
Display Messages | 5.10.1 |
Original Mode Queries | 5.10.2 |
Enhanced Mode Queries | 5.10.4 |
Other Query/Response Message Segments | 5.10.5 |
Other Query Examples | 5.10.6 |
Outstanding Issues | 5.11 |
data regarding a single patient, e.g., send all lab results for patient #123456
data regarding multiple patients, e.g., send the list of patients whose attending physician is Dr. #123
data that is not patient related, e.g., send the age specific normal values for serum protein.
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.
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.
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._
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).
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.
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.
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.
Versions of the HL7 standard after 2.3.1 more cleanly separate how a query is specified from how the data is returned, and they emphasize 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 after Version 2.3.1 consists of defining a format for Conformance Statements, and giving examples of query design and use.
Note: Version 2.5 introduces a new, use-case-based mechanism for conformance in Section 2.12 of Chapter 2. Query implementers are encouraged to review and, where appropriate, adopt the profiling structures outlined in that section. Current Conformance Statement structures are retained in Chapter 5 pending revision to the new structures in the next version of the Standard.
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 versions of HL7 prior to 2.4, 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.
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:
As traditional HL7 segments. (See section 5.2.4.1, _Segment pattern response._.)
As rows and columns of data from a precisely defined Virtual Table. (See section 5.2.4.2, _Tabular response._)
As rows of human readable text ready to output to a screen or printer. (See section 5.2.4.3, _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:
Introduction including title, trigger events, mode, characteristics and purpose
Query Grammar
Response Grammar
Input Specification and Commentary
Response Control
Output specifications and Commentary
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.
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.
HL7 recognizes three main styles of representing responses to queries: tabular, segment pattern, or display. Segment pattern and tabular were previously known as record-oriented as described in earlier versions of this Standard. Segment pattern responses consist of a set of HL7 segments. Each query will define, in its conformance statement, the precise grammar of HL7 segments that it will return. Tabular responses return data as a set of rows, one RDT segment per row. Display queries return data in DSP segments. An HL7 conformant system interested in supporting queries will choose one or more of these styles before proceeding with a detailed design.
Tabular | The responding system formats the data in a relational format, as rows and columns. |
Segment pattern | The responding system formats the data on the basis of an application-specific segment-oriented (record-oriented) message. |
Display | The responding system formats the data in human readable format for direct outputting to a display device (in both original and enhanced modes). |
These structures support all original mode and enhanced mode responses, as well as the 2.4 queries.
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.
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.
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.
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.
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.
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.
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.
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.
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^Q13^QBP_Q13|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.
Query Modalities | |
---|---|
Simple Parameter Variant | The Server specifies parameters and the Client passes specific values to the parameters when the query is invoked |
Complex Expression Variant | The Server offers variables which can be used by the Client who passes a constraining expression (subject to any limitations specified by the Conformance Statement) over those variables when invoking the query |
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.
The following chart delineates the query/response messages defined in chapter 5:
Description | Query | Response | Response type | Defining segment(s) | Sec Ref |
---|---|---|---|---|---|
Cancel query | QCN |
|
|
| 5.4.6 |
Embedded query language query | EQQ |
| Enhanced mode (superceded) | EQL | 5.10.4.1 |
Query By Parameter | QBP |
|
| QPD | 5.4.1, 5.4.2, 5.4.3 |
Query, original Mode | QRY |
| Original mode (superceded) | QRD/QRF | 5.10.2 |
Event Replay Query | RQQ |
| Enhanced mode (superceded) | ERQ | 5.10.4.2 |
Stored procedure request | SPQ |
| Enhanced mode (superceded) | SPR | 5.10.4.3 |
Virtual Table query | VQQ |
| Enhanced mode (superceded) | VTQ | 5.10.4.4 |
Display response |
| RDY | Display | DSP | 5.4.3 |
Enhanced display response |
| EDR | Enhanced mode (superceded) | DSP | 5.10.4.3, 5.10.4.4 |
Event replay response |
| ERP | Enhanced mode (superceded) | ERQ | 5.10.4.2, 5.10.4.3 |
Response Segment Pattern |
| RSP | Segment pattern |
| 5.4.1 |
Response tabular |
| RTB | tabular | RDF/RDT | 5.4.2 |
Tabular Data Response |
| TBR | tabular | RDF/RDT | 5.10.4.4 |
Unsolicited display message | UDM |
| Display (superceded) | URD/URS | 5.10.1.2 |
The following chart delineates the query/response messages defined in the functional chapters:
Description | Query | Response | Response type | Defining segment(s) | Sec Ref |
---|---|---|---|---|---|
ADT response | QRY^A19 | ADR^A19 | Original mode | QRD/QRF | 3.3.19 |
Allocate identifiers | QBP^Q24 | RSP^K24 | Segment pattern | QBP | 3.3.59 |
Ancillary RPT (display) (for backward compatibility only) |
| ARD | Original mode |
| 7 |
Find candidates | QBP^Q22 | RSP^K22 | Segment pattern | QBP | 3.3.57 |
Get corresponding identifiers | QBP^Q23 | RSP^K23 | Segment pattern | QBP | 3.3.58 |
Get person demographics | QBP^Q21 | RSP^K21 | Segment pattern | QBP | 3.3.56 |
Order status query/ Order status response | OSQ^Q06 | OSR^Q06 | Original mode | QRD/QRF | 4.4.3 |
Pharmacy administration information | QRY^Q27 | RAR^RAR | Original mode | QRD/QRF | 4.13.14 |
Master files query | MFQ |
| Original mode |
| 8.4.3 |
Master files query response |
| MFR | Original mode |
| 8.43 |
Personnel information | QBP^Qnn | RSP^Knn | Segment pattern | QBP | 15.3.7 |
Pharmacy dispense information | QRY^Q28 | RDR^RDR | Original mode | QRD/QRF | 4.13.15 |
Pharmacy dose information | QRY^Q30 | RGR/RGR | Original mode | QRD/QRF | 4.13.17 |
Pharmacy encoded order information | QRY^Q29 | RER^RER | Original mode | QRD/QRF | 4.13.16 |
Pharmacy prescription order response | QRY^Q26 | ROR^ROR | Original mode | QRD/QRF | 4.13.13 |
Request clinical information | RQC^I05 |
| Original mode | QRD/QRF | 11.3.5 |
Results of observation, query for | QRY^R02 | ORF^R04 | Original mode | QRD/QRF | 7.2.2 |
Return Clinical Information |
| RCI^I05 | Original mode | QRD/QRF | 11.2.5 |
Return Clinical List |
| RCL^I06 | Original mode | QRD/QRF | 11.3.6 |
Return patient referral | RRI |
| Original mode |
| 11.5 |
Return patient referral |
| RRI | Original mode |
| 11.5 |
Schedule query | SQM |
| Original mode |
| 10.5.3 |
Schedule query response |
| SQR | Original mode |
| 10.5.3 |
Query for vaccination record | VXQ^V01 |
| Original mode |
| 4.17.3 |
Vaccination query record response |
| VXR^V03 | Original mode |
| 4.17.5 |
Vaccination query response with multiple PID matches |
| VXX^V02 | Original mode |
| 4.17.4 |
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.
Note: Version 2.5 introduces a new, use-case-based mechanism for conformance in Chapter 2. Query implementers are encouraged to review and, where appropriate, adopt the profiling structures outlined in that chapter. Current Conformance Statement structures are retained in Chapter 5 pending revision to the new structures in the next version of the Standard.
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.
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||
Conformance Statement
5.3 QUERY/RESPONSE CONFORMANCE STATEMENT
5.3.1 Using the conformance statement
5.3.1.0
5.3.1.1 Query with tabular response example
5.3.1.2 Example of Conformance Statement with tabular response
Query ID | Z99 |
Query Type | Query (or Publish) |
Query Name | Who Am I |
Query Trigger | QBP^Z99^QBP_Q13 |
Both | |
Response Trigger | RSP^Z84^RSP_K11 |
Query Characteristics | Returns response sorted by PatientLastName unless otherwise specified. |
Query Purpose | Find the identity of the patient for specified medical record number(s) |
Response Characteristics | Returns response sorted by PatientLastName unless otherwise specified. |
Query Trigger | QBP^Z99^QBP_Q13 |
QBP^Z99^QBP_Q13 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ RDF ] | Table Row Definition Segment |
| 5.5.6.6 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RSP^Z84^RSP_K11 | Response Grammar: RTB Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.4.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ | --- ROW_DEFINITION begin |
|
|
|
RDF | Table Row Definition Segment |
| 5.5.6.6 | DB |
[ { RDT } ] | Table Row Data Segment |
| 5.5.6 | DB |
] | --- ROW_DEFINITION end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Z99) | Field Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | PatientList | S | Y | 20 | CX | O |
|
|
| PID-3 |
| PID-3 Patient Identifier List |
Input Parameter (Query ID=Z99) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z99^WhoAmI^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
PatientList |
| CX |
|
|
|
|
Components: ^ < assigning authority (HD)> ^ |
|
|
| The combination of values for PatientID, and PatientIDAssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientIDTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) This PATIENT_MASTER entry will be searched against on the PHARMACY_DISPENSE_TRANSACTION table to retrieve the rows fulfilling the query conditions. |
|
|
| If this field is not valued, all values for this field are considered to be a match. |
|
|
|
|
| ID | ST | If this field, PID.3.1, is not valued, all values for this field are considered to be a match. |
| Assigning Authority | HD | If this field, PID.3.4, is not valued, all values for this field are considered to be a match. |
| Identifier Type Code | IS | If this field, PID.3.5, is not valued, all values for this field are considered to be a match. |
Field Seq (Query ID=Z99) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
6 | Sort-by Field |
| 256 | SRT |
|
|
| Sort-by Field |
| ST | Segment field name of an output column by which the response may be sorted. Must contain a Y in the Sort column of the output specification table. |
|
| Sequencing |
| ID | As specified in HL7 Table 0397- Sequencing. Default is Ascending. |
ColName (Query ID=Z99) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
PatientName |
|
| 48 | XPN |
|
|
|
| PID.5 |
| PID-5 Patient Name |
Mother_sMaidenName |
|
| 48 | XPN |
|
|
|
| PID.6 |
| PID-6 Mother_s Maiden Name |
DOB |
|
| 26 | TS |
|
|
|
| PID.7 |
| PID-7 Date/Time of Birth |
Sex |
|
| 1 | IS |
|
|
|
| PID.8 |
| PID-8 Sex |
Race |
|
| 80 | CE |
|
|
|
| PID.10 |
| PID-10 Race |
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.
Before composing the Conformance Statement, express the query in ordinary English sentences.
Transform the query into a mathematical or pseudo-language statement. A syntax such as SQL provides a useful mechanism.
From the pseudo-statement, extract the parameters and the operations upon the parameters.
Advertise the parameters in the Conformance Statement.
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.
The Conformance Statement begins with a table that summarizes the characteristics and identifying information about the query to which the Conformance Statement applies.
Conformance Statement
5.3.2 Formal specification of the conformance statement
5.3.2.0
5.3.2.1 Steps for developing a conformance statement
5.3.2.2 Conformance Statement introduction
Query ID |
|
Query Type | Query (or Publish) |
Query Name |
|
Query Trigger |
|
|
|
Response Trigger |
|
Query Characteristics |
|
Query Purpose |
|
Response Characteristics |
|
Query Trigger |
|
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.6.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.
The Conformance Statement shows a query grammar. This is a brief model of the segments used in the query message.
QBP^Znn^QBP_Qnn | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ RDF ] | Table Row Definition Segment |
| 5 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
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.
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.
RTB^Znn^RTB_Knn | Response Grammar: Widget Dispense Message | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
_ |
|
|
|
|
_ |
|
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
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.
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.
RDY^Znn^RDY_K15 | Response Grammar: Dispense History | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ { DSP } ] | Display Data |
| 5.5.1 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
The data will display as follows: (Query ID=Z99) |
---|
DSP|| GENERAL HOSPITAL _ PHARMACY DEPARTMENT DATE:mm-dd-yy |
DSP|| DISPENSE HISTORY REPORT PAGE n |
DSP||MRN Patient Name MEDICATION DISPENSED DISP-DATE |
DSP||XXXXX XXXXXx, XXXXX XXXXXXXXXXXXXXXX mm/dd/ccyy |
_ |
DSP|| << END OF REPORT >> |
Field Seq (Query ID=Z99) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.16 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 _ Relational 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.
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 (Query ID=Znn) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z99^WhoAmI^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
InputItem_ |
| CX |
|
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.
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
Segment Field Name (Query ID=Z99) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
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).
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
Input Parameter (Query ID=Znn) | Comp. Name | DT | Description |
|
|
|
|
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.
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 (Query ID=Znn) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
|
|
|
|
|
|
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.
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
ColName (Query ID=Znn) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
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.
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 (Query ID=Znn) | Comp. Name | DT | Description |
---|---|---|---|
|
|
|
|
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.
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
ColName (Query ID=Z99) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
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.
Conformance Statement
Query ID |
|
Query Type | Query (or Publish) |
Query Name |
|
Query Trigger |
|
|
|
Response Trigger |
|
Query Characteristics |
|
Query Purpose |
|
Response Characteristics |
|
Query Trigger |
|
QBP^Znn^QBP_Q13 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ RDF ] | Table Row Definition Segment |
| 5.5.6.6 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RTB^Znn^RTB_K13 | Response Grammar: RTB Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.4.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ | --- ROW_DEFINITION begin |
|
|
|
RDF | Table Row Definition Segment |
| 5.5.6.6 | DB |
[ { RDT } ] | Table Row Data Segment |
| 5.5.6 | DB |
[ | --- ROW_DEFINITION end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Znn) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | InputItem . . . |
|
|
|
|
|
|
|
|
|
|
|
Input Parameter (Query ID=Znn) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE |
Must be valued Znn^ |
QueryTag |
| ST | Unique to each query message instance. |
InputItem1 |
| DataType |
|
|
|
| Components: (if applicable) |
|
|
| (Description) |
|
|
| (Valuation note) |
|
|
|
|
| Component1 (if applicable) | DataType | (Valuation note) |
ColName (Query ID=Znn) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
ColName (Query ID=Znn) | Comp. Name | DT | Description |
---|---|---|---|
|
|
|
|
Segment Field Name (Query ID=Znn) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Service Identifier Code | Element Name |
|
|
|
|
|
|
|
|
|
|
|
|
Input Parameter (Query ID=Znn) | Comp. Name | DT | Description |
|
|
|
|
Field Seq (Query ID=Znn) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
|
|
|
|
|
|
ColName (Query ID=Znn) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Conformance Statement
5.3.3.2 Conformance statement template for query with segment pattern response
Query ID |
|
Query Type | Query (or Publish) |
Query Name |
|
Query Trigger |
|
|
|
Response Trigger |
|
Query Characteristics |
|
Query Purpose |
|
Response Characteristics |
|
Query Trigger |
|
QBP^Znn^QBP_Q11 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RSP^Znn^RSP_K11 | Response Grammar: RSP Message | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ _ ] | (additional segments according to the data to be produced) |
|
|
DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Znn) | Col Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | InputItem . . . |
|
|
|
|
|
|
|
|
|
|
|
Input Parameter (Query ID=Znn) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE |
Must be valued Znn^ |
QueryTag |
| ST | Unique to each query message instance. |
InputItem1 |
| DataType |
|
|
|
| Components: (if applicable) |
|
|
| (Description) |
|
|
| (Valuation note) |
|
|
|
|
| Component1 (if applicable) | DataType | (Valuation note) |
ColName (Query ID=Znn) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
ColName (Query ID=Znn) | Comp. Name | DT | Description |
---|---|---|---|
|
|
|
|
Segment Field Name (Query ID=Znn) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Service Identifier Code | Element Name |
|
|
|
|
|
|
|
|
|
|
|
|
Input Parameter (Query ID=Znn) | Comp. Name | DT | Description |
|
|
|
|
Field Seq (Query ID=Znn) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
|
|
|
|
|
|
Conformance Statement
5.3.3.3 Conformance statement for query with display response
Query ID |
|
Query Type | Query (or Publish) |
Query Name |
|
Query Trigger |
|
|
|
Response Trigger |
|
Query Characteristics |
|
Query Purpose |
|
Response Characteristics |
|
Query Trigger |
|
QBP^Znn^QBP_Q15 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RDY^Znn^RDY_K15 | Response Grammar: RDY Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ { DSP } ] | Display Data |
| 5.5.1 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
The data will display as follows: (Query ID=Znn) |
---|
DSP|| (data in actual display format) |
Field Seq (Query ID=Znn) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
| InputItem |
|
|
|
|
|
|
|
|
|
|
|
Input Parameter (Query ID=Znn) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE |
Must be valued Znn^ |
QueryTag |
| ST | Unique to each query message instance. |
InputItem1 |
| DataType |
|
|
|
| Components: (if applicable) |
|
|
| (Description) |
|
|
| (Valuation note) |
|
|
|
|
| Component1 (if applicable) | DataType | (Valuation note) |
ColName (Query ID=Znn) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
ColName (Query ID=Znn) | Comp. Name | DT | Description |
---|---|---|---|
|
|
|
|
[The following table is used only for the Query By Example (QBE) variant.]
QBE Input Parameter Specification
Segment Field Name (Query ID=Znn) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Service Identifier Code | Element Name |
|
|
|
|
|
|
|
|
|
|
|
|
Input Parameter (Query ID=Znn) | Comp. Name | DT | Description |
|
|
|
|
Field Seq (Query ID=Znn) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
|
|
|
|
|
|
Response Type | Query Variant | Table Included | Section Reference |
---|---|---|---|
Display | None (QPD) | Conformance Statement introduction | 5.3.2.2 |
|
| Query grammar | 5.3.2.3 |
|
| Response grammar for display response | 5.3.2.5 |
|
| QPD input parameter specification | 5.3.2.6 |
|
| QPD input parameter field description and commentary | 5.3.2.7 |
|
| RCP input parameter field description and commentary | 5.3.2.10 |
Display | QBE | Conformance Statement introduction | 5.3.2.2 |
|
| Query grammar | 5.3.2.3 |
|
| Response grammar for display response | 5.3.2.5 |
|
| QPD input parameter specification | 5.3.2.6 |
|
| QPD input parameter field description and commentary | 5.3.2.7 |
|
| QBE input parameter specification | 5.3.2.8 |
|
| QBE input parameter field description and commentary | 5.3.2.9 |
|
| RCP input parameter field description and commentary | 5.3.2.10 |
Display | QSC | Conformance Statement introduction | 5.3.2.2 |
|
| Query grammar | 5.3.2.3 |
|
| Response grammar for display response | 5.3.2.5 |
|
| QPD input parameter specification | 5.3.2.6 |
|
| QPD input parameter field description and commentary | 5.3.2.7 |
|
| Input specification: virtual table | 5.3.2.11 |
|
| Virtual table field description and commentary | 5.3.2.12 |
Tabular | None (QPD) | Conformance Statement introduction | 5.3.2.2 |
|
| Query grammar | 5.3.2.3 |
|
| Response grammar | 5.3.2.4 |
|
| QPD input parameter specification | 5.3.2.6 |
|
| QPD input parameter field description and commentary | 5.3.2.7 |
|
| RCP input parameter field description and commentary | 5.3.2.10 |
|
| Output specification for tabular response | 5.3.2.13 |
Tabular | QBE | Conformance Statement introduction | 5.3.2.2 |
|
| Query grammar | 5.3.2.3 |
|
| Response grammar | 5.3.2.4 |
|
| QPD input parameter specification | 5.3.2.6 |
|
| QPD input parameter field description and commentary | 5.3.2.7 |
|
| QBE input parameter specification | 5.3.2.8 |
|
| QBE input parameter field description and commentary | 5.3.2.9 |
|
| RCP input parameter field description and commentary | 5.3.2.10 |
|
| Output specification for tabular response | 5.3.2.13 |
Tabular | QSC | Conformance Statement introduction | 5.3.2.2 |
|
| Query grammar | 5.3.2.3 |
|
| Response grammar | 5.3.2.4 |
|
| QPD input parameter specification | 5.3.2.6 |
|
| QPD input parameter field description and commentary | 5.3.2.7 |
|
| Input/output specification: virtual table | 5.3.2.11 |
|
| Virtual table field description and commentary | 5.3.2.12 |
|
| RCP input parameter field description and commentary | 5.3.2.10 |
Segment pattern | None (QPD) | Conformance Statement introduction | 5.3.2.2 |
|
| Query grammar | 5.3.2.3 |
|
| Response grammar | 5.3.2.4 |
|
| QPD input parameter specification | 5.3.2.6 |
|
| QPD input parameter field description and commentary | 5.3.2.7 |
|
| RCP input parameter field description and commentary | 5.3.2.10 |
Segment pattern | QBE | Conformance Statement introduction | 5.3.2.2 |
|
| Query grammar | 5.3.2.3 |
|
| Response grammar | 5.3.2.4 |
|
| QPD input parameter specification | 5.3.2.6 |
|
| QPD input parameter field description and commentary | 5.3.2.7 |
|
| QBE input parameter specification | 5.3.2.8 |
|
| QBE input parameter field description and commentary | 5.3.2.9 |
|
| RCP input parameter field description and commentary | 5.3.2.10 |
Segment pattern | QSC | Conformance Statement introduction | 5.3.2.2 |
|
| Query grammar | 5.3.2.3 |
|
| Response grammar | 5.3.2.4 |
|
| QPD input parameter specification | 5.3.2.6 |
|
| QPD input parameter field description and commentary | 5.3.2.7 |
|
| Input specification: virtual table | 5.3.2.11 |
|
| Virtual table field description and commentary | 5.3.2.12 |
|
| RCP input parameter field description and commentary | 5.3.2.10 |
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 QUERY/RESPONSE MESSAGE PAIRS
5.4.1 QBP/RSP _ query by parameter/segment pattern response (events vary )
QBP^Q11^QBP_Q11 | Query By Parameter | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
QPD | Query Parameter Definition Segment |
| 5 | DB |
[_ | --- QBP begin |
|
|
|
[ _ ] | Optional query by example segments |
|
|
DB |
_] | --- QBP end |
|
|
|
RCP | Response Control Parameters |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
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.
RSP^K11^RSP_K11 | Segment Pattern Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgement |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgement |
| 5 | DB |
QPD | Query Parameter Definition Segment |
| 5 | DB |
[ | --- SEGMENT_PATTERN begin |
|
|
|
_ | Segment Pattern from Conformance Statement |
|
|
DB |
] | --- SEGMENT_PATTERN end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2 | DB |
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.
QBP^Q13^QBP_Q13 | Query By Parameter | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
QPD | Query Parameter Definition Segment |
| 5 | DB |
[_ | --- QBP begin |
|
|
|
[ _ ] | Optional query by example segments |
|
|
DB |
_] | --- QBP end |
|
|
|
[ RDF ] | Table Row Definition Segment |
| 5 | DB |
RCP | Response Control Parameters |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
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.
RTB^K13^RTB_K13 | Table Based Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgement |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgement |
| 5 | DB |
QPD | Query Definition Segment |
| 5 | DB |
[ | --- ROW_DEFINITION begin |
|
|
|
RDF | Table Row Definition Segment |
| 5 | DB |
[ { RDT } ] | Table Row Data Segment |
| 5 | DB |
] | --- ROW_DEFINITION end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2 | DB |
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.
QBP^Q15^QBP_Q15 | Query By Parameter | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
QPD | Query Parameter Definition Segment |
| 5 | DB |
[ _ ] | Optional query by example segments |
|
|
DB |
RCP | Response Control Parameters |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
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.
RDY^K15^RDY_K15 | Display Based Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgement |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgement |
| 5 | DB |
QPD | Query Parameter Definition Segment |
| 5 | DB |
[ { DSP } ] | Display Data |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
|
|
|
|
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.
See section 5.7 for more information about this event.
QSB^Q16^QSB_Q16 | Create Subscription | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
QPD | Query Parameter Definition |
| 5 | DB |
RCP | Response Control Parameters |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
ACK^Q16^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QVR^Q17^QVR_Q17 | Query for Previous Events | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
QPD | Event Definition Segment |
| 5 | DB |
[_ | --- QBP begin |
|
|
|
[ _ ] | Optional query by example segments |
|
|
DB |
_] | --- QBP end |
|
|
|
RCP | Response Control Parameters |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
ACK^Q17^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
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.
QCN^J01^QCN_J01 | Cancel Query | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
QID | Query identification Segment |
| 5 | DB |
ACK^J01^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QSX^J02^QCN_J01 | Cancel Subscription | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
QID | Query identification Segment |
| 5 | DB |
ACK^J02^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
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.
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.
HL7 Attribute Table _ DSP _ Display Data
5.5 QUERY/RESPONSE MESSAGE SEGMENTS
5.5.1 DSP - display data segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 4 | SI | O |
|
| 00061 | Set ID - DSP | DB |
2 | 4 | SI | O |
|
| 00062 | Display Level | DB |
3 | 300 | TX | R |
|
| 00063 | Data Line | DB |
4 | 2 | ST | O |
|
| 00064 | Logical Break Point | DB |
5 | 20 | TX | O |
|
| 00065 | Result ID | DB |
Definition: This field is used optionally to number multiple display segments.
Definition: This field contains numbering to define groups of fields as assigned by the individual sites or applications.
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.
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.
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.
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.
HL7 Attribute Table _ QAK _ Query Acknowledgment
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
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 32 | ST | C |
|
| 00696 | Query Tag | DB |
2 | 2 | ID | O |
| 0208 | 00708 | Query Response Status | DB |
3 | 250 | CE | O |
| 0471 | 01375 | Message Query Name | DB |
4 | 10 | NM | O |
|
| 01434 | Hit Count | DB |
5 | 10 | NM | O |
|
| 01622 | This payload | DB |
6 | 10 | NM | O |
|
| 01623 | Hits remaining | DB |
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.
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.
HL7 Table 0208 - Query Response Status
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
Value | Description | Comment |
---|---|---|
OK | Data found, no errors (this is the default) |
|
NF | No data found, no errors |
|
AE | Application error |
|
AR | Application reject |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
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.
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._
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.
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.
The QID segment contains the information necessary to uniquely identify a query. Its primary use is in query cancellation or subscription cancellation.
HL7 Attribute Table _ QID _ Query Identification
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
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 32 | ST | R |
|
| 00696 | Query Tag | DB |
2 | 250 | CE | R |
| 0471 | 01375 | Message Query Name | DB |
Definition: This field identifies the instance of a query.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
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 defined table 0471 - Query name for suggested values.
The QPD segment defines the parameters of the query.
HL7 Attribute Table _ QPD _ Query Parameter Definition
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.4 QPD _ query parameter definition
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 250 | CE | R |
| 0471 | 01375 | Message Query Name | DB |
2 | 32 | ST | C |
|
| 00696 | Query Tag | DB |
3-n | 256 | varies |
|
|
| 01435 | User Parameters (in successive fields) | DB |
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
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 - Query name for suggested values.
User-defined Table 0471 _ Query name
5.5.4.0 QPD field definitions
5.5.4.1 QPD-1 Message Query Name (CE) 01375
Value | Description | Comment |
---|---|---|
| No suggested values defined |
|
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 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.
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.
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.3.57, "Find Candidates and Response."
HL7 Attribute Table _ QRI _ Query Response Instance
5.5.4.2 QPD-2 Query Tag (ST) 00696
5.5.4.3 QPD-3 User Parameters (Varies) 01435
5.5.4.3.1 Note on QPD usage for query by example variant.
5.5.5 QRI _ query response instance segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 10 | NM | O |
|
| 01436 | Candidate Confidence | DB |
2 | 2 | IS | O | Y | 0392 | 01437 | Match Reason Code | DB |
3 | 250 | CE | O |
| 0393 | 01438 | Algorithm Descriptor | DB |
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.
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.
User-defined Table 0392 _ Match reason
5.5.5.0 QRI field definitions
5.5.5.1 QRI-1 Candidate Confidence (NM) 01436
5.5.5.2 QRI-2 Match Reason Code (IS) 01437
Value | Description | Comment |
---|---|---|
DB | Match on Date of Birth |
|
NA | Match on Name (Alpha Match) |
|
NP | Match on Name (Phonetic Match) |
|
SS | Match on Social Security Number |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
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.
User-defined Table 0393 _ Match algorithms
5.5.5.3 QRI-3 Algorithm Descriptor (CE) 01438
Value | Description | Comment |
---|---|---|
LINKSOFT_2.01 | Proprietary algorithm for LinkSoft v2.01 |
|
MATCHWARE_1.2 | Proprietary algorithm for MatchWare v1.2 |
|
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.
The RCP segment is used to restrict the amount of data that should be returned in response to query.
HL7 Attribute Table _ RCP _ Response Control Parameter
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 1 | ID | O |
| 0091 | 00027 | Query Priority | DB |
2 | 10 | CQ | O |
| 0126 | 00031 | Quantity Limited Request | DB |
3 | 250 | CE | O |
| 0394 | 01440 | Response Modality | DB |
4 | 26 | TS | C |
|
| 01441 | Execution and Delivery Time | DB |
5 | 1 | ID | O |
| 0395 | 01443 | Modify Indicator | DB |
6 | 512 | SRT | O | Y |
| 01624 | Sort-by Field | DB |
7 | 256 | ID |
| Y |
| 01594 | Segment group inclusion | DB |
Definition: This field contains the time frame in which the response is expected. Refer to HL7 Table 0091 - Query priority for valid values. Table values and subsequent fields specify time frames for response.
HL7 Table 0091 - Query priority
5.5.6.0 RCP field definitions
5.5.6.1 RCP-1 Query Priority (ID) 00027
Value | Description | Comment |
---|---|---|
D | Deferred |
|
I | Immediate |
|
Components: <Quantity (NM)> ^ <Units (CE)>
Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Definition: This field contains the maximum length of the response that can be accepted by the requesting system. Valid entries are numerical values (in the first component) given in the units specified in the second component. Default is LI (lines).
Refer to HL7 Table 0126 - Quantity limited request for valid entries for the second component. In a segment pattern response, a line is defined as a single segment.
HL7 Table 0126 - Quantity limited request
5.5.6.2 RCP-2 Quantity Limited Request (CQ) 00031
Value | Description | Message Usage | Comment |
---|---|---|---|
CH | Characters | RSP/RTB/RDY | Used where size of input buffer has limitations |
LI | Lines | RTB/RDY |
|
PG | Pages | RDY |
|
RD | Records | RSP/RTB/RDY | In RSP record = hit |
ZO | Locally defined |
|
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field specifies the timing and grouping of the response message(s). Refer to HL7 Table 0394 _ Response modality for valid values.
HL7 Table 0394 _ Response modality
5.5.6.3 RCP-3 Response Modality (CE) 01440
Value | Description | Comment |
---|---|---|
R | Real Time |
|
T | Bolus (a series of responses sent at the same time without use of batch formatting) |
|
B | Batch |
|
Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
Specifies the time the response is to be returned. This field is only valued when RCP-1-Query priority contains the value D (Deferred).
Definition: This field specifies whether the subscription is new or is being modified. Refer to HL7 Table 0395 - Modify indicator for valid values.
Table 0395 _ Modify indicator
5.5.6.4 RCP-4 Execution and Delivery Time (TS) 01441
5.5.6.5 RCP-5 Modify Indicator (ID) 01443
Value | Description | Comment |
---|---|---|
N | New Subscription |
|
M | Modified Subscription |
|
Components: <Sort-by Field (ST)> ^ <Sequencing (ID)>
Definition: For queries requesting a tabular response, this field specifies by which fields the response is to be sorted, and the order(s) in which sorting is to be performed. When the QSC variant is not in use, the values specified for the first component in this field are derived from the ColName field of the Output Specification and Commentary; see Section 5.3.3.1. When the QSC variant is used, the values are derived from the ColName field of the Input/Output Specification and Commentary; see Section 5.9.4.1 for an example.
Each repetition of this field specifies a single sort field. Thus, the first repetition of this field specifies the primary sort field; the second repetition specifies the secondary sort field; etc.
Definition: Specifies those optional segment groups which are to be included in the response. Refer to HL7 Table 0391_Segment group for values for Segment Group. This is a repeating field, to accommodate inclusion of multiple segment groups. The default for this field, not present, means that all relevant groups are included.
Note: Although the codes for segment groups are taken from HL7 Table 0391, the exact segment-level definition of a segment group (e.g. PIDG) is given only in the conformance statement of the query in which this segment group appears.
For example,
HL7 Table 0391 _ Segment group
5.5.6.6 RCP-6 Sort-by Field (SRT) 01624
5.5.6.7 RCP-7 Segment Group Inclusion (ID) 01594
Value | Description | Comment |
---|---|---|
PIDG | PID group |
|
OBRG | OBR group |
|
ORCG | ORC group |
|
RXAG | RXA group |
|
RXDG | RXD group |
|
RXEG | RXE group |
|
RXOG | RXO group |
|
Etc |
|
|
Note: HL7 Table 0391 _ Segment group currently includes no values defined by HL7. As values are agreed upon in conformance statements balloted by HL7 Technical Committees, they will be included in this table.
The RDF segment defines the content of the row data segments (RDT) in the tabular response (RTB).
As an optional segment in a query either a QBP or QBS, this segment can be used to limit the number of columns returned and to specify what column positions the fields occupy (where supported, these features can be used to override the defaults for the particular query). If omitted, all fields defined for the query are returned in their default column order.
As a required segment in a tabular response (RTB) to either a QBP or QBS, this segment defines the contents of the table row data (RDT) segments that follows. It is not necessarily an echo back of the segment as it appeared in the query.
HL7 Attribute Table _ RDF _ Table Row Definition
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 3 | NM | R |
|
| 00701 | Number of Columns per Row | DB |
2 | 40 | RCD | R | Y | 0440 | 00702 | Column Description | DB |
Definition: This field specifies the number of data columns (and therefore the number of fields) contained within each row of returned data.
Components: <Segment Field Name (ST)> ^ <HL7 Data Type (ID)> ^ <Maximum Column Width (NM)>
Definition: Each repetition of this field consists of three components:
The segment field name that identifies the field occupying the column. The segment field name must agree with the column name as it appears in the Conformance Statement. Use of the @ sign as prefix to the column name is optional.
The 2 or 3 character HL7 data type, as defined in chapter 2. Refer to HL7 Table 0440 - Data types for valid values.
The maximum width of the column, as dictated by the responding system. (This may vary from the HL7-defined maximum field length.)
The RDT segment contains the row data of the tabular data response message (TBR).
HL7 Attribute Table _ RDT _ Table Row Data
5.5.7.0 RDF field definitions
5.5.7.1 RDF-1 Number of Columns Per Row (NM) 00701
5.5.7.2 RDF-2 Column Description (RCD) 00702
5.5.8 RDT - table row data segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1-n | 99999 | varies | R |
|
| 00703 | Column Value | DB |
Definition: This field is a requested field. Fields occur in the position order defined for the query or table (unless overridden by an optional RDF segment on a stored procedure request or Virtual Table query message), separated by field delimiters.
This section discusses properties of queries that can be described as global properties. These properties enable the Client and Server to deal with timing and sizing issues and to handle exceptions.
Responses to queries can be either immediate or deferred. In the immediate mode, the responding process gives the response immediately or in a short period during which the requesting process will wait for the response. In the deferred mode, the response is returned asynchronously, as a separate message pair. Also, a time interval for the deferred transaction may be specified.
In the case of immediate mode query, the Server does NOT send a General Acknowledgement (ACK). The acknowledgement of the query is contained within the response message. In the case of deferred mode, the query is acknowledged immediately by an ACK. The Server sends the deferred response at the appropriate time. The Client acknowledges the response with an ACK. In short, the deferred query transaction consists of 2 _round trips_.
If an immediate mode query message is malformed, a negative ACK is immediately sent.
Use cases for Deferred include
evaluate the query conditions at a certain point in time and then return the response. For example, At 9 AM tomorrow, evaluate query and return response.
produce a large report to be communicated to the Server at an off-peak hour. For example, a response containing all admissions records for the month to be sent at 4:00 a.m., or a reference lab results listing to be sent at noon. A deferred response can benefit both Server and Client in such cases, especially where the generation, communication, and receipt of segments can all be done at times of otherwise low-volume processing.
If the Conformance Statement indicates that the Server will support both immediate and deferred responses, then the Client may indicate the desired value of this property by sending it in the RCP-1 Response priority field. If the Server supports only one response type, then the value specified by the Client must agree.
The following examples demonstrate how the same query could be invoked in either immediate or deferred mode.
The Client submits the following query and indicates that an immediate response is desired by setting RCP-1-Response priority to _I_.
MSH|^~\&|PCR|Gen Hosp|PIMS||199811201400-0800||QBP^Q42^QBP_Q13|ACK9901|P|2.4||||||||
QPD|Q42^Tabular Dispense History^HL7nnn|Q0010|555444222111^^^MPI^MR| |19980531|19990531|
RCP|I|999^RD|
RDF|3|PatientList^ST^20~PatientName^XPN^48~MedicationDispensed^ST^40~RXD.3^TS^26
The Server responds one minute later.
MSH|^~\&|PIMS|Gen Hosp|PCR||199811201401-0800||RTB^K42^RTB_K13|8858|P|2.3||||||||
MSA|AA|8699|
QAK|Q010|OK|Q42^Tabular Dispense History^HL7nnn|4
QPD|Q42^Tabular Dispense History^HL7nnn|Q0010|555444222111^^^MPI^MR||19980531|19990531|
RDF|7|PatientId^CX^20~PatientName^XPN^48~OrderControlCode^ID^2~ MedicationDispensed^CE^100~DispenseDate^TS^26~QuantityDispensed^NM^20~ OrderingProvider^XCN^120
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|525440345^Verapamil Hydrochloride 120 mg TAB^NDC |199805291115-0700|100|77^Hippocrates^Harold^H^III^DR^MD
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |19980821-0700|100|77^Hippocrates^Harold^H^III^DR^MD
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|00172409660^BACLOFEN 10MG TABS^NDC |199809221415-0700|10|88^Semmelweis^Samuel^^^DR^MD
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|199810121145-0700|10|99^Lister^Lenora^^^DR^MD
The Client submits the following query and indicates that a deferred response is desired by setting RCP-1-Response priority to _D_.
MSH|^~\&|PCR|Gen Hosp|PIMS||199811201400-0800||QBP^Q42^QBP_Q13|ACK9901|P|2.4||||||||
QPD|Q42^Tabular Dispense History^HL7nnn|Q0010|555444222111^^^MPI^MR| |19980531|19990531|
RCP|D|999^RD|
RDF|3|PatientList^ST^20~PatientName^XPN^48~MedicationDispensed^ST^40~RXD.3^TS^26
The Server responds one minute later with a general acknowledgement.
MSH|^~\&|PIMS|Gen Hosp|PCR||199811201401-0800||ACK^Q42^ACK|8875|P|2.4||||||||
MSA|AA|8699|
The Server responds the following morning with the desired data.
MSH|^~\&|PIMS|Gen Hosp|PCR||199811210300-0800||RTB^K42^RTB_K13|9950|P|2.3||||||||
QAK|Q010|OK|Q42^Tabular Dispense History^HL7nnn|4
QPD|Q42^Tabular Dispense History^HL7nnn|Q0010|555444222111^^^MPI^MR||19980531|19990531|
RDF|7|PatientId^CX^20~PatientName^XPN^48~OrderControlCode^ID^2~ MedicationDispensed^CE^100~DispenseDate^TS^26~QuantityDispensed^NM^20~ OrderingProvider^XCN^120
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|525440345^Verapamil Hydrochloride 120 mg TAB^NDC |199805291115-0700|100|77^Hippocrates^Harold^H^III^DR^MD
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |19980821-0700|100|77^Hippocrates^Harold^H^III^DR^MD
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|00172409660^BACLOFEN 10MG TABS^NDC |199809221415-0700|10|88^Semmelweis^Samuel^^^DR^MD
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|199810121145-0700|10|99^Lister^Lenora^^^DR^MD
The Client responds immediately with a general acknowledgement.
MSH|^~\&|PCR|Gen Hosp|PIMS||199811210300-0800||ACK^K42^ACK|8750|P|2.4||||||||
MSA|AA|9950|
Canceling a query is equivalent to canceling an order in that it is asking the discontinuation of a request for which a response may already be on its way. In the case of an interactive query, a cancellation request is a courtesy on the part of the Client, but not strictly required. How long the query will stay open is an implementation issue.
Although the effect to the Client is the same as if it had not sent any message (no further query data is received), receipt of this message by the Server enables it to discard any unsent continuation data that might be queued.
MSH|^~\&|||||||QCN^Jnn^QCN_J01|...
QID|Q001|Q99^SomeQuery^0003|...
...
The Interactive Continuation Protocol defines the methodology for the intentional transmission of a large query-response payload over multiple HL7 messages. Without this protocol, the response would be returned in a single large logical message.
The protocol is called interactive because there is an ongoing dialog between the Client and the Server. The dialog commences when the Client issues a query for a potentially large amount of data, but specifies in the RCP-2-Quantity limited request, that only a limited amount of data is to be returned in each continued response. The Server then returns one response message containing data up to the requested quantity. The Client may continue to ask for further subsets of the data until the entire set is exhausted or may choose to cancel the query.
This use of the term _continuation_ responses in queries should not be confused with its use in continuing an unsolicited fragmented message. In the case of continuing a response to query the control is on the side of the querying application and there is an explicit cancellation event. In the case of continuation of an unsolicited message, the control is on the part of the sending application and there is no concept of canceling the message transmission.
Segment fragmentation and message fragmentation are discussed in chapter 2.
The rules for the interactive continuation (of a query response) are as follows:
If the Server is sending a subset of the data, the message is terminated with a DSC segment with the DSC-1-Continuation pointer set to the appropriate pointer value and the DSC-2 -Continuation type set to _L_.
If the Client wishes to receive the next installment, the query is sent again with a DSC segment following the RCP. The DSC-1-Continuation pointer echoes the value sent by the Server.
The Server continues to send installments in response to the Client_s request until there is no more data. The end of data is signified by the absence of the DSC segment OR an empty value in DSC-1-Continuation pointer.
If the Client wishes to cancel the query before the end of the data is reached, a Cancel query is sent.
In addition to DSC-1-Continuation pointer, QAK-1-Query tag may be used to confirm to the Client which query instance the Server is responding to, since the Client may not be relied upon to have retained the text of each query message and continuation request.
The value of MSH-10-Message control ID will be different for every message sent by the Client (i.e., the initial query and each continuation request). Thus the value of MSA-2-Message control ID for each message sent by the Server (which echoes the value of MSH-10-Message control ID from the Client) will vary among multiple response payload messages. By contrast, QAK-1-Query tag will remain the same across all response payload messages to a given query instance.
One use of queries is to retrieve data from one application for presentation to users of another. This approach might be used for users of a patient care system retrieving data from lab or other ancillaries. It also might permit users of a pharmacy system to retrieve a patient_s lab results from the lab system or non-pharmacy order data from the patient care system. Almost any other application system could be the source of data or the system initiating the query for its users.
Of particular interest is the case where the inquiring user formulates the query online at the terminal of one system and waits while that system sends the query to another. The inquiring user gets the response and displays it at their terminal. The user formulating such a query may only have limited understanding of what data is available for a given patient. Sometimes the user_s preference would be to make a simple query such as _give me recent data in reverse chronological sequence_ rather than _give me data for yesterday,_ since there may be some data available for today, or there may be data from two days ago that is of interest. The user will look at the data returned and simply quit looking at it after finding the part that is of interest. (The time frames or the sort sequence may differ, or the user may wish to impose some selectivity on the response, but the general principle remains the same. The user would prefer to make a vague statement of the interest, have the data presented in order of decreasing likelihood of interest, and quit when he or she has seen enough.)
While beneficial to the user, this way of requesting data could be very burdensome when the resulting query takes place over an inter-application interface. If the Server were to retrieve, format, and send all the data the user might like to see, the processing load would be extremely high and the response time unacceptable.
The interactive continuation protocol provides a way to permit the users to formulate queries loosely while limiting the processing burden on the Server. The Client specifies the general constraints of the query and an amount of data to be returned. (For example, the query might be for lab results for patient #12379 and 44 lines would be requested.) The Server retrieves and formats the specified amount of data and returns it with a special key field, DSC-1-Continuation pointer. The Server presents the requested data to the user and retains the continuation pointer field for use if another query is needed. The internal structure of the value is not known to the Client.
If, after viewing the data, the user requests more, the Client sends the query again in a format that is identical with the first, except that DSC-1-Continuation pointer value is included and the requested amount of data may be changed. The Server may use the continuation pointer field as a key into its database to continue retrieval and formatting of the results. If the user does not request more data, no further messages are exchanged.
The initiating system may also explicitly terminate the query by sending a QCN^J01 (cancel query) message. Prior to HL7 Version 2.4, a _cancel query_ message was formatted just like a continuation query, except that the event-type (MSH-9-message type) was set equal to CNQ. (The CNQ trigger event is retained for backward compatibility only.) Receipt of the QCN^J01 message by the responding system enables it to discard any unsent continuation data that might be queued.
The user wishes to know all the medications dispensed for the period between January 1, 1998, and December 31, 1999 for the patient whose medical record number is _555444222111_. The Client submits the following query and invokes the interactive continuation protocol. Note that the quantity has been limited to 8 lines.
MSH|^~\&|PCR|Gen Hosp|IE||200009171400-0800||QBP^Q41^QBP_Q15|8699|P|2.4||||||||
QPD|Q41^DispenseHistory^HL7nnnn|Q001|555444222111^^^MPI ^MR||19980101|19991231|
RCP|I|8^LI|
The pharmacy system identifies medical record number _555444222111_ as belonging to Adam Everyman and locates 7 prescription dispenses meeting the criteria. As shown in the following response, eight lines of data are returned as requested. The response ends with a DSC segment showing the continuation pointer and the indication that this is a logical breaking point.
MSH|^~\&|PIMS|Gen Hosp|PCR||200009171401-0800||RDY^R41^RDY_R15|8858|P|2.3||||||||
MSA|AA|8699|
QAK|Q001|OK|Q41^DispenseHistory^HL7nnnn|^8
QPD|Q41^DispenseHistory^HL7nnnn|Q001|555444222111^^^MPI^MR||19980101|19991231|
DSP|| GENERAL HOSPITAL _ PHARMACY DEPARTMENT DATE:09-17-00
DSP|| DISPENSE HISTORY REPORT PAGE 1
DSP||MRN Patient Name MEDICATION DISPENSED DISP-DATE
DSP||555444222111 Everyman,Adam VERAPAMIL HCL 120 mg TAB 10/12/1999
DSP||555444222111 Everyman,Adam VERAPAMIL HCL ER TAB 180MG 09/21/1999
DSP||555444222111 Everyman,Adam BACLOFEN 10MG TABS 08/22/1999
DSP||555444222111 Everyman,Adam THEOPHYLLINE 80MG/15ML SOL 05/29/1999
DSP|| << END OF Screen>>
DSC|77|L|
The Client wishes to receive another payload.
MSH|^~\&|PCR|Gen Hosp|IE||199811201405-0800||QBP^Q41^QBP_Q15|8890|P|2.4||||||||
QPD|Q41^DispenseHistory^HL7nnnn|Q001|555444222111^^^MPI^MR||19980101|19991231|
RCP|I|8^LI|
DSC|77|L|
The Server returns the next payload and indicates in QAK-4-Hit count that this is the last of the data..
MSH|^~\&|PIMS|Gen Hosp|PCR||199811201407-0800||RDY^R15^RDY_R15|8898|P|2.3||||||||
MSA|AA|8890|
QAK|Q001|OK|Q41^DispenseHistory^HL7nnnn|^7^^Y|
QPD|Q41^DispenseHistory^HL7nnnn|Q001|555444222111^^^MPI^MR||19980101|19991231|
DSP|| GENERAL HOSPITAL _ PHARMACY DEPARTMENT DATE:09-17-99
DSP|| DISPENSE HISTORY REPORT PAGE 1
DSP||MRN Patient Name MEDICATION DISPENSED DISP-DATE
DSP||555444222111 Everyman,Adam VERAPAMIL HCL 120 mg TAB 05/29/1998
DSP||555444222111 Everyman,Adam VERAPAMIL HCL ER TAB 180MG 04/21/1998
DSP||555444222111 Everyman,Adam BACLOFEN 10MG TABS 04/22/1998
DSP|| << END OF REPORT>>
The query/response is now completed.
Query responses, like unsolicited updates, may need to force the continuation of a message, or even a segment, across multiple physical messages. This is more precisely described as fragmenting. Fragmentation is discussed in detail in chapter 2. Those aspects pertaining to how this would apply to a query response are repeated here for the reader_s convenience.
The Client requests the last chest x-ray for the patient whose medical record number is 555444222111. The following query is submitted.
MSH|^~\&|CIS||RAD||199910180900-0700||QBP^Q61^QBP_Q11|7777|P|2.4|
QPD|Q61^Radiology Result^HL7nnnn|Q98|555444222111^^^^MR|
RCP|I|
The Server returns the following response but the OBX segment that contains a DICOM image overflows its buffer. The segment is fragmented as follows:
MSH|^~\&|RAD||CIS||||RSP^K61^RSP_K61|5555|P|2.4|
MSA|AA|7777|
QAK|Q98|OK|Q61^Radiology Result^HL7nnnn|
QPD|Q61^Radiology Result^HL7nnnn|Q98|555444222111^^^^MR|
PID|||5554442221111^^^^MR|
ORC
OBR
OBX||ED|13^^L||abcdefghij|
ADD|
DSC|99|F|
The Client returns an ACK upon receipt of the response.
MSH|^~\&|CIS||RAD||||ACK^K61^ACK|7780|P|2.4|
MSA|AA|5555|
The Server sends the following continued response. Note that the ADD segment will contain the remainder of the data from the fragmented segment. The response then continues on as normal.
MSH|^~\&|RAD||CIS||||RSP^K61^RSP_K61|5560|P|2.4||99|
ADD|klmnop|
OBX|
_
The Client returns an ACK upon receipt of the response.
MSH|^~\&|CIS||RAD||||ACK|7782|P|2.4|
MSA|AA|5560|
The HL7 query also can be used to query for a batch in the following manner:
Use the value B of RCP-3-Response modality to specify a batch response.
Note: If using old style query mode, the value BB or BL of QRD-5-Deferred response type may be used to specify a batch response. The query will be acknowledged with a general acknowledgment as in the Deferred Access example above
in addition, insert into the batch file the query defining and RCP segments as follows:
5.5.8.0 RDT field definitions
5.5.8.1 RDT-1 Column Value (varies) 00703
5.6 AUXILIARY QUERY PROTOCOLS
5.6.1 Immediate vs. deferred response
5.6.1.0
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.0
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
[ FHS ] | (file header segment) | DB |
{ [BHS] | (batch header segment) | DB |
QPD |
Query defining segment Note: if using old style query mode, the QRD and QRF segments may be used.
|
DB |
[ RCP ] |
|
|
{ MSH | (one or more HL7 messages) | DB |
.... |
|
|
.... |
|
|
.... |
|
|
} |
|
|
[ BTS ] | (batch trailer segment) | DB |
} |
|
|
[ FTS ] | (file trailer segment) | DB |
the acknowledgment of a batch is described in chapter 2.
The Conformance Statement should stipulate if the batch modality is supported.
A query/response error can occur at 3 levels:
Communication failure (broken connection, timeout)
Malformed message (message reject)
Malformed query (application error)
If the application receiving the query detects an error while processing the query, the preferred method of response is to return an Application Error (AE) or Application Reject (AR) condition in the MSA-1-Acknowledgement code of the applicable query response message. Further description of the error code is to be included in ERR-1-Error code and location. Note that MSA-6-Error condition is retained for backward compatibility for those applications not using the ERR segment. Thus far, this method is consistent with the methods used elsewhere for reporting errors in acknowledgement messages, irrespective of the type of message being acknowledged. In addition, because this is a query response, it is important to include the QAK segment because it specifies the query tag that will identify the particular query instance that was in error. This is of particular importance where a query response may span more than one message.
In summary, use the ERR segment to describe the error if the message fails because of
a malformed message
a malformed query _ problem with query tag, problems with parameters
The ERR segment supercedes QAK-2-Query response status.
There are 3 common situations that can arise in a query error response:
Situation 1: Malformed Message
The query message itself is bad. The parser does not get to the actual query content. Something is wrong with the envelope, i.e., the message is malformed.
The only response is a negative ACK message containing the MSH, MSA and the ERR. That is, the Server creates an ACK message with AR in MSA-1-Acknowledgement code in the above sentence. The dialogue is ended.
Situation 2: Malformed Query
The query message got to the Server and is legitimate, but the Server cannot process the query for some reason, i.e., the query is malformed.
The Response message indicates a negative acknowledgement and shows the problem in the ERR. The response message contains the MSH, MSA, ERR, QAK and the query defining segment if available. That is, the Server creates an ACK message with AE in MSA-1-Acknowledgement code in the above sentence. The rest of the message is absent.
Note that the continuation (DSC) segment is not sent or, if it is, its continuation pointer field (DSC-1-Continuation pointer) is null.
Note: The use of AE (application error) and AR (application reject) codes in QAK-2-Query response status has been deprecated in favor of the ERR segment.
Situation 3: No data found
The query is well formed, but there is no data to be returned by the query. This is not strictly an error condition. This example clarifies the protocol to be followed.
The Response message contains MSH, MSA, QAK, and query defining segment. The QAK would indicate _no records found_. The rest of the message is absent, i.e., no blank rows or segments are sent.
Note: If the responding application successfully processes the query, but is unable to find any qualifying data, this is not an error condition. The responding application returns an Application Accept (AA) in the MSA segment of the query response message, but does not return any data segments (DSP, RDT, or iterations of the items that are counted in hit counts). The continuation (DSC) segment is not sent or, if it is, its continuation pointer field (DSC-1- Continuation pointer) is null. If the QAK segment is being used, the field QAK-2-Query response status is valued with NF (no data found, no errors).
This section outlines the framework/process of the publish and subscribe machinery.
_Publish and subscribe_ refers to the ability of one system, the _Publisher_, to offer a data stream that can be sent to recipient systems upon subscription. In one sense, the entire HL7 unsolicited update paradigm, in which the sender sends out a stream of messages to recipients, is a kind of publish and subscribe mechanism. Subscriptions to unsolicited updates are established at interface set-up time when analysts on both sides agree to start sending a stream of data.
This section describes a mechanism by which the Publisher defines a stream of data, but also agrees to selectively subset the message stream based on query-like data constraints. In the normal case, the right of the Subscriber to subscribe is decided at interface setup time. At runtime, the Subscriber controls the data rules under which it sends messages.
Runtime subscription has existed in earlier versions of HL7, but little attention has been drawn to it. Original mode queries could define an open ended time interval in QRF-9-When quantity/timing qualifier. The unexplained semantics of this field had been interpreted to mean: If the QRF-9 specified an end time in the future, then the source system would keep sending results using the query continuation protocol.
This section elaborates on such a mechanism, and more cleanly ties the selective filtering into the whole query facility.
Subscription is a process/protocol that allows one system to request that prospective data be sent for a specified period of time, or for an open-ended period of time until further notice. It allows a message stream to be selectively filtered by a query-like mechanism. Specific messages have been defined for subscription and the canceling of a subscription.
A Publisher is one who possesses and transmits streams of data. The Publisher might be a mediator or a broker, such as an interface engine. The Publisher is not necessarily the system that collected the data, but it is the system willing to transmit it
With traditional _unsolicited update subscriptions_, a Publisher sends the entire data stream to the recipients. A Publisher normally transmits unfiltered data. However, the Publisher may agree to selectively filter the stream of data within parameters as defined by analysts. For each filterable stream, the Publisher defines a Conformance Statement that lists the data values that may be used in the filter expression, and defines the segment pattern for the messages that are selected.
If supported in the Conformance Statement, a subscription may be modified at a later date. RCP-6-Modify indicator is set to _M_, and the Action Code parameter is set to _A_ or _D_ as appropriate. If modification is allowed, the Server bears responsibility for maintaining the filter list. If, as is usually the case, the onus of retaining the filters is on the Client, modification is not allowed and would not be part of the Conformance statement.
A lab system normally sends all reports to the central archive. To provide better service to other departments, the Lab decides to offer a filtered stream in addition to the full stream going to the archive.
The lab decides that it will allow recipients to select based on the MRN of the patient, on the type of study (OBR-4), and on the ordering provider (OBR-16). It names this filtered stream "ORU-Subscription", and writes a conformance specification.
At interface setup time, permission is given for four systems, CommunityNorth, CommunitySouth, CommunityEast and CommunityWest to receive this filtered stream.
The Conformance Statement for this published filtered stream might be:
Conformance Statement
Query ID | Z83 |
Query Type | Publish |
Query Name | ORU Subscription |
Query Trigger | QSB^Z83^QSB_Q16 |
Both | |
Response Trigger | ORU^R01^ORU_R01 |
Query Characteristics | Returns lab results reports for the patient(s) as constrained in the input parameters. |
Query Purpose | Sends Lab Results, either filtered or unfiltered, as specified in the input parameters. |
Response Characteristics | A standard query response is not received from the server. Instead, actual ORU messages are returned corresponding to the constraints expressed in the input parameters. |
Query Trigger | QSB^Z83^QSB_Q16 |
QSB^Z83^QSB_Q16 | Query Grammar: QSB Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
ORU^R01^ORU_R01 | Response Grammar: ORU Message | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
{ | --- PATIENT RESULT_begin |
|
|
|
[ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3.4.2 | DB |
[ PD1 ] | Additional Demographics |
| 3.4.10 | DB |
[ { NTE } ] | Notes and comments |
| 2.15.10 | DB |
[ { NK1 } ] | Next of Kin/Associated Parties |
| 3.3.5 | DB |
[ | --- VISIT begin |
|
|
|
PV1 | Patient Visit |
| 3.4.3 | DB |
[ PV2 ] ] | Patient Visit _ Additional Info. |
| 3.4.4 | DB |
] | --- VISIT end |
|
|
|
] | --- PATIENT end |
|
|
|
{ | --- ORDER_OBSERVATION begin |
|
|
|
[ ORC ] | Order Common |
| 4.5.1 | DB |
OBR | Observations Request |
| 7.4.1 | DB |
[ { NTE } ] | Notes and Comments |
| 2.15.10 | DB |
[{ | --- TIMING_QTY begin |
|
|
|
TQ1 | Timing/Quantity |
| 4.5.4 | DB |
[ { TQ2 } ] | Timing/Quantity Order Sequence |
| 4.5.5 | DB |
}] | --- TIMING_QTY end |
|
|
|
[ CTD ] | Contact Data |
| 11.6.4 | DB |
[{ | --- OBSERVATION begin |
|
|
|
OBX | Observation/Result |
| 7.4.2 | DB |
[ { NTE } ] | Notes and Comments |
|
|
DB |
}] | --- OBSERVATION end |
|
|
|
[ { FT1 } ] | Financial Transaction |
| 6.5.1 | DB |
[ { CTI } ] | Clinical Trial Identification |
| 7.8.4 | DB |
{ [ | --- SPECIMEN begin |
|
|
|
SPM | Specimen |
| 7.4.3 | DB |
[ { OBX } ] | Observation Related to Specimen |
| 7.4.2 | DB |
] } | --- SPECIMEN end |
|
|
|
} | --- ORDER_OBSERVATION end |
|
|
|
} | --- PATIENT_RESULT end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
QPD Input Parameter Specification
Field Seq (Query ID=Z83) | ColName |
Key/
Search | Sort | LEN | DT | Opt | RP/# | Match Op | TBL # | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
| Message Query Name |
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
| Query Tag |
3 | MRN |
|
|
| CX | O | Y |
|
| PID.3 |
|
|
4 | ActionCode |
|
|
| ID | O |
|
| 0323 |
|
|
|
5 | PatientLocation |
|
|
| PL | O | Y |
|
| PV1.3 |
|
|
6 | HospitalService |
|
|
| IS | O | Y |
|
| PV1.10 |
|
|
7 | SRVC |
|
|
| CE | O | Y |
|
| OBR.4 |
|
|
8 | PVDR |
|
|
| CN | O | Y |
|
| OBR.16 |
|
|
Input Parameter (Query ID=Z83) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z83^ORU Subscription^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
MRN |
| CX | One or more patient identifiers may be sent. When a list is provided, results will be sent if any parameter matches any ID known for a patient. Sending no value matches all patients |
ActionCode |
| ID | If the subscription is being modified, the desired action e.g., Add or Delete is carried in this field. |
PatientLocation |
| PL | When a list is provided, results will be sent if any parameter matches PV1.3 for any result. Sending no value matches all results. |
HospitalService |
| IS | When a list is provided, results will be sent if any parameter matches PV1.10 for any result. Sending no value matches all results. |
SRVC |
| CE | When a list is provided, results will be sent if any parameter matches OBR.4 for any result.. Sending no value matches all results. |
PVDR |
| CN | When a list is provided, results will be sent if any parameter matches OBR.16 for any result.. Sending no value matches all results. |
Field Seq (Query ID=Z99) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
7 | Segment group inclusion |
| 256 | ID | What segment group(s) are to be included. If this field is not valued, all segment groups will be included. |
To establish the subscription to see lab results for two patients, an authorized Subscriber (e.g. CommunityWest) would send a query message with event code Q99
MSH|^~\&|CPR|COMWEST|PS^LAB||||QSB^Q99^QSB_Q16|8888|P|2.4|
QPD|Q99^ORU_Subscription^HL7nnnn|Q0044|1234^^^MPI^MR~4567^^^MPI^MR|
RCP||||||N|
As results are generated by the Lab, they are all sent to the archive. In addition, the Lab has a list of all subscription requests (such as the message, above). For each message, it checks the query filters associated with the subscription against the message being considered. If the message matches the query, it is sent to the recipient.
For example, a hit on patient 4567 would result in the message:
MSH|^~\&|PS^LAB||CPR|COMWEST||||ORU^R01^ORU_R01|4409|P|2.4|
PID|||4567^^^MPI^MR|....
OBR|....
OBX|...
Note: The result message has message type ORU^R01^ORU_R01 (as specified by the Conformance Statement).
Canceling a subscription is analogous to canceling a query. See sections 5.4.6 and 0.
The template would be as follows.
MSH|^~\&|||||||QSX^Jnn^QSX_J01|
QID...
To cancel the subscription cited in the previous section, CommunityWest would send a cancel message with event code J99.
MSH|^~\&|CPR|COMWEST|PS^LAB||||QSX^J99^QSX_J01|
QID|Q0044|Q99^ORU_Subscription^HL70003|
Implementation issues are discussed in section 5.1.
The following is the structure of the Pharmacy Dispense Information (RDR) message, an original-mode query that was defined in Chapter 4.
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.0
5.9.1.1 Proposed dispense history example and Conformance Statement
RDR^RDR | Pharmacy/treatment Dispense Information | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
MSA | Message Acknowledgment |
| 2.15.8 | DB |
[ { ERR } ] | Error |
| 2.15.5 | DB |
[ SFT ] | Software Segment |
| 2.15.12 | DB |
{ | --- DEFINITION begin |
|
|
|
QRD | Query Definition |
| 5.10.5.3 | DB |
[ QRF ] | Query Filter |
| 5.10.5.4 | DB |
[ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
|
|
DB |
[ { NTE } ] | Notes and Comments (for PID) |
| 2.15.10 | DB |
] | --- PATIENT end |
|
|
|
{ | --- ORDER begin |
|
|
|
ORC | Common Order |
|
|
DB |
[{ | --- TIMING begin |
|
|
|
TQ1 | Timing/Quantity |
| 4.5.4 | DB |
[ { TQ2 } ] | Timing/Quantity Order Sequence |
| 4.5.5 | DB |
}] | --- TIMING end |
|
|
|
[ | --- ENCODING begin |
| 4.5.1 | |
RXE | Pharmacy/Treatment Encoded Order |
| 4.14.4 | DB |
[{ | --- TIMING_ENCODED begin |
|
|
|
TQ1 | Timing/Quantity |
| 4.5.4 | DB |
[ { TQ2 } ] | Timing/Quantity Order Sequence |
| 4.5.5 | DB |
}] | --- TIMING_ENCODED end |
|
|
|
{ RXR } | Pharmacy/Treatment Route |
| 4.14.2 | DB |
[ { RXC } ] | Pharmacy/Treatment Component |
| 4.14.3 | DB |
] | --- ENCODING end |
|
|
|
{ | --- DISPENSE begin |
|
|
|
RXD | Pharmacy/Treatment Dispense |
| 4.14.5 | DB |
{ RXR } | Pharmacy/Treatment Route |
| 4.14.2 | DB |
[ { RXC } ] | Pharmacy/Treatment Component |
| 4.14.3 | DB |
} | --- DISPENSE end |
|
|
|
} | --- ORDER end |
|
|
|
} | --- DEFINITION end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
The function served by that query can be more clearly defined within the new query functionality. In the RDR message, the full meaning of the filter elements in the QRD and QRF segments could be discerned only by inference. By contrast, needed parameters can be explicitly defined in the Conformance Statement for the new Dispense History query, as shown in the following example.
Example: The user wishes to know all the medications dispensed for the patient whose medical record number is _555444222111_ for the period beginning 5/31/98 and ending 5/31/99. The following QBP message is generated.
MSH|^~\&|PCR|Gen Hosp|PIMS||199811201400-0800||QBP^Z81^QBP_Q11|ACK9901|P|2.4||||||||
QPD|Z81^Dispense History^HL7nnnn|Q001|555444222111^^^MPI^MR||19980531|19990531|
RCP|I|999^RD|
The pharmacy system identifies medical record number _555444222111_ as belonging to Adam Everyman and locates 4 prescription dispenses for the period beginning 5/31/98 and ending 5/31/99and returns the following RSP message:
MSH|^~\&|PIMS|Gen hosp|PCR||199811201400-0800||RSP^Z82^RSP_Z82|8858|P|2.4||||||||
MSA|AA|ACK9901|
QAK|Q001|OK|Z81^Dispense History^HL7nnnn|4|
QPD|Z81^Dispense History^HL7nnnn|Q001|555444222111^^^MPI^MR||19980531|19990531|
PID|||555444222111^^^MPI^MR||Everyman^Adam||19600614|M||C|2101 Webster # 106^^Oakland^CA^94612||^^^^^510^6271111|^^^^^510^6277654|||||343132266|||N|||||||||
ORC|RE||89968665||||||199805121345-0700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600||||||
RXE|1^BID^^19980529|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |120||mgm||||||||||||||||||||||||||
RXD|1|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |199805291115-0700|100|||1331665|3|||||||||||||||||
RXR|PO||||
ORC|RE||89968665||||||199805291030-0700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600||||||
RXE|1^^D100^^20020731^^^TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |100||180MG|TABLET SA|||G|||0|BC3126631^CHU^Y^L||213220929|0|0|19980821|||
RXD|1|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |19980821|100|||213220929|0|TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR||||||||||||
RXR|PO||||
ORC|RE||235134037||||||199809221330-0700|||88^Semmelweis^Samuel^^^DR^MD||^^^^^510^ 2673900||||||
RXD|1|00172409660^BACLOFEN 10MG TABS^NDC|199809221415-0700|10|||235134037|5|AS DIRECTED||||||||||||
RXR|PO||||
ORC|RE||235134030||||||199810121030-0700|||99^Lister^Lenora^^^DR^MD||^^^^^510^ 2673700||||||
RXD|1|00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|199810121145-0700|10|||235134030|5|AS DIRECTED||||||||||||
RXR|PO
Conformance Statement
Query ID | Z81 |
Query Type | Query |
Query Name | Dispense History |
Query Trigger | QBP^Z81^QBP_Q11 |
Both | |
Response Trigger | RSP^Z82^RSP_Z82 |
Query Characteristics | May specify patient, medication, a date range, and how the response is to be sorted. |
Query Purpose | To retrieve patient pharmacy dispense history information from the Server. |
Response Characteristics | Sorted by Medication Dispensed unless otherwise specified in SortControl. |
Query Trigger | QBP^Z81^QBP_Q11 |
QBP^Z81^QBP_Q11 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RSP^Z82^RSP_Z82 | Response Grammar: Pharmacy Dispense Message | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
{ | --- QUERY_RESPONSE begin |
|
|
|
[ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3.4.2 | DB |
[ PD1 ] | Additional Demographics |
| 3.4.9 | DB |
[ { NTE } ] | Notes and Comments (for PID) |
| 2.15.10 | DB |
[ | --- VISIT begin |
|
|
|
{ AL1 } | Allergy Information |
| 3.4.6 | DB |
[PV1 | Patient Visit |
| 3.4.3 | DB |
[ PV2 ] | Patient Visit _ Additional Info |
| 3.4.4 | DB |
] | --- VISIT end |
|
|
|
] | --- PATIENT end |
|
|
|
{ | --- COMMON_ORDER begin |
|
|
|
ORC | Common Order |
|
|
DB |
[{ | --- TIMING begin |
|
|
|
TQ1 | Timing/Quantity |
| 4.5.4 | DB |
[ { TQ2 } ] | Timing/Quantity Order Sequence |
| 4.5.5 | DB |
}] | --- TIMING end |
|
|
|
[ | --- ORDER_DETAIL begin |
|
|
|
RXO | Pharmacy/Treatment Order |
|
|
DB |
[ { NTE } ] | Notes and Comments (for RXO) |
| 2.15.10 | DB |
{ RXR } | Pharmacy/Treatment Route |
|
|
DB |
[ | --- TREATMENT begin |
|
|
|
{ RXC } | Pharmacy/Treatment Component |
|
|
DB |
[ { NTE } ] | Notes and Comments (for RXC) |
| 2.15.10 | DB |
] | --- TREATMENT end |
|
|
|
] | --- ORDER_DETAIL end |
|
|
|
[ | --- ENCODED_ORDER begin |
|
|
|
RXE | Pharmacy/Treatment Encoded Order |
|
|
DB |
[{ | --- TIMING_ENCODED begin |
|
|
|
TQ1 | Timing/Quantity |
| 4.5.4 | DB |
[ { TQ2 } ] | Timing/Quantity Order Sequence |
| 4.5.5 | DB |
}] | --- TIMING_ENCODED end |
|
|
|
{ RXR } | Pharmacy/Treatment Route |
|
|
DB |
[ { RXC } ] | Pharmacy/Treatment Component |
|
|
DB |
] | --- ENCODED_ORDER end |
|
|
|
RXD | Pharmacy/Treatment Dispense |
|
|
DB |
{ RXR } | Pharmacy/Treatment Route |
|
|
DB |
[ { RXC } ] | Pharmacy/Treatment Component |
|
|
DB |
{ | --- OBSERVATION begin |
|
|
|
[ OBX ] | Results |
|
|
DB |
[ { NTE } ] | Notes and Comments (for OBX) |
| 2.15.10 | DB |
} | --- OBSERVATION end |
|
|
|
} | --- COMMON_ORDER end |
|
|
|
} | --- QUERY_RESPONSE end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
Input Parameter Specification
Field Seq (Query ID=Z81) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
| PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
| MedicationDispensed | S | Y | 100 | CE | O |
| = |
| RXD.2 |
| RXD-2: Dispense/Give Code |
| DispenseDate.LL | S | Y | 26 | TS | O |
| > = |
| RXD.3 |
| RXD-3: Date/Time Dispensed |
| DispenseDate.UL | S | Y | 26 | TS | O |
| < = |
| RXD.3 |
| RXD-3: Date/Time Dispensed |
Input Parameter (Query ID=Z81) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z81^Dispense History^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
PatientList |
| CX | The combination of values for PatientList.ID, and PatientList.AssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientList.IdentifierTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) This PATIENT_MASTER entry will be searched against on the PHARMACY_DISPENSE_TRANSACTION table to retrieve the rows fulfilling the query conditions. |
|
|
| If this field is not valued, all values for this field are considered to be a match. |
|
|
| If one PID.3 is specified, only 1 segment pattern will be returned. |
| ID | ID | If this field, PID.3.1, is not valued, all values for this field are considered to be a match. |
| Assigning Authority | HD | If this field, PID.3.4, is not valued, all values for this field are considered to be a match. |
| Identifier type code | IS | If this field, PID.3.5, is not valued, all values for this field are considered to be a match. |
MedicationDispensed |
| CE | If this field is not valued, all values for this field are considered to be a match. |
DispenseDate.LL |
| TS | This is the earliest value to be returned for Date/Time Dispensed. If this field is not valued, all values for this field are considered to be a match. |
DispenseDate.UL |
| TS | This is the latest value to be returned for Date/Time Dispensed. If this field is not valued, all values for this field are considered to be a match. |
The user wishes to know all the medications dispensed for the patient whose medical record number is _555444222111_ for the period beginning 5/31/98 and ending 5/31/99. The following QBP message is generated.
MSH|^~\&|PCR|Gen Hosp|PIMS||199811201400-0800||QBP^Z85^QBP_Q11|8332|P|2.4||||||||
QPD|Z85^Pharmacy Information Comprehensive^HL7nnnn|Q002|555444222111^^^MPI^MR ||||19980531|19990531||RXO~RXG~RXA|
RCP|I|999^RD|
The pharmacy system identifies medical record number _555444222111_ as belonging to Adam Everyman and locates 4 prescription dispenses and an electrolytes panel for the period beginning 5/31/98 and ending 5/31/99and returns the following RSP message:
MSH|^~\&|PIMS|Gen hosp|PCR||199811201400-0800||RSP^Z86^RSP_Z86|8858|P|2.4||||||||
MSA|AA|8332|
QAK|Q002|OK|Z85^Pharmacy Information Comprehensive^HL70003|4|
QPD|Z85^Pharmacy Information Comprehensive^HL7nnnn|Q002|555444222111^^^MPI^MR ||||19980531|19990531||RXO~RXG~RXA|
PID|||555444222111^^^MPI^MR||Everyman^Adam||19600614|M||C|2101 Webster # 106^^Oakland^CA^94612||^^^^^510^6271111|^^^^^510^6277654|||||343132266|||N|||||||||
ORC|RE||89968665||||||199805121345-0700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600||||||
RXE|1^BID^^19980529|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |120||mgm||||||||||||||||||||||||||
RXD|1|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |199805291115-0700|100|||1331665|3|||||||||||||||||
RXR|PO||||
ORC|RE||89968665||||||199805291030-0700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600||||||
RXE|1^^D100^^20020731^^^TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |100||180MG|TABLET SA|||G|||0|BC3126631^CHU^Y^L||213220929|0|0|19980821|||
RXD|1|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |19980821|100|||213220929|0|TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR||||||||||||
RXR|PO||||
ORC|RE||235134037||||||199809221330-0700|||88^Semmelweis^Samuel^^^DR^MD||^^^^^510^ 2673900||||||
RXD|1|00172409660^BACLOFEN 10MG TABS^NDC|199809221415-0700|10|||235134037|5|AS DIRECTED||||||||||||
RXR|PO||||
ORC|RE||235134030||||||199810121030-0700|||99^Lister^Lenora^^^DR^MD||^^^^^510^ 2673700||||||
RXD|1|00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|199810121145-0700|10|||235134030|5|AS DIRECTED||||||||||||
RXR|PO
OBX|1|ST|2951-2^SODIUM^LN||150|mmol/l|136-148|H||A|F|19850301||199811180700-0800
OBX|2|ST|2823-3^POTASSIUM^LN||4.5|mmol/l|3.5-5|N||N|F|19850301||199811180700-0800
OBX|3|ST|2075-0^CHLORIDE^LN||102|mmol/l|94-105|N||N|F|19850301||199811180700-0800
OBX|4|ST|2028-9^CARBON DIOXIDE^LN||27|mmol/l|24-31|N||N|F|19850301||199811180700-0800
...
Note the use of OBX-14-Date/time of the observation to time the laboratory observations.
The following is a highly experimental approach to establishing a super segment pattern response to a general purpose query structure. It contains all of the pharmacy information segments as possible inclusions in the response. It differs from previously defined segment pattern queries in that it cuts across multiple related standard HL7 messages although there is a logical hierarchy that can be determined.
Conformance Statement
5.9.1.2 Comprehensive pharmacy information examples and Conformance Statement
5.9.1.2.1 Comprehensive pharmacy information Conformance Statement
Query ID | Z85 |
Query Type | Query |
Query Name | Pharmacy Information Comprehensive |
Query Trigger | QBP^Z85^QBP_Q11 |
Both | |
Response Trigger | RSP^Z86^RSP_Z86 |
Query Characteristics | May specify patient, medication, a date range, how the response is to be sorted, and what segment groups are to be returned. |
Query Purpose | To retrieve patient pharmacy history information from the Server. |
Response Characteristics | Sorted by Medication Dispensed unless otherwise specified in SortControl. |
Query Trigger | QBP^Z85^QBP_Q11 |
QBP^Z85^QBP_Q11 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RSP^Z86^RSP_Z86 | Response Grammar: Pharmacy Information Comprehensive | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
{ | --- QUERY_RESPONSE begin |
|
|
|
[ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3.4.2 | DB |
[ PD1 ] | Additional Demographics |
| 3.4.9 | DB |
[ { NTE } ] | Notes and Comments (for PID) |
| 2.15.10 | DB |
[{AL1} | Allergy Information |
| 3.4.6 | DB |
] | --- PATIENT end |
|
|
|
{ | --- COMMON_ORDER begin |
|
|
|
ORC | Common Order |
| 4.5.3 | DB |
[{ | --- TIMING begin |
|
|
|
TQ1 | Timing/Quantity |
| 4.5.4 | DB |
[ { TQ2 } ] | Timing/Quantity Order Sequence |
| 4.5.5 | DB |
}] | --- TIMING end |
|
|
|
[ | --- ORDER_DETAIL begin |
|
|
|
RXO | Pharmacy/Treatment Order |
| 4.14.1 | DB |
{ RXR } | Pharmacy/Treatment Route |
| 4.14.2 | DB |
[ { RXC } ] | Pharmacy/Treatment Component |
| 4.14.3 | DB |
] | --- ORDER_DETAIL end |
|
|
|
[ | --- ENCODED ORDER begin |
|
|
|
RXE | Pharmacy/Treatment Encoded Order |
| 4.14.4 | DB |
[{ | --- TIMING_ENCODED begin |
|
|
|
TQ1 | Timing/Quantity |
| 4.5.4 | DB |
[ { TQ2 } ] | Timing/Quantity Order Sequence |
| 4.5.5 | DB |
}] | --- TIMING_ENCODED end |
|
|
|
{ RXR } | Pharmacy/Treatment Route |
| 4.14.2 | DB |
[ { RXC } ] | Pharmacy/Treatment Component |
| 4.14.3 | DB |
] | --- ENCODED ORDER end |
|
|
|
[ | --- DISPENSE begin |
|
|
|
RXD | Pharmacy/Treatment Dispense |
| 4.14.5 | DB |
{ RXR } | Pharmacy/Treatment Route |
| 4.14.2 | DB |
[ { RXC } ] | Pharmacy/Treatment Component |
| 4.14.3 | DB |
] | --- DISPENSE end |
|
|
|
[ | --- GIVE begin |
|
|
|
RXG | Pharmacy/Treatment Give |
| 4.14.6 | DB |
{ RXR } | Pharmacy/Treatment Route |
| 4.14.2 | DB |
[ { RXC } ] | Pharmacy/Treatment Component |
| 4.14.3 | DB |
] | --- GIVE end |
|
|
|
[ | --- ADMINISTRATION begin |
|
|
|
RXA | Pharmacy/Treatment Administration |
| 4.14.7 | DB |
{ RXR } | Pharmacy/Treatment Route |
| 4.14.2 | DB |
[ { RXC } ] | Pharmacy/Treatment Component |
| 4.14.3 | DB |
] | --- ADMINISTRATION end |
|
|
|
{ | --- OBSERVATION begin |
|
|
|
[ OBX ] | Results |
| 7.4.2 | DB |
[ { NTE } ] | Notes and Comments (for OBX) |
| 2.15.10 | DB |
} | --- OBSERVATION end |
|
|
|
} | --- COMMON_ORDER end |
|
|
|
} | --- QUERY_RESPONSE end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Z85) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
4 | OrderControlCode | S |
| 2 | ID |
| Y |
| 0119 | ORC.1 |
| ORC-1: Order Control |
5 | OrderingProvider | S |
| 120 | XCN |
|
|
|
| ORC.12 |
| ORC-12: Ordering Provider |
6 | MedicationDispensed | S | Y | 100 | CE | O |
| = |
| RXD.2 |
| RXD-2: Dispense/Give Code |
7 | DispenseDate.LL | S | Y | 26 | TS | O |
| > = |
| RXD.3 |
| RXD-3: Date/Time Dispensed |
8 | DispenseDate.UL | S | Y | 26 | TS | O |
| < = |
| RXD.3 |
| RXD-3: Date/Time Dispensed |
Input Parameter (Query ID=Z85) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z85^Pharmacy Information Comprehensive^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
PatientList |
| CX | The combination of values for PatientList.ID, and PatientList.AssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientList.IdentifierTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) This PATIENT_MASTER entry will be searched against on the PHARMACY_DISPENSE_TRANSACTION table to retrieve the rows fulfilling the query conditions. |
|
|
| If this field is not valued, all values for this field are considered to be a match. |
|
|
| If one PID.3 is specified, only 1 segment pattern will be returned. |
| ID | ID | If this field, PID.3.1, is not valued, all values for this field are considered to be a match. |
| Assigning Authority | HD | If this field, PID.3.4, is not valued, all values for this field are considered to be a match. |
| Identifier type code | IS | If this field, PID.3.5, is not valued, all values for this field are considered to be a match. |
OrderControlCode |
| ID | If this field, ORC.1, is not valued, all values for this field are considered to be a match. |
OrderingProvider |
| XCN | If this field, ORC.12, is not valued, all values for this field are considered to be a match. |
MedicationDispensed |
| CE | If this field is not valued, all values for this field are considered to be a match. |
DispenseDate.LL |
| TS | This is the earliest value to be returned for Date/Time Dispensed. If this field is not valued, all values for this field are considered to be a match. |
DispenseDate.UL |
| TS | This is the latest value to be returned for Date/Time Dispensed. If this field is not valued, all values for this field are considered to be a match. |
Field Seq (Query ID=Z85) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
7 | Segment group inclusion |
| 256 | ID | What segment group(s) are to be included. If this field is not valued, all segment groups will be included. |
The following example demonstrates that the same results, as shown in the example in 5.9.1.1, can be obtained using the QSC variant. The difference is how the input parameters are expressed.
The user wishes to know all the medications dispensed for the patient whose medical record number is _555444222111_ for the period beginning 5/31/98 and ending 5/31/99. The following message is generated.
MSH|^~\&|PCR|Gen Hosp|PIMS||199811201300-0800||QBP^Z87^QBP_Q11|8698|P|2.4||||||||
QPD|Z87^Dispense Information^HL7nnnn|Q001|@PID.3^EQ^55544422211^AND~@ORC.1^EQ^RE^ AND~@RXD.3^GE^199805310000-0800^AND~@RXD.3^LE^199905310000-0800
RCP|I|999^RD|
The pharmacy system identifies medical record number _555444222111_ as belonging to Adam Everyman and locates 4 prescription dispenses for the period beginning 5/31/98 and ending 5/31/99 and returns the following RSP message:
MSH|^~\&|PIMS|Gen Hosp|PCR||199811201300-0800||RSP^Z88^RSP_Z88|8857|P|2.4||||||||
MSA|AA|8698|
QAK|Q001|OK|Z87^Dispense Information^HL7nnnn|4
QPD|Z87^Dispense Information^HL7nnnn|Q001|@PID.3^EQ^55544422211^AND~ORC.1^EQ^RE^ AND~@RXD.3^GE^199805310000-0800^AND~@RXD.3^LE^199905310000-0800
PID|||555444222111^^^MPI^MR||Everyman^Adam||19600614|M||C|2101 Webster # 106^^Oakland^CA^94612||^^^^^510^6271111|^^^^^510^6277654|||||343132266|||N|||||||||
ORC|RE||89968665||||||199905121345-0700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600||||||
RXE|1^BID^^19990529|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC |120||mgm||||||||||||||||||||||||||
RXD|1|00378112001^Verapamil Hydrochloride 120 mg TAB^NDC|199905291115-0700|100|||1331665|3|||||||||||||||||
RXR|PO||||
ORC|RE||89968665||||||199905291030-0700|||77^Hippocrates^Harold^H^III^DR^MD||^^^^^510^ 2673600||||||
RXE|1^^D100^^20020731^^^TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC|100||180MG|TABLET SA|||G|||0|BC3126631^CHU^Y^L||213220929|0|0|19990821|||
RXD|1|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC|19990821|100|||213220929|0|TAKE 1 TABLET DAILY --GENERIC FOR CALAN SR||||||||||||
RXR|PO||||
ORC|RE||235134037||||||199809221330-0700|||88^Semmelweis^Samuel^^^DR^MD||^^^^^510^ 2673900||||||
RXD|1|00172409660^BACLOFEN 10MG TABS^NDC|199809221415-0700|10|||235134037|5|AS DIRECTED||||||||||||
RXR|PO||||
ORC|RE||235134030||||||199810121030-0700|||99^Lister^Lenora^^^DR^MD||^^^^^510^ 2673700||||||
RXD|1|00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|199810121145-0700|10|||235134030|5|AS DIRECTED||||||||||||
RXR|PO
Note that the following Conformance Statement contains many more input parameters. The user is allowed to populate as many of these as desired.
Conformance Statement
5.9.2 Query using QSC variant / segment pattern response examples
5.9.2.0
5.9.2.1 Dispense information example and Conformance Statement
5.9.2.1.1 Associated dispense information Conformance Statement
Query ID | Z87 |
Query Type | Query |
Query Name | Dispense Information |
Query Trigger | QBP^Z87^QBP_Q11 |
Both | |
Response Trigger | RSP^Z88^RSP_Z88 |
Query Characteristics | Selection criteria are chosen from a Virtual Table. May specify patient, medication, and a date range. |
Query Purpose | To retrieve patient pharmacy dispense history information from the Server. |
Response Characteristics | Sorted by Medication Dispensed unless otherwise specified in SortControl. |
Query Trigger | QBP^Z87^QBP_Q11 |
QBP^Z87^QBP_Q11 | Query Grammar: QBS Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RSP^Z88^RSP_Z88 | Response Grammar: Pharmacy Information Comprehensive | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
{ | --- QUERY_RESPONSE begin |
|
|
|
[ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3.4.2 | DB |
[ PD1 ] | Additional Demographics |
| 3.4.10 | DB |
[ { NTE } ] | Notes and Comments (for PID) |
| 2.15.10 | DB |
[ | --- ALLERGY begin |
|
|
|
{ AL1 } | Allergy Information |
| 3.4.5 | DB |
[ | --- VISIT begin |
|
|
|
PV1 | Patient Visit |
| 3.4.3 | DB |
[ PV2 ] | Patient Visit _ Additional Info |
| 3.4.4 | DB |
] | --- VISIT begin |
|
|
|
] | --- ALLERGY end |
|
|
|
] | --- PATIENT end |
|
|
|
{ | --- COMMON_ORDER begin |
|
|
|
ORC | Common Order |
| 4.5.1 | DB |
[{ | --- TIMING begin |
|
|
|
TQ1 | Timing/Quantity |
| 4.5.4 | DB |
[ { TQ2 } ] | Timing/Quantity Order Sequence |
| 4.5.5 | DB |
}] | --- TIMING end |
|
|
|
[ | --- ORDER_DETAIL begin |
|
|
|
RXO | Pharmacy/Treatment Order |
| 4.8.2 | DB |
[ { NTE } ] | Notes and Comments (for RXO) |
| 2.15.10 | DB |
{ RXR } | Pharmacy/Treatment Route |
| 4.14.2 | DB |
[ | --- COMPONENT begin |
|
|
|
{ RXC } | Pharmacy/Treatment Component |
| 4.14.3 | DB |
[ { NTE } ] | Notes and Comments (for RXC) |
| 2.15.10 | DB |
] | --- COMPONENT end |
|
|
|
] | --- ORDER_DETAIL end |
|
|
|
[ | --- ORDER_ENCODED begin |
|
|
|
RXE | Pharmacy/Treatment Encoded Order |
| 4.8.7 | DB |
[{ | --- TIMING_ENCODED begin |
|
|
|
TQ1 | Timing/Quantity |
| 4.5.4 | DB |
[ { TQ2 } ] | Timing/Quantity Order Sequence |
| 4.5.5 | DB |
}] | --- TIMING_ENCODED end |
|
|
|
{ RXR } | Pharmacy/Treatment Route |
| 4.14.2 | DB |
[ { RXC } ] | Pharmacy/Treatment Component |
| 4.14.3 | DB |
] | --- ORDER_ENCODED end |
|
|
|
RXD | Pharmacy/Treatment Dispense |
| 4.8.10 | DB |
{ RXR } | Pharmacy/Treatment Route |
| 4.14.2 | DB |
[ { RXC } ] | Pharmacy/Treatment Component |
| 4.14.3 | DB |
{ | --- OBSERVATION begin |
|
|
|
[ OBX ] | Results |
| 7.4.2 | DB |
[ { NTE } ] | Notes and Comments (for OBX) |
| 2.15.10 | DB |
} | --- OBSERVATION end |
|
|
|
} | --- COMMON_ORDER end |
|
|
|
} | --- QUERY_RESPONSE end |
|
|
|
DSC | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Z87) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | SelectionCriteria |
|
| 255 | ST | R | Y |
|
|
|
|
|
Input Parameter (Query ID=Z87) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z87^Dispense Information^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
SelectionCriteria |
| ST | A query expression whose operands are derived from the _ColName_ column in the _Input Specification: Virtual Table_ given below. |
ColName (Query ID=Z87) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
PatientName |
|
| 48 | XPN |
|
|
|
| PID.5 |
| PID-5 Patient Name |
OrderControlCode | S |
| 2 | ID |
|
|
| 0119 | ORC.1 |
| ORC-1 Order Control |
MedicationDispensed | S | Y | 100 | CE |
|
|
|
| RXD.2 |
| RXD-2 Dispense/Give Code |
DispenseDate | S |
| 26 | TS |
|
|
|
| RXD.3 |
| RXD-2 Date/Time Dispensed |
QuantityDispensed | L |
| 20 | NM |
|
|
|
| RXD.4 |
| RXD-4 Actual Dispense Amount |
OrderingProvider | S |
| 120 | XCN |
|
|
|
| ORC.12 |
| ORC-12 Ordering Provider |
ColName (Query ID=Z87) | Comp. Name | DT | Description |
---|---|---|---|
PatientList |
| CX | The combination of values for PatientList.ID, and PatientList.AssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientList.IdentifierTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) This PATIENT_MASTER entry will be searched against on the PHARMACY_DISPENSE_TRANSACTION table to retrieve the rows fulfilling the query conditions. |
|
|
| If this field is not valued, all values for this field are considered to be a match. |
|
|
| If one PID.3 is specified, only 1 segment pattern will be returned |
| ID | ID | If this field, PID.3.1, is not valued, all values for this field are considered to be a match. |
| Assigning Authority | HD | If this field, PID.3.4, is not valued, all values for this field are considered to be a match. |
| Identifier type code | IS | If this field, PID.3.5, is not valued, all values for this field are considered to be a match. |
OrderControlCode |
| ID | If this field, ORC.1, is not valued, all values for this field are considered to be a match. |
MedicationDispensed |
| CE | If this field, RXD.2, is not valued, all values for this field are considered to be a match. |
DispenseDate |
| TS | If this field, RXD.3, is not valued, all values for this field are considered to be a match. |
QuantityDispensed |
| NM | If this field, RXD.4, is not valued, all values for this field are considered to be a match. |
OrderingProvider |
| XCN | If this field, ORC.12, is not valued, all values for this field are considered to be a match. |
Field Seq (Query ID=Z87) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
7 | Segment group inclusion |
| 256 | ID | What segment group(s) are to be included. If this field is not valued, all segment groups will be included. |
The following example shows how the same QSC style query can be invoked in a very different way producing very different results.
The user wishes to know all the medications ever dispensed for the patient whose medical record number is _555444222111_ prescribed by Dr Lister (provider number 99). The following message is generated. Note that the same Query has been used, but different input specifications were used.
MSH|^~\&|PCR|Gen Hosp|PIMS||199811201300-0800||QBP^Z87^QBP_Q11|8698|P|2.4||||||||
QPD|Q33^Dispense Information^HL7nnnn|Q005| @PID.3^EQ^55544422211^AND~@ORC.1^EQ^RE^AND~@ORC.12.1^EQ^99
RCP|I|999^RD|
The pharmacy system identifies medical record number _555444222111_ as belonging to Adam Everyman and locates 2 prescription dispenses as prescribed by Dr. Lister. The response is clearly different than the response to the first query.
MSH|^~\&|PIMS|Gen Hosp|PCR||199811201300-0800||RSP^Z88^RSP_Z88|8857|P|2.4||||||||
MSA|AA|8698|
QAK|Q005|OK|Q33^Dispense Information^HL7nnnn|2|
QPD|Q33^Dispense Information^HL7nnnn|Q005| @PID.3^EQ^55544422211^AND~@ORC.1^EQ^RE^AND~@ORC.12.1^EQ^99
PID|||555444222111^^^MPI^MR||Everyman^Adam||19600614|M||C|2101 Webster # 106^^Oakland^CA^94612||^^^^^510^6271111|^^^^^510^6277654|||||343132266|||N|||||||||
ORC|RE||89968665||||||199603121345-0700|||99^Lister^Lenora^^^DR^MD ||^^^^^510^ 2673600||||||
RXE|1^BID^^19980529|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |120||mgm||||||||||||||||||||||||||
RXD|1|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC|199603122000-0700|100|||1331665|3|||||||||||||||||
RXR|PO||||
ORC|RE||235134030||||||199810121030-0700|||99^Lister^Lenora^^^DR^MD||^^^^^510^ 2673700||||||
RXD|1|00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|199810121145-0700|10|||235134030|5|AS DIRECTED||||||||||||
RXR|PO
The user wishes to know all the lab results for the patient whose medical record is 80302641876 and where the result report date/time is between March 21, 1999 and June 24, 1999 and the Lab department is chemistry. This Query Name might be invoked once with a query tag of 123 in the following manner:
MSH|^~\&| PCR|Gen Hosp|LIS.RMS||199907131030-0800||QBP^Z89^QBP_Q11|4460|D|2.4|
QPD|Z89^Lab Results History^HL7nnnn|123|@PID.3.1.1^EQ^80302641876^AND~ @OBR.22^GE^19990321^AND~@OBR.22^LE^19990624^AND~@OBR.24^EQ^_CHEMISTRY_
RCP|I||R|
The _Lab Results History_ query returns laboratory results information in the form of the Segment Pattern Response corresponding to the ORU^R01 _ unsolicited transmission of an observation message. It returns all of the results which meet the criteria defined in the QPD _ Query Parameter Definition Segment of the RSP^R11 _ Segment Pattern Response message.
Conformance Statement
5.9.2.2 Dispense information query showing different instantiation
5.9.2.3 Lab results history example
5.9.2.4 Lab results history Conformance Statement
Query ID | Z89 |
Query Type | Query |
Query Name | Lab Results History |
Query Trigger | QBP^Z89^QBP_Q11 |
Both | |
Response Trigger | RSP^Z90^RSP_Z90 |
Query Characteristics | May specify patient, report time, laboratory department, and LOINC code of result to be returned. |
Query Purpose | To retrieve patient laboratory results information from the Server. |
Response Characteristics |
|
Query Trigger | QBP^Z89^QBP_Q11 |
QBP^Z89^QBP_Q11 | Query Grammar: QBS Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RSP^Z90^RSP_Z90 | Response Grammar: Pharmacy Information Comprehensive | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
{ | --- QUERY_RESPONSE begin |
|
|
|
[ | --- PATIENT begin |
|
|
|
PID | Patient Identification |
| 3.4.2 | DB |
[ PD1 ] | Additional Demographics |
| 3.4.10 | DB |
[ { NK1 } ] | Next of Kin/Associated Parties |
| 3.4.5 | DB |
[ { NTE } ] | Notes and Comments (for PID) |
| 2.15.10 | DB |
[ | --- VISIT begin |
|
|
|
PV1 | Patient Visit |
| 3.4.3 | DB |
[ PV2] ] | Patient Visit _ Additional Info |
| 3.4.4 | DB |
[ | --- VISIT end |
|
|
|
] | --- PATIENT end |
|
|
|
{ | --- COMMON_ORDER begin |
|
|
|
ORC | Common Order |
| 4.5.1 | DB |
[{ | --- TIMING begin |
|
|
|
TQ1 | Timing/Quantity |
| 4.5.4 | DB |
[ { TQ2 } ] | Timing/Quantity Order Sequence |
| 4.5.5 | DB |
}] | --- TIMING end |
|
|
|
OBR | Observations Report ID |
| 4.5.3 | DB |
[ { NTE } ] | Notes and Comments (for ORC/OBR) |
| 2.15.10 | DB |
[ CTD ] | Contact Data |
| 11.6.4 | DB |
{ | --- OBSERVATION begin |
|
|
|
[ OBX ] | Observation/Result |
| 7.4.2 | DB |
[ { NTE } ] | Notes and Comments (for OBX) |
| 2.15.10 | DB |
} | --- OBSERVATION end |
|
|
|
} | --- COMMON_ORDER end |
|
|
|
[{ | --- SPECIMEN begin |
|
|
|
SPM | Specimen |
| 7.4.3 | DB |
[ { OBX } ] | Observation Related to Specimen |
| 7.4.2 | DB |
}] | --- SPECIMEN end |
|
|
|
} | --- QUERY_RESPONSE end |
|
|
|
DSC | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Z89) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | SelectionCriteria |
|
| 255 | ST | R | Y |
|
|
|
|
|
Input Parameter (Query ID=Z89) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z89^Lab Results History^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
SelectionCriteria |
| ST | A query expression whose operands are derived from the _ColName_ column in the _Input Specification: Virtual Table_ given below. |
ColName (Query ID=Z89) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
ResultReportTime.LL |
|
| 26 | TS | O |
|
|
| OBR.22 |
| OBR-22: Results rpt/status chng _ date/time _ lower limit |
ResultReportTime.UL |
|
| 26 | TS | O |
|
|
| OBR.22 |
| OBR-22: Results rpt/status chng _ date/time _ upper limit |
LabDept |
|
| 80 | CE | O | Y |
| 0074 | OBR.24 |
| OBR-24: Diagnostic Serv Sect ID |
LOINCCode |
|
| 80 | CE | O | Y |
|
| OBX.3.4 |
| OBX-3-4: Observation identifier _ alternate identifier |
Input Parameter (Query ID=Z89) | Comp. Name | DT | Description |
---|---|---|---|
PatientList |
| CX | The combination of values for PatientList.ID, and PatientList.AssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientList.IdentifierTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) |
|
|
| If this field is not valued, all values for this field are considered to be a match. |
|
|
| If one PID.3 is specified, only 1 segment pattern will be returned. |
| ID | ID | If this field, PID.3.1, is not valued, all values for this field are considered to be a match. |
| Assigning Authority | HD | If this field, PID.3.4, is not valued, all values for this field are considered to be a match. |
| Identifier type code | IS | If this field, PID.3.5, is not valued, all values for this field are considered to be a match. |
Result Report Time.LL |
| TS | The earliest date and time for which results are to be returned. If this field is not valued, the earliest results that conform to the other query parameters will be returned. |
Result Report Time.UL |
| TS | The latest date and time for which results are to be returned. If this field is not valued, the latest results that conform to the other query parameters will be returned. |
LabDept |
| CE | The section(s) or department(s) of the laboratory reporting the results. As many LabDept values may be specified as desired. If this field is not valued, results that conform to the other query parameters from all sections or departments will be returned. |
LOINCCode |
| CE | The LOINC identifier for the results to be reported. As many LOINCCode values may be specified as desired. If this field is not valued, results that conform to the other query parameters for all LOINC codes will be returned. |
Field Seq (Query ID=Z89) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
7 | Segment group inclusion |
| 256 | ID | What segment group(s) are to be included. If this field is not valued, all segment groups will be included. |
If a LOINC code is used as one of the operands of the input specification expression, all of the other OBX segments which are part of the same OBR as the selected OBX will be returned along with the selected OBX. In other words, if an OBX segment that is part of a panel is selected by the query, the entire panel will be returned.
The same Query Name might be invoked with a different query tag (456) as follows:
The user wishes to know all the lab results reported having a LOINC code of 6777-7 between March 21, 1999 and March 23, 1999.
MSH|^~\&|PCR|GenHosp|LIS||199907131040-0800||QBP^Z89^QBP_Z89|4495|D|2.4|
QPD |Z89^LabResultsHistory^HL7nnnn||@OBX.3.4^EQ^6777-7^AND~@OBR.22^GE^19990321^AND~@OBR.22^LE^19990323
RCP|I||R|
The second instance of the _Lab Results for Specified Criteria_ query would clearly return quite different results than the first even though both are invocations of the same query.
The user wishes to know the identity of the patient whose medical record number is _555444222111_.
MSH|^~\&|PCR|GenHosp|MPI||199811201400-0800||QBP^Z91^QBP_Q13|8699|P|2.4||||||||
QPD|Z91^WhoAmI^HL7nnnn|Q0009|555444222111^^^MPI^MR
RCP|I|999^RD|
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^Z92^RTB_K13|8699|P|2.4||||||||
MSA|AA|8699|
QAK|Q0009|OK|Z91^WhoAmI^HL7nnnn|1^1|
QPD|Z91^WhoAmI^HL7nnnn|Q0009|555444222111^^MPI^MR
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||
Conformance Statement
Query ID | Z91 |
Query Type | Query |
Query Name | Who Am I |
Query Trigger | QBP^Z91^QBP_Q13 |
Both | |
Response Trigger | RTB^Z92^RTB_K13 |
Query Characteristics |
|
Query Purpose | Find the identity of the patient for specified medical record number(s) |
Response Characteristics |
|
Query Trigger | QBP^Z91^QBP_Q13 |
QBP^Z91^QBP_Q13 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ RDF ] | Table Row Definition Segment |
| 5.5.7 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RTB^Z94^RTB_K13 | Response Grammar: Who Am I | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ | --- ROW_DEFINITION begin |
|
|
|
RDF | Table Row Definition Segment |
| 5.5.7 | DB |
[ { RDT } ] | Table Row Data Segment |
| 5.5.8 | DB |
] | --- ROW_DEFINITION end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Z91) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
Input Parameter (Query ID=Z91) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z91^Who Am I^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
PatientList |
| CX | The combination of values for PatientList.ID, and PatientList.AssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientList.IdentifierTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) If this field is not valued, all values for this field are considered to be a match. If one PID.3 is specified, only 1 segment pattern will be returned. |
| ID | ID | If this field, PID.3.1, is not valued, all values for this field are considered to be a match. |
| Assigning Authority | HD | If this field, PID.3.4, is not valued, all values for this field are considered to be a match. |
| Identifier type code | IS | If this field, PID.3.5, is not valued, all values for this field are considered to be a match. |
Field Seq (Query ID=Z91) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
6 | Sort-by Field |
| 256 | SRT |
|
|
| Sort-by Field |
| ST | Segment field name of an output column by which the response may be sorted. Must contain a Y in the Sort column of the output specification table. |
|
| Sequencing |
| ID | As specified in HL7 Table 0397- Sequencing. Default is Ascending. |
ColName (Query ID=Z91) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
PatientName |
|
| 48 | XPN |
|
|
|
| PID.5 |
| PID-5 Patient Name |
Mother_sMaidenName |
|
| 48 | XPN |
|
|
|
| PID.6 |
| PID-6 Mother_s Maiden Name |
DOB |
|
| 26 | TS |
|
|
|
| PID.7 |
| PID-7 Date/Time of Birth |
Sex |
|
| 1 | IS |
|
|
|
| PID.8 |
| PID-8 Sex |
Race |
|
| 80 | CE |
|
|
|
| PID.10 |
| PID-10 Race |
The user wishes to know all the medications dispensed for the patient whose medical record number is _555444222111_ for the period beginning 5/31/98 and ending 5/31/99. The following QBP message is generated.
MSH|^~\&|PCR|Gen Hosp|PIMS||199811201400-0800||QBP^Q42^QBP_Q13|8699|P|2.4||||||||
QPD|Q42^Tabular Dispense History^HL7nnn|Q0010|555444222111^^^MPI^MR| |19980531|19990531|
RCP|I|999^RD|
RDF|3|PatientList^ST^20~PatientName^XPN^48~MedicationDispensed^ST^40~RXD.3^TS^26
The pharmacy system identifies medical record number _555444222111_ as belonging to Adam Everyman and locates 4 prescription dispenses meeting the criteria and returns the following RTB message:
MSH|^~\&|PIMS|Gen Hosp|PCR||199811201400-0800||RTB^K42^RTB_K13|8858|P|2.4||||||||
MSA|AA|8699|
QAK|Q010|OK|Q42^Tabular Dispense History^HL7nnn|4
QPD|Q42^Tabular Dispense History^HL7nnn|Q0010|555444222111^^^MPI^MR||19980531|19990531|
RDF|7|PatientId^CX^20~PatientName^XPN^48~OrderControlCode^ID^2~ MedicationDispensed^CE^100~DispenseDate^TS^26~QuantityDispensed^NM^20~ OrderingProvider^XCN^120
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|525440345^Verapamil Hydrochloride 120 mg TAB^NDC |199805291115-0700|100|77^Hippocrates^Harold^H^III^DR^MD
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |19980821-0700|100|77^Hippocrates^Harold^H^III^DR^MD
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|00172409660^BACLOFEN 10MG TABS^NDC |199809221415-0700|10|88^Semmelweis^Samuel^^^DR^MD
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|199810121145-0700|10|99^Lister^Lenora^^^DR^MD
Conformance Statement
5.9.3.2 Pharmacy example:
5.9.3.2.1 QBP/RTB dispense history Conformance Statement
Query ID | Z93 |
Query Type | Query |
Query Name | Tabular Dispense History |
Query Trigger | QBP^Z93^QBP_Q13 |
Both | |
Response Trigger | RTB^Z94^RTB_K13 |
Query Characteristics | Returns response sorted by Date Dispensed unless otherwise specified. |
Query Purpose | Find medications dispensed between specified date range for specified medical record numbers. |
Response Characteristics |
|
Query Trigger | QBP^Z93^QBP_Q13 |
QBP^Z93^QBP_Q13 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ RDF ] | Table Row Definition Segment |
| 5.5.7 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RTB^Z94^RTB_K13 | Response Grammar: Who Am I | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ | --- ROW_DEFINITION begin |
|
|
|
RDF | Table Row Definition Segment |
| 5.5.7 | DB |
[ { RDT } ] | Table Row Data Segment |
| 5.5.8 | DB |
] | --- ROW_DEFINITION end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Z93) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
4 | MedicationDispensed | S | Y | 100 | CE | O |
| = |
| RXD.2 |
| RXD-2: Dispense/Give Code |
5 | DispenseDate.LL | S | Y | 26 | TS | O |
| > = |
| RXD.3 |
| RXD-3: Date/Time Dispensed |
6 | DispenseDate.UL | S | Y | 26 | TS | O |
| < = |
| RXD.3 |
| RXD-3: Date/Time Dispensed |
QPD Input Parameter Field Description and Commentary
Input Parameter (Query ID=Z93) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z93^Tabular Dispense History^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
PatientList |
| CX | The combination of values for PatientList.ID, and PatientList.AssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientList.IdentifierTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) This PATIENT_MASTER entry will be searched against on the PHARMACY_DISPENSE_TRANSACTION table to retrieve the rows fulfilling the query conditions. |
|
|
| If this field is not valued, all values for this field are considered to be a match. |
|
|
| If one PID.3 is specified, only 1 segment pattern will be returned. |
| ID | ID | If this field, PID.3.1, is not valued, all values for this field are considered to be a match. |
| Assigning Authority | HD | If this field, PID.3.4, is not valued, all values for this field are considered to be a match. |
| Identifier type code | IS | If this field, PID.3.5, is not valued, all values for this field are considered to be a match. |
MedicationDispensed |
| CE | If this field is not valued, all values for this field are considered to be a match. |
DispenseDate.LL |
| TS | This is the earliest value to be returned for Date/Time Dispensed. If this field is not valued, all values for this field are considered to be a match. |
DispenseDate.UL |
| TS | This is the latest value to be returned for Date/Time Dispensed. If this field is not valued, all values for this field are considered to be a match. |
Field Seq (Query ID=Z93) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
6 | Sort-by Field |
| 256 | SRT |
|
|
| Sort-by Field |
| ST | Segment field name of an output column by which the response may be sorted. Must contain a Y in the Sort column of the output specification table. |
|
| Sequencing |
| ID | As specified in HL7 Table 0397- Sequencing. Default is Ascending. |
ColName (Query ID=Z93) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
PatientName |
|
| 48 | XPN |
|
|
|
| PID.5 |
| PID-5 Patient Name |
MedicationDispensed | S | Y | 100 | CE | O |
| = |
| RXD.2 |
| RXD-2 Dispense/Give Code |
DispenseDate.LL | S | Y | 26 | TS | O |
| >= |
| RXD.3 |
| RXD-3 Date/Time Dispensed |
DispenseDate.UL | S | Y | 26 | TS | O |
| <= |
| RXD.3 |
| RXD-3 Date/Time Dispensed |
The user wishes to know all the medications dispensed for the patient whose medical record number is _555444222111_ for the period beginning 5/31/98 and ending 5/31/99. The following message is generated.
MSH|^~\&|PCR|Gen Hosp|PIMS||199811201400-0800||QBP^Z95^QBP_Q13|8699|P|2.4||||||||
QPD|Z95^Dispense Information^HL7nnnn|Q504 |PID.3^EQ^55544422211^AND~RXD.3^GE^19980531^AND~RXD.3^LE^19990531
RCP|I|999^RD|
RDF|3|PatientList^ST^20~PatientName^XPN^48~OrderControlCode^ID^2~OrderingProvider^XCN^120~MedicationDispensed^ST^40~DispenseDate^TS^26~QuantityDispensed^NM^20|
The pharmacy system identifies medical record number _555444222111_ as belonging to Adam Everyman and locates 4 prescription dispenses meeting the criteria and returns the following RTB message:
MSH|^~\&|PIMS|Gen Hosp|PCR||199811201400-0800||RTB^Z96^RTB_K13|8858|P|2.4||||||||
MSA|AA|8699|
QAK|Q001|OK|Z95^Dispense Information^HL7nnnn|4
QPD|Z95^Dispense Information^HL7nnnn|Q504 |PID.3^EQ^55544422211^AND~RXD.3^GE^19980531^AND~RXD.3^LE^19990531
RDF|3|PatientList^ST^20~PatientName^XPN^48~OrderControlCode^ID^2~OrderingProvider^XCN^120~MedicationDispensed^ST^40~DispenseDate^TS^26~QuantityDispensed^NM^20|
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|77^Hippocrates^Harold^H^III^DR^MD |525440345^Verapamil Hydrochloride 120 mg TAB^NDC |199805291115-0700|100
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|77^Hippocrates^Harold^H^III^DR^MD |00182196901^VERAPAMIL HCL ER TAB 180MG ER^NDC |19980821-0700|100
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|88^Semmelweis^Samuel^^^DR^MD |00172409660^BACLOFEN 10MG TABS^NDC |199809221415-0700|10
RDT|555444222111^^^MPI^MR|Everyman^Adam|RE|99^Lister^Lenora^^^DR^MD |00054384163^THEOPHYLLINE 80MG/15ML SOLN^NDC|199810121145-0700|10
Note that this Conformance Statement includes no separate Output Description and Commentary. In the QBP/RTB combination using the QSC variant, the selection criteria in QPD-3-user parameters and the desired return data in RDF-2-column description are constructed from the same Virtual Table, which appears in the Input Specification.
Conformance Statement
5.9.4 Query using QSC variant / tabular response (RTB)
5.9.4.0
5.9.4.1 Pharmacy example
5.9.4.1.1 QBP/RTB dispense history Conformance Statement using QSC variant
Query ID | Z95 |
Query Type | Query |
Query Name | Tabular Dispense History |
Query Trigger | QBP^Z95^QBP_Q13 |
Both | |
Response Trigger | RTB^Z96^RTB_K13 |
Query Characteristics | Selection criteria are chosen from a Virtual Table. May specify patient, medication, and a date range. |
Query Purpose | To retrieve patient pharmacy dispense history information from the Server. |
Response Characteristics | Columns from the Virtual Table listed in the Input/Output Specification are specified for output in the RDF segment. |
Query Trigger | QBP^Z95^QBP_Q13 |
QBP^Z95^QBP_Q13 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ RDF ] | Table Row Definition Segment |
| 5.5.7 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RTB^Z96^RTB_K13 | Response Grammar: Who Am I | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ | --- ROW_DEFINITION begin |
|
|
|
RDF | Table Row Definition Segment |
| 5.5.7 | DB |
[ { RDT } ] | Table Row Data Segment |
| 5.5.8 | DB |
] | --- ROW_DEFINITION end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Z95) | Field Description |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | SelectionCriteria |
|
| 255 | ST | R | Y |
|
|
|
|
|
Input Parameter (Query ID=Z95) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z95^Tabular Dispense History^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
SelectionCriteria |
| ST | A query expression whose operands are derived from the _ColName_ column in the _Input/Output Specification: Virtual Table_ given below. |
ColName (Query ID=Z95) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
PatientName |
|
| 48 | XPN |
|
|
|
| PID.5 |
| PID-5 Patient Name |
OrderControlCode | S |
| 2 | ID |
|
|
| 0119 | ORC.1 |
| ORC-1 Order Control |
MedicationDispensed | S | Y | 100 | CE |
|
|
|
| RXD.2 |
| RXD-2 Dispense/Give Code |
DispenseDate | S |
| 26 | TS |
|
|
|
| RXD.3 |
| RXD-2 Date/Time Dispensed |
QuantityDispensed | L |
| 20 | NM |
|
|
|
| RXD.4 |
| RXD-4 Actual Dispense Amount |
OrderingProvider | S |
| 120 | XCN |
|
|
|
| ORC.12 |
| ORC-12 Ordering Provider |
ColName (Query ID=Z95) | Comp. Name | DT | Description |
---|---|---|---|
PatientList |
| CX | The combination of values for PatientList.ID, and PatientList.AssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientList.IdentifierTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) This PATIENT_MASTER entry will be searched against on the PHARMACY_DISPENSE_TRANSACTION table to retrieve the rows fulfilling the query conditions. |
|
|
| If this field is not valued, all values for this field are considered to be a match. |
|
|
| If one PID.3 is specified, only 1 segment pattern will be returned. |
| ID | ID | If this field, PID.3.1, is not valued, all values for this field are considered to be a match. |
| Assigning Authority | HD | If this field, PID.3.4, is not valued, all values for this field are considered to be a match. |
| Identifier type code | IS | If this field, PID.3.5, is not valued, all values for this field are considered to be a match. |
PatientName |
| XPN | If this field, PID.5, is not valued, all values for this field are considered to be a match. |
OrderControlCode |
| ID | If this field, ORC.1, is not valued, all values for this field are considered to be a match. |
MedicationDispensed |
| CE | If this field, RXD.2, is not valued, all values for this field are considered to be a match. |
DispenseDate |
| TS | If this field, RXD.3, is not valued, all values for this field are considered to be a match. |
QuantityDispensed |
| NM | If this field, RXD.4, is not valued, all values for this field are considered to be a match. |
OrderingProvider |
| XCN | If this field, ORC.12, is not valued, all values for this field are considered to be a match. |
Field Seq (Query ID=Z95) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
6 | Sort-by Field |
| 256 | SRT |
|
|
| Sort-by Field |
| ST | Segment field name of an output column by which the response may be sorted. Must contain a Y in the Sort column of the output specification table. |
|
| Sequencing |
| ID | As specified in HL7 Table 0397- Sequencing. Default is Ascending. |
The user wishes to know all the medications dispensed for the patient whose medical record number is _555444222111_ for the period beginning 5/31/98 and ending 5/31/99. The following QBP message is generated.
MSH|^~\&|PCR|Gen Hosp|PIMS||199909171400-0800||QBP^Z97^QBP_Q15|8699|P|2.4||||||||
QPD|Z97^DispenseHistoryDisplay^HL7nnnn|Q005|555444222111^^^MPI^MR||19980531|19990531|
RCP|I|999^RD|
The pharmacy system identifies medical record number _555444222111_ as belonging to Adam Everyman and locates 4 prescription dispenses meeting the criteria and returns the following RDY message:
MSH|^~\&|PIMS|Gen Hosp|PCR||199909171401-0800||RDY^Z98^RDY_K15|8858|P|2.3||||||||
MSA|AA|8699|
QAK|Q005|OK|Z97^DispenseHistoryDisplay|4
QPD|Z97^DispenseHistoryDisplay^HL7nnnn|Q005|555444222111^^^MPI^MR||19980531|19990531|
DSP|| GENERAL HOSPITAL _ PHARMACY DEPARTMENT DATE:09-17-99
DSP|| DISPENSE HISTORY REPORT PAGE 1
DSP||MRN Patient Name MEDICATION DISPENSED DISP-DATE
DSP||555444222111 Everyman,Adam VERAPAMIL HCL 120 mg TAB 05/29/1998
DSP||555444222111 Everyman,Adam VERAPAMIL HCL ER TAB 180MG 08/21/1998
DSP||555444222111 Everyman,Adam BACLOFEN 10MG TABS 09/22/1998
DSP||555444222111 Everyman,Adam THEOPHYLLINE 80MG/15ML SOL 10/12/1998
DSP|| << END OF REPORT >>
Note that this Conformance Statement includes no separate Output Description and Commentary. In conformance statements that specify an RDY response message, the display format follows the response grammar.
Conformance Statement
5.9.5 Query by parameter (QBP) / display response (RDY)
5.9.5.0
5.9.5.1 Dispense history display Conformance Statement
Query ID | Z97 |
Query Type | Query |
Query Name | Dispense History |
Query Trigger | QBP^Z97^QBP_Q15 |
Both | |
Response Trigger | RDY^Z98^RDY_K15 |
Query Characteristics | May specify patient, medication, a date range, and how the response is to be sorted. |
Query Purpose | To retrieve patient pharmacy dispense history information from the Server. |
Response Characteristics | Returns data formatted for screen display. Data are sorted by Medication Dispensed unless otherwise specified in SortControl. |
Query Trigger | QBP^Z97^QBP_Q15 |
QBP^Z97^QBP_Q15 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RDY^Z98^RDY_K15 | Response Grammar: Dispense History | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ { DSP } ] | Display Data |
| 5.5.1 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
The data will display as follows: (Query ID=Z97) |
---|
DSP|| GENERAL HOSPITAL _ PHARMACY DEPARTMENT DATE:mm-dd-yy |
DSP|| DISPENSE HISTORY REPORT PAGE n |
DSP||MRN Patient Name MEDICATION DISPENSED DISP-DATE |
DSP||XXXXX XXXXXx, XXXXX XXXXXXXXXXXXXXXX mm/dd/ccyy |
_ |
DSP|| << END OF REPORT >> |
Field Seq (Query ID=Z97) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
4 | MedicationDispensed | S | Y | 100 | CE | O |
| = |
| RXD.2 |
| RXD-2: Dispense/Give Code |
5 | DispenseDate.LL | S | Y | 26 | TS | O |
| > = |
| RXD.3 |
| RXD-3: Date/Time Dispensed |
6 | DispenseDate.UL | S | Y | 26 | TS | O |
| < = |
| RXD.3 |
| RXD-3: Date/Time Dispensed |
Input Parameter (Query ID=Z97) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z97^Dispense History^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
PatientList |
| CX | The combination of values for PatientList.ID, and PatientList.AssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientList.IdentifierTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) This PATIENT_MASTER entry will be searched against on the PHARMACY_DISPENSE_TRANSACTION table to retrieve the rows fulfilling the query conditions. |
|
|
| If this field is not valued, all values for this field are considered to be a match. |
|
|
| If one PID.3 is specified, only 1 segment pattern will be returned. |
| ID | ID | If this field, PID.3.1, is not valued, all values for this field are considered to be a match. |
| Assigning Authority | HD | If this field, PID.3.4, is not valued, all values for this field are considered to be a match. |
| Identifier type code | IS | If this field, PID.3.5, is not valued, all values for this field are considered to be a match. |
MedicationDispensed |
| CE | If this field is not valued, all values for this field are considered to be a match. |
DispenseDate.LL |
| TS | This is the earliest value to be returned for Date/Time Dispensed. If this field is not valued, all values for this field are considered to be a match. |
DispenseDate.UL |
| TS | This is the latest value to be returned for Date/Time Dispensed. If this field is not valued, all values for this field are considered to be a match. |
Field Seq (Query ID=Z97) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
The user wishes to know all the medications ever dispensed for the patient whose medical record number is _555444222111_ prescribed by Dr Lister (provider number 99). The following message is generated. (Note the similarity between the QPD segment here and that used in the query in Section 5.8.4.)
MSH|^~\&|PCR|Gen Hosp|PIMS||199811201300-0800||QBP^Z79^QBP_Q15|8698|P|2.4||||||||
QPD|Z79^Dispense Information^HL7nnnn|Q503 |PID.3^EQ^55544422211^AND~ORC.1^EQ^RE^AND~ORC.12.1^EQ^99
RCP|I|999^RD|
The pharmacy system identifies medical record number _555444222111_ as belonging to Adam Everyman and locates 2 prescription dispenses as prescribed by Dr. Lister. The response is clearly different than the response to the first query.
MSH|^~\&|PIMS|Gen Hosp|PCR||199811201300-0800||RDY^Z80^RDY_K15|8857|P|2.3||||||||
MSA|AA|8698|
QAK|Q003|OK|Z79^Dispense Information^HL7nnnn|2
QPD|Z79^Dispense Information^HL7nnnn|Q503 |@PID.3^EQ^55544422211^AND~ORC.1^EQ^RE^AND~@RXD.3^GE^199711200000-0800^AND~@RXD.3^LE^199811200000-0800
DSP|| GENERAL HOSPITAL _ PHARMACY DEPARTMENT DATE:09-17-99
DSP|| DISPENSE HISTORY REPORT PAGE 1
DSP||MRN Patient Name MEDICATION DISPENSED DISP-DATE
DSP||555444222111 Everyman,Adam VERAPAMIL HCL 120 mg TAB 05/29/1998
DSP||555444222111 Everyman,Adam THEOPHYLLINE 80MG/15ML SOL 10/12/1998
DSP|| << END OF REPORT >>
Note that this Conformance Statement includes no separate Output Description and Commentary. In conformance statements that specify an RDY response message, the display format follows the response grammar.
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
Query ID | Z79 |
Query Type | Query |
Query Name | Dispense Information |
Query Trigger | QBP^Z79^QBP_Q15 |
Both | |
Response Trigger | RDY^Z80^RSP_K11 |
Query Characteristics | Selection criteria are chosen from a Virtual Table. May specify patient, order control code, medication, a date range, quantity dispensed, and ordering provider. |
Query Purpose | To retrieve patient pharmacy dispense history information from the Server. |
Response Characteristics | Returns data formatted for screen display. Data are sorted by Medication Dispensed unless otherwise specified in SortControl. |
Query Trigger | QBP^Z79^QBP_Q15 |
QBP^Z79^QBP_Q15 | Query Grammar: QBS Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RDY^Z80^RSP_K11 | Response Grammar: Dispense History | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ { DSP } ] | Display Data |
| 5.5.1 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
The data will display as follows: (Query ID=Z79) |
---|
DSP|| GENERAL HOSPITAL _ PHARMACY DEPARTMENT DATE:mm-dd-yy |
DSP|| DISPENSE HISTORY REPORT PAGE n |
DSP||MRN Patient Name MEDICATION DISPENSED DISP-DATE |
DSP||XXXXX XXXXXx, XXXXX XXXXXXXXXXXXXXXX mm/dd/ccyy |
_ |
DSP|| << END OF REPORT >> |
Field Seq (Query ID=Z79) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | ElementName |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
|
|
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
|
|
3 | SelectionCriteria |
|
| 255 | ST | R | Y |
|
|
|
|
|
Input Parameter (Query ID=Z79) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z79^Dispense Information^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
SelectionCriteria |
| ST | A query expression whose operands are derived from the _ColName_ column in the _Input/Output Specification: Virtual Table_ given below. |
ColName (Query ID=Z79) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | ElementName |
---|---|---|---|---|---|---|---|---|---|---|---|
PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3: Patient Identifier List |
OrderControlCode | S |
| 2 | ID |
|
|
| 0119 | ORC.1 |
| ORC-1 Order Control |
MedicationDispensed | S | Y | 100 | CE |
|
|
|
| RXD.2 |
| RXD-2 Dispense/Give Code |
DispenseDate | S |
| 26 | TS |
|
|
|
| RXD.3 |
| RXD-2 Date/Time Dispensed |
QuantityDispensed | L |
| 20 | NM |
|
|
|
| RXD.4 |
| RXD-4 Actual Dispense Amount |
OrderingProvider | S |
| 120 | XCN |
|
|
|
| ORC.12 |
| ORC-12 Ordering Provider |
ColName (Query ID=Z79) | Comp. Name | DT | Description |
---|---|---|---|
PatientList |
| CX | The combination of values for PatientList.ID, and PatientList.AssigningAuthority, are intended to identify a unique entry on the PATIENT_MASTER table. The PatientList.IdentifierTypeCode is useful for further filtering or to supply uniqueness in the event that the assigning authority may have more than one coding system. (The PATIENT_MASTER table contains a constraint that prevents multiple patients from being identified by the same combination of field values.) This PATIENT_MASTER entry will be searched against on the PHARMACY_DISPENSE_TRANSACTION table to retrieve the rows fulfilling the query conditions. |
|
|
| If this field is not valued, all values for this field are considered to be a match. |
|
|
| If one PID.3 is specified, only 1 segment pattern will be returned. |
| ID | ID | If this field, PID.3.1, is not valued, all values for this field are considered to be a match. |
| Assigning Authority | HD | If this field, PID.3.4, is not valued, all values for this field are considered to be a match. |
| Identifier type code | IS | If this field, PID.3.5, is not valued, all values for this field are considered to be a match. |
OrderControlCode |
| ID | If this field, ORC.1, is not valued, all values for this field are considered to be a match. |
MedicationDispensed |
| CE | If this field, RXD.2, is not valued, all values for this field are considered to be a match. |
DispenseDate |
| TS | If this field, RXD.3, is not valued, all values for this field are considered to be a match. |
QuantityDispensed |
| NM | If this field, RXD.4, is not valued, all values for this field are considered to be a match. |
OrderingProvider |
| XCN | If this field, ORC.12, is not valued, all values for this field are considered to be a match. |
Field Seq (Query ID=Z79) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
6 | Sort-by Field |
| 256 | SRT |
|
|
| Sort-by Field |
| ST | Segment field name of an output column by which the response may be sorted. Must contain a Y in the Sort column of the output specification table. |
|
| Sequencing |
| ID | As specified in HL7 Table 0397- Sequencing. Default is Ascending. |
This section demonstrates how to use a different syntax for passing query parameters to the query server. This syntactic variant is called _query by example_ because, instead of passing query parameter as fields of the QBP segment, they are passed as fields of existing HL7 segments. Nevertheless, the query conformance statement will clearly specify which fields of the HL7 segment can carry useful values. Note that both the QBP syntax and the _query by example_ syntax have the same expressive power. Also note that when segments are used in the _query by example_ variant, the required/optional characteristics of each field should be defined in the conformance statement, and that field optionality in queries may be different from the usual optionality of the segment when used in other HL7 messages.
This sample shows how the _query by example_ might be used to find a list of candidates matching a set of demographics. Because demographic data is naturally carried by the existing PID segment, the message designer may, for stylistic or practical reasons, decide to pass the demographic parameters such as patient name or patient age in a PID segment.
The Client wishes to see a list of patients whose demographics are as follows:
Last Name: Thomas First Name: Gregory Sex: Male DOB: 12/11/48
The Client wishes to do this using the peekaboo algorithm with an 80% confidence level.
MSH|^~\&|PCR|GenHosp|MPI||199811201400-0800||QBP^Z77^QBP_Q13|8699|P|2.4||||||||
QPD|Z77^find_candidates^HL7nnnn|Q0001|peekaboo|80|
PID|||||Thomas&Gregory||19481211|M
RCP|I|25^RD|
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^Z78^RTB_R13|8699|P|2.4||||||||
MSA|AA|8699|
QAK|
QPD|Z77^find_candidates^HL7nnnn|Q0001|peekaboo|80|
RDF|PatientList^CX^20~PatientName^XPN^48~Mother_sMaidenName^XPN^48~DOB^TS^26~Sex^IS^1~Race^CE^80|
RDT|555444222111^^^MPI&KP.NCA&L^MR|Thomas^Gregory||19481211|M||
Conformance Statement
5.9.7 Query by example (QBP) / tabular response (RTB)
5.9.7.0
5.9.7.1 MPI Conformance Statement using QBE variant
Query ID | Z77 |
Query Type | Query |
Query Name | Tabular Patient List |
Query Trigger | QBP^Z77^QBP_Q13 |
Both | |
Response Trigger | RTB^Z78^RTB_K13 |
Query Characteristics | Query By Example: passes algorithm data via QBP segment and patient match information via PID segment. |
Query Purpose | To find patient records that closely (as specified by the Client) match a set of input criteria using a specified algorithm. |
Response Characteristics | Response returns requested columns from the Virtual Table. If no columns were requested, all columns are returned. |
Query Trigger | QBP^Z77^QBP_Q13 |
QBP^Z77^QBP_Q13 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
PID | Patient Identification Segment |
| 3.4.2 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ RDF ] | Table Row Definition Segment |
| 5.5.7 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RTB^Z78^RTB_K13 | Response Grammar: Who Am I | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ | --- ROW_DEFINITION begin |
|
|
|
RDF | Table Row Definition Segment |
| 5.5.7 | DB |
[ { RDT } ] | Table Row Data Segment |
| 5.5.8 | DB |
] | --- ROW_DEFINITION end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Z77) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
| Message Query Name |
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
| Query Tag |
3 | Algorithm |
|
| 48 | ST |
|
|
|
|
|
| Algorithm |
4 | ConfidenceLevel |
|
| 8 | NM |
|
|
|
|
|
| Confidence Level |
Input Parameter (Query ID=Z77) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z77^Tabular Patient List^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
Algorithm |
| ST | The name of the search algorithm that is used to look up the parameter values specified in the PID segment. |
ConfidenceLevel |
| NM | The degree of accuracy that the search algorithm must achieve in order to score a _hit._ |
Segment Field Name (Query ID=Z77) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Service Identifier Code | Element Name |
PID.5 | PatientName | S |
| 48 | XPN |
|
|
|
|
| PID-5-Patient Name |
PID.7 | DOB | S |
| 26 | TS |
|
|
|
|
| PID-7-Date/time of Birth |
PID.8 | Sex | S |
| 1 | IS |
|
|
|
|
| PID-8-Sex |
Input Parameter (Query ID=Z77) | Comp. Name | DT | Description |
PatientName |
| XPN | Name of the patient. May be specified in full or in part. |
DOB |
| TS | Date and time of the patient_s birth. Year, month, and day must be specified; time is optional. |
Sex |
| IS | Administrative gender of the patient. |
Field Seq (Query ID=Z77) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
6 | Sort-by Field |
| 256 | SRT |
|
|
| Sort-by Field |
| ST | Segment field name of an output column by which the response may be sorted. Must contain a Y in the Sort column of the output specification table. |
|
| Sequencing |
| ID | As specified in HL7 Table 0397- Sequencing. Default is Ascending. |
ColName (Query ID=Z77) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3 Patient Identifier List |
PatientName |
|
| 48 | XPN |
|
|
|
| PID.5 |
| PID-5 Patient Name |
MothersMaidenName |
|
| 48 | XPN |
|
|
|
| PID.6 |
| PID-6 Mother_s Maiden Name |
DOB |
|
| 26 | TS |
|
|
|
| PID.7 |
| PID-7 Date/Time of Birth |
Sex |
|
| 1 | IS |
|
|
|
| PID.8 |
| PID-8 Sex |
Race |
|
| 80 | CE |
|
|
|
| PID.10 |
| PID-10 Race |
The same query as described above could be sent as a pure Query By Parameter query, without the _query by example_ variant, as follows.
Notice that the query uses only a single QPD segment to carry all the parameters. The response to the query is the same as for the _query by example_ variant above.
Example: the Client wishes to do this using the peekaboo algorithm with an 80% confidence level.
MSH|^~\&|PCR|GenHosp|MPI||199811201400-0800||QBP^Z75^QBP_Q13|8699|P|2.4||||||||
QPD|Z75^find_candidates^HL7nnnn|Q0001|peekaboo|80|Thomas^Gregory|19481211|M
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^Z76^RTB_R13|8699|P|2.4||||||||
MSA|AA|8699|
QAK|
QPD|Z75^find_candidates^HL7nnnn|Q0001|peekaboo|80|Thomas^Gregory|19481211|M
RDF|PatientList^CX^20~PatientName^XPN^48~Mother_sMaidenName^XPN^48~DOB^TS^26~Sex^IS^1~Race^CE^80|
RDT|555444222111^^^MPI&KP.NCA&L^MR| Thomas^Gregory|19481211|M||
Conformance Statement
Query ID | Z75 |
Query Type | Query |
Query Name | Tabular Patient List |
Query Trigger | QBP^Z75^QBP_Q13 |
Both | |
Response Trigger | RTB^Z76^RTB_K13 |
Query Characteristics | Patient identifier and matching algorithm requirements are passed via the input parameters. Output columns are chosen from a Virtual Table. |
Query Purpose | To find patient records that closely (as specified by the Client) match a set of input criteria using a specified algorithm. |
Response Characteristics | Response returns requested columns from the Virtual Table. If no columns were requested, all columns are returned. |
Query Trigger | QBP^Z75^QBP_Q13 |
QBP^Z75^QBP_Q13 | Query Grammar: QBP Message | Status | Section Reference | DB Ref. |
---|---|---|---|---|
MSH | Message Header Segment |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
RCP | Response Control Parameter |
| 5.5.6 | DB |
[ RDF ] | Table Row Definition Segment |
| 5.5.7 | DB |
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
RTB^Z76^RTB_K13 | Response Grammar: Who Am I | Status | Sec Ref | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2.15.9 | DB |
[ { SFT } ] | Software Segment |
| 2.15.12 | DB |
MSA | Message Acknowledgement |
| 2.15.8 | DB |
[ ERR ] | Error |
| 2.15.5 | DB |
QAK | Query Acknowledgement |
| 5.5.2 | DB |
QPD | Query Parameter Definition |
| 5.5.4 | DB |
[ | --- ROW_DEFINITION begin |
|
|
|
RDF | Table Row Definition Segment |
| 5.5.7 | DB |
[ { RDT } ] | Table Row Data Segment |
| 5.5.8 | DB |
] | --- ROW_DEFINITION end |
|
|
|
[ DSC ] | Continuation Pointer |
| 2.15.4 | DB |
Field Seq (Query ID=Z75) | Name |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | MessageQueryName |
|
| 60 | CE | R |
|
|
|
|
| Message Query Name |
2 | QueryTag |
|
| 32 | ST | R |
|
|
|
|
| Query Tag |
3 | Algorithm |
|
| 48 | ST |
|
|
|
|
|
| Algorithm |
4 | ConfidenceLevel |
|
| 8 | NM |
|
|
|
|
|
| Confidence Level |
5 | PatientName | S |
| 48 | XPN |
|
|
|
| PID.5 |
| PID-5-Patient Name |
6 | DOB | S |
| 26 | TS |
|
|
|
| PID.7 |
| PID-7-Date/Time of Birth |
7 | Sex | S |
| 1 | IS |
|
|
|
| PID.8 |
| PID-8-Sex |
Input Parameter (Query ID=Z75) | Comp. Name | DT | Description |
---|---|---|---|
MessageQueryName |
| CE | Must be valued Z75^Tabular Patient List^HL7nnnn. |
QueryTag |
| ST | Unique to each query message instance. |
Algorithm |
| ST | The name of the search algorithm that is used to look up the parameter values specified in the PID segment. |
ConfidenceLevel |
| NM | The degree of accuracy that the search algorithm must achieve in order to score a _hit._ |
PatientName |
| XPN | Name of the patient. May be specified in full or in part. |
DOB |
| TS | Date and time of the patient_s birth. Year, month, and day must be specified; time is optional. |
Sex |
| IS | Administrative gender of the patient. |
Field Seq (Query ID=Z75) | Name | Component Name | LEN | DT | Description |
---|---|---|---|---|---|
1 | Query Priority |
| 1 | ID | (D)eferred or (I)mmediate. Default is I. |
2 | Quantity Limited Request |
| 10 | CQ |
|
|
| Quantity |
| NM | Number of units (specified by the following component) that will be returned in each increment of the response. If no value is given, the entire response will be returned in a single increment. |
|
| Units |
| CE | CHaracters, LInes, PaGes, or RecorDs. Default is LI. |
3 | Response Modality |
| 60 | CE | Real time or Batch. Default is R. |
6 | Sort-by Field |
| 256 | SRT |
|
|
| Sort-by Field |
| ST | Segment field name of an output column by which the response may be sorted. Must contain a Y in the Sort column of the output specification table. |
|
| Sequencing |
| ID | As specified in HL7 Table 0397- Sequencing. Default is Ascending. |
ColName (Query ID=Z75) |
Key/
Search | Sort | LEN | TYPE | Opt | Rep | Match Op | TBL | Segment Field Name | Service Identifier Code | Element Name |
---|---|---|---|---|---|---|---|---|---|---|---|
PatientList | S | Y | 20 | CX | O |
|
|
| PID.3 |
| PID-3 Patient Identifier List |
PatientName |
|
| 48 | XPN |
|
|
|
| PID.5 |
| PID-5 Patient Name |
MothersMaidenName |
|
| 48 | XPN |
|
|
|
| PID.6 |
| PID-6 Mother_s Maiden Name |
DOB |
|
| 26 | TS |
|
|
|
| PID.7 |
| PID-7 Date/Time of Birth |
Sex |
|
| 1 | IS |
|
|
|
| PID.8 |
| PID-8 Sex |
Race |
|
| 80 | CE |
|
|
|
| PID.10 |
| PID-10 Race |
If the reader is defining a new query, please refer to the new recommended query/response pairs defined in section 5.3. This section is retained for backward compatibility and the framework for the existing functional queries.
The UDM message does not have a direct replacement in the new methodology. It is not clear how extensively this message is used.
There is a simple HL7 message that allows for unsolicited display update messages to be sent in HL7 format from one system to another.
Trigger events for the unsolicited update are generally the completion of a particular action (concerning a given patient). For example, a lab test might be completed, generating a STAT unsolicited display message to be sent to the appropriate location
5.10 SUPERCEDED QUERY/RESPONSE TRIGGER EVENTS AND MESSAGE PAIRS
5.10.1 Display message
5.10.1.0
5.10.1.1 Display vs. record-oriented messages
UDM^Q05 | Unsolicited Display Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
URD | Results/Update Definition |
| 5 | DB |
[ URS ] | Results/Update Selection Criteria |
| 5 | DB |
{ DSP } | Display Data |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
ACK^Q05^ACK | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
MSH | (no continuation pointer) |
|
DB |
[ { SFT } ] |
|
|
|
URD |
|
|
|
[ URS ] |
|
|
|
{ DSP } |
|
|
|
DSC |
|
|
The second message would contain:
MSH | (continuation pointer (to first message)) |
|
DB |
[ { SFT } ] |
|
|
|
{ DSP } |
|
|
|
DSC | (with continuation pointer) |
|
DB |
The last message would then contain:
MSH | (continuation pointer (to second message)) |
|
DB |
{ DSP } |
|
|
|
|
Note: This scheme works equally well with non-display messages, such as the Unsolicited Update ORU message (see Chapter 7).
Since these are unsolicited messages, intervening messages (from other systems) may be sent to the receiving application while the sections of the particular message are being continued. MSH-14-Continuation pointer enables the receiving system to keep track of extraneous intervening messages.
If the reader is defining a new query, please refer to the new recommended query/response pairs defined in section 5.3.3.4. This section is retained for backward compatibility and the framework for the existing functional queries.
Original mode implementation considerations
The particular allowable values for the filters in the QRD and QRF segments are determined among cooperating applications during implementation.
The format chosen for the query segments is very general. This might be read by prospective implementers to imply that the requirement for using the Standard is the ability to respond to a wide variety of inquiries. This is not the intent. The format here can be used with specific restrictions in any interface.
QRY^Q01 | Query Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
QRD | Query Definition |
| 5 | DB |
[ QRF ] | Query Filter |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
DSR^Q01 | Display Response Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
[ QAK ] | Query Acknowledgment |
| 5 | DB |
QRD | Query Definition |
| 5 | DB |
[ QRF ] | Query Filter |
| 5 | DB |
{ DSP } | Display Data |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
The QRF and QRD segments from the QRY are echoed back in the response. The DSC segment contains the continuation pointer, if it is not null (DSC-1-Continuation pointer).
If a display query has more than a single type of response (i.e., a DSR message with a different meaning, requiring different processing on the querying system), the second component of the Message Type field of the MSH segment may be used to indicate the response event type. For example, an ancillary name search display query may be defined using the query event code of DNM. The display response to such a query may be either a list of name matches (response event type is DNM) or the ancillary_s display results for an exact match to the name query (response event type is NRS). See HL7 Table 0003 - Event type code and field notes for MSH-9-Message type.
For clarity, A is the system initiating the query and B is the system sending the responses. Multiple queries and responses are permitted within single messages. The responses to a given query may be broken into several separate DSR messages. A single DSR message may contain responses to more than one QRY.
For clarity, A is the system initiating the query and B is the system sending the responses. Multiple queries and responses are permitted within single messages. The responses to a given query may be broken into several separate DSR messages. A single DSR message may contain responses to more than one QRY.
QRY^Q02 (A to B) | Query Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
QRD | Query Definition |
| 5 | DB |
[ QRF ] | Query Filter |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
QCK^Q02 (B to A) | Query General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
[ QAK ] | Query Acknowledgment |
| 5 | DB |
Later, perhaps more than once.
5.10.3.2 DSR/ACK - deferred response to a query (event Q03)
DSR^Q03 | Display Response Message | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
[ MSA ] | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
[ QAK ] | Query Acknowledgment |
| 5 | DB |
QRD | Query Definition |
| 5 | DB |
[ QRF ] | Query Filter |
| 5 | DB |
{ DSP } | Display Data |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
ACK^Q03^ACK (A to B) | General Acknowledgment | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ { ERR } ] | Error |
| 2 | DB |
Note: All record-oriented original mode and all enhanced mode queries follow the immediate and deferred acknowledgment modes defined in Section 5.10.3.0.
Version 2.3 introduced 4 enhanced queries as follows:
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
Code | Query Name | Defining Segment | Explanation |
---|---|---|---|
EQQ | Embedded Query language Query | EQL |
Custom message existing in an inhouse situation or communication between known vendors where the goal is to wrap a custom EQL Query in an HL7 Message.
This query provides an envelope with which a query expressed in a language (e.g., SQL) is packaged and sent to the responding system. It is meant to provide the maximum query functionality and re-use. The EQQ with its EQL query defining segment supports free-form select statements, based on the query language of choice (e.g., SQL). |
RQQ | Event Replay Query | ERQ | The Event Replay Query, introduced in Version 2.3, provides a way for the querying system to request data in a format very similar to the format that would have been used had this data been sent as an update in response to a trigger event. |
SPQ | Stored Procedure Request | SPR |
The Stored Procedure Query provides a mechanism for the querying system to invoke a stored procedure on the responding system. The request includes a stored procedure name and a list of parameters passed to it.
The SPQ enables an application on one system to execute a stored procedure on another system, which is coded to extract specific data. |
VQQ | Virtual Table Query | VTQ |
Preferable over multiple platforms or where standardization is desired. The VTQ provides a way to query for data to be expressed as tables without having to specify SQL or a stored procedure. The reader is advised to consider using the new recommended query as described in section 5.3.
The VQQ supports queries against Server database table (virtual or actual) based on specific selection criteria delineated in the VTQ segment. |
And 3 enhanced responses as follows:
Code | Response Name | Defining Segment | Explanation |
---|---|---|---|
EDR | Enhanced Display Response |
| Generalized display response message formatted for direct output to a display device |
ERP | Event Replay Response | ERQ | Formats the data on the basis of an application-specific segment-oriented (record-oriented) message |
TBR | Tabular Data Response |
| Formats the data in a relational format, as rows and columns. |
This set of queries and set of responses can be mixed and matched according to the following grid. Note that the pairs appearing on shaded lines are not valid.
Query | Response | Response type | Defining factor | Validity Status | Sec Ref |
---|---|---|---|---|---|
EQQ^Q04 | TBR^R08 | Tabular | EQL-2 = T | valid | 5.10.4.0 |
EQQ^Q04 | EDR^R07 | Display | EQL-2 = D | valid | 5.10.4.0 |
EQQ^Q04 | ERP^R09 | Segment Pattern | EQL-2 = R | not valid |
|
RQQ^Q09 | ERP^R09 | Segment Pattern | ERQ-2 = specified trigger event | valid | 5.10.4.2 |
RQQ^Q09 | TBR^R08 |
|
| Not valid |
|
RQQ^Q09 | EDR^R07 |
|
| Not valid |
|
SPQ^Q08 | TBR^R08 | Tabular | SPR-2 = T | Valid | 5.10.4.3 |
SPQ^Q08 | EDR^R07 | Display | SPR -2 = D | valid | 5.10.4.3 |
SPQ^Q08 | ERP^R09 | Segment Pattern | SPR -2 = R | Valid | 5.10.4.3 |
VQQ^Q07 | TBR^R08 | Tabular | VTQ-2 = T | valid | 5.10.4.4 |
VQQ^Q07 | EDR^R07 | Display | VTQ-2 = D | valid | 5.10.4.4 |
VQQ^Q07 | ERP^R09 | Segment Pattern | VTQ-2 = R | not valid |
|
The enhanced query/response pairs are contingent on the Server having defined the Conformance Statement.
Enhanced mode implementation considerations: definition of tables and _Virtual Tables_
The particular allowable values for the EQL, VTQ, SPR, and RDF segments are determined among cooperating applications during implementation.
The formats chosen for the query messages are very general. This might be read by prospective implementers to imply that the requirement for using the Standard is the ability to respond to a wide variety of inquiries. This is not the intent. The format here can be used with specific restrictions in any interface.
The contents of the tables expressed as TBR response messages are defined by the functional chapters. Where an existing HL7 segment contains the fields needed to form a row of a tabular response, the segment ID can be referenced. For example, if a table of patients is needed, where each row represents a patient and each column a field from the PID segment, then the PID can be referenced as a table, also sometimes referred to as a _Virtual Table._
Where each row is comprised of fields from multiple HL7 segments, the functional chapters may define additional tables. For example, a table may be defined to respond to insurance queries where each row represents a patient, and is comprised of columns derived from the PID segment and the insurance segments (IN1-IN4).
This query provides an envelope with which a query expressed in a language (e.g., SQL) is packaged and sent to the responding system. It is meant to provide the maximum query function without reinventing the wheel.
The EQQ with its EQL query defining segment supports free-form select statements, based on the query language of choice (e.g., SQL).
EQQ^Q04 | Embedded Query Language Query | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
EQL | EQL Definition |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
The response to the EQQ could be tabular or display. The segment pattern response (the ERP) is invalid given that there is no way to specify the desired segment pattern in the query defining segment, EQL.
TBR^R08 | Tabular Data Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgment |
| 5 | DB |
RDF | Table Row Definition |
| 5 | DB |
{ RDT } | Table Row Data |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
EDR^R07 | Enhanced Display Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgment |
| 5 | DB |
{ DSP } | Display Data |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
RQQ^Q09 | Event Replay Query | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
ERQ | Event Replay Query |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
|
ERP^R09 | Event Replay Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgment |
| 5 | DB |
ERQ | Event Replay Query |
| 5 | DB |
| . . . |
|
|
DB |
| ... |
|
|
DB |
| ... |
|
|
DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
Note: The remainder of this message is defined by the contents of the corresponding segment-oriented record-oriented unsolicited update message, excluding the MSH, as defined by the function-specific chapters of this specification. The input parameter list may be satisfied by more than one record-oriented unsolicited update message: in this case, the segment group after the ERQ segment may repeat.
When this message is continued, the continuation messages should include the MSH, MSA, [ERR], QAK, ERQ, and [DSC] segments, as well as the segments indicated by the ellipsis (...) in the response definition and the DSC should be used only at the end of the group corresponding to the record-oriented unsolicited update message.
Enhanced mode record-oriented response messages note: The RDF segment from the EQQ, VQQ and SPQ messages, and the ERQ segment from the EQQ message, are echoed back in their respective responses. The DSC segment contains the continuation pointer, if it is not null (DSC-1-continuation pointer).
The Stored Procedure Query provides a mechanism for the querying system to invoke a stored procedure on the responding system. The request includes a stored procedure name and a list of parameters passed to it.
The SPQ enables an application on one system to execute a stored procedure on another system, which is coded to extract specific data.
SPQ^Q08 | Stored Procedure Request | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
SPR | Store Procedure Request |
| 5 | DB |
[ RDF ] | Table Row Definition |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
Since the SPR segment includes a response format code, the response could be tabular, display or segment pattern.
EDR^R07 | Enhanced Display Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgment |
| 5 | DB |
{ DSP } | Display Data |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
ERP^R09 | Event Replay Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgment |
| 5 | DB |
ERQ | Event Replay Query |
| 5 | DB |
| . . . |
|
|
DB |
| ... |
|
|
DB |
| ... |
|
|
DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
Note: The remainder of this message is defined by the contents of the corresponding segment-oriented record-oriented unsolicited update message, excluding the MSH, as defined by the function-specific chapters of this specification. The input parameter list may be satisfied by more than one record-oriented unsolicited update message: in this case, the segment group after the ERQ segment may repeat.
When this message is continued, the continuation messages should include the MSH, MSA, [ERR], QAK, ERQ, and [DSC] segments, as well as the segments indicated by the ellipsis (...) in the response definition and the DSC should be used only at the end of the group corresponding to the record-oriented unsolicited update message.
Enhanced mode record-oriented response messages note: The RDF segment from the EQQ, VQQ and SPQ messages, and the ERQ segment from the EQQ message, are echoed back in their respective responses. The DSC segment contains the continuation pointer, if it is not null (DSC-1-Continuation pointer).
TBR^R08 | Tabular Data Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgment |
| 5 | DB |
RDF | Table Row Definition |
| 5 | DB |
{ RDT } | Table Row Data |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
VQQ^Q07 | Virtual Table Query | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
VTQ | VTQ Definition |
| 5 | DB |
[ RDF ] | Table Row Definition |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
EDR^R07 | Enhanced Display Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgment |
| 5 | DB |
{ DSP } | Display Data |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
TBR^R08 | Tabular Data Response | Status | Chapter | DB Ref. |
---|---|---|---|---|
MSH | Message Header |
| 2 | DB |
[ { SFT } ] | Software Segment |
| 2 | DB |
MSA | Message Acknowledgment |
| 2 | DB |
[ ERR ] | Error |
| 2 | DB |
QAK | Query Acknowledgment |
| 5 | DB |
RDF | Table Row Definition |
| 5 | DB |
{ RDT } | Table Row Data |
| 5 | DB |
[ DSC ] | Continuation Pointer |
| 2 | DB |
This section includes query/response message segments not carried forward to the recommended queries for v 2.4. The reader is referred to section 5.5 for those message segments that are used by both the recommended queries and the previous generation queries.
The EQL segment is used to define queries using select statements based on the query language of choice (e.g., SQL). Refer to the functional chapters for the lists of HL7-defined EQL select statements.
HL7 Attribute Table _ EQL _ Embedded Query Language
5.10.5 Other query/response message segments
5.10.5.0
5.10.5.1 EQL - embedded query language segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 32 | ST | O |
|
| 00696 | Query Tag | DB |
2 | 1 | ID | R |
| 0106 | 00697 | Query/Response Format Code | DB |
3 | 250 | CE | R |
|
| 00709 | EQL Query Name | DB |
4 | 4096 | ST | R |
|
| 00710 | EQL Query Statement | DB |
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.
Definition: This field refers to HL7 Table 0106 - Query/response format code for valid values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the name of the query. Where the default HL7 coding system is used, these names are assigned by the function-specific chapters of this specification. The values for this field are equivalent to those of SPR-3-Stored procedure name (see Section 5.10.5.5 _SPR - stored procedure request definition segment_).
Definition: This field contains the EQL select statement that is the basis of the query.
Fields are designated by the _@_ symbol concatenated with the HL7 segment ID followed by the sequence number for the field separated by a period (see chapter 2 for definition of segment ID and sequence number). If the field is divided into components, the designation may be suffixed with _.nn,_ to identify a particular component (a suffix of _.3_ indicates the third component of the field); otherwise, the whole field is assumed. If the field is further divided into subcomponents, the designation is suffixed with _.nn.mm,_ which identifies the component and subcomponent requested by relative position.
Site-specific fields may be used, provided that they begin with the letter _Z._ Note that in this case the site-specified segment ID (if the field is not being added to an existing HL7 segment) followed by the sequence number must be defined so that they do not conflict with existing HL7 segment IDs and field sequence numbers. Values for this field are defined in the function-specific chapters of this specification.
Note: If the _@_ is being used as one of the delimiter characters defined in MSH-2-Encoding characters, it must be _escaped _ (See Section )
The ERQ segment is used to issue queries where the desired response is formatted as an event replay response message. This enables the querying application to request detailed event data from an application that supports this feature, such that it may no longer be necessary for it to capture and store all event information at the time of the original trigger event.
HL7 Attribute Table _ ERQ _ Event replay query
5.10.5.1.1 EQL field definitions
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
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 32 | ST | O |
|
| 00696 | Query Tag | DB |
2 | 250 | CE | R |
|
| 00706 | Event Identifier | DB |
3 | 256 | QIP | O | Y |
| 00705 | Input Parameter List | DB |
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.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the HL7 event identifier corresponding to the original trigger event. Its contents dictate the format of the response message. Hence, a value of _A04_ in this field indicates a request for the data associated with the _register a patient_ trigger event. The ERP response message returns the contents of the _register a patient_ message defined in Chapter 3. If more than one match is found, the ERP returns repeating groups of the segments defined by the _A04_ message.
Components: <Segment Field Name (ST)> ^ <Values (ST)>
Definition: This field contains the list of parameter names and values to be passed to the responding system, in the form _<segment field name> ^ <value1 & value2 & value3 ...>._ A single valued parameter contains only a single subcomponent in the second component: thus no subcomponent delimiters are needed (e.g., <segment field name> ^ <value>). A simple list of values (i.e., a one-dimensional array) may be passed instead of a single value by separating each value with the subcomponent delimiter: _<segment field name> ^ <value1&value2 &...>._ Refer to Section 5.10.5.1.5, _EQL-4 EQL Query Statement (ST) 00710,_ for segment field name definition conventions.
For example, a value of _@PID.19^123-45-6789_ could be combined with the A04 event identifier to request patient registration data for the patient with the social security number 123-45-6789.
The QRD segment is used to define a query.
HL7 Attribute Table _ QRD - Original-Style Query Definition
5.10.5.2.1 ERQ field definitions
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
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 26 | TS | R |
|
| 00025 | Query Date/Time | DB |
2 | 1 | ID | R |
| 0106 | 00026 | Query Format Code | DB |
3 | 1 | ID | R |
| 0091 | 00027 | Query Priority | DB |
4 | 10 | ST | R |
|
| 00028 | Query ID | DB |
5 | 1 | ID | O |
| 0107 | 00029 | Deferred Response Type | DB |
6 | 26 | TS | O |
|
| 00030 | Deferred Response Date/Time | DB |
7 | 10 | CQ | R |
| 0126 | 00031 | Quantity Limited Request | DB |
8 | 250 | XCN | R | Y |
| 00032 | Who Subject Filter | DB |
9 | 250 | CE | R | Y | 0048 | 00033 | What Subject Filter | DB |
10 | 250 | CE | R | Y |
| 00034 | What Department Data Code | DB |
11 | 20 | VR | O | Y |
| 00035 | What Data Code Value Qual. | DB |
12 | 1 | ID | O |
| 0108 | 00036 | Query Results Level | DB |
Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
Definition: This field contains the date the query was generated by the application program.
Definition: This field refers to HL7 Table 0106 - Query/response format code for valid values.
HL7 Table 0106 - Query/response format code
5.10.5.3.1 QRD field definitions
5.10.5.3.2 QRD-2 Query Format Code (ID) 00026
Value | Description | Comment |
---|---|---|
D | Response is in display format |
|
R | Response is in record-oriented format |
|
T | Response is in tabular format |
|
Definition: This field contains the time frame in which the response is expected. Refer HL7 Table 0091 - Query priority for valid values. Table values and subsequent fields specify time frames for response.
HL7 Table 0091 - Query priority
5.10.5.3.3 QRD-3 Query Priority (ID) 00027
Value | Description | Comment |
---|---|---|
D | Deferred |
|
I | Immediate |
|
Definition: This field contains a unique identifier for the query. Assigned by the querying application. Returned intact by the responding application.
Definition: This field refers to HL7 Table 0107 - Deferred response type for valid entries.
HL7 Table 0107 - Deferred response type
5.10.5.3.4 QRD-4 Query ID (ST) 00028
5.10.5.3.5 QRD-5 Deferred Response Type (ID) 00029
Value | Description | Comment |
---|---|---|
B | Before the Date/Time specified |
|
L | Later than the Date/Time specified |
|
Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
Definition: This field contains the date/time before or after which to send a deferred response. If not present, the response can be sent when it is available. (See QRD-5-Deferred response type above).
Components: <Quantity (NM)> ^ <Units (CE)>
Subcomponents for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Definition: This field contains the maximum length of the response that can be accepted by the requesting system. Valid responses are numerical values (in the first component) given in the units specified in the second component. Refer to HL7 Table 0126 - Quantity limited request for valid entries for the second component. Default is LI (lines).
HL7 Table 0126 - Quantity limited request
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
Value | Description | Comment |
---|---|---|
CH | Characters |
|
LI | Lines |
|
PG | Pages |
|
RD | Records |
|
ZO | Locally defined |
|
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Note subcomponent contains sub-subcomponents
Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field identifies the subject, or who the inquiry is about.
Note: This field should not have been a required field. However, for backward compatibility it remains a required field. There are some queries in the standard that have not required this field.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field describes the kind of information that is required to satisfy the request. Valid values define the type of transaction inquiry and may be extended locally during implementation.
HL7 Table 0048 - What subject filter
5.10.5.3.8 QRD-8 Who Subject Filter (XCN) 00032
5.10.5.3.9 QRD-9 What Subject Filter (CE) 00033
Value | Description | Comment |
---|---|---|
ADV | Advice/diagnosis |
|
ANU | Nursing unit lookup (returns patients in beds, excluding empty beds) |
|
APN | Patient name lookup |
|
APP | Physician lookup |
|
ARN | Nursing unit lookup (returns patients in beds, including empty beds) |
|
APM | Medical record number query, returns visits for a medical record number |
|
APA | Account number query, return matching visit |
|
CAN | Cancel. Used to cancel a query |
|
DEM | Demographics |
|
FIN | Financial |
|
GID | Generate new identifier |
|
GOL | Goals |
|
MRI | Most recent inpatient |
|
MRO | Most recent outpatient |
|
NCK | Network clock |
|
NSC | Network status change |
|
NST | Network statistic |
|
ORD | Order |
|
OTH | Other |
|
PRB | Problems |
|
PRO | Procedure |
|
RES | Result |
|
RAR | Pharmacy administration information |
|
RER | Pharmacy encoded order information |
|
RDR | Pharmacy dispense information |
|
RGR | Pharmacy give information |
|
ROR | Pharmacy prescription information |
|
SAL | All schedule related information, including open slots, booked slots, blocked slots |
|
SBK | Booked slots on the identified schedule |
|
SBL | Blocked slots on the identified schedule |
|
SOF | First open slot on the identified schedule after the start date/tiem |
|
SOP | Open slots on the identified schedule between the begin and end of the start date/time range |
|
SSA | Time slots available for a single appointment |
|
SSR | Time slots available for a recurring appointment |
|
STA | Status |
|
VXI | Vaccine Information |
|
XID | Get cross-referenced identifiers |
|
See the HL7 Implementation Guide for detailed examples of use of various query filter fields.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the possible contents including test number, procedure number, drug code, item number, order number, etc. The contents of this field are determined by the contents of the previous field. This field could contain multiple occurrences separated by repetition delimiters.
Note: This field should not have been a required field. However, for backwards compatibility it remains a required field. There are some queries in the standard that have not required this field.
Components: <First Data Code Value (ST)> ^ <Last Data Code Value (ST)>
Definition: This field contains start and stop values separated by a component separator. These values constitute a window or range to further refine the inquiry.
Definition: This field is used to control level of detail in results. Refer to HL7 Table 0108 - Query results level for valid values. See chapters 4 and 7.
HL7 Table 0108 - Query results level
Value | Description | Comment |
---|---|---|
O | Order plus order status |
|
R | Results without bulk text |
|
S | Status only |
|
T | Full results |
|
The QRF segment is used with the QRD segment to further refine the content of an original style query.
HL7 Attribute Table _ QRF _ Original style query filter
5.10.5.4 QRF - original style query filter segment
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 20 | ST | R | Y |
| 00037 | Where Subject Filter | DB |
2 | 26 | TS | B |
|
| 00038 | When Data Start Date/Time | DB |
3 | 26 | TS | B |
|
| 00039 | When Data End Date/Time | DB |
4 | 60 | ST | O | Y |
| 00040 | What User Qualifier | DB |
5 | 60 | ST | O | Y |
| 00041 | Other QRY Subject Filter | DB |
6 | 12 | ID | O | Y | 0156 | 00042 | Which Date/Time Qualifier | DB |
7 | 12 | ID | O | Y | 0157 | 00043 | Which Date/Time Status Qualifier | DB |
8 | 12 | ID | O | Y | 0158 | 00044 | Date/Time Selection Qualifier | DB |
9 | 60 | TQ | O |
|
| 00694 | When Quantity/Timing Qualifier | DB |
10 | 10 | NM | O |
|
| 01442 | Search Confidence Threshold | DB |
Definition: This field identifies the department, system, or subsystem to which the query pertains. This field may repeat as in LAB~HEMO, etc.
Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
Definition: This field has been retained for backward compatibility only. It is recommended to use QRF-9 _ When quantity/timing qualifier. When used for backward compatibility, this field contains the dates and times equal to or after which this value should be included.
Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
Definition: This field has been retained for backward compatibility only. It is recommended to use QRF-9 _ When quantity/timing qualifier. When used for backward compatibility, this field contains the dates and times equal to or before which this date should be included. This field contains the dates and times equal to or before which this date should be included.
Definition: This field contains an identifier to further define characteristics of the data of interest.
Definition: This field contains a filter defined locally for use between two systems. This filter uses codes and field definitions that have specific meaning only to the applications and/or site involved.
Definition: This field specifies the type of date referred to in QRF-2-When data start date/time and QRF-3-When data end date/time.
HL7 Table 0156 - Which date/time qualifier
5.10.5.4.1 QRF field definitions
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
Value | Description | Comment |
---|---|---|
ANY | Any date/time within a range |
|
COL | Collection date/time, equivalent to film or sample collection date/time |
|
ORD | Order date/time |
|
RCT | Specimen receipt date/time, receipt of specimen in filling ancillary (Lab) |
|
REP | Report date/time, report date/time at filing ancillary (i.e., Lab) |
|
SCHED | Schedule date/time |
|
Definition: This field specifies the status type of objects selected in date range defined by QRF-2-When data start date/time and QRF-3-When data end date/time.
HL7 Table 0157 - Which date/time status qualifier
5.10.5.4.7 QRF-7 Which Date/time Status Qualifier (ID) 00043
Value | Description | Comment |
---|---|---|
ANY | Any status |
|
CFN | Current final value, whether final or corrected |
|
COR | Corrected only (no final with corrections) |
|
FIN | Final only (no corrections) |
|
PRE | Preliminary |
|
REP | Report completion date/time |
|
Definition: This field allows the specification of certain types of values within the date/time range.
HL7 Table 0158 - Date/time selection qualifier
5.10.5.4.8 QRF-8 Date/time Selection Qualifier (ID) 00044
Value | Description | Comment |
---|---|---|
1ST | First value within range |
|
ALL | All values within the range |
|
LST | Last value within the range |
|
REV | All values within the range returned in reverse chronological order (This is the default if not otherwise specified.) |
|
Components: <Quantity (CQ)> ^ <Interval (RI)> ^ <Duration (ST)> ^ <Start Date/Time (TS)> ^ <End Date/Time (TS)> ^ <Priority (ST)> ^ <Condition (ST)> ^ <Text (TX)> ^ <Conjunction (ID)> ^ <Order Sequencing (OSD)> ^ <Occurrence Duration (CE)> ^ <Total Occurrences (NM)>
Subcomponents for Quantity (CQ): <Quantity (NM)> & <Units (CE)>
Note subcomponent contains sub-subcomponents
Subcomponents for Interval (RI): <Repeat Pattern (IS)> & <Explicit Time Interval (ST)>
Subcomponents for Start Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
Subcomponents for End Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
Subcomponents for Order Sequencing (OSD): <Sequence/Results Flag (ID)> & <Placer Order Number: Entity Identifier (ST)> & <Placer Order Number: Namespace ID (IS)> & <Filler Order Number: Entity Identifier (ST)> & <Filler Order Number: Namespace ID (IS)> & <Sequence Condition Value (ST)> & <Maximum Number of Repeats (NM)> & <Placer Order Number: Universal ID (ST)> & <Placer Order Number: Universal ID Type (ID)> & <Filler Order Number: Universal ID (ST)> & <Filler Order Number: Universal ID Type (ID)>
Subcomponents for Occurrence Duration (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Definition: This field allows an interval definition to be used for specifying multiple responses to a query. With the addition of this filter, new query specifications should no longer use QRF-2-When data start date/time and QRF-3-When data end date/time in future implementations.
Note: This field is of data type TQ, which has been deprecated in Version 2.5. Please refer to Section 2.A.81 of Chapter 2, _Data Types,_ for information on implementing the quantity component (component 1).
Definition: This field contains a numeric value used to establish the minimum threshold match. The value instructs the responding system to return no records for patients whose _match weight_ on the look-up was lower than this user-defined value.
Example: |0.50| or |8.25|
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 lookups.
The SPR segment is used to issue queries using stored procedure calls. Refer to the functional chapters for the lists of HL7-defined stored procedure names, input parameters and output tables.
HL7 Attribute Table _ SPR _ Stored Procedure Request Definition
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
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 32 | ST | O |
|
| 00696 | Query Tag | DB |
2 | 1 | ID | R |
| 0106 | 00697 | Query/Response Format Code | DB |
3 | 250 | CE | R |
|
| 00704 | Stored Procedure Name | DB |
4 | 256 | QIP | O | Y |
| 00705 | Input Parameter List | DB |
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.
Definition: This field refers to HL7 Table 0106 - Query/response format code for valid values.
HL7 Table 0106 - Query/response format code
5.10.5.5.1 SPR field definitions
5.10.5.5.2 SPR-2 Query/response Format Code (ID) 00697
Value | Description | Comment |
---|---|---|
D | Response is in display format |
|
R | Response is in record-oriented format |
|
T | Response is in tabular format |
|
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the name of the stored procedure that is to be executed. Values for this field are defined in the function-specific chapters of this specification; site-specific stored procedure names begin with the letter _Z._
Components: <Segment Field Name (ST)> ^ <Values (ST)>
Definition: This field contains the list of parameter names and values to be passed to the stored procedure, in the form _<segment field name> ^ <value1& value2 & value3 ...>._ A single valued parameter contains only a single subcomponent in the second component: thus no subcomponent delimiters are needed (e.g., <segment field name> ^ <value>). A simple list of values (i.e., a one-dimensional array) may be passed instead of a single value by separating each value with the subcomponent delimiter: _<segment field name> ^ <value1& value2 &...>._ Refer to Section 5.10.5.1.5, _EQL-4 EQL Query Statement (ST) 00710 for segment field naming conventions.
The URD segment is used in sending unsolicited updates about orders and results. Its purpose is similar to that of the QRD segment, but from the results/unsolicited update point of view. Some of the fields have parallels in the QRD segment.
HL7 Attribute Table _ URD _ Results/update Definition
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
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 26 | TS | O |
|
| 00045 | R/U Date/Time | DB |
2 | 1 | ID | O |
| 0109 | 00046 | Report Priority | DB |
3 | 250 | XCN | R | Y |
| 00047 | R/U Who Subject Definition | DB |
4 | 250 | CE | O | Y | 0048 | 00048 | R/U What Subject Definition | DB |
5 | 250 | CE | O | Y |
| 00049 | R/U What Department Code | DB |
6 | 20 | ST | O | Y |
| 00050 | R/U Display/Print Locations | DB |
7 | 1 | ID | O |
| 0108 | 00051 | R/U Results Level | DB |
Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
Definition: This field contains the date and time the update was generated by the application program.
Definition: This field contains the priority associated with this report or update. Refer to HL7 Table 0109 - Report priority for valid values.
HL7 Table 0109 - Report priority
5.10.5.6.1 URD field definitions
5.10.5.6.2 URD-2 Report Priority (ID) 00046
Value | Description | Comment |
---|---|---|
R | Routine |
|
S | Stat |
|
Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>
Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
Note subcomponent contains sub-subcomponents
Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>
Definition: This field contains the definition of the subject, or who the report is about.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field describes the kind of information that is provided in the report. Valid values are the type of transaction inquiry. Refer to HL7 Table 0048 - What subject filter for valid values.
This table may be extended by local agreement during implementation. See the HL7 Implementation Guide for detailed examples of use of various query filter fields.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains either a test number, procedure number, drug code, item number, order number, etc. to identify the department. The contents of this field are determined by the contents of the previous field. This field could contain multiple occurrences separated by repetition delimiters.
Definition: This field contains a list of the locations to which the report should be distributed.
Definition: This field is used to control level of detail in results. Refer to HL7 Table 0108 - Query results level for valid values. Default level is T for full results. See chapters 4 and 7.
The URS segment is identical with the QRF segment, except that if the name of any field contains Query (of QRY), this word has been changed to Results (see URS-5-R/U other results subject definition).
HL7 Attribute Table _ URS _ Unsolicited Selection
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
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM # | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 20 | ST | R | Y |
| 00052 | R/U Where Subject Definition | DB |
2 | 26 | TS | O |
|
| 00053 | R/U When Data Start Date/Time | DB |
3 | 26 | TS | O |
|
| 00054 | R/U When Data End Date/Time | DB |
4 | 20 | ST | O | Y |
| 00055 | R/U What User Qualifier | DB |
5 | 20 | ST | O | Y |
| 00056 | R/U Other Results Subject Definition | DB |
6 | 12 | ID | O | Y | 0156 | 00057 | R/U Which Date/Time Qualifier | DB |
7 | 12 | ID | O | Y | 0157 | 00058 | R/U Which Date/Time Status Qualifier | DB |
8 | 12 | ID | O | Y | 0158 | 00059 | R/U Date/Time Selection Qualifier | DB |
9 | 60 | TQ | O |
|
| 00695 | R/U Quantity/Timing Qualifier | DB |
Definition: This field identifies the department, system, or subsystem to which the result pertains. This field may repeat as in LAB~HEMO, etc.
Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
Definition: This field contains the date/time the result starts (if applicable).
Components: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
Definition: This field contains the date/time the result ends (if applicable).
Definition: This field contains an identifier to define further the characteristics of the data that are of interest.
Definition: This field contains a further qualifier, defined locally, for use between two systems. This filter uses codes and field definitions that have specific meaning only to the application and/or site involved.
Definition: This field specifies the type of date referred to in URS-2-when data start date/time and URS-3-when data end date/time. Refer to HL7 Table 0156 - Which date/time qualifier for valid values.
Definition: This field specifies the status type of objects selected in date range defined by URS-2-when data start date/time and URS-3-When data end date/time. Refer HL7 Table 0157 _ Which date/time status qualifier for valid values.
Definition: This field allows the specification of certain types of values within the date/time range. Refer to HL7 Table 0158 - Date/time selection qualifier for valid values.
Components: <Quantity (CQ)> ^ <Interval (RI)> ^ <Duration (ST)> ^ <Start Date/Time (TS)> ^ <End Date/Time (TS)> ^ <Priority (ST)> ^ <Condition (ST)> ^ <Text (TX)> ^ <Conjunction (ID)> ^ <Order Sequencing (OSD)> ^ <Occurrence Duration (CE)> ^ <Total Occurrences (NM)>
Subcomponents for Quantity (CQ): <Quantity (NM)> & <Units (CE)>
Note subcomponent contains sub-subcomponents
Subcomponents for Interval (RI): <Repeat Pattern (IS)> & <Explicit Time Interval (ST)>
Subcomponents for Start Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
Subcomponents for End Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
Subcomponents for Order Sequencing (OSD): <Sequence/Results Flag (ID)> & <Placer Order Number: Entity Identifier (ST)> & <Placer Order Number: Namespace ID (IS)> & <Filler Order Number: Entity Identifier (ST)> & <Filler Order Number: Namespace ID (IS)> & <Sequence Condition Value (ST)> & <Maximum Number of Repeats (NM)> & <Placer Order Number: Universal ID (ST)> & <Placer Order Number: Universal ID Type (ID)> & <Filler Order Number: Universal ID (ST)> & <Filler Order Number: Universal ID Type (ID)>
Subcomponents for Occurrence Duration (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
Definition: This field allows an interval definition to be used for specifying multiple responses to a query. With the addition of this filter, new query specifications should no longer use URS-2-R/U when data start date/time and URS-3-R/U when data end date/time in future implementations.
Note: This field is of data type TQ, which has been deprecated in Version 2.5. Please refer to Section 2.A.81 of Chapter 2, _Data Types,_ for information on implementing the quantity component (component 1).
The VTQ segment is used to define queries that are responded to with the Tabular Data Message (TBR). The VTQ query message is an alternate method to the EQQ query message that some systems may find easier to implement, due to its use of HL7 delimiters that separate components of the selection definition, and its limited selection criteria. Queries involving complex selection criteria (nested operators, etc.) may need to be formatted as an EQL segment.
As with the other query methods, the functional chapters define specific queries supported as VTQ messages. Refer to these functional chapters for the lists of HL7-defined Virtual Tables, selection lists and criteria.
HL7 Attribute Table _ VTQ _ Virtual Table Query Request
5.10.5.7.1 URS field definitions
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
SEQ | LEN | DT | OPT | RP/# | TBL# | ITEM# | ELEMENT NAME | DB Ref. |
---|---|---|---|---|---|---|---|---|
1 | 32 | ST | O |
|
| 00696 | Query Tag | DB |
2 | 1 | ID | R |
| 0106 | 00697 | Query/ Response Format Code | DB |
3 | 250 | CE | R |
|
| 00698 | VT Query Name | DB |
4 | 250 | CE | R |
|
| 00699 | Virtual Table Name | DB |
5 | 256 | QSC | O | Y |
| 00700 | Selection Criteria | DB |
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.
Definition: This field refers to HL7 Table 0106 - Query/response format code for valid values.
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the name of the Virtual Table query. These names are assigned by the function-specific chapters of this specification. Site-specific VT query names begin with the letter _Z._
Components: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
Definition: This field contains the name of the Virtual Table being referenced. This table name may refer to an HL7-defined segment, an HL7 Virtual Table (refer to the functional chapters), or a site-specific _Z table._
Components: <Segment Field Name (ST)> ^ <Relational Operator (ID)> ^ <Value (ST)> ^ <Relational Conjunction (ID)>
Definition: Each repetition of this field defines a column in the RDT segment: the first repetition defines the first column of the RDT segment; the second repetition defines the second column of the RDT segments, etc.
This field indicates the conditions that qualify the rows to be returned in the query response. (This field conveys the same information as the _WHERE_ clause in the corresponding SQL expression of the query, but is formatted differently.) It is comprised of the following components:
The segment field name that is participating as a qualifier (usually the _key_). Refer to Section 5.10.5.1.5, for field naming conventions.
A relational operator, refer to HL7 Table 0209 - Relational operator for valid values.
HL7 Table 0209 - Relational operator
5.10.5.8.1 VTQ field definitions
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
Relational operator | Value | Comment |
---|---|---|
EQ | Equal |
|
NE | Not Equal |
|
LT | Less than |
|
GT | Greater than |
|
LE | Less than or equal |
|
GE | Greater than or equal |
|
CT | Contains |
|
GN | Generic |
|
If more than one comparison is to be made to select qualifying rows, a conjunction (defined by HL7 Table 0210 - Relational conjunction) relating this repetition of the field to the next:
HL7 Table 0210 - Relational conjunction
Relational conjunction | Note | Comment |
---|---|---|
AND | Default |
|
OR |
|
|
Hence, the segment
VTQ|TAG001|T|VT_QUERY_NAME|PID|@00108.1^EQ^EVANS^AND~@00108.2^EQ^CAROLYN <cr>
causes a response to be generated from the Virtual Table defined by the PID segment. All rows containing the name field subcomponents defined in the selection criteria field (last name = _Evans,_ first name = _Carolyn_) will be selected for the response. The columns returned from each selected row will be defined by the RDF segment (see Section
Notes:
As previously stated, the VTQ segment does not, and is not intended to, provide as robust selection function as native EQQ query. It is offered as a simpler alternative.
When applied to strings, the relational operators LT, GT, LE, and GE imply an alphabetic comparison.
A _generic_ comparison selects a record for inclusion in the response if the beginning of the designated field matches the select string.
Where a repeating field is specified as an operand, a match on any instance of that field qualifies the row for inclusion in the response message.
AND takes precedence over OR. More sophisticated precedence rules require that the query be expressed as an SQL message, or a stored procedure for the query may be written and referenced with the SPR segment.
Query for all lab results on patient #12233. The query is made at 11:00 a.m., 9/11/87. The Query anticipates an immediate display-oriented response.
MSH|^~\&|ICU||LAB01||||QRY^Q01|MSG00001|P|2.3<cr>
QRD|198709111012|D|I|4387|||20^LI|12233|RES|ALL<cr>
The response to the above query might look like the following:
MSH|^~\&|LAB01||ICU||||DSR|ZXT23461|P|2.3<cr>
MSA|AA|MSG00001P<cr>
QRD|198709111012|D|I|4387|||20^LI|12233|RES|ALL<cr>
DSP|||RESULTS FOR PATIENT#12233 SMITH, JOHN H. 09/11/87<cr>
DSP|||SPECIMEN#H85 COLLECTED 09/11/87 /07/0/0<cr>
DSP<cr>
DSP|||ELECTROLYTES<cr>
DSP||| SODIUM 140 [135-148] MEQ/L STAT<cr>
DSP||| POTASSIUM 4.0 [3.5-5.0] MEQ/L STAT<cr>
DSP||| CHLORIDE 89 [95-111] MEQ/L STAT<cr>
DSP||| CO2 20 [20-30] MEQ/L STAT<cr>
DSP||||LB<cr>
DSP|||CBC<cr>
DSP||| HEMOGLOBIN [13.5-18.0]<cr>
DSP||| HEMATOCRIT 45 [40-54] %<cr>
DSP||| RED CELL COUNT 5.0 [4.6-6.2] M/MM3<cr>
DSP||| MCHC 32 [32-36] G/DL<cr>
DSP||| MCH 28 [26-32] PG<cr>
DSP||| MCV 85 [81-101] FL<cr>
DSP||| WHITE CELL CNT 7.5 [5.0-10.0] K/MM3<cr>
DSP||||LB<cr>
DSP|||SPECIMEN#B24 COLLECTED 9/10/87<cr>
DSC|12333H85;12<cr>
A continuation query would echo back the contents of DSC-1-Continuation pointer as follows:
MSH|^~\&|ICU||LAB01||||QRY^Q01|MSG00003|P|2.3<cr>
QRD|198709111012|D|I|4387|||20^LI|12233|RES|ALL<cr>
DSC|12333H85;12<cr>
The following response shows that there is no further data by leaving DSC-1-Continuation pointer not present. This could be done by sending the DSC segment with no data, but the example does the same thing by totally omitting the DSC segment.
MSH|^~\&|LAB01||ICU|||DSR|ZXT23469|P|2.1<cr>
MSA|AA|MSG00003|<cr>
QRD|198709111012|D|I|4387|||20^LI|12233|RES|ALL<cr>
DSP|||RESULTS FOR PATIENT#12233 SMITH, JOHN H. 09/11/87<cr>
DSP|||SPECIMEN#H85 COLLECTED 09/10/87 /07/0/0<cr>
DSP<cr>
DSP|||ELECTROLYTES<cr>
DSP||| SODIUM 136 [135-148] MEQ/L STAT<cr>
DSP||| POTASSIUM 4.2 [3.5-5.0] MEQ/L STAT<cr>
DSP||| CHLORIDE 91 [95-111] MEQ/L STAT<cr>
DSP||| CO2 25 [20-30] MEQ/L STAT<cr>
DSP||||LB<cr>
Note: For illustration purposes, these examples assume that the following are defined in the ADT chapter:
The VQQ (using SQL) and EQQ selection criteria
The Virtual Table named PID, representing the PID segment as a "Virtual Table"
The stored procedure named PID_QRY_01
This section includes embedded query language (using SQL), Virtual Table and stored procedure query examples with tabular response.
The following examples illustrate a query for the last and first names, address, social security number and date of birth of patients whose last name is _Evans._ The fields comprising the query and response are identified by their HL7 segment field names. Where a field is composed of components, the particular component is identified with a _.n_ suffix (e.g., the patient last name is the first component of the patient name field (PID-5-Patient Name), and therefore is identified as _@PID.5.1._
The following examples illustrate this query expressed as an SQL select statement, as a Virtual Table query and as a stored procedure call
MSH|^~\&|CLINIC||CENTRAL-REG||||EQQ^Q04|MSG00001|P|2.4<cr>
EQL|TAG001|T|SQL_PID_QRY_01|SELECT @PID.5.1,@PID.5.2,@PID.11.1,@PID.11.2,
@PID.11.3,@PID.11.4,@PID.11.5,@PID.19,@PID.7
FROM PID WHERE @PID.5.1=_EVANS_<cr>
MSH|^~\&|CLINIC||CENTRAL-REG||||VQQ^Q07|MSG00001|P|2.4<cr>
VTQ| TAG001|T | VTQ_PID_QRY_01|PID|@PID.5.1^EQ^EVANS<cr>
RDF|9|@PID.5.1^ST^20~@PID.5.2^ST^20~@PID.11.1^ST^30~@PID.11.2^ST^30~@PID.11.3^ST^20~@PID.11.4^ST^2~@PID.11.5^ST^5~@PID.19^ST^11~@PID.7^TS^8<cr>
MSH|^~\&|CLINIC||CENTRAL-REG||||SPQ^Q08|MSG00001|P|2.4<cr>
SPR|TAG0001|T|SPR_PID_QRY_01|@PID.5.1^EVANS<cr>
RDF|9|@PID.5.1^ST^20~@PID.5.2^ST^20~@PID.11.1^ST^30~@PID.11.2^ST^30~@PID.11.3^ST^20~@PID.11.4^ST^2~@PID.11.5^ST^5~@PID.19^ST^11~@PID.7^TS^8<cr>
MSH|^~\&|CENTRAL-REG||CLINIC||||TBR^R08|MSG99001|P|2.4<cr>
MSA|AA|MSG00001<cr>
QAK|TAG0001|OK<cr>
RDF|9|@PID.5.1^ST^20~@PID.5.2^ST^20~@PID.11.1^ST^30~@PID.11.2^ST^30~@PID.11.3^ST^20~@PID.11.4^ST^2~@PID.11.5^ST^5~@PID.19^ST^11~@PID.7^TS^8<cr>
RDT|Evans|Aaron|105 Maple St.||Lancaster|PA|19786|156-96-2542|19520809<cr>
RDT|Evans|Bart|166 Norwood Ln.||Hershey|PA|19987|765-58-4615|19701217<cr>
RDT|Evans|Beth|15 Elmwood Ct.|Apt. 15|Gap|PA|19724|58-96-7619|19401119<cr>
RDT|Evans|Carolyn|903 Diane Circle||Phoenixville|PA|19460|156-96-2542|19620324<cr>
DSC|00005<cr>
For each of the above queries, a continuation query would echo back the contents of DSC-1- continuation pointer, as shown in the following examples:
MSH|^~\&|CLINIC||CENTRAL-REG||||EQQ^Q04|MSG00002|P|2.4<cr>
EQL|TAG001|T|SQL_PID_QRY_01|SELECT @PID.5.1,@PID.5.2,@PID.11.1,@PID.11.2,
@PID.11.3,@PID.11.4,@PID.11.5,@PID.19,@PID.7
FROM PID WHERE @PID.5.1=_EVANS_<cr>
DSC|00005<cr>
MSH|^~\&|CLINIC||CENTRAL-REG||||VQQ^Q07|MSG00002|P|2.4<cr>
VTQ| TAG001|T | VTQ_PID_QRY_01|PID|@PID.5.1^EQ^EVANS<cr>
RDF|9|@PID.5.1^ST^20~@PID.5.2^ST^20~@PID.11.1^ST^30~@PID.11.2^ST^30~@PID.11.3^ST^20~@PID.11.4^ST^2~@PID.11.5^ST^5~@PID.19^ST^11~@PID.7^TS^8<cr>
DSC|00005<cr>
MSH|^~\&|CLINIC||CENTRAL-REG||||SPQ^Q08|MSG00002|P|2.4<cr>
SPR|TAG0001|T|SPR_PID_QRY_01|@PID.5.1^EVANS<cr>
RDF|9|@PID.5.1^ST^20~@PID.5.2^ST^20~@PID.11.1^ST^30~@PID.11.2^ST^30~@PID.11.3^ST^20~@PID.11.4^ST^2~@PID.11.5^ST^5~@PID.19^ST^11~@PID.7^TS^8<cr>
DSC|00005<cr>
This response shows that there is no further data by leaving the continuation pointer not present. This could be done by sending the DSC segment ID with no data, but the example does the same thing by totally omitting the DSC segment
MSH|^~\&|CENTRAL-REG||CLINIC||||TBR^R08|MSG00003|P|2.4<cr>
MSA|AA|MSG00002<cr>
QAK|TAG0001|OK<cr>
RDF|9|@PID.5.1^ST^20~@PID.5.2^ST^20~@PID.11.1^ST^30~@PID.11.2^ST^30~@PID.11.3^ST^20~@PID.11.4^ST^2~@PID.11.5^ST^5~@PID.19^ST^11~@PID.7^TS^8<cr>
RDT|Evans|William|609 N. 3rd St.||Manheim|PA|19898|169-03-9872|19290726<cr>
RDT|Evans|Zachary|111 North Ln.||Lancaster|PA|19987|539-43-8725|19340926<cr>
Suppose that from the table of _Evans,_ Carolyn Evans is selected and the querying application now needs detailed ADT information about her. It can issue another query for this information using the event replay query (RQQ).
MSH|^~\&|CLINIC||CENTRAL-REG||||RQQ^Q09|MSG00004|P|2.3<cr>
ERQ|TAG0002|A04|@PID.19^ST^11^156-96-2542<cr>
The response is returned as an Event Replay Response, which is the HL7 ADT patient registration message corresponding to event code A04, prefixed by the MSH, MSA and ERQ segments:
MSH|^~\&|CLINIC||CENTRAL-REG||||ERP^R09|MSG00005|P|2.4<cr>
MSA|AA|MSG00004<cr>
QAK|TAG0002|OK<cr>
ERQ|TAG0002|A04|@PID.19^ST^11^156-96-2542<cr>
EVN|A04|199405151259||<cr>
PID|||2-68708-5|253763|EVANS^CAROLYN||19620324|F|||903 Diane Circle^^PHOENIXVILLE^PA^19460|(610)555-1212|(610)555-1212||S|C||156-96-2542||<cr>
NK1||EVANS^RICHARD|SPOUSE|903Diane Circle^^PHOENIXVILLE^
PA^19460|(610)555-1212|<cr>
PV1||E|EMERG||||0148^ADDISON^JAMES<cr>
..etc
Error responses to the above queries might look like the following:
MSH|^~\&|CENTRAL-REG||CLINIC||||TBR^R08|MSG99001|P|2.4<cr>
MSA|AE|MSG00001| <cr>
ERR|EQL^^4^207&&HL70357
QAK|TAG0001|AE<cr>
MSH|^~\&|CENTRAL-REG||CLINIC||||ERP^R09|MSG00005|P|2.3<cr>
MSA|AE|MSG00004||||^REQUESTED EVENT TYPE "A04" NOT SUPPORTED ON THIS SYSTEM<cr>
ERR|MSH^^9^201&&HL70357
QAK|TAG0002|AE<cr>
It is not clear that there is a good use case for the super segment pattern as described in the example in section 5.9.1.2.1.