General Settings¶

Channel Name¶

The name associated with the channel is recorded here. The channel name should be unique within the zone.

Naming convention

A consistent naming convention makes channels easier to find in lists, search results, and log entries. The clearest pattern is arrow notation (Sender >> Receiver) for example CPSI >> GE Lab or Epic >> Allscripts. The arrow points from the sending system to the receiving system, so the channel name alone tells a reader what the channel is for with no ambiguity.

Useful variants:

Message type in parentheses to show what the channel carries, such as EMR >> C-PACS (ORM) for a single message type, or EMR (ADT) >> LAB (ORU) when the channel converts one HL7 message type into another. Short single-letter codes also work when a project has a documented shorthand, e.g. eCW(a) > PS+PACS+VNA where (a) is ADT, (o) is orders, (r) is radiology, (l) is labs, and combinations like (rl) indicate both.
+ to join multiple senders or receivers when one channel handles several systems on the same side, as in eCW(o) > PS+PACS+VNA (one source feeding three destinations) or PS+PACS (rl) > PACS+eCW (two sources fanning into two destinations).
The word to in place of >> when arrow characters are awkward in a particular context (commonly used for IIS channels), e.g. AL: ORU to VXU Channel (AL-IIS).

Some teams use Source-Direction-Destination (e.g. Epic-Inbound-Allscripts), but the Inbound / Outbound term is ambiguous in conversations involving multiple vendors. "Inbound" is read differently depending on whether the listener works on Epic, Allscripts, or QIE itself. Arrow notation avoids this entirely.

Whichever convention you pick, use it consistently across the zone.

Channel ID¶

This is the database id for the given channel. This id can be used for monitoring a channel with an External Monitoring system like Nagios. An example URL to monitor a channel would be:

http://qieServer:port/channelStatus?channelId={channelId}

See External Status Endpoints for the full response format, the other available checks, and the network access guidance that applies to them.

Channel Enabled¶

Checkbox that controls whether the channel can run. A disabled channel cannot be started and is hidden from the Zone Status window (it is still visible on the Channels page). Disable a channel to take it out of service without deleting it, for example, when decommissioning an interface, holding a partially-built channel for later work, or preventing accidental starts. Re-enable from the Properties dialog or the Enable item on the channel context menu.

Process messages in order received¶

When this option is selected, messages are processed one at a time, in the order that they are received by the channel.

Limit message processing to xx at a time¶

This setting allows the user to specify the number of messages the channel processes simultaneously. It is limited to the number of processing threads available to the channel (50% of total processing threads). A warning message displays at the bottom of the screen if the number of threads specified here exceed the total allowed.

Purge Messages¶

The 'Purge Messages' button allows system administrators to purge messages from the QIE database at any time rather than waiting for the nightly purge routine to run. This option opens the 'Purge Messages' dialog for this channel only. See Purge Messages Dialog for more information.

Message State Persistence Level¶

The message state persistence level controls how aggressively QIE persists (commits to the database) the state of each message as it is processed through the channel. A higher persistence level setting results in more frequent database updates of message state, but slower overall performance. QIE supports the following message state persistence levels:

Default: Level 1.

Persistence Level	Description
Level 0	Messages are *NOT* persisted to the database. Use this option only if processing speed is critical and message recovery is not needed (for example, processing large batch files that can easily be reprocessed if the channel stops unexpectedly or encounters critical errors). Speed: Very Fast Persistence: None
Level 1	Messages are persisted as they enter the inbound queue and as they are completed. Any messages in the processing or outbound queues when the channel is stopped are restored to the inbound queue when the channel is restarted. Speed: Fast Persistence: Inbound, Completed
Level 2	Messages are persisted as they enter the inbound queue, the outbound queue, and as they are completed. Any messages in the processing queue when the channel is stopped are restored to the inbound queue when the channel is restarted. Speed: Medium Persistence: Inbound, Outbound, Completed
Level 3	Messages are persisted at every step, including each transition from one channel node to the next. Speed: Reduced Persistence: Inbound, Processing, Outbound, Completed

Note

Errors are always landed in the Error Queue, which is persisted regardless of the channel's persistence level, including at Level 0.

Save Message Cache For Each Message¶

Checkbox. When unchecked (the default), message cache values set during processing, meaning values written by messageCache.setValue(...) in scripts, are discarded once the message completes and are not stored in the database. Check this box to persist those values alongside the message record.

Enable this when:

You want to retain cache values for auditing, debugging, or reporting on completed messages.
A downstream script needs to look up previously-processed messages by a cached value, using qie.findPreviousMessage(...). The function requires persisted message cache and throws an error if the channel is not configured for it.

Persisting message cache writes one extra row per cache entry per message, which increases database size and write load. Enable only on channels that actually need the retained values.

Override Message Retention Policy/Override Error Retention Policy¶

Check these boxes to override the message or error retention policies for this channel and enter the number of days in the Msg Retention and/or Error Retention fields.

Upon completion, delete data from¶

Source Message¶

When this box is checked, the source message is not retained in message history after being successfully processed through the channel. This option can be used for channels that process large messages to prevent the database from growing very large.

Message Result¶

When this box is checked, the message result is not retained in message history after being successfully processed through the channel. This option can be used for channels that process large messages to prevent the database from growing very large.

Response sent¶

When this box is checked, the responses sent by QIE to a sending system is not retained in message history after being successfully processed through the channel.

Response(s) received¶

When this box is checked, the responses received by QIE from a receiving system is not retained in message history after being successfully processed through the channel.