visit the hl7 website The Demo site for our new HL7 Version 2+ (plus) Standard

18.4.146 QVR - query for previous events (Event Q17) (5.4.5)

The Query for Previous Events is like a Query by Parameter with a Segment Pattern Response except that the response consists of zero to many messages of the type defined in the Query Profile rather than a single response message containing multiple iterations of the segment pattern. While the messages sent in response to a QVR will reflect events which occurred in the past, the time stamp in the message header will reflect the time the message is actually constructed (current time). It is also similar to the previous generation VQQ/RQQ Event Replay.

While the response is similar to subscription messages, it differs from subscription in that the response messages are the result of "interrogating" the database rather than events being triggered in the current timeframe.

In a Query for Previous Events, the Server still has to parse the query, but avoids the handshaking protocols required in normal query/response situations. The Server acknowledges the query with the general acknowledgement message ACK. The Server then transmits a sequence of messages as if they were simulated unsolicited messages. This is useful for low end systems that unable to deal with the overhead of the query response message syntax, i.e., systems that can only process unsolicited update messages.

Systems that choose to offer the QVR should offer guidance in the Query Profile, where appropriate, concerning the scope and size of the data requested by the Client. Moreover, the Query Profile should contain language cautioning Clients of the potential for harm from getting messages out of the original sequence and/or context.

Use cases for this query are as follows: 1) to populate a database initially, 2) to recover from an extended down time on the part of the recipient, or 3) to enable systems which normally receive unsolicited data to be extended to act as a query client with minimal modification.

Note: If there is a concern that it will be difficult to distinguish these messages from any current realtime messages, e.g., if they are going down the same pipe, the data offerer might choose to designate a unique MSH-3 Sending application for the messages it sends in response to a QVR. This would allow downstream systems to recognize which messages were the result of the QVR, versus which are the result of current realtime activity on the sending system. For example, there may be 2 systems receiving pharmacy dispense messages. If system A wishes to issue a QVR to receive a historical load, system B might misinterpret the QVR results coming over the pipe as actual live data. A separate Sending Application name would allow for easy differentiation.
Segment Cardinality Implement Status
QVR^Q17^QVR_Q17
MSH

Message Header

[1..1] SHALL
SFT

Software Segment

 
QPD

Query Parameter Definition

[1..1] SHALL
QBP [0..1]  
Hxx

any HL7 segment

[0..1]  
RCP

Response Control Parameter

[1..1] SHALL
DSC

Continuation Pointer

[0..1]  

 

QVR_Q17

MSH-15 MSH-16 Immediate ACK Application Ack
Blank Blank - ACK^Q17^ACK
NE AL - ACK^Q17^ACK
AL, SU, ER AL ACK^Q17^ACK ACK^Q17^ACK
We need some ER7 examples...
We need some XML examples...
Segment Cardinality Implement Status
ACK^Q17^ACK
MSH

Message Header

[1..1] SHALL
SFT

Software Segment

 
MSA

Message Acknowledgment

[1..1] SHALL
ERR

Error

 

 

ACK

We need some ER7 examples...
We need some XML examples...

The QVR message segments are identical to those of the QBP. A QVR Query Profile may use either the QSC or query by example syntactic variants as well as the query by simple parameter.