Open Transmission Wrapper Issues

Back to Infrastructure and Messaging TC

Known Issues

MCCI:

• Message.profileId is a LIST, not a SET. MCCI line item 131.
• Change Message.versionCode and Batch.versionCode to be mandatory attributes. MCCI line-item 156.
• (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." - open MCCI line-item 168.
• Open attachmentText issues, need further clarification from Charlie McKay. MCCI line-items 102.
• Open non-controversial MCCI line items 150, 154 and 155.
• Procedural: can a new use-case (although in scope of the domain) be brought forward in the form of a line-item, and be grounds for a negative line-item ? Or should a proposal be brought forward ? - MCCI line item 171.
• Guidance as to XPath expression for identifying where syntax errors have occurred - Lloyd McKenzie, Alexander Henket
• 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 ?
  • Simply ignoring a duplicate won't work at the HL7 layer, for we have a sending system that may be waiting for a response. For the Dutch implementation guide we wrote some quite complicated rules:
    • If the duplicate interaction has no receiver responsibilities, ignore it at the receivers end.
    • If the duplicate interaction has receiver responsibilities, then you need to respond with a duplicate of the response interaction as has been sent by the receiver when it originally received the interaction.
  • In order to detect duplicates and be able to send duplicate responses we now require that all systems have a 48-hour log of all messages sent/received. Maybe we need a shorter timeframe than 48 hours, time will tell.
• Batch: add Attachment class to Batch models.
• Principles of Interaction Pattern vs. Transmission Pattern. See also open MCCI line-item 55.
• AttentionLine: IDs of interactions contained in batch ? (Manifest). See below for a discussion of Manifest items. MCCI line-item 172,173.
• Is there a need for a general mechanism for chunking large messages as well as batches. (UK: max 25Mb size of individual transactions)
• Batch acknowledgement mechanism, open MCCI line-items 68, 69. Batch respopnseMode attribute, open MCCI line-item 146.
• Adressing: device.id vs. device.telecom. MCCI line item 97.
• AcknowledgementDetail.typeCode is optional - should this be mandatory instead ? Contains E, W, or I, a categorization of the acknowledgement code/text.
• 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."
• 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.
• 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.

ATS:

• Message.id "sameness" discussion after transformation by a Gateway
• Translations: add "derived from .. ID" attribute ?, much like acknowledgementOf. See also MCCI line-item 157.

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)