This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Open Transmission Wrapper Issues"

From HL7Wiki
Jump to navigation Jump to search
(→‎Manifest: reorg, add suggested resolution for manifest and attentionLine)
(create MCCI batch issues section)
Line 3: Line 3:
 
== Known Issues ==
 
== Known Issues ==
  
MCCI:
+
=== MCCI Tramsmission/Message ===
 
*Open attachmentText issues, need further clarification from Charlie McKay. MCCI line-items 102.
 
*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
 
*Guidance as to XPath expression for identifying where syntax errors have occurred - Lloyd McKenzie, Alexander Henket
Line 13: Line 13:
 
**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.
 
**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).  
 
**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.
 
*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)
 
*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. If we don’t do this in v3, need to document why.  
 
**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. If we don’t do this in v3, need to document why.  
 
*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.  
 
*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.
 
*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.
 
*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."
 
*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."
 +
*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).
 +
 +
=== MCCI Batch ===
 +
 +
Suggested way of dealing with some (non-chunking related) batch-related use-cases:
 +
#Associate 0..* a new Manifest class, with a structure for carrying a set of values ''relating to a specific message payload item.'' The value should however not affect the semantic interpretation of the clinical payload. - 20050109: Phoenix WGM: Comittee is inclined to use a Manifest key-value pair class to Batch.
 +
#Add attributes to the Batch where the use-case is Universal in nature.
 +
#Change RIM description of AttentionLine so it can be used to convey (realm specific) meta-information related to the batch as a whole, as long as such content has no impact on the semantic interpretation of the contents of the Batch.
 +
 +
 +
*The English NHS has defined a requirement to add Manifest Items for each Message contained in a batch (e.g. InteractionId, Message.id). :a structure for carrying a set of values relating to a specific message payload item. Typically this class will be repeated for each payload instance in the batch. Currently, if this class is used, it shall carry the (e.g. payload id, artefact id and / or sequence number of the item).
 +
*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)
 +
*OriginalRequestRef: (reponse only) id of the original request that triggered this response (this could be information could be conveyed by a separate ebXML-style Conversation Id) - this is the queryId of the original query.
 +
*BatchSequenceNumber (see "chunking" topic elsewhere in this list): the ordinal number of this batch in a sequence of batches This is used by the sender to sequence multiple batch response messages that are derived from a single batch request (as might result from imposing limits on batch size). This allows identification of missing or out of sequence batch response messages.
 +
*AttentionLine: IDs of interactions contained in batch ? (Manifest).  MCCI line-item 172,173.
 
*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.
 
*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 SIG before sending in the proposal.
 
*Batch: RIM proposal to add ProfileID attribute to the Batch class. 2005-08-08 INM agrees, confer with Conformance SIG 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:
+
*Batch: add Attachment class to Batch models.
 +
*Batch acknowledgement mechanism, open MCCI line-items 68, 69. Batch responseMode attribute, open MCCI line-item 146.
 +
 
 +
 
 +
=== ATS ===
 
*[[Message.id]] "sameness" discussion after transformation by a Gateway
 
*[[Message.id]] "sameness" discussion after transformation by a Gateway
 
*Translations: add "derived from .. ID" attribute ?, much like acknowledgementOf. See also MCCI line-item 157.
 
*Translations: add "derived from .. ID" attribute ?, much like acknowledgementOf. See also MCCI line-item 157.
Line 48: Line 63:
 
*transmissionQuantity (Batch): Application-level count of the number of messages in a batch
 
*transmissionQuantity (Batch): Application-level count of the number of messages in a batch
 
*batchTotalNumber (Batch): Application-level checksum
 
*batchTotalNumber (Batch): Application-level checksum
 
=== Manifest ===
 
 
Suggested way of dealing with some (non-chunking related) batch-related use-cases:
 
#Associate 0..* a new Manifest class, with a structure for carrying a set of values ''relating to a specific message payload item.'' The value should however not affect the semantic interpretation of the clinical payload. - 20050109: Phoenix WGM: Comittee is inclined to use a Manifest key-value pair class to Batch.
 
#Add attributes to the Batch where the use-case is Universal in nature.
 
#Change RIM description of AttentionLine so it can be used to convey (realm specific) meta-information related to the batch as a whole, as long as such content has no impact on the semantic interpretation of the contents of the Batch.
 
 
 
*The English NHS has defined a requirement to add Manifest Items for each Message contained in a batch (e.g. InteractionId, Message.id). :a structure for carrying a set of values relating to a specific message payload item. Typically this class will be repeated for each payload instance in the batch. Currently, if this class is used, it shall carry the (e.g. payload id, artefact id and / or sequence number of the item).
 
*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)
 
*OriginalRequestRef: (reponse only) id of the original request that triggered this response (this could be information could be conveyed by a separate ebXML-style Conversation Id) - this is the queryId of the original query.
 
*BatchSequenceNumber (see "chunking" topic elsewhere in this list): the ordinal number of this batch in a sequence of batches This is used by the sender to sequence multiple batch response messages that are derived from a single batch request (as might result from imposing limits on batch size). This allows identification of missing or out of sequence batch response messages.
 
 
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 service oriented architecture), and create a "Manifest" (or: "Bill of Lading") class which contains generic versions of the above attributes.
 
  
 
=== Control Act Wrapper ===
 
=== Control Act Wrapper ===

Revision as of 13:27, 13 January 2006

Back to Infrastructure and Messaging TC

Known Issues

MCCI Tramsmission/Message

  • 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).
  • Principles of Interaction Pattern vs. Transmission Pattern. See also open MCCI line-item 55.
  • 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. If we don’t do this in v3, need to document why.
  • 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.
  • 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."
  • 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).

MCCI Batch

Suggested way of dealing with some (non-chunking related) batch-related use-cases:

  1. Associate 0..* a new Manifest class, with a structure for carrying a set of values relating to a specific message payload item. The value should however not affect the semantic interpretation of the clinical payload. - 20050109: Phoenix WGM: Comittee is inclined to use a Manifest key-value pair class to Batch.
  2. Add attributes to the Batch where the use-case is Universal in nature.
  3. Change RIM description of AttentionLine so it can be used to convey (realm specific) meta-information related to the batch as a whole, as long as such content has no impact on the semantic interpretation of the contents of the Batch.


  • The English NHS has defined a requirement to add Manifest Items for each Message contained in a batch (e.g. InteractionId, Message.id). :a structure for carrying a set of values relating to a specific message payload item. Typically this class will be repeated for each payload instance in the batch. Currently, if this class is used, it shall carry the (e.g. payload id, artefact id and / or sequence number of the item).
  • 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)
  • OriginalRequestRef: (reponse only) id of the original request that triggered this response (this could be information could be conveyed by a separate ebXML-style Conversation Id) - this is the queryId of the original query.
  • BatchSequenceNumber (see "chunking" topic elsewhere in this list): the ordinal number of this batch in a sequence of batches This is used by the sender to sequence multiple batch response messages that are derived from a single batch request (as might result from imposing limits on batch size). This allows identification of missing or out of sequence batch response messages.
  • AttentionLine: IDs of interactions contained in batch ? (Manifest). MCCI line-item 172,173.
  • 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 SIG before sending in the proposal.
  • Batch: add Attachment class to Batch models.
  • Batch acknowledgement mechanism, open MCCI line-items 68, 69. Batch responseMode attribute, open MCCI line-item 146.


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

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)