Mirth migration

This page answers the question that comes before every switch: what of my Mirth keeps running in Brio-IO — and what does not? It describes today’s state, without promises for later.

The short answer

The script mechanics come across unchanged. E4X brackets, mutation, returning msg at the end — and even the component paths stay as you know them, because both systems number positionally:

// Runs in Mirth. Runs in Brio-IO js-legacy. Unchanged.
var familyName = msg['PID']['PID.5']['PID.5.1'].toString();

The new XML(msg) known from Mirth is not even needed — in Rhino, msg is already an E4X object.

What does not come across are the places where Mirth scripts address the platform itself: channel-to-channel dispatch, direct connector sends, and Mirth’s own Java classes. More on that below.

The importer

Brio-IO reads an exported Mirth channel XML or a ZIP archive and creates connectors and channels from it. Before importing you get a preview showing what would happen — it changes nothing.

Transports that are mapped

Mirth	Brio-IO
HTTP Listener	http-listener
HTTP Sender	http-sender
TCP Listener	mllp-listener
TCP Sender	mllp-sender
File Reader	file-reader
File Writer	file-writer
Database Reader	jdbc-reader
Database Writer	jdbc-writer
JMS Listener	jms-listener
JMS Sender	jms-sender
SMTP Sender	smtp-sender

A Mirth “TCP Listener” is deliberately mapped to mllp-listener — in practice a Mirth TCP listener in healthcare almost always carries HL7 over MLLP.

Transports that are not mapped

A DICOM Listener is recognised as a source transport but not mapped. The importer reports it as unsupported. The same applies to any other transport not in the table above.

Important for planning: an unsupported destination does not make the channel import fail — it is skipped and reported as a warning, and the rest of the channel arrives. An unsupported source, by contrast, leaves the channel unusable, because it has no inbound path.

What the importer warns about

On import, scripts are checked for known non-portable calls. These warnings appear in the import result:

Detected pattern	Warning
router.routeMessage(...)	not available in Brio-IO — use destinations on the channel instead
$co(...)	connector send is not available — use destinations instead
Packages.com.mirth.*	Mirth’s own Java packages are not available

The scripts are not rewritten. They arrive unchanged and are set to js-legacy — the warning tells you where you have to rework by hand.

The three patterns you have to replace

router.routeMessage() → a destination on the channel

In Mirth a script pushes a message into another channel. In Brio-IO that is not a script operation but configuration: the target channel hangs off the channel as a destination.

If you need genuine channel-to-channel transport today, you connect an http-sender to the target channel’s http-listener. A dedicated channel connector does not exist yet.

$co(...) → a destination on the channel

Same idea: where a message goes belongs in the channel, not in the script. That is also why you can see in the message browser where a message went — a send from inside a script would be invisible there.

Packages.com.mirth.* → no replacement

Mirth’s own Java classes do not exist in Brio-IO. Scripts using them need a functional rewrite. This is the one of the three that has no mechanical substitute.

After the import: the migration path

1. Everything starts on js-legacy. The importer sets imported scripts to it automatically. E4X mechanics and component paths keep working unchanged. A look at the message browser confirms, for every received message, the canonical XML your paths run against.
2. Move script by script to Groovy or GraalJS — replacing the bracket strings with property access (msg.PID.PID_5.PID_5_1, with .text() in Groovy). See the Transformer handbook.
3. Done when no js-legacy script is left — at which point the deprecation warning on deploy disappears too.

This is explicitly not a big bang. A channel may carry a Groovy filter and a js-legacy transformer at the same time.

Rhino has an expiry date

js-legacy is deliberately deprecated. Every deploy of a channel with at least one Rhino script produces a deprecation warning — in the log and in the API response — naming the affected scripts.

Version	Behaviour
Brio-IO 1.x (today)	Rhino runs, warning on channel deploy
Brio-IO 2.x	warning becomes more prominent (banner in the channel editor)
Brio-IO 3.x	Rhino only available behind a feature flag
Brio-IO 4.0	Rhino and dot notation are removed

The lead time is long on purpose: migration should happen script by script, not under time pressure.

What else is different

Configuration lives in Git. There is no export button whose output you file away somewhere — every change is a commit. See Concepts.

Dropped messages stay visible. What a filter sorts out appears as a FILTERED row in the message browser instead of vanishing without trace.

Changes can be checked against real traffic beforehand. Shadowing and comparison have no equivalent in Mirth — see Concepts.