Query/response model

A query with its response should be thought of as a message pair. The following illustration shows the three generic models of message pairs: the declarative, interrogative, and imperative. Within each model, one system assumes the role of initiator and the other system assumes the role of responder. HL7 queries follow the "interrogative" style of messaging as described below.

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, 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."

Evolution of the query standard

The Query Standard, like the HL7 Standard in general, has been evolving since its inception in Version 2.1. Version 2.4 introduced a new methodology intended to supersede 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 v 2.3, "enhanced mode queries" were introduced that attempted to provide for a much higher level of precision in queries. Four new ways of specifying a query were introduced in Version 2.3.

• An Embedded Query Language query, which supports free-form select statements, based on the query language of choice (e.g., SQL)

• a Virtual Table request query which supports queries against server database tables (virtual or actual) based on specific selection criteria

• a stored procedure request, which enables an application on one system to execute a stored procedure on another system, which is coded to extract specific data

• an event replay request message, which is used to request data formatted as an event replay response

"Enhanced Mode" introduced three new ways to pass data to the responding system (e.g., a Server).

1. Passing values to specific parameters of a query. (Used by the stored procedure and event replay queries.) This is the most common and straightforward technique for creating queries. The drawback is that the client is tightly limited in the range of queries it can formulate.

2. Passing the query as a single complex query "expression". (Used by the Virtual Table query.) The query is defined by an expression-tree made up of the usual AND OR, '<' , '>', ... Operators can refer to column names or variables defined by the Server. These Queries give the Client significant flexibility in specifying their query over the columns that the Server has permitted. The cost of this Client flexibility is that the Server SHALL evaluate the query expression, rather than simply plug parameter values into an existing stored procedure.

3. Passing the query as a single string in an existing database query language such as SQL. (Used by the EQL External Query Language query.) An EQL query is represented as a string formatted in the particular syntax of an existing query language. The Server will probably pass this string expression directly to an existing database engine to evaluate the query, which will have to parse this expression to recover the query. The drawback of this technique is that different database engines use different query languages, and so the exact query string which the Client constructs will depend on the Server's query language.

Also in Version 2.3, the use of the trigger event was moving closer to the definition set forth in chapter 2. Each offered query had its own trigger event. In Version 2.3.1 each response had its own trigger event.

Version 2.4 Queries

Users of v 2.3 queries encountered some somewhat arbitrary limitations suggested by the v 2.3 standard. A close reading of the v 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 v 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 introduced 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. Conformance Statement structures introduced in Version 2.4 have been renamed Query Profiles.

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 and later.

As in versions of the standard 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, "Response format," and 5.2.5, "Query specification formats," discuss Response Formats and Query Specification Formats.

Query development methodology

Typically, an individual HL7 conformant query would evolve as follows:

An institution, or data owner, decides that it would like to make information available via a query. It decides precisely what data will be made available and how it will be offered. Knowing its own data, the data owner will define its query to return one of three representations of the data:

1. As traditional HL7 segments. (See section 5.2.4.1, "Segment pattern response.")

2. As rows and columns of data from a precisely defined Virtual Table. (See section 5.2.4.2, "Tabular response.")

3. 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 Query Profile.

The Query Profile concept is critical to the proper usage of the query/response pair. In the absence of a Query Profile, 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 Query Profile.

The Query Profile has the following broad structure:

Query Profile: 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 0, Note that the Vaccination Query related messages have been removed as these were deprecated and withdrawn as of v 2.8.

Acknowledgment Choreography

As of Version 2.9 Infrastructure and Messaging requires that Acknowledgment Choreography be explicitly specified in MSH-15 and MSH-16. Because of the nature of the Query and Response Messaging pattern, the Response message is always an Application Acknowledgment. To specify this, the value in MSH-16 SHALL always be “AL” to indicate that there will always be an Application Acknowledgment to the Query Message. See Chapter 2 for more details on this subject.

QUERY/RESPONSE PROFILE," will explain the Query Profile 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 Query Profile 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.

Response format

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

These structures support all original mode and enhanced mode responses, as well as the Conformance Based Queries.

Query specification formats

The previous section explained the three representations for data that are returned to a query client. This section discusses how the client may represent a query for information.

HL7 now recommends one primary way with 3 basic variants for specifying a query.

This query model with its variants is intended to assist implementers in translating specific query needs from the ordinary prose of the business model into an appropriate HL7 query paradigm. The paradigm selected will depend upon the philosophy of the institution: whether to allow relative freedom to client systems in composing query expressions, or to control rigidly the fields and operations to be offered. The following paragraphs compare and contrast the features of each of the HL7 query variant models. The differences between them lie mainly in the processing they require on the Server side.

Query by Simple Parameter

The first variant is called the Simple Parameter query. In the simple parameter query, the input parameters are passed in order as successive fields of an HL7 segment. The Server need only read them from the corresponding HL7 fields, and plug them into an internal function to evaluate the query.

This is the most basic form of the query in which the Server specifies a fixed list of parameters in its Query Profile. (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 or later Query By Parameter.

The obvious implementation gain is that the Server can simply map the input values to the parameters specified in the Query Profile. 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 Query Profile 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 Query Profile 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 SHALL 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 SHALL 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.

Summary chart of query/response pairs

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

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

Acknowledgment Choreography

As of Version 2.9 Infrastructure and Messaging requires that Acknowledgment Choreography be explicitly specified in MSH-15 and MSH-16. Because of the nature of the Query and Response Messaging pattern, the Response message is always an Application Acknowledgment. To specify this, the value in MSH-16 SHALL always be “AL” to indicate that there will always be an Application Acknowledgment to the Query Message. See Chapter 2 for more details on this subject.

Using the Query Profile

Critical to the proper usage of the new query/response pairs is the Query Profile concept. In the absence of a Query Profile, 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 Query Profile. The Query Profile identifies the query, specifies what items can be queried and describes what the response will look like.

Query Profile: 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 Query Profiles can be found in section 5.9, "QUERY/RESPONSE MESSAGE EXAMPLES."

Query with tabular response example

The user wishes to know the identity of the patient whose medical record number is "555444222111".

MSH|^~VALUEamp;|PCR|GenHosp|MPI||199811201400-0800||QBP^Q40^QBP_Q13|8699|P|2.8||||||||

QPD|Q40^WhoAmI^HL7nnnn|Q0001|555444222111^^^MPI^MR|||19980531|19990531|

RCP|I|

RDF|6|PatientList^CX^20~PatientName^XPN^48~Mother'sMaidenName^XPN^48~DOB^DTM^24~Sex^IS^1~Race^CWE^80|

The MPI system returns the following RTB message

MSH|^~VALUEamp;|MPI|GenHosp|PCR||199811201400-0800||RTB^K13^RTB_K13|ACK9901|P|2.8||||||||

MSA|AA|8699|

QAK|Q0001|OK|Q40^WhoAmI^HL7nnnn|1|

QPD|Q28^WhoAmI^HL7nnnn|Q0001|555444222111^^^MPI^MR|||19980531|19990531|

RDF|6|PatientList^CX^20~PatientName^XPN^48~Mother'sMaidenName^XPN^48~DOB^DTM^24~Sex^IS^1~Race^CWE^80|

RDT|555444222111^^^MPI^MR|Everyman^Adam||19600614|M||

Example of Query Profile with tabular response

Query Profile

Query Statement ID (Query ID=Z99):	Z99
Type:	Query (or Publish)
Query Name:	Who Am I
Query Trigger (= MSH-9):	QBP^Z99^QBP_Q13
Query Mode:	Both
Response Trigger (= MSH-9):	RSP^Z84^RSP_Z84
Query Characteristics:	Returns response sorted by PatientLastName unless otherwise specified. Note that neither the PID nor the RDF segments are used.
Purpose:	Find the identity of the patient for specified medical record number(s)
Response Characteristics:	Returns response sorted by PatientLastName unless otherwise specified.
Based on Segment Pattern:

QPD Input Parameter Specification

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

CWE

R

2

QueryTag

32

ST

R

3

PatientList

S

Y

20

CX

O

PID-3

PID-3 Patient Identifier List

QPD Input Parameter Field Description and Commentary

Input Parameter (Query ID=Z99)	Comp. Name	DT	Description
MessageQueryName		CWE	SHALL be valued Z99^WhoAmI^HL7nnnn.
QueryTag		ST	Unique to each query message instance.
PatientList		CX
			Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (IS)> ^ < assigning facility (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	CWE	If this field, PID.3.5, is not valued, all values for this field are considered to be a match.

RCP Response Control Parameter Field Description and Commentary

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		CWE	CHaracters, LInes, PaGes, or RecorDs. Default is LI.
3	Response Modality		60	CWE	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. SHALL contain a Y in the Sort column of the output specification table.
		Sequencing		ID	As specified in HL7 Table 0397- Sequencing. Default is Ascending.

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
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			24	DTM					PID.7		PID-7 Date/Time of Birth
Sex			1	CWE					PID.8		PID-8 Sex
Race			80	CWE					PID.10		PID-10 Race

QBP^Z99^QBP_Q13: Query Grammar: QBP Message

• Message Structure
• Acknowlegment Choreography
• v2.xml XSD

HL7 MessageStructure Table - QBP_Q13

Segment	Cardinality	Must Implement	Status
QBP_Q13
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..1		additional
QPD	1..1	Yes	additional
PID	0..1		additional
RDF	0..1		additional
RCP	1..1	Yes	additional
RDF	0..1		additional
DSC	0..1		additional

Original Mode Acknowledgement Choreography for QBP^Z99^QBP_Q13

Send Application Ack: RSP^Z84^RSP_Z84

Enhanced Mode Acknowledgement Choreography for QBP^Z99^QBP_Q13

When the MSH-15 value of a QBP^Z99^QBP_Q13 message is AL or ER or SU, an ACK^Z84^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Z99^QBP_Q13 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Z99^QBP_Q13 message is AL, a RSP^Z84^RSP_Z84 message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Z99^QBP_Q13 message is NE or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^Z84^ACK
	NE, AL, ER, SU	(none)
MSH-16	AL	application ack: RSP^Z84^RSP_Z84
	NE, ER, SU	(none)

<?xml version="1.0"?> <!-- v2.xml Message Definitions for Version 2.8.2 - here: QBP_Q13--> <!-- Copyright (c) 1999-2019, Health Level Seven. All rights reserved. --> <!-- (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb--> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml" targetNamespace="urn:hl7-org:v2xml" version="1.1"> <!-- import segment definition for version --> <xsd:include schemaLocation="segments.xsd" /> <!-- MESSAGE QBP_Q13 --> <!-- .. message definition QBP_Q13 --> <xsd:complexType name="QBP_Q13.CONTENT"> <xsd:sequence> <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" /> <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" /> <xsd:element ref="UAC" minOccurs="0" maxOccurs="1" /> <xsd:element ref="QPD" minOccurs="1" maxOccurs="1" /> <xsd:element ref="PID" minOccurs="0" maxOccurs="1" /> <xsd:element ref="RDF" minOccurs="0" maxOccurs="1" /> <xsd:element ref="RCP" minOccurs="1" maxOccurs="1" /> <xsd:element ref="RDF" minOccurs="0" maxOccurs="1" /> <xsd:element ref="DSC" minOccurs="0" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> <xsd:element name="QBP_Q13" type="QBP_Q13.CONTENT" /> </xsd:schema>

Download

RSP^Z84^RSP_Z84: Response Grammar: RTB Message

• Message Structure
• Acknowlegment Choreography
• v2.xml XSD

HL7 MessageStructure Table - RTB_K13

Segment	Cardinality	Must Implement	Status
RTB_K13
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..1		additional
MSA	1..1	Yes	additional
ERR	0..1		additional
QAK	1..1	Yes	additional
QPD	1..1	Yes	additional
ROW_DEFINITION	0..1		additional
RDF	1..1	Yes	additional
RDT	0..*		additional
DSC	0..1		additional

Original Mode Acknowledgement Choreography for RSP^Z84^RSP_Z84

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RSP^Z84^RSP_Z84

When the MSH-15 value of a RSP^Z84^RSP_Z84 message is AL or ER or SU, an ACK^Z84^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^Z84^RSP_Z84 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^Z84^RSP_Z84 message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^Z84^RSP_Z84 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^Z84^ACK
	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack:
	NE, AL, ER, SU	(none)

<?xml version="1.0"?> <!-- v2.xml Message Definitions for Version 2.8.2 - here: RSP_Z84--> <!-- Copyright (c) 1999-2019, Health Level Seven. All rights reserved. --> <!-- (generated on 09.01.2019 by HL7-Database) D:\Eigene Dateien\HL7\Datenbank\hl7_94.mdb--> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:hl7-org:v2xml" xmlns:hl7="urn:hl7-org:v2xml" targetNamespace="urn:hl7-org:v2xml" version="1.1"> <!-- import segment definition for version --> <xsd:include schemaLocation="segments.xsd" /> <!-- MESSAGE RSP_Z84 --> <!-- .. message definition RSP_Z84 --> <xsd:complexType name="RSP_Z84.CONTENT"> <xsd:sequence> <xsd:element ref="MSH" minOccurs="1" maxOccurs="1" /> <xsd:element ref="SFT" minOccurs="0" maxOccurs="unbounded" /> <xsd:element ref="UAC" minOccurs="0" maxOccurs="1" /> <xsd:element ref="MSA" minOccurs="1" maxOccurs="1" /> <xsd:element ref="ERR" minOccurs="0" maxOccurs="1" /> <xsd:element ref="QAK" minOccurs="1" maxOccurs="1" /> <xsd:element ref="QPD" minOccurs="1" maxOccurs="1" /> <xsd:element ref="RSP_Z84.ROW_DEFINITION" minOccurs="0" maxOccurs="1" /> <xsd:element ref="DSC" minOccurs="0" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> <xsd:element name="RSP_Z84" type="RSP_Z84.CONTENT" /> <xsd:complexType name="RSP_Z84.ROW_DEFINITION.CONTENT"> <xsd:sequence> <xsd:element ref="RDF" minOccurs="1" maxOccurs="1" /> <xsd:element ref="RDT" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> <xsd:element name="RSP_Z84.ROW_DEFINITION" type="RSP_Z84.ROW_DEFINITION.CONTENT" /> </xsd:schema>

Download

Formal specification of the Query Profile

The Query Profile contains the following information:

• Query Profile ID: The unique identifier applying to this query's Query Profile. 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-Query Profile 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 Query Profile 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 Query Profile.

• 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 SHALL 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 Query Profile 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 Query Profile.

• 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 Query Profile 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 Query Profile is very similar in appearance to a message syntax with two 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 Query Profile.

• Input Parameter Field Specification and Commentary: Cites the allowable parameters that can be passed to the recipient. The structure of this part of the Query Profile 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 Query Profile.

• 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 Query Profile 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 Query Profile. The existence of a standard Query Profile for any given query does not mean that a system SHALL implement this particular query to be conformant to the HL7 Standard. However, systems that do implement the query SHALL follow the specifications as given in the Query Profile.

Sites that wish to offer queries not specified by the Standard may create their own Query Profiles. By contrast to an HL7-standard query, in the case of a site defined query, the Query Profile 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 Query Profile was 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 Query Profiles published in the HL7 Standard, each table includes the Query Profile ID in parentheses in the upper left-hand cell. This allows the table to be imported automatically into the HL7 database.

Steps for developing a Query Profile

1. Before composing the Query Profile, express the query in ordinary English sentences.

2. Transform the query into a mathematical or pseudo-language statement. A syntax such as SQL provides a useful mechanism.

3. From the pseudo-statement, extract the parameters and the operations upon the parameters.

4. Advertise the parameters in the Query Profile.

5. Within the Query Profile, 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.

Query Profile introduction

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

Query Profile

Query Statement ID (Query ID=Znn):	Znn
Type:
Query Name:
Query Trigger (= MSH-9):
Query Mode:
Response Trigger (= MSH-9):
Query Characteristics:
Purpose:
Response Characteristics:
Based on Segment Pattern:

Query Statement ID: The unique identifier applying to this Query Profile. This value is transmitted as the first component of QPD-1-Message query name.

Type: Usually Query, except for publish-and subscribe Query Profiles (see section 5.7.3.1, "Example of a publish and subscribe Query Profile") 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, "Interactive continuation of response messages." 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.

Query grammar

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

Query Grammar: This and the following column specify the HL7 code name and full name of each segment sent in the query. Braces specify that the segment or segment group is repeatable; brackets specify the optionality of the segment or segment group.

Section Reference: Specifies where in the standard further information about the segment can be found.

When the Query by Example variant is used, the Query Grammar shows the segments that may be used to transmit parameters and the order in which they appear. Segments used to transmit parameters are always sent immediately following the QPD segment.

QBP^Znn^QBP_Qnn: Query Grammar: QBP Message

• Message Structure
• Acknowlegment Choreography

HL7 MessageStructure Table - QBP_Qnn

Segment	Cardinality	Must Implement	Status
QBP_Qnn
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..1		additional
QPD	1..1	Yes	additional
RDF	0..1		additional
RCP	1..1	Yes	additional
DSC	0..1		additional

Original Mode Acknowledgement Choreography for QBP^Znn^QBP_Qnn

Send Application Ack: RTB^Z

Enhanced Mode Acknowledgement Choreography for QBP^Znn^QBP_Qnn

When the MSH-15 value of a QBP^Z message is AL or ER or SU, an ACK^Z message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Z message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Z message is AL, a RTB^Z message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Z message is NE or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^Z
	NE, AL, ER, SU	(none)
MSH-16	AL	application ack: RTB^Z
	NE, ER, SU	(none)

Response grammar

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

Response Grammar: This and the following column specify the HL7 code name and full name of each segment returned in the response. Braces specify that the segment or segment group is repeatable; brackets specify the optionality of the segment or segment group.

For Query Profiles published in the HL7 Standard, the Response Grammar table includes the Query Profile 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.

RTB^Znn^RTB_Knn: Response Grammar: Widget Dispense Message

• Message Structure
• Acknowlegment Choreography

HL7 MessageStructure Table - RTB_Knn

Segment	Cardinality	Must Implement	Status
RTB_Knn
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..1		additional
MSA	1..1	Yes	additional
ERR	0..1		additional
QAK	1..1	Yes	additional
QPD	1..1	Yes	additional
...	1..1	Yes
DSC	0..1		additional

Original Mode Acknowledgement Choreography for RTB^Znn^RTB_Knn

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RTB^Znn^RTB_Knn

When the MSH-15 value of a RTB^Z message is AL or ER or SU, an ACK^Z message SHALL be sent as an immediate ack.

When the MSH-15 value of a RTB^Z message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RTB^Z message is AL, a message SHALL be sent as an application ack.

When the MSH-16 value of a RTB^Z message is NE or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^Z
	NE, AL, ER, SU	(none)
MSH-16	AL	application ack:
	NE, ER, SU	(none)

Response grammar for display response

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

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

RDY^Znn^RDY_K15: Response Grammar: Dispense History

• Message Structure
• Acknowlegment Choreography

HL7 MessageStructure Table - RDY_K15

Segment	Cardinality	Must Implement	Status
RDY_K15
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..1		additional
MSA	1..1	Yes	additional
ERR	0..1		additional
QAK	1..1	Yes	additional
QPD	1..1	Yes	additional
DSP	0..*		additional
DSC	0..1		additional

Original Mode Acknowledgement Choreography for RDY^Znn^RDY_K15

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RDY^Znn^RDY_K15

When the MSH-15 value of a RDY^Z message is AL or ER or SU, an ACK^Z message SHALL be sent as an immediate ack.

When the MSH-15 value of a RDY^Z message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RDY^Z message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RDY^Z message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^Z
	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack:
	NE, AL, ER, SU	(none)

QPD input parameter specification

The Input Parameter Specification section of the Query Profile looks very much like an attribute table and is followed by a commentary on the fields. Each row of the QPD Input Parameter Specification specifies one user parameter within the QPD segment. Values for user parameters are transmitted in successive fields of the QPD segment, beginning at QPD-3.

When the QSC variant is employed (see section 5.2.5.1.3, "Expression as a complex expression"), a complex query expression may be used as the only input parameter, or may be combined with other (simple) input parameters.

QPD Input Parameter Specification

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 Query Profiles published in the HL7 Standard, the Input Parameter Specification table includes the Query Profile 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 Chapter 2, section 2.16 of this 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 CWE 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.

QPD input parameter field description and commentary

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

Input Parameter (Query ID=Znn)	Comp. Name	DT	Description
MessageQueryName		CWE	SHALL 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.

QBE input parameter specification

In the Query by Example variant, discussed below in section 5.9.7, "Query by example (QBP) / tabular response (RTB)," the Query Profile 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 Query Profile 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).

QBE input parameter field description and commentary

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

QBE Input Parameter Field Description and Commentary

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.

RCP input parameter field description and commentary

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

RCP Response Control Parameter Field Description and Commentary

Field Seq (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.

Input specification: virtual table

When the QSC variant is in use, the Query Profile 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.

Virtual table field description and commentary

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

Virtual Table Field Description and Commentary

ColName (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.

Output specification for tabular response

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

Output Specification and Commentary: Virtual Table

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.3.2.8, "QBE 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.

Query Profile templates

Query Profile template for query with tabular response

Query Profile

Query Statement ID (Query ID=Znn):
Type:
Query Name:
Query Trigger (= MSH-9):
Query Mode:
Response Trigger (= MSH-9):
Query Characteristics:
Purpose:
Response Characteristics:
Based on Segment Pattern:

The message structure for QBP^Znn^QPB_Q13 can be found in 5.3.1.2. Use the QBP^Q13^QPB_Q13 Message structure.

QPD Input Parameter Specification

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

CWE

R

2

QueryTag

32

ST

R

3

InputItem . . .

QPD Input Parameter Field Description and Commentary

Input Parameter (Query ID=Znn)	Comp. Name	DT	Description
MessageQueryName		CWE	SHALL be valued Znn^<query name>^HL7nnnn.
QueryTag		ST	Unique to each query message instance.
InputItem1		DataType
			Components: (if applicable)
			(Description)
			(Valuation note)
	Component1 (if applicable)	DataType	(Valuation note)

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

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 following table is used only for the Complex Expression (QSC) variant.]

Virtual Table Field Description and Commentary

ColName (Query ID=Znn)	Comp. Name	DT	Description

[The following table is used only for the Query by Example 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

[The following table is used only for the Query by Example (QBE) variant.]

QBE Input Parameter Field Description and Commentary

Input Parameter (Query ID=Znn)	Comp. Name	DT	Description

RCP Response Control Parameter Field Description and Commentary

Field Seq (Query ID=Znn)	Name	Component Name	LEN	DT	Description

Output Specification and Commentary: Virtual Table

ColName (Query ID=Znn)	Key/ Search	Sort	LEN	TYPE	Opt	Rep	Match Op	TBL	Segment Field Name	Service Identifier Code	Element Name

RTB^Znn^RTB_Knn: Response Grammar: Widget Dispense Message

• Message Structure
• Acknowlegment Choreography

HL7 MessageStructure Table - RTB_Knn

Segment	Cardinality	Must Implement	Status
RTB_Knn
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..1		additional
MSA	1..1	Yes	additional
ERR	0..1		additional
QAK	1..1	Yes	additional
QPD	1..1	Yes	additional
...	1..1	Yes
DSC	0..1		additional

Original Mode Acknowledgement Choreography for RTB^Znn^RTB_Knn

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RTB^Znn^RTB_Knn

When the MSH-15 value of a RTB^Z message is AL or ER or SU, an ACK^Z message SHALL be sent as an immediate ack.

When the MSH-15 value of a RTB^Z message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RTB^Z message is AL, a message SHALL be sent as an application ack.

When the MSH-16 value of a RTB^Z message is NE or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^Z
	NE, AL, ER, SU	(none)
MSH-16	AL	application ack:
	NE, ER, SU	(none)

Query Profile template for query with segment pattern response

Query Profile

Query Statement ID (Query ID=Znn):
Type:
Query Name:
Query Trigger (= MSH-9):
Query Mode:
Response Trigger (= MSH-9):
Query Characteristics:
Purpose:
Response Characteristics:
Based on Segment Pattern:

QPD Input Parameter Specification

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

CWE

R

2

QueryTag

32

ST

R

3

InputItem . . .

QPD Input Parameter Field Description and Commentary

Input Parameter (Query ID=Znn)	Comp. Name	DT	Description
MessageQueryName		CWE	SHALL be valued Znn^<query name>^HL7nnnn.
QueryTag		ST	Unique to each query message instance.
InputItem1		DataType
			Components: (if applicable)
			(Description)
			(Valuation note)
	Component1 (if applicable)	DataType	(Valuation note)

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

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 following table is used only for the Complex Expression (QSC) variant.]

Virtual Table Field Description and Commentary

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

[The following table is used only for the Query by Example variant.]

QBE Input Parameter Field Description and Commentary

Input Parameter (Query ID=Znn)	Comp. Name	DT	Description

RCP Response Control Parameter Field Description and Commentary

Field Seq (Query ID=Znn)	Name	Component Name	LEN	DT	Description

QBP^Znn^QBP_Qnn: Query Grammar: QBP Message

• Message Structure
• Acknowlegment Choreography

HL7 MessageStructure Table - QBP_Qnn

Segment	Cardinality	Must Implement	Status
QBP_Qnn
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..1		additional
QPD	1..1	Yes	additional
RDF	0..1		additional
RCP	1..1	Yes	additional
DSC	0..1		additional

Original Mode Acknowledgement Choreography for QBP^Znn^QBP_Qnn

Send Application Ack: RTB^Z

Enhanced Mode Acknowledgement Choreography for QBP^Znn^QBP_Qnn

When the MSH-15 value of a QBP^Z message is AL or ER or SU, an ACK^Z message SHALL be sent as an immediate ack.

When the MSH-15 value of a QBP^Z message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a QBP^Z message is AL, a RTB^Z message SHALL be sent as an application ack.

When the MSH-16 value of a QBP^Z message is NE or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^Z
	NE, AL, ER, SU	(none)
MSH-16	AL	application ack: RTB^Z
	NE, ER, SU	(none)

RSP^Znn^RSP_Znn: Response Grammar: RSP Message

• Message Structure
• Acknowlegment Choreography

HL7 MessageStructure Table - RTB_Knn

Segment	Cardinality	Must Implement	Status
RTB_Knn
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..1		additional
MSA	1..1	Yes	additional
ERR	0..1		additional
QAK	1..1	Yes	additional
QPD	1..1	Yes	additional
...	1..1	Yes
DSC	0..1		additional

Original Mode Acknowledgement Choreography for RSP^Znn^RSP_Znn

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RSP^Znn^RSP_Znn

When the MSH-15 value of a RSP^Z message is AL or ER or SU, an ACK^Z message SHALL be sent as an immediate ack.

When the MSH-15 value of a RSP^Z message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RSP^Z message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RSP^Z message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^Z
	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack:
	NE, AL, ER, SU	(none)

Query Profile for query with display response

Query Profile

Query Statement ID (Query ID=Znn):
Type:
Query Name:
Query Trigger (= MSH-9):
Query Mode:
Response Trigger (= MSH-9):
Query Characteristics:
Purpose:
Response Characteristics:
Based on Segment Pattern:

The message structure for QBP^Znn^QPB_Q15 can be found in 5.4.3. Use the QBP^Q15^QPB_Q15 Message structure.

The data will display as follows: (Query ID=Znn)

DSP||| (data in actual display format)

QPD Input Parameter Specification

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

CWE

R

2

QueryTag

32

ST

R

InputItem

QPD Input Parameter Field Description and Commentary

Input Parameter (Query ID=Znn)	Comp. Name	DT	Description
MessageQueryName		CWE	SHALL be valued Znn^<query name>^HL7nnnn.
QueryTag		ST	Unique to each query message instance.
InputItem1		DataType
			Components: (if applicable)
			(Description)
			(Valuation note)
	Component1 (if applicable)	DataType	(Valuation note)

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

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 following table is used only for the Complex Expression (QSC) variant.]

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

[The following table is used only for the Query by Example variant.]

QBE Input Parameter Field Description and Commentary

Input Parameter (Query ID=Znn)	Comp. Name	DT	Description

RCP Response Control Parameter Field Description and Commentary

Field Seq (Query ID=Znn)	Name	Component Name	LEN	DT	Description

RDY^Znn^RDY_K15: Response Grammar: Dispense History

• Message Structure
• Acknowlegment Choreography

HL7 MessageStructure Table - RDY_K15

Segment	Cardinality	Must Implement	Status
RDY_K15
MSH	1..1	Yes	additional
SFT	0..*		additional
UAC	0..1		additional
MSA	1..1	Yes	additional
ERR	0..1		additional
QAK	1..1	Yes	additional
QPD	1..1	Yes	additional
DSP	0..*		additional
DSC	0..1		additional

Original Mode Acknowledgement Choreography for RDY^Znn^RDY_K15

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for RDY^Znn^RDY_K15

When the MSH-15 value of a RDY^Z message is AL or ER or SU, an ACK^Z message SHALL be sent as an immediate ack.

When the MSH-15 value of a RDY^Z message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a RDY^Z message is AL or ER or SU, a message SHALL be sent as an application ack.

When the MSH-16 value of a RDY^Z message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

Field	Value	Send Response
MSH-15	AL, ER, SU	immediate ack: ACK^Z
	NE, AL, ER, SU	(none)
MSH-16	AL, ER, SU	application ack:
	NE, AL, ER, SU	(none)

Query Profile table summaries

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

Response Type	Query Variant	Table Included	Section Reference
Display	None (QPD)	Query Profile 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	Query Profile 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	Query Profile 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)	Query Profile 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	Query Profile 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	Query Profile 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)	Query Profile 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	Query Profile 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	Query Profile 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