Difference between revisions of "Query Transmission Pattern"
Rene spronk (talk | contribs) (→FAQ) |
Rene spronk (talk | contribs) |
||
| Line 12: | Line 12: | ||
#abort the query transmission pattern | #abort the query transmission pattern | ||
| − | There is also a publish/subscribe mechanism, which is an extensions of the generic query mechanism | + | There is also a [[Publish/Subscribe Transmission Pattern|publish/subscribe mechanism]], which is an extensions of the generic query mechanism. |
A Responses to a query IS NEVER (i.e. can never be) a notification. It is always a query response, with a queryAck class. The same is true for messages sent as a response to a subscription or event replay query. The dynamic model doesn't allow sending query responses as "notifications". (Note that the dynamic model doesn't really cover subscriptions or Bolus-type queries at the moment) | A Responses to a query IS NEVER (i.e. can never be) a notification. It is always a query response, with a queryAck class. The same is true for messages sent as a response to a subscription or event replay query. The dynamic model doesn't allow sending query responses as "notifications". (Note that the dynamic model doesn't really cover subscriptions or Bolus-type queries at the moment) | ||
Latest revision as of 12:33, 14 March 2009
The Transmission Sender (an HL7 Application) sends the initial Query Transmission, including all applicable query parameter values. The Transmission Receiver (another HL7 Application) performs an accept-level validation, and sends an accept-level acknowledgement transmission if the Sender had requested such an acknowledgement.
The timing and delivery method of the Response Transmission (a.k.a. Query Response depends on settings as provided by the Sender with the initial Transmission.
A query response identifies the number of results provided in the response transmission, as well as the number of remaining results.
The Query Continuation/Abort Transmission can be used to
- query for response with additional results
- abort the query transmission pattern
There is also a publish/subscribe mechanism, which is an extensions of the generic query mechanism.
A Responses to a query IS NEVER (i.e. can never be) a notification. It is always a query response, with a queryAck class. The same is true for messages sent as a response to a subscription or event replay query. The dynamic model doesn't allow sending query responses as "notifications". (Note that the dynamic model doesn't really cover subscriptions or Bolus-type queries at the moment)
Notes
- The only way to send a response to a different system than the querying system is the use of the respondTo class in the transmission wrapper. There is no other mechanism. In such circumstances a copy of the queryParameters in the response is probably useful.
- Querying should not be confused with Polling. These are at two entirely different conceptual levels.
FAQ
Does setting the QueryByParameter.initialQuantity to "1" in a message instance mean "return only one record that matches my query parameters and if more than one record matches return a detected issue"?
- No. It means that the responding system should return a maximum of 1 record(s) in the response message. If there are more than 1, only 1 will be returned in the response, and the response will indicate (in the QueryAck.resultRemainingQuantity attribute) how many more results there are, which can be queried using the Query Continuation/Cancel Transmission (MCCI_IN000003).
