Constrain Transmission Wrapper

Issue Statement and Project Goals

There are several crucial issues in the current Wrapper model, that are of interest and in the scope of the MCCI R2 project. These can be summarized as follows:

• The current message and transmission layer seems to mix transmission and "how to interpret/process" information. This causes confusion and ambiguity in HL7 implementations
• Transmission Wrapper (MCCI R1) provides various constructs available in the MIL technologies, such as reliable messaging, addressing, attachments handling, sequencing and security. This causes problems in implementations relying on MIL to provide these QoS data communication features.

Our aim is to analyze the classes and atributes contained in Transmission Wrapper (but also look into ControlAct when necessary) and determine do they naturaly belong to the Transmission Part of the Behavioral_Contract_Wrapper_(new_wrapper_mechanism) (i.e. purely transmission oriented semantics), or should they reside with the Conversation Part (payload and context related semantics).

The Final Goal

The final goal is to declare the Transmission Part of Behavioral_Contract_Wrapper_(new_wrapper_mechanism) optional. In other words, we want to enable efficient implementations using different communication paradigms (point to point communication, message brokers, SOA, etc), with as little duplication of functionality as possible.

It is important to note that if we declare an attribute mandatory, but the class that this attribute resides with belongs to the Transmission part, that does not mean that this attribute will be communicated in each message instance. If the Transsmission part is not used this functionality will be provided elsewhere, according to the paradigm and SLA used in the specific case. What will be however required is that the role of HL7 Bridge can construct and de-construct Transmission part of Behavioral_Contract_Wrapper_(new_wrapper_mechanism) when bridging from one communication paradigm to another.

Defitnion of the Criteria

The following criteria is used to determine the which lebel should go to which class/attribute of the Transmission Wrapper, and consequently actions to be taken based on the results:

• The class/attribute is related to processing if it has an impact on the semantic interpretation of the interaction (Label "P")
  • Action - these constructs belong to Conversation Part. They might be declared mandatory, required or optional, depending on the functionality they provide.
• The attribute is related to transmission if it relates to the semantics of how/why/when to transfer the message, and has no concerns what is contained in the payload. I.e. the attribute is consumed by the Messaging Adapter opposite to the receiving HL7 Application (Label "P")
  • Action - these constructs should belong to Transmission Part. They can be declared mandatory, required or optional, depending on the functionality they provide.
• The attribute is related to Transmission if there is equivalent functionality in MIL headers (e.g. Webservices, ebXML, SOAP) (Label "C")
  • Action - these constucts should belong to Transmission Part. They should be declared optional as we want to enable the implementers to choose on which layer to implement the required functionality.
• The attribute presumes a certain solution paradigm (e.g. Messaging Oriented Middleware) (Label "B")
  • Action - the attribute should be declared optional (note - this might be the same as Label C, but at this point we are not sure do some of attributes labeled "B" should go to Conversation part)

Note that any class or attribute in the Transmission Wrapper might have more then one label attached to it. Also, a special attention is paid to the class/attribute that has backwards compatibility value.

Transmission Wrapper Attributes and Classes Labels

(Miroslav) The list below is just a start and needs more work...

Btw, do we take the MCCI R1 or R2 as the input? To me, it would make more sense to have R2 as the starting point, since it reflects more recent findings and work done.

A list of "Transmission" classes and attributes includes (Labels C and/or T):

• Message.id attribute (T/C): id of the Transmission. Should stay mandatory.
• Message.creationTime attribute (T): Time of the transmission. Should stay mandatory.
• AttentionLine Keyword/value attribute (T): Transmission routing information
• Message.responseModeCode (C/B): attribute expresses how does the Sender expect the response, if one is required by the Receiver Resposibility defintion. Should stay in Transmission part, and labeled as mandatory.
• Accept Ack class construct (C): Reliable messaging on the HL7 Layer. The same funcitonality exists at MIL (e.g. WS-ReliableMessaging). The entire construct should be declared optional.
• Attachment class construct (C): Attachment handling on the HL7 Layer. The same funcitonality exists at MIL (e.g. SOAP with Attachments). The entire construct should be declared optional.
• Sender/Receiver/Device classes construct (C): Addressing on the HL7 Layer. The same funcitonality exists at MIL (e.g. WS-Addressing). The entire construct should be declared optional.
• Message.sequenceNumber attribute (C): inOrder delivery on the HL7 Layer. The same funcitonality exists at MIL (e.g. WS-ReliableMessaging). Should be declared optional.

A list of "processing/conversation related attributes" includes (Label P):

• Message.profileId (P/C) - Indicates to which profile(s) does the message conform to. Can influence receiver behavior. Identifies part of the "contract" between Sender and Receiver. Should stay optional.
• Transmission.versionCode (P) - Indicates how to validate the interactions, allows confirmation of "can I process this?" (e.g. version of RIM). Identifies part of the "contract" between sender and receiver. Should stay optional.
• Transmission.interactionId (P/C) - 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. Should be declared optional, as the same functionality in different paradigms exists elsewehere (method call on service in SOA).
• Transmission.processingModeCode (P) - Indicates how the instance is to be treated. Identifies part of the "contract" between sender and receiver. Should be declared optional
• Message.processingCode (P) - Indicates how the instance is to be treated. Identifies part of the "contract" between sender and receiver. Should be declared optional
• Message.securityText (P/C) - used as a mechanism to convey a security/authentication token established via a prievious message. Belongs to the Conversation part, and should be declared optional.

• Note that agent/Organization and LocatedEntity/Place have been removed from the R-MIM during the May 2006 INM out of cycle meeting.

Comments

Comment 12/18/06 (Alan Honey) - As I look at some of these items, in my mind this still leaves unresolved some higher level questions, namely what is requirement and what is solution, and also what is appropriately "instance level" vs "contractual. Some of the items identified above are (correctly in my view) identified as "contractual" yet the need is felt for instance level attributes, which is a messaging specific solution. If they are totally optional items, then I can live with that. Going back to the SOA vs Messaging issue, in SOA, most of this variability would be constrained in the contract exposed by a specific version of a specific service, and a specific endpoint would be identified that exposed the specific version, and some would be handled by process management (orchestration) mechanisms totally without any action by either provider or consumer. What I am saying is that the "requirement" for the items defined as "processing" is not "paradigm or transport" specific, but the solution maybe. In the case of SOA, some of these would not require any specific instance level attributes at all.

Comment 01/09/07 (Miroslav) - I think we should separate the items that refer to HL7 protocol semantics (i.e. renaming the "pure transmission" group) from the HL7 message processing related attributes. The HL7 communication protocol semantics would encompass items that describe the HL7 Transmission Pattern as the core unit of HL7 communication protocol. For example, Message.acceptAck is pure HL7 protocol semantics, and expresses the requirement for the Receiver to send the Message Adapter Acknowledgement (MCCI_IN002002), which is an HL7 message and not MIL specific interaction. The idea is to have items grouped in two categories, so the HL7 protocol semantics can be (in future) declared as an optional (part of the) wrapper (See Behavioral Contract Wrapper (new wrapper mechanism)), since these requirements are nowadays are usually managed and implemented with different MIL technologies. We should have that machinery in the HL7 messages as well (for reasons such as backwards compatibility, simple and pure messaging architectures, etc), but those would all need to be optional as Alan suggests.

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

Resolution

MnM endorsed option #2 at the January, 2007 WGM