PerfuseLeaving Mirth Connect
A free alternative to Mirth Connect that runs your channels
From version 4.6, Mirth Connect is commercial only. Perfuse is free under Apache 2.0, reads your Mirth exports, runs your existing JavaScript unchanged, and runs beside Mirth on your real traffic until you can prove the two agree.
Why sites look elsewhere
Mirth works. Its licence changed.
Mirth Connect has run interfaces at thousands of sites for nearly twenty years. Teams start looking for other reasons:
The licence
NextGen no longer publishes open-source releases. The free engine many hospitals run has no upgrade path that stays free.
The Java runtime
A JVM to install, patch and keep supported on every server the engine touches.
The footprint
A 254 MB install plus OpenJDK, holding 383 MB of memory while idle.
Restarts
An engine that needs to warm up is one you think twice about restarting in the working day.
Side by side
Perfuse and Mirth Connect
| Perfuse | Mirth Connect | |
|---|---|---|
| Licence | Apache 2.0, no tiers | Commercial only since 4.6 |
| Memory at rest | 45 MB | 383 MB |
| Runtime required | None: one program | OpenJDK 17 |
| Your Mirth JavaScript | Runs unchanged, E4X included | Native |
| Formats | HL7 v2, FHIR, DICOM, X12, CDA in the one program | HL7 v2 and FHIR core; others by extension |
| Kafka, MQTT, IBM MQ, Google Cloud | Built in | Not built in |
| CMS-0057-F payer APIs | All four, tested with Inferno | Not provided |
| Find a patient across formats | One search box over HL7 v2, FHIR, DICOM and X12 | Search per format |
| Production track record | None yet (v0.1.23) | Twenty years, thousands of sites |
The last row should weigh more than the first. Perfuse has not yet processed production clinical traffic. Everything that was tested is written down, and so is everything that was not, in the verification record.
The usual blocker
E4X runs here
Mirth transformers are JavaScript, and many use E4X, the syntax that lets a script write
msg['PID']['PID.5']['PID.5.1']. Modern JavaScript engines removed E4X years ago, so most migrations discover on
the first transformer that they are really a rewrite. Perfuse runs E4X, along with channelMap, $(),
DateUtil and SerializerFactory.
That is why a Mirth migration here is a conversion, not a rewrite of every transformer you own.
How the move works
Five steps, each one reversible
1. Explain
perfuse explain server-backup.xml says by
name what converts, what converts with caveats, and what does not, before you commit to anything.
2. Translate
perfuse translate turns a channel, a
group, a code template library or a whole server backup into Perfuse channels.
3. Test
perfuse test runs each channel on sample
messages and checks what comes out.
4. Run beside Mirth
Mirth forwards a copy of live traffic; Perfuse writes its results to a folder and delivers nothing. No patient is affected, so nobody needs to approve it.
5. Prove
perfuse compare pairs the two engines'
outputs by message and reports every difference, grouped by cause.
The same tools work for the Open Integration Engine and BridgeLink, the open-source forks of Mirth, and Perfuse can write channels back out as Mirth files, so the door stays open both ways.
Quick start
Find out in a minute what your channels need
Export your Mirth server backup from the Administrator (or OIE, or BridgeLink), and run these on any machine. Nothing is changed or sent anywhere.
The full migration guide# what converts, what converts with caveats, what does not
perfuse explain server-backup.xml
# bring the channels across, code template libraries included
perfuse translate -o channels/ server-backup.xml
# run each channel on sample messages
perfuse test channels/
# after running both engines on the same messages,
# only Mirth delivering: every difference, grouped by cause
perfuse compare mirth-out/ perfuse-out/| Area | Tested | Not yet |
|---|---|---|
| Reading Mirth exports | Server backups, channel groups and code template libraries written by Mirth 4.5.2, OIE 4.5.2 and 4.6.0, and BridgeLink 26.9.0 themselves, translated and run on every build | Channels set up by hand in each Administrator may use settings this corpus does not; third-party plugins are not covered |
| Connectors | MLLP and TCP, HTTP, file, database, DICOM, Web Service (SOAP), SMTP, JavaScript, Channel Reader/Writer | JMS and the Document Writer do not translate, and are reported as blockers |
| Scripts | Mirth JavaScript with E4X, channelMap, $(), DateUtil, and the
common Java classes (SimpleDateFormat, HashMap and the like) | Calls into Mirth's own server classes, vendor jars and uncommon Java classes fail by name; the explain report lists each one |
| Writing channels back to Mirth | Ten transport pairs loaded into all four engines without being marked invalid | Filters, transformations and scripts have no place in Mirth's format and are listed, not approximated |
| Production | No hospital has run production traffic through Perfuse yet. That is why step 4 runs it beside Mirth, delivering nothing, until the comparison is clean. | |
Find out what your channels need, today
Run perfuse explain on your Mirth export. It changes nothing and takes a minute.