Open Transmission Wrapper Issues

Back to Infrastructure and Messaging TC

Known Issues

MCCI:

• Guidance as to XPath expression for identifying where syntax errors have occurred - Lloyd McKenzie, Alexander Henket
• Translations: add "derived from .. ID" attribute ?, much like acknowledgementOf.
• Constrain payloads to 0..1 in non-query-responses (textual constraint)
• There is an action item for INM from Vocab: "Vocab TC recommends to INM and MnM that Trigger Events and Interation IDs become coded attributes with INM to determine what the datatype should be for them."
• RIM AttentionLine.value :: ANY. Definition:OpenIssue: INM agreed to provide new definition that includes a strong set of constraints on the data tpes that this attribute can assume. Pending the delivery of that description, it was agreed in harmonization to drop the proposed description.
• How to respond to duplicate Interactions ? How should an HL7 Application (this is NOT a Messaging Infrastructure question) react to a duplicate Interaction ? Reject it ? Send the same response as it has sent before ?
• AttentionLine: IDs of interactions contained in batch ? (Manifest). See below for a discussion of Manifest items.
• Is there a need for a general mechanism for chunking large messages as well as batches. (UK: max 25Mb size of individual transactions)
• (solved) MnM issue: inheritance of transmission wrappers from Batch to Message. See action item 1023. "Child transmissions inherit all elements of the Parent transmission unless explicityl overridden, such as sender, receiver, attachments, transmission time, etc. This is applicable to (but not limited to) Messages contained in a Batch. The RIM and the MCCI domain will be updated to reflect this."

MCCI-Batch

• Batch: RIM proposal to add ProfileID attribute to the Batch class. 2005-08-08 INM agrees, confer with Conformance (i.e. MnM, v3 Conformance) before sending in the proposal.
• Batch: add attachmentText to Batch models.
• Batchname good as a code (type of batch), but we need batchId (batchGroup class or attribute?) for linking chunks of a batch. Related to ConversationId. Penny to work on use-case description.

ATS:

• Message.id "sameness" discussion after transformation by a Gateway

Scope of the current Transmission Wrapper

As part of the discussion of the newly proposed Transmission Wrapper (in MCCI R2), and of the Abstract Transport Specification (ATS) document, we'll need to take a fresh look at the Batch/Message Transmission Wrappers and the underlying use-cases.

It has been suggested by proponents of service based architectures that the current Transmission Wrapper contains classes and attributes which are not related to Transmission. Possible candidates include:

• versionCode: The version code applies to the entire interaction, but given that the Transmission Wrapper is relatively small in scope it is mostly related to that which is transmitted.
• interactionId: Effectively defines the structure of that which is transported. Currently the only need to be aware of the interactionId at the Transmission level is to distinguish between a Message and a Batch.
• profileId: Profiles apply to the entire interaction, but given that the Transmission Wrapper is relatively small in scope it is mostly related to that which is transmitted.
• processingCode: Application-level parameter for use by a receiving application.
• processingModeCode: Application-level parameter for use by a receiving application.
• acceptAckCode: Application-level parameter for use by a receiving Message Adapter. Accept-level acks are about syntax/conformance, not about Transport.
• responseModeCode: Application-level parameter for use by a receiving application.
• referenceControlId (Batch): used for application-level duplicate checking
• name (Batch): Free text, application level
• batchComment (Batch): Free text, application level
• transmissionQuantity (Batch): Application-level count of the number of messages in a batch
• batchTotalNumber (Batch): Application-level checksum

Manifest

• The English NHS has defined a requirement to add Manifest Items for each Message contained in a batch (e.g. InteractionId, Message.id).
• Others (Mead Walker, Robert Hausam) have come forward with use-cases for the inclusion of a BatchTypeCode and time-interval of a Batch (e.g. this is a batch containing all invoices from 20050101 up to 20050201)

This raises the question whether we can define a very lean Transmission Wrapper that only contains Transmission oriented issues (and which can be omitted in a sevrice oriented architecture), and create a "Manifest" (or: "Bill of Lading") class which contains generic versions of the above attributes.

Control Act Wrapper

The Control Act Wrapper plays an important part in this. It represents the Trigger Event of the transmission. Therefore it would make sense to include all things related to the expected behaviour of a receiver of this trigger event at this level, including:

• explicitely identified receiver responsibilities
• processingCode: Application-level parameter for use by a receiving application.
• processingModeCode: Application-level parameter for use by a receiving application.
• acceptAckCode: Application-level parameter for use by a receiving Message Adapter. Accept-level acks are about syntax/conformance, not about Transport.
• responseModeCode: Application-level parameter for use by a receiving application.

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)