Harmonization: add continuationToken to queryAck and queryContinuation

Editing of harmonization proposals prior to a harmonization meeting is restricted to the proposal submitter and the co-chairs of the steward comittee. Other changes will be undone. Please add comments to the "discussion" page associated with this proposal.

Recommendation for HL7 RIM Change	RECOMMENDATION ID:
Sponsored by: INM	Approval date by committee:
Revision (# and date): 20061006	Date submitted:
Editor/Author: Rene Spronk
PROPOSALNAME: add continuationToken to queryAck and queryContinuation

Stewards Position

REQUIRED - This table should contain one row for each Steward Committee affected by the recommendation.

TC	RECOMMENDATION APPROVAL STATUS	AFFECTED ENTITIES OF INTEREST TO TC (responsibility level: S=Steward; I=Interested)
INM	Discussed (see Stateless Queries)	S

Issue

The current query continuation mechanism is based on the fact that the query server maintains the state of the result set. This proposal adds two optional attributes which allow for the support of a query mechanism that is stateless at the server side.

Recommendation(s)

• Add a new (optional) attribute in the queryAck and queryContinuation classes, called "continuationToken", of datatype ST.
• Description of queryAck.continuationToken: Contains the the continuation state (the state of the query server, e.g. the relational database id of the last "record" returned). If queryAck.continuationToken is valued by the query server the querying system SHALL populate queryContinuation.continuationToken with that value in any subsequent query continuation/cancel interactions.
• Description of queryContinuation.continuationToken: Contains the continuationToken which contains the continuation state as reported by a stateless server. If a responding system values querAck.continuationToken, a querying system SHALL populate queryContinuation.continuationToken in subsequent query continuation/cancel interactions with that value.

RIM Recommendation(s)

See above. Two new attributes are introduced: queryAck.continuationToken and queryContinuation.continuationToken.

Vocabulary Recommendation(s)

None.

Rationale

A couple of members of HL7 Sweden have brought forward a use-case for a query which is stateless on the server. The current query mechanism is based on the fact that it is assumed that the receiving application maintains the state of the result set. A query continuation message (part of the Query Transmission Pattern) need not contain more than the queryID, the responding system needs to derive everything from that ID.

The argument against a stateful implementation is that the server side query session state would complicate load balancing and fail over (e.g. when using large server farms using SOAP to serve a multitude of clients). The query mechanism in HL7 is essentially 20 years old, which means it has a proven track record, but we also have to realize that 20 years ago issues such as "load balancing" were probably not a design consideration.

The use-case can be supported with the introduction of a new optional attribute. The proposed change is backwards compatible.

Recommended Action Items

• Implement the proposed solution

Discussion

• You, obviously, assume responsibility for the declaring in your query conformance statement that the resulting scans might suffer the problem that Lloyd points out: that continuation cookies may result in scans with incomplete or inconsistent data. A continuation query acts on a different (updated) dataset than the original query.
  • (Torbjorn Dahlin) When I think of it an implementation could stuff an "initial query timestamp" in the continuationToken sent to the client. When processing continuation requests the server could return results as if the query had been processed at the initial query time. A common requirement for new systems (at least here in Sweden) is that it should be possible to ask queries like "give me the patients 'current medication list' as it looked on the 1st of august 2006 at 10.30 am". If this requirement is fulfilled it would be possible to guarantee that you would receive exactly the same set of records regardless of if you fetched them all at once or if you used a stateless server and requested a record a day.