Mirth Connect support and migration: reviewing your estate
What to review in a Mirth Connect estate before you upgrade, re-license, outsource or migrate, from license status and the Java runtime to PHI kept in message storage and the FHIR your channels produce, plus vendor-neutral questions for a support or migration RFP.
For hospital integration teams, health IT managers and the CTO or CIO deciding whether to upgrade, re-license, outsource or migrate.
What is a Mirth Connect estate review?
A Mirth Connect estate review is an evidence-based look at an existing Mirth Connect installation: version and license status, Java runtime, channels, alerts, security settings, PHI in message storage and FHIR output. Agnotic Technologies runs these reviews before support, upgrade or migration work, then builds the monitoring, channel and FHIR fixes the review surfaces.
Last reviewed by the Agnotic Technologies engineering team
What goes wrong in a Mirth Connect estate?
Interface engines run for years with little attention until something stops. These are the problems teams most often find when they finally look.
Version and license drift
Servers stay on releases from before the 4.6 license change with no plan for security fixes, or run a licensed release with nobody tracking the term and renewal.
An unpatched Java runtime
The Java runtime under every interface was installed once and never updated, and nobody knows which update source it should use.
Channel sprawl
Channels nobody can explain are still deployed, and shared code templates and global scripts mean a change for one interface breaks another.
Silent failures
Errors and queued messages alert nobody, so the first sign of a stopped interface is a call from a clinic about a missing result.
PHI kept in message storage
Full message content is stored on every channel at the default setting, and no pruning period was ever agreed, so years of PHI sit in the engine's database.
FHIR output that receivers reject
HL7 v2 to FHIR channels were tested once, and their resources now parse but fail validation against US Core 6.1.0.
What do we build for Mirth Connect estates?
Agnotic Technologies builds to the client's requirements, whether that means keeping Mirth Connect on its current version, upgrading to a licensed release or moving interfaces to another engine.
Channel inventory and dependency map
Every channel, code template and global script exported and listed with its owner, source, destination and the interfaces that depend on it.
Monitoring and alerting outside the engine
Error counts, queue depth, disk and server health sent to the client's monitoring tool, with on-call routing outside working hours.
Version and Java upgrade path
A tested upgrade to the release the client chooses, with a supported OpenJDK runtime and a rollback plan for each step.
Channel regression testing
Sample messages and regression runs for each channel, so a change is tested against real message shapes before it reaches production.
PHI storage and pruning settings
Message storage set per channel on purpose, and pruning configured to the retention period the client has agreed and written down.
Validated HL7 v2 to FHIR transformers
Transformers mapped to the US Core 6.1.0 profiles, with the HL7 FHIR validator run on channel output in the release pipeline.
TLS and access hardening
Encrypted listeners and senders between networks, named accounts with roles and audit events kept long enough to answer who changed what.
Parallel run and cutover tooling
For a migration, old and new engines run side by side with message-level comparison, and interfaces cut over one at a time.
Which parts of the estate need evidence?
Each point needs evidence from whoever administers the server, not a belief that it is fine. Channel sprawl and silent failures are covered in more depth in Mirth Connect pitfalls and how we handle them.
| What to confirm | Where to find it | Risk if missing |
|---|---|---|
| PlatformServer version and license status recorded, with the license term and renewal owner | The Administrator's About dialog, and your license agreement | A release you cannot get fixes for, or a license term nobody is tracking |
| PlatformJava runtime version and update source known and supported | The server host and the service's startup configuration | An unpatched runtime under every interface you run |
| PlatformProduction database identified, sized and backed up, with a restore tested | The database settings in the server's configuration on the host | Message history and channel state lost with the server |
| PlatformServer configuration exported on a schedule and stored off the server | The server settings backup export, and wherever the copies are kept | No way to rebuild the server after a failure |
| ChannelsEvery channel listed with its owner, source, destination and purpose, including disabled ones | The Channels view and exported channel groups | Channels nobody can explain, still deployed |
| ChannelsCode templates and global scripts listed with the channels that call them | The code template library and global scripts | A shared change for one interface breaks another |
| OperationsErrors and queued messages alert a named person, outside working hours too | The Dashboard counts and the Alerts view | Failed messages that nobody is told about |
| OperationsServer health, disk and queue depth watched by a monitoring tool outside Mirth | Your infrastructure monitoring | The engine stops and the first alert is a call from a clinic |
| SecurityTraffic between networks encrypted in transit, listener by listener | Each listener and sender connector, and any proxy or tunnel in front of the server | HL7 v2 with PHI sent in clear text between sites |
| SecurityNamed user accounts only, with roles, and leavers removed | The Users view and your account provisioning process | Shared admin logins and former staff who still have access |
| SecurityAudit events kept long enough to answer who changed a channel or viewed a message | The Events view and its retention settings | No record when an incident needs one |
| PHIMessage storage level set on purpose for each channel, not left at the default | Each channel's message storage setting | Full message content, including PHI, kept on every channel |
| PHIPruning removes stored messages after an agreed period, and the period is written down | The data pruner settings and your retention decision | Years of PHI in the engine's database that nobody decided to keep |
| FHIR outputSample output from each HL7 v2 to FHIR channel validates against US Core 6.1.0 | The HL7 FHIR validator run on saved channel output | Resources that parse but are rejected by the systems that receive them |
What does the 4.6 license change mean for your estate?
NextGen Healthcare moved Mirth Connect to a single commercial license with version 4.6 in March 2025. The version and license row of the estate review tells you which of these paths you are on. None of them is right for everyone; choose with your support model and risk in view.
Stay on your current version
Possible, and NextGen Healthcare says existing source code and documentation stay available. Plan how you will handle security fixes and Java updates yourself.
Move to 4.5.2
The last release published under the open-source license. A step for estates on older versions, not an end state.
License 4.6 or later
Releases from 4.6 come from NextGen Healthcare and authorized resellers. Budget the license and check which extensions your tier includes.
Migrate to another engine
Review the estate first: the channel inventory, code templates and alerts are the migration scope.
Mirth Connect vs a custom integration engineIs your FHIR output ready for USCDI v3?
Channels that turn HL7 v2 into FHIR are often tested once and never again. These checks apply to every resource your engine produces for an API, an HIE or a partner.
- Each resource type your channels emit is listed, with the US Core 6.1.0 profile it should meet.
- Saved output from each channel passes the HL7 FHIR validator against that profile.
- Must Support elements are populated whenever the source message carries the data.
- Codes are mapped to the bound code systems, not passed through as local codes.
- New USCDI v3 data elements your partners expect are traced back to a field in the source messages, or noted as not available.
Which questions belong in a support or migration RFP?
Vendor-neutral questions for any partner, in house team or reseller. Ask for evidence, not adjectives; the right answer is one you can check.
| Question | Why it matters | Evidence to ask for |
|---|---|---|
| How will you handle our current version and license position? | The 4.6 license change sets the upgrade path and its cost. | A written upgrade or license plan for our version |
| How will you inventory our channels before changing anything? | Changes made without an inventory break interfaces nobody listed. | A sample inventory from a past engagement, anonymized |
| How do you test a channel change before it reaches production? | Most interface incidents start with an untested change. | The test approach, with sample messages and regression steps |
| Who is alerted when an interface stops, and how? | Silent failures are the most expensive kind. | The alerting design and escalation path you would set up |
| How will you handle PHI in message storage, logs and test data? | Interface engines often hold more PHI than any other system. | A retention proposal and how test data is de-identified |
| Will you sign a business associate agreement? | A partner that can see message content handles PHI. | Your standard BAA |
| How do you validate HL7 v2 to FHIR output? | Receivers reject resources that do not meet the profile. | A validator report against US Core 6.1.0 |
| What do you hand back if the contract ends? | Exported channels without runbooks are hard to support. | An exit plan listing exports, documentation and credentials |
| If we migrate, how do the old and new engines run side by side? | Cutting over every interface at once multiplies risk. | A parallel-run and cutover plan, interface by interface |
How do you compare the answers?
Score evidence, not confidence. An answer with an artifact attached beats a longer answer without one.
Treat "we will assess that later" for the inventory, alerts or PHI questions as a gap, not a plan.
Ask every respondent the same questions in the same order, so answers can be laid side by side.
Check the BAA and the exit plan before price; both are hard to fix after signing.
Trusted by global innovators
Which sources back this page?
License statements come from NextGen Healthcare's own pages; USCDI and US Core versions from the federal certification regulations.
On 19 March 2025, with the release of version 4.6, Mirth Connect moved from a dual open-source and commercial license to a single commercial, proprietary license; version 4.6 and later releases are available only from NextGen Healthcare and authorized resellers, and source code is no longer published for new releases.
Source: NextGen Healthcare, Mirth Connect wiki (GitHub)NextGen Healthcare states that open-source Mirth Connect users can remain on their current version, upgrade to 4.5.2, the last published open-source version, or become licensed users and upgrade to 4.6.
Source: NextGen Healthcare, A New Era for Mirth ConnectMirth Connect versions 3.7 and later support OpenJDK, so an Oracle Java license is not required to run them.
Source: NextGen Healthcare, Java licensing FAQ (GitHub wiki)45 CFR 170.213 adopts USCDI Version 3 for certified health IT, and the adoption of USCDI Version 1 expired on 1 January 2026.
Source: 45 CFR 170.213 (eCFR)45 CFR 170.215 names the HL7 FHIR US Core Implementation Guide STU 6.1.0 as an API implementation specification for certified health IT.
Source: 45 CFR 170.215 (eCFR)
Which interoperability standards does Agnotic build to?
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
What does this page not cover?
- Which partner to choose
- The RFP questions are neutral on purpose. They help you compare answers; they do not rank vendors.
- Your license terms
- Tiers, extensions and prices come from NextGen Healthcare or an authorized reseller, not from this page.
- Whether every interface is correct
- The estate review tests how the estate is run. Message-level testing of each interface is separate work.
- Legal advice
- This is engineering guidance. Confirm license and contract questions with your procurement and legal teams.
Which interface engine services can help?
Agnotic Technologies supports, upgrades and migrates interface engines for clients, starting from an inventory of channels, code templates and alerts.
- Mirth Connect integration servicesChannel builds, transformers, error handling and HL7 to FHIR bridges.
- Mirth Connect vs a custom integration engineWhen to stay on Mirth and when a custom engine fits better.
- Interface engine migration and modernizationInventory, mapping, parallel run and cutover off a legacy engine.
- HL7 v2 integration servicesADT, ORM and ORU interfaces over MLLP, tested before go-live.
- FHIR integration servicesFHIR R4 and US Core output that receivers accept.
- TEFCA integration servicesQHIN connectivity for the records your engine sends and receives.