Mirth Connect 3.4 introduces dozens of new features, improvements, and bug fixes. Channel groups and dependencies add an entirely new level to managing your interfaces. It also features a new and easy to use REST API, HTTP authentication settings, configurable multi-threaded channels, and many other features designed to optimize interface performance and management.

• Channel Groups
• Channel Dependencies
• Mirth Connect REST API
• Parallel Message Processing
• HTTP Authentication Settings

You can find a list of issues completed for this release here.

Channel groups add an entirely new level to channel management. Organizing channels under distinct groups allows you to more quickly find the channels you're looking for. You can also perform certain operations across an entire group at once!

• Use groups in tandem with channel tags to allow organization from multiple angles. Each channel is under one group, but tags can still apply to multiple channels at once, even across different groups.
• Quickly assign channels to a group with multi-selection and drag-and-drop capabilities.
• Export a group as a single, self-contained file with all channels within.
• Select a group and quickly perform actions across all channels underneath. Enable/disable, deploy/undeploy, start/stop, etc. All actions that apply to multiple channels on the dashboard also apply to group selections!
• On both the Dashboard and Channels views, switch between the groups and channels table views.

Channels can now be made dependent on each other! This means that you can ensure that certain channels get deployed before others, and messages flowing from upstream to downstream channels will never error out.

• Management UI shows you what channels the current one is directly dependent on, and what channels are directly dependent on it! The tree will also show indirect dependencies, in case you have multiple channels dependent on each other in a chain.
• On server startup, all enabled channels in the same dependency chain will automatically deploy in the correct order, from leaf dependencies all the way up to dependents.
• When deploying / undeploying / starting / stopping channels, users will be prompted if any other channels in the dependency chain should be included. The option dialog will show the order in which channels will be deployed / etc. as well.

In 3.4 the HTTP API that Mirth Connect uses has been entirely revamped to be more RESTful and easier to use. External applications / integrations will benefit the most from this, especially if they were communicating with the internal database directly beforehand. Documentation has been much improved as well with a dedicated API page hosted by your server. The documentation page also allows users to login and invoke various endpoints. Everything possible via the Mirth Connect Administrator is also possible through this API.

Dramatically increase throughput by increasing the maximum number of threads that channels can process at once! This is most useful for "stateless" interfaces where order of messages across multiple sources doesn't matter. If you have long-running transformer scripts or destination connectors, and still want responses to flow synchronously from destinations back to the originating system without queuing, this option will allow multiple clients to connect without having them block each other.

New authentication options have been added to all HTTP-based source connectors (HTTP Listener, Web Service Listener, FHIR Listener).