Ability in the dashboard to directly jump/browse from one channel to another related channel, following channel writer/reader "links"

[dfauraz]

When you have complex channels, it is often mandatory to combine a few of them to implement the final features. For example, if you have 2 sources, you need at least 3 channels: 2 for each sources, and one for the "processing/destination". These channels are combined using channel writers/readers. Following the message in the Dashboard is then rather tedious: you have to open the channel 1, find the messages you are interested in, close it, open channel 2, find again the messages etc... The idea would be, in the dashboard, to allow jumping to the "next channel" when you have a channel writer, keeping for example the search criteria (like patient id). And then going back to the channel reader. This would dramatically help "browsing" messages in the dashboard

[pacmano1]

Interesting idea. That assumes a bit though on how people develop their channels. For example, channel A may iterate over an array and use router.routeMessage to send downstream to channel B. Also the downstream channel name may be defined on the fly. In other words there is no channel writer destination, instead the message is routes via code. How do you propose that would work?

[dfauraz]

Several options:

• Do not address this use case (because indeed it is too difficult) but only the channel writer/channel reader use case
• Add something like a correlation id in the routing logic and source map, allowing to link messages from one channel to the other
• I guess other possibilities exist

[dfauraz]

Another option: there is already a source map variable called "sourceChannelId" when you route over channel writer => you would just need to add the same variable when using the router (it does not seem to be the case)

[tom08zehn]

Open multiple Mirth GUIs / windows and display them side by side.

Or maybe you can avoid channel chaining (side effect: saves space in your Mirth DB) and redesign the destination of each source-channel by wrapping everything in a Code Template Library function and putting it in a JavaScript Writer.

[dfauraz]

Thanks @tom08zehn but both suggestions are off topic:

1. the suggestion is about usability, not "how to find your messages"
2. do you know the number of clicks to start a new window and find a message ? Please count ...
3. redesign a channel just because the tool you use is cumbersome is not really an option.
   There are many uses cases when you cannot work with one channel anyway : multiple sources, message split ...

[tom08zehn]

Well, you can't avoid the different source channels. But if all of them have the same Channel Writer as destination then you could replace it with the same JavaScript Writer that just calls one function from the Code Template Library.

But also yes, I agree, sometimes I'd prefer the channel chaining concept as you described because it's more "mirthy".

I was trying to address your issue with some creativity and by using the tools that you already have today. Opening a new Mirth window incl. auto-logon can be accomplished with one double-click (once prepared). Still, you'd need to switch to the other channel's dashboard view... just another double-click. Two clicks is too much? Ideally, you would open several windows and position them (e.g. on 2 screens) using a script. And maybe even the dashboard view could be accomplished using a macro. Gets more complex if you have several source channels... so limited in scalability.

Still, I like your idea. It would require that every message had a unique Mirth-wide (internal UUID) ID that is not equal to the channel's message ID + some advanced Mirth features that allow searching for and "following" an internal message UUID.

[dfauraz]

Another option would be to review the "Search" to make it cross channels: drop-down with the list of channels. Then you could keep all other search criterias (patient id, test id ...) but just change the channel (dropdown or other) to jump around. This would allow keeping the "context" but changing the channel

[tonygermano]

I think this would work with basic search options, but gets messy with advanced search since not all channels necessarily have the same metadata fields.

These existing issues may help somewhat, #3615 #2667