Final Processing Steps

Mirth® Connect by NextGen Healthcare User Guide

Destination Chains

Destination Chains Destination Chains A channel's destinations are grouped into one or more destination chains. Each destination chain processes simultaneously with respect to each other, however in any particular chain, a message will flow through each destination in order. It looks something like this: In the above example, there are 5 total destinations. However Destination 3 does not wait on Destination 2, so it marks the beginning of a new chain. If each destination takes 1 second to process, then the overall time it takes the message to process through the channel will not be 5 seconds, but rather 3 seconds. When flowing through the destination connectors, a message will take only as long as the longest destination chain. Parent topic: The Message Processing Lifecycle

Mirth® Connect by NextGen Healthcare User Guide

Source Processing Steps

A message or stream of data is received by the source connector. The batch processor decides whether to split the message into multiple messages. If so, the below steps are repeated for each message returned by the batch processor. The attachment handler extracts and/or stores all attachment data. The post-attachment-handler content is stored as raw data. The content runs through the preprocessor script and is stored as processed raw data. The content is serialized (converted) to the internal representation of the inbound data type (e.g. XML). The content runs through the filter, and the message is either accepted or filtered. If the message gets filtered, flow stops here and jumps down to the Final Processing Steps. The content runs through the transformer, where it may be modified. The post-transformer content is stored as the transformed data. The content is deserialized (converted) from the outbound data type's internal representation (e.g. XML) into the actual outbound format (HL7

Mirth® Connect by NextGen Healthcare User Guide

Destination Processing Steps

Note: These steps are repeated for each destination connector that a message flows through. The encoded content from the source connector is used by each destination connector as its raw data. The content is serialized (converted) to the internal representation of the inbound data type (e.g. XML). The content runs through the filter, and the message is either accepted or filtered. If the message gets filtered, flow stops for the current destination here. If there are additional destinations in the current chain, these steps are repeated for the next destination. Otherwise, assuming all other destination chains have finished, flow jumps down to the Final Processing Steps. The content runs through the transformer, where it may be modified. The post-transformer content is stored as the transformed data. The content is deserialized (converted) from the outbound data type's internal representation (e.g. XML) into the actual outbound format (HL7, EDI, etc.). The content is stored as encoded

Mirth® Connect by NextGen Healthcare User Guide

The Message Processing Lifecycle

As explained in the About Message Data section, each source and destination connector has various versions of the message data as it flows through the channel. The raw inbound message enters Mirth® Connect, is received by the source connector, is filtered and transformed, then encoded and sent to the destination connector. From the source connector, the raw inbound message can be passed through multiple destination connectors where it can again be influenced by filters and transformers before it is processed, encoded, and sent on. Source Processing Steps Destination Processing Steps Final Processing Steps Destination Chains Parent topic: The Fundamentals of Mirth Connect

Mirth® Connect by NextGen Healthcare User Guide

Response Map

This map is isolated to the current message as it processes through a channel. Unlike the channel map, this one is specifically used for storing Response objects. When a destination finishes processing, its Response will automatically be stored in the response map. Subsequent destinations and the Postprocessor Script will have access to these values. The source connector can also use values stored in the response map to send responses back to the originating system (set in the Source Settings) . Get response map value: var value = responseMap.get('key'); var value = $r('key'); Put response map value: responseMap.put('key', 'value'); $r('key', 'value'); Parent topic: Variable Maps

Mirth® Connect by NextGen Healthcare User Guide

Edit Global Scripts

Select a script type from the drop-down menu and edit the script in the text area below. There is also a Reference List to the right for easy drag-and-drop of common helper methods / code templates. The following global script types can be edited: Deploy Script: This script executes once whenever any channel or set of channels deploys. You have access to the global / configuration maps here. Typically this script is used to perform a one-time operation, such as loading a properties file from disk, or instantiate a database connection. Undeploy Script: This script executes once whenever any channel or set of channels is undeployed. You have access to the global / configuration maps here. Typically this script is used to cleanup any data created from the deploy script, such as closing a database connection. Preprocessor Script: This script applies across all channels, and executes once for every message, after the attachment handler has run but before the message reaches the source filte

Final Processing Steps

Recommendations

Destination Chains

Source Processing Steps

Destination Processing Steps

The Message Processing Lifecycle

Response Map

Edit Global Scripts

Final Processing Steps

Destination Chains

Source Processing Steps

Destination Processing Steps

The Message Processing Lifecycle

Response Map

Edit Global Scripts