Qvera Interface Engine (QIE) is the strongest fit for Mirth teams that want to keep their Java and JavaScript expertise, convert existing channels rather than rebuild them, and move to one fully featured engine supported directly by the company that builds it. If an open-source license, exact drop-in compatibility with 4.5.2, or PostgreSQL or Oracle is mandatory, QIE is not the right answer — the forks and Mirth 4.6+ are compared below. QIE is in production at more than 600 sites, running more than 25,000 interfaces and processing more than 50 million messages a day.
On 19 March 2025 NextGen Healthcare announced that Mirth Connect becomes a single, commercially licensed product from version 4.6. Releases from 4.6 onward are available only from NextGen and its resellers, and their source code is no longer published.
Version 4.5.2, released in September 2024, is the last release under the open-source Mozilla Public License. Its source stays on GitHub and you can keep running it. NextGen’s licensing FAQ makes no statement about security updates or support for 4.5.2 and earlier.
That leaves a Mirth Connect administrator with four choices:
Six things Mirth teams ask of Mirth Connect alternatives, in the order they tend to ask them:
Yes — QIE converts a Mirth Connect configuration directly into QIE channels.
From the QIE console, choose Application → Convert Mirth Configuration and upload your Mirth channel export. The conversion runs on Qvera’s conversion service rather than on your engine, so it continues even if you close the dialog, and it works through four phases: reading the Mirth file, building channels and nodes, converting the JavaScript from the original channels, and assembling the QIE configuration. When it finishes you can import the result directly or download it as a QIE configuration file.
Every conversion produces a report. It lists what was created — zones, channels, nodes and connections — and then, for each channel, the parts of the original Mirth channel that did not convert or that converted in a way worth checking, and where each one is. The same notes appear on each channel’s About tab after import, so the review happens where the work is.
That report is the point. Interfaces are safety-critical; a conversion that told you everything was fine would be less useful than one that tells you exactly where to look. Convert, read the report, test with your own messages, then go live — and Qvera’s support engineers are part of that process, not an extra.
Mirth cells come from the 4.5.2 source code and from NextGen’s published edition tiers; Enterprise is the entry tier, then Gold, then Platinum.
| Technology stack | QIE | Mirth 4.5.2 (open source) | Mirth 4.6+ (commercial) |
|---|---|---|---|
| Java engine, runs in a JVM | ✓ | ✓ | ✓ |
| Interfaces scripted in JavaScript | ✓ | ✓ | ✓ |
| Third-party Java libraries extend the engine | ✓ | ✓ | ✓ |
| Standards & transports | QIE | Mirth 4.5.2 | Mirth 4.6+ |
| HL7 v2 and v3 | ✓ | ✓ | ✓ |
| FHIR | ✓ | ✗ | Gold and Platinum (FHIR R5) |
| DICOM over DIMSE | ✓ C-STORE, C-FIND, C-MOVE, C-GET, C-ECHO, Modality Worklist | C-STORE only | C-STORE only |
| DICOMweb (QIDO-RS, WADO-RS, STOW-RS, UPS-RS) | ✓ | ✗ | not published |
| X12 | ✓ | ✓ | ✓ |
| ASTM | ✓ | ✗ | Gold and Platinum |
| CDA | ✓ | ✓ | ✓ |
| IHE profiles | ✓ | ✗ | not published |
| Security & access | QIE | Mirth 4.5.2 | Mirth 4.6+ |
| SOC 2 Type 2 attested vendor | ✓ | ||
| TLS in transit, including mutual authentication | ✓ | partial — keystore management needs the SSL Manager extension | ✓ Enterprise tier includes SSL Manager |
| Encryption of sensitive data at rest | ✓ Message content encrypted by default; sensitive connection settings (connection strings, usernames, and passwords) encrypted at the field level. | whole-message encryption per channel | whole-message encryption per channel |
| LDAP / Active Directory authentication | ✓ | ✗ | Gold and Platinum |
| OpenID Connect single sign-on | ✓ | ✗ | ✗ |
| Two-factor authentication | ✓ | ✗ | Gold and Platinum |
| Role-based access | ✓ per zone: read, manage, edit | admin or user | Gold and Platinum |
| Configuration audit trail and revision history | ✓ every change, with restore | event log only; no versioning | Enterprise tier (Channel History) |
| Database the engine runs on | QIE | Mirth 4.5.2 | Mirth 4.6+ |
| Microsoft SQL Server | ✓ | ✓ | ✓ |
| MySQL | ✓ | ✓ | ✓ |
| MariaDB | ✓ | ✗ | not published |
| PostgreSQL · Oracle | ✗ | ✓ | ✓ |
| Deployment | QIE | Mirth 4.5.2 | Mirth 4.6+ |
| Windows · Linux | ✓ | ✓ | ✓ |
| Vendor-published container image | ✓ maintained | ✓ 4.5.2 only | ✗ none published |
| Kubernetes, including Azure Kubernetes Service | ✓ | no published guidance | no published guidance |
| AWS Elastic Container Service | ✓ | no published guidance | no published guidance |
| Primary/backup high availability | ✓ | ✓ | ✓ |
| Load-balanced cluster of three or more nodes | ✓ | ✗ | Platinum only (Advanced Clustering) |
| Fleet management across sites and networks | ✓ Remote Management Hub | ✗ | Mirth Command Center: metrics and analytics |
| Building interfaces | QIE | Mirth 4.5.2 | Mirth 4.6+ |
| Mirth channel conversion into QIE, with a review report | ✓ | n/a | n/a |
| AI Companion for configuration and code generation | ✓ | ✗ | ✗ |
| Visual drag-and-drop channel editor | ✓ | ✗ form-based | ✗ form-based |
| Generated script for common mappings | ✓ Code Wizard | Code Templates, Mapper steps | Code Templates, Mapper steps |
| Step-by-step testing with sample messages | ✓ | ✗ | ✗ |
| Operations | QIE | Mirth 4.5.2 | Mirth 4.6+ |
| Error queue with replay or discard | ✓ | ✓ | ✓ |
| Configurable per-channel message persistence | ✓ levels 0–3 | ✓ five storage modes | ✓ five storage modes |
| Alerting on errors and status | ✓ | ✓ | ✓ (+ Advanced Alerting, Platinum only) |
| Management API | ✓ | ✓ | ✓ |
| Support | QIE | Mirth 4.5.2 | Mirth 4.6+ |
| Knowledge base and community | ✓ | ✓ | ✓ |
| Phone support with a live engineer, included | ✓ | ✗ | Gold and Platinum — 24×7; none listed for Enterprise |
| 24/7 system-down support, included | ✓ | ✗ | Not stated; the tier table lists 24×7 phone support at Gold and Platinum |
| Interface development assistance, included | ✓ | ✗ | not published |
| Licensing | QIE | Mirth 4.5.2 | Mirth 4.6+ |
| Model | commercial; see pricing below | MPL 2.0; 4.5.2 is the last NextGen-published open-source release | commercial license, three tiers |
Both forks begin at Mirth Connect 4.5.2, the last open-source release, and each has moved on from there: Eclipse Open Integration Engine ships a 4.6.0 release with its own plugin set, and BridgeLink adds FHIR, paid plugins and a fleet console. Neither currently publishes expanded DICOM support comparable to QIE’s documented DIMSE operations and DICOMweb support. OIE inherits Mirth 4.5.2’s C-STORE capability, while BridgeLink does not document DICOM support. Here is how the two compare with QIE.
| QIE | Eclipse Open Integration Engine | BridgeLink | |
|---|---|---|---|
| Maintainer | Qvera | Maintained by the community; vendor-neutral | Innovar Healthcare |
| License | Commercial | Mozilla Public License 2.0 | Mozilla Public License 2.0 (core) |
| Base | Qvera’s own engine, in production since 2008 | Mirth Connect 4.5.2 | Mirth Connect 4.5.2 |
| Support | From Qvera, the company that builds it, including 24/7 coverage for system-down emergencies | Third-party consultancies, not the project | Sold by Innovar |
| Paid editions | All QIE engine capabilities are included in one edition; Remote Management Hub is a separately licensed product | None | Three editions; two are paid |
| Channel compatibility | Existing Mirth channels convert with the Convert Mirth Configuration utility | Drop-in for 4.5.2 channels | Backward compatible |
| Standards beyond HL7 v2 | HL7 v3, FHIR, DICOM including native DIMSE and DICOMweb, X12, NCPDP, ASTM, CDA and IHE profiles — one engine, one license | Inherits the Mirth 4.5.2 core capability set. No FHIR or expanded DICOM plugin appears in the current published plugin catalog. The Eclipse project proposal includes FHIR and DICOM in scope; expanding native FHIR support is identified as future work. | HL7 and FHIR; DICOM not documented |
| Remotely manage & administer many sites | Remote Management Hub: monitor, control and administer QIE instances inside separate customer networks from one console, over outbound-only connections with no per-site VPN | No central multi-instance management; OIE Sentinel monitors and alerts per instance | BridgeLink Fleet: central monitoring, configuration drift and promotion, fleet-wide alerts |
| AI-assisted interface build | AI Companion, included with every license — builds and troubleshoots interfaces from a plain-English description | None documented | Enterprise edition only |
| Who sets the roadmap | Qvera, as the vendor — one company answerable for what ships next | No single company | Innovar |
A fork is the smaller decision today. QIE becomes especially compelling when you need supported FHIR, full DIMSE and DICOMweb, and cross-site administration from one vendor-supported platform.
Mirth Connect, its open-source forks and QIE are not the only healthcare integration engines available. Depending on an organization’s requirements and existing technology relationships, its shortlist may also include other established engines. They are not Mirth-derived products, and their development models, migration approaches, deployment options, licensing and support structures differ enough that reducing them to a few checkmarks would obscure more than it clarified. This page therefore compares in detail the choices most directly connected to a Mirth team’s immediate decision: remain on open-source Mirth 4.5.2, license commercial Mirth 4.6+, adopt a Mirth-derived fork, or convert to QIE.
If another engine is on your shortlist, ask every vendor—including Qvera—to demonstrate the transition using one of your actual Mirth channels. Ask what converts, what must be rebuilt, how the result is tested, and what the complete cost will be after support, high availability, non-production environments, additional modules and multi-instance management are included. Qvera offers that evaluation through the Mirth conversion utility, its conversion report and a free QIE trial.
Yes — and with QIE it is one engine. Anything QIE does for HL7 v2 it also does for HL7 v3, FHIR, DICOM including native DIMSE and DICOMweb, X12, ASTM, CDA and IHE profiles, over MLLP, REST, SFTP, file, database, message queue and network share. The Qvera DICOM Router is that same engine configured for imaging.
It runs on Windows or Linux, in Docker or Kubernetes from images Qvera maintains, or on AWS ECS — on-premise, in containers, or in your own AWS, Azure or Google Cloud account, against Microsoft SQL Server, MySQL or MariaDB. Running engines at more than one site, or inside networks you do not control, is what the Remote Management Hub is for.
The Qvera Interface Engine · The Qvera DICOM Router · Remote Management Hub
Qvera offers Channel-based, Enterprise, and OEM licensing models. Channel-based licensing starts at $9,980 per year for 2 channels. View Qvera Licensing and Pricing.
QIE is in production at more than 600 sites, running more than 25,000 interfaces and processing more than 50 million messages a day. Qvera has built healthcare interface engine software since 2008 and is SOC 2 Type 2 attested.
How this comparison is sourced: Qvera publishes this page and sells QIE. What this page says about QIE comes from Qvera’s own product documentation and production deployments; about Mirth Connect, from the 4.5.2 source and NextGen’s published edition tiers; about the community forks, from each project’s own site, release notes and plugin documentation. All competitor information was last reviewed on 18 September 2026 — vendors change their products and tiers, so check the linked sources before relying on any single claim. Found something out of date? Tell us and we will correct it.
