Talk:The use of the Bolus ResponseModalityCode in HL7 v3
- 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.
