Draft Standard for Trial Use Notice

Publication of this draft standard for trial use and comment has been approved by Health Level Seven International (HL7). This draft standard is not an accredited American National Standard. The comment period for use of this draft standard shall end 24 months from the date of publication. Suggestions for revision should be submitted at http://www.hl7.org/dstucomments/index.cfm.

Following this 24 month evaluation period, this draft standard, revised as necessary, will be submitted to a normative ballot in preparation for approval by ANSI as an American National Standard. Implementations of this draft standard shall be viable throughout the normative ballot process and for up to six months after publication of the relevant normative standard.

Preface

There are instances when it is convenient to transfer a batch of HL7 interactions. A common example is the transmission of a batch of financial posting detail transactions sent from an ancillary to a financial system.

Although a batch will usually consist of a single type of interaction, there is nothing in the definition that restricts a batch to only one interaction type. It should be noted that the "unit of work" of HL7 is the interaction, not the batch. Thus, it is possible that some interactions contained within the batch may be successfully processed, while others are not. Batching a mechanism that may be used ONLY as a transmission grouper, it does not group interactions for transactional purposes. Receivers of a batch should remove the batch wrapper and process the interaction contained therein as if they were received individually. Interactions contained in a batch that are addressed not to the receiver, but to another receiver SHALL be processed the same way as interactions not contained in a batch that were not addressed to the receiver.

A batch may contain zero or more interactions. (There are cases in which a system is expected to send a batch at a specific repeating point in time, e.g., 12 midnight every day. In such cases, a batch with no content is reasonable.) If an application has been configured to send a batch of financial charge interactions every morning at four, and on a particular day there is nothing to be charged, then one could send an empty batch to inform the receiving application that there was 'nothing to report'. The support of batches and the contained interactions may be described in the conformance profile of an application. Some users may wish to support batch for all interactions they support, while others may wish to be more selective.

Please note that a message based interaction (i.e. not batched) shall never result in the receiver using a batch wrapper for any of the related responses, unless the use of the batch wrapper was explicitly requested by the sender. For example, the HL7 query allows for an explicit request for a batch response by using the value 'B' in the QueryByParameter.responseModalityCode attribute of the query message.

Responding to a batch

The receiver responsibilities of an application which receives a batch are:

1. To check for the integrity of the batch i.e. perform the same level of validation one would typically use for an Accept Acknowledgement; to send 0 or 1 Accept Acknowledgement (a.k.a. Accept-level Acknowledgement).
2. To execute the receiver responsibilities related to individual interactions contained within the batch.

Application Responses

The way in which a receiver should deliver its receiver responsibilities, i.e. the expected dynamic behavior of the receiving application with regard to application responses, is determined by the Response Mode of the batch. The Response Mode of the batch is contained in the Batch.responseModeCode attribute.

The Response Mode of the batch can have one of the following values:

• Immediate. The receiver is required to assume that the sender is blocking and behave appropriately by sending immediate responses to the interactions contained in the batch.
• Deferred. The receiver may respond to interactions contained in the batch in a non-immediate manner.
• Queue. The receiver may create responses in a non-immediate manner and shall keep any application responses in a queue until such a point in time the queue is polled.

The Response Mode as contained in the batch overrules the Response Mode as defined by individual interactions contained in the batch. Example: if the Response Mode specified at the batch level equals "Queue", then all messages contained in the batch shall be processed as if their Response Mode was set to "Queue" as well.

Context Conduction of Wrappers

The sender and receiver associations associated with the Message class are almost always equal to the sender and receiver associated with the Batch class of the Batch the message interactions are contained in. The RIM allows for automatic conduction of these associations from Batch to Message.

However, the sender and receiver are mandatory in the current message-level Transmission Wrapper which leads to duplication of data. This is a known issue which will be addressed in a future release of this domain.

Note: the current tooling doesn't support Batch Wrappers. A schema for the XML ITS will have to be manually created based on the schema for the Message Wrapper. The root element has to be renamed to Batch, additional attributes of the Batch class have to be added to the schema, and subject should be replaced with an xs:any declaration. The reader should see http://wiki.hl7.org/index.php?title=Batch_Wrapper_Schema for a detailed description.