原文链接：

 

Receiver Responsibilities

From HL7Wiki

Jump to: ,

This page documents , i.e. all the facts and traditions about a particular subject that have been accumulated over time, but that have not been documented in a ballot yet.

Receiver Responsibilities of an will be defined for the target receiver of the message. do not have receiver responsibilities; contained within the batch may have receiver responsibilities. The receiver responsibilities (if any) will be cast in terms of one of several interactions to be sent as a result of receiving the message and/or as one trigger event out of a set of trigger events the receiver will fire after receipt of the message.

Implementers will need to take care that applications that can send an interaction are capable of receiving the ‘receiver responsibility’ interactions, and vice versa.

Definition

Receiver Responsibilities are a set of mutually exclusive responsibility options that are triggered by the receipt of an interaction. Each responsibility option includes a description that describes the circumstances under which that option should be fired. These circumstances are all mutually exclusive, such that one and only one responsibility option fires in response to a given interaction. The recipient must invoke one and only one of the receiver responsibilities (provided that at least one is defined) when they receive the interaction.

An individual responsibility consists of:

• Returning an . This is what's sent as an , a.k.a. 'application acknowledgment'.
• Firing a . Note that firing a trigger event may result in the initiation of zero or more interactions to various applications, possibly including the sender of the originating interaction. These interactions are NOT sent as , but as interactions which initiate a new conversation (for lack of a better world).
• Returning an and firing a . Note that firing a trigger event may result in the initiation of zero or more interactions to various applications, possibly including the sender of the originating interaction. These interactions are NOT sent as , but as interactions which initiate a new conversation (for lack of a better world).

However, for reasons of dynamic conformance, the following constraint applies: either all receiver responsibilities have interactions or none do. In other words: if one of the individual receiver responsibities is to "return an interaction", then all individual receiver responsibities shall "return an interaction".

It is NOT be possible to define something that amounts to:

• the receiver will either trigger an event, OR sent an interaction.
• the receiver will either Do Nothing, OR sent an interaction.

Open Issue

MnM have discussed "optional receiver responsibilities", the exact status of this is not known. The principle -as far as we know- has not been formally approved by MnM.

• The only circumstance that is known of where support for a receiver responsibility might be optional would be the "refuse with counter-proposal" interaction because there's an obvious fall-back if it's not supported. Because there is no capability to mark interactions as optional at the moment, all current receiver responsibilities should be interpreted as "required".

Notes

1. All interactions have the (not explicitly documented) default receiver responsability of sending a (a.k.a. ) message in case of syntax or conformance errors. This resposibility is conditional on the value of the Message.acceptAckCode attribute.
2. It is possible that an interaction (sent when a receiver fulfills its receiver resposibilities) will itself have receiver responsibilities, resulting in a between sender and receiver.
3. An Event Replay Request has no Receiver Responsibilities; it is however the initial interaction of a .
4. Any interaction chosen to be a receiver responsibility SHALL have a "Application Response" (..0300) Transmission Wrapper (this includes the Acknowledgement class required to link interaction with its response). An interaction which has the normal "Send Message" transmission wrapper (..0100) can't be used as a receiver responsibility.
5. A (when defined as a receiver responsibility option) may result in zero interactions, either because the receiver supports no interactions that are fired by that trigger event, or because the application configuration is such that no potential receivers have been registered as interested in receiving such interactions, then nothing happens.
6. The fact that an interaction has receiver responsibilities is independent of the timing issue, e.g. when the response will be sent. No default shall be assumed. Release 2 of the MCCI domain addresses the timing issue by introducing a new Mandatory Message.responseModeCode attribute with the following description: "responseModeCode: Identifies the timing and delivery method of the Application Response Transmission as required by the initiating system. ResponseModeCode can have one of three values: I (Immediate, the receiver should act as if the Sender is blocking), D (Deferred, the receiver may respond at a later point in time), or Q (Queue the response, initiating system will Poll for responses at a later point in time). If the receiver doesn't support the requested ResponseModeCode in combination with a given interactionId it should indicate this as an error in either the accept-level acknowledgement or in the application response."

Retrieved from ""