Difference between revisions of "Bolus"
m (→Issues) |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | This page documents the use of the [[Bolus]] mode in HL7 v2. | |
| + | *Also see [[The use of the Bolus ResponseModalityCode in HL7 v3]] | ||
| + | |||
== Summary == | == Summary == | ||
The "BOLUS" query response mode refers to a query in which a | The "BOLUS" query response mode refers to a query in which a | ||
| Line 10: | Line 12: | ||
protocol into the existing HL7 flows, but rather to use existing | protocol into the existing HL7 flows, but rather to use existing | ||
unsolicted messages. | unsolicted messages. | ||
| + | |||
| + | Note: Bolus exists in v2.x (not terribly well documented), and in HL7 v3 (not documented at all). This page was created as an attempt to document the Lore related to the Bolus query mode. | ||
| + | |||
== Introduction == | == Introduction == | ||
Normally, when a client makes an HL7 query, it interacts with | Normally, when a client makes an HL7 query, it interacts with | ||
| Line 33: | Line 38: | ||
OBR|...<br> | OBR|...<br> | ||
OBX|....<br> | OBX|....<br> | ||
| + | |||
| + | Notice the response is an ackowledgement, and has QAK and QPD segments. | ||
| + | |||
| + | |||
| + | With a Bolus response the query would look like | ||
| + | |||
| + | MSH|...|QBP^ZRG1|MSG922<br> | ||
| + | QPD|ZQ1^Query For Report^RG|Q003|VN-232-131321|<br> | ||
| + | RCP|I|B|<br> | ||
| + | |||
| + | The query response is a simple 'OK' and doesn't contain any data. | ||
| + | |||
| + | MSH|^~\&|RG|DB|...|RSP^ZRG1|<br> | ||
| + | MSA|MSG922<br> | ||
| + | QAK|Q003|OK|ZQ1^Query forReport^RG|1|<br> | ||
| + | QPD|ZQ1^Query For Report^RG|Q003|VN-232-131321<br> | ||
| + | |||
| + | ..... Then the QueryServer would connect to the HL7 sending host:port | ||
| + | that supports the app/fac "|RG|DB|" and would send the apparently | ||
| + | unsolicited message | ||
| + | |||
| + | MSH||ORU^RO1|MSG7721|<br> | ||
| + | PID|...<br> | ||
| + | OBR|...<br> | ||
| + | OBX|...<br> | ||
| + | |||
| + | == Issues == | ||
| + | |||
| + | The primary point is that the return healthcare data flows back as | ||
| + | normal ORU messages. | ||
| + | |||
| + | The interesting twist is: How did the QueryServer know where to send | ||
| + | the result? Normally, HL7 recievers simply "ACK" back on the port that | ||
| + | connected to them. In the case of "DEFERRED" response, presumably the | ||
| + | QueryServer remembers the APP|FAC that sent the message, and, | ||
| + | somewhere within the "HL7 Network Infastructure" (which could be in | ||
| + | the application or within a Cloverleaf/Datagate router) it knows the | ||
| + | IP host:port that the DEFERRED response should be sent to. | ||
| + | |||
| + | |||
| + | In the case of a BOLUS response, the same logic is followed. The | ||
| + | QueryServer knows that the message was from |RB|DB|, and it then looks | ||
| + | that up in the infastructure, and sends the unsolicted result message | ||
| + | to that port. | ||
| + | ==20100120 == | ||
| + | Mark Tucker will document use cases and bring propsal to "undeprecate" for the first Feb. concall. | ||
Latest revision as of 18:18, 19 January 2010
This page documents the use of the Bolus mode in HL7 v2.
Contents
Summary
The "BOLUS" query response mode refers to a query in which a the response to a query is sent back to the client as a completely normal set of apparently unsolicited HL7 messages, instead of as segments within special query/response messages. The BOLUS response mode is useful if the query mechanism is being grafted into an infastructure that already supports unsolicted transactions, and the decision is made not to engineer the query/response/continuation protocol into the existing HL7 flows, but rather to use existing unsolicted messages.
Note: Bolus exists in v2.x (not terribly well documented), and in HL7 v3 (not documented at all). This page was created as an attempt to document the Lore related to the Bolus query mode.
Introduction
Normally, when a client makes an HL7 query, it interacts with the HL7 query server by exchanging query and reseponse messages. The query may contain a QBP and an RCP segment, and the data comes back in messages containing QAK and RCP segments, as well as the "data" being asked for.
For example, the client asks for the visit note
MSH|...|DQBP^ZRG1|MSG922
QPD|ZQ1^Query For Report^RG|Q003|VN-232-131321|
RCP|I|R
....
and gets back an answer
MSH|...|RSP^ZRG1|
MSA|MSG922
QAK|Q003|OK|ZQ1^Query forReport^RG|1|
QPD|ZQ1^Query For Report^RG|Q003|VN-232-131321|
PID|...
OBR|...
OBX|....
Notice the response is an ackowledgement, and has QAK and QPD segments.
With a Bolus response the query would look like
MSH|...|QBP^ZRG1|MSG922
QPD|ZQ1^Query For Report^RG|Q003|VN-232-131321|
RCP|I|B|
The query response is a simple 'OK' and doesn't contain any data.
MSH|^~\&|RG|DB|...|RSP^ZRG1|
MSA|MSG922
QAK|Q003|OK|ZQ1^Query forReport^RG|1|
QPD|ZQ1^Query For Report^RG|Q003|VN-232-131321
..... Then the QueryServer would connect to the HL7 sending host:port that supports the app/fac "|RG|DB|" and would send the apparently unsolicited message
MSH||ORU^RO1|MSG7721|
PID|...
OBR|...
OBX|...
Issues
The primary point is that the return healthcare data flows back as normal ORU messages.
The interesting twist is: How did the QueryServer know where to send the result? Normally, HL7 recievers simply "ACK" back on the port that connected to them. In the case of "DEFERRED" response, presumably the QueryServer remembers the APP|FAC that sent the message, and, somewhere within the "HL7 Network Infastructure" (which could be in the application or within a Cloverleaf/Datagate router) it knows the IP host:port that the DEFERRED response should be sent to.
In the case of a BOLUS response, the same logic is followed. The
QueryServer knows that the message was from |RB|DB|, and it then looks
that up in the infastructure, and sends the unsolicted result message
to that port.
20100120
Mark Tucker will document use cases and bring propsal to "undeprecate" for the first Feb. concall.
