Query Infrastructure

The Query Specification Message

A query by parameter mechanism is provided for defining a query specification. The structure of an HL7 V3 composite message for a query specification consists of the HL7 transmission wrapper, a query specification control act and a parameter definition structure that is specified as required for each domain defined query request message type.

The parameter definition structure for the query by parameter query specification is an information structure that may be similar in form for many query implementations but differentiated by constraints on attribute values as described as follows. This chapter includes two R-MIMs for query by parameter specification. One that allows domains to define the full query by parameter specification and one that allows them specify only the parameter items.

Refer to the walk-through below for details on classes and attributes.

The Query Response Message

An HL7 V3 composite Query Response Message is prepared by an HL7 V3 Query Fulfiller application role in response to receiving a Query Specification Message. The structure of this HL7 V3 composite message consists of the HL7 transmission wrapper, a query response control act and a domain defined message type.

Refer to the walk-through below for details of the classes and attributes.

The Query Continuation Message

The Query Continuation Message is a query control message that applies to the logical level of a query session that is controlled by the applications that implement the HL7 V3 Query Placer and Query Fulfiller application roles. The structure of this HL7 V3 composite message consists of the HL7 transmission wrapper and a minimal query control act.

Refer to the walk-through below for details of the classes and attributes.

Overview

The Query Infrastructure domain comprises the classes and attributes needed to support queries, responses, and continuation requests. It is an extension of the Message Control Act Infrastructure domain.

Trigger Events and Control Acts

The query storyboards, application roles, trigger events and interactions provided in this domain are for example purposes only. Domains will define these within their query definitions.

The initial interaction generates messages as a result of the trigger events Execute Query Specification (by the data requester) and Complete Query Response (by the data server).

If the data requester has asked that results be sent back in partial sets, subsequent interactions may generate messages as a result of the trigger events Activate Query Continuation (by the data requester) and Complete Query Continuation (by the data server). This pair of trigger events continues for as long as the data requester wants to continue receiving result sets. It ceases when the data server runs out of qualifying data or the data requester does not want any more result sets.

All query messages are centered on the ControlActProcess act, which is discussed further below and is described fully in the Message Control Act Infrastructure domain.

Focal Classes Exposed

The ControlActProcess act, as constrained within the Query domain, constitutes the trigger event control act within which the query payload classes are contained. Its associations facilitate the production of queries by data requesters and of responses by data servers.

The dynamic model for query-response is that of a request for data by some interested system, followed by the production of a response by a server. Thus, the mood code for ControlActProcess will always be Order from the data requester and Event from the data server.

Query D-MIM Core Structure

The structure of the query D-MIM supports both the initial query-response interaction and subsequent interactions.

In the initial query-response interaction, the payload from the data requester will consist of exactly one instance of the QueryByParameter class. This class in turn will be associated with at least one instance of the Parameter class (either ParameterList or one to many ParameterItem) and may also be associated with instance(s) of the SortControl class. The payload from the data server will consist of exactly one instance of the QueryAck class, containing summary information about the response and about the data (if any) that it contains. This is followed by the actual response data, if there are any, structured as instances of RIM classes that are associated with the QueryAck class. The associations within the response payload are elaborated upon in the definition of the specific query being used.

If all the response data could not be returned in one result set, there will be additional query-response interactions. In subsequent interactions, the payload from the data requester will consist of exactly one instance of the QueryContinuation class, in which the data requester specifies how much more data it would like to receive, if any. As in the initial interaction, the payload from the data server will consist of an instance of the QueryAck class (containing summary data) and then the actual response data, if there are any.

Query Domain Information Model Classes

ControlActProcess

The core Act of the Query domain wrapper. This Act contains information about the query message. Its act relationships and participations, while included in support of queries, contain information about the message itself rather than about the query.

This class is described more fully in Control Act Infrastructure D-MIM walkthrough.

QueryByParameter

This class contains information about the query. Non-query message information is contained in ControlActProcess. This is the entry point for those domain-defined queries that wish to fully express the query specifications, including sort order. The key attribute of this class is queryId, which is used to associate this query instance with both the initial response message and with later query interactions. Valuing queryId avoids the need for the QueryContinuation and QueryAck classes (which also contain the queryId attribute) to carry as much detail information as is carried in the initial query.

The requester values attributes of this class in the initial query interaction to specify the query's priority, whether data should be returned immediately or later, to specify a delivery time if desired, and to indicate how many records (i.e., instances of matching response data) it would like to receive in each response message.

The following is the description and use of the attributes for QueryByParameter class.

• queryId: may be valued by the initiating application to identify the query (it is intended to be used to match response messages to the originating query and may remain the same across multiple interactions when performing continuations of a previous query)

• statusCode: defined by the QueryEventStatus domain (required)

• modifyCode: indicates whether the subscription to a query is new or is being modified

• responseElementGroupId: identifies the specific message type to be returned in the query response (this message type must be chosen from the set of message types supported by the receiver responsibilities associated with the query interaction)

• responseModalityCode: defines the timing and grouping of the response instances

• responsePriorityCode: identifies the time frame in which the response is expected

• initialQuantity: defines the maximum size of the response that can be accepted by the requesting application.

• initialQuantityCode: defines the units associated with the magnitude of the maximum size limit of a query response that can be accepted by the requesting application (defined by the QueryRequestLimit domain)

• executionAndDeliveryTime: specifies the time the response is to be returned

QueryContinuation

This class is instantiated by the requester in subsequent query interactions if needed. It references query information through the value contained in the queryId attribute. The requester may specify a differently-sized return payload or may request that the next data set be started at any point.

The following is the description and use of the attributes for this class.

• queryId: may be valued by the initiating application to identify the query (it is intended to be used to match response messages to the originating query and may remain the same across multiple interactions when performing continuations of a previous query)

• statusCode: defined by the QueryEventStatus domain (required)

• startResultNumber: specifies the instance number in the original query result set to start return in next query response message

• continuationQuantity: specifies the number of instance matches to return in the next query response message

QueryAck

The server returns an instance of this class both in the initial response (even if no matching data are returned) and continuation responses, if any. It references query information through the value contained in the queryId attribute.

The following is the description and use of the attributes for this class.

• queryId: may be valued by the initiating application to identify the query (it is intended to be used to match response messages to the originating query and may remain the same across multiple interactions when performing continuations of a previous query)

• queryResponseCode: allows the responding system to return a precise response status (values defined by the QueryStatus domain

• resultTotalQuantity: specifies the total number of instance matches for query specification associated with this query response instance

• resultCurrentQuantity: specifies the number of matches for processed query specification that occur in current bundle of matches

• resultRemainingQuantity: specifies number of matches for processed query specification that have yet to be sent to receiver

Parameter

Sent in the initial query payload. Note that the DMIM includes both QueryByParameter and Parameter as domain entry point stubs. The QueryByParameter as Stub RMIM may be represented as either ParameterItem classes or the ParameterList class. The ParameterList as Stub RMIM is a grouping of ParameterItem classes. The Parameter classes carry the values that specify the data that the requester wishes to be returned. The ParameterItem class is instantiated as many times as there are parameters to be sent, but in any case at least once. ParameterList is the entry point for many of the domain-defined queries.

If continuation interactions are required in order to bring back additional results, the continuation messages will not contain this class.

Query definitions in the application domains state how the value and semanticsText attributes are to be populated.

The following is the description and use of the attributes for this class.

• id: can assist in tracing problems with implementing the query-by-parameter mechanism

• value: represents a valued element structure for the element specified in the query response

• semanticsText: provides a unique identification to an element within a specified query response structure

SortControl

Sent in the initial query payload. This class allows the requester to specify the order in which the server should return multiple results. If used, it is instantiated only once.

If continuation interactions are required in order to bring back additional results, the continuation messages will not contain this class.

The following is the description and use of the attributes for this class.

• sequenceNumber: specifies the order

• elementName: identifies a RIM element in a query response

• directionCode: specifies sequence of sort order (values are ascending, descending, or none)

Act

This class connects the query response (either initial or continuation) with the top or outermost application class that is instantiated for the response.

Participations

The following control act participations are defined for the query control act. Note that where the model permits more than one instance of (or requires) a participation or act relationship, cardinality should be constrained as fully as possible in the domain-defined message type. Note that the location for any of the participants, if provided, will be defined in the R_AssignedPerson CMET.

• authorOrPerformer: Who or what is asking for the information. More than one overseer may exist; this participation is not required. This participation associates the query act with either an entity that is described in an instance of the R_AssignedEntity role class, or a device that is described in an instance of an instance of the R_AssignedDevice role CMET.

• overseer: The supervisor of the administrative person (dataEnterer) who physically places the query into the system. More than one overseer may exist; this participation is not required. This participation associates the query act with a person that is described in an instance of the R_AssignedPerson role CMET.

• dataEnterer: The administrative person who physically places the query into the system. More than one dataEnterer may exist; this participation is not required. This participation associates the query act with a person that is described in an instance of the R_AssignedPerson role CMET.

• informationRecipient: Who will get a copy of the returned data. More than one informationRecipient may exist; this participation is not required. This participation associates the query act with a person that is described in an instance of the R_AssignedPerson role CMET.

Refer to the Trigger Event Control Act Detected Issue Local CMET walkthrough for details of the DetectedIssueEvent and DetectedIssueManagement.