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 patients 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 enquiring user formulates the query on-line at the terminal of one system and waits while that system sends the query to another. He gets the response and displays it at their terminal. When the user is formulating such a query she may only have limited understanding of what data is available for a given patient. Sometimes the users 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 he or she has found 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 responding system 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 continuation query provides a way to permit the users to formulate queries loosely while limiting the processing burden on the responding system. The initial query 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 responding system retrieves and formats the specified amount of data and returns it with a special key field, DSC-1-continuation pointer. The initiating system 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 initiating system.
If, after viewing the data, the user requests more, the initiating system sends the query again in a format that is identical with the first, except that the DSC-1-continuation pointer value is included and the requested amount of data may be changed. The responding system uses 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 "cancel query" message. This message is formatted just like a continuation query, except that the event-type (MSH-2-encoding characters) is set equal to CNQ. Although the effect to the initiating system is the same as if it had not sent any message (no further query data is received), receipt of this message by the responding system enables it to discard any unsent continuation data that might be queued.