Batch Topic DSTU R1 Issues

This page contains approved changes to the MCCI Batch topic. Those issues that will cause backwards compatibility issues if they're not included in the DSTU have to be included in the upcoming Release.

Open Issues

• (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) 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.

Decisions

• Harmonization: Transmission Inheritance (approved, basis for new R-MIMs in the DSTU)
• Harmonization: Batch.contentProcessingMode (has to be added in the DSTU)
• Harmonization: add Attachment to Batch (optional)
• Harmonization: enable Batch.profileId attribute (optional) (Message.profileId is LIST<II>, not SET)
• Harmonization: add priorTransmission to support Transmission Sequencing (approved, used for sequencing of batch chunks)
• Transmission Addressing (include?)
• Sequence Number Protocol (include)
• Transmission.id (include wording in DSTU)
• Error Location (include)
• Minimalistic full-unheritance R-MIM as per the NHS proposal prsented THU Q4/Sept2006 WGM.

From the former "Open Transmission Wrapper Issues" page:

• (closed, CfH, Sept2006) Requirement for long term planning: InM to provide a solution to batch messaging that does not require message headers to be unnecessarily repeated (taking up a lot of message space and network bandwidth) and at the same time provides the mechanism to respond to individual detected issues.
  • 20070109 WGM. Closed, covered by new Behavioral Contract Wrapper.
• (closed) 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
  • 20070109 WGM. Batch has been redefined to be a grouper for transmission purposes only. **Either payloads of the same type can be sent in one Message interaction. Payloads of different types can be grouped under the new Behavioral Contract Class.
• (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.

Form the INM Transmission and Transport Action Items list: item 958, 2016, 2018(implicit in batch)

From the MCCI Batch ballot reconciliation (MCCI R2 C1):

• Mead Walker/Robert Hausam have come forward with use-cases (line item 172,173) 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 (during the January2006 WGM??) to include a solution for this use case in the next publication of the MCCI domain. This has been resolved (??) by the very fact that at a later point in time (the May2006 out-of-cycle) we defined a Batch wrapper to be "only a grouping of interactions for transmission purposes".
• 170: Motion to find persuasive, and to add a section to the Batch topic to clarify the use of "duplicate" classes and attributes in both wrappers.
• 168: INM will put forward a harmonization proposal to explicitely state in the RIM that there is context conduction between transmission wrappers. MCCI material should point out what consequences this has for senders and receivers of batches
• 165: add rec resp to par 4.6.3, 164: change name of 4.6.3 artefact to include the word "batch"
• 162: par 4.4.2 this R-MIM is used both for (1) batches of accept acknowledgements, (2) batches of application responses. The only difference between this R-MIM and the Batch R-MIM is the fact that it contains a mandatory Acknowledgement class. Wording similar to this response will be added to the R-MIM description.
• 159: Motion Rene/Sandy to find persuasive. There was a use-case for this field (batchTotalNumber) in HL7 v2 - but there probably isn't one today. It will be removed from the R-MIM and D-MIM and be added again should someone come forward with a use-case.
• 158: remove transmissionQuantity
• 157: remove referenceControlId
• 156: make versionCode mandatory
• 143: "During the recent INM out of cycle meeting the nature of Batches was changed, which amongst other things means that a Batch (as a whole) can only be accept-level NAKed (and not ACKed) . The concept of a Batch of accept-level acks will be removed from the standard."
• Other minor typo/editorial corrections, see reconcliliation package for comments related to ection 4.x