The use of the Bolus ResponseModalityCode in HL7 v3

This page documents the use of the Bolus ResponseModalityCode in HL7 v3.

• See Bolus for documentation of the use of the corresponding HL7v2 functionality.

Summary

The "BOLUS" query response mode refers to a query interaction which requests that the responses are to be sent as a completely normal set of apparently unsolicited HL7 messages, instead of as an application response interaction with a queryAck class.

Bolus in HL7 v2

• If field RCP-3 (Response Modality) contains the value T the Bolus mode is being used. Alternative values are R (Real Time) and B (Batch).
  • See the Bolus wiki page for HL7 v2 examples.

Bolus in HL7 version 3

Scenario/Dynamic model aspects

1. The query interaction is responded to by its associated application response, defined as the receiver responsibility of the query interaction. The response contains zero payloads and an indication that the query in Bolus mode was accepted.
2. zero or more unsolicited interactions with payloads that match the search criteria as listed in the initial query interactions are sent to the same application that did sent the orginial query interaction.

• Methodology issue: what's the 'trigger event type' of these unsolicited interactions? stat based? interaction based? Related question: What would it be for messages that are sent as a result of a publish/subscribe?

Lloyd: It depends. If they're "event replay" (i.e. they are interactions that had been sent previously to the same recipient and you're just re-sending them, the trigger event and ControlAct would be identical to whatever they were. If they're brand new interactions that you're effectively causing to be invoked "now", I'd say they were interaction-based.

• Methodology issue: what will be the content of the ControlActs in those interactions? Suppose my query is for 'completed observations for patient X', should the corresponding trigger event then be 'complete observation'?
  • If so, what if the system sending the responses first had an 'complete observation', followed by an 'revise observation', should we then use a copy of the original 'complete observation' ControlAct, but associate it with the revised payload?
  • The 'safe' option is probably to have the Bolus query trigger a series of new 'revise observation' triggers, one for each matching observation. The trigger event contained in the unsolicited messages will be a 'revise' (not a 'complete')

Lloyd: If it's just notifications, you could "pretend" you're doing a re-send of an old notification trigger event, so long as the date on the ControlAct is the date the state transition occurred, not 'now'. However, if you're wanting to send something like a fulfillment request, that would be a new interaction. (Please note the important distinction from "notification of order existance" and "request to fulfill an existing order" :>). I don't like the "revise" trigger event idea. No revision has occurred, so you shouldn't pretend that one has.

Static Model Aspects

• In Queries, QueryByParameter.responseModalityCode shall be valued with 'T' to indicate use of the Bolus mechanism.

• In the application response,
  • QueryAck.statusCode shall be 'executing'
  • QueryAck.queryResponseCode (assuming no errors occurred) should be either NF or OK. It should be NF if no matches were found, i.e. there will be no unsolicited interactions. If it contains the value OK one or more declarative interactions will be sent.
  • QueryAck.resultCurrentQuantity shall always be set to 0. It doesn't contain the number of future declarative interactions.
  • There will be zero payloads/subjects in the query response interaction.