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

Open Transmission Wrapper Issues

From HL7Wiki
Jump to navigation Jump to search

Back to Infrastructure and Messaging TC

Known Issues

MCCI Transmission/Message

  • (major) Requirement that transports be reliable, set acceptActCode to ER
  • (medium) 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 ? See Duplicate Transmissions for a discussion.
  • (medium) Is there a need for a general mechanism for chunking large messages as well as batches. (UK: max 25Mb size of individual transactions)
  • (medium) J Venturello: Being acceptAckCode limited to ER in MCCI R2, then how can we use the sequence number protocol?
    • (Grahame)I don't believe that there's any use case for the sequence number protocol now that we've done what we've done with the acknowledgement paradigm. I think that we should deprecate the concept.
    • (Rene) The underlying messaging infrastructure may provide reliable delivery, but it may not provide in-order delivery.
    • From: Test Cases (Lloyd) Suggest that the discussion of sequence number indicate that it only applies where either acceptAckCode is ‘AL’ (Always) or where acceptAckCode is ‘NE’, responseMode is ‘I’ (Immediate) and the outgoing interaction’s has receiver responsibilities that all have associated interactions. Rationale: The sequence # protocol depends on their being an immediate response to every outgoing message. These identified constraints are the only two mechanisms which ensure that such a combination will exist.
  • (medium) 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.
  • (minor) Currently one would be allowed to specify a different "respondTo" in a continuation query transmission than was present in the initial query. Is this desirable, or do we need some constraints to be put in place? (Rene) personally I think this is not a big issue, and no constraints are necessary.
  • (minor) Add guidance to MCCI and MCAI (DetectedIssue) as to XPath expression for identifying where syntax errors have occurred - Lloyd McKenzie, Alexander Henket, proposed wording 20050823:
    • Location will identify the specific location within the message using a simplified xPath syntax. No axis prefixes may be specified. The default 'child' axis will always be assumed but not specified. A predicate will always be specified and will be limited to indicating the relative repetition of the element. All attributes and associations will be treated as elements, including 'structural' attributes (meaning that the xPath will not necessarily be directly valid when applied against the standard XML ITS. For example: /PORX_IN123456UV01[1]/controlActProcess[1]/authorOrPerformer[2]/typeCode[1]
      To be more explicit, the regex syntax for the xPath is restricted to: (/[a-z,A-Z,0-9,_]+\[\d+\])+
      For AcknowledgementDetail, the root node will be assumed to be the Transmission class for the Transmission being acknowledged.
      For DetectedIssue, the root node will be assumed to be the ControlAct for the interaction being responded to.
  • (minor) AcknowledgementDetail.typeCode is optional - should this be mandatory instead ? Contains E, W, or I, a categorization of the acknowledgement code/text.
  • (minor) 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."
  • (medium, proposal made) 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. See Harmonization: Description of AttentionLine (For July 2006).
  • (closed, for next release) Editorial: MCCI artefacts labeled as "deprecated" should probably be labeled "for backwards compatibility only". Once they have had that status for 2 normative releases of v3, their status will change to "deprecated".
  • (MnM will talk about interaction patterns) Principles of Interaction Pattern vs. Transmission Pattern.

MCCI Batch

Batch class

  • (requires revisit of a line item) Mead Walker/Robert Hausam have come forward with a use-case for the inclusion of a BatchTypeCode. Batch.name is of datatype SC, so a code can be supplied. Only open issue is if we should rename the attribute, which has RIM backwards compatibility issues associated with it. MCCI line-item 171
  • (medium) Consider 1 Batch resulting in exactly 1 batch with application responses. See Batch Transmission Pattern for details, we may want to introduce 2 new attributes.
  • (MEDIUM) The Response Mode as contained in the batch overrules the Response Mode as defined by individual interactions contained in the batch. Do we really want to do this? I can understand sometimes wanting to override it ... but I can also see cases where one would want the Response Mode of the individual interactions to be honored. Maybe the vocab domain could be extended to include an 'honor individual interaction response modes' term?
    • delete responseModeCode from batch
  • (medium, depends on batch as a unit-of-processing discussion) 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.
    • (Rene) QueryId is not a transmission-level identifier, but links an Interaction Pattern. Batch is a Transmission wrapper, business process identifiers (like queryId) don't belong in a Transmission wrapper. At most it could be included in AttentionLine if sender and receiver have create a site-specific agreement to do so.
  • (medium) Committee intends to support the concept of batch chunking and accepts a work item to do this. (Rene Spronk/John Arnett 14-0-0 Jan06 WGM THU Q4)
    • Discussion: One consequence: if you allow for batch chunking then the HL7 dynamic model does not work anymore. One Transmission/Interaction may result in multiple (chunk-)interactions.
    • Batch chunking in response to a query works just fine, because the Query Transmission Pattern supports a throttling mechanism. If the Bolus query mechanism is used we have the same dynamic model issues as in a batch (-chunks) notification scenario.
    • (Action item 978, Sept05) Work to add a new batch group class to the batch transmission wrapper. The new class will contain attributes such as batch ID. A new sequence number needs to be added to the current batch class as well. New dynamic models, interactions, etc. need to be documented.
    • add BatchSequenceNumber attribute: 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.
  • (medium) There is a gateway scenario in the netherlands, where the gateway routes (clones of) one inbound query to multiple systems, and collects all of the responses in 1 batch, which is then returned to the original querying party. In the situation were 2 or more applications return an AE in their query response, the batch will contain multiple interactions containing an AE. (e.g. AA AA AA AE AA AA AA AE AA AA) If the batchprocession is serialized, then the first AE will cause the further processing of the batch to be aborted, resulting in the remaining interactions not being processed. Current workaround is to "sort" the AE's to be at the end of the batch.
  • (medium) Batch acknowledgement mechanism, open MCCI line-items 68, 69. Batch responseMode attribute, open MCCI line-item 146.
  • (minor) Mead Walker/Robert Hausam have come forward with use-cases for the inclusion of a time-interval of a Batch (e.g. this is a batch containing all invoices from 20050101 up to 20050201) - The comittee has commited itself to include a solution for this use case in the next publication of the MCCI domain.
  • 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. 20060305 Conformance does not indicate disagreement on their e-mail list.
  • Batch: add Attachment class to Batch models, see Harmonization: add Attachment to Batch. This proposal is up for discussion during the March 2006 Harmonization meeting.
  • 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 a ManifestItem class for each Message contained in a batch: a structure for carrying a set of values relating to a specific payload item (mostly: a message). Typically this class will be repeated for each payload instance in the batch. 20050109: Phoenix WGM: Comittee is inclined to use a Manifest key-value pair class to Batch.
  • Add an optional content processingMode attribute to the batch class to indicate the type of content processing that the receiver of the batch is expected to undertake, i.e., sequential or parallel. Default value is sequential. (John Arnett/Mark Tucker 14-0-0 Jan06 WGM THU Q4). Create harmonization proposal to add this attribute.
  • Child transmissions inherit all elements of the Parent transmission unless explicitly overridden, such as sender, receiver, attachments, transmission time, etc. This is applicable to (but not limited to) Messages [interactions with a Message-class entry-point] contained in a Batch [interactions with a Batch-class entry-point]. The RIM and the MCCI domain will be updated to reflect this. (motion Jan06 WGM TUE Q1)
  • (issue resolved, needs to be documented in next release) It is the intent of the committee not to require an instance of the reference control id attribute in the initial batch transmission. (John Arnett / Tony Davey 11–0-3 Jan06 WGM THU Q4)
  • (issue resolved, needs documentation) There is an element of tension between the statement that a Batch wrapper is "only a grouping of interactions for transmission purposes" and the presence of the batch.referenceControlId and batch.name. These seem to hint that a Batch is a "unit of processing". Well: is it, or isn't it?
    • INM out of cycle: Transmission Wrapper will be a thin grouper of transmissions only. NHS use-case for syncing databases via message-batches will be discussed separately.

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)

Retrieved from "https://wiki.hl7.org/w/index.php?title=Open_Transmission_Wrapper_Issues&oldid=3333"