Open Transmission Wrapper Issues

Back to Infrastructure and Messaging TC

Known Issues

MCCI:

• Open attachmentText issues, need further clarification from Charlie McKay. MCCI line-items 102.
• 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.
  • 20050109 Phoenix WGM: Discussion: do we want HL7 to prescribe the way to deal with it ? No one size fits all solution. Does the way to deal with duplicates depend on message infrastructure used ? – No, that just affects the amount of lost messages. What is a valid reason to resend with the same message.id ? – should one always use a new Message.id on a resend ? Do we need a “this is a duplicate of message x” attribute ? Create a list of pro and cons of various approaches. Replay messages obviously contains duplicate message.ids. Detection of duplicate order (via business ID) is different from a duplicate Transmission (message.id). From sender perspective: no application response [although one was expected], what should a sender do ? (action item: Rene to create Wiki paper).
• 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)
  • 20050111 WGM: Chunking in principe occurs at transport level (re-assemble at receiving end), or at application level ? NHS uses 1 query, followed by a series ofd chunked responses. Bandwith problem that can be solved by the standard. Add max byte size in query ? Is ITS Dependent, but so what ? problematic with ITS transformation. Paul Biron: may be use-cases where one wants to explicitly convey that the response needs to be according to another ITS. If we don’t do this in v3, need to document why.
• 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.
• 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. PIC Issue ? Does this depend on the level of the ballot being commented ? Risk that the cycle goes on forever. Acceptable to make a use-case suggestion (for things that are missing, use-cases that are not covered) as an affirmative line-item. Move to PIC (Action item for Joann).

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.

20050109: Phoenix WGM: Comittee is inclined to use a Manifest key-value pair class to Batch. Value should however not affect the semantic interpretation of the clinical payload.

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)