Constrain Transmission Wrapper

Issue

The current message and transmission layer seems to mix transmission and "how to interpret/process" information. The following criteria are used to determine if an attribute is Transmission or Processing related:

1. The attribute is related to processing if the attribute has an impact on the semantic interpretation of the interaction.
2. The attribute is related to processing if the attribute is processed by the receiving HL7 Application as opposed to the Messaging Adapter.
3. The attribute is related to Transmission if there is equivalent functionality in MIL headers (e.g. Webservices, ebXML, SOAP).

A list of "pure transmission" attributes includes:

• Message.id: id of the Transmission
• Message.creationTime: time of the transmission
• AttentionLine Keyword/value: Transmission routing information
• Device: end point identification
• Attachment class: grouper of things for transmission purposes
• Message.securityText: use is transmission oriented.

A list of "processing related attributes" includes:

• Message.profileId - Indicates how to validate the instance. Can influence receiver behavior. Identifies part of the "contract" between sender and receiver.
• Transmission.versionCode - Indicates how to validate the interactions, allows confirmation of "can I process this?". Identifies part of the "contract" between sender and receiver.
• Transmission.interactionId - Indicates how to validate the interaction, allows confirmation of "can I process this?" and determines receiver behavior. Identifies part of the "contract" between sender and receiver.
• Transmission.processingModeCode - Indicates how the instance is to be treated. Identifies part of the "contract" between sender and receiver.
• Message.processingCode - Indicates how the instance is to be treated. Identifies part of the "contract" between sender and receiver.

To check:

• Message.acceptAckCode: ???

Notes related to MCCI R1 wrappers:

• Message.attachmentText (deprecated) - Contains information referenced by the message
• Note that agent/Organization and LocatedEntity/Place have been removed from the R-MIM during the May 2006 INM out of cycle meeting.

Possible solutions

1. Moving some/all of these attributes to ControlAct (which would actually have to be a deprecate and copy)

• Advantages - ControlAct is already understood and in place
• Disadvantages - This information relates to the Interaction, while ControlAct really Describes the trigger event. Also, ControlAct is used to convey history, where these attributes aren't terribly relevant

2. Adding an additional class to deal with this information. See Behavioral Contract Wrapper (new wrapper mechanism), which adds an Act to the current ControlAct wrapper.

• Advantages - Addresses disadvantages above
• Disadvantages - It adds yet another layer

OPEN ISSUE: MnM and INM to express a preference for one of the above options (regardless of which specific attributes will be "moved").

Discussion

In application responses, it would make sense to include a link to the original controlAct, instead of including a reference to the orginal Transmission. (Tom de Jong, 20051113)

20060630 MnM discussion

• need a better explanation of why the layers should be separated
  • Need to indicate what can be thrown away and what can't
  • Need to indicate what can be changed when routing and what can't
  • Better mapping to "standard" transports
• need to recognize that this "non-transport" information is routing related
• Ask INM and SOA to update this
• Defer future discussion until INM asks us to re-address
• Consider as an agenda item INM/MNM joint meeting Sept. 2006